SE503394C2 - Förfarande för att strukturera anropsbearbetning samt växelsystem för telefoni med koppelbearbetning - Google Patents

Description

2 speciellt realtidkommunikationen mellan objekten i enlighet med CCIT X200. EP-A1-O 524 077 med titeln "Structure de logiciel pour système de traitement d'informations" beskriver en struktur som för tillämpningsprogrammen döljer hàrdvaru- och mjukvaruegenska- per.

EP-A2-O 470 415 beskriver en metod att förse ett antal applika- tionsprocessorer i ett telefonsystem med tillgång till koppel- relaterad information ienlgemensanxdatabas. Informationen taggas och lagras temporärt som en registrering i databasen så länge som kommunikationen págár. Informationen är speciellt inriktad att vara direkt synlig pà en presentationsterminal för övervakning i ett operatörsstyrt Växelsystem.

SAMMANFATTNING AV UPPFINNINGEN Det är därför ett behov i ett telekommunikationssystem, lämpligen med hjälp av nüukvara, att skapa en standardmässig och allmän struktur, som gör det möjligt att utsträcka systemet med nya tjänster och data utan att påverka redan existerande arbetande mjukvara i ett system som utnyttjar halvkoppelprincipen.

Ett första syfte i enlighet med den föreliggande uppfinningen är att kombinera halvkoppelprincipen, med ett allmänt protokoll mellan exekveringshalvkopplen och inbegripande en session innefattande en sessionsomfattning och en trafikfallsomfattning sonnanvänderrninnesfunktionez'i vilka olika registreringar lagrar pekare till en lokal minnesfunktion, varvid pekaren vidare kombineras med ett taggelement med vars hjälp lokalt lagrade data kommer att unikt identifieras och kan, trots att inte vara verkliga globala data, fortfarande användas som globala data under den speciella sessionens varaktighet, under vilken period de speciella registreringarna existerar.

Ett andra syfte i enlighet med den föreliggande uppfinningen är att den speciella sessionsomfattningen använder en sessions- registrering för lagring av pekare till exekveringsobjekt för kopplet och ur vilken registrering det kommer att vara möjligt 503 394 3 att hitta alla andra objekt i sessionen om taggelelemten under vilka objekten lagras är kända, varjämte andra objekt lagras i en transaktionsregistrering refererad av sessionsregistreringen eller av en trafikfallsregistrering.

Ett tredje syfte i enlighet med den föreliggande uppfinningen är att trafikfallsomfattningen har en liknande struktur som session- somfattningen och trafikfallsregistreringen refereras från sessionsregistreringen och trafikfallsregistreringen skapas för att lagra exekveringsobjekt för ett koppel.

Ett fjärde syfte i enlighet med den föreliggande uppfinningen är att transaktionsregistreringen lagrar' dataobjekt soul tillhör tafikfallet.

Ett femte syfte i enlighet med den föreliggande uppfinningen är att taggelementet realiseras genom ett heltal unikt tilldelat varje exekveringsobjekt eller dataobjekt som lagras.

KORT BESKRIVNING AV RITNINGARNA Uppfinningen tillsammans med ytterligare syften och fördelar med denna kan bäst förstås genom att hänvisa till den följande beskrivningen läst tillsamans med de medföljande ritningarna i Vilka: Figur 1 är en illustration av en session med en sessionsstyr- ning, SC, som hanterar åtskilliga trafikfall inbe- gripande för varje trafikfall ett respektive origine- rande koppel, OC i komunikation med andra trafikfall inbegripande ett respektive terminerande koppel, TC, Figur 2 visar en sessionstyrning, SC som använder i enlighet med förfarandet och systemet enligt den föreliggande uppfinningen en sessionsregistrering för att lagra referenser till exekveringsobjekt och en transaktions- registrering för att lagra referenser till dataobjekt, 503 394 4 Figur 3 visar sammanställningar i enlighet med förfarandet och systemet enligt den föreliggande uppfinningen för att lagra ett trafikfallsobjekt i ett originerande koppel, OC, Figur 4 är den demonstration av objekt som styr dataflödet i en session, Figur 5 visar ett exempel när data för ett debiteringsunderlag tas ut frán en session, Figur 6 visar i ett enkelt exempel sambandet mellan skapade skötta objekt, Figur 7 visar den fullständiga statiska överblicken i enlighet med det enkla exemplet i fig. 6, Figur 8 är ett enkelt flödesdiagram för koppeldatasaman- fattning i en transaktionsregistrering under koppelbe- arbetning, samt Figur 9 är ett enkelt flödesdiagram över specifikation av data som skall inkluderas i en utmatning.

