SE515179C2 - Sätt för internkommunikaton i telekommunikationssystem - Google Patents

Description

30 35 515 179 z tionstjänster för en centraldator är anordnade i oberoende horisontella funktioner, vilka hante- ras parallellt. Villkorsberoenden mellan de horisontella funktionerna löses av ett organ, som upprättar gränssnitt mellan de horisontella funktionerna och ett tillämpningsskikt hos central- datom. Kommunikationen förbättras genom att medge adaptiv specifikation av ett högnivåpro- tokoll använt i arkitekturen för att tillhandahålla högnivåtjänstema. Denna adaptiva specifika- tion kan initieras som svar på ändrade användarkrav eller varierande nätverksparametrar. I protokollspecifikationen väljs lämpliga värden på parametrar för de horisontella funktionerna, som är parametriskt programmerbara.

I EP O 513 799 beskrivs ett system för att stödja inmatning eller referens av ett datavär- de eller ett strukturvärde, som utgör en komponent av en protokolldataenhet. Denna enhets syntax definieras enligt ISO8824 och den kodas/avkodas i enlighet med ASN.l reglerna i ' rsosszs.

I det amerikanska patentet 4 967 193 beskrivs en metod för att kommunicera med ett protokoll använt i ett telekommunikationssystem med åtminstone en centraldator ansluten till ett flertal digitala gränssnittsenheter via en kommunikationsmodul. Varje digital gränssnittsen- het är ansluten till ett flertal kanalenheter. Från datorn till kommunikationsmodulen sänds ett instruktionsmeddelande med åtminstone en första adress hos en utvald gränssnittsenhet, en adress hos en utvald kanalenhet, en andra adress, som är väsentligen identisk med den första gränssnittsenhetadressen, samt en första informationsdel. Instruktionsmeddelandet från kom- munikationsmodulen sänds till de digitala gränssnittsenheterna, varvid den utvalda gränssnitts- enheten mottager instruktionsmeddelandet. I den utvalda gränssnittsenheten avlägsnas den första adressen från instruktionsmeddelandet till bildande av ett modifierat meddelande. Det modifierade meddelandet sänds från den utvalda gränssnittsenheten till kanalenheterna, varvid den utvalda kanalenheten mottager det modifierade meddelandet. Den utvalda modulen till- handahåller ett svarsmeddelande till datorn. Protokollet tillhandahåller ett svarsformat, som identifierar den svarande modulen, typ av svar, och, i händelse av fel, var felet detekterades och vilken typ av fel det rör sig om.

I den amerikanska patentskriften 5 276 816 beskrivs ett system för tolkning av medde- landen sända från en in/ut-enhet till ett tillämpningsobjekt i en objektorienterad miljö, så att rneddelandetolkningen av dessa meddelanden förblir konsistent oberoende av vilken in/ut- enhet som används för att generera dem. Dynamisk bindning används för att tolka alla objekt- objektinteraktioner, som kan uppträda. Detta medger att ytterligare in/ut-enheter kan användas i den objektorienterade miljön utan behov av att uppdatera alla tillämpningsobjekt däri.

I den europeiska patentansökan O 505 092 beskrivs ett system för användning av en dator för att styra en anordning för åstadkommande av ett flertal tjänster för ett flertal enti- teter. Varje entitet motsvarar exakt en av tjänsterna och varje tjänst har sin egen kopia av den kod, som definierar tjänsten. Systemet associerar en process som exekverar tjänsten med varje tjänst. Koden för en tjänst defmierar en "flnite state"-tillstândsmaskin som exekveras kontinuerligt av tjänsteprocessen. I ett givet tillstånd kan tillståndsmaskinen röra sig utefter ett 40 beslutsdiagram, som är direkt åtkomligt för processen. Åtgärder som skall vidtas vid passe- 20 25 30 35 515 179 a rande av en nod hos beslutsdiagrammet kan definieras i tillståndsmaskinen. Tjänsteprocessen kommunicerar med andra processer och med sig själv via interprocessmeddelanden. Varje tillstånd hos tillståndsmaskinen innehåller eventhanterare för att svara på meddelanden, som mottagits av tjänsteprocessen.

EP 555 997 hänför sig till protokollstyrd kommunikation mellan entiteter i ett distribue- rat datorsystem. Ett generellt protokoll används i vilket man kan sända en protokollbeskriv- ning på ett språk som är oberoende av några tillämpningar. Varje entitet har möjlighet att tolka vilket protokoll som beskrivs i det generella protokollet med ledning av det tillämp- ningsoberoende språket. Alternativt kan protokolltolken i mottagande entitet utrustas med protokollbeskrivning i ett minne, varvid man endast behöver sända en protokollidentifierare i det generella protokollet.

WO 94/6251 visar bland amiat ett signaleringsprotokoll för telekommunikationsnät.

Nätets noder är sammankopplade med ett kopplingsnät. Kommunikation mellan noderna sker med två olika protokoll, ett basprotokoll som används för att upprätta signalvägar mellan servicerelaterade mjukvarugrupper och ett eller flera specifika protokoll.

EP 350 844 beskriver en metod för att överföra programparametrar från en växel till terminaler. Överföringen baseras pâ ett meddelandeorienterat protokoll, som utnyttjar en signaleringskanal för att överföra information mellan dessa enheter. Programparametrarna utnyttjas i terminalerna bland annat för att styra procedurer för olika tjänster och sänds till terminalerna inbäddade i ett parametermeddelande.

US 5 239 542 visar ett kommunikationssystem som konverterar överföringsformat och signaleringsprotokoll så att kommunikation kan ske mellan kretsar i system som härstammar från olika nät. Systemet karaktäriseras genom att en processor översätter kommunikationen till gemensamma protokolloberoende meddelanden.

I övrigt förekommer inom det aktuella tekniska området även följande publikationer.

US 5 007 080, "Communication system supporting remote operations".

US 5 073 890, "Remote agent operation for automatic call distributors EP 0 504 087, "Synchronizing asynchronous protocol interactions between peer layers in different modes of a layered communication network".

US 5 251 255, "Processing interactions among telecommunications call features US 5 184 346, "Switching system".

"Design and validation of computer protocols", Gerard J. Holzrnann, AT&T Bell Labo- ratories, PRENTICE HALL.

REDOGÖRELSE FÖR' UPPFINNINGEN Ett första syfte med uppfinningen är att, för intern kommunikation mellan tjänstestyran- de entiteter i trafikförlopp i ett telekommunikationssystem, åstadkomma ett generellt kommu- nikationsförfarande utan tillämpningsberoenden, som därmed underlättar tillägg av nya tjäns- ter, som tillhör samma eller olika telekommunikationstjänstenät.

Ett andra syfte med uppfinningen är att åstadkomma ett generellt kommunikationsförfa- 4o rande av nyss nämnt slag, som möjliggör skapande av tjänsteprotokoll, som ej innehåller till- 10 15 20 25 30 35 40 515 179 4 lämpníngslogik, och därigenom kan användas för kommunikation mellan tjänstestyrande entiteter tillhörande ett stort antal varierande telekomrnunikationstjänstenät.

Ett tredje syfte med uppfinningen är att åstadkomma ett generellt kommunikationsförfa- rande, som utnyttjar en protokollmodell, som är distribuerad snarare än monolitisk, så att till- lämpningsspecifika delar kan placeras i sin egen omgivning.

Ett fjärde syfte med uppfinningen är att åstadkomma ett generellt kommimikationsförfa- rande, som medger skapande och användning av tjänsteprotokoll med kompatibilitet framåt och bakåt, dvs. det skall vara möjligt att utvidga ett dylikt protokoll utan att befintliga delar blir felaktiga eller meningslösa.

Ett femte syfte med uppfinningen är att ersätta tidigare koncept för kommunikation mellan tjänstestyrande entiteter med en transporttjänst, som helt enkelt förflyttar information mellan likvärdiga entiteter, och därmed förbättrar kapaciteten genom reducerad hantering.

Ett sjätte syfte med uppfinningen är att åstadkomma ett generellt kommunikationsförfa- rande, som i sitt grundläggande informationsutbyte, i enlighet med ITU-T (fd. CCITT) Q.2764, har en mekanism, som anger vad en tjäristestyrande entitet bör göra med mottagen information som den ej förstår, vilket innebär att interaktionslogiken som krävs i den tjänste- styrande entiteten förenklas.

Ytterligare ett syfte är att ange ett sätt att kommunicera på, som gör det möjligt att uppdatera delar av ett telekommunikationssystem utan att behöva uppgradera andra.

Enligt en huvudaspekt av uppfinningen styrs den interna kommunikationen mellan tjäns- testyrande entiteter i trafikförlopp i ett telekommunikationssystem med hjälp av regler angivna i en generell protokollmodell.

Enligt en annan huvudaspekt hänförlig till programvarusystem för telekommunikations- system, som innehåller hårdvaru- och programvarukomponenter med bestämda funktioner, och till vilket ett flertal användare är anslutna, används för styming av den interna kommuni- kationen mellan tjänstestyrande entiteter i trafikförlopp i telekommunikationssystemet, regler angivna i en generell protokollmodell.

Enligt ytterligare en huvudaspekt hänförlig till strukturering av programvara i ett tele- kommunikationssystem som innehåller hårdvaru- och programvarukomponenter med bestämda funktioner, och till vilket ett flertal användare är anslutna, lagras i systemet, för styming av intern kommunikation mellan tjänstestyrande entiteter i trafikförlopp i telekommunikationssys- temet, programvarukomponenter baserade på regler angivna i en generell protokollmodell.

Enligt en första delaspekt är det gemensamt för ovannämnda tre huvudaspekter att reg- lerna i den generella protokollmodellen föreskriver avsaknad av meddelanden, och använd- ning endast av protokollparametrar i form av odelbara inforrnationsöverföringselement. Dessa informationselement distribueras av en kommunikationstjänst med en parameterdistributions- funktion för nämnda parametrar.

Enligt en andra delaspekt är det gemensamt för de tre huvudaspekterna att på grundval av den generella protokollmodellen specificeras tjänsteprotokoll svarande mot varsin tjänst.

Enligt en tredje delaspekt är det gemensamt för de tre huvudaspekterna att reglerna i 20 25 30 35 40 515 179 5 den generella protokollmodellen föreskriver användning av protokollparametrar i fonn av odelbara informationsöverföringselement.

Enligt en fjärde delaspekt är det gemensamt för de tre huvudaspekterna att reglerna i den generella protokollmodellen föreskriver användning av protokollparametrar, vilka dis- tribueras av en kommunikationstjänst med en parameterdistributionsfunktion för nämnda parametrar.

Enligt en femte delaspekt är det gemensamt för de tre huvudaspekterna att reglerna i den generella protokollmodellen föreskriver avsaknad av meddelanden och användning endast av protokollparametrar.

Enligt en betydelsefull utföringsform av uppfinningen specificeras på grundval av den generella protokollmodellen tjänsteprotokoll svarande mot varsin tjänst.

Företrädesvis hör till den generella protokollmodellen ett antal definierade protokollpar- ametrar, vilka utgör den minsta dataenhet, som är möjlig att överföra i tjänsteprotokollet.

Vid specificering av ett tjänsteprotokoll väljs godtyckligt ett för tjänsten lämpligt antal protokollparametrar, och nya protokollparametrar definieras vid behov. En protokollspeciñka- tion finnes för varje tjänsteprotokoll där denna innehåller en lista över sända och mottagna parametrar.

Vid en väsentlig utföringsform av uppfinningen saknar tjänsteprotokollen tillämpningslo- gik.

Företrädesvis tar en protokollhanteringsentitet inom en tillämpning hand om protokoll- hanteringen för en viss tjänst enligt tjänsteprotokollet.

