3 Konfigurációkezelés
A csatornakonfiguráció során szükség van szolgáltatáskonfigurációra, optikai réteg logikai kapcsolatkonfigurációra és kapcsolat virtuális topológia térkép konfigurációra. Ha egyetlen csatorna konfigurálható védelmi útvonallal, akkor a csatornakonfiguráció ekkor bonyolultabb lesz, és az ebből következő konfigurációkezelés is bonyolultabb. Egy dedikált szolgáltatástáblázatra van szükség a csatornairányok kezeléséhez, és az üzleti irányokat a táblázatban folytonos és szaggatott vonalakkal kell megkülönböztetni. Az OTN csatornák és az IP-kapcsolatok közötti megfelelés kezelésekor, különösen OTN-védelem esetén, egy IP-kapcsolatnak több OTN-csatornának kell megfelelnie. Ekkor a kezelés mennyisége megnő, és a kezelés bonyolultabbá válik, ami az Excel-táblázatok kezelését is növeli. Az üzleti tevékenység összes elemének teljes kezeléséhez szükséges követelmények akár 15-ig is eltarthatnak. Amikor egy mérnök egy bizonyos kapcsolatot szeretne kezelni, meg kell találnia az Excel-űrlapot, majd a gyártó NMS-ében kell megtalálnia a megfelelőt, és ezután végre kell hajtania az üzemeltetést. Ehhez mindkét oldalon szinkronizálni kell az információkat. Mivel az OTN NMS platformja és a mérnök által készített Excel két ember alkotta adat, könnyen előfordulhat, hogy az információk nincsenek szinkronban. Bármely hiba miatt az üzleti információk eltérhetnek a tényleges kapcsolattól. Ennek megfelelően befolyásolhatja az üzletmenetet a változtatások és módosítások során. Ezért a gyártó berendezésadatait egy felügyeleti platformra gyűjtik az északi irányú interfészen keresztül, majd az IP-kapcsolat információit ezen a platformon egyeztetik, így az információk automatikusan módosíthatók a meglévő hálózat szolgáltatásváltozásainak megfelelően, és biztosított az információk központosított kezelése, valamint egyetlen pontossági forrás biztosítja a konfigurációkezelési információk pontosságát.
Az OTN szolgáltatás kiépítésének konfigurálásakor készítse el az egyes interfészek információs leírását, majd gyűjtse össze az OTN információkat az OTN NMS által biztosított északi irányú interfészen keresztül, és párosítsa a vonatkozó leírást az IP-eszköz által az északi irányú interfészen keresztül gyűjtött portinformációkkal. Az OTN csatornák és IP-kapcsolatok platformalapú kezelése kiküszöböli a manuális információfrissítés szükségességét.
A DCI átviteli hálózat használata esetén kerülni kell az elektromos keresztösszekötős szolgáltatáskonfiguráció alkalmazását. Ez a módszer rendkívül összetett a felügyeleti logikában, és nem alkalmazható a DCI hálózati modellre. Már a DCI tervezésének kezdetétől elkerülhető.
4 Riasztáskezelés
Az OTN összetett kezelési terhei, a nagy távolságú átvitel során a jelfigyelés, valamint a különböző szolgáltatási részecskék multiplexálása és beágyazása miatt egy hiba több tucat vagy több száz riasztási üzenetet is jelenthet. Bár a gyártó négy szintre sorolta a riasztásokat, és minden riasztásnak más a neve, a mérnöki üzemeltetés és karbantartás szempontjából ez továbbra is rendkívül bonyolult, és tapasztalt személyzetre van szükség a hiba okának meghatározásához. A hagyományos OTN berendezések hibaüzenet-küldési funkciója főként SMS modemet vagy e-mail push-t használ, de a két funkció speciális az internetes vállalat alaprendszerének meglévő hálózati riasztáskezelő platformjával való integráció szempontjából, és a külön fejlesztés költsége magas, ezért többet kell tenni. A szabványos észak felé irányuló interfész összegyűjti a riasztási információkat, kibővíti a funkciókat, miközben megtartja a vállalat meglévő releváns platformjait, majd továbbítja a riasztást az üzemeltetési és karbantartási mérnöknek.
Ezért az üzemeltetési és karbantartó személyzet számára szükséges, hogy a platform automatikusan konvergálja az OTN hiba által generált riasztási információkat, majd fogadja az információkat. Ezért először be kell állítani a riasztási besorolást az OTN NMS-en, majd el kell végezni a küldési és szűrési munkákat az utolsó riasztási információkezelő platformon. Az általános OTN riasztási módszer az, hogy az NMS beállítja és elküldi az összes első és második típusú riasztást a riasztási információkezelő platformnak, majd a platform elemzi egyetlen szolgáltatáskimaradás riasztási információit, a főbb optikai útvonal-megszakítás riasztási információit és (ha van ilyen) a védelmi kapcsolási riasztási információkat elküldi az üzemeltetési és karbantartó mérnöknek. A fenti három információ valószínűleg felhasználható a hibák diagnosztizálására és feldolgozására. A vétel beállításakor beállíthatja a telefonos értesítési beállításokat a nagyobb riasztásokhoz, például az összetett jelhibákhoz, amelyek csak akkor fordulnak elő, ha az optikai szálak megszakadnak, például a következőkhöz:
Riasztás kínai leírása
Riasztás angol leírása Riasztás típusa Súlyosság és korlátozás
OMS réteg hasznos teher jelveszteség OMS_LOS_P Kommunikációs riasztás kritikus (FM)
Bemeneti/kimeneti kombinált jelveszteség MUT_LOS kommunikációs riasztás vészhelyzet (FM)
OTS hasznos teher veszteség
OTS_LOS_P jel Kommunikációs riasztás Kritikus (FM)
OTS hasznos teher veszteség jelzés OTS_PMI kommunikációs riasztás sürgős (FM)
Az NMS észak felé irányú interfészét, például a Huawei és a ZTE Alang által jelenleg támogatott XML interfészt, gyakran használják riasztási információk továbbítására is.
5 Teljesítménymenedzsment
Az OTN rendszer stabilitása nagymértékben függ a rendszer különböző aspektusainak teljesítményadataitól, például a trunk szál optikai teljesítménygazdálkodásától, a multiplexelt jel egyes csatornáinak optikai teljesítménygazdálkodásától és a rendszer OSNR margin gazdálkodásától. Ezeket a tartalmakat hozzá kell adni a vállalat hálózati rendszerének monitorozási projektjéhez, hogy bármikor megismerhető legyen a rendszer teljesítménye, és időben optimalizálható legyen a teljesítmény a hálózat stabilitásának biztosítása érdekében. Ezenkívül a hosszú távú szálteljesítmény és minőségfigyelés felhasználható a szálirányítás változásainak felfedezésére is, megakadályozva, hogy egyes szálbeszállítók értesítés nélkül megváltoztassák a szálirányítást, ami működési és karbantartási vakfoltokat, valamint a szálirányítási kockázat előfordulását eredményezné. Természetesen ehhez nagy mennyiségű adatra van szükség a modell betanításához, hogy az útvonalváltozások felfedezése pontosabb legyen.
6. DCN-kezelés
A DCN itt az OTN berendezés felügyeleti kommunikációs hálózatára utal, amely felelős az OTN egyes hálózati elemeinek felügyeletének hálózati struktúrájáért. Az OTN hálózat befolyásolja a DCN hálózat méretét és összetettségét is. Általában kétféle DCN hálózat létezik:
1. Erősítse meg az aktív és készenléti átjáró NE-ket a teljes OTN hálózatban. A többi nem átjáró NE hagyományos NE. Az összes hagyományos NE felügyeleti jelei az OSC csatornán keresztül, az OTS rétegen keresztül érik el az aktív és a készenléti átjáró NE-ket az OTN-ben, majd csatlakozzanak ahhoz az IP hálózathoz, ahol az NMS található. Ez a módszer csökkentheti a hálózati elemek telepítését az NMS-t tartalmazó IP hálózaton, és magát az OTN-t használhatja a hálózatfelügyeleti probléma megoldására. Ha azonban a trunk szál megszakad, a megfelelő távoli hálózati elemek is érintettek lesznek, és kikerülnek a felügyelet alól.
2. Az OTN hálózat összes hálózati eleme átjáró hálózati elemként van konfigurálva, és minden átjáró hálózati elem önállóan kommunikál az NMS-t tartalmazó IP-hálózattal, az OSC csatornán keresztül. Ez biztosítja, hogy a hálózati elemek felügyeleti kommunikációját ne befolyásolja a fő optikai szál megszakadása, és a hálózati elemek továbbra is távolról kezelhetők legyenek, mindegyik az IP-hálózathoz csatlakozik, valamint a hagyományos IP-hálózati dolgozók üzemeltetési és karbantartási költségei is csökkennek.
A DCN hálózat kiépítésének kezdetén el kell végezni a hálózati elemek tervezését és az IP-címek kiosztását. Különösen a hálózatkezelő szervert kell a lehető legnagyobb mértékben elszigetelni a többi hálózattól a telepítés során. Ellenkező esetben később túl sok mesh kapcsolat lesz a hálózatban, és a karbantartás során a hálózati jitter normális lesz, és a szokásos hálózati elemek nem lesznek csatlakoztatva. Problémák jelentkezhetnek, például az átjáró hálózati elem, és az éles hálózati cím és a DCN hálózat címe újrafelhasználásra kerül, ami hatással lesz az éles hálózatra.
Közzététel ideje: 2022. dec. 19.