GRUNDPRINCIPER För att på ett effektivt sätt kunna hantera ändamålet enligt den föreliggande ansökningen är det praktiskt att först definiera ett antal tekniska termer som komer att vara användbara i. den följande beskrivningen.

Ett vanligt sätt att strukturera mjukvara i växelsystem för telefoni med bearbetning av koppel är att dela styrningen av kopplet i tvâ halvor, ett Halvkoppel A och ett Halvkoppel B.

Detta illustreras i fig. 2. Mjukvaran. san kontrollerar ett halvkoppel exekveras i en process benämnd en Session. En session kan hantera ett eller flera Trafikfall samtidigt (till exempel i.en flerkoppelsituation). Trafikfallet.definierar funktionalite- 503 394 5 ten och data som hanterar ett koppel i en session. Notera även att ett trepartskoppel hanteras av tvà trafikfall i en session, ett för varje koppelben.

För enkelhets skull struktureras sessionen i olika omfattningar och därför introduceras Sessionsomfattningen och Trafikfallsom- fattningen. Detta illustreras i fig. 3. Sessionsomfattningen kontrolleras av Grundflödes-sessionsstvrninqen, SC. Huvudupp- giften för sessionsstyrningen är att verka som en kommandotolk gentemot Ãtkomstprotokollet, ACP och göra en tjänstanalys på dessa kommandon (Meddelanden). Detta inbegriper dä, till exempel, initiering och terminering av nya trafikfall, distribution av information fràn átkomstprotokollet till rätt trafikfall, initiering av nya tjänster, osv.

Varje trafikfall i sessionen styrs av ett basflöde. Ett sådant basflöde kan vara antingen ett Qriginerande koppel, OC eller ett Terminerande koppel, TC. Huvuduppgiften för detta basflöde är att ta hand om den grundläggande koppelhanteringen. Detta inbegriper till exempel upprättande/urkopplande av ett koppel (inkluderande hantering av Telekommunikationstiänstprotokollet, TSP, mellan halvkoppel), beställning av upprättande/urkopplande av för- bindelser (till exempel en talförbindelse), beställning av adressinformationsanalys, osv.

För att understöda de olika omfattningarna och styrlogiken som arbetar inom dessa, finns det ett behov av en liknande datastruk- tur. Alltsá måste data struktureras pà ett visst sätt för att göra det möjligt att implementera och.underhàlla tillämpningarna.

Motsvarande finns det två olika typer av objekt, vilka i denna beskrivning benämns Exekveringsobjekt och Dataobjekt.

Ett exekveringsobjekt kommer att exekveras i sessionen, t. ex. styrobjekt, protokollobjekt, resursobjekt, osv. Ett rent data- objekt kommer att innehålla data mottagna till exempel fràn ett Teletjänstprotokollmeddelande_ Det skall också vara möjligt att göra en utmatning av denna typ av data av debiterings- och 503 394 6 statistikskäl. De tvà typerna av objekt har olika semantik och lagras i skilda registreringar i sessionen. Detta illustreras i fig. 4. En sådan registrering refereras till som en Sessions- registrering och används för att lagra pekare till protokollo- bjekt instantierade av styr- och resursobjekt i sessionen.

Objekten lagrade i sessionsregistreringen är gemensama för hela sessionen. För lagring av referenser till rena dataobjekt används en Transaktionsregistrering. Pà liknande sätt som sessions- registreringen lagrar pekare till objekt används också trans- aktionsregistreringen (också kallad koppelregistrering) för att lagra pekare till rena dataobjekt instantierade av styr-, protokoll- och resursobjekt i sessionen eller i ett trafikfall som exekverar i sessionen.