Vid kommunikation mellan två tjänstestyrande entiteter överför kommunikationstjänsten data mellan protokollhanteringsentiteterna, varvid parameterdistributionsfunktionen som finns i kommunikationstjäristen anger till vilka protokollhanteringsentiteter varje protokollparameter skall sändas, och två parameterdistributionslistor används, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terminerande tjän- stestyrande entiteten.

Vid systemuppgradering laddas nya eller modifierade protokollhanteringsentiteter, vilka kommer att påverka parameterdistributionsfunktionen under exekveringen.

Tillämpningslogik beordrar protokollhanteringsentiteterna genom metoder att sända parametrar till kommunikationstjänsten varpå tillämpningslogiken beordrar kommunikations- tjänsten att sända ett meddelande.

Konfigurationen av en protokollhanteringsentitet bestäms i samband med tillämpnings- konstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

För varje protokollhanteringsentitet specificerar tilllämpningskonstruktören de paramet- rar som erfordras för att generera event till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

Ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet innehåller en specifikation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och metoder som skall skickas från tilllämpningslogiken till protokollhan- 10 15 20 25 30 35 40 515 179 6 teringsentiteten.

Vid mottagning av en parameter, eller en viss uppsättning av parametrar, från kommu- nikationstjänsten avger en protokollhanteringsentitet en event till tillämpningslogiken.

Tillämpningslogiken innehåller all logik för trafikhantering, hantering av tilläggstjänster, och interaktion mellan tjänster.

Till varje protokollparameter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsenhet skall göra med pararnetern om den ej förstås.

Kommunikationstjänsten använder en uppsättning meddelanden och en motsvarande tillståndsmaskin, vilka meddelanden ej har någon betydelse för tjänsteprotokollet och ej behö- ver vara kända av tillämpningskonstruktören.

Uppfinningen medger konstruktion av tjänsteprotokoll, som kan överleva i en omgivning med föränderliga tillämpningar. Detta sker genom att man med hänsynstagande till grunderna för kommunikation undviker att bygga in tillämpningsberoenden i protokollmodellens grund- koncept.

Uppfinningen bygger på insikten att tillämpningslogik och protokoll måste separeras.

Detta innebär i praktiken att tillståndsmaskinen för tjänsten, tidmätningsfunktion, etc. ej placeras i de funktionella enheter, som bildar tjänsteprotokollet. Endast med separeringen av tillämpningslogik och tjänsteprotokoll kan protokollet uppnå tillämpningsoberoende och där- med stödja kommunikation mellan de tjänster, som specificeras att kunna samverka i ett stort antal varierande telekommunikationstjänstenät.

Den modell på vilken protokollet är byggd är distribuerad snarare än monolitisk. Detta medger att tillämpningsspeciñka delar kan placeras i sin egen omgivning. Man kan använda protokollhanteringsentiteter, vilka var och en avser en särskild tjänst i tillämpningslogiken.

Det är genom denna distribuerade lösning och kompatibilitet framåt, dvs. möjlighet att tillföra nya tjänsteprotokoll, och bakåt, dvs. möjlighet att utveckla ett tjänsteprotokoll utan att kon- struerade tjänstestyrande entiteter behöver uppdateras, som kraven på kommunikation mellan tjänster tillhörande olika logiska noder uppfylls. Framgångsrik samverkan mellan tjänster kräver logiska beslut, varför tjänstelogiken i varje tjänstestyrande entitet måste förstå de tjänster som den kan samverka med.

En viktig mekanism för det grundläggande informationsutbytet är instruktionsindikatorer som sänds med varje protokollparameter och anger vad en mottagare skall göra med informa- tion som den ej förstår. Detta medger att varje parameter kan sändas från ett protokoll till ett annat, varigenom interaktionslogiken som krävs förenklas. Grundläggande funktioner som förkasta parameter, friställ koppel, och underrätta sändare, är möjliga. Detta täcker den erfor- drade funktionen i de flesta fall. Det bör särskilt framhållas att denna mekanism är framåt kompatibel, dvs. den kan utvecklas och vara kompatibel bakåt.

Instruktionsindikatormekanismen tillåter att parametrar vid varje tidpunkt kan tillföras tjänsteprotokollet utan att störa samarbetande tjänster, som ej har något intresse av informa- tionen. Detta i sin tur innebär att tjänster kan utvecklas utan att störa andra tjänster i syste- met. Detta underlättar tjänstutveckling och successiv införing av ny tjänst i en del av ett 20 25 30 35 515 179 7 system i drift utan att störa andra delar av systemet.

En annan aspekt som är värd att nämna är att endast data driver de tillståndsmaskiner som arbetar inom respektive tjänst. Detta innebär att det ej finns något behov av att defmiera globala tillstånd eller events som sträcker sig över flera tjänster tillhörande samma eller olika telekommunikationstjäiustenät. Tjänsteprotokollet kommer att bära de data, som varje tjänst kommer att använda för att generera sina egna tillståndsövergångar. Detta i sin tur innebär att tjänsteprotokollet självt förblir tillämpningsoberoende, eftersom inget tillämpningstillståndsbe- roende finns i själva tjänsteprotokollet.

Behovet av marknadsanpassningar hanteras på samma sätt som tjänster i övrigt, dvs. markriadsparametrar skapas för att bära marknadsinforrnation, ändringar i logik på grund av att marknadsfunktionalitet hanteras i tillämpningslogiken, och ej i protokollet. Följaktligen påverkar marknadsfunktioner endast de tjänster vilka krävs för att funktionellt stödja dem.

Tjänsteprotokoll specificeras och implementeras per tjänst, varigenom det blir lättare att lägga till och ta bort tjänster.

Sammanfattningsvis uppnår protokollet maximalast möjliga flexibilitet, genom den frihet som erbjuds i samband med utveckling av tjänster, tillförsel av nya tjänster, specificering och implementering av tjänsteprotokoll per tjänst, och avsaknad av protokollglobala meddelanden och tillstånd.

FIGURBESKRIVNING Utföringsformer av uppfinningen skall nu beskrivas närmare nedan med hänvisning till bifogade ritningar, på vilka - fig. 1 schematiskt visar ett prograinstyrt telekommunikationssystem enligt teknikens stånd- punkt, - fig. 2 schematiskt åskådliggör uppbyggnaden av en telefonstation ingående i ett telekommu- nikationssystem enligt teknikens ståndpunkt, - fig. 3 och 4 är schematiska bilder för att åskådliggöra en del i fortsättningen i samband med uppfinningen använd terminologi, - fig. 5 åskådliggör en generell protokollmodell enligt uppfinningen, - fig. 6 schematiskt åskådliggör ett exempel på protokollstrukturen i en protokollmodell enligt fig. 5, med hjälp av enkla tillståndsmaskiner, - fig. 7 mera detaljerat visar ett exempel på protokollstrukturen i ett fall där en AXE N-ISDN användaraccess interagerar med en AXE N-ISDN nätaccess, - fig. 8 visar en logisk nod i närmare detalj, åskådliggörande bl.a. interaktion mellan tillämp- ningslogik, protokollhanteringsentiteter och kommunikationstjänst, - fig. 9a och 9b visar exempel på två utgåvor av en iristruktionsindikatorbitmap, - fig. 10 visar strukturen hos en parameter ingående i protokollet enligt uppfinningen, - fig. ll åskådliggör ett nätverksexempel, i vilket en bredbands ISDN användaraccessnod måste kunna kommunicera med sig själv, med en bredbands ISDN nätaccessnod och med en smalbands ISDN användaraccessnod, 40 - fig. 12 åskådliggör hur meddelanden, som överförs av kommunikationstjänsten transporterar 20 25 30 35 40 515 179 s parametrar, som ingår i protokollet enligt uppfmningen, - fig. 13 åskådliggör uppstartningsfasen av en halvkoppelprocess, - fig. 14 åskådliggör den aktiva fasen av en halvkoppelprocess.

FÖREDRAGNA UTPÖRINGSFORMER Såsom kommer att framgå närmare nedan hänför sig uppfinningen till intern kommuni- kation mellan tjänstestyrande entiteter i trafikförlopp i ett telekommunikationssystem. Med tjänstestyrande entiteter avses här exempelvis tjänsteprocesser, som styr tjänst för en part i ett koppel. Bland typer av tjänsteprocesser som kan förekomma i ett kommunikationsnät kan nämnas trañkstyrprocesser för användaraccess och nätaccess.

Med att en tjänstestyrande entitet tillhör en logisk nod avses att den skall vara specifice- rad i den logiska noden. Dess realisering i programvara utgörs av exekverande funktioner i den logiska noden. Programvaran för de tjänstestyrande entiteterna i en logisk nod kan vara distribuerad på olika processorer styrda av ett distribuerat operativsystem. Med logisk nod avses här en grupp funktioner, som skall installeras tillsammans i ett system.

Uppfinningen är, såvida det inte av nedan mera detaljerade beskrivning framgår annor- lunda, t.ex. tillärnpbar i omgivningar av det slag, som presenteras i den ovarmämnda U.S. an- sökan 07/723,166, eller i den svenska patentansökan 9202489-2, vilka publikationer härmed är "incorporated herein by reference I fig. 1 visas ett från U.S. ansökan 07/723,166 känt mjukvarusystem, vilket t.ex. kan bilda del av AXE-systemet. Figuren visar i sin övre del en del 112 av ett telekommunika- tionsnät, som återges såsom omfattande ett flertal noder. Sättet på vilket var och en av dessa noder kommunicerar med andra noder via vissa definierade protokoll återspeglas i en i en programminnesstyrd telefonstation 114 ingående mjukvaruarkitektur, som kommer att beskri- vas närmare nedan.

Närmare bestämt visas i telekomnätdelen 112 en i ett PSTN-nät ingående nod 115 så- som exempelvis ansluten till en i ett ISDN-nät ingående nod 116, vilka båda är kopplade till en i ett privatnät ingående nod 118. Privatnoden 118 är i sin tur kopplad till en annan i ett privatnät ingående nod 120. Noden 115 kommunicerar med noden 118 via ett MFC(multi- frequency code)-protokoll 122, medan noden 116 kommunicerar med både noden 115 och noden 118 via CCITT-TUP protokoll 124 och 126. ISDN-noden 116 kan kommunicera med andra ISDN-noder via ett ISUP protokoll 128 och de i privatnät ingående noderna 120 och 118 kommunicerar med varandra via ett DPNSS protokoll 130. Till var och en av noderna 115-120 är telefonabonnenter 132 anslutna, medan noden 120 och ISDN-noden 116 även kan ha datakommunikationsabonnenter 134 anslutna.

Funktionaliteten i telekommunikationsnätet 112 innefattas i telefonstationen 114. Den gemensamma funktionaliteten för de logiska noderna 115-120 innefattas i gemensamma resur- ser 135. Telefonstationen 114 innefattar nodens 115 specifika funktionalitet i en PSTN-till- ämpningsmodul 136. På liknande sätt ingår ISDN-nodens 116 specifika funktionalitet i en ISDN-tillämpningsmodul 138, medan privatnodens 118 specifika fimktionalitet ingår i en till- ämpningsmodul 140. Tillämpningsmodulema 136-140 innehåller tjänstehanterande datapro- 10 15 20 25 30 35 40 515 179 9 gram och är avsedda att tillhandahålla telekommunikationstjänster för användare anslutna till telefonstationen 114. Varje tillämpningsmodul innehåller styrinstruktioner och data som im- plementerar den specifika funktionaliteten för en viss nodtyp.

Tillämpningsmodulema 136-140 visas såsom kommunicerande med varandra via proto- koll, såsom ett internt T UP-protokoll 142, ett internt MFC-protokoll 143, och ett internt DPNSS-protokoll 144. De gemensamma resurserna 134 utnyttjas via gränssnitt 146.

