3 Konfiguratsioonihaldus
Kanali konfigureerimise ajal on vaja teenuse konfigureerimist, optilise kihi loogilise lingi konfigureerimist ja lingi virtuaalse topoloogiakaardi konfigureerimist. Kui üks kanal saab konfigureerida kaitseteega, on kanali konfiguratsioon sel ajal keerulisem ja sellest tulenev konfiguratsioonihaldus samuti keerulisem. Kanali suuna haldamiseks on vaja spetsiaalset teenusetabelit ning ärisuunad tuleb tabelis eristada pidevate ja katkendlike joonte abil. OTN-kanalite ja IP-linkide vahelise vastavuse haldamisel, eriti OTN-kaitse puhul, peab üks IP-link vastama mitmele OTN-kanalile. Sel ajal suureneb haldusmaht ja haldamine on keerukam, mis suurendab ka Exceli tabelite haldamist. Nõuded ettevõtte kõigi elementide täielikuks haldamiseks võivad ulatuda kuni 15-ni. Kui insener soovib teatud linki hallata, peab ta leidma Exceli vormi ja seejärel minema tootja NMS-i, et leida vastav ja seejärel teostada toimingute haldamist. See nõuab teabe sünkroniseerimist mõlemal poolel. Kuna OTN-i NMS-platvorm ja inseneri loodud Excel on kaks inimese loodud andmeallikat, on teave kergesti sünkroonist väljas. Igasugune viga põhjustab äriteabe vastuolu tegeliku seosega. Seega võib see muutuste ja kohandamise korral mõjutada äritegevust. Seetõttu kogutakse tootja seadmete andmed haldusplatvormile põhjasuunalise liidese kaudu ja seejärel sobitatakse IP-lingi teave sellel platvormil, et teavet saaks automaatselt kohandada vastavalt olemasoleva võrgu teenusemuudatustele ning tagada teabe tsentraliseeritud haldamine ja ühtne täpsusallikas konfiguratsioonihaldusteabe täpsuse tagamiseks.
OTN-teenuse pakkumise konfigureerimisel valmistage ette iga liidese teabekirjeldus ja seejärel koguge OTN-teavet OTN NMS-i pakutava põhjasuunalise liidese kaudu ning siduge asjakohane kirjeldus IP-seadme poolt põhjasuunalise liidese kaudu kogutud porditeabega. OTN-kanalite ja IP-linkide platvormipõhine haldamine välistab vajaduse teabe käsitsi värskendamiseks.
DCI ülekandevõrgu kasutamisel tuleks püüda vältida elektrilise ristühenduse teenuse konfiguratsiooni. See meetod on haldusloogika poolest äärmiselt keeruline ja ei kehti DCI võrgumudeli kohta. Seda saab DCI disaini algusest peale vältida.
4 Häirete haldamine
OTN-i keerukate halduskulude, pikamaaülekande signaali jälgimise ning erinevate teenuseosakeste multipleksimise ja pesastamise tõttu võib rike edastada kümneid või sadu häiresõnumeid. Kuigi tootja on liigitanud alarmid neljaks tasemeks ja igal alarmil on erinev nimi, on see siiski inseneri käitamise ja hoolduse seisukohast äärmiselt keeruline ning rikke põhjuse esmaseks kindlakstegemiseks on vaja kogenud personali. Traditsiooniliste OTN-seadmete rikketeadete saatmise funktsioon kasutab peamiselt SMS-modemi või e-posti teel edastamist, kuid need kaks funktsiooni on spetsiaalsed integreerimiseks Interneti-ettevõtte põhisüsteemi olemasoleva võrguhäirete haldusplatvormiga ning eraldi arenduse kulud on suured, seega on vaja rohkem ära teha. Standardne põhjasuunaline liides kogub häireteavet, laiendab funktsioone, säilitades samal ajal ettevõtte olemasolevad asjakohased platvormid, ja seejärel edastab häire käitamise ja hoolduse insenerile.
Seetõttu on käitus- ja hoolduspersonali jaoks vaja lasta platvormil automaatselt koonda OTN-i rikke tekitatud häireinfo ja seejärel info vastu võtta. Seega tuleb esmalt seadistada OTN-i NMS-il häire klassifikatsioon ja seejärel teostada saatmis- ja sõelumistööd viimasel häireinfo haldusplatvormil. Üldine OTN-i häiremeetod on see, et NMS seadistab ja edastab kõik esimese ja teise tüübi häired häireinfo haldusplatvormile ning seejärel analüüsib platvorm ühe teenusekatkestuse häireinfot, peamise optilise tee katkestuse häireinfo ja (kui see on olemas) kaitselülituse häireinfo edastatakse käitus- ja hooldusinsenerile. Ülaltoodud kolme infot saab tõenäoliselt kasutada rikete diagnoosimiseks ja töötlemiseks. Vastuvõtu seadistamisel saate seadistada telefoniteavitusseaded suuremate häirete, näiteks liitsignaali rikete jaoks, mis tekivad ainult optiliste kiudude purunemisel, näiteks järgmised:
Alarmi hiina kirjeldus
Häire ingliskeelne kirjeldus Häire tüüp Tõsidusaste ja piirangud
OMS-kihi kasuliku koormuse signaali kadu OMS_LOS_P Sidehäire kriitiline (FM)
Sisend/väljund Kombineeritud signaali kadu MUT_LOS Sidehäire Hädaolukord (FM)
OTS-i kasuliku koormuse kaotus
Signaal OTS_LOS_P Sidehäire kriitiline (FM)
OTS-i kasuliku koormuse kadumise näidik OTS_PMI sidehäire kiireloomuline (FM)
NMS-i põhjasuunalist liidest, näiteks Huawei ja ZTE Alangi praegu toetatavat XML-liidest, kasutatakse tavaliselt ka häireteabe edastamiseks.
5 Tulemuste juhtimine
OTN-süsteemi stabiilsus sõltub suuresti süsteemi erinevate aspektide jõudlusandmetest, näiteks magistraalkiu optilise võimsuse haldusest, multipleksitud signaali iga kanali optilise võimsuse haldusest ja süsteemi OSNR-i marginaali haldusest. Need andmed tuleks lisada ettevõtte võrgusüsteemi jälgimisprojekti, et süsteemi jõudlust igal ajal teada ja seda õigeaegselt optimeerida, et tagada võrgu stabiilsus. Lisaks saab pikaajalist kiu jõudluse ja kvaliteedi jälgimist kasutada ka kiu marsruutimise muutuste avastamiseks, takistades mõnedel kiu tarnijatel kiu marsruutimist ette teatamata muutmast, mis võib põhjustada töö ja hoolduse ajal pimealasid ning kiu marsruutimise riski. Loomulikult nõuab see mudeli treenimiseks suurt hulka andmeid, et marsruutimise muutusi oleks võimalik täpsemalt avastada.
6. DCN-i haldus
DCN viitab siin OTN-seadmete halduskommunikatsioonivõrgule, mis vastutab OTN-i iga võrguelemendi haldusvõrgu struktuuri eest. OTN-võrk mõjutab ka DCN-võrgu ulatust ja keerukust. Üldiselt on DCN-võrgu loomiseks kaks meetodit:
1. Kinnitage kogu OTN-võrgu aktiivsed ja ooterežiimis olevad lüüsi NE-d. Teised mitte-lüüsi NE-d on tavalised NE-d. Kõigi tavaliste NE-de haldussignaalid jõuavad aktiivsete ja ooterežiimis olevate lüüsi NE-deni OSC-kanali kaudu OTS-kihi kaudu OTN-is ja seejärel ühenduvad IP-võrguga, kus NMS asub. See meetod võib vähendada võrguelementide juurutamist IP-võrgus, kus NMS asub, ja kasutada OTN-i ennast võrguhaldusprobleemi lahendamiseks. Kui aga magistraalkiud katkeb, mõjutab see ka vastavaid kaugvõrgu elemente ja need jäävad haldusest välja.
2. Kõik OTN-võrgu võrguelemendid on konfigureeritud lüüsi-võrguelementidena ning iga lüüsi-võrguelement suhtleb NMS-i asukohaga IP-võrguga iseseisvalt, ilma OSC-kanalit läbimata. See tagab, et peamise optilise kiu katkemine ei mõjuta võrguelementide halduskommunikatsiooni ning võrguelemente saab endiselt hallata eemalt, kuna kõik need on ühendatud IP-võrguga, vähendades samal ajal ka traditsiooniliste IP-võrgu töötajate tegevus- ja hoolduskulusid.
DCN-võrgu ehituse alguses tuleks läbi viia võrguelementide planeerimine ja IP-aadresside eraldamine. Eelkõige tuleks võrguhaldusserver juurutamisel teistest võrkudest võimalikult isoleerida. Vastasel juhul on võrgus hiljem liiga palju võrgusilmi, hoolduse ajal on võrgu värin normaalne ja tavalised võrguelemendid ei ole ühendatud. Ilmnevad probleemid, näiteks lüüsivõrgu element, ning tootmisvõrgu aadressi ja DCN-võrgu aadressi kasutatakse uuesti, mis mõjutab tootmisvõrku.
Postituse aeg: 19. detsember 2022