En användares översikt av en sessionsregistrering refereras som en Sessionsrggistreringsöversikt och ger användaren ett gräns- snitt till sessionsregistreringen pá en hög abstraktionsnivà. Pä sama sätt refereras som Transaktionsregistreringsöversikten en användares översikt av en transaktionsregistrering och ger an- vändaren ett gränssnitt till transaktionsregistreringentpå en hög abstraktionsnivà.

Slutligen finns det också en Trafikfallsregistrering som är en registrering där pekare till objekt som tillhör ett trafikfall lagras. Endast pekare till protokollobjekt och resursobjekt lagras i denna registrering. För lagring av rena dataobjekt skulle en transaktionsregistrering användas. En användares översikt av en trafikfallsregistrering refereras till en Trafikfallsregistreringsöversikt och ger användaren ett gräns- snitt till sessionsregistreringen på en hög abstraktionsnivà.

DETALJERAD BESKRIVNING Av DEN FÖREDRAGNA UTFöRINGsFoRMEN För att understöda de olika omfattningarna och motsvarande styrlogik vid en bearbetning av koppel i ett telekommunikations- system behöver vi en lämplig datastruktur. Data máste strukture- ras för att göra det möjligt att implementera och underhålla 503 394 7 tillämpningarna. Vi introducerar därför två olika typer av objekt, exekveringsobjekt, respektive dataobjekt, för att hålla ordning i en session. Dessa två termer, som redan definierats ovan, har olika semantik och lagras i olika registreringar i den genererade sessionen. Vid lagring av ett objekt i en samman- fattning är det endast en fråga om att lagra en pekare till objektet som skall lagras och följaktligen görs i ett sådant steg ingen duplicering av objektet självt. Detta innebär också att för en sådan pekarlagring finns det faktiskt inget behov av att veta storleken av det speciella objektet.

Figur 1 är en generaliserad översikt av en sessionsomfattning, vilken styrs av sessionsstyrningen SC. Sessionsstyrningen verkar som en kommandotolk gentemot åtkomstprotokollet ACP, vilket är den allmänna termen använd för abonnent- eller nätätkomster. Som är uppenbart ur figur 1 innehåller sessionen ett eller flera trafikfall, och här innehåller den speciella sessionen tvà trafikfall som båda är av typen OC (originerande koppel). Vart och ett av de två trafikfallen av typ OC upprättas med hjälp av respektive trafikfall till ett annat trafikfall av typ TC (terminerande koppel) via ett hanterande telekommunikation- stjänstprotokoll, TSP.

Som indikerat i figur 2 finns det i sessionsomfattningen en sessionsregistrering som skall användas för lagring av en pekare, PTR, till varje exekveringsobjekt, till exempel till en så kallad sessionsagent. Sessionsregistreringen, SR, är med hjälp av andra pekare datastrukturens rot i varje session. Dataobjekten i hela sessions hittas i transaktionsregistreringen med hjälp av deras respektive pekare, PTR. Varje inmatning i sessionsregistreringen har ett speciellt namn eller en nyckel, TAG, vilken gör det möjligt finna vilket som helst objekt inom sessionsomfattningen om den specielle systemoperatören känner det speciella namnet eller TAG.

Figur 3 är en generaliserad översikt av en trafikfallsomfattning, här innehållande ett koppel av originerande typ, OC, men ett 503 394 8 koppel av terminerande typ, TC, skulle ha motsvarande struktur.

Denna omfattning måste introduceras om tillämpningen har behov av att exekvera ett godtyckligt antal parallella trafikfall i sessionen. Trafikfallsomfattningens struktur är sålunda likartad med den för sessionsomfattningen. För varje trafikfall i en session finns skapat en trafikfallsregistrering för att lagra exekveringsobjekt. Liksom i sessionsregistreringen används ett namn eller TAG cxflï en pekare PTR. Trafikfallsregistreringen refereras följaktligen.frán sessionsregistreringen. För att lagra objekt som tillhör trafikfallet används följaktligen en trans- aktionsregistrering, TR, som skapar en tabell för dataobjekten vid denna trafikfallsnivà.

Varje användare av en sessions- eller trafikfallsregistrering har ett eget översiktsobjekt via vilket de lagrade exekveringsobjek- ten eller dataobjekten kan àtkommas.

Figur 4 demonstrerar mera i detalj dataflödet genom en session som exekverar ett originerande koppel, OC. Dataflödet startar när nâgra data umttas :mr en âtkomstagent eller inmatningsagent.

