SE502999C2 - Telekommunikationssystem - Google Patents

Description

502 å99 =f Teknikens ståndpunkt.

Dagens telekommunikationsnät är stora och antalet resurser i näten ökar. Näten tillhandahåller ett stort antal olika tjänster och nätutrustningarna kommer ofta från olika leveran- törer. Nätoperatörerna använder ett flertal driftstödsystem för styrning av sina nät. Varje leverantörs utrustning har sitt eget driftstödsystem, och de olika tjänsterna i nätet styrs på olika sätt, vilket medför stora kostnader för drift och under- håll.

Ett sätt att reducera kostnaderna för nätoperatörerna har varit att utveckla en internationell standard avseende hur telekommunikationsnäten skall kunna hanteras på ett likformigt och effektivt sätt från ett nät av driftstödsystem. För detta ändamål har en standard benämnd TMN (Telecommunications Manage- ment Network) för telekommunikationshanteringsnät föreslagits.

Storleken hos ett TMN-nät kan variera från en enkel förbindelse mellan ett driftstödsystem och ett nätelement till ett helt nät av driftstödsystem som styr ett stort telekommunikationsnät.

TMN-standarden har utvecklats av en organisation benämnd ITU-TS (International Telecommunication Union for Telecommunication Standardization) och beskrivs i dennas rekommendation M.3010.

ITU-TS rekommendationerna i sin tur bygger på internationella standardrekommendationer föreslagna av en internationell organisation benämnd ISO (International Standardization Organi- zation).

Arkitekturen hos TMN tillåter nätelement att vara dis- åtribuerade. Hanteringstjänsten "Switching Management" i ITU-TS definierar exempelvis ett väljarnätelement på följande sätt: "NE kan bestå av en eller flera delar. Delarna kan vara place- rade på olika ställen. En del kan tillhandahålla ett Q3-gräns- snitt, som är gemensamt för alla hanteringsentiteter i en växel".

TMN-rekommendationerna säger emellertid inte mycket mera beträffande distribuerade nätelement. Det finns i själva verket ett flertal hanteringsinformationsmodellaspekter att ta hänsyn till, såsom kommer att framgå fortsättningsvis.

Nätelement i interväxelnätet, såsom transitnoder, signal- gï- 302 999 3 transferpunkter, centrala tjänstenoder (t.ex. GSM:s tjänsteno- der), är typiskt ej distribuerade. Detsamma gäller för de flesta nätelement i transmissionsnätet. För lokala väljar- systemtillämpningar å andra sidan kan det ofta vara lämpligt att vara implementerade som distribuerade nätelement.

US 5,204,955 visar ett nät innefattande ett integrerat hanteringssystem för nätet i dess helhet, liksom hanteringssys- tem för individuella delar av nätet.

US 5,031,211 beskriver ett kommunikationssystem innefattan- de delnät, varvid till vart och ett av dessa delnät hör ett hanteringssystem.

Redogörelse för uppfinningen.

Ett syfte med uppfinningen är att ange en hanteringsin- formationsmodell, som minskar kostnaderna för drift och under- håll för det interna nätet i ett nätelement, som ingår i ett telekommunikationssystem av inledningsvis angivet slag.

Detta syfte har uppnåtts genom att telekommunikationssyste- met, liksom inledningsvis definierade nätelement samt sätt, enligt uppfinningen erhållit de i bifogade patentkrav 1, 2 resp. 3 angivna kännetecknen.

Betydelsefulla utföringsformer har därvid erhållit de i de underordnade patentkraven angivna kännetecknen.

Figurbeskrivning.

Uppfinningen skall nu beskrivas närmare med hänvisning till utföringsformer visade på bifogade ritningar, på vilka fig. 1-13 är avsedda att allmänt åskådliggöra en teknisk standard, som kan sägas bilda en av grundvalarna för, och belysa senare beskrivna utföringsformer av uppfinningen, varvid fig. 1 visar exempel på ett telekommunikationsnät enligt TMNf fig. 2 schematiskt åskådliggör uppdelningen av ett i fig. 1 ingående nätelement i hanteringsskikt och resursskikt, fig. 3 schematiskt åskådliggör tre standardtyper av resur- ser av det slag, som i ett i fig. 1 ingående nätelement, fig. 4 schematiskt åskådliggör ett exempel på hur ett 502 §99 Q 4 driftstödsystem övervakar och styr en resurs via ett hante- ringsobjekt, som representerar resursen, fig. 5-7 schematiskt åskådliggör olika exempel på hur hanteringsobjekt kan representera resurser och andra objekt, fig. 8 visar ett exempel på hårdvara ingående i ett enkelt nätelement, som kan ingå i telekommunikationsnätet enligt fig. 1, fig. 9 visar hanteringsskiktet hos nätelementet enligt fig. 8, fig. 10 visar ett hanteringsinformationsträd uppbyggt av hanteringsobjekt ingående i hanteringsskiktet i fig. 9, fig. 11 är en vy som åskådliggör kommunikation och in- teraktion mellan ett driftstödsystem och hanteringsobjekt ingående i ett nätelement, fig. 12 visar ett första exempel på ett telekommunika- tionssystem innehållande distribuerade nätelement, fig. 13 visar ett andra exempel på ett telekommunikations- system innehållande distribuerade nätelement, fig. 14 visar ett exempel på två olika scenarier för hantering av ett distribuerat nätelement, fig. 15 visar ett exempel på fysisk integrering av trans- portnätfunktioner i ett distribuerat nätelement, fig. 16 visar ett exempel på den fysiska uppbyggnaden av ett distribuerat nätelement, fig. 17 visar ett exempel på en "svart låda"-vy av nätele- mentet i fig. 16, fig. 18 visar en stiliserad "vit låda"-vy av det i fig. 16 visade nätelementet, fig. 19 visar en topologisk vy enligt en nätstandard av ett telekommunikationsnät, fig. 20 visar ett hanteringsinformationsträd för nätet enligt fig. 19, fig. 21 visar en fysisk distributionsvy av ett nätelement ingående i telekommunikationsnätet enligt fig. 19, fig. 22 visar ett hanteringsinformationsträd för nätelemen- tet enligt fig. 21, fig. 23 är en framställning av entitetsrelationer i ett u' f, foz 999 I . 04 exempel på en hanteringsinformationsmodell enligt uppfinningen, fig. 24 och 25 visar namngivnings- resp. härledningshierar- ki för hanteringsinformationsmodellen enligt fig. 23, fig. 26 visar ett exempel på feldetektering och alarmkoor- dinering i händelse av länkbortfall mellan två noder ingående i nätelementet enligt fig. 16, fig. 27 visar en distribuerad atm vc cross connect med ett internt atm vp transportnät som referenskonfiguration för att beskriva två enligt uppfinningen använda hanteringsobjekt, fig. 28 visar en förenklad 'protokollvy' av ett utsnitt av referenskonfigurationen enligt fig. 27, fig. 29 visar en referenskonfiguration av ett distribuerat nätelement, som utnyttjas för att med hänvisning till fig. 28- 36 beskriva exempel på användning av hanteringsinformationsmo- dellen enligt fig. 23-26, varvid fig. 30 visar ett hanteringsträd enligt ETSI-standard för en ATM vp förbindelse uppställd mellan en användarkanal och en nätkanal, fig. 31 visar ett hanteringsträd enligt ETSI-standard för en ATM vp förbindelse uppställd mellan två användarkanaler, fig. 32 visar ett hanteringsträd för det interna nätet hos nätelementet enligt fig. 29 med fokus på adressering av interna kanaler, fig. 33 visar ett utsnitt av hanteringsträdet i fig. 23, som visar fast multiplexering av en intern kanal till en annan, samt fast länkförbindelse mellan två till varsin nod hörande interna kanaler, fig. 34 visar ett utsnitt av hanteringsträdet i fig. 23, som visar länkförbindelser mellan tre noder, fig. 35 visar ett utsnitt av hanteringsträdet i fig. 23, som visar en hanteringsobjektmodell av en etablerad ATM vp korskoppling mellan två interna kanaler, fig. 36 visar en konfiguration av synliga kanaler/kanal- grupper på delnätnivå hos det distribuerade nätelementet, för att bilda underlag för en beskrivning med hänvisning till fig. 37 och 38 av etablering av korskopplingsförbindelser över flera noder, varvid 502 “i 6 fig. 37 och 38 visar varsin hanteringsobjektmodell av vardera ett exempel på sådana korskopplingsförbindelser, fig. 39 visar ett nätelement i form av en distribuerad B- ISDN väljare med alternativa interna länkar, fig. 40 visar en standardiserad, tjänsterelaterad "svart låda"-vy av dirigeringsinformation för nätelementet enligt fig. 39, fig. 41 visar en förenklad hanteringsobjektmodell av dirigeringsinformationen enligt fig. 40, fig. 42 visar utsnitt av intern dirigeringsinformation för nätelementet enligt fig. 39, vilken är strukturerad per intern nod, fig. 43 visar utsnitt av ett hanteringsojektträd för intern dirigering av ett dirigeringsfall, fig. 44 visar en fysisk utrustningsvy av en distribuerad lokalväxel, fig. 45 visar ett hanteringsinformationsträd för lokal- växeln enligt fig. 44.

Föredragna utföringsformer.

Som en första introduktion till den följande beskrivningen av utföringsexempel av uppfinningen, och eftersom dessa utför- ingsexempel av praktiska skäl huvudsakligen baserar sig på en tillämpning av uppfinningen i TMN-miljö, kommer nu till att börja med ett antal benämningar och begrepp i detta sammanhang att diskuteras närmare med hänvisning till fig. 1-11. Såsom dock kommer att framgå i fortsättningen är användning av uppfinningen ej begränsad till denna miljö, utan kan sägas omfatta all miljö som baserar sig på den internationella ISO- standarden.

Figur 1 visar schematiskt en hanteringsvy 102 enligt TMN för ett telekommunikationsnät 104. I det senare antyds hur två abonnenter 106 och 108 är uppkopplade mot varandra via nätele- ment i form av en första lokalstation 110, till vilken abonnen- ten 106 hör, ett första transmissionssystem 112, en förmed- lingsstation 114, ett andra transmissionssystem 116, och en andra lokalstation 118, till vilken abonnenten 108 hör. Hante- > šnz 999 7 ringsvyn 102 innehåller förutom nätelementen 110-118 två driftstödsystem 120 och 122, som via ett datakommunikationsnät 124 och ett Q3-gränssnitt 126, kommunicerar med elementen 110- 118. Ett lokalt driftstödsystem 128 kommunicerar direkt med lokalstationen 118 via gränssnittet 126. Q3 är ett standar- diserat fysiskt gränssnitt mellan två TMN-byggstenar, såsom nätelement och driftstödsystem. Det består av två delar, nämligen ett hanteringsprotokoll och en i gränssnittet synlig hanteringsinformationsmodell.

Gränssnittet 126, över vilket driftstödsystemen, såsom 120, 122 och 128, i TMN betraktar telekommunikationsnätet 104, är ett standardiserat maskin-maskingränssnitt, där alla typer av nätutrustning kan övervakas och styras på samma sätt. Q3- gränssnittet definierar både en objektorienterad informations- modell av nätelementen 110-118, och kommunikationsprotokollet mellan driftstödsystemen 120, 122 och nätelementen 110-118.

Med hänvisning till fig. 2 är ett schematiskt visat nätele- ment 202 uppdelat i ett hanteringsskikt 204 och ett resursskikt 206. Från det här med 208 betecknade driftstödsystemet är endast hanteringsskiktet 204 synligt. Hanteringsskiktet 204 består av en samling hanteringsobjekt 210, vilka kan övervakas och styras från driftstödsystemet 208 via Q3-gränssnittet.

Hanteringsobjekten 210 väljs med avseende på hur nätelementet 202 kommer att te sig för en underhållstekniker. Det finns standardiserade hanteringsobjekt för de flesta tilllämpningar.

En underhållstekniker kommer därför att veta hur nätelement från olika leverantörer skall styras.

Resursskiktet 206 är den verkliga implementationen av nätelementet 202. Resurser väljs för att uppnå de bästa egen- skaperna hos systemet. Exekveringstid och minnesåtgång utgör exempel på egenskaper som skall beaktas vid implementering av resursskiktet. Med hänvisning till fig. 3 talar man enligt standard om tre typer av resurser, nämligen fysiska resurser 302, logiska resurser 304, samt funktionella resurser 306.

Fysiska resurser är t.ex. maskinvaruutrustning och program- varuelement.

Logiska resurser utgör abstrakta systemdelar, vilka här- soz šjiiss a 8 leds, antytt med pil 308, från de fysiska resurserna för att tillhandahålla tjänster. Exempel på logiska resurser är: - Subscriber. Denna innehåller data avseende en viss abonnent.

- Line termination point. Realiseras av en linjegräns- snittskrets tillsammans med tillhörande programvara.

- Route. Realiseras som en datatabell och funktioner för hantering av tabellen.

- Trunk. En talkanal i en PCM-länk.

- Processor. Realiseras av processormaskinvara tillsammans med operativsystemprogramvara.

Funktionella resurser bär de logiska resurserna, antytt med pil 310, och är systemdelar som tillhandahåller en funktion, t.ex. en linjeprovningsfunktion, en talanalystabell, samt en resurshanterare för en viss typ av resurs.

Resurserna i ett nätelement används av trafikhanteringen.

En trunk används exempelvis för att bära ett telefonanrop i en riktning. Såsom redan nämnts är endast nätelementets hante- ringsskikt synligt för driftstödsystemen. Om en trunk skall kunna hanteras från ett driftstödsystem måste den representeras av ett hanteringsobjekt.