I fig. 2 visas en programminnesstyrd telefonstation 212 av det slag, som t.ex. framgår av ovannämnda svenska patentansökan, som likaledes t.ex. kan bilda del av AXE-systemet och som kan användas i ett kommunikationssystem enligt ovannämnda US-ansökan.

Telefonstationen 212, i detta fall en lokalstation, innefattar en dator 214, som styr kopp- lingsutrustning. Kopplingsutrustningen består av ett abonnentgränssnitt 216, väljarutrustning 218, och ett trunkförbindelsegränssnitt 220. Väljarutrustningen 218 kan koppla telefonkanaler för telefonsamtal mellan abonnentgränssnittet 216 och trunkförbindelsegränssnittet 220. Da- torn 214 styr signalering från en abonnent 222 via en abonnentledning 224 och abonnent- gränssnittet 216 till lokalstationen 212. Datorn 214 styr på samma sätt på trunksidan uppkopp- ling av trunkkretsar 226 via trunkförbindelsegränssnittet 220 till väljarutrustningen 218. Dess- utom har datorn 214 ett gränssnitt 228 till ett signalnät via signaleringsförbindelser 230.

Gränssnittet 228 kallas vanligen signalterminal.

I datorn 214 körs ett antal datorprogram, som har olika funktioner i telefonstationen såsom att styra uppkoppling av samtal eller underhållsfunktioner exempelvis för att hämta ut taxeringsinforrnation. Via signalterminalen 228 kan dessa program signalera med program i andra telefonstationer.

Datorprogrammen innefattar närmare bestämt två grupper av program, nämligen dels en fórbindelsehanterande grupp 232 och dels en tjänstehanterande grupp 234. De två grupperna har olika protokoll, nämligen för gruppen 232 ett protokoll 236 och för gruppen 234 ett pro- tokoll 238. I ett telefonnät, i vilket ett antal stationer av det beskrivna slaget ingår, etablerar de tjänstehanterande programmen 234 i två stationer, som hanterar varsin abonnent, direkta protokoll 238 mellan sig. På samma sätt kommer de förbindelsehanterande programmen 232 att kommunicera från station till station med hjälp av protokollet 236. Övriga detaljer rörande telekommunikationssystem, som uppfinningen kan tillämpas i, kan som exempel hämtas från ovannämnda US-ansökan eller svenska patentansökan, och kräver följaktligen ingen närmare beskrivning här.

Enligt föreliggande uppfmning styrs den interna kommunikationen mellan de i logiska noder ingående tjänstestyrande entiteterna med hjälp av regler angivna i en generell protokoll- modell, nedan benämnd TSPM (Telecommunication Services Protocol Model). Dessa regler föreskriver avsaknad av meddelanden, och användning endast av protokollparametrar i fonn av odelbara informationsöverföringselement, vilka nedan kommer att benämnas TSPM-defini- erade parametrar. En TSPM-definierad parameter är den minsta dataenhet, som är möjlig att överföra enligt TSPM. De TSPM-definierade parametrarna distribueras av en kommunikation- stjänst, nedan benämnd ITS (Infonnation Transfer Service), med en parameterdistributions- 15 20 25 30 35 515 179 io funktion för dessa parametrar.

På grundval av den generella protokollmodellen TSPM specificeras tjänsteprotokoll, som svarar mot varsin tjänst, och nedan benämns ASP (Application Service Protocol). Vid tillämpning av uppfinningen i miljön enligt fig. 1 skulle flera tjänsteprotokoll ASP ersätta ett internt protokoll, t.ex. det interna TUP-protokollet 142 vad avser kommunikationen mellan de i tilllämpningsmodulerna 136, 138 och 140 ingående tjänstehanterande programmen. På lik- nande sätt skulle i miljön enligt fig. 2 den interna kommunikationen mellan de tjänstehante- rande datorprogrammen 234 liksom den interna kommunikationen mellan de förbindelsehante- rande datorprogrammen 232 ske via täristeprotokoll ASP enligt uppfinningen.

En protokollhanteringsentitet, nedan benämnd ASPE (Application Service Protocol Entity), tar hand om protokollhanteringen för en viss tjänst enligt tjänsteprotokollet ASP.

Tjänsteprotokollet ASP används för samverkan mellan ASPEzer, och av detsamma framgår vilka TSPM-definierade parametrar, som skall överföras.

Den närmare beskrivningen nedan av utföringsformer av uppfinningen kommer att ske stegvis på ett sätt, som i och för sig kan innebära upprepanden, men även klargör sambandet mellan olika aspekter av uppfmningstanken. Vidare kommer som exempel uppfinningen i vissa fall att beskrivas med speciell inriktning på användning i AXE-systemet, ehuru den även är generellt tilllämplig i andra omgivningar. Vad beträffar AXE-systemet förekommer i detta vissa begrepp, som kommer att identifieras och användas i fortsättningen.

Till att börja med skall här bl.a. de ovan nämnda begreppen TSPM, ASP, ASPE, och ITS åskådliggöras något utförligare med hänvisning till fig. 3 och 4.

Protokollmodellen TSPM antas i exemplet enligt fig. 3 och 4 visa typen av internkom- munikation för AXE. Med hjälp av de av TSPM föreskrivna reglerna definieras ASPzer, som används för kommunikation mellan halvkoppelprocesser. Halvkoppelprocesserria hör till samma eller olika telekommunikationsnät.

ASPE:er implementeras som protokollobjekt i en halvkoppelprocess. I fig. 3 antyds tvâ uppsättningar ASPEzer vid 302 resp. 304, varvid ASPEzerna 302 visas såsom ingående i en logisk nod 306.

Begreppet protokollobjekt definieras i AXE-systemet som en objekttyp som innehåller beteendet hos ett kommunikationsprotokoll för kommunikation mellan delsystem. Ett exempel på ett protokollobjekt är en objekttyp, som representerar ett yttre protokoll såsom TUP (Te- lephone User Part) eller SCCP (Signalling Connection Control Part).

Protokollobjekt utgör del av de i systemet ingående objekttyperna. De gör det lättare att förstå delsystemet eftersom de klargör dess gränser och ger en klar bild av delsystemets gränssnitt.

Vidare definieras i AXE-systemet begreppet halvkoppelprocess som en realtidsmiljö avsedd att styra ena parten av ett koppel. Halvkoppelprocessomgivningen, som består av heap, stack och exekveringsfunktioner, är begränsad till en viss processor. I fig. 3 antyds vid 308 en uppsättning tjänstestyrande entiteter i form av AL-funktionaliteter (AL = Application 4o Logic) i den logiska noden 306, samt en amian uppsättning vid 310. Med AL avses här, i 20 25 30 35 515 179 11 samband med föreliggande uppfinning, tillämpningslogiken för en tjänst, dvs. i föreliggande fall en tjänstestyrande entitets logik. AL-funktionaliteter innehåller för motsvarande tjänst tillämpningslogik av typen trafikhantering, hantering av tilläggstjänster, interaktion mellan tjänster etc.

AL implementeras som ett antal trådar i en halvkoppelprocess. En tråd är en exekve- ringsbana i en halvkoppelprocess med en programpekare och stack. Det kan finnas flera trådar inom en halvkoppelprocess. De delar alla på samma heap och statiska data. En tråd kan inställa sig själv att vänta på en eller flera halvkoppelprocessevents för att därigenom låta en annan tråd starta eller återta exekvering.

Kommunikationstjänsten ITS markeras i fig. 3 med ett block 312. Den överför data mellan ASPE-uppsättningarna 302 och 304. Kommunikationstjänsten ITS innehåller en param- eterdistributionsfunktion, som anger till vilken eller vilka ASPE:er varje parameter skall sändas. Parameterdistributionsfunktionen kan vara i form av en lista benämnd PDL (Parame- ter Distribution List) i nedanstående exempel. Varje parameter kan sändas till en eller flera ASPE:er. De i fig. 3 visade pilarna mellan de olika funktionalitetema antyder kommunika- tionsbanor.

Med hänvisning till fig. 4 har TSPM använts för att konstruera ASPE:er för kommuni- kation mellan logiska noder. I figuren är ett N-ISDN tjänstenät betecknat med 402 och ett annat tjänstenät med 404. Typiska logiska noder är N-ISDN nätaccess vid 406, N-ISDN an- vändaraccess vid 408. En logisk nod i tjänstenätet 404 betecknas med 410. Ett enligt TSPM definierat tjänsteprotokoll kan uppställas mellan logiska noder, som hör till olika tjänstenät, men även mellan logiska noder, som tillhör samma tjänstenät. Detta åskådliggörs i tig. 4 där den logiska noden 410 ingående i tjänstenätet 404 har TSPM-anslutningar 412 och 414 till de logiska noderna 408 och 406 i tjänstenätet 402. Mellan de logiska noderna 406 och 408 finns det en TSPM-definierad kommunikation 416.

I realtid kommunicerar tjänstestyrande entiteter i logiska noder via ett antal ASPzer mellan samverkande tjänster. Med varje ASP överförs TSPM-definierade parametrar. Specifi- cering och implementeringar görs av tillämpningskonstruktörer. TSPM möjliggör att en eller flera nya ASP:er kan tillföras varje logisk nod utan anpassning av existerande ASP:er. I föreliggande fall kommer begreppet "halvkoppelprocess" att användas i samband med beskriv- ning av exekvering. Annars kommer det mer generella begreppet logisk nod att användas för att beskriva en tjänsts distribution och dess kommunikation via dess ASP:er.

Med hänvisning till fig. 5 kommer nu en generell protokollhanteringsmodell, i vilken uppfinningen tillämpas, att beskrivas. Den innehåller följande funlctionaliteter.

AP-funktionalitet (Application Process), som innehåller all tjänstelogik hänförlig till en viss logisk tjänstenod, dvs. flera AL-ftniktionaliteter. I fig. 5 visas som exempel två AP- fllnktionaliteter vid 502 resp. 504.

AL-funktionaliteter, som ingår i AP-funktionaliteten och innehåller logik hänförlig till var sin tjänst, t.ex. Call Control och Closed User Groups (CUG). AL-funktionalitetema 40 bildar tjänstestyrande entiteter 506,508 och 510,5 12, vilka ingår i varsin av AP-funktionalite- 10 15 20 25 30 35 40 515 179 12 tema 502 resp. 504.

Två tillämpningsprotokolldelar 514 resp. 516 innefattar vardera som exempel vid 518 resp. 520 två uppsättningar ASPE-funktionaliteter, liksom vardera en ACSPE-funktionalitet 522 resp. 524.

Varje ASPE innehåller signaleringsstöd för en viss tillämpningslogik AL, vilket signale- ringsstöd antyds som exempel vid 526,528 resp. 530,532 för ASPE-uppsättningarna 518 resp. 520.

Funktionaliteten ACSPE (Application Common Service Protocol Entity) innehåller protokolltillstândsmaskínen och utför uppackning/nedpackning av parametrar för ett visst pro- tokoll, dvs. distribution och insamling av tagg-märkta data till och från relevant ASPE. Det senare antyds vid 534 resp. 536 för ASPE-uppsättningarna 518 resp. 520. Om en tagg är okänd sänds parametern till en separat ASPE. Det skall inte förekomma någon vidareutveck- ling av ACSPE vid anslutning av ytterligare ASPE:er, utan distributions-/samlingstabeller i ACSPE kommer helt enkelt bara att kräva uppdatering.

Lågnivåprotokollentiteter 538 resp. 540, LLP (Low Layer Protocols), innehåller icke- tillämpningsberoende protokoll såsom Q.921, MTP, SCCP och motsvarande AXE-interna lågnivåprotokoll.

