3 Configuratiebeheer
Tijdens de kanaalconfiguratie zijn serviceconfiguratie, configuratie van de logische link op de optische laag en configuratie van de virtuele topologiekaart van de link vereist. Als een enkel kanaal kan worden geconfigureerd met een beveiligingspad, wordt de kanaalconfiguratie op dat moment complexer, en daarmee ook het daaropvolgende configuratiebeheer. Een speciale servicetabel is nodig om de kanaalrichting te beheren, en de bedrijfsrichtingen moeten in de tabel worden onderscheiden met behulp van doorgetrokken en gestippelde lijnen. Bij het beheren van de correspondentie tussen OTN-kanalen en IP-links, met name in het geval van OTN-beveiliging, moet één IP-link corresponderen met meerdere OTN-kanalen. Dit verhoogt de beheersomvang en de complexiteit van het beheer, evenals het aantal Excel-tabellen dat nodig is om alle elementen van een bedrijfsproces volledig te beheren. Dit kan oplopen tot 15. Wanneer een engineer een bepaalde link wil beheren, moet hij het bijbehorende Excel-bestand opzoeken, vervolgens naar het NMS van de fabrikant gaan om de bijbehorende gegevens te vinden en vervolgens het beheer uit te voeren. Dit vereist synchronisatie van informatie aan beide zijden. Omdat het NMS-platform van OTN en de door de engineer gemaakte Excel-bestanden handmatig zijn gegenereerd, is de kans groot dat de informatie niet synchroon loopt. Elke fout kan leiden tot inconsistenties in de bedrijfsgegevens. Dit kan vervolgens gevolgen hebben voor de bedrijfsvoering bij wijzigingen en aanpassingen. Daarom worden de apparatuurgegevens van de fabrikant via de northbound-interface naar een beheerplatform verzameld. Vervolgens worden de IP-linkgegevens op dit platform gekoppeld, zodat de informatie automatisch kan worden aangepast aan de servicewijzigingen in het bestaande netwerk. Dit zorgt voor gecentraliseerd informatiebeheer en een betrouwbare bron van informatie over de nauwkeurigheid van de configuratie.
Bij het configureren van OTN-serviceprovisioning dient u de informatiebeschrijving van elke interface voor te bereiden en vervolgens de OTN-informatie te verzamelen via de northbound-interface die door het OTN NMS wordt aangeboden. Koppel de relevante beschrijving vervolgens aan de poortinformatie die door het IP-apparaat via de northbound-interface wordt verzameld. Het platformgebaseerde beheer van OTN-kanalen en IP-links elimineert de noodzaak voor handmatige informatie-updates.
Voor het gebruik van het DCI-transmissienetwerk is het raadzaam om de configuratie met elektrische kruisverbindingen te vermijden. Deze methode is extreem complex qua beheerlogica en is niet geschikt voor het DCI-netwerkmodel. Het is daarom het beste om dit vanaf het begin van het DCI-ontwerp te vermijden.
4 Alarmbeheer
Vanwege de complexe beheerkosten van OTN, de signaalbewaking tijdens transmissie over lange afstanden en de multiplexing en nesting van verschillende servicecomponenten, kan een storing tientallen of zelfs honderden alarmmeldingen genereren. Hoewel de fabrikant alarmen in vier niveaus heeft ingedeeld, met elk een eigen naam, blijft dit vanuit het oogpunt van een technicus voor operationeel beheer en onderhoud uiterst complex. Het vereist bovendien ervaren personeel om de oorzaak van de storing te achterhalen. De foutmeldingsfunctie van traditionele OTN-apparatuur maakt voornamelijk gebruik van sms-modems of e-mailberichten. Deze functies vereisen echter integratie met het bestaande alarmbeheerplatform van de internetprovider en de ontwikkeling ervan is kostbaar. Daarom is er meer nodig. De standaard northbound-interface verzamelt alarminformatie, breidt de functionaliteit uit met behoud van de bestaande relevante platforms van het bedrijf en stuurt de alarmmelding vervolgens door naar de technicus voor operationeel beheer en onderhoud.
Daarom is het voor het operationele en onderhoudspersoneel noodzakelijk dat het platform de alarminformatie die door de OTN-storing wordt gegenereerd, automatisch verzamelt en vervolgens ontvangt. Stel daarom eerst de alarmclassificatie in op het OTN NMS en voer vervolgens de verzend- en filterwerkzaamheden uit op het laatste alarminformatiebeheerplatform. De algemene OTN-alarmmethode is dat het NMS alle alarmen van de eerste en tweede categorie instelt en naar het alarminformatiebeheerplatform stuurt. Vervolgens analyseert het platform de alarminformatie van een enkele serviceonderbreking. De belangrijkste alarminformatie over optische padonderbrekingen en (indien aanwezig) alarminformatie over beveiligingsschakelingen worden naar de operationele en onderhoudstechnicus gestuurd. Deze drie soorten informatie kunnen mogelijk worden gebruikt voor foutdiagnose en -afhandeling. Bij het instellen van de ontvangst kunnen telefonische meldingen worden ingesteld voor belangrijke alarmen, zoals samengestelde signaalstoringen die alleen optreden wanneer optische vezels zijn gebroken, zoals hieronder weergegeven:
Alarm Chinese beschrijving
Alarmbeschrijving (Engels) Alarmtype Ernst en beperkingen
OMS-laag signaalverlies van payload OMS_LOS_P Communicatiealarm Kritiek (FM)
Ingang/Uitgang Gecombineerd Signaalverlies MUT_LOS Communicatie Alarm Noodgeval (FM)
OTS-payloadverlies van
Signaal OTS_LOS_P Communicatiealarm Kritiek (FM)
Indicatie van verlies van OTS-payload OTS_PMI Communicatiealarm Urgent (FM)
De noordelijke interface van het NMS, zoals de XML-interface die momenteel door Huawei en ZTE Alang wordt ondersteund, wordt ook vaak gebruikt om alarminformatie te verzenden.
5. Prestatiebeheer
De stabiliteit van het OTN-systeem is sterk afhankelijk van de prestatiegegevens van verschillende aspecten van het systeem, zoals het optisch vermogensbeheer van de hoofdvezel, het optisch vermogensbeheer van elk kanaal in het gemultiplexte signaal en het beheer van de OSNR-marge van het systeem. Deze aspecten moeten worden opgenomen in het monitoringproject van het netwerksysteem van het bedrijf, zodat de systeemprestaties te allen tijde bekend zijn en tijdig kunnen worden geoptimaliseerd om de stabiliteit van het netwerk te waarborgen. Daarnaast kan langdurige monitoring van de prestaties en kwaliteit van de glasvezel ook worden gebruikt om wijzigingen in de glasvezelroutering te detecteren. Dit voorkomt dat glasvezelleveranciers de routering zonder kennisgeving wijzigen, wat kan leiden tot blinde vlekken in de bedrijfsvoering en het onderhoud, en tot risico's met betrekking tot de glasvezelroutering. Dit vereist uiteraard een grote hoeveelheid data voor modeltraining, zodat routeringswijzigingen nauwkeuriger kunnen worden gedetecteerd.
6. DCN-beheer
De DCN verwijst hier naar het beheercommunicatienetwerk van de OTN-apparatuur, dat verantwoordelijk is voor de netwerkstructuur en het beheer van elk netwerkelement van de OTN. Het OTN-netwerk heeft ook invloed op de schaal en complexiteit van het DCN-netwerk. Over het algemeen zijn er twee methoden voor DCN-netwerken:
1. Bevestig de actieve en standby gateway-NE's in het gehele OTN-netwerk. Alle andere niet-gateway-NE's zijn gewone NE's. De beheersignalen van alle gewone NE's bereiken de actieve en standby gateway-NE's via het OSC-kanaal over de OTS-laag in het OTN-netwerk en maken vervolgens verbinding met het IP-netwerk waar het NMS zich bevindt. Deze methode kan de implementatie van netwerkelementen op het IP-netwerk waar het NMS zich bevindt verminderen en het OTN-netwerk zelf gebruiken om het netwerkbeheerprobleem op te lossen. Als de trunk-glasvezelverbinding echter wordt onderbroken, worden de corresponderende externe netwerkelementen ook getroffen en vallen ze buiten het beheer.
2. Alle netwerkelementen van het OTN-netwerk zijn geconfigureerd als gateway-netwerkelementen. Elk gateway-netwerkelement communiceert onafhankelijk met het IP-netwerk waar het NMS zich bevindt, zonder gebruik te maken van het OSC-kanaal. Dit zorgt ervoor dat de beheercommunicatie van de netwerkelementen niet wordt beïnvloed door een onderbreking van de hoofdglasvezelverbinding. De netwerkelementen kunnen nog steeds op afstand worden beheerd, aangezien ze allemaal met het IP-netwerk zijn verbonden. Bovendien worden de operationele en onderhoudskosten voor traditionele IP-netwerkmedewerkers verlaagd.
Aan het begin van de DCN-netwerkconstructie moeten de netwerkelementen worden gepland en IP-adressen worden toegewezen. In het bijzonder moet de netwerkbeheerserver tijdens de implementatie zoveel mogelijk worden geïsoleerd van andere netwerken. Anders ontstaan er later te veel mesh-verbindingen in het netwerk, wat leidt tot netwerkjitter tijdens onderhoud en problemen met de verbinding tussen gewone netwerkelementen. Dit kan bijvoorbeeld leiden tot hergebruik van IP-adressen van het productienetwerk en het DCN-netwerk, wat de werking van het productienetwerk negatief beïnvloedt.
Geplaatst op: 19 december 2022