Som exempel visar fig. 4 hur en trunkresurs 402 uppfångas, pil 404, för ett anrop internt i ett nätelement 406. Den visar även hur resursen 402 kan övervakas och styras, pil 408, från ett driftstödsystem 410 genom ett hanteringsobjekt 412, som irepresenterar, pil 414, trunkresursen 402. Hanteringsobjektet 412 verkar då som ett "gränssnitt" mot driftstödsystemet. Ett hanteringsobjekt kan inte lagra data, utan alla data tillhör resurserna. Det föreligger inte nödvändigtvis 1-till-1 mappning mellan hanteringsobjekt och resurser. Flera hanteringsobjekt kan implementeras som en resurs, se fig. 5, där två hanterings- objekt 502 och 504 representerar och ger varsin hanteringsvy av en resurs 506. Ett skäl till att implementera de två hante- ringsobjekten som en resurs är att uppnå bättre egenskaper hos tillämpningen.

Mer komplexa hanteringsobjekt kan implementeras som en kombination av resurser, såsom i fig. 6, som visar ett hante- ë šoz 999 9 ringsobjekt 602, vilket representerar en kombination av tre resurser 604, 606 och 608.

Ett hanteringsobjekt kan även representera andra hante- ringsobjekt för att öka abstraktionsnivån, jfr. fig. 7, där ett hanteringsobjekt 702 representerar, pilar 704 och 706, två andra objekt 708 resp. 710. Objektet 708 representerar därvid en resurs 712, och objektet 710 representerar två resurser 714 och 716. Driftstödfunktioner kan då implementeras i det högsta hanteringsobjektet 702, i stället för i ett driftstödsystem.

I fig. 8 visas maskinvaran hos ett enkelt nätelement 802, som här kan antagas motsvara t.ex. lokalstationen 110 i fig. 1.

Nätelementet 802 innehåller en väljare 804, till vilken två processorer 806 och 808 visas vara anslutna. Till väljaren 804 är vidare en abonnent 810, som kan tänkas vara densamma som abonnenten 106 i fig. 1, ansluten via en abonnentlinjekrets 812. Nätelementet 802 har en anslutning till resten av nätet genom en stationsterminal 814, som kommunicerar över en PCM- länk 816. Detta enkla nätelement kan övervakas och styras från ett till processorn 806 anslutet driftstödsystem 818, motsva- rande driftstödsystemet 120 i fig. 1.

I fig. 9 visas endast hanteringsskiktet av nätelementet i fig. 8 och betecknas med 902, varvid driftstödsystemet erhållit beteckningen 904. Hanteringsskiktet 902 består närmare bestämt av hanteringsobjekt, vilka anges med respektive klassnamn och instans i fig. 9.

I hanteringsskiktet 902 representeras abonnenten 810 i fig. 8 av en instans 7273000 av ett objekt 906 av klassen Subscri- ber. Objektet 906 innehåller abonnentdata och är kopplat till en instans 11 av ett objekt 908 av klassen Subscriber-line, som innehåller linjekopplingsdata. Detta objekt representerar närmare bestämt linjen mellan abonnenten och linjekretsen 812 i fig. 8. Talkanalerna i PCM-länken 816 i fig. 8 representeras av varsin instans av ett objekt 910 av klassen Trunk. I nätelemen- tet visas två trunkar kopplade till utgående riktning, medan tre trunkar är kopplade till inkommande riktning. Detta repre- senteras av en instans "outgoing" av ett objekt 912 av klassen Route, respektive en instans "incoming" av ett objekt 914 av 502 š99 c samma klass. Resten av trunkarna i PCM-länken används ej av nätelementet 802.

Data hos ett hanteringsobjekt specificeras som attribut.

Ett attribut hos ett hanteringsobjekt kan motsvara ett var- aktigt lagrat attribut hos ett resursobjekt, men det kan även kalkyleras i en algoritm, som hämtar attribut från flera resursobjekt. Resursdata kan även lagras i filsystemet eller i maskinvaruregister. Ett hanteringsobjekt för en trunk kan exempelvis ha följande attribut: trunkld, state, och myRoute. I detta fall motsvarar alla tre attributen attribut i samma resursobjekt.

Operationer som kan utföras på ett hanteringsobjekt är: "skapa" (create) och "ta bort" (delete) en instans av ett hanteringsobjekt,' "hämta" (get) och "ställ" (set) ett attributvärde, "åtgärd" (action) anmodar ett hanteringsobjekt att utföra en uppgift. Åtgärder används när operationen är mer komplex än bara att hämta eller ställa ett attributvärde för ett hanteringsobjekt. Åtgärder inbegriper objektet i dess helhet, men kan även indirekt inbegripa andra objekt.

Ett hanteringsobjekt sänder en "notifikation" (notifica- tion), och informerar driftstödsystemet att en händelse har inträffat i nätelementet. Ett alarmtillstånd utgör exempel på en notifikation. Notifikationer används även för andra ändamål, t.ex. laddning av data och trafikstatistik. När det tar lång tid att utföra en åtgärd, kan returvärdet vid mottagande av "åtgärd" informera om att åtgärden påbörjats. Därpå sänds resultatet som en notifikation.

Dessutom kan hanteringsobjekt ha associativa relationer till andra hanteringsobjekt. Trunkar kan exempelvis utgöra delar av en väg (route). Associativa relationer specificeras som attribut.

I det som exempel ovan med hänvisning till fig. 8 och 9 angivna nätelementet ingår flera trunkar. Alla har samma attribut, actions och notifikationer. I objektorienterade termer utgör de instanser av hanteringsobjektklassen Trunk. Éoz 999 ll Samlingen av alla skapade hanteringsobjektinstanser i ett nätelement benämns hanteringsinformationsbas MIB (Management Information Base). Hanteringsinformationsbasen är ett abstrakt begrepp och skall ej förväxlas med en fysisk databas, som används för att stadigvarande lagra data i ett system.

I vissa nätelement kan det finnas ett mycket stort antal hanteringsobjekt. För att kunna söka efter ett visst hante- ringsobjekt och navigera mellan alla skapade hanteringsob- jektinstanser i ett nätelement är det nödvändigt att ha en fastställd namngivningsstruktur. Standard rekommenderar den tidigare omnämnda trädstrukturen eller hanteringsinformations- trädet MIT, även benämnt namngivningsträd. Relationerna som formar MIT:et benämns namnbindningsrelationer. I fig. 10 visas MIT för det med hänvisning till fig. 8 och 9 ovan beskrivna exemplet, varvid det antas att nätelementet 802/902 bildar del av ett ISDN-nät.

Varje hanteringsobjekt erhåller ett instansnamn när det skapas. Alla hanteringsobjekt som är "barn" till samma hante- ringsobjekt måste ha olika instansnamn. Instansnamnet behöver ej vara unikt i hanteringssystemet, utan två hanteringsobjekt kan ha samma instansnamn under förutsättning att de har olika "föräldrar".

Varje hanteringsobjekt har även ett namn som används för att identifiera det unikt i hela hanteringssystemet, och benämns särskiljande namn (Distinguished Name DN). Det särskil- jande namnet utgår från MIT:ets rot och avslutas med hante- ringsobjektets instansnamn. Till utseendet påminner det mycket om t.ex. ett fullständigt vägnamn i UNIX. Som exempel kan det särskiljande namnet hos intansen Trunk5 av hanteringsobjektet Trunk skrivas: DN = {Route=incomingRoute/Trunk=Trunk5} Kommunikationen mellan driftstödsystem och nätelement definieras i Q3-gränssnittet. Standardföreskrifter rekommende- rar hur man skall nå och arbeta med hanteringsobjekt från ett driftstödsystem. Dessutom rekommenderar standard hur hante- ringsobjekt skall informera driftstödsystemet om händelser i nätelementet. 502 §99 12 En hanterare i driftstödsystemet manipulerar hanterings- objekten i nätelementet via en agent. Interaktionen mellan hanteraren och agenten visas närmare i fig. 11. Det med 1102 i fig. 11 betecknade driftstödsystemet är det hanterande systemet och det med 1104 betecknade nätelementet det hanterade syste- met. Hanteraren betecknas med 1106 och agenten med 1108.

Hanteraren 1106 initierar kontakt med agenten 1108 genom att upprätta en association till agenten. Denna association kan betraktas som en kommunikationslänk mellan de två systemen. När associationen har ställts upp kan hanteraren och agenten kommunicera med varandra. Hanteraren 1106 manipulerar de med 1110 betecknade hanteringsobjekten genom användning av definie- rade operationer (create, delete, set, get samt action) antydda genom pil 1112. Hanteringsobjekten 1110 genererar information, notifikationer, som kan vidareledas som händelserapporter, pil 1114, till driftstödsystemet. Operationerna och händelserap- porterna utgör delar av en gemensam hanteringsinformations- tjänst (Common Management Information Service CMIS).

För lokala väljarsystemtillämpningar kan det ofta vara lämpligt att vara implementerade som distribuerade nätelement.

Två exempel, som kommer att användas för att åskådliggöra detta, visas i fig. 12 och 13.

I fig. 12 visas ett driftstödnät 1202, som innefattar tre driftstödsystem 1204, 1206 och 1208. Driftstödsystemen 1204, 1206 och 1208 kommunicerar via ett datakommunikationsnät 1210 och Q-gränssnitt 1212, 1214 och 1216 med nätelement 1218, 1220 resp. 1222, vilka ingår i ett telekommunikationsnät 1224, som här kan antas vara t.ex. ett B-ISDN access- och lokalväxelnät.

Nätelementet 1220 är en distribuerad lokalväxel, som innefattar en central nod 1226, som är förbunden med två uppsättningar externa länkar 1228 och 1230, som kan leda till exempelvis en nationell växel resp. en internationell växel. I nätelementet 1220 ingår vidare avlägsna accessnoder 1232, 1234, 1236 och 1238, av vilka accessnoderna 1234, 1236 och 1238 har anslutningar från abonnentlinjer 1240, 1242 resp. 1244. Kommu- nikationen mellan noden 1226 och accessnoderna sker via interna länkar 1246, 1248, 1250 och 1252. fffsoz 999 13 Noden 1226 kommunicerar vidare via ett gränssnitt 1254 med en accessnod, som bildar nätelementet 1222, vilket styrs från lokalstationen 1220. Till accessnoden 1222 är abonnentlinjer 1256 anslutna.

Accessnoden 1234 kommunicerar via ett gränssnitt 1258 med tre accessnoder 1260, 1262 och 1264 i nätelementet 1218, till vilka abonnentlinjer 1260 och 1262 är anslutna. Noden 1264 kan exempelvis bilda anslutning till en företagsväxel. Nätelementet 1218 kan också vara distribuerat, och styrs likaledes från lokalstationen 1220.

Det ovan med hänvisning till fig. 12 beskrivna B-ISDN- lokalväxelnätet, utgör exempel på ett scenario där några accessnoder utgör del av ett distribuerat nätelement, medan andra exempelvis kan vara generella accessnodprodukter (GAP), som själva utgör nätelement.

Exemplet i fig. 13 visar ett liknande scenario för en lokal ATM korskopplingstillämpning i form av ett distribuerat nätele- ment 1302 ingående i ett ATM access- och transportnät 1304 (ATM - Asynchronous Transfer Mode). Med begreppet "korskoppling" avses här och fortsättningsvis detsamma som "cross connect", vilket enligt ATM-standard avser en förbindelse, som uppställs via en operatör. Med ATM-standard avses här och fortsättnings- vis den standardiserade hanteringsinformationsmodell för ett ATM-nät, vilken exempelvis beskrivs i ETS DE/NA5-2210-Version 03 Helsinki 25-29 April 94 “B-ISDN Management Architecture and Management Infomation Model for the ATM crossconnect".

I nätelementet 1302 ingår en central nod 1306, ansluten till två avlägsna accessnoder 1308 och 1310 via interna länkar 1312 och 1314. att driftstödnät 1316 innehåller driftstödsystem 1318, 1320 och 1322, vilka via ett datakommunikationsnät 1324 och ett Q- gränssnitt 1326 är anslutningsbara till nätelementet 1302.

Ett SDH-nät 1328, som bildar en anslutningsväg (eventuellt alternativ) mellan noderna 1306 och 1310, har anslutning till datakommunikationsnätet 1324 via ett Q-gränssnitt 1330. (SDH - Synchronous Digital Hierarchy).

Det finns flera skäl till att det i en lokal växeltillämp- 502 14 ning, såsom vid exemplen ovan, kan vara fördelaktigt att implementera den centrala lokala noden och vissa av dess accessnoder som ett enda distribuerat nätelement.

I en lokalväxel-väljardomän, som stödjer avancerade nät- accessfunktioner - såsom "distributed connection switching" med centraliserad koppelstyrning, "stand alone switching" i access- noder, icke-standard accessnoder, “multi-homing", mm. - kan styrgränssnitten, för signalering såväl som tjänsterelationer, mellan de olika avlägset belägna och centrala noderna vara ganska komplexa. Om varje nod i ett sådant distribuerat lokal- växelnät skall utgöras av ett separat nätelement, behöver dessa styrgränssnitt standardiseras. Om marknaden ej kan vänta på detta måste ägargränssnitt användas. Det är då naturligt att ha alla "icke-standard" noder hos lokalväxelnätet som ett enda "distribuerat" nätelement, som utifrån sett är anpassat till "standardiserade" näthanteringsgränssnitt och -procedurer.

Ett annat skäl till att implementera flera noder till- sammans som "ett enda" nätelement är att om man kan använda ägargränssnitt mellan centrala och avlägsna delar kan man ganska ofta uppnå väsentligen lägre totalkostnad för systemets interna datorsystem. Detta beror på att avlägsna "enkla" noder då kan dela på många dyra infrastrukturfunktioner och -resurser i styrsystemet, vilka kan placeras i den centrala noden i det distribuerade nätelementets domän. Sådana resurser är t.ex. allmänna datorsystemfunktioner och resurser för lagring och utmatning av genererade laddnings- och prestationsövervaknings- data, terminering av hela Q-gränssnittets stack, avancerade programvaru- och utrustningshanteringsfunktíoner, backup- och I/0-anordningar, etc.

För nätelement i allmänhet och för distribuerade nätelement i synnerhet skall nu här två olika hanteringsvyer introduceras.

Den första vyn kommer här att benämnas "svart låda"-vyn. Detta är den vy som används av majoriteten av standardiserade hante- ringstjänster, såsom trafikhantering, dirigerings- och siffer- analysadministrering, hantering av ATM transportnät etc. Dessa hanteringstjänster ser ett nätelement som en "svart låda", innehållande ett antal hanterade tjänster och ett antal in- š5ü2 999 gångar och utgångar, som skall hanteras.