Tjänsteprotokollet ASP beskriver informationsflödet, som består av parametrar, mellan tvâ ASPE:er, antytt vid 542 resp. 544.

Ett protokoll ACSP (Application Common Service Protocol) beskriver både syntax och inforrnationsflöde mellan ACSPE:er, antytt vid 546.

Med hänvisning till fig. 6 skall nu ett enkelt exempel på protokollstrukturen i TSPM åskådliggöras, grundad på beskrivningen ovan av protokollhanteringsmodellen i fig. 5. Såsom kommer att framgå är tjänsteprotokollet för en ASPE synnerligen enkelt eftersom protokoll- tillståndsmaskinen innehåller endast ett tillstånd, nämligen "AKTIV". Detta resulterar i att protokollet endast utgörs av en lista med parametrar, som sänds respektive mottages. Pro- tokolltillståndsmaskinen för en tillämpningslogik AL är en mer komplett tillståndsmaskin, som kommer att spegla trafikavverkningen som äger rum över protokollet.

För enkelhetens skull är den AP-funktionalitet, som motsvarar AP-funktionaliteten 504 i den högra halvan av fig. 5 utelämnad i fig. 6. I den vänstra halvan av fig. 6 representeras de båda tillämpningslogikfunktionaliteterna 506 och 508 i fig. 5 av block 602 och 603. I övrigt visas två ASPE-funktionaliteter 604 resp. 606 med tillhörande relationsanknytningar 608 resp. 610 till tillämpningslogikfunktionalitetema 602 och 603. ASPEzerna 604 och 606 antas ta hand om protokollhanteringen för bastjänsten 'CallControP resp. tilläggstjänsten 'CallingLine- IdentificationPresentation'. Dessa som exempel angivna benämningar på varsin tjänst, liksom övriga i fig. 6 förekommande benämningar på parametrar är av ett slag, som motsvaras av parametrar tillhörande ISDN, som är välbekant för fackmannen inom telekommunikation- stekniken, jfr. exempelvis CCITT. De kräver därför ej någon närmare förklaring här.

I fig. 6 får vidare den övre pilen 601 allmänt representera kommunikationen mellan 10 15 20 25 30 35 515 179 13 tillämpningslogiken AL 508 och 510 i ñg. 5. Över denna pil åskådliggörs ett exempel på till- ståndsmaskinen för tillämpningslogiken AL. Därvid betecknas tillståndet 'idle' med I, tillstån- det 'call attempt' med C, tillståndet 'end state' med E, samt tillståndet 'active' med A. Över pilarna 612 och 614 visas, bredvid en symbol för respektive entillstånds tillståndsmaskin, ASPEzernas 604 och 606 respektive protokoll, som i det första fallet utgörs av den visade listan med parametrar, som sänds och mottages, och i det andra fallet av den visade enda parametern, som sänds. Även vad avser det som, på i och för sig välkänt sätt, symboliseras av de som exempel här visade tre protokollen, inser fackmannen inom telekommunikationsornrådet vad detta innebär. Inte heller här krävs därför någon närmare förklaring.

I fig. 7 visas för en som exempel vald AXE-irnplementation, med samma uppbyggnad som i fig. 5, protokollstrukturen i ett fall där en N-ISDN användaraccess 730 interagerar med en N-ISDN nätaccess 732. De två AP-ftniktionaliteterrxa visas vid 702 resp. 704. Vid 706,708 och 7l0,7l2 visas som exempel två AL-funktionaliteter ingå i vardera AP-funktionaliteten 702 resp. 704.

De två AP-funktionaliteterna interagerar enligt TSPM-specificerade ASP-protokoll 733.

Underliggande protokollnivåer visas vid 734. Vid 718 och 722 visas ACSPE i respektive till- ämpningsprotokoll. ACSPE benämns ITS i fallet TSPM, betecknat med 720 resp. 724. Lågni- våprotokollet i fallet N-ISDN användaraccess är Q.92l och för N-ISDN nätaccess är det MTP, betecknat med 726 resp. 728.

Lågnivåprotokollentiteter 726 resp. 728 innehåller icke-tillämpningsberoende protokoll Q.92l resp. MTP.

Med hänvisning till fig. 8 består den resulterande TSPM-implementationen av en upp- sättning ASPE:er 802, 804, 806, 808, vilka ingår i en logisk nod 810, och var och en hante- rar protokollet för en viss tjänst, styrt av AL-tillämpningslogik 812, 814, 816 resp. 818.

ASPE-indelníngen bestäms i samband med AL-tillämpningskonstruktionen. Strukturen är ej känd av andra logiska noder, ett fakturn som ökar konstruktionsmodulariteten.

AL-tillämpningskonstruktören beskriver protokolltillståndet för den ifrågavarande tjäns- ten, samt konstruerar ASPE:er och AL. ITS är generisk. Tillståndsmaskinen för tjänsten placeras i AL-tillämpningslogiken 812, 814, 816 resp. 818. I realtid instansieras ASPE:er av ITS-kommunikationstjärist vid behov. ASPE:erna kan betraktas som enkla parameterdistribu- törer, och har inget kategoriberoende.

När en halvkoppelprocess skapas, skapas en instans 820 av ITS. En implementation av ITS kommer att ha två parameterdistributionsfunktioner inom en halvkoppelprocess, nämligen en funktion som används för det originerande halvkopplet, och en som används för det termi- nerande halvkopplet.

ITS-instansen 820 använder en parameterdistributionsfunktion 822 för att kunna dis- tribuera de mottagna parametrarna till rätt ASPE. I fig. 8 antyds funktionen 822 för detta ändamål att bestå av två listkolurnner 824 och 826, innehållande parametrar resp. motsva- 40 rande ASPE:er. 10 15 20 25 30 35 40 515 179 14 Den logiska noden 810 kommunicerar via ett antal ASP:er 802-808, antytt vid 828, där vart och ett terminerar i varsin av de fyra ASPE:ema. När ett meddelande mottages distribue- rar ITS-instansen 820 parametrarna till ASPE:erna enligt PDL 826. När meddelanden skall sändas används inte PDL. ASPEzerna sänder närmare bestämt ned parametrar till ITS-instan- sen, och därpå beordrar AL-tillämpningslogiken 812-818 ITS-instansen att sända ett med- delande innehållande ett antal parametrar.

Funktionaliteten hos den logiska noden 810 som kommunicerar via ASPzer visas såsom exempel vara uppdelad i fyra tjänster, en per ASPE 802-808: Call control CC, Call forward- ing CF (innefattande alla olika tilläggstjänster som hör ihop med Call forwarding), UUS (signalering användare till användare) resp. CUG (Closed User Group). För varje tjänst finns det en ASPE, som har en originerande del och en terminerande del. Vid 830 i den logiska noden 810 antyds entiteter för hantering av yttre protokoll.

TSPM anger en protokollstruktur, som nu skall beskrivas närmare.

Såsom nämnts tidigare föreskriver TSPM:s regler avsaknad av meddelanden, vilket innebär att det inte förekommer några meddelandeni ett TSPM:baserat ASP-protokoll. Det enda sättet att överföra information är via TSPM-definierade parametrar. Både koppelinfor- mation, t.ex. uppringda partens nummer, och event, såsom "svar" och "koppla ned", måste överföras via parametrar. Det finns inga obligatoriska parametrar.

De data som är möjliga att överföra enligt TSPM är uppdelade i en uppsättning odelbara parametrar.

Varje utgåva av TSPM skall innehålla ett antal globala parametrar, som definieras och beskrivs i en referensmanual för applikationskonstruktörer. Dessa globala TSPM-definierade parametrar kan och bör i så stor utsträckning som möjligt användas av alla tillämpningar.

Referensmanualen uppdateras vid behov vid varje ny utgåva av bassystemet.

Om uppsättningen parametrar i TSPM-referensmanualen ej är tillräcklig, är det möjligt att skapa lokala TSPM-definierade parametrar. Behov av nya TSPM-definierade parametrar kan uppstå på grund av att en ny tjänst behöver överföra en ny datatyp. En marknad skulle även kunna behöva en marknadsspeciñk parameter. De lokala TSPM-definierade parametrar- na måste definieras och beskrivas i lokala referensmanualer för applikationskonstruktörer.

Endast den tillämpning/marknad som skapade de lokala TSPM-definierade parametrarna kan använda dem. Om det förefaller möjligt att andra tillämpningar skulle vilja använda en lokal TSPM-definierad parameter bör denna göras till global TSPM-definierad parameter så snart som möjligt.

Om nya parametrar skapas, vilka baserar sig på gamla, bör relationen mellan den gamla och den nya parametem anges i TSPM-referensmanualen (eller den lokala TSPM-manualen).

Med varje parameter som sänds via ett ASP, ingår en instruktionsindikator, som anger vad den mottagande logiska noden bör göra med parametem om den ej förstås. Exempel på instruktionsindikatorer är: - Rapportera tillbaka - Förkasta parametem 20 25 30 35 40 515 179 15 - Friställ kopplet En tillämpning kan inte skapa sina egna instruktionsindikatorer. Uppsättningen instruk- tionsindikatorer kan endast utvidgas vid nya T SPM-utgåvor.

Allmänt är instruktionsindikatorer en mekanism som används vid kompatibilitetsproce- durer för hantering av okänd infonnation. Denna information kan på ett protokoll såsom BISUP vara ett meddelande, en parameter i ett meddelande eller ett värde i en parameter. För TSPM kan okänd information ha forrnen av endast en parameter om det rör sig om samver- kan mellan halvkoppelprocesser.

För att avgöra ett korrekt uppförande måste en nod känna till huruvida den verkar som transitnod eller slutnod innan instruktionsindikatorerna tolkas.

Okänd information skall skickas vidare från ett nät-accessprotokoll till ett annat nätac- cessprotokoll, t.ex. N-ISUP endast om protokollen har samma funktionella möjlighet. Okänd information får emellertid inte skickas vidare på ett användaraccessprotokoll, t.ex. DSS1. I det fallet att minst ett av de externa protokollen är ett användaraccessprotokoll har alltså kopplet slutnodtolkning och ej transitnodtolkning.

Instruktionsindikatorer har definierats för användning i både bredbands och smalbands nätaccessprotokoll. Användaraccessprotokollet för B-ISDN stödjer endast en underavdelning av dessa indikatorer på grund av protokollets natur och den förbindelsesektion över vilken den verkar.

Instruktionsindikatorerna definieras som separata fält för varje funktion snarare än som absolutvärden så att nya fält kan tillföras och fortfarande samverka med äldre noder utan att förorsaka kompatibilitetsproblem. Äldre noder tittar endast på de fält de känner till. När nya fält definieras måste därför de existerande fälten ställas på sådant sätt att en acceptabel funk- tion uppnås vid en äldre nod, som ej tittar på de nya fälten.

Antag exempelvis med hänvisning till fig. 9a att instruktionsindikator-bitrriappen är sex bitar lång. När endast bit fyra 1-ställs är betydelsen av instruktionsindikatorn att en notifika- tion skall sändas tillbaka om pararnetern inte förstås. Antag vidare att det för nästa utgåva behövs ett nytt instruktionsindikatorvärde, nämligen: ange bakåt om parametern ej förstås, men gör inte detta om kopplet befmner sig i nedkopplat tillstånd. Detta värde kan kodas genom att förlänga bitmappen från sex till åtta bitar enligt fig. 9b. Det nya värdet kan då anges av en bitmappkombination med bitarna sju och fyra l-ställda. Därigenom erhålles sålunda ett tillfredsställande resultat både med sexbitmappen och med ättabitmappen.