Mottagna data omvandlas till en intern AXE-representation.

Omvandlade data lagras sedan i transaktionsregistreringen, TR.

Dataobjektet lagras med en tagg. Taggen är ett heltal som är reserverat för detta speciella dataobjekt. Andra användare, t. ex. en tillämpningsanalys, som behöver dataobjektet kan hämta detta ur transaktionsregistreringen:ned hjälp av taggen och genom att utnyttja ett transaktionsregistreringsöversiktsobjekt, TR_View. Ovanstående exempel illustrerar när data sänds av utmatningsagenten till det andra halvkopplet via telekommunika- tionstjänstprotokollet, TSP. Data sänds i en parameter vilken förutom data innehåller taggen som identifierar den.

Som nämnts ovan lagras ett dataobjekt i transaktionsregistre- ringen (en synonym för transaktionsregistrering är också koppel- registrering). Transaktionsregistreringen, TR, átkoms som redan nämnts via ett översiktsobjekt. Översiktsobjektet ger användaren ett högnivàgränssnitt till TR, vilket kommer att ytterligare 503 394 9 beskrivas nedan. Varje dataobjekt som lagras i transaktions- registreringen identifieras semantiskt genom ett namn eller en nyckel hänvisad till som TAG. TAG är ett heltal, i en exemplifie- rande utföringsform ett 16 bitars ord, som har reserverats för ett speciellt dataobjekt. Genonxanvändning av en dynamisk lagring såsom transaktionsregistreringen, där dataobjekten lagras med taggar kommer det att vara möjligt att understöda en mycket flexibel utmatningsmekanism. Med andra ord kommer det att vara ytterst lätt, utan att inverka pá telekommunikationssystemets allmänna funktion, att vid vilken som helst speciell tidsperiod ta ut vilka som helst valda dataobjekt pá begäran av användaren för en senare analys. En följd av detta är att det kommer att vara ytterst enkelt att lägga till ytterligare tjänster i ett system som arbetar i enlighet med ett sådant strukturerat arbetssätt.

Antag att agenten tar emot parametern "anropar parts nummer" i protokollet ACP. Data kommer att omvandlas till intern AXE- representation och lagras i TR tillsammans med en dedicerad tagg, "AppCallingPartyNumberTag". Andra användare av TR som behöver detta 'anropar parts numer' kan sedan vända sig till TR och begära dataobjektet som är lagrat med TAG "AppCallingPartyNum- berTag". Ett gränssnitt "Application Platform Tags Interface", ATI innehåller antalet taggar använda av funktionerna. ATI innehåller också regler som skall följas när nya taggar reserve- ras.

Som redan nämnt àtkoms TR alltid via ett översiktsobjekt. Över- siktsobjektet har två huvuduppgifter. Varje användare av TR skall ha ett dedicerat gränssnitt till innehållet i TR. Den andra upp- giften är att verka som ett handtagsobjekt gentemot TR, varvid handtaget säkerställer att TR inte avlägsnas förrän alla handtag tagits bort. Översiktsobjekt används också för att ätkomma innehállen i de andra typerna av registreringar son1finns, sessionsregistreringen och trafikfallsregistreringen. Som nämnt ovan är en uppgift för 503 394 10 översiktsobjektet att förse användaren med ett skräddarsytt gränssnitt på en hög abstraktionsnivå gentemot en registrering.

Med skräddarsytt menas att gränssnittet ger användarna åtkomst endast till objekt som behöver vara åtkomliga, vilket kan vara endast en del av det totala innehållet i en registrering.

Den andra huvuduppgiften för översiktsobjektet gentemot transak- tionsregistreringen och trafikfallsregistreringen är att de kan fungera som handtag. Sá länge som en registrering har ett handtag kan den inte tas bort. När det sista handtaget gentemot en registrering tas bort tas också registreringen och allt dess innehåll bort från den lokala minneslagringen. Det är uppenbart att detta skapar en mycket förmånlig lokal minneshantering.