Det väsentliga med "svart låda"-vyn är att den ej befattar sig med aspekter, som har med systemintern implementeringste- knologi att göra. Den berör exempelvis inte hanteringsinforma- tion som hänför sig till konfigurering av systeminterna dator- system, såsom vilket antal databehandlingsresurser det finns och hur olika programvaruenheter är allokerade/distribuerade.

Den andra hanteringssynpunkten kommer här att kallas "vit låda"-vyn. I denna vy hanteras internstruktur-, distributions- och teknologiaspekter hos nätelementet. Denna vy stödjer systemspecifika hanteringstjänster såsom programvaruuppgrade- ring, -konfigurering (distribution) och -användning, utrust- ningsreparationshantering, hantering av systeminterna operativ- systemdata, hantering av internt switchningsnät, etc.

Fig. 14 åskådliggör de två hanteringsvyerna. Den visar ett driftstödsystem 1402 med två "svart låda"-driftstödsystemfunk- tioner 1404 och 1406 för ISDN-näthantering respektive ATM- transportnäthantering. Den visar även en "vit låda"-driftstöd- systemfunktion 1408 för hantering, via datakommunikationsnätet 1410 och ett Q-gränssnitt 1412, av systeminterna kommunika- tionslänkar och logiska väljarfunktioner hos ett distribuerat lokalväxelnätelement 1414. Nätelementet 1414 visas, tillsammans med tre ytterligare nätelement 1416, 1418 och 1420, ingå i ett telekommunikationsnät 1422, i vilket de fyra nätelementen erbjuder ISDN-tjänster, som stöds av ISDN-driftstödsystem- funktionen 1404. Dessutom erbjuder nätelementen 1414, 1418 och 1420 ATM-transportnättjänster, som stöds av ATM-driftstöd- funktionen 1406. Nätelementen 1416 och 1418 kan t.ex. antas vara en nationell växel resp. en internationell växel, med vilka nätelementet 1414 kommunicerar. I figuren framställs nätelementet 1414 med både hanteringsskikt 1422 och resursskikt 1424.

Bilderna i nedre delen av driftstödsystemfunktionerna 1404, 1406 och 1408 är avsedda att symbolisera “svart låda"-, "svart låda"- resp. "vit låda"-vyerna. I nätelementets 1414 resurs- skikt 1424 återkommer den ifrågavarande "vit låda"-symbolen, vilken är avsedd att antyda maskinvarustruktur. 502 959 Det bör framhållas att relationen mellan hanteringsvyn av nätresurser och de fysiska nätelementen ej alltid är enkel.

Detta skall åskådliggöras med hänvisning till fig. 15, som visar separata add-drop multiplexorfunktioner, som är fysiskt integrerade i ett distribuerat nätelement. Det rör sig närmare bestämt om ett scenario med en distribuerad väljare 1502 i form av en B-ISDN lokalväxel, som innefattar, på samma tryckta kretskort 1504 och 1506 och/eller i samma kopplingsställ, både transportnätresurser 1508 resp. 1510, i form av add-drop multiplexorer, ingående i ett SDH-nät 1511, och switchningsre- surser 1512 resp. 1514 hos lokalväxeln 1502. Likaså använder implementationen av SDH-resurserna i växeln samma interna systemtjänster, såsom det systeminterna processorsystemet, som används av andra växelresurser.

Vid 1530 visas tillhörande driftstödsystem med "svart låda"-driftstödsystemfunktioner 1532 och 1534 för ISDN-näthan- tering resp. SDH-transportnäthantering. Driftstödsystemet 1530 kommunicerar med nätelementet 1502 via ett datakommunikations- nät 1536 och ett Q-gränssnitt 1538.

En sådan lokalväxel måste behandlas som ett enda fysiskt nätelement, eftersom "vit låda"-hanteringen av utrustning, programvara och dataresurser annars skulle bli mycket komplex, och även eftersom "svart låda"-näthanteringen av den switchade tillämpningen, dvs. ISDN trafikhanterings- och dirigeringsad- ministration, betraktar en lokalväxel som en enda nätfunk- tionsentitet.

Driftstödsystemfunktionen 1534 för standard "svart låda" SDH näthantering behandlar emellertid varje separat SDH add- drop multiplexor som en separat nätfunktionsentitet oberoende av om den är ett ensamt ADM-nätelement (ADM = Add-Drop Multi- plexor), såsom det vid 1540 visade, eller tillhandahålls av lokalväxeln, såsom multiplexorerna 1508 och 1510. I SDH-näthan- teringsvyn tillhandahålls alltså de hanterade entiteterna inte alla av separata nätelement. Driftstödfunktionen 1532 för standardiserad näthantering av den switchade tillämpningen kommer fortfarande att hantera nätelementet 1502 som "svart låda". ïsoz 999 17 Här skall nu vissa "vit låda" hanteringsinformationsaspek- ter, som hänför sig till intern distríbuering i ett nätelement, diskuteras närmare. Därvid skall som exempel det distribuerade lokalväxelnätelementet 1220 i fig. 12 användas och beskrivas mera i detalj med hänvisning till fig. 16. För att visa sam- bandet med nätelementet i fig. 12, överensstämmer hänvisnings- beteckningarna i fig. 16 med de som i fig. 12 används för motsvarande element med undantag av de två första siffrorna, som i fig. 16 är 16 för att framhålla figurtillhörigheten.

Det distribuerade lokalväxelnätelementet 1620 i fig. 16, sålunda motsvarande nätelementet 1220 i fig. 12, antas närmare bestämt tillhandahålla både ATM korskopplings- och B-ISDN swit- chade tjänster. Det består sålunda av fem interna noder på olika geografiska ställen, nämligen en central väljare/tjänste- nod 1626, två avlägsna väljare/koncentratornoder 1632 resp. 1634, och två avlägsna multiplexornoder 1636 resp. 1638. Mellan noden 1626 å ena sidan och noderna 1632 och 1634 å andra sidan finns det alternativa länkar 1646', 1646" resp. 1648', 1648", vilket ej visas i fig. 12.

Under installation, uppgradering, alarm, reparation av utrustningsresurser, t.ex. kretskort, kraftenheter etc., i ett distribuerat nätelement är det nödvändigt att den administrati- va personalen för systemet erhåller information om den fysiska placeringen av de individuella utrustningsresurserna. Hante- ringsinformationsmodellen måste på något sätt innehålla denna information.

TMN standardrekommendationer (ITU-TS M.3100) specificerar att varje utrustningsresurs bör representeras av ett hante- ringsobjekt av klassen "Equipment", eller en underklass av denna. Denna klass av hanteringsobjekt innehåller ett attribut “LocationName", vilket representerar den fysiska placeringen av utrustningsresursen. Det representerar ett "site", dvs. ett geografiskt läge, där utrustningsresurser såsom skåp, ställ- ningar och deras inpluggade tryckta kretskort är belägna.

Om exempelvis en av de avlägsna multiplexorerna i fig. 16 detekterar ett utrustningsfel kommer en alarmrapport av typen "Equipment alarm" att sändas från nätelementet till driftstöd- 502 #99 18 systemet. Av alarmrapporten skall operatören kunna läsa attri- butet "LocationName" och sända reparationspersonal till det angivna stället.

Under konfiguration av det distribuerade processornätet i nätelementet är det nödvändigt att hantera de interna pro- cessorkommunikationstjänsterna, dvs. dirigeringsinformation måste definieras vid varje processorstation (nod) och länkar måste konfigureras mellan dessa. Varje länk implementeras med en förbindelseorienterad pakettjänst, som kan "brygga" över ett internt paketnodnät. Om t.ex. de avlägsna väljarna i fig. 16 innehåller en intern paketväljare, som används för switchning av processorpaket, måste denna ha konfigurerats för varje paketanslutning.

Här kommer nuui korthet ett exempel att beskrivas, som avser hur koppeldirigerings- liksom interndirigeringsinforma- tion för den distribuerade ATM-väljaren i fig. 16 är konfigure- rad. Såsom beskrivits tidigare tillhandahåller den standardise- rade hanteringsinformationsmodellen av nätelementet en "svart låda"-vy, dvs. den interna distributionen visas ej.

Med hänvisning till fig. 17 innefattar denna "svart låda"- vy ett destinationsidentifierande fragment 1704, som identifie- rar två destinationer 1706 och 1708 för nationella resp. internationella koppel. Med "fragment" avses här och fortsätt- ningsvis ett antal hanteringsobjekt, som hör ihop funktionellt.

Motsvarande kretsvalfragment antyds vid 1710. Även ett stort antal lokala destinationer och accessportar, varav några antyds vid 1712, 1714 och 1716, identifieras för de terminerande kopplen till anslutna abonnenter. Motsvarande "kundadministra- tion" antyds vid 1718. Fig. 17 visar även ett driftstödsystem 1720, som via ett datakommunikationsnät 1722 och ett Q-gräns- snitt 1724 kommunicerar med nätelementet 1702, liksom med växlarna 1706 och 1708. Kretsvalfragmentet 1710 väljer en fri krets i kretsundergruppen, identifierat från destinationen och andra ingångar såsom QoS (Quality of Service) hos ATM vc bärar- tjänsten och erfordrad signalering.

Såsom beskrivits tidigare finns det även behov av att ett nätelement, såsom särskilt ett distribuerat nätelement, skall f5o2 999 19 kunna tillhandahålla en "vit låda"-vy för systemspecifika hanteringstjänster, där den interna distributionen visas. I exemplet enligt fig. 16 finns det alternativa interna länkar mellan de avlägsna väljarna 1632, 1634, 1636 och 1638 och den centrala väljar-/tjänstenoden 1626. Låt oss även anta att de interna förstavalslänkarna realiseras över en extern SDH- ringinfrastruktur som förbinder de tre noderna, och de interna andravalslänkarna realiseras över en extern PDH-infrastruktur.

För att hantera detta scenario måste nätelementet till- handahålla ett annat "vit låda"-fragment, förutom det tidigare angivna "vit låda" atm-interna näthanteringsfragmentet, för hantering av intern koppeldirigering och resursval.

För detta ändamål behövs den i fig. 18 indikerade hante- ringsobjektmodellen, vilken på sedvanligt sätt är uppdelad i dels ett hanteringsskikt 1802, som via ett Q-gränssnitt 1804 styrs av ett ej visat driftstödsystem, och dels ett resursskikt 1806. Resursskiktet 1806 återger som synes strukturen hos det ifrågavarande nätelementet 1620 från fig. 16.

Närmare bestämt behövs det ett eller flera systemspecifika hanteringsobjektfragment 18O81m, som representerar det interna nätet. De interna noderna och hur dessa är förbundna med interna länkar, liksom intern dirigering och resursval repre- senteras av denna hanteringsobjektmodell.

Andra exempel på systemspecifika hanteringstjänster är: - konfigurering av korskopplingsförbindelser över “intern- segment" såsom en eller flera interna noder i nätelementet.

Detta kan behövas för provningsändamål för interna noder och länkar. - felhantering av "internsegment", såsom feldetektering och alarmkoordinering vid internlänkfel. - prestandahantering av "internsegment“, såsom insamling av transmissionskvalitetsstatistik för interna länkar.

Stöd för tillämpningssystemen om de har behov av konstruk- tionshanteringstjänster för ett internt nät av det slag, som diskuterats ovan med hänvisning till fig. 16-18, kan enligt uppfinningen, såsom kommer att framgå närmare nedan, t.ex. tillhandahållas av ett bassystem. Det stöd som erbjuds är 502 .9399 interna resurser och funktioner, såsom fel- och prestandahante- ring, internt dirigerings- och resursval för det interna nätet (bärartjänst), liksom en motsvarande hanteringsobjektmodell, här benämnd IBSN (Internal Bearer Service Network fragment) i nätelement med flera noder.

Den av bassystemet tillhandahållna hanteringsobjektmodellen för det interna nätet kan då basera sig på följande: - de interna bärartjänstnoderna representeras av en system- specifik hanteringsobjektklass, benämnd InternalNetworkNode i fig. 19 - den interna cross-connect funktionaliteten för varje "väljarnod“ i det distribuerade nätelementet representeras av en hanteringsobjektklass baserad på standard, såsom atmFabric - för transporttillämpningar representeras de interna transmissionslänkarnas/anslutningarnas termineringar av stan- dard termineringspunkt (TP) hanteringsobjektklasser för de olika transportskikten. Dessutom representeras även de interna kretsarnas termineringar för switchade tillämpningar av dylika hanteringsobjektklasser - för interndirigerings- och resursvaländamål grupperas även dessa olika termineringspunkter till hanteringsobjekt, som representerar poler av termineringspunkter - den interna dirigeringsinformationen för varje intern nod representeras av en systemspecifik hanteringsobjektklass - förbindningar i subnät och topologiska uppdelningar av interna nätresurser representeras av systemspecifika hante- ringsobjektklasser.

Normalt är detta av bassystemet tillhandahållna stöd till- räckligt för att det ej skall krävas utvidgningar av till- lämpningssystemen. Det är emellertid även möjligt att tillföra tillämpnings- och/eller marknadsspecifika utvidgningar av IBSN:en.

Som inledning till en närmare beskrivning av sådana hante- ringsobjektklasser skall nu några väsentliga begrepp i samman- hanget diskuteras med hänvisning till fig. 19 och 20.

I fig. 19 visas en topologisk vy enligt ITU-TS G.803 av ett i ett telekommunikationsnät ingående subnät 1902. Subnätet 1902 '909-502 999 21 innehåller subnät 1904, 1906 samt två noder 1908 och 1910.

Subnätet 1904 bildar ett nätelement innehållande tre noder 1912, 1914 och 1916. Subnätet 1906 innehåller tre noder 1918, 1920 och 1922 bildande varsitt nätelement.