Ett enligt TSPM specificerat ASP-protokoll är meddelandelöst, varför endast instruk- tionsindikatorer hänförande sig till parametrar krävs.

TSPM måste även innehålla regler för att kunna stödja funktioner dikterade av instruk- tionsindikatorer som används på yttre protokoll: a. Tillåt okända parametrar att transparent överföras mellan två externa protokoll. b. Tillåt okända meddelanden att transparent överföras mellan två externa protokoll. c. Det originerande/inkormnande halvkopplet måste känna till typen av terrninerande/utgående halvkoppelprocess med vilket det kommer att samverka mycket tidigt (innan information 15 20 25 30 35 40 515 179 16 sänds till det andra halvkopplet), så att det känner till huruvida det skall verka som en transit- eller slutnod, och om det rör sig om en slutnod, huruvida vidaresändning är möjlig eller inte. d. Det terrninerande/utgående halvkopplet måste känna till typen av originerande/inkommande halvkoppelprocess med vilket det har samband (innan information sänds till det andra halv- kopplet) så att det känner till huruvida det skall verka som transit- eller slutnod, och om det rör sig om en slutnod, huruvida vidaresändning är möjlig eller ej.

För att svara mot dessa krav definieras ett antal parametrar för TSPM: a. Typen originerande halvkoppelprocess. Denna parameter skall sändas framåt i ett ITS startmeddelande och ange för det terrninerande halvkopplet vilken typ det originerande halv- kopplet är, t.ex. N-ISDN användaraccess, B-ISDN nätaccess. Denna infonnation används av det terrninerande halvkopplet för att känna till huruvida det originerande halvkopplets okända meddelanden och parametrar kan skickas vidare. b. Okänt yttre meddelande. Denna parameter kan sändas i ett ITS-meddelande om en halv- koppelprocess har mottagit ett okänt meddelande från sitt yttre protokoll och har avgjort att det bör skickas vidare till det samhörande halvkopplet. Beslutet att skicka vidare baserar sig på undersökning av yttre protokollinstruktionsindikatorer och kännedom om att det samhöran- de halvkopplet kan skicka vidare meddelanden från det egna halvkopplets yttre protokoll. Det yttre meddelandet innefattande instruktionsindikatorer, namn och längd ingår som en del av denna parameter. c. Okänd yttre parameter. Denna parameter kan sändas i ett ITS-meddelande om en halvkop- pelprocess har mottagit en okänd parameter från sitt yttre protokoll och har avgjort att den bör skickas vidare till det samhörande halvkopplet. Beslutet att skicka vidare baserar sig på undersökning av yttre protokollinstruktionsindikatorer och kännedom om att det samhörande halvkopplet kan skicka vidare meddelanden från det egna halvkopplets yttre protokoll. Den yttre parametern innefattande instruktionsindikatorer, namn och längd ingår som en del av denna parameter.

Den analys som utförs i det originerande/inkommande halvkopplet ger ett resultat, som anger den utgående/terrninerande halvkoppelprocesstypen. Detta tillåter att det originerande/ inkommande halvkopplet kan avgöra om det terrninerande/utgående halvkopplet kan skicka vidare sina okända meddelanden och parametrar.

Varje halvkoppelprocess måste ha en tabell, som anger andra halvkoppelprocesstyper, som kan skicka vidare sina okända meddelanden och parametrar. Denna tabell kontrolleras när det andra halvkopplet är känt. Det måste vara möjligt att uppdatera dessa tabeller om nya halvkoppelprocesser tillförs till systemet.

Med hänvisning till tig. 10, som visar strukturen hos en TSPM-defmierad parameter, kan parametern innehålla ett antal fält. I det visade exemplet utgörs dessa fält av ett fält 1002 för parameternamn, ett fält 1004 för en längdindikator för parametern, ett fält 1006 för in- struktionsiridikatorerna. Vidare kan det fmnas ett eller flera ytterligare fält, exempliñerade vid 1008 och 1010, vilka vart och ett har ett värdeområde med en särskild betydelse. Ett exempel är parametern 'Address information' med fältet 'Type of Number”. Värdeområdet kan vara 15 20 25 30 40 515 179 17 något enligt följande: - 0 = okänt , - 1 = lokalt t' - 2 = nationellt Vid utveckling av en tjänst skall det finnas bestämda krav på att denna tjänst skall vara i stånd att interagera med samma typ av tjänst i andra logiska noder. Eftersom tjänster i dessa andra logiska noder emellertid skulle kunna vara uppdaterade, eller det kan uppträda nya logi- ska noder, måste det alltid fmnas stöd för att hantera okända parametrar.

Som en hjälp för att hantera oväntade parametrar används den tidigare beskrivna in- struktionsindikatorn i anslutning till varje parameter. lnstruktionsindikatorn, som sätts av den sändande logiska noden, föreslår åtgärder som skall utföras om parametern ej förstås av den mottagande logiska noden.

När en parameter mottages, som ej är väntad av någon ASPE, sänder ITS parametern till en UP ASPE, där UP står för "Unrecognized parameter", vilken är ASPE för signalering, som inte förstås.

Följande exempel på interaktion kan nämnas.

- Om en terminerande halvkoppelprocess begär A-numret från en originerande halvkoppelpro- cess, och finner att begäran ej förstås, bör det vara möjligt att fortsätta utan presentation av A-numret.

- Om den andra logiska noden befinnes vara "för inkompatibel", bör kopplet frigöras. Detta kan t.ex. vara fallet om den andra sidan ej förstår en väsentlig parameter som "connect", "B- nummer", etc.

- Om en smalbandig logisk nod erhåller en begäran att ställa upp en bredbandsanslutning, bör den tillbakavisa koppelförsöket.

Med hänvisning till fig. 11 kan som exempel ett AXE telekommunikationssystem bestå av en smalbandig ISDN nätaccessnod 1102, en bredbandig ISDN nätaccessnod 1104 och en bredbandig ISDN användaraccessnod 1106. När ett anrop görs från en abonnent i användarac- cessnoden 1104, påbörjas en halvkoppelprocess. Denna halvkoppelprocess kommer att kom- municera via ett antal ASP mot en annan halvkoppelprocess i nätverket. I detta exempel kan detta ske mot vilken som helst av de tre noderna, inklusive noden 1106 själv, det senare antytt vid 1108. Samma ASPE-uppsättning hos användaraccessnoden 1106 används vid kom- munikation med de andra logiska noderna.

Att anbringa samarbetet i de logiska noderna leder i och för sig till extra arbete för tillämpningama. Fördelen är emellertid större genom att man undviker behov av en centrali- serad och komplex entitet, som skall hantera alla typer av interaktion och måste uppdateras närhelst en logisk nod uppdaterats. I ett fall som nätverksexemplet i fig. 11 måste konstruk- tionen av var och en av de tre logiska noderna kunna vara oberoende av de andras konstruk- tion. Det bör även vara möjligt att uppdatera/omkonstruera en av de logiska noderna utan att studera den inre strukturen hos de andra logiska nodema och utan att uppdatera dem.

I tig. 12 åskâdliggörs hur två logiska noder, markerade genom motsvarande ASPE- 515 179 18 uppsättningar 1202 och 1204, via ITS-instanser 1206 resp. 1208 utbyter TSPM-deñnierade parametrar 1210, 1212, 1214, 1216 transporterade av ITS-meddelanden 1218 och 1220.

ITS använder en liten uppsättning av meddelanden och en motsvarande enkel tillstånds- maskin. ITS-meddelandena har ingen betydelse för ASP-protokollet och behöver ej vara kända av tillämpningskonstruktören. ITS använder en underliggande dialogtjänst.

I fig. 13 visas uppstartningsfasen för en halvkoppelprocess. ASPE:er och styrlogik kan anropa ITS-metoder via ett gränssnitt. Alla ASPE:er kan t.ex. härledas från en C++ -bas- klass för ASPE-protokollobjekt, varvid ITS kan anropa metoder i ASPE:er via ett annat gränssnitt för att distribuera från andra sidan erhållna parametrar.

När ett uppkopplingsförsök uppträder ställer en start-funktion upp en dynamisk process 1302 för det originerande halvkopplet. Först skapar en exekveringstråd, pil 1304, den origi- nerande koppelstyrlogiken 1306. Redan vid instansiering utför den originerande koppelstyrlo- _ giken flödesbindning, pilar 1308, 1310, där den avgör vilka utvidgningsflöden, exemplifiera- 20 25 30 35 40 de vid 1312 resp. 1314 som tilläggstjänster CLIP (Calling Line Identification Presentation) resp. SUB-addressing, som skall tillåtas att adderas till koppelstyrlogikens 1306 grundflöde.

Koppelstyrlogiken 1306 instansierar, pil 1316, ITS 1318 när adressinforrnationsanalys har visat mot vilket system uppkopplingsförsöket är riktat. När ITS 1318 startas kan koppel- styrlogiken 1306 instansiera, pil 1320, sin ASPE 1322. ASPE:en 1322 erhåller pekare till ITS 1318, antingen från sin styrlogik 1306 eller genom att läsa i en halvkoppelspecifik databas.

När ASPE:en 1322 instansieras länkar den sig själv, pil 1324, till ITS 1318 och skickar på samma gång en lista över vilka parametrar den önskar abonnera på när meddelanden mottages från den terrninerande sidan. Länkningen mot ITS sker med en metod °subscribeParameters'.

Parametrar som skall transporteras mot den terrninerande sidan sänds till ITS 1318 från ASPE 1322 genom en metod 'prepareParametersï När utvidgningsflödena 1312 och 1314 tar över exekveringen kan de även skapa, pilar 1326 resp. 1328, sina egna ASPE:er 1330 resp. 1332, som likaledes länkas, pilar 1334 resp. 1336, till ITS 1318, samt abonnera på parametrar från ITS och överföra parametrar till ITS.

I ñg. 13 anger de vid varje flödespil även anbringade talen 1-10 ordningsföljden för de respektive allokeringsanropen.

Naturligtvis behöver alla tjänster som behöver överföra TSPM-definierade parametrar i det första meddelandet mot den terrninerande sidan skapa ASPE:er och länka till ITS under halvkoppelprocessens första jobb. Andra tjänster, såsom COLP (Connected Line Identification Presentation), kan ställa upp sin ASPE senare.

När startfunktionen på den terrninerande sidan skapar halvkoppelprocessen på denna sida, instansieras styrlogiken för koppelstyrning. Den skapar därpå en ITS-instans och en AL- instans på samma sätt som på den originerande sidan. Tjänsterna som kan mottaga parametrar i det första meddelandet mot den terrninerande sidan måste instansieras tillsammans med sina ASPE:er vid start av halvkoppelprocessen. Därefter uppställs resten av kontrollogiken och ASPE:er såsom på den originerande sidan.

Vid instansiering kommer ITS ej att ha någon kännedom om den halvkoppelprocess i 10 20 25 30 35 515 179 19 vilken den skapats. Den kommer att mottaga dirigeringsinformation från koppelstyrlogiken och även objektpekarna för alla ASPEzersom skall distribuera parametrar.

Allt eftersom ITS erhåller information om parameterdistributionen kommer den att dynamiskt bygga upp sin parameterdistributionslista PDL.

Med hänvisning till fig. 14 skall nu ett exempel på den aktiva fasen av en halvkoppel- process beskrivas. I en halvkoppelprocess 1402 implementeras AL som trådar 1404 och ASPE:er 1406, 1408 som protokollobjekt.

När ITS 1410 mottager ett meddelande anropar det en generell metod 1412, 1414 till ASPE:ema 1406, 1408, såsom anges i parameterlistan PDL. ASPE:erna identifierar paramet- rarna och tolkar deras ingående data. När en parameter, eller en viss uppsättning av paramet- rar, mottages från ITS, avger en ASPE 1406 eller 1408 en event 1416 resp. 1418 till AL 1404.

