SE514977C2 - Förfarande för modifiering av ett protokoll med hjälp av ett adaptivt protokoll - Google Patents

Description

l0 15 20 25 30 35 40 514 977 2 U.S. 4 905 282 avser ett protokoll som tillåter att mot- stående parter (modem) kan förhandla om vilka funktioner som skall ingå i protokollet. Det ena modemet kan efter en normal handskakningsprocedur sända en lista över önskade funktioner, varvid detta andra modemet kan acceptera funktionerna eller sända tillbaka en lista över funktioner som de stödjer.

U.S. figurera ett modem i ett kommunikationssystem. Metoden till- 4 956 852 beskriver en metod för att kunna kon- låter att ett första modem kan avläsa vilka funktioner som ett annat modem stödjer. Det första modemet kan även modi- fiera det andra modemets funktioner genom att försätta det i testläge.

U.S. dynamiskt. Telefonen implementerar ett protokoll som tillåter 4 928 306 visar en telefon som kan konfigureras att den kan konfigureras genom att mottaga kommandon och parametrar från en central punkt, t.ex. en abonnentväxel.

WO 94/6251 avser en nätstruktur och ett signalerings- protokoll i ett telenät. Signaleringsprotokollet tillåter att nya tjänster läggs till som enbart implementeras av de två motstàende parterna. Ett generellt signaleringsprotokoll stödjer tillägg av nya tjänster genom att delas in i ett grundprotokoll och i ett eller flera tjänstespecifika proto- koll. Detta tillåter att tjänster läggs till eller tas bort utan att grundprotokollet ändras.

EP-A-555 997 visar en apparat och en metod för att implementera protokoll. Kommunikationen kan ske över ett godtyckligt protokoll genom att i ett generellt protokoll översända en beskrivning av det protokoll som önskas.

Teknikens ståndpunkt löser inte tillfredsställande pro- blemet att automatiskt uppdatera ett protokoll. Föreliggande uppfinning tillhandahåller en mekanism som medger enkel till- läggning och borttagning av funktionaliteter så att proto- kollet modifieras automatiskt och hos rätt part på rätt nivå utan amkonstruktion av lagren.

SAMANFATTNING AV UPPFINNINGEN Lösningen innebär i korthet att adaptiviteten åstad- kommes genom en publiceringsmekanism som informerar mot- stående parter som använder sig av ett givet protokoll att tillägg har gjorts till protokollet. Mekanismen är i sig ett 10 15 20 25 30 35 40 514 97"/ 3 protokoll som erbjuder och hanterar en mängd operationer, argument och datatyper. Huvuddraget i mekanismen är att man antingen försöker publicera ett objekt och får tillbaka en konfirmation från den motstående partnern, eller att man tar bort ett objekt. Med publicering menas att erbjudandet om det nya objektet kan gå ut till flera parter, där var och en av parterna kan acceptera eller avvisa objektet. Olika revi- sioner av grundprotokollet kan därför förekomma. Uppfinningen medger således att processen att uppdatera ett protokoll kan automatiseras.

Således tillhandahåller föreliggande uppfinning ett för- farande för modifiering av ett protokoll hos parter i ett telesystem med hjälp av ett adaptivt protokoll. Enligt upp- finningen publiceras ett modifierat protokollobjekt av en part som önskar en modifiering till berörda andra parter som mottar publiceringen. Protokollobjektet definieras av en identifierare, en nivå och en beskrivning. Uppfinningen är mera detaljerat angiven i åtföljande patentkrav.

KORTFATTAD BESKRIVNING AV RITNINGARNA Uppfinningen kommer att beskrivas i detalj härefter med hänvisning till bifogade ritningar, varav: Figur l är ett blockschema över kommunikation mellan två parter, figur 2 är ett motsvarande blockschema över ändring av ett protokoll P på nivå N-2 med hjälp av föreliggande upp- finning, och figur 3 är ett flödesschema över ett exempel på ändring av ett protokoll.

DETALJERAD BESKRIVNING AV EN FÖREDRAGEN UTFÖRINGSFORM Föreliggande uppfinning tillhandahåller således ett för- farande som medger en ändring av protokoll i telesystem. För- farandet är i sig ett protokoll som är adaptivt.

Genom att ett protokoll är adaptivt kan man enkelt lägga till ny funktionalitet i protokollet utan att behöva omkon- struera de i protokollet ingående lagren. Dessutom är det möjligt att under drift ändra protokollet utan att stoppa systemet. Det här är användbart då man har en protokoll- standard och då nya eller existerande produkter uppgraderas, 10 15 20 25 30 35 40 514 977 4 som visserligen följer standarden men har några ytterligare funktioner som de erbjuder. Med hjälp av adaptiviteten kan då produkterna justera protokollet så att den nya funktionali- teten direkt kan erbjudas.