I fig. 20 visas ett hanteringsinformationsträd av vyn i fig. 19. Subnätet 1902 representeras av en hanteringsobjektin- stans 2002 av en standardklass SubNetwork enligt ITU-TS M.3l00, som bildar roten i hanteringsinformationsträdet. Subnätet 1904 och nätelementen 1908 och 1910 representeras av varsin hante- ringsobjektinstans 2004, 2008 resp. 2010 av en standardklass ManagedElement enligt ITU-TS M.3l00, vilka har namnbindnings- relationer till hanteringsobjektinstansen 2002. Subnätet 1906 representeras av en hanteringsobjektinstans 2006, som likaledes är av standardklassen SubNetwork, och har namnbindningsrelation till hanteringsobjektinstansen 2002. Nätelementen 1918, 1920 och 1922 representeras av varsin hanteringsobjektinstans 2018, 2020 resp. 2022 av standardklassen Managedßlement och med namn- bindningsrelationer till hanteringsobjektinstansen 2006. Hante- ringsobjektinstansen 2004 bildar även den lokala roten för ett hanteringsinformationsträd för nätfragment innehållande hante- ringsobjektinstanser 2024, 2026, 2028 och 2030 för den interna bärartjänsten mellan noderna i nätelemetet 1904. Vid 2032, 2034, 2036, 2038, 2040 och 2042 antyds andra fragment med namn- bindningsrelationer till hanteringsobjektinstanserna 2004, 2008, 2010, 2018, 2020 resp. 2022.

Hanteringsobjektinstanserna 2002 och 2006 är typiskt realiserade inom ett externt driftstödsystem, medan övriga hanteringsobjektinstanser är realiserade inom ett nätelement.

Eftersom nätelementet 1904 är distribuerat och på grund av att dess distributionstopologi är densamma som grundtopologin för telekommunikationsnätet, bör grundtanken vara att det bör modelleras på ett sätt som liknar modelleringen av telekommuni- kationsnätet i nätets driftstödskikt. Det finns därvid bl.a. två fundamentala koncept, som tillämpas vid modellering av nätdriftstödskikt. Med hänvisning till ITU-TS G.803, är dessa "network layering", dvs. nätskiktning, och "network partitio- ning", dvs. nätuppdelning. Nätskiktning är en "vertikal vy", Pi 502 999 22 som delar upp transportnätet i olika skiktnät med client/- server-associationer mellan sig. SDH “path layer network" är t.ex. klient till SDH "transmission media layer", som agerar som server. Nätuppdelning är en "horisontell vy", som uppdelar varje skiktnät i rekursiva abstraktionsnivåer bestående av subnät och länkar, t.ex. lokala, regionala och nationella abstraktionsnivåer.

Dessa två koncept bör även tillämpas vid modellering av den interna topologin hos ett distribuerat nätelement. Nätskiktning stöds av en hanteringsobjektklass "InternalLayerNetwork" och nätuppdelning stöds av en hanteringsobjektklass "InternalSub- network", vilka klasser beskrivs närmare nedan. Rekursiv indelning stöds, dvs. subnät kan ingå i större subnät. Den lägsta nivån av denna rekursion, som tillhandahålls av detta fragment är när en särskild hanteringsobjektinstans av klassen "InternalNetworkNode (INN)" adresseras. Den kan med hänvisning till fig. 21 exempelvis representera en avlägsen switchningsnod 2102 i ett distribuerat ATM cross-connect-nätelement 2104, som t.ex. kan motsvara nätelementet 1904 i fig. 19, vars "fysiska" distributionsvy framgår av fig. 21. Förutom noden 2102 in- nehåller nätelementet 2104 en central nod 2106 och en ytterli- gare avlägsen nod 2108. Mellan noderna 2102 och 2108 å ena sidan och noden 2106 å andra sidan finns det länkar 2110 resp. 2112.

Fig. 22 visar motsvarande hanteringsinformationsträd. I detta representeras noderna 2102, 2106 och 2108 av var sin instans 2202, 2206 resp. 2208 av klassen InternalNetworkNode.

Varje av länkarna 2110 och 2112 grupperad länkförbindelse representeras av varsin instans av ett objekt 2210 resp. 2212 av en hanteringsobjektklass InternalLinkConnection. Hanterings- objektinstanserna 2202, 2206, 2208, 2210, 2212 har namnbind- ningsrelationer till en instans 2220 av en hanteringsobjekt- klass Internalsubnetwork, vilken instans representerar det interna nätet inom nätelementet 2104. Instansen 2220 i sin tur har namnbindningsrelation till en instans 2222 av en ATM- specifik hanteringsobjektklass atmME (ME - Managedßlement).

Logiska väljarfunktioner i noderna 2102, 2106 och 2108 repre- ”99502 999 23 senteras av hanteringsobjektinstanser 2214, 2216 resp. 2218 av en hanteringsobjektklass InternalFabric med namnbindnings- relationer till hanteringsobjektinstanserna 2202, 2206 resp. 2208. I nedanstående beskrivning kommer bl.a. klasserna atmME, Internalsubnetwork, InternalLinkConnection och InternalFabric att beskrivas närmare.

För den ovan med hänvisning till fig. 21 och 22 beskrivna specifika nätelementkonfigurationen behövde operatören inte klassen "InternalLayerNetwork“, varför den utelämnades.

Eftersom behovet av hanteringsobjektklassen "InternalLayer- Network" beror på den specifika nätelementkonfigurationen har denna hanteringsobjektklass två alternativa namnbindnings- definitioner, vilka kommer att framgå av nedan mera detaljerade beskrivning med hänvisning till fig. 23. En av dessa måste väljas. Detta val kan ofta göras redan vid specificering av en nätelementkonfiguration. Senast måste valet ske vid instansie- ring av hanteringsobjektklassen.

Hanteringsobjektklassen "Interna1LayerNetwork" behövs 1) när topologin hos det distribuerade nätelementet är av det slaget att ett komplett "Layer network" enligt ITU-TS G.803 tillhandahålls i nätelementet eller 2) förhållandet mellan ett klient- och server “Layer network" i nätelementet bör hanteras i Q3. Ett scenario när detta skulle kunna vara fallet är när ett server "Layer network" tillhandahålls som en "intern" infrastruktur till bärartjänsten som erbjuds av nätelementet.

Ett exempel skulle kunna vara ett distribuerat ATM vc väl- jarnätelement, som är distribuerat över en "intern" ATM vp transportinfrastruktur.

Fig. 23 är en framställning av entity-relationer i ett nätfragment för interna bärartjänster, och visar de flesta hanteringsobjektklasser, som är av intresse vid hantering av ett bärartjänstnät i föreliggande sammanhang. Närmare bestämt återger fig. 23 en hanteringsinformationsmodell, som enligt uppfinningen är gjord väsentligen som en systemspecifik utvidg- ning av en standardiserad hanteringsinformationsmodell - i det i fig. 23 visade exemplet den tidigare omnämnda hanterings- modellen för ett ATM-nät. Såsom emellertid kommer att framgå i vWlr 502 1999 24 fortsättningen är uppfinningen ej begränsad till tillämpning i ATM-sammanhang.

I fig. 23 markeras de ifrågavarande hanteringsobjektklas- serna av varsitt block i form av en liggande rektangel. En streckad sådan rektangel markerar en klass hörande till ett annat fragment, medan de heldragna rektanglarna avser klasser tillhörande det aktuella fragmentet.

Information avseende relationer mellan de ifrågavarande objektklasserna kan härledas ur block i form av liggande rombiska figurer. En pil genom varje sådant rombiskt block pekar från en hanteringsobjektklass, som antingen "innehåller", "terminerar", "pekar mot", "utgör medlem av", eller "korskopp- lar" den hanteringsobjektklass, mot vilken pilen är riktad. Med att en hanteringsobjektklass "innehåller", "pekar mot", “utgör medlem av", eller "korskopplar" en annan hanteringsobjektklass avses här detsamma som begreppen "contains", "terminates", "points to", "member of" resp. "cross connects", enligt defini- tionen därav enligt ITU-TS M.3010. Vidare kommer fortsätt- ningsvis uttrycket "ingår i" att i en del fall användas som "omvänd" synonym för "innehåller", dvs. om det anges att en klass "ingår" i en annan klass avses detsamma som att den sistnämnda klassen "innehåller" den förstnämnda. På var sida av det rombiska blocket är två tal angivna efter varandra i pilriktningen. Dessa tal utgör del av relationsinformationen och anger för det närmast belägna rektangulära blocket antalet i denna relation ingående instanser av den klass, som markeras av detta block. Därvid markerar n ett tal som kan vara 0 eller större.

Relationsvyn utgår från standardklassen Managedßlement en- ligt ITU-TS M.3100, markerad med ett streckat block 2302.

Därtill anslutande relationsinformation 2304 anger, med hän- visning till ovanstående mera detaljerade förklaring, att en instans av denna klass kan innehålla ett antal n instanser av nästföjande klass i relationsvyn, nämligen den tidigare dis- kuterade klassen Interna1LayerNetwork vid 2306. Denna hante- ringsobjektklass representerar ett "Layer network", enligt ITU- TS G.803, ingående i ett distribuerat nätelement. ifsoz 999 Såsom berörts ovan beror behovet av denna hanteringsobjekt- klass av det aktuella nätscenariet. Den kan uteslutas om det ej krävs för ett specifikt nätelement på en specifik marknad. Även om denna klass ingår i “leveransen", kan operatören välja om klassen skall instansieras eller inte. För att tillhandahålla denna flexibilitet finns det flera alternativa relationsmöjlig- heter, nämligen de vid 2308 och 2310 markerade. Enligt relatio- nen 2308 kommer InternalLayerNetwork 2306 ej att instansieras, och därför är i detta fall n=0.

Med ledning av den inledande diskussionen hittills av det som framgår av fig. 23 torde relationerna mellan de fortsätt- ningsvis beskrivna hanteringsobjektklasserna kunna utläsas ur figuren utan en närmare förklaring därav, varför i de flesta fall en sådan kommer att utelämnas.

Följande ytterligare hanteringsobjektklasser framgår av fig. 23.

InternalLink 2312. Representerar en länk och används t.ex. i samband med felhantering av interna länkar, såsom kommer att beskrivas närmare nedan med hänvisning till fig. 27.

InternalTrail 2314. Denna hanteringsobjektklass represen- terar en "Trail" enligt ITU-TS G.803. Den kan endast ingå om InternaLayerNetwork ingår, och en instans av densamma termine- ras, jfr. relationsinfomationen vid 2316, av en instans av en standardklass 2318 TrailTerminationPoint TTP enligt ITU-TS M.3100, som representerar TTP "source", "sink" eller “bidi- flrectional" hanteringsobjektklasser i relevant TP fragment.

InternalLayerNetwork 2306 "pekar mot", dvs. känner till TTP 2318, jfr. relationen 2319.

Internalsubnetwork 2320 ingående i klassen 2302. Denna hanteringsobjektklass representerar ett delnät i ett nätele- ment. En instans av denna klass kan innehålla en annan instans av samma klass, jfr. relationsinformationen 2322. Detta beror på att rekursiv uppdelning stöds av klassen ifråga. Behovet av rekursiv uppdelning beror, såsom nämnts tidigare, på det aktuella nätscenariet. Internalsubnetwork innehåller Internal- Link 2312.

Interna1SubnetworkConnection 2324 ingående i klassen 2320. 502 90909 26 En instans av klassen 2324 termineras av en instans 2336 av en standardklass ConnectionTerminationPoint, CTP, som represen- terar CTP "source", "sink" eller "bidirectional" hanteringsob- jektklasser i relevant TP fragment. Internalsubnetwork 2320 "pekar" mot, dvs. känner till CTP 2326, jfr. relationen 2327.

Hanteringsobjektklassen 2324 representerar en förbindelse mellan termineríngspunkter inom delnät i ett nätelement.

InternalLinkConnection 2328 visas såsom ingående i klassen Internalsubnetwork 2320 och utgörande en medlem av klassen InternalLink 2312. InternalLinkConnection 2328 kan emellertid som alternativ till sistnämnda relationer ingå i klassen 2312, jfr. streckad linje 2329. En instans av klassen 2328 termineras likaledes av en instans av standardklassen 2326. Hanteringsob- jektklassen 2328 representerar en länkförbindelse inom en internlänk i ett nätelement.

InternalNetworkNode 2330 ingående i klassen 2320. Denna hanteringsobjektklass representerar ett delnät i ett nätele- ment, vilket delnät emellertid ej kan delas ytterligare i mindre delnät, som ingår i en nättopologi. I klassen 2330 ingår en instans 2331 av standardklassen Termination Point som representerar CTP/TTP "source", "sink" eller “bidirectional" hanteringsobjektklasser i relevant TP fragment.

InternalFabric 2332 ingående i klassen 2330. Denna hante- ringsobjektklass representerar korskopplingsfunktionalitet i ett delnät, som enligt ovan representeras av InternalNetworkNo- de. Korskopplingsfunktionaliteten hos en avlägsen switchnings- enhet, som är ansluten till en central switchningsenhet, skulle exempelvis kunna representeras av denna objektklass.

InternalRouting 2334 ingående i klassen 2330. Denna klass representerar dirigeringsinformation för interna bärartjänst- nätnoder.

InternalCrossConnection 2336 ingående i InternalFabric 2332. Denna klass representerar en korskopplingsförbindelse mellan två termineringspunkter belägna i ett delnät av det slag som enligt ovan representeras av InternalNetworkNode 2330 med korskopplingsfunktionalitet i ett nätelement. Objektet 2336 har relationen "korskopplar" till en instans 2337 av standard- ifïsoz 999 27 klassen TerminationPoint, som representerar CTP/TTP "source", "sink“ eller "bidirectíonal" hanteringsobjektklasser i relevant TP fragment.

InternalTPpool i fallet STM och InternalVPgroup (Internal- VirtualPathgroup) i fallet ATM 2338, båda ingående i klassen 2332, och i fig. 23 representerade av ett gemensamt block 2338.