Koppelregistreringsutmatningsmekanismen redan nämnd används för att mata ut innehållet i en transaktionsregistrering för efterbe- arbetning. Det skall noteras att innehållen i sessionsregistre- ringen och trafikfallsregistreringen och en transaktionsregistre- ring finns endast under varaktigheten av denna speciella session och kommer att försvinna när sessionen avslutas. Utmatnings- mekanismen är uppbyggd kring ett antal hanterade objekt som innehåller tagglistor. I ett telekommunikationssystems funktion finns till exempel ett behov att samla debiteringsdata för att kunna på riktigt sätt debitera de olika abonnenterna. I figur 5 exemplifieras vad som kan ske i en session. Ett kontrollobjekt "debitering" har öppnat ett objekt Cro_Type. Detta speciella objekt Cro_Type innehåller en tagg-lista hämtad från databasen som anger dataobjekten som kan tas ut ur transaktionsregistre- ringen. Cro_Type beordras sedan sammanställa en rapport in- nehållande dataobjekten identifierade av tagg-listan som är lagrad i databasen. Kontrollobjektet använder sedan gränssnittet för Cro_Type för att samla in data under den speciella sessionens existens. Data kan packas i en data-area som sedan sänds till en efterbearbetningsnod. Följaktligen kan ett debiteringsunderlag på grund av ökade tjänster ändras vid vilket som helst ögonblick genom enkel modifiering av tagg-listan utan att alls interferera med det existerade systemet som har en struktur i enlighet med 503 394 ll den föreliggande uppfinningen.

Det effektiva resultatet av detta är att även om innehällen i de olika sessionerna definieras som lokala data är det möjligt att samtidigt använda önskade delar av innehållet som om det utgör globala data. En skillnad mellan lokala och globala data är till exempel att de senare av nödvändighet normalt måste allokeras i pà förhand fastställa minnespositioner för att kunna àtkommas av andra användare.

I den belysande utföringsformen använder vi tre typer av hanterade objekt för att åstadkomma den flexibla utmatnings- mekanismen beskriven här. De kallas 'CroServiceTemplate', 'CroType' och 'CroCustomerTemplate'. Den första hanterade objekttypen, 'CroServiceTemplate' används för specifikation av vilka data som är möjliga att ta ut för en speciell bas- eller tilläggstjänst. 'CroServiceTemp1ate' innehåller ett attribut, möjliga TAG, som anger vilka data som är möjliga att ta ut ur transaktionsregistreringen, TR, för en speciell tjänst, till exempel i detta sammanhang en "bastjänst“ eller ett "trepartskop- pel".

Den andra hanterade objekttypen är 'CroType' vilken används för specifikation av en viss utmatningstyp. Varje exempel på 'CroType' är kopplad till en eller flera exempel pá 'CroService- Template'. Föreningen av data i dessa 'CroServiceTemplate' bestämmer vilka data som är möjliga att mata ut för en speciell 'CroType'.

Det tredje och sista.hanteringsobjekttypen är 'CroCustomerTempla- te' som är ett hanterat objekt för en speciell kund i en speciell utmatningstyp, 'CroType'.

Figur 6 demonstrerar ett litet exempel med villkoren: - Det finns två kunder, A och B.

- Det finns tvâ tjänster, "baskoppel" och "trepartskoppel".

- Det finns två 'CroType', 'Crotype1' och CroType2' 503 394 12 Eftersonxdet finns två tjänster behöver vi två 'CroServiceTempla- te': - 'CroServiceTemplate' för baskoppel, som innehåller taggar 1, 2, 5, och 8.

- 'CroService Template' för trepartskoppel, som innehåller taggar 1, 2, 6 och 9.

Detta betyder att för "baskopplet" kan vi mata ut data lagrade i TR med taggarna 1, 2, 5, och 8, medan för tjänsten "tre- partskoppel" kan vi mata ut data lagrade under taggarna 1, 2, 6, och 9.

Vi kan sedan definiera två utmatningstyper, 'CroType1' konstrue- rad så att den kommer att kunna mata ut data relaterade till båda tjänsterna och 'CroType2' konstruerad så att den kommer att kunna utmata data relaterade till baskopplet. I figur 6 åskådliggörs grundstrukturen och relationen mellan de skapade hanterade objekten.