När ett meddelande skall skickas beordrar trådarna 1404 ASPE:err1a, genom metoder 1420 resp. 1422, att sända parametrar till ITS 1410. Därpå beordrar, 1424, en tråd 1404 ITS 1410 att sända ett ITS-meddelande. ITS-instansen 1410 kommer att använda en adresspunkt som port, antj/tt vid 1426, för att utväxla ITS-meddelandena.

Här följer nu avslutningsvis ett praktiskt exempel på användning av sättet enligt upp- finningen för internkommunikation. Därvid skall tjänsten COLP användas som åskådningsex- empel. Denna tjänst gör det möjligt för anropande abonnent att se vilken abonnent som accep- terar anropet. På grund av att olika vidarekopplingstjänster kan invokeras under koppelupp- sättningen, behöver inte den abonnent som accepterar anropet vara densamma som den till vilken anropet var ställt.

När en tillämpning skall använda sig av tjänsten COLP används två TSPM-definierade parametrar: COLP-förfrågan och COLP-nummer. Om dessa inte redan finns i TSPM-bibliote- ket, måste de skapas. För att tjänsten ska fungera måste det finnas en tjänstestyrande entitet för varje trañksida av kopplet.

Vid anropets början överförs parametem COLP-förfrågan från anroparens sida av kopp- let till den andra sidan. När och om anropet accepteras skickas den TSPM-defmierade para- metem COLP-nummer mot den anropande abonnenten.

Följande kan noteras beträffande exemplet ovan: - Protokollet har utökats genom tillägget av de två ovannämnda TSPM-deñnierade pararnet- rama.

- Protokollet finns tillgängligt för alla tillämpningskonstruktörer.

- Protokollet innehåller inte någon tillämpningslogik, dvs. i protokolldokumentationen be- skrivs inte om parametrarna är nödvändiga för tjänsten, och i vilken ordning eller gruppering de ska sändas. Detta, som dock är nödvändigt för att tjänsten ska fungera, fmns specificerat och implementerat i tillämpningslogiken (AL).

- Då den ovan beskrivna tjänsten inte är nödvändig för att kopplet ska kunna slutföras, bör de till parametrarna tillhörande instruktionsindikatorerna sättas till "förkasta parametern". 40 - Genom sättningen av instruktionsindikatom enligt ovan kommer tjänsten att kurma introdu- 515 179 zo ceras successivt i nätet. Tjänsten kommer att fungera om och endast om tjänsten är introduce- rad i både den nod som exekverar tjänstelogiken för den anropande abonnenten och den nod som exekverar tjänstelogiken för den abonnent som accepterar anropet. Koppeluppsättningen kommer dock att fungera oberoende av om tjänsten fungerar.

- Om tjänstefunktionalitet någon gäng ska ökas kan detta leda till att en ny TSPM-defmierad parameter måste skapas på grund av att ett värdeomfång i en av de befintliga parametrarna ska utökas. Denna tjänsteuppgradering kan då införas successivt i nätet. Tills det att alla noder uppdaterats bör både den gamla och den nya parametern skickas.

För genomförandet av ovan beskrivna exempel finns det i den originerande noden kod som t.ex. exekverar koden (logiken): Om abonnenten har tjänsten COLP aktiverad, så skicka TSPM-deñnierade parametern COLP-förfrågan till den terminerande sidan.

Om TSPM-defmierade parametern COLP-nummer sedan kommer och kopplet inte har gått snett, så skicka det aktuella numret på det externa protokollet 'till abonnenten.

Fackmannen inser hur denna logik kan överföras till en tillståndsmaskin, ett flödesdia- gram eller kod, varför ingen närmare beskrivning därav behövs här. Det bör dock än en gång frarnhållas att detta finns i tillämpningen - inte i protokollet eller dess dokumentation.

Claims (121)

15 20 25 30 35 40 515 179 21 PATENTKRAV