InternalTPpool representerar en logisk gruppering av trans- porttermineringspunkter i det interna transportnätet i ett nätelement. De ingående termineringspunkterna är likvärdiga medlemmar av en pool. Detta kan vara användbart om (re)konfi- gurering krävs av dirigeringsinformationen för de olika interna korskopplingsdelnäten i ett nätelement. InternalTPpool kan även representera en logisk gruppering av kretstermineringspunkter i det interna switchade nätet. De ingående termineringspunkterna är likvärdiga medlemmar av en pool. Denna förmåga kan vara an- vändbar om det krävs (re)konfigurering av dirigeringsinforma- tionen för de olika interna switchningsdelnäten i ett nätele- ment.

Objektet internalVPgroup utgör ATM's motsvarighet till internalTPpool inom IBSN. Det representerar funktionen att allokera ATM (vc) kanaler med viss bandbredd (och QoS) på en given grupp av ATM (vp) länkar. Detta objekt är med andra ord så pass olikt objektklassen internalTPpool att det inte kan utgöra en specialisering av denna, vilken endast passar för bärartjänster av STM-typ. Detta innebär att IBSN innehåller två olika klasser för allokering av kanalresurs, nämligen InternalTPpool, som passar för STM, och InternalVirtualPath- Group, som passar för ATM. Bägge klasserna kan ytterligare specialiseras efter behov.

Objektet 2338 är medlem av TerminationPoint 2337, relation 2340, och mot detsamma pekar InternalLayerNetwork 2306 och Internalsubnetwork 2320, jfr. relationerna 2342 resp. 2344.

Vidare terminerar objektet 2338 InternalLink'2312, relationen 2346. InternalRouting 2334 och InternalFabric 2332 har rela- tionen "allocate channel", indikerat vid 2348 resp. 2350, till objektet 2338. Denna relation avser att objektet uppmanas att allokera en kanal, och ger i retur besked om vilken kanal som 502 999 28 valts, genom en referens till ett objekt, som representerar den ifrågavarande kanalen.

I fig. 24 och 25 visas namnbindnings- resp. arvsträd för det med hänvisning till fig. 23 beskrivna IBSN-fragmentet.

Med hänvisning till fig. 26 skall nu ett exempel på felde- tektering och alarmkoordinering vid fel på intern länk be- skrivas, som visar behovet av hanteringsobjektet InternalLink.

Närmare bestämt visas en hanteringsvy av noderna 1626 och 1632 i fig. 16, såsom antyds genom den inlagda bilden nedtill till höger i fig. 26, och de streckade syftlinjer, som förlöper från denna bild. I fig. 26 används därför samma hänvisningsbeteck- ningar som i fig. 16 för de båda noderna och de däremellan förlöpande alternativa länkarna, så när som på de första siffrorna, som i fig. 26 är 26 för att markera figurtillhörig- heten. I enlighet därmed betecknas noderna med 2626 resp. 2632, och de alternativa länkarna med 2648' och 2648". I fig. 26 antyds de båda länkarna 2648' och 2648" innehålla ett flertal kanaler 2648' resp 2648"n. I figuren visas även några av de El resursrepresenterande hanteringsobjekten.

Varje förbindelseändpunkt hos en kanal 2648' resp. 2648"n B i de alternativa länkarna 2648' och 2648" representeras av en instans 2650, 2652 resp. 2654, 2656 av hanteringsobjektet TerminationPoint. Dessa instanser är medlemar av instanser 2658, 2660 resp. 2662, 2664 av hanteringsobjektklassen InternalTPpool som representerar termineringen av varsin ände på länkarna 2648' och 2648". Vid 2666 resp. 2668 visas vardera en instans av InternalLínk, som representerar länkarna 2648' resp. 2648", och sålunda har relation till vardera två InternalTPpool-instanser. Noderna 2626 och 2632 har vidare varsin instans 2670 resp. 2672 av InternalRouting med relation till TPpool-instanserna 2658, 2662 resp. 2660, 2664 och in- gående i varsin instans 2674 resp. 2676 av InternalNetworkNode.

En av länkarna 2648', 2648" kan plötsligt bli otillgänglig, t.ex. på grund av att kabeln har skadats vid ett gatuarbete.

Till följd härav kommer alla TerminationPoint-instanser som representerar den felaktiga länkens kanaler att ändra drift- tillstånd till "ej funktionsduglig" p.g.a. en alarmindike- :_9502 999 29 ringssignal, vilket drifttillstånd finns definierat i ITU-TS, X.731. Vidare kommer motsvarande TPpool-instanser likaså att ändra tillstånd till "ej funktionsduglig" p.g.a. att alla deras medlemmar, dvs. TerminationPoint-instanserna, intar samma tillstånd. Slutligen kommer även motsvarande objekt Internal- Link att ändra drifttillstånd.

Genom abstraktionshöjning i hanteringsträdet kan operatören erhålla ett larm med t.ex. lydelsen "länk nr 1 är ur drift p.g.a. externt avbrott på transmissionslänken. Alternativ länk nr. 2 har valts". Dessutom kan en referens ges till något av de drabbade TerminationPoint-objekten, vilken kan användas för eventuell utredning av mera detaljer kring felet.

För att klara ovanstående, med hänvisning till fig. 26 beskrivna scenario krävs objektet InternalLink samt relationen terminates mellan InternalTPpool och detta objekt, som framgår av fig. 23.

Med hänvisning till ett exempel, som framgår av fig. 27 och 28, skall nu behovet av hanteringsobjekten internalTrail och internalLayerNetwork beskrivas.

Objektet internalLayerNetwork representerar ett nätelement- internt 'Layer network', definierat i ITU-standarden G.803 (Med titeln 'Architectures of Transport Networks based on the SDH'), vilket utgör ett nät inom ett visst transportskikt (t.ex. atmvirtual path, atmvirtual channel eller sdh multiplex sec- tion). Objektet internalTrail representerar en förbindelse, vilken garanterar transparent överföring av användardata, mellan två accesspunkter till detta nät.

Fig. 27 visar exempel på distribuerad atm vc cross-connect med ett internt atmVP transportnät i ett nätelement 2702.

Nätelementet 2702 innehåller tre noder 2704, 2706 och 2708 innehållande varsin atmVC switch, samt två noder 2710 och 2712 innehållande varsin atmVP switch. Noden 2712 har gentemot var och en av noderna 2704 och 2708 en atmVP länkförbindelse 2714 resp. 2716. Mellan noderna 2704 och 2708 förlöper en atmVC trail 2712. Denna kan bära 1-n stycken atmVC länkförbindelser, dvs. en atmVPtrail inom atmVP Layer Network motsvaras av minst en atmVClänk inom atmVC Layer Network. En nätaccess visas vid 502 999 2720 och användaraccesser vid 2722 och 2724.

Fig. 28 visar en förenklad 'protokollvy' av ett utsnitt av referenskonfigurationen i fig. 27. I fig. 28 representerar blocken 2804, 2812 och 2808 noderna 2704, 2712 resp. 2708.

Till denna figur kan tillfogas att atmVPtrail'ens termine- ringspunkter representeras av standardiserade hanteringsobjekt av typen TrailTerminationPoint (TTP). Länkförbindelsernas atmVP resp. atmVC termineringspunkter representeras av standardisera- de hanteringsobjekt av typen ConnectionTerminationPoint (CTP).

Den interna atmVP trail'en mellan de två atmVC switcharna 2704 och 2708 representeras av objektet atmVPinternalTrail. Detta är troligen baserat på det standardiserade objektet Trail. Nätet av med atmVP switcharna 2704, 2706 och 2708, atmVP länkför- bindelserna 2714 och 2716, samt nätets 'accesspunkter' vilka är av typen trail termination point, benämns atmVP Layer Network enligt ITU-T G.803 standard. Detta nät representeras av objek- tet atmVPinternalLayerNetwork.

Således kan operatören etablera atmVPtrail'ar genom att rikta en begäran mot objektet atmVPinternalLayerNetwork.

Dessutom specificerar operatören mellan vilka atmVP trailtermi- neringspunkter genom objektet trailterminationPoint hur denna trail skall etableras. Som ett resultat svarar nätelementet med en referens till objektet atmVPinterna1Trail vilket represente- rar den etablerade interna trailen.

Det med hänvisning till fig. 23-26 beskrivna IBSN är till- lämpbart både för switchade och för cross-connect tillämp- ningar, dvs. bärartjänster. I det följande kommer ett antal exempel på detta att beskrivas närmare.

Ett första exempel rörande en cross-connect tillämpning beskrivs därvid med hänvisning till fig. 29-38. Som referens- konfiguration väljs ett nätelement enligt fig. 29. Till de ovan med hänvisning till fig. 23 beskrivna generella benämningarna på hanteringsobjekt har därvid fogats förstavelsen atm för att markera att det i ifrågavarande exempel rör sig om att de fort- sättningsvis omnämnda hanteringsobjekten utgör atm-specifika> underklasser till de basklasser, vilka beskrivs med hänvisning till fig. 23-25. Dessa klasser kan t.ex. utgöra ett system- Ésoz 999 31 specifikt underträd av det standardiserade atmME hanteringsin- formationsträdet. De kan dock även utgöra ett underträd till någon annan lokal rot, t.ex. en systemspecifik sådan.

I fig. 29 är ett nätelement 2902 en distribuerad korskopp- lingsväxel, som innefattar en central väljar- och tjänstenod 2904, som via en 'intern kanal' 2906 är förbunden med en nätkanal 2908. Kanalen 2906 representerar samma fysiska kanal som kanalen 2908. Skillnaden ligger i adresseringen av deras respektive hanteringsobjektinstanser, såsom kommer att be- skrivas närmare nedan. Noden 2904 är via en intern kanal 2910 och en mellanliggande länkförbindelse 2912 förbunden med en intern kanal 2914 hos en avlägset belägen väljarnod 2916.

Länkförbindelsen 2912 kan exempelvis ha en längd av storleks- ordningen 20 km, och de båda noderna 2904 och 2916 vara belägna i samma kommun A. Noden 2916 är via en intern kanal 2918 förbunden med en användarkanal 2920. Kanalen 2918 representerar samma fysiska kanal som kanalen 2920. Skillnaden ligger i adresseringen av deras respektive hanteringsobjektinstanser, såsom kommer att beskrivas närmare nedan.

Noden 2904 är vidare via en intern kanal 2922 och en mellanliggande länkförbindelse 2924 förbunden med en intern kanal 2926 hos en väljarnod 2928, som är belägen i en annan kommun B, varvid en symbolisk kommungräns antyds vid AB.

Länkförbindelsen 2924 kan exempelvis ha en längd av storleks- ordningen 10 km. Noden 2928 är vidare via interna kanaler 2930 och 2932 och mellanliggande länkförbindelser 2934 resp. 2936 förbunden med interna kanaler 2938 resp. 2940 hos två avlägset belägna multiplexornoder 2942 resp. 2944. Länkförbindelserna 2934 och 2936 kan exempelvis ha en längd av storleksordningen 2 km. Multiplexornoderna 2938 och 2940 är via vardera en intern kanal 2946 resp. 2948 anslutna till varsin användarkanal 2950 resp. 2952. Kanalen 2946 representerar samma fysiska kanal som kanalen 2950. Skillnaden ligger i adresseringen av deras respektive hanteringsobjektinstanser, såsom kommer att be- skrivas närmare nedan.

I fig. 29 utgör nätkanalen 2908 och användarkanalerna 2920, 2950 och 2952 adresseringspunkter på nätelementet 2902 i en 502 §99 32 "svart låda"-vy. De 'interna' kanalerna 2906, 2938, 2946 och 2948 utgör i en "vit låda"-vy både adresseringspunkter på de interna noderna 2904, 2916, 2942 resp. 2944, och terminerings- punkter för en uppställd förbindelse.

En tjänsterelaterad hanteringsobjektvy av konfigurationen enligt fig. 29 visas i fig. 30, dvs. en "svart låda"- vy enligt ETSI-standard, till vilken hänvisas i publikationen ETS DE/N275-2210-Version 03 Helsinki 25-29 April 94 "B-ISDN Manage- ment Architecture and Management Infomation Model for the ATM crossconnect". Denna vy används vid normal uppställning av förbindelser över ett nät av flera nätelement. Fig. 30 visar närmare bestämt ett hanteringsträd när en korskopplings-(ATM vp)-förbindelse står uppställd mellan användarkanalen 2920 och nätkanalen 2908. .

Hanteringsträdet har i roten en instans 3002 av den ATM- specifika hanteringsobjektklassen atmME. Såsom nämnts tidigare avses i föreliggande sammanhang och fortsättningsvis med "ATM- specifik hanteringsobjektklass" en klass, vars objekt beskrivs ingående i ovannämnda publikation. Denna beskrivning behöver därför ej upprepas här. Klassen atmME innehåller objekt för bl.a. SDH-terminering, varav instanser indikeras vid 3004, 3006, 3008 och 3010, vilka representerar varsin del av det interna nätet i nätelementet 2902 för upprättande av förbindel- se till användarkanalerna 2950, 2952, 2920 resp. nätkanalen 2908. Instanserna 3004, 3006, 3008 och 3010 innehåller varsin instans 3012, 3014, 3016 resp. 3018 av den ATM-specifika hante- ringsobjektklassen atmAccessPoint. Instanserna 3016 och 3018 innehåller varsin instans 3020 resp. 3022 av den ATM-specifika hanteringsobjektklassen vpCTPBid.

Instansen 3002 av hanteringsobjektklassen atmME innehåller en instans 3024 av den ATM-specifika klassen atmFabric. In- stansen 3024 innehåller i sin tur en instans 3026 av den ATM- specifika klassen atmCrossConnection. Korskopplingsförbindelsen mellan användarkanalen 2920 och nätkanalen 2908 representeras med dubbelpilar 3028 och 3030 mellan å ena sidan vpCTPBid-in- stansen 3020 och atmCrossConnection-instansen 3026, och å andra sidan vpCTPBid-instansen 3022 och atmCrossConnection-instansen í-SÛZ 999 33 3026.

Fig. 31 visar ett hanteringsträd när en förbindelse istäl- let är upprättad mellan användarkanalerna 2950 och 2952.

Hänvisningsbeteckningar i fig. 31 på samma objektinstanser som i fig. 30 skiljer sig från de i fig. 30 genom de två första siffrorna, vilka är desamma som hos respektive figurnummer.