En 'CroCustomerTemplate' krävs för varje kund och 'Crotype' för att bilda utmatningsmekanismen "koppelregistreringsutmatning", CRO, i stånd att utföra utmatningar av alla "CroType' till alla kunder. Detta resulterar i detta exempel i totalt fyra 'CroCusto- merTemplate'. I figur'7 demonstreras den resulterande strukturen.

Kund A kräver alla möjliga taggar ur 'CroType1' och tagg nr 1 och 2 ur 'CroType2' och kund B kräver taggar med lägre numer än 8 från alla 'CroType'. Vi har då en slutlig struktur som ut- matningsmekanismen CRO behöver för att bilda en riktig för- delning. Vi har specificerat vilka datafält alla olika kunder behöver ur alla olika 'CroType'.

En slutdel av dataflödet i figur 4 beskriver när data skall sändas till det andra halvkopplet. Halvkopplen kommunicerar med hjälp av telekommunikationstjänstprotokollet, TSP. TSP bär självidentifierande parametrar. En parameter innehåller ett dataobjekt och identifieras av en tagg, vilken i en belysande utföringsforu1kan innehålla ett antal bitgrupper, t.ex. 16 binära 503 394 13 bitar. Mottagaren kan fastställa vilka data som tas emot genom att titta pá taggen. Taggen vilken används för att identifiera en parameter i TSP är sama tagg som används för att identifiera data lagrade i TR.

I figur 8 sammanfattas ett antal steg i ett enkelt flödesdiagram för en koppeldatasammanfattning i en transaktionsregistrering under koppelbearbetning. En sådan bearbetning startas i ett steg 100. I ett första steg 101 i processen tas ett meddelande emot via ett externt protokoll. Det tas emot i en protokollagent i en dynamisk process i systemet. Därefter i ett steg 102 omvandlas data från en extern representation till en intern representation.

Ett dataobjekt skapa i processen. Detta dataobjekt innehåller då den interna representationen av mottagna data.

I ett tredje steg 103 lagras dataobjektet under ett unikt taggelement i en transaktionsregistrering. Under koppelbe- arbetningen hämtas data i ett fjärde steg 104 frán transaktions- registreringen med användning av ett transaktionsregistrerings- översiktsobjekt, som då använder taggelementet för att få den korrekta pekaren PTR, för att återskapa specificerade data.

När kopplet upphör, eller när en utmatning av koppeldata önskas av statistik- eller debiteringsskäl, kallas funktionen koppel- registreringsutmatning :í ett femte steg 105. Denna funktion àtkomer databasen för att finna ut vilka data, som skall matas ut. Som ett resultat fär funktionen en lista över taggelement. önskade data hämtas från TR i steg 104 och läggs till en utmatningsbuffert. Denna buffert kan sedan matas ut till ett externt media. Data kan senare efterbearbetas för att till exempel skapa debiteringsinformation osv.

Slutligen i figur 9 visas med hjälp av tre steg i ett enkelt flödesdiagram en specifikation av data, som skall inkluderas i en utmatning. Proceduren startar i steg 200. I ett steg 201 bestämmer tillhandahállaren av tjänsten, eller någon annan operatör som administrerar systemet, vilka data som skall matas 503 394 14 ut för olika koppeltyper. Dessa olika utmatningstyper specifice- ras i ett andra steg 202 genom att fylla i mallar med listor för taggar, som skall utmatas. I ett sista steg 203 lagras dessa mallar i databasen genom att, till exempel, mata in listan med taggar med hjälp av en separat terminal och/eller ett tangent- bord. Dessa inmatade tagglistor àtkoms senare under koppelbe- arbetningen. Inmatning av tagglistan kommer inte att interferera med den allmänna koppelbearbetningen i telekommunikationssystemet för att initiera och avsluta trafikfall, distribuera information från átkomstprotokollet till det rätt trafikfall, initiera nya tjänster, etc., utan när den är inmatad kommer den att bestämma vilka data, som skall lagras i databasen för efterbearbetning.

Det kommer att inses av fackmannen att olika modifikationer och ändringar kan göras pá hårdvaran/mjukvaran i enlighet med den föreliggande uppfinningens koncept utan att avvika frán andeme- ningen och omfattningen av detta, vilket definieras av de bilagda patentkraven.

Claims (10)

503 394 15 PATENTKRAV

