3 Konfigurasiebestuur
Tydens kanaalkonfigurasie word dienskonfigurasie, optiese laag logiese skakelkonfigurasie en skakel virtuele topologiekaartkonfigurasie vereis. As 'n enkele kanaal met 'n beskermingspad gekonfigureer kan word, sal die kanaalkonfigurasie op hierdie tydstip meer ingewikkeld wees, en die daaropvolgende konfigurasiebestuur sal ook meer ingewikkeld wees. 'n Toegewyde dienstabel is nodig net om kanaalrigting te bestuur, en besigheidsrigtings moet in die tabel onderskei word deur soliede en stippellyne te gebruik. Wanneer die korrespondensie tussen OTN-kanale en IP-skakels bestuur word, veral in die geval van OTN-beskerming, moet een IP-skakel ooreenstem met verskeie OTN-kanale. Op hierdie tydstip neem die bestuurshoeveelheid toe en is die bestuur ingewikkeld, wat ook die bestuur van Excel-tabelle verhoog. Vereistes om alle elemente van 'n besigheid volledig te bestuur, tot 15. Wanneer 'n ingenieur 'n sekere skakel wil bestuur, moet hy die Excel-vorm uitvind, en dan na die vervaardiger se NMS gaan om die ooreenstemmende te vind, en dan operasionele bestuur uit te voer. Dit vereis die sinchronisasie van inligting aan beide kante. Aangesien die NMS-platform van OTN en die Excel wat deur die ingenieur gemaak word, twee mensgemaakte data is, is dit maklik vir die inligting om nie gesinchroniseerd te wees nie. Enige fout sal veroorsaak dat die besigheidsinligting teenstrydig is met die werklike verhouding. Gevolglik kan dit die besigheid beïnvloed tydens verandering en aanpassing. Daarom word die toerustingdata van die vervaardiger deur die noordwaartse koppelvlak na 'n bestuursplatform versamel, en dan word die inligting van die IP-skakel op hierdie platform gekoppel, sodat die inligting outomaties aangepas kan word volgens die diensveranderinge van die bestaande netwerk, en die gesentraliseerde bestuur van die inligting verseker word. 'n Enkele bron van akkuraatheid om die akkuraatheid van konfigurasiebestuursinligting te verseker.
Wanneer OTN-diensvoorsiening gekonfigureer word, berei die inligtingsbeskrywing van elke koppelvlak voor, en versamel dan OTN-inligting deur die noordwaartse koppelvlak wat deur die OTN NMS verskaf word, en koppel die relevante beskrywing met die poortinligting wat deur die IP-toestel deur die noordwaartse koppelvlak versamel word. Die platformgebaseerde bestuur van OTN-kanale en IP-skakels elimineer die behoefte aan handmatige inligtingopdatering.
Vir die gebruik van die DCI-transmissienetwerk, probeer om die gebruik van elektriese kruisverbindingsdienskonfigurasie te vermy. Hierdie metode is uiters kompleks in bestuurslogika, en dit is nie van toepassing op die DCI-netwerkmodel nie. Dit kan van die begin van DCI-ontwerp vermy word.
4 Alarmbestuur
As gevolg van OTN se komplekse bestuursoorhoofse koste, seinmonitering tydens langafstand-oordrag, en multipleksering en nesmaak van verskillende diensdeeltjies, kan 'n fout dosyne of honderde alarmboodskappe rapporteer. Alhoewel die vervaardiger alarms in vier vlakke geklassifiseer het, en elke alarm 'n ander naam het, is dit steeds uiters ingewikkeld vanuit die perspektief van 'n ingenieur se werking en onderhoud, en dit vereis ervare personeel om die oorsaak van die fout in die eerste plek te bepaal. Die foutversendingsfunksie van tradisionele OTN-toerusting gebruik hoofsaaklik SMS-modem of e-posstoot, maar die twee funksies is spesiaal vir integrasie met die bestaande netwerkalarmbestuursplatform van die internetmaatskappy se basiese stelsel, en die koste van afsonderlike ontwikkeling is hoog, dus moet meer gedoen word. Die standaard noordwaartse koppelvlak versamel alarminligting, brei die funksies uit terwyl die maatskappy se bestaande relevante platforms behoue bly, en stuur dan die alarm na die bedryfs- en onderhoudsingenieur.
Daarom is dit vir die bedryfs- en instandhoudingspersoneel nodig om die platform outomaties die alarminligting wat deur die OTN-fout gegenereer word, te laat saamsmelt, en dan die inligting te ontvang. Stel dus eers die alarmklassifikasie op die OTN NMS in, en voer dan die stuur- en siftingswerk op die laaste alarminligtingbestuursplatform uit. Die algemene OTN-alarmmetode is dat die NMS al die eerste en tweede tipes alarms sal stel en na die alarminligtingbestuursplatform sal stuur, en dan sal die platform die alarminligting van 'n enkele diensonderbreking analiseer, die hoof Die optiese padonderbrekingsalarminligting en (indien enige) beskermingskakelalarminligting word na die bedryfs- en instandhoudingsingenieur gestuur. Die bogenoemde drie inligting kan waarskynlik gebruik word vir foutdiagnose en -verwerking. Wanneer u ontvangs opstel, kan u telefoonkennisgewinginstellings opstel vir groot alarms soos saamgestelde seinfoute wat slegs voorkom wanneer optiese vesels gebreek is, soos die volgende:
Alarm Chinese beskrywing
Alarm Engelse beskrywing Alarmtipe Ernstigheid en beperking
OMS-laag-vragseinverlies OMS_LOS_P Kommunikasie-alarm Krities (FM)
Invoer/Uitvoer Gekombineerde Seinverlies MUT_LOS Kommunikasie Alarm Noodgeval (FM)
OTS-vragverlies van
Sein OTS_LOS_P Kommunikasie Alarm Krities (FM)
OTS-vragverlies-aanduiding OTS_PMI Kommunikasie-alarm Dringend (FM)
Die noordwaartse koppelvlak van die NMS, soos die XML-koppelvlak wat tans deur Huawei en ZTE Alang ondersteun word, word ook algemeen gebruik om alarminligting te stuur.
5 Prestasiebestuur
Die stabiliteit van die OTN-stelsel is hoogs afhanklik van die werkverrigtingsdata van verskeie aspekte van die stelsel, soos die optiese kragbestuur van die stamvesel, die optiese kragbestuur van elke kanaal in die gemultiplekseerde sein, en die stelsel se OSNR-margebestuur. Hierdie inhoud moet by die moniteringsprojek van die maatskappy se netwerkstelsel gevoeg word, sodat die stelselprestasie te eniger tyd geken kan word en die werkverrigting betyds geoptimaliseer kan word om die stabiliteit van die netwerk te verseker. Daarbenewens kan langtermyn-veselprestasie- en kwaliteitsmonitering ook gebruik word om veranderinge in veselroetering te ontdek, wat verhoed dat sommige veselverskaffers veselroetering sonder kennisgewing verander, wat lei tot blinde kolle in werking en instandhouding, en die voorkoms van veselroeteringsrisiko. Dit vereis natuurlik 'n groot hoeveelheid data vir modelopleiding, sodat die ontdekking van roeteveranderinge meer akkuraat kan wees.
6. DCN-bestuur
Die DCN verwys hier na die bestuurskommunikasienetwerk van die OTN-toerusting, wat verantwoordelik is vir die netwerkstruktuur van die bestuur van elke netwerkelement van die OTN. Die OTN-netwerk sal ook die skaal en kompleksiteit van die DCN-netwerk beïnvloed. Oor die algemeen is daar twee metodes van DCN-netwerke:
1. Bevestig die aktiewe en bystand-poort-NE's in die hele OTN-netwerk. Ander nie-poort-NE's is gewone NE's. Die bestuurseine van alle gewone NE's bereik die aktiewe en bystand-poort-NE's deur die OSC-kanaal oor die OTS-laag in die OTN, en koppel dan aan die IP-netwerk waar die NMS geleë is. Hierdie metode kan die ontplooiing van netwerkelemente op die IP-netwerk waar die NMS geleë is, verminder en die OTN self gebruik om die netwerkbestuursprobleem op te los. As die stamvesel egter onderbreek word, sal die ooreenstemmende afgeleë netwerkelemente ook beïnvloed word en buite bestuur wees.
2. Al die netwerkelemente van die OTN-netwerk is as poortnetwerkelemente gekonfigureer, en elke poortnetwerkelement kommunikeer onafhanklik met die IP-netwerk waar die NMS geleë is sonder om deur die OSC-kanaal te gaan. Dit verseker dat die bestuurskommunikasie van die netwerkelemente nie beïnvloed word deur die onderbreking van die hoof optiese vesel nie, en die netwerkelemente kan steeds op afstand bestuur word, wat almal aan die IP-netwerk gekoppel is, en die bedryfs- en onderhoudskoste vir tradisionele IP-netwerkwerkers sal ook verminder word.
Aan die begin van die DCN-netwerkkonstruksie moet netwerkelementbeplanning en IP-adrestoekenning uitgevoer word. In die besonder moet die netwerkbestuursbediener soveel as moontlik van ander netwerke geïsoleer word tydens ontplooiing. Andersins sal daar later te veel maasverbindings in die netwerk wees, en die netwerkjitter sal normaal wees tydens onderhoud, en gewone netwerkelemente sal nie gekoppel word nie. Probleme soos die poortnetwerkelement sal verskyn, en die produksienetwerkadres en die adres van die DCN-netwerk sal hergebruik word, wat die produksienetwerk sal beïnvloed.
Plasingstyd: 19 Desember 2022