AtmAccessPoint-instanserna 3112 och 3114 innehåller varsin vpCTPBid-instans 3138 resp. 3140. Korskopplingsförbindelsen mellan användarkanalerna 2950 och 2952 representeras med dubbelpilar 3142 och 3144 mellan å ena sidan vpCTPBid-instansen 3138 och atmCrossConnection-instansen 3126, och å andra sidan vpCTPBid-instansen 3140 och atmCrossConnection-instansen 3126.

I det följande beskrivs ett antal exempel på en "vit låda"- vy av konfigurationen enligt fig. 29. Denna "vit låda"-vy bygger på hantering på grundval av den ovan med hänvisning till fig. 23 beskrivna hanteringsinformationsmodellen, och används vid lokala driftsfall såsom anläggningskonfigurering, test av delförbindelser inom nätelementet, övervakning (fel resp. statistik) på dylika delförbindelser. Av exemplen framgår att flera frihetsgrader finns vid konfigureringen._Valet av dessa beror på operatörens specifika krav på driftsfallen ovan.

Fig. 32 visar ett hanteringsträd för ett fall där en operatör vill kunna grupp-adressera de olika interna kanalerna i nätelementet 2902 efter geografisk position. Trädet innehål- ler, om inte annat sägs, instanser av hanteringsobjektklasser, som ingår i hanteringsinformationsmodellen enligt fig. 23-26.

Trädets rot består såsom i föregående fall av en instans 3202 av den ATM-specifika hanteringsobjektklassen atmME. Denna instans innehåller en instans 3204 av klassen atmInternalSub- network, vilken representerar hela det i nätelementet 2902 ingående interna nätet, vilket täcker kommunerna A och B.

Instansen 3204 i sin tur innehåller ytterligare en instans 3206 av klassen atmïnternalsubnetwork, som representerar den del av det interna nätet, som täcker kommun B.

Instansen 3204 innehåller vidare två instanser 3208 och 3210 av hanteringsobjektklassen atmInternalNetworkNode, vilka representerar noderna 2904 och 2916. Instansen 3206 innehåller 502 999 34 tre instanser 3212, 3214 och 3216 av atmInternalNetworkNode, vilka representerar noderna 2928, 2944 resp. 2942. Instanserna 3208, 3210 och 3212 innehåller varsin instans 3218, 3220 resp. 3222 av hanteringsobjektklassen atmInternalFabric.

Instansen 3208 innehåller vidare hanteringsobjektinstanser för bl.a. SDH-terminering och internt gränsnitt, vilka repre- senteras av streckade block 3224, 3226 och 3228, som i sin tur innehåller varsin instans 3230, 3232 resp. 3234 av den ATM- specifika hanteringsobjektklassen vpCTPBid, en för varsin av de interna kanalerna 2906, 2922 resp. 2910.

Instansen 3210 innehåller vidare hanteringsobjektinstanser för bl.a. SDH-terminering och internt gränsnitt, vilka repre- senteras av streckade block 3235 och 3236, som i sin tur innehåller varsin instans 3238 resp. 3240 av den ATM-specifika hanteringsobjektklassen vpCTPBid, en för varsin av de interna kanalerna 2918 resp. 2914.

Instansen 3212 innehåller vidare hanteringsobjektinstanser för bl.a. SDB-terminering och internt gränsnitt, vilka repre- senteras av streckade block 3242, 3244 och 3246, som i sin tur innehåller varsin instans 3248, 3250 resp. 3252 av den ATM- specifika hanteringsobjektklassen vpCTPBid, en för varsin av de interna kanalerna 2926, 2930 resp. 2932.

Instansen 3214 innehåller vidare hanteringsobjektinstanser för bl.a. SDH-terminering och internt gränsnitt, vilka repre- senteras av streckade block 3254 och 3256, som i sin tur innehåller varsin instans 3258 resp. 3260 av den ATM-specifika hanteringsobjektklassen vpCTPBid, en för varsin av de interna kanalerna 2938 resp. 2946.

Instansen 3216 innehåller vidare hanteringsobjektinstanser för bl.a. SDH-terminering och internt gränsnitt, vilka repre- senteras av streckade block 3262 och 3264, som i sin tur innehåller varsin instans 3266 resp. 3268 av den ATM-specifika hanteringsobjektklassen vpCTPBid, en för varsin av de interna kanalerna 2940 resp. 2948.

I fig. 32 har således operatören valt att konfigurera anläggningen så att noderna 2928, 2942 och 2944 ingår i ett eget delnät vilket i sin tur ingår i ett större delnät. Detta ïsnz 999 senare täcker in även de två övriga noderna 2904 och 2916.

Anledningen till denna konfigurering kan t.ex. vara att de tillhör olika kommuner och att man vill speciellt peka ut kommunens B noder och interna kanaler. Närmare bestämt kan därigenom de interna kanalerna i kommunen B lätt adresseras i en "klump" via instansen 3206 av atmlnternalsubnetwork. De in- terna kanalerna i kommun A måste däremot adresseras i två "klumpar", nämligen per nod 2904 och 2916.

Om det inte finns anledning att speciellt peka ut några interna noder för sig så kan en flat struktur istället konfigu- reras. I ett sådant fall inordnas noderna 2928, 2942 och 2944 direkt under instansen 3204.

En tredje möjlig konfiguration kan vara att även represen- tera kommunens A noder med ett eget delnät vilket ingår i samma delnät under instansen 3204 som kommunens B delnät.

Fig. 33 visar ett utsnitt av hanteringsträdet i fig. 23, som åskådliggör fast multiplexering av den interna kanalen 2946 till den interna kanalen 2938, samt fast länkförbindelse mellan de interna kanalerna 2938 och 2930.

Den fasta multiplexeringen av kanalen 2946 till kanalen 2938 representeras av att objektinstansen 3260, som represen- terar kanalen 2946, har relationen 'connectedTo' till objektin- stansen 3258, som representerar kanalen 2938 och omvänt, enligt dubbelpil 3302. Objektinstanserna 3258 och 3250 har i sin tur relationen 'terminates', enligt pilar 3304 resp. 3306, till en objektinstans 3308 av klassen atmlnternalLinkConnection, vilken representerar en ATM vp förbindelse över transmissionslänken mellan noderna 2928 och 2942.

Fig. 34 visar ett annat utsnitt av hanteringsträdet enligt fig. 23, vilket anger länkförbindelser mellan noderna 2928, 2904 och 2916. Instansen 3204 av atmlnternalsubnetwork in- nehåller två instanser 3402 och 3404 av klassen atmlnternal- LinkConnection. Objektinstanserna 3248 och 3232 har relationen 'terminates' enligt pilar 3406 resp. 3408 till instansen 3402, vilket representerar en ATM vp förbindelse över transmissions- länken mellan noderna 2904 och 2928. Objektinstanserna 3234 och 3240 har relationen 'terminates' enligt pilar 3410 resp. 3412 502 999 36 till instansen 3404, vilket representerar en ATM vp förbindelse över transmissionslänken mellan noderna 2904 och 2916.

Med hänvisning till fig. 35 skall det nu exemplifieras hur interna ATM vp korskopplingsförbindelser kan ställas upp utgående ifrån konfigurationen i fig. 23. Det är nu lämpligt att introducera objekt av klassen atmInternalTPpool vilka grupperar ett antal vpCTPBid, som alla är likvärdiga ur dirige- ringssynpunkt (samma QoS och destination). Destinationen bör vara definierad av ett av attributen hos ett atmInternalTPpool objekt. För att objektet i fråga skall vara meningsfullt antas vidare att varje intern kanal, liksom användarkanal och nät- kanal, endast är den första kanalen i en grupp. t.ex. innehål- lande 30 kanaler, av likvärdiga sådana. Detta innebär i före- liggande fall att operatören skall konfigurera dessa atmInternalTPpool objekt till noderna 2904, 2928 och 2916.

Noderna 2942 och 2944 är endast multiplexorer vilka inte kan etablera förbindelser styrt från en operatör, dvs. en given inkanal är fast kopplad till en given utkanal. Med dessa givna förutsättningar skall operatören konfigurera tre instanser av atmInternalTPpool för nod 2904, tre för nod 2928, och två för nod 2916. Dessa objekt skapas med hjälp av atmInternalFabric, vilket representerar korskopplingsfunktionaliteten i resp. intern nod. För överskådlighetens skull, och eftersom enligt nedan exemplet enligt fig. 35 endast är avsett att handla om nod 2928, innehåller fig. 35 endast den del av trädet i fig. 23, som hänför sig till nod 2928. Dock gäller att de interna kanalerna 2946 och 2938, liksom 2948 och 2940, är dubbelriktat fast kopplade till varandra.

Utgående från vad som sagts ovan, innehåller instansen 3222 av atmInternalFabric tre instanser 3502, 3504 och 3506 av atmInternalTPpool, av vilka instanserna 3248, 3250 resp. 3252 av vpCTPBid utgör medlemmar, enligt pilar 3508, 3510 resp. 3512.

Exemplet enligt fig. 35 går nu ut på att operatören vill etablera en testförbindelse över nod 2928. Skälet till detta kan vara att denna nod misstänks ge dåliga transmissionsegen- skaper, t.ex. många tappade ATM celler. ÉD2 999 37 Vid etableringen av förbindelsen i fig. 35 styr operatören instansen 3222 av atmInternalFabric. Till instansen skickas en styrorder, i vilken två ändpunkter pekas ut, i föreliggande fall de som representeras av instanserna 3248 och 3252 av vpCTPBid, vilka skall kopplas ihop med en korskoppling.

Operatören kan välja mellan att antingen peka ut en enstaka kanal eller endast en grupp av likvärdiga kanaler, via atm- InternalTPpool. Om det senare alternativet väljs så väljer nätelementet själv en kanal i denna grupp och meddelar opera- tören vilken kanal som har valts, vid bekräftelsen på att förbindelsen är uppställd. Den sålunda i föreliggande fall upprättade förbindelsen representeras av dubbelriktade pilar 3514 och 3516 mellan var och en av vpCTPBid-instanserna 3248 resp. 3252 å ena sidan, och å andra sidan en instans 3518 av atmInternalCrossConnection, som ingår i instansen 3222 av atm- InternalFabric.

Här skall nu ett fall av etablering av korskopplingsför- bindelse över flera interna noder beskrivas. Fallet bygger på att operatören vill etablera en ATM vp korskopplingsförbindelse mellan de interna kanalerna 2930 och 2918, dvs. över noderna 2928, 2904 och 2916. Detta kan naturligtvis göras i tre steg, dvs. en styrorder skickas till respektive nods instans av atmInternalFabric. Om istället den i fig. 29 konfigurerade delnätstrukturen utnyttjas kan antal styrorder minskas till en eller maximalt två stycken. För att kunna beskriva detta måste först konfigurationen kompletteras med i fig. 36 visade rela- tioner. De kanaler/kanalgrupper vilka skall vara synliga på delnätsnivå blir detta genom att skapa relationen 'pointsTo' från resp. delnät till resp. kanal/kanalgrupp.

I exemplet antas att operatören väljer att synliggöra kanalerna, eller motsvarande kanalgrupp, 2946, 2948, 2922, 2906, 2920 för det av instansen 3204 av atmlnternalsubnetwork representerade delnätet. Detta visas i fig. 36 genom pilar 3602, 3604, 3606, 3608 resp. 3610, vilka representerar ovan- nämnda relation 'pointsTo', och förlöper från instansen 3204 till respektive instans 3260 och 3268 av vpCTPBid, och till respektive instans 3612, 3614, 3616 av atmInternalTPpoo1, som soz 999 38 innehåller varsin motsvarande instans 3232, 3230 resp. 3238 av vpCTPBid. Skälet till att den interna kanalen 2922 synliggörs är att den gränsar mot ett annat delnät.

För det av instansen 3206 av atmlnternalsubnetwork repre- senterade andra delnätet synliggörs kanalerna 2946, 2948, 2926.

Detta visas i fig. 36 genom pilar 3618, 3620 och 3622, som representerar relationen 'pointsTo', och förlöper från in- stansen 3206 till respektive instans 3260 och 3268 av vpCTPBid, och till en instans 3624 av atmInternalTPpool, som innehåller instansen 3248 av vpCTPBid.

Operatören känner till att noden 2942 är en multiplexor vilken har kanalen 2946 fast kopplad till kanalen 2938, och att denna i sin tur enligt fig. 37 är kopplad till kanalen 2930 via en transmissionslänk. Han vet dessutom att enligt fig. 32 kanalerna 2926 och 2910 är kopplade till kanalen 2922 resp. kanalen 2914 via transmissionslänkar. Detta innebär att för- bindelsen kan etableras genom att skicka endast en styrorder till instansen 3204 av atmlnternalsubnetwork med adresserna till kanalerna 2946 och 2920 som parametrar. Det av instansen 3204 representerade delnätet kommer att etablera en förbindelse över de tre noderna 2928, 2904, och 2916.

Detta innebär att en komplett förbindelse har etablerats mellan kanalerna 2946 och 2920 via kanalen 2930. Med hänvisning till fig. 37 representeras denna förbindelse med en instans 3702 av hanteringsobjektklassen atmlnternalSubnetworkConnection ingående i atmlnternalsubnetwork, till vilken instans instan- serna 3260 och 3238 av vpCTPBid har relationen 'terminates'.

Om man istället antar att operatören inte känner till att kanalen 2946 är förbunden med kanalen 2930 via fast multi- plexering och transmission, får operatören ställa upp för- bindelsen i två steg. Operatören måste då först "öppna upp" det av instansen 3206 representerade delnätet för att kanalen 2930 skall bli synlig, jfr. instansen 3260 av vpCTPBid i fig. 37, som representerar denna kanal. Med hänvisning till fig. 38 etablerar operatören i det första steget en förbindelse, representerad av en instans 3802 av atmInternalCrossConnection ingående i instansen 3222 av atmInternalFabric, mellan de av “#502 999 39 vpCTPBid-instanserna 3250 och 3248 representerade interna kanalerna 2930 och 2926 över nod 2928. Detta sker på samma sätt som beskrivits närmare ovan med hänvisning till fig. 37 för förbindelsen mellan kanalerna 2932 och 2926 över den ifråga- varande noden 2928.