1. Förfarande för att strukturera anropsbearbetning i ett telekommunikationssystem, lämpligen med hjälp av mjukvara, för att skapa en standardmässigt och allmän struktur, vilken gör det möjligt att utsträcka systemet med nya tjänster och data utan att påverka en redan existerande arbetande huvudmjukvara för systemet som använder halvkoppelprincipen, k ä n n e t e c k n a t av kombination av denna halvkoppelprincip med ett allmänt protokoll mellan de exekverande halvkopplen och inkluderande en session innefattande en sessionsomfattning och en trafikfallsomfattning vilka använder minnesfunktioner i vilka olika registreringar lagrar pekare (PTR) till en lokal minnesfunktion, varvid pekarna kombineras med ett taggelement (TAG) med 'vars hjälp lokalt lagrade data kan unikt idetifieras och kan, trots att inte vara verkliga reella globala data, fortfarande användas som globala data under en specifik sessions varaktighet under vilken period en speciell registrering existerar.

2. Förfarande enligt krav 1, k ä n n e t e c k n a t av att den speciella sessionsomfattningen använder en sessionsregistre- ring (SR) för lagring' av' pekare till exekveringsobjekt för kopplet och ur vilken registrering det komer att vara möjligt att hitta alla andra objekt i sessionen om taggelelemten (TAG) under vilka objekten lagras är kända, varjämte andra objekt lagras i en transaktionsregistrering (TR) refererad av en sessionsregistrering (SR) eller av en trafikfallsregistrering.

3. Förfarande enligt krav 2, k ä n n e t e c k n a t av att trafikfallsomfattningen har en liknande struktur som sessions- omfattningen och trafikfallsregistreringen refereras fràn sessionsregistreringen (SR) och trafikfallsregistreringen skapas för att lagra exekveringsobjekt för ett koppel.

4. Förfarande enligt krav 2, k ä n n e t e c k n a t av att transaktionsregistreringen lagrar dataobjekt som tillhör trafik- fallet. 503 394 16

5. Förfarande enligt något av kraven 1 till 4, k ä n n e - t e c k n a t av att taggelementet (TAG) realiseras genom ett heltal unikt tilldelat varje exekveringsobjekt eller dataobjekt som lagras.

6. Växelsystem för telefoni med koppelbearbetning, vilket gör det möjligt att utvidga systemet med nya tjänster och data utan att påverka en redan existerande arbetande huvudmjukvara för systemet som använder halvkoppelprincipen, k ä n n e t e c k - n a t av att halvkoppelprincipen kombineras med ett allmänt protokoll mellan de exekverande halvkopplen och inkluderande en session som innefattar en sessionsomfattning och en trafik- fallsomfattning vilka använder minnesfunktioner i vilka olika registreringar lagrar pekare (PTR) till en lokal minnesfunktion, varvid pekarna kombineras med ett taggelement (TAG) med vars hjälp lokalt lagrade data kan unikt idetifieras och kan, trots att inte vara verkliga reella globala data, fortfarande användas som globala data under en specifik sessions varaktighet under vilken period en speciell registrering existerar.

7. System enligt krav 6, k ä n n e t e c k n a t av att den speciella sessionsomfattningen använder en sessionsregistrering (SR) för lagring av pekare till exekveringsobjekt för kopplet och ur vilken registrering det kommer att vara möjligt att hitta alla andra objekt i sessionen om taggelelemten (TAG) under vilka objekten lagras är kända, varjämte andra objekt lagras i en transaktionsregistrering (TR) refererad av en sessionsregistre- ring (SR) eller av en en trafikfallsregistrering.

8. System enligt krav 7, k ä n n e t e c k n a t av att trafikfallsomfattningen har en liknande struktur som sessions- omfattningen och trafikfallsregistreringen refereras från sessionsregistreringen (SR) och trafikfallsregistreringen skapas för att lagra exekveringsobjekt för ett koppel. 503 394 17

9. System enligt krav 8, k ä n n e t e c k n a t av att transaktionsregistreringen lagrar dataobjekt som tillhör trafik- fallet.

10. System enligt något av kraven kraven 6 till 9, k ä n n e - t e c k n a t av att taggelementet (TAG) realiseras genom ett heltal unikt tilldelat varje exekveringsobjekt eller dataobjekt som lagras.