1. Sätt för intern kommunikation i ett telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,4l0; 502,504; 810) i de logiska nätverken, tjänstestyrande entiteter (308, 310; 506,508,5l0,512; 812,814,816,8l8; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att kommunikationen (828) mellan olika noders (1202 resp. 1204) tjänste- styrande entiteter sker enligt en generell protokollmodell genom utbyte av protokollparametrar (824; 1210,1212,1214,1216) i form av odelbara informatíonsöverföringselement, vilka dis- tribueras i meddelanden (1218, 1220), som är utan betydelse för de tjänstestyrande entite- terna, i en kommunikationstjänst (820; 1206,1208) med en parameterdistributionsfunktion (822) för nämnda parametrar.

2. Sätt att strukturera programvara i ett telekommunikationssystem som innefattar logis- ka nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,4l0; 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,5l0,512; 812,814,816,8l8; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i trafikförlopp i telekommunikationssystemet, - lagras i systemet programvarukomponenter baserade på en generell protokollmodell, som föreskriver utbyte av protokollparametrar (824; 1210,12l2,1214,1216) i form av odelbara in- forrriationsöverföringselement, vilka skall distribueras i meddelanden (1218, 1220), som saknar betydelse för de tjänstestyrande entiteterna, i en kommunikationstjänst (820; 1206,1208) med en parameterdistributionsfunktion (822) för nämnda parametrar.

3. Sätt enligt något av krav 1 eller 2, kännetecknat av att på grundval av den generella protokollmodellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst.

4. Sätt enligt något av krav 1-3, kännetecknat av att till den generella protokollmodel- len (TSPM) hör ett antal definierade protokollparametrar, vilka utgör den minsta dataenhet, som är möjlig att överföra i tjänsteprotokollet.

5. Sätt enligt något av krav 3 eller 4, kännetecknat av att vid specificering av ett tjäns- teprotokoll väljs godtyckligt ett för tjänsten lämpligt antal protokollparametrar, och nya pro- tokollparametrar definieras vid behov.

6. Sätt enligt något av krav 3 eller 5, kännetecknat av att en protokollspecifikation finnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna parametrar. i

7. Sätt enligt något av krav 3-6, kännetecknat av att tjänsteprotokollet saknar tillämp- ningslogik.

8. Sätt enligt något av krav 3-7, kännetecknat av att en protokollhanteringsentitet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänste- 10 20 25 30 35 515 179 22 protokollet (ASP).

9. Sätt enligt krav 9, kännetecknat av att uppdatering av en protokollhanteringsentitet (ASPE) inte kräver uppgradering av därmed samarbetande protokollhanteringsentiteter.

10. Sätt enligt något av krav 8 eller 9, kännetecknat av att vid kommunikation mellan två tjånstestyrande entiteter överför kommunikationstjänsten (ITS) data mellan protokollhante- ringsentiterna (ASPE), varvid parameterdistributionsfunktionen som fimis i kommunikation- stjänsten (ITS) anger till vilka protokollhanteringsentiteter (ASPE) varje protokollparameter skall sändas, och två parameterdistributionslistor används, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terminerande tjän- stestyrande entiteten.

11. ll. Sätt enligt krav 10, kännetecknat av att vid systemuppgradering laddas nya eller modifierade protokollhanteringsentiteter (ASPE), vilka kommer att påverka parameterdistribu- tionsfunktionen under exekveringen.

12. Sätt enligt något av krav 10 eller 11, kännetecknat av att tillämpningslogiken be- ordrar protokollhanteringsentiterna (ASPE) genom metoder att sända parametrar till kommu- nikationstjänsten (ITS) varpå tillåmpningslogiken beordrar kommunikationstjänsten (ITS) att sända ett meddelande.

13. Sätt enligt något av krav 8-12, kännetecknat av att konfigurationen av en protokoll- hanteringsentitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

14. Sätt enligt krav 13, kännetecknat av att för varje protokollhanteringsentitet (ASPE) specificerar tillämpningskonstruktören de parametrar som erfordras för att generera event till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

15. Sätt enligt något av krav 8-14, kännetecknat av att ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifikation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och meto- der som skall skickas från tillämpningslogiken till protokollhanteringsentiteten.

16. Sätt enligt något av krav 8-15, kännetecknat av att vid mottagning av en parame- ter, eller en viss uppsättning av parametrar, från kommunikationstjänsten (ITS) avger en pro- tokollhanteringsentitet (ASPE) en event till tillämpningslogiken.

17. Sätt enligt något av föregående krav, kännetecknat av att tillämpningslogiken (AL) innehåller all logik för trafikhantering, hantering av tilläggstjänster, interaktion mellan tjäns- ter.

18. Sätt enligt något av föregående krav, kännetecknat av att till varje protokollpara- meter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsenhet skall göra med parametern om den ej förstås.

19. Sätt enligt något av krav 3-18, kännetecknat av att kommunikationstjänsten (ITS) använder en uppsättning meddelanden och en motsvarande tillståndsmaskin, vilka meddelan- den ej har någon betydelse för tjänsteprotokollet (ASP) och ej behöver vara kända av tillämp- 4o ningskonstruktören. 20 25 30 35 515 179 23

20. Programvarusystem för telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,410; 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,5l0,512; 812,814,816,818; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i trafikförlopp i telekommunikationssystemet, - används regler angivna i en generell protokollmodell, som föreskriver utbyte av protokoll- parametrar (824; 1210,1212,1214,1216) i form av odelbara informationsöverföringselement, vilka skall distribueras i meddelanden (1218, 1220), som saknar betydelse för de tjänstesty- rande entiteterna, i en kommunikationstjänst (820; l206,1208) med en parameterdistributions- funktion (822) för nämnda parametrar.

21. System enligt krav 20, kännetecknat av att på grundval av den generella protokoll- modellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst.

22. System enligt något av krav 20 eller 21, kännetecknat av att till den generella protokollmodellen (TSPM) hör ett antal definierade protokollparametrar, vilka utgör den minsta dataenhet, som är möjlig att överföra i tjänsteprotokollet.

23. System enligt krav 21 eller 22, kännetecknat av att vid speciñcering av ett tjänste- protokoll väljs godtyckligt ett för tjänsten lämpligt antal protokollparametrar, och nya pro- tokollparametrar definieras vid behov.

24. System enligt något av krav 21-23, kännetecknat av att en protokollspecitikation finnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna parametrar.

25. System enligt något av krav 21-24, kännetecknat av att tjänsteprotokollet saknar tillämpningslogik.

26. System enligt något av krav 21-25, kännetecknat av att en protokollhanteringsenti- tet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänsteprotokollet (ASP).

27. System enligt krav 26, kännetecknat av att uppdatering av en protokollhanterings- entitet (ASPE) inte kräver uppgradering av därmed samarbetande protokollhanteringsentiteter.

28. System enligt krav 26 eller 27, kännetecknat av att vid kommunikation mellan två tjänstestyrande entiteter överför kommunikationstjänsten (ITS) data mellan protokollhante- ringsentiterna (ASPE), varvid parameterdistributionsfimktionen som ñnns i kommunikation- stjänsten (ITS) anger till vilka protokollhanteringsentiteter (ASPE) varje protokollparameter skall sändas, och två parameterdistributionslistor används, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terminerande tjän- stestyrande entiteten.

29. System enligt krav 28, kännetecknat av att vid systemuppgradering laddas nya eller 4o modifierade protokollhanteringsentiteter (ASPE), vilka kommer att påverka parameterdistribu- 20 25 30 35 40 502,504; 515 179 24 tionsfunktionen under exekveringen.

30. System enligt krav 28 eller 29, kännetecknat av att tillämpningslogiken beordrar protokollhanteringsentiterna (ASPE) genom metoder att sända parametrar till kommunika- tionstjänsten (ITS) varpå tillämpningslogiken beordrar kommunikationstjänsten (ITS) att sända ett meddelande.

31. System enligt något av krav 26-30, kännetecknat av att konñgurationen av en protokollhanteringsentitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

32. System enligt krav 31, kännetecknat av att för varje protokollhanteringsentitet (ASPE) specificerar tillämpningskonstruktören de parametrar som erfordras för att generera event till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

33. System enligt något av krav 26-32, kännetecknat av att ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifi- kation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och metoder som skall skickas från tillämpningslogiken till protokollhanteringsentiteten.

34. System enligt något av krav 26-33, kännetecknat av att vid mottagning av en para- meter, eller en viss uppsättning av parametrar, från kommunikationstjänsten (ITS) avger en protokollhanteringsentitet (ASPE) en event till tillåmpningslogiken.

35. System enligt något av krav 20-34, kännetecknat av att tillämpningslogiken (AL) innehåller all logik för trafikhantering, hantering av tilläggstjänster, interaktion mellan tjäns- ter.

36. System enligt något av krav 20-35, kännetecknat av att till varje protokollparame- ter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsenhet skall göra med parametem om den ej förstås.

37. System enligt något av krav 21-36, kännetecknat av att kommunikationstjänsten (ITS) använder en uppsättning meddelanden och en motsvarande tillståndsmaskin, vilka med- delanden ej har någon betydelse för tjänsteprotokollet (ASP) och ej behöver vara kända av tillämpningskonstruktören.

38. Sätt för intern kommunikation i ett telekommunikationssystem, som innefattar logis- ka nätverk (402,404) för telekommunikationstjänster, - logiska noder (306; 406,408,410; 502,504; 810) i de logiska nätverken, - tjänstestyrande entiteter (308, 310; 506,508,5l0,512; 8l2,814,816,8l8; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska nodema samt realiserade i programvara i form av exekverande fiinktioner i dessa, kännetecknat av att kommunikatio- nen (828) mellan olika noders (1202 resp. 1204) tjänstestyrande entiteter sker enligt en gene- rell protokollmodell genom utbyte av protokollparametrar (824; 12l0,l212,l214,1216) i form av odelbara informationsöverföringselement.

39. Sätt att strukturera programvara i ett telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjärister, logiska noder (306; 406,408,410; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 10 20 25 30 35 40 515 179 25 506,508,510,5l2; 8l2,814,8l6,8l8; 1202, l204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska moderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i traflkförlopp i telekommunikationssystemet, - lagras i systemet programvarukomponenter baserade på en generell protokollmodell, som föreskriver utbyte av protokollparametrar (824; 1210,l212,12l4,1216) i forrn av odelbara in- formationsöverföringselement.

40. Sätt enligt krav 38 eller 39, kännetecknat av att till den generella protokollmodel- len (TSPM) hör ett antal definierade protokollparametrar, vilka utgör den minsta dataenhet, som är möjlig att överföra i tjänsteprotokollet. i

41. Sätt enligt något av krav 38-40, kännetecknat av att vid speciticering av ett tjäns- teprotokoll väljs godtyckligt ett för tjänsten lämpligt antal protokollparametrar, och nya pro- tokollparametrar definieras vid behov.

42. Sätt enligt något av krav 38-41, kännetecknat av att på grundval av den generella protokollmodellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst.

43. Sätt enligt något av krav 38-42, kännetecknat av att en protokollspecifikation fmnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna para- metrar.

44. Sätt enligt något av krav 40-42, kännetecknat av att tjänsteprotokollet saknar till- lämpningslogik.

45. Sätt enligt något av krav 40-44, kännetecknat av att en protokollhanteringsentitet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänste- protokollet (ASP).

46. Sätt enligt krav 45, kännetecknat av att uppdatering av en protokollhanteringsenti- tet (ASPE) inte kräver uppgradering av därmed samarbetande protokollhanteringsentiteter.

47. Sätt enligt något av krav 38-46, kännetecknat av att vid kommunikation mellan två tjänstestyrande entiteter överför kommunikationstjänsten (ITS) data mellan protokollhante- ringsentitema (ASPE), varvid parameterdistributionsfunktionen som fmns i kommunikation- stjänsten (ITS) anger till vilka protokollhanteringsentiteter (ASPE) varje protokollparameter skall sändas, och två parameterdistributionslistor används, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terminerande tjän- stestyrande entiteten.

48. Sätt enligt något av krav 45-47, kännetecknat av att konfigurationen av en pro- tokollhanteringsentitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

49. Sätt enligt krav 48, kännetecknat av att för varje protokollhanteringsentitet (ASPE) specificerat tillämpningskonstruktören de parametrar som erfordras för att generera händelse till tjänsten, varvid tillstândsmaskinen för tjänsten placeras i tillämpningslogiken.

50. Sätt enligt något av krav 38-49, kännetecknat av att ett gränssnitt per tjänst mellan 20 25 30 35 515 179 26 tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifikation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och meto- der som skall skickas från tillämpningslogiken till protokollhanteringsentiteten.

51. Sätt enligt något av krav 38-50, kännetecknat av att tillämpriingslogiken (AL) innehåller all logik for trafikhantering, hantering av tilläggstjänster, interaktion mellan tjäns- ter.

52. Sätt enligt något av krav 38-51, kännetecknat av att till varje protokollparameter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsentitet skall göra med parametern om den ej förstås.

53. Programvarusystem för telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,4l0; 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,510,512; 812,8l4,8l6,8l8; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entitetenia i trafikförlopp i telekommuriikationssystemet, - används regler baserade på en generell protokollmodell, som föreskriver utbyte av proto- kollparametrar (824; l2lO,l2l2,l214,l216) i form av odelbara informationsöverföringsele- ment.

54. System enligt krav 53, kännetecknat av att till den generella protokollmodellen (TSPM) hör ett antal definierade protokollparametrar, vilka utgör den minsta dataenhet, som är möjlig att överföra i tjänsteprotokollet.

55. System enligt krav 53 eller 54, kännetecknat av att vid specificering av ett tjänste- protokoll väljs godtyckligt ett för tjänsten lämpligt antal protokollparametrar, och nya pro- tokollparametrar definieras vid behov.

56. System enligt något av krav 53-55, kännetecknat av att på grundval av den genere- lla protokollmodellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst.

57. System enligt något av krav 53-56, kännetecknat av att en protokollspecifikation finnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna parametrar.

58. System enligt något av krav 53-57, kännetecknat av att tjänsteprotokollet saknar tillämpningslogik.

59. System enligt något av krav 54-58, kännetecknat av att en protokollhanteringsenti- tet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänsteprotokollet (ASP).

60. System enligt krav 59, kännetecknat av att uppdatering av en protokollhanterings- entitet (ASPE) inte kräver uppgradering av därmed samarbetande protokollhanteringsentiteter.

61. System enligt något av krav 53-60, kännetecknat av att vid kommunikation mellan 40 tvâ tjänstestyrande entiteter överför kommunikationstjänsten (ITS) data mellan protokollhante- 15 20 25 30 35 515 179 27 ringsentiterna (ASPE), varvid parameterdistributionsfunktionen som fmns i kommunikation- stjänsten (ITS) anger till vilka protokollhanteringsentiteter (ASPE) varje protokollpararneter skall sändas, och två parameterdistributionslistor används, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terrninerande tjän- stestyrande entiteten.

62. System enligt något av krav 59-61, kännetecknat av att konfigurationen av en protokollhanteringsentitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

63. System enligt krav 62, kännetecknat av att för varje protokollhanteringsentitet (ASPE) specificerar tillämpningskonstruktören de parametrar som erfordras för att generera händelse till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

64. System enligt något av krav 53-63, kännetecknat av att ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifi- kation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och metoder som skall skickas från tillämpningslogiken till protokollhanteringsentiteten.

65. System enligt något av krav 53-64, kännetecknat av att tillämpningslogiken (AL) innehåller all logik för trañkhantering, hantering av tilläggstjänster, interaktion mellan tjäns- ter.

66. System enligt något av krav 53-65, kännetecknat av att till varje protokollparame- ter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsentitet skall göra med parametem om den ej förstås.

67. Sätt för intern kommunikation i ett telekommunikationssystem, som innefattar logis- ka nätverk (402,404) för telekommunikationstjänster, - logiska noder (306; 406,408,410; 502,504; 810) i de logiska nätverken, - tjänstestyrande entiteter (308, 310; 506,508,510,5l2; 812,814,8l6,8l8; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att kommunikatio- nen (828) mellan olika noders (1202 resp. 1204) tjänstestyrande entiteter sker enligt en gene- rell protokollmodell, på vars grundval specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst.

68. Sätt att strukturera programvara i ett telekommunikationssystem som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,410; 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,510,5l2; 812,814,8l6,8l8; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska nodema samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i trañkförlopp i telekommunjkationssystemet, - lagras i systemet programvarukomponenter baserade på en generell protokollmodell, på vars 40 grundval specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst. 10 20 25 30 35 40 515 179 zs

69. Sätt enligt krav 67 eller 68, kännetecknat av att vid specificering av ett tjänstepro- tokoll väljs godtyckligt ett för tjänsten lämpligt antal protokollparametrar, och nya protokoll- parametrar definieras vid behov.

70. Sätt enligt något av krav 67-69, kännetecknat av att en protokollspecifikation finnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna para- metrar.

71. Sätt enligt något av krav 67-70, kännetecknat av att tjänsteprotokollet saknar till- lämpningslogik.

72. Sätt enligt något av krav 67-71, kännetecknat av att en protokollhanteringsentitet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänste- protokollet (ASP).

73. Sätt enligt krav 72, kännetecknat av att uppdatering av en protokollhanteringsenti- tet (ASPE) inte kräver uppgradering av därmed samarbetande protokollhanteringsentiteter.

74. Sätt enligt av krav 72 eller 73, kännetecknat av att konfigurationen av en proto- kollhanteringsentitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

75. Sätt enligt krav 74, kännetecknat av att för varje protokollhanteringsentitet (ASPE) specificerat tillämpningskonstruktören de parametrar som erfordras för att generera händelse till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

76. Sätt enligt något av krav 67-75, kännetecknat av att ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifikation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och meto- der som skall skickas från tillämpningslogiken till protokollhanteringsentiteten.

77. Sätt enligt något av krav 67-76, kännetecknat av att tillämpningslogiken (AL) innehåller all logik för trafikhantering, hantering av tilläggstjänster, interaktion mellan tjäns- ter.

78. Sätt enligt något av krav 67-77, kännetecknat av att till varje protokollparameter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsentitet skall göra med parametern om den ej förstås.

79. Programvarusystem för telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,4l0; 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,5l0,512; 812,814,816,8l8; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i trafikförlopp i telekommunikationssystemet, - används regler angivna i en generell protokollmodell, på vars grundval specificeras tjänste- protokoll (ASP) svarande mot varsin tjänst.

80. System enligt krav 79, kännetecknat av att vid specificering av ett tjänsteprotokoll 20 25 30 35 40 515 179 29 väljs godtyckligt ett för tjänsten lämpligt antal protokollparametrar, och nya protokollparamet- rar deñnieras vid behov. ,

81. System enligt krav 79 eller 80, kännetecknat av att en protokollspecifikation fmnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna para- metrar.

82. System enligt något av krav 79-81, kännetecknat av att tjänsteprotokollet saknar tillämpningslogik.

83. System enligt något av krav 79-82, kännetecknat av att en protokollhanteringsenti- tet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänsteprotokollet (ASP).

84. System enligt krav 83, kännetecknat av att uppdatering av en protokollhanterings- entitet (ASPE) inte kräver uppgradering av därmed samarbetande protokollhanteringsentiteter.

85. System enligt krav 83 eller 84, kännetecknat av att konfigurationen av en proto- kollhanteringsentitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

86. System enligt krav 85, kännetecknat av att för varje protokollhanteringsentitet (ASPE) specificerar tillämpningskonstruktören de parametrar som erfordras for att generera händelse till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

87. System enligt något av krav 79-86, kännetecknat av att ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifi- kation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och metoder som skall skickas från tillämpningslogiken till protokollhanteringsentiteten.

88. System enligt något av krav 79-87, kännetecknat av att tillämpningslogiken (AL) innehåller all logik för trafikhantering, hantering av tilläggstjänster, interaktion mellan tjäns- ter.

89. System enligt något av krav 79-88, kännetecknat av att till varje protokollparame- ter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsentitet skall göra med parametern om den ej förstås.

90. Sätt för intern kommunikation i ett telekommunikationssystem, som innefattar logis- ka nätverk (402,404) för telekommunikationstjärister, - logiska noder (306; 406,408,410; 502,504; 810) i de logiska nätverken, - tjänstestyrande entiteter (308, 310; 506,508,510,512; 812,814,816,818; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i fonn av exekverande funktioner i dessa, kännetecknat av att kommunikatio- nen (828) mellan olika noders (1202 resp. 1204) tjänstestyrande entiteter sker enligt en gene- rell protokollmodell genom utbyte av protokollparametrar (824; 1210,l212,1214,1216), vilka distribueras av en kommunikationstjänst (820; 1206,1208) med en parameterdistributionsfunk- tion (822) för nämnda parametrar.

91. Sätt att strukturera programvara i ett telekommunikationssystem som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,410; 15 20 25 30 35 515 179 30 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,5l0,512; 812,814,816,818; 120,2, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i trafikförlopp i telekommunikationssystemet, - lagras i systemet programvarukomponenter baserade på en generell protokollmodell, som föreskriver utbyte av protokollparametrar (824; l210,12l2,1214,1216) vilka distribueras av en kommunikationstjänst (820; 1206,1208) med en parameterdistributionsfunktion (822) för nämnda parametrar.

92. Sätt enligt krav 90 eller 91, kännetecknat av att på grundval av den generella protokollmodellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst, att en protokollhanteringsentitet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänsteprotokollet (ASP), samt att kommuníkationstjänsten (ITS) över- för data mellan protokollhanteringsentiteriia (ASPE).

93. Sätt enligt något av krav 90-92, kännetecknat av att en protokollspecifikation finnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna para- metrar.

94. Sätt enligt något av krav 90-93, kännetecknat av att vid kommunikation mellan två tjänstestyrande entiteter överför komrnunikationstjäristen (ITS) data mellan protokollhante- ringsentiterna (ASPE), varvid parameterdistributionsfunktionen som finns i kommunikation- stjänsten (ITS) anger till vilka protokollhanteringsentiteter (ASPE) varje protokollparameter skall sändas, och två parameterdistributionslistor används, närnligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terminerande tjän- stestyrande entiteten.

95. Sätt enligt krav 94, kännetecknat av att konfigurationen av en protokollhanterings- entitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

96. Sätt enligt krav 95, kännetecknat av att för varje protokollhanteringsentitet (ASPE) specificerat tillämpningskonstruktören de parametrar som erfordras för att generera händelse till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

97. Sätt enligt något av krav 90-96, kännetecknat av att ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifikation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och meto- der som skall skickas från tillämpningslogiken till protokolllianteringsentiteten.

98. Sätt enligt något av krav 92-97, kännetecknat av att vid systemuppgradering laddas nya eller modifierade protokollhanteringsentiteter (ASPE), vilka kommer att påverka parame- terdistributionsfunktionen under exekveringen.

99. Sätt enligt krav 98 eller 99, kännetecknat av att tillämpningslogiken beordrar pro- 4o tokollhanteringsentiterria (ASPE) genom metoder att sända parametrar till kommunikations- 20 25 30 35 40 515 179 31 tjänsten (ITS) varpå tillämpningslogiken beordrar kommunikationstjänsten (ITS) att sända ett meddelande. ' ,

100. Sätt enligt något av krav 92-99, kännetecknat av att vid mottagning av en parame- ter, eller en viss uppsättning av parametrar, från kommunikationstjänsten (ITS) avger en pro- tokollhanteringsentitet (ASPE) en händelse till tillämpningslogiken.

101. Sätt enligt något av krav 90-100, kännetecknat av att på grundval av den generel- la protokollmodellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst, och att kommunikationstjänsten (ITS) använder en uppsättning meddelanden och en motsva- rande tillståndsmaskin, vilka meddelanden ej har någon betydelse för tjänsteprotokollet (ASP) och ej behöver vara kända av tillämpningskonstruktören.

102. Programvarusystem för telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,4l0; 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,510,512; 812,814,8l6,818; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i trafikförlopp i telekommunikationssystemet, - används regler baserade på en generell protokollmodell, som föreskriver utbyte av proto- kollparametrar (824; 1210,12l2,1214,1216) vilka distribueras av en kommunikationstjänst (820; 1206,1208) med en parameterdistributionsfunktion (822) för nämnda parametrar.

103. System enligt krav 102, kännetecknat av att på grundval av den generella pro- tokollmodellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst, att en protokollhanteringsentitet (ASPE) inom en tillämpning tar hand om protokollhanteringen för en viss tjänst enligt tjänsteprotokollet (ASP), samt att kommunikationstjänsten (ITS) överför data mellan protokollhanteringsentiteterna (ASPE).

104. System enligt krav 102 eller 103, kännetecknat av att en protokollspecifikation finnes för varje tjänsteprotokoll (ASP) där denna innehåller en lista över sända och mottagna parametrar.

105. System enligt något av krav 102-104, kännetecknat av att vid kommunikation mellan två tjänstestyrande entiteter överför kommunikationstjänsten (ITS) data mellan proto- kollhanteringsentiterna (ASPE), varvid parameterdistributionsfunktionen som finns i kommu- nikationstjänsten (ITS) anger till vilka protokollhanteringsentiteter (ASPE) varje protokoll- parameter skall sändas, och tvâ parameterdistributionslistor används, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den tenni- nerande tjänstestyrande entiteten.

106. System enligt något av krav 102-105, kännetecknat av att konfigurationen av en protokollhanteringsentitet (ASPE) bestäms i samband med tillämpningskonstruktionen, på så sätt att strukturen i huvudsak ej är känd av andra logiska noder.

107. System enligt krav 106, kännetecknat av att för varje protokollhanteringsentitet 10 20 25 30 35 515 179 sz (ASPE) specificerat tillämpningskonstruktören de parametrar som erfordras för att generera händelse till tjänsten, varvid tillståndsmaskinen för tjänsten placeras i tillämpningslogiken.

108. System enligt något av krav 102-107, kännetecknat av att ett gränssnitt per tjänst mellan tillämpningslogiken och en protokollhanteringsentitet (ASPE) innehåller en specifi- kation av events som skall skickas från protokollhanteringsentiteten till tillämpningslogiken, och metoder som skall skickas från tillämpningslogiken till protokollhanteringsentiteten.

109. System enligt något av krav 103-108, kännetecknat av att vid systemuppgradering laddas nya eller modifierade protokollhanteringsentiteter (ASPE), vilka kommer att påverka parameterdistributionsfunktionen under exekveringen.

110. System enligt något av krav 102-109, kännetecknat av att tillämpningslogiken beordrar protokollhanteringsentitema (ASPE) genom metoder att sända parametrar till kom- munikationstjänsten (ITS) varpå tillämpningslogiken beordrar kommunikationstjänsten (ITS) att sända ett meddelande.

111. System enligt något av krav 103-110, kännetecknat av att vid mottagning av en parameter, eller en viss uppsättning av parametrar, från kommunikationstjänsten (ITS) avger en protokollhanteringsentitet (ASPE) en händelse till tillämpningslogiken.

112. System enligt något av krav 102-111, kännetecknat av att på grundval av den generella protokollmodellen (TSPM) specificeras tjänsteprotokoll (ASP) svarande mot varsin tjänst, och att kommunikationstjänsten (ITS) använder en uppsättning meddelanden och en motsvarande tillståndsmaskin, vilka meddelanden ej har någon betydelse för tjänsteprotokollet (ASP) och ej behöver vara kända av tillämpningskonstruktören.

113. Sätt för intern kommunikation i ett telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjänster, - logiska noder (306; 406,408,410; 502,504; 810) i de logiska nätverken, - tjänstestyrande entiteter (308, 310; 506,508,510,5l2; 812,814,8l6,818; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att kommunikatio- nen (828) mellan olika noders (1202 resp. 1204) tjänstestyrande entiteter sker enligt en gene- rell protokollmodell genom utbyte av protokollparametrar (824; l210,1212,12l4,1216), vilka distribueras i meddelanden (1218, 1220), som är utan betydelse för de tjänstestyrande entite- tema.

114. Sätt att strukturera programvara i ett telekommunikationssystem som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,410; 502,504; 810) i de logiska nätverken, och tjänstestyrande entiteter (308, 310; 506,508,510,5l2; 812,814,8l6,818; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entitetema i trafikförlopp i telekommunikationssystemet, 40 - lagras i systemet programvarukomponenter baserade på en generell protokollmodell, som 10 15 20 25 30 515 179 33 föreskriver utbyte av protokollparametrar (824; 1210,1212,l214,l216), vilka skall distribu- eras i meddelanden ( 1218, 1220), som saknar betydelse för de tjänstestyrande entiteterna.

115. Sätt enligt krav 113 eller 114, kännetecknat av att tillämpningslogiken (AL) in- nehåller all logik för trafikhantering, hantering av tilläggstjänster, interaktion mellan tjänster.

116. Sätt enligt något av krav 113-115, kännetecknat av att en implementation av ett enligt den generella protokollmodellen skapat gränssnitt har två parameterdistributionsfunk- tioner, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terrninerande tjänstestyrande entiteten.

117. Sätt enligt något av krav 113-116, kännetecknat av att till varje protokollparame- ter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsentitet skall göra med parametem om den ej förstås.

118. Programvarusystem för telekommunikationssystem, som innefattar logiska nätverk (402,404) för telekommunikationstjänster, logiska noder (306; 406,408,4l0; 502,504; 810) i de logiska nätverken, tjänstestyrande entiteter (308, 310; 506,508,510,512; 812,814,816,818; 1202, 1204) som styr tjänst för en part i ett koppel, och är specificerade i de logiska noderna samt realiserade i programvara i form av exekverande funktioner i dessa, kännetecknat av att - för styrning av intern kommunikation mellan de tjänstestyrande entiteterna i trafikförlopp i telekommunikationssystemet, och - används regler baserade på en generell protokollrnodell, som föreskriver utbyte av proto- kollparametrar (824; 1210,1212,l214,l216), vilka skall distribueras i meddelanden (1218, 1220), som saknar betydelse för de tjänstestyrande entitetema.

119. System enligt krav 118, kännetecknat av att tillämpningslogiken (AL) innehåller all logik för trañkhantering, hantering av tilläggstjänster, interaktion mellan tjänster.

120. System enligt krav 118 eller 119, kännetecknat av att en implementation av ett enligt den generella protokollmodellen skapat gränssnitt har två parameterdistributionsfunk- tioner, nämligen en funktion som används för den originerande tjänstestyrande entiteten, och en som används av den terminerande tjänstestyrande entiteten.

121. System enligt något av krav 118-120, kännetecknat av att till varje protokollpara- meter hör en instruktionsindikator, som anger vad en mottagande protokollhanteringsentitet skall göra med parametern om den ej förstås.