Därpå upprättas i steg 2 en delnätförbindelse, represente- rad av en instans 3804 av atmInternalSubnetworkConnection ingående i instansen 3204 av atmlnternalsubnetwork, från nodens 2904 interna kanal 2922, representerad av vpCTPBid-instansen 3232, till nodens 2916 interna kanal 2920, representerad av vpCTPBid-instansen 3238. Pilarna 3806 och 3808 representerar relationen 'terminates'.

Den av instansen 3402 av atmlnternalLinkConnection repre- senterade förbindelsen mellan nodens 2928 interna kanal 2926 och nodens 2904 interna kanal 2922 är uppställd såsom beskri- vits ovan med hänvisning till fig. 34, där pilarna 3406 och 3408 representerar relationen 'terminates'.

I det följande kommer användning av interna bärartjänstnät- fragment enligt uppfinningen, IBSN, att beskrivas närmare för switchade tillämpningar. Som referenskonfiguration väljs ett nätelement enligt fig. 39 med "svart låda"-vy enligt fig. 40 och standardiserad hanteringsobjektmodell enligt fig. 41.

I fig. 39 är ett nätelement 3902 en distribuerad B-ISDN väljare, som innefattar en central väljar- och tjänstenod 3904, som via en intern kanal 3906 är förbunden med en nätkanal 3908.

Noden 3904 är via en intern kanal 3910 och en mellanliggande länkförbindelse 3912 förbunden med en intern kanal 3914 hos en avlägset belägen väljarnod 3916. Noden 3916 är via en intern kanal 3918 förbunden med en användarkanal 3920.

Noden 3904 är vidare via en intern kanal 3922 och en mellanliggande förstahandslänk 3924, som innehåller ett antal vid 3924n antydda länkförbindelser, förbunden med en intern kanal 3926 hos en väljarnod 3928. Noden 3928 är vidare via interna kanaler 3930 och 3932 och mellanliggande länkar 3934 resp. 3936 förbunden med interna kanaler 3938 resp. 3940 hos två avlägset belägna multiplexornoder 3942 resp. 3944. Multi- plexornoderna 3938 och 3940 är via vardera en intern kanal 3946 502 999 40 resp. 3948 anslutna till varsin användarkanal 3950 resp. 3952.

En alternativ länk 3924' mellan interna kanaler 3926' och 3922' hos noderna 3928 resp. 3904 används vid fel på endast förstahandslänken 3924. En alternativ länk 3954 mellan interna kanaler 3956 och 3958 hos noderna 3928 resp. 3916 används vid fel på bägge länkarna mellan nod2 och nodl eller vid fel på länken 3912 mellan noderna 3904 och 3916.

En tjänsterelaterad hanteringsobjektvy av väljaren enligt fig. 39 visas i fig. 40, dvs. en "svart låda"-vy enligt ETSI standard, för att åskådliggöra hantering av dirigeringsin- formation, abonnent- och abonnentlinjeinformation.

Med hänvisning till fig. 40 innefattar denna "svart låda"- vy ett destinationsidentifierande fragment 4002, 'Routing target identification', som identifierar två växlar 4004 och 4006 för nationella resp. internationella koppel. Beteckningar- na B och A i respektive block 4004, 4006 anger B- resp. A- nummer. Motsvarande kretsvalfragment, 'Circuit selection', visas vid 4008. Även ett stort antal lokala destinationer och accessportar, varav några antyds vid 4010, 4012 och 4014 identifieras för de terminerande kopplen till anslutna abonnen- ter. Motsvarande fragment för abonnentdataadministration, 'Customer administration', visas vid 4016. Fig. 40 visar även ett driftstödsystem 4018, som via ett datakommunikationsnät 4020 och ett Q-gränssnitt 4022 kommunicerar med nätelementet, liksom via gränssnitt 4024 och 4026 med växlarna 4004 resp. 4006. Begreppen 'Routing target identification', 'Circuit selection' och 'Customer administration' är enligt ETSI-stan- dard.

I fig. 41 visas en förenklad hanteringsobjektmodell enligt N-ISDN standard av dirigeringsinformationen, som används i vyn enligt fig. 40. För B-ISDN finns ännu ingen standard, men troligen kommer grundstrukturen att bli densamma. B-nummer- analys görs i det destinationsidentifierande fragmentet 4002.

Ytterligare analys görs i kretsvalfragmentet 4008 såsom val av väg (baseras bl.a. på signalerings- och bärartjänstattribut).

Principerna för valet av kanal (kretskopplad länkförbindelse) inom vägen ('route') kommer dock att vara annorlunda i fallet *S02 999 41 B-ISDN. Kretskopplade länkförbindelser (circuits) motsvaras i ATM-fallet av virtuella kanalförbindelser (ATM vc connection).

Resursallokeringen, såsom bandbredd, för dessa sker per för- bindelsetablering. ATM (vc) kanalerna allokeras på ATM 'virtual path' grupper, vilka representerar konfigurerade grupper av ATM (vp) länkar mellan nätelementen. De i figuren använda beteckningarna på hanteringsobjekt inom ovala block är enligt N-ISDN standard, jfr. exempelvis Interim ETSI standard I-ETS 300 292, DI/NA-43310, October 1993, "Functional Specifi- cation of call routing information management on the Operations System/Network Element (OS/NE) interface".

En "vit låda"-vy används vid lokala driftsfall såsom anläggningskonfigurering, av t.ex. intern förbindelsedirige- ring, test av transmissionslänkar mellan noderna inom nätele- mentet, etablering av interna testförbindelser, övervakning med felindikering och felstatistik på dylika förbindelser och transmissionslänkar, och övervakning av intern trafikexekvering såsom dirigering och resursallokering av ATM kanaler. De nedan med hänvisning till fig. 42 och 43 beskrivna exemplen baserar sig på användning av IBSN enligt uppfinningen. Flera frihets- grader finns vid konfigureringen. Valet av dessa beror på operatörens specifika krav på de möjliga driftsfall, som framgår av fig. 39.

I den i fig. 39 visade referenskonfigurationen krävs anläggningskonfigurering av intern förbindelsedirigering.

Anledningen härtill är att det finns två alternativa länkar 3924' och 3954, som förutom den ordinarie länken 3924 möjliggör ett första resp. andra alternativ för förbindelse mellan noderna 3926 och 3906. Om dessa inte hade funnits skulle sådan konfigurering inte behövas. Det bör noteras att denna typ av dirigering endast gäller styrning av längs vilken intern väg en förbindelse mellan tvâ förbindelsetermineringspunkter, eller grupper, skall etableras. Det genomförs alltså en enkel 'väg- analys' utan bl.a. “nummeranalys" och "signaleringsanalys", vilka redan gjorts på call-nivån. I fallet ATM kan dock resurs- allokeringen av kanal på intern ATM länk vara rätt komplicerad.

I fig. 42 visas i tabellform ett förenklat exempel på hur 502 999 42 konfigureringen principiellt kan ske, med hjälp av konfigure- ring av möjliga vägval per nod. Tabellerna 4202, 4204 och 4206 visar därvid olika vägval eller dirigeringsfall för noderna 3928, 3904 resp. 3916. För det nedan närmare med hänvisning till fig. 43 beskrivna dirigeringsfallet användarkanal 3950 -> nätkanal 3908 har pilar 4208, 4210 och 4212 införts för att ange den ordinarie vägen, vägen enligt alternativ 1, resp. vägen enligt alternativ 2. De interna ut-kanalerna angivna i tredje spalten innebär en förenkling. I verkligheten kommer grupper av 'ut-kanaler' oftast att utpekas, (i fallet ATM vc kommer istället grupper av interna ATM vp länkar att pekas ut).

Allokering av enskild 'ut-kanal' inom utpekad grupp sker separat, och denna kanal motsvarar en specifik 'in-kanal' i nästa nod. 9 Möjliga vägar över det interna nätet kan konfigureras genom att 'länka ihop' varje enskild nods vägval till en komplett vägbeskrivning på nätnivå, såsom enligt pilarna 4208, 4210 och 4212. En viktig användning av denna beskrivning kan vara att kunna hantera statusinformation, t.ex. felinformation, per väg/nätväg och inte bara per nod och länk. Detta kan användas på många sätt, t.ex. att erhålla statusinformation för konnek- tiviteten genom ett visst delnät eller adaptiv styrning av intern dirigering på nätnivå. Beskrivningen kan antingen realiseras distribuerat per nods vägvalsinformation, som i fig. 42, eller centralt på nätnivå.

Ett utsnitt av ett hanteringsträd för intern dirigering visas i fig. 43. I detta fall har operatören valt att endast konfigurera ett styck delnät med en flat struktur, som ej innehåller några ytterligare delnät. Närmare bestämt beskrivs dirigeringsfallet användarkanal 3950 -> nätkanal 3908 för noderna 3928, 3904 och 3916, enligt tabellerna 4202, 4204 resp. 4206, jfr. fig. 42.

Trädets rot består såsom i tidigare fall av en instans 4302 av den ATM-specifika hanteringsobjektklassen atmME. Denna instans innehåller en instans 4304 av klassen atmlnternalsub- network, vilken representerar det ifrågavarande delnätet.

Instansen 4304 innehåller vidare tre instanser 4306, 4308 och 9502 999 43 4310 av hanteringsobjektklassen atmInternalNetworkNode, vilka representerar noderna 3928, 3904 resp. 3916. Instanserna 4306, 4308 och 4310 innehåller varsin instans 4312, 4314 resp. 4316 av hanteringsobjektklassen atmInternalRouting. Objektet In- ternalRouting inom IBSN fragmentet representerar, såsom nämnts tidigare, dirigeringsinformation per nod. Instansen 4306 av atmInternalNetworkNode innehåller tre instanser 4318, 4320, 4322 av en objektklass interna1VirtualPathGroup, och instanser- na 4308 och 4310 av atmInterna1NetworkNode innehåller varsin instans 4324 resp. 4326 av samma klass.

Instansen 4312 av atmInternalRouting allokerar enligt pil 4328 instansen 4318 av InternalVirtualPathGroup för att repre- sentera den ordinarie interna vägen mellan de interna kanalerna 3930 och 3926 hos nod 3928, som ingår i det aktuella dirige- ringsfallet.

På samma sätt allokerar instansen 4312 av atmïnternal- Routing enligt pil 4330 instansen 4320 av Internalvirtual- PathGroup för att representera vägen mellan de interna kanaler- na 3930 och 3926'. Denna väg utgör alternativ 1 för nod 3928 i det aktuella dirigeringsfallet.

På samma sätt allokerar instansen 4312 av atmïnternal- Routing enligt pil 4332 instansen 4322 av InternalVirtual- PathGroup för att representera vägen mellan de interna kanaler- na 3930 och 3956. Denna väg utgör alternativ 2 för nod 3928 i det aktuella dirigeringsfallet.

Instansen 4314 av atmInternalRouting allokerar enligt pil 4334 instansen 4324 av InternalVirtualPathGroup för att i det aktuella dirigeringsfallet representera vägen hos nod 3904 mellan endera av de interna kanalerna 3922 och 3922' å ena sidan och den interna kanalen 3906 å andra sidan, dvs. ordina- rie väg resp. väg enligt alternativ 1 i tabell 4204.

Instansen 4316 av atmInternalRouting allokerar enligt pil 4336 instansen 4326 av InternalVirtualPathGroup för att i det aktuella dirigeringsfallet representera vägen enligt alternativ 2 i tabell 4206 mellan de interna kanalerna 3958 och 3914 hos nod 3916.

I fig. 43 antyder vidare pilar 4338 och 4338' mellan 502 999 44 instanserna 4312 och 4314 ordinarie väg enligt kanal 3924 resp. den alternativa vägen 1 enligt kanal 3924' mellan noderna 3928 och 3904 i det aktuella dirigeringsfallet. Pilarna 4338 och 4338' motsvarar alltså pilarna 4208 resp. 4210 i fig. 42. Pil 4340 mellan instanserna 4312 och 4316 antyder den alternativa vägen 2 via nod 3916 i det aktuella dirigeringsfallet. Pilen 4340 motsvarar alltså pilen 4212 i fig. 42.

Påverkan av intern distribution på hanteringsinformations- modellen för utrustning i ett nätelement kommer nu att behand- las närmare med hänvisning till fig. 44 och 45.

Fig. 44 hänför sig som exempel till ett distribuerat lokal- växelnätelement 4402 av liknande typ som i fig. 16. Det består av sex interna noder på olika geografiska ställen, nämligen en central väljare/tjänstenod 4404, två avlägsna väljare/kon- centratornoder 4406 resp. 4408 och tre avlägsna multiplexorno- der 4410, 4412 resp. 4414. Noden 4404 har vid 4415 antydda anslutningar till ej visade externa länkar och till ett lika- ledes ej visat driftstödsystem. Noden 4404 är förbunden med noderna 4406 och 4408 genom länkar 4416 resp. 4418. Noden 4406 är förbunden med noderna 4410 och 4412 genom länkar 4420 resp. 4422 och noden 4408 är förbunden med noden 4414 genom en länk 4424. Till noderna 4404, 4408, 4410, 4412 och 4414 är abonnent- linjer anslutna.

Under installation, uppgradering, alarm, reparation av utrustningsresurser (t.ex. kretskort, kraftenheter etc.) i ett distribuerat nätelement är det nödvändigt att den administrati- va personalen för systemet erhåller information om den fysiska placeringen av de individuella utrustningsresurserna. Hante- ringsinformationsmodellen måste på något sätt innehålla denna information.

TMN standardrekommendationer (ITU-TS M.3100) specificerar att varje utrustningsresurs bör representeras av ett hante- ringsobjekt av klassen "Equipment", eller en underklass av denna. Denna klass av hanteringsobjekt innehåller ett lägesatt- ribut "LocationName", vilket bör innehålla information avseende den fysiska placeringen av utrustningsresursen. Standarden anger emellertid ej exakt hur attributet skall användas. En .Én-OZ 999 45 modell för hur detta skall ske kommer att beskrivas här med hänvisning till fig. 45.

