3 Konfigurationshantering
Under kanalkonfiguration krävs tjänstkonfiguration, konfiguration av logiska länkar för det optiska lagret och konfiguration av länkens virtuella topologikarta. Om en enda kanal kan konfigureras med en skyddsväg, kommer kanalkonfigurationen att vara mer komplicerad, och den efterföljande konfigurationshanteringen kommer också att bli mer komplicerad. En dedikerad tjänstetabell krävs bara för att hantera kanalriktningen, och affärsriktningar måste särskiljas i tabellen med hjälp av heldragna och streckade linjer. När korrespondensen mellan OTN-kanaler och IP-länkar hanteras, särskilt när det gäller OTN-skydd, måste en IP-länk motsvara flera OTN-kanaler. Vid denna tidpunkt ökar hanteringsmängden och hanteringen blir komplicerad, vilket också ökar hanteringen av Excel-tabeller. Krav för att fullständigt hantera alla element i en verksamhet, upp till 15. När en ingenjör vill hantera en viss länk måste hen ta reda på Excel-formuläret och sedan gå till tillverkarens NMS för att hitta motsvarande och sedan utföra driftshantering. Detta kräver synkronisering av information på båda sidor. Eftersom NMS-plattformen för OTN och den Excel som skapats av ingenjören är två konstgjorda data, är det lätt att informationen blir osynkroniserad. Alla misstag kommer att leda till att affärsinformationen inte stämmer överens med den faktiska relationen. På motsvarande sätt kan det påverka verksamheten vid ändringar och justeringar. Därför samlas tillverkarens utrustningsdata in till en hanteringsplattform via det norrgående gränssnittet, och sedan matchas informationen från IP-länken på denna plattform, så att informationen automatiskt kan justeras enligt tjänsteändringar i det befintliga nätverket, och centraliserad hantering av informationen säkerställs. En enda källa för noggrannhet säkerställer noggrannheten i konfigurationshanteringsinformationen.
När du konfigurerar OTN-tjänsteleverans, förbered informationsbeskrivningen för varje gränssnitt och samla sedan in OTN-information via det norrgående gränssnittet som tillhandahålls av OTN NMS, och para ihop den relevanta beskrivningen med portinformationen som samlas in av IP-enheten via det norrgående gränssnittet. Den plattformsbaserade hanteringen av OTN-kanaler och IP-länkar eliminerar behovet av manuell informationsuppdatering.
För användning av DCI-överföringsnätet, försök att undvika användning av elektrisk korskopplingstjänstkonfiguration. Denna metod är extremt komplex i hanteringslogik och gäller inte DCI-nätverksmodellen. Den kan undvikas redan från början av DCI-designen.
4 Larmhantering
På grund av OTN:s komplexa hanteringskostnader, signalövervakning under långdistansöverföring och multiplexering och kapsling av olika servicepartiklar kan ett fel rapportera dussintals eller hundratals larmmeddelanden. Även om tillverkaren har klassificerat larm i fyra nivåer, och varje larm har ett annat namn, är det fortfarande extremt komplicerat ur en ingenjörs perspektiv för drift och underhåll, och det kräver erfaren personal för att fastställa orsaken till felet från första början. Felsändningsfunktionen i traditionell OTN-utrustning använder huvudsakligen SMS-modem eller e-postpush, men de två funktionerna är speciella för integration med den befintliga nätverkslarmhanteringsplattformen i internetföretagets grundläggande system, och kostnaden för separat utveckling är hög, så mer behöver göras. Standardgränssnittet för norrgående överföring samlar in larminformation, utökar funktionerna samtidigt som företagets befintliga relevanta plattformar bibehålls och skickar sedan larmet till drift- och underhållsingenjören.
Därför är det för drift- och underhållspersonalen nödvändigt att låta plattformen automatiskt sammanföra larminformationen som genereras av OTN-felet och sedan ta emot informationen. Ställ därför först in larmklassificeringen på OTN NMS och utför sedan sändnings- och screeningsarbetet på den sista larminformationshanteringsplattformen. Den allmänna OTN-larmmetoden är att NMS kommer att ställa in och skicka alla första och andra typer av larm till larminformationshanteringsplattformen, och sedan kommer plattformen att analysera larminformationen för ett enskilt serviceavbrott. Huvudinformationen om larm om avbrott i optiska vägen och (om någon) information om skyddsomkoppling skickas till drift- och underhållsteknikern. Ovanstående tre informationer kan förmodligen användas för feldiagnos och bearbetning. När du konfigurerar mottagning kan du ställa in telefonaviseringsinställningar för större larm, såsom fel i sammansatta signaler som endast uppstår när optiska fibrer är trasiga, såsom följande:
Larm kinesisk beskrivning
Larm Engelsk beskrivning Larmtyp Allvarlighetsgrad och begränsning
OMS-lager nyttolastsignalförlust OMS_LOS_P Kommunikationslarm kritiskt (FM)
Kombinerad signalförlust för ingång/utgång MUT_LOS Kommunikationslarm Nödläge (FM)
OTS nyttolastförlust av
Signal OTS_LOS_P Kommunikationslarm Kritiskt (FM)
OTS-indikering för nyttolastförlust OTS_PMI Kommunikationslarm Brådskande (FM)
NMS:s norrgående gränssnitt, såsom XML-gränssnittet som för närvarande stöds av Huawei och ZTE Alang, används också ofta för att skicka larminformation.
5 Prestationsstyrning
OTN-systemets stabilitet är starkt beroende av prestandadata för olika aspekter av systemet, såsom den optiska effekthanteringen för stamfibern, den optiska effekthanteringen för varje kanal i den multiplexerade signalen och systemets OSNR-marginalhantering. Detta innehåll bör läggas till i övervakningsprojektet för företagets nätverkssystem, för att när som helst känna till systemets prestanda och optimera prestandan i tid för att säkerställa nätverkets stabilitet. Dessutom kan långsiktig övervakning av fiberprestanda och kvalitet också användas för att upptäcka förändringar i fiberrutningen, vilket förhindrar att vissa fiberleverantörer ändrar fiberrutningen utan meddelande, vilket resulterar i blinda fläckar i drift och underhåll, och uppkomsten av fiberrutningsrisker. Naturligtvis kräver detta en stor mängd data för modellträning, så att upptäckten av routningsändringar kan bli mer exakt.
6. DCN-hantering
DCN hänvisar här till OTN-utrustningens kommunikationsnätverk, vilket ansvarar för nätverksstrukturen för hanteringen av varje nätverkselement i OTN. OTN-nätverket kommer också att påverka DCN-nätverkets skala och komplexitet. Generellt finns det två metoder för DCN-nätverk:
1. Bekräfta de aktiva och standby-gateway-NE:erna i hela OTN-nätverket. Andra icke-gateway-NE:er är vanliga NE:er. Hanteringssignalerna från alla vanliga NE:er når de aktiva och standby-gateway-NE:erna via OSC-kanalen över OTS-lagret i OTN:et och ansluter sedan till IP-nätverket där NMS:et finns. Denna metod kan minska utplaceringen av nätverkselement på IP-nätverket där NMS:et finns och använda själva OTN:et för att lösa problemet med nätverkshantering. Men om stamfibern avbryts kommer motsvarande fjärrnätverkselement också att påverkas och bli ur hantering.
2. Alla nätverkselement i OTN-nätverket är konfigurerade som gateway-nätverkselement, och varje gateway-nätverkselement kommunicerar oberoende med IP-nätverket där NMS finns, utan att gå igenom OSC-kanalen. Detta säkerställer att nätverkselementens hanteringskommunikation inte påverkas av avbrott i den huvudsakliga optiska fibern, och att nätverkselementen fortfarande kan hanteras på distans, eftersom alla är anslutna till IP-nätverket, och drifts- och underhållskostnaderna för traditionella IP-nätverksarbetare kommer också att minskas.
I början av DCN-nätverkskonstruktionen bör planering av nätverkselement och IP-adressallokering utföras. I synnerhet bör nätverkshanteringsservern isoleras från andra nätverk så mycket som möjligt vid driftsättning. Annars kommer det att finnas för många mesh-länkar i nätverket senare, och nätverksjittern kommer att vara normal under underhåll, och vanliga nätverkselement kommer inte att vara anslutna. Problem som gateway-nätverkselementet kommer att uppstå, och produktionsnätverksadressen och DCN-nätverkets adress kommer att återanvändas, vilket kommer att påverka produktionsnätverket.
Publiceringstid: 19 december 2022