Adaptiviteten i ett protokoll innebär enligt upp- finningen att man genom en publiceringsmekanism informerar motstående parter som använder ett givet protokoll att tillägg har gjorts till protokollet.

I figur l visas ett exempel på kommunikation mellan två parter. Antag att det finns ett protokoll P och parter A och B som kommunicerar via protokollet på en viss nivå N. Om A eller B vill utöka sin egen funktionalitet brukar detta leda till en utökning av det gemensamma protokollet P på nivå N.

Antag att A har fått en utökad funktionalitet och vill utöka protokollet P. A använder då adaptivitetsmekanismen i proto- kollstacken för att publicera utökningen i protokoll P. B kan då delge detta till övriga nivåer i protokollstacken samt själv använda sig av denna information.

Mekanismen är i sig ett protokoll som erbjuder en diskret mängd operationer.

Mekanismen kan hantera operationer, argument och data- typer. Beroende på hur man anger relationen till andra opera- tioner, argument och datatyper så bestäms omfattningen av en operation, ett argument eller en datatyp. Operationer, argu- ment eller datatyper är exempel på protokollobjekt.

Huvuddraget i mekanismen är att man antingen försöker publicera ett objekt och får tillbaks en konfirmation från den motstående parten, eller att man tar bort ett objekt. Om man tar bort ett objekt behövs ingen konfirmation eftersom man hela tiden skall kunna falla tillbaka på grundprotokollet utan att problem skall uppstå. Det kan t.ex. vara så att en part får ett fel som gör att en viss operation inte kan an- vändas för en längre tid och då skall parten kunna dra till- baka den erbjudna operationen utan att övriga parter skall behöva godkänna denna.

Med publicering menas att erbjudandet om det nya objektet kan gå ut till flera parter, där var och en kan acceptera eller avvisa objektet. Publicerande part håller reda på vem som ha accepterat det nya objektet. Olika revi- sioner av grundprotokollet kan därför förekomma. 10 15 20 25 30 35 4O 514 977 5 Inbyggt i mekanismen finns textuella beskrivningar i klartext av det publicerade objektet för att ovanliggande applikationer t.ex. en hjälp-applikation ska kunna ta del av vad som händer med protokollet. Det finns också en formell beskrivning som t.ex. kan vara skriven med notationen ASN.1.

Adressering av motpart, felhantering och notation sker enligt gällande protokoll.

För att adaptivitetsmekanismen skall fungera måste den finnas implementerad upp till minst nivå N för att kunna adaptera protokollstacken upp till nivå N. Dessutom måste protokollet på någon av nivåerna upp till nivå N ha möjlighet att hantera adaptivitetsmekanismens protokollobjekt. Med dagens protokoll innebär detta ofta att mekanismens egna objekt finns på applikations- eller sessionsnivå i OSI- stacken, vilket medför att adaptivitetsmekanismen finns im- plementerad från åtminstone sessionsnivån och nedåt. Nivåer med mekanismer som inte direkt kan kommunicera med varandra, anropar överliggande nivås mekanism.

Figur 2 visar hur protokollet P på nivå N-2 utvidgas genom att mekanismen på nivå N-2 anropar mekanismen på nivå N-1 som i sin tur anropar mekanismen på nivå N, som kan kom- municera med motstående part via mekanismens egna protokoll- objekt. Publiceringen skickas sedan nedåt till nivå N-2, var- efter en konfirmering sker från nivå N-2 och uppåt och till- baks.

Det adaptiva protokollets mekanism beskrivs nedan med avseende på de olika operationerna och definitionerna. För lättfattlighetens skull och för att mekanismen i sig är obe- roende av notationssätt beskrivs den i pseudoform. Dock kan man naturligtvis välja ett notationssätt t.ex. ASN.l om man så önskar.

Vid tillägg till protokollet publicerar den modifierande parten till motstående part den nya operationen med dess parametrar. Operationen förväntar sig en konfirmering från motstående part. Följande argument finns i operationen: iden- tifierare, nivå och beskrivning. Identifieraren anger den nya operationens identifikation. Nivån anger vilket lager i pro- tokollstacken som skall modifieras. Beskrivningen innehåller en textuell beskrivning av den nya operationen som ger möj- lighet att uppdatera manualsidor m.m. och en beskrivning en- lO 15 20 25 30 35 40 ligt gällande notation som beskriver den nya operationen med t.ex. ASN.l, eller annan notation.

Vid borttagning från protokollet publicerar den modi- fierande parten till motstàende part att en viss operation inte längre gäller i protokollet. Argument i operationen är följande. Identifierare anger operationens identifikation.

Nivå anger vilket lager i protokollstacken som skall modi- fieras. Orsak är en textuell och en formell beskrivning av orsaken till tillbakadragandet av operationen.

Part som emottagit en publicering via operationen “Publicera tillägg“ returnerar till den publicerande parten en konfirmation som antingen accepterar eller avvisar den publicerade operationen för användning i protokollet. Föl- jande argument finns. Identifierare anger den publicerade operationens identifikation. Nivå anger vilket lager i pro- tokollstacken som skall modifieras. Konfirmering anger accep- tans eller avvisning.

Vid tillägg av nytt argument publicerar den modifierande parten för motstående part det nya argumentet som skall adde- ras till en redan känd operation. Följande argument används.

Operationsidentifierare anger den kända operationens identi- tet. Om argumentet inte anges, antas argumentet gälla för alla operationer. Nivå anger vilket lager i protokollstacken som skall modifieras. Argumentidentifierare anger det nya argumentets identitet. Textuell beskrivning är en beskrivning av argumentet i fri text. Beskrivning enligt gällande nota- tion är det nya argumentet beskrivet i formell form.

Vid borttagning av argument publicerar den modifierande parten till motstàende part att ett argument inte längre gäller i protokollet. Argument i operationen är följande.

Operationsidentifierare är operationens identifikation. Om argumentet inte anges, så gäller detta för samtliga opera- tioner. Argumentidentifierare anger argumentets identitet.

Nivå anger vilket lager i protokollstacken som skall modi- fieras. Orsak är en textuell och en formell beskrivning av orsaken till tillbakadragande av argumentet.

Part som emottagit en publicering via operationen "Pub- licera nytt argument" returnerar till den publicerande parten en konformation som antingen accepterar eller avvisar det publicerade argumentet för användning i protokollet. Följande 10 15 20 25 30 35 40 514 977 7 argument finns. Operationsidentifierare anger operationens identifikation. Om argumentet angavs i föregående operation anges det även här. Argumentidentifierare anger det publice- rade argumentets identifikation. Nivå anger vilket lager i protokollstacken som skall modifieras. Konfirmering anger acceptans eller avvisning.

Vid tillägg av en ny datatyp publicerar den modifierande parten för motstàende part den nya datatypen som skall adde- ras till en redan känd operation eller argument. Beroende pà vilka identifierare som ges, avgörs hur stort användnings- T.ex. område datatypen har. om ingen operationsidentifierare anges, så är datatypen global i protokollet. Följande argu- ment används. Operationsidentifierare anger den kända opera- tionens identitet. Om argumentet inte anges, gäller publice- ringen för alla operationer. Argumentidentifierare anger det kända argumentets identitet. Om argumentet inte anges, gäller datatypen för alla argument i en operation, eller för alla argument i protokollet. Detta beror på om en operationsiden- tifierare anges. Unionen mellan operationsidentifieraren och argumentidentifieraren anger omfattningen av publiceringen.

Datatypidentifierare anger det nya argumentets identitet.

Nivà anger vilket lager i protokollstacken som skall modi- fieras. Textuell beskrivning är en beskrivning av datatypen i fri text. Beskrivning enligt gällande notation beskriver den nya datatypen i formell form.

Vid borttagning av en datatyp publicerar den modifi- erande parten till motstàende part att en datatyp inte längre gäller i protokollet. Argument i operationen är enligt föl- jande. Operationsidentifierare anger den kända operationens identitet. Om argumentet inte anges, gäller borttagningen för alla operationer. Argumentidentifierare anger det kända argu- mentets identitet.

Om argumentet inte anges, gäller detta för alla argument i en operation, eller för alla argument i pro- tokollet, beroende pà om en operationsidentifierare har an- getts. Unionen mellan operationsidentifieraren och argument- identifieraren anger omfattningen av borttagningen. Datatyp- identifierare anger datatypens identitet. Nivà anger vilket lager i protokollstacken som skall modifieras. Orsak är en textuell och en formell beskrivning av orsaken till till- bakadragandet av datatypen. 10 15 20 25 30 35 40 514 977 8 Part som emottagit en publicering via operationen “Publicera ny datatyp" returnerar till den publicerande parten en konformation som antingen accepterar eller avvisar den publicerade datatypen för användning i protokollet. Föl- jande argument används. Operationsidentifierare anger den kända operationens identitet. Om argumentet angavs i före- gående operation anges det även här. Argumentidentifierare anger det aktuella argumentet. Om identifieraren angavs i föregående operation, anges det även här. Datatypidenti- fierare anger den publicerade datatypens identifikation. Nivå anger vilket lager i protokollstacken som skall modifieras.

Konfirmering anger acceptans eller avvisning.

EXEMPEL Figur 3 visar ett exempel som illustrerar uppfinningen.

Antag att vi har en Service Control Point (SCP) och en Ser- (SSP) (Intelligent Network Access Protocol) vice Switching Point som har standardprotokollet INAP mellan sig. I INAP-protokollet finns en operation som kan skickas från SCP Operationen begär en till SSP som kallas "Dirigera till". uppkoppling till ett telefonnummer. Antag nu att en annan tillverkare av SSP har en extra funktion som kan skapa tre~ partssamtal. Han vill då kunna erbjuda detta genom att addera till en operation som heter "Trepartssamtal". Genom publice- ringsmekanismen kan han då publicera denna operation genom att skicka operationen "Publicera tillägg" via TCAP (nivån under INAP) med lämpligt val av argument.

Exempelvis: 0 Publicera tillägg av operation - Identifierare: INAP - Textuell beskrivning: "Trepartssamtal" - Nivå: "Operationen erbjuder trepartssamtal med lokaltaxa“ - Beskrivning enligt gällande notation ASNl. Ver 1.0: . - - ~ - . . .

SSPn inväntar sedan en konfirmation från SCPn: 0 Konfirmera tillägg av operation Identifierare: “Trepartssamtal“ INAP Konfirmering: Ja Nivå: I 10 15 514 977 9 Efter konfirmering är det upp till applikationerna på båda sidor att internt informera och använda sig av den nya operationen. För nätets del innebär det troligtvis att pro- grammeraren av tjänster ser den nya operationen i sin verk- tygslàda, med beskrivning och allt.

Således tillhandahåller uppfinningen ett automatiskt förfarande för att uppdatera protokoll. Uppfinningen elimi- nerar moment med manuellt ingripande från människor. Tidigare var man tvungen att manuellt omprogrammera system för att lägga till nya delar av protokoll. Uppfinningen möjliggör även automatisk ändring av protokoll under drift. En före- dragen utföringsform och ett exempel har beskrivits ovan.

Många variationer av uppfinningens form kan lätt inses av en fackman på området. Uppfinningen är endast begränsad av nedanstående patentkrav.

Claims (10)

10 15 20 25 30 35 40 514- 977 IO PATENTKRAV

1. Förfarande för modifiering av ett protokoll som består av protokollobjekt hos parter i telesystem, kännetecknat av att ett modifierat protokollobjekt publiceras av en part som önskar en modifiering,dvs. den publicerande parten sänder ett erbjudande om ett modifierat protokollobjekt till berörda andra parter, som mottar publiceringen, vilket protokoll- objekt definieras av en identifierare, en nivå och en be- skrivning, att en mottagande part återsånder en konfirmation till den publicerande parten som använder det modifierade protokollobjektet i beroende av konfirmationen.

2. Förfarande enligt krav 1, kännetecknat av att modifieringen innebär ett tillägg till protokollet, varvid mottagande part återsånder en konfirmation som accepterar eller avvisar tillägget.

3. Förfarande enligt krav 1, kännetecknat av att modifieringen innebär en borttagning i protokollet, varvid mottagande part återsånder en konfirmation som accepterar eller avvisar borttagningen.

4. Förfarande enligt krav 2 eller 3, kännetecknat av att den publicerande parten registrerar vilka mottagande parter som har accepterat modifikationen.

5. Förfarande enligt något av kraven 1-4, kännetecknat av att protokollobjektet är en operation.

6. Förfarande enligt något av kraven 1-4, kännetecknat av att protokollobjektet år ett argument som dessutom kan definieras för vilken operation som det avser.

7. Förfarande enligt något av kraven 1-4, kännetecknat av att protokollobjektet år en datatyp som dessutom kan de- finieras för vilken operation och vilket argument som den avser.

8. Förfarande enligt något av föregående krav, känne- tecknat av att nivån anger vilket lager i protokollstacken som skall modifieras.

9. Förfarande enligt något av föregående krav, känne- tecknat av att beskrivningen innehåller en textuell beskriv- ning i klartext samt en beskrivning med formell notation.

10. Förfarande enligt krav 9, kännetecknat av att den formella notationen år skriven med ASN.1.