Fig. 45 visar ett partiellt och stiliserat hanteringsin- formationsträd för utrustningsresurserna hos det i fig. 44 visade nätelementet. Närmare bestämt ingår däri för överskåd- lighetens skull endast objekt, 4504, 4506 och 4514, som repre- senterar till noderna 4404, 4406 och 4414 hörande utrustnings- resurser. Övriga, ej visade objekt, representerande noderna 4408, 4410 och 4412, ingår på motsvarande sätt i hanteringsin- formationsträdet. Gentemot driftstödsystemet representeras nätelementet 4402 i hanteringsinformationsträdets rot av en instans 4515 av en "namngivningsobjekt"-klass under klassen ManagedElement. _ Objekten 4504, 4506 och 4514, liksom de andra, ej visade objekten utgör vart och ett en instans av en klass "Equipment- Node", under "namngivnings"-objektklassen. Varje sådan instans är gemensam för hårdvara belägen på samma geografiska ställe, dvs., i det visade exemplet, i respektive nod 4404-4414. Denna hårdvara utgörs av utrustningsresurser såsom skåp, ställningar och deras inpluggade tryckta kretskort. Varje objektinstans av "EquipmentNode" har ett lägesattribut "LocationName", som används för att specificera det geografiska läget, t.ex. gatuadress, för respektive nod.

Varje i en nod, såsom noderna 4404-4414, ingående utrust- ningsresurs representeras likaledes av en instans av objekt- klassen "Equipment“, som är namngivningsassocierad med den objektinstans av klassen "EquipmentNode", som representerar noden ifråga. I exemplet enligt fig. 45 antyds för vart och ett av objekten 4504, 4506 och 4514 sådana instanser vid pilar 45041¶, 45061¶ resp. 45141m. Dessa instansers respektive läges- attribut “LocationName" anger läget för respektive resurs i den nod, i vilken resursen är belägen. Sålunda representerar lägesattributen för skåputrustningsobjekt skåpets läge (t.ex. rum, skåprad etc.), lägesattributet för underrackar specifice- rar läget i skåpet, och lägesattributet för enheter inpluggade i underrackarna specificerar läget i en underrack. Denna hierarkiska lokaliseringsinformationsstruktur används för olika 502 999 46 driftändamål.

Om man exempelvis detekterar ett utrustningsfel i en avlägset belägen multiplexor kommer en alarmhändelserapport av typen "Equipment alarm" att alstras, och sänds från nätelemen- tet till ett driftstödsystem. Av alarmrapporten skall operatö- ren kunna läsa attributet "LocationName", som i själva verket utgör en sammanlänkning av informationen i utrustningsmodell- hierarkin, och ger den nödvändiga lokaliseringsinformationen.

Ytterligare ett exempel på tjänster, som ur driftsynpunkt påverkas av den systeminterna distributionen, är sådana som krävs för hantering av det distribuerade databehandlingssyste- met i nätelementet. Särskilt påverkade är sådana funktioner som ger kommunikation mellan program (processer) i olika processo- rer. I Låt oss i åskådningssyfte anta att alla processorer i systemet använder atm-bärartjänsten för kommunikation med varandra. Dirigeringsinformation som är specifik för kommunika- tionen mellan processorer måste då definieras och kanaler i atm väljarnät och på atm länkar måste reserveras för kommunikation mellan processorer.

Det behövs därför ett hanteringsfragment för det interna kommunikationsnätet mellan processorer. I detta fragment kan de olika processorerna var och en representeras av ett hanterings- objekt, som innehåller information avseende adressen hos den systeminterna atm-termineringspunkt som den är ansluten till.

Denna information kan exempelvis implementeras som ett rela- tionsattribut, som refererar till ett systeminternt hante- ringsobjekt för atm-nättermineringspunkt. Från denna kommuni- kationsadressinformation kan databehandlingssystemet vid start och vid konfigurationsändringar kalkylera dirigeringstabeller och bestämma på vilka atm-kanaler etablering skall ske i det interna atm-bärnätet.

Claims (23)

“__'5Û2 999 47 Patentkrav.

1. Telekommunikationssystem innefattande ett nät av nätelement, vilka tillhandahåller nätelement- funktioner, som möjliggör kommunikation mellan nätelementen, och vart och ett innehåller resurser i form av hårdvara och programvara, vilka används för nätelementfunktionernas genom- förande, ' minst ett driftstödsystem, som för genomförande av nätele- mentfunktionerna hanterar resurserna enligt en första hante- ringsinformationsmodell via i programvaran ingående hanterings- objekt, vilka representerar resurserna, varvid driftstödsyste- met av nätelementen erbjuds en standardiserad tjänstespecifik “svart låda"-vy, innebärande att ur resurshanteringssynpunkt endast sådana delar av resurserna är åtkomliga, vilka behöver användas i samband med kommunikation mellan nätelementen och mellan anslutna abonnenter, samt uppkoppling av förbindelser, kännetecknat av att åtminstone ett av nämnda nätelement innehåller flera noder, vilka ingår i ett för detta nätelement internt system, och tillhandahåller interna nätelementfunktioner i ett internt bärartjänstnät, samt interna resurser i form av hårdvara och programvara, vilka används för de interna nätelementfunktioner- nas genomförande, ett driftstödsystem av detta nätelement erbjuds en "vit låda"-vy, innebärande att interna resurser är åtkomliga för driftstödsystemet, vilket använder hanteringsobjekt, som representerar de interna resurserna, för att enligt en andra hanteringsinformationsmodell hantera resurserna vid användning av dem i samband med genomförande av interna nätelementfunk- tioner.

2. Nätelement, som ingår i ett nät av nätelement i ett telekommunikationsnät, tillhandahåller nätelementfunktioner möjliggörande kommunikation med andra i nätet ingående nätele- ment, samt innehåller resurser i form av hårdvara och program- vara, vilka används för dessa nätelementfunktioners genom- förande medelst minst ett driftstödsystem, som för detta ändamål enligt en första hanteringsinformationsmodell hanterar 502 999 48 resurserna via i programvaran ingående hanteringsobjekt, vilka representerar resurserna, varvid ett sådant driftstödsystem av nätelementet erbjuds en standardiserad tjänstespecifik "svart låda"-vy, innebärande att ur resurshanteringssynpunkt endast sådana delar av re- surserna är åtkomliga, vilka behöver användas i samband med kommunikation med andra nätelement och mellan till nätelementet anslutna abonnenter, samt uppkoppling av förbindelser, kännetecknat av att nätelementet innehåller flera noder, vilka ingår i ett för nätelementet internt system, och tillhandahåller interna nätelementfunktioner i ett internt bärartjänstnät, samt interna resurser i form av hårdvara och programvara, vilka används för de interna nätelementfunktionernas genomförande, ett driftstödsystem av detta nätelement kan erbjudas en "vit låda"-vy, innebärande att interna resurser är åtkomliga för detta driftstödsystem, så att det kan använda hanteringsob- jekt, som representerar de interna resurserna, för att enligt en andra hanteringsinformationsmodell hantera de interna resur- serna vid användning av dem i samband med genomförande av interna nätelementfunktioner.

3. Sätt att konfigurera ett nätelement, som ingår i ett nät av nätelement i ett telekommunikationsnät, för att möjliggöra hantering av i nätelementet ingående interna resurser i form av hårdvara och mjukvara, som används för genomförande av interna nätelementfunktioner, vilket nätelement dessutom tillhandahåller nätelementfunktioner möjliggörande kommunikation med andra i nätet ingående nätelement, samt innehåller resurser i form av hårdvara och programvara, vilka används för dessa nätelementfunktioners genomförande medelst minst ett driftstödsystem, som för detta ändamål enligt en första hanteringsinformationsmodell hanterar resurserna via i programvaran ingående hanteringsobjekt, vilka representerar resurserna, samt erbjuder ett sådant driftstödsystem en standardiserad tjänstespecifik “svart låda"-vy, innebärande att ur resurs- fBo2 999 49 hanteringssynpunkt endast sådana delar av resurserna är åtkom- liga, vilka behöver användas i samband med kommunikation med andra nätelement och mellan till nätelementet anslutna abonnen- ter, samt uppkoppling av förbindelser, kännetecknat av att nätelementet konfigureras med ett för nätelementet internt system, i vilket i nätele- mentet ingående noder tillhandahåller de interna nätelement- funktionerna i ett internt bärartjänstnät, en "vit låda"-vy, som kan erbjudas ett driftstödsystem och innebär att interna resurser är åtkomliga för detta driftstöd- system och hanteringsbara av detta medelst hanteringsobjekt, som representerar de interna resurserna, en andra hanteringsinformationsmodell enligt vilken ett sådant driftstödsystem hanterar de interna resurserna vid användning av dem i samband med genomförande av interna nätele- mentfunktioner.

4. Nätelement enligt något av föregående krav, kännetecknat av att den andra hanteringsinformationsmodellen är utformad på ett sådant sätt att nätelementet efter behov tillhandahåller "svart låda"-vyn eller "vit låda"-vyn.

5. Nätelement enligt något av föregående krav, kännetecknat av att den andra hanteringsinformationsmodellen är utformad som ett tillägg till den första hanteringsinformationsmodellen.

6. Nätelement enligt krav 5, kännetecknat av att ett hante- ringsinformationsträd, som bygger på den andra hanteringsin- formationsmodellen, i roten har ett hanteringsobjekt, som även är känt för hantering enligt den första informationsmodellen.

7. Nätelement enligt krav 6, kännetecknat av att rot- objektet (atmME) är av en standardklass, som är specifik för en transportnätstandard, som kan utnyttjas i "svart låda"-vyn.

8. Nätelement enligt krav 5, kännetecknat av att rot- objektet är av en klass specifik för användning vid hantering enligt den andra hanteringsinformationsmodellen.

9. Nätelement enligt något av krav 5-8, kännetecknat av att rotobjektet innehåller ett internnätspecifikt hanteringsobjekt (Interna1LayerNetwork), som stödjer nätskiktning i det interna 502 999 50 nätet.

10. Nätelement enligt något av krav 5-9, kännetecknat av att rotobjektet innehåller ett internnätspecifikt hanterings- objekt (InternalSubNetwork), som stödjer nätuppdelning i det interna nätet och representerar ett delnät i detta, som kan uppdelas i ytterligare delnät.

11. Nätelement enligt krav 9 eller 10, kännetecknat av att det nätskiktning stödjande objektet innehåller ett intern- nätspecifikt hanteringsobjekt (InternalSubNetwork) som stödjer nätuppdelning i det interna nätet och representerar ett delnät i detta, som kan uppdelas i ytterligare delnät.

12. Nätelement enligt något av krav 9-11, kännetecknat av att det nätskiktning stödjande objektet innehåller ett in- ternnätspecifikt objekt (InternalTrail), vilket representerar en traíl av standardtyp.

13. Nätelement enligt något av krav 10-12, kännetecknat av att det ett uppdelningsbart delnät representerande objektet in- nehåller ett internnätspecifikt objekt (InternalSubnetwork- Connection), som representerar en förbindelse mellan termine- ringspunkter inom delnät i det interna nätet.

14. Nätelement enligt något av krav 10-13, kännetecknat av att det ett uppdelningsbart delnät representerande objektet innehåller ett internnätspecifikt objekt (InternalLinkConnec- tion), som representerar en länkförbindelse i det interna nätet.

15. Nätelement enligt något av krav 10-14, kännetecknat av att det ett uppdelningsbart delnät representerande objektet innehåller ett internnätspecifikt objekt (InternalNetworkNode), som representerar ett ej uppdelningsbart delnät i det interna nätet.

16. Nätelement enligt krav 15, kännetecknat av att det ett ej uppdelningsbart delnät representerande objektet innehåller ett objekt, som representerar en instans (TerminationPoint) av ett objekt av standardklass, som representerar en terminerings- punkt.

17. Nätelement enligt krav 15 eller 16, kännetecknat av att det ett ej uppdelningsbart delnät representerande objektet in- E02 999 51 nehåller ett internspecifikt objekt (Interna1Fabric), som representerar en korskopplingsfunktionalitet för det ej upp- delningsbara delnätet.

18. Nätelement enligt något av krav 15-17, kännetecknat av att det ett ej uppdelningsbart delnät representerande objektet innehåller ett internspecifikt objekt (InternalRouting), som representerar dirigeringsinformation för de ej uppdelningsbara delnäten.

19. Nätelement enligt krav 17 eller 18, kännetecknat av att det en korskopplingsfunktionalitet representerande objektet in- nehåller ett internnätspecifikt objekt (InternalCrossConnec- tion), som representerar en korskoppling mellan två termine- ringspunkter i ett ej uppdelningsbart delnät.

20. Nätelement enligt något av krav 17-19, kännetecknat av att det en korskopplingsfunktionalitet representerande objektet innehåller ett internnätspecifikt objekt (InternalTPpool), som representerar en logisk gruppering av transportterminerings- punkter i det interna transportnätet.

21. Nätelement enligt något av krav 15-20, kännetecknat av att det ett ej uppdelningsbart delnät representerande objektet innehåller ett internnätspecifikt objekt (InternalTPpool), som representerar en logisk gruppering av kretstermineringspunkter i det interna switchade nätet.

22. Nätelement enligt något av krav 17-21, kännetecknat av att det en korskopplingsfunktionalitet representerande objektet innehåller ett internnätspecifikt objekt (InternalVPgroup), som representerar funktionen att allokera ATM (vc) kanaler med viss bandbredd (och QoS) på en given grupp av ATM (vp) länkar i det interna transportnätet.

23. Nätelement enligt något av krav 15-22, kännetecknat av att det ett ej uppdelningsbart delnät representerande objektet innehåller ett internnätspecifikt objekt (InternalVPgroup), som representerar funktionen att allokera ATM (vc) kanaler med viss bandbredd (och QoS) på en given grupp av ATM (vp) länkar i det interna switchade nätet.