SE503393C2 - Förfarande och system för en flexibel koppelregistreringsmekanism - Google Patents

Description

503 393 2 speciellt för telekommunikationssystem. Strukturen förenklar speciellt realtidkommunikationen mellan objekten i enlighet med CCIT XZOO. 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- ochmmjukvaruegenska- per.

EP-A2-0 470 415 beskriver en metod att förse ett antal applika- tionsprocessorer i ett telefonsystem med tillgång till koppel- relaterad information i en gemensam databas. 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.

SAMANFATTNING AV UPPFINNINGEN Det är därför ett behov i ett telekommunikationssystem att skapa en koppelregistreringsmekanism, som gör det möjligt att utsträcka systemet med nya tjänster och data utan att påverka redan ex- isterande arbetande mjukvara i ett system som utnyttjar halv- koppelprincipen.

Ett första syfte i enlighet med den föreliggande uppfinningen är att i en session som utför koppelbearbetning göra den lokala tillfälliga lagringen av data med hjälp av minnespekare i registreringar associerade med varje exekverad session, varvid pekaren vidare kombineras med ett taggelement med vars hjälp lokalt lagrade data kommer att unikt identifieras och kan under sessionens varaktighet selektivt uppkallas med en registrerings- översiktsobjektfunktion och lagras i en databas för efterföljande bearbetning.

Ett andra syfte i enlighet med den föreliggande uppfinningen är att den speciella sessionen använder en sessionsregistrering och en transaktionsregistrering för att lagra pekare och taggar för objekt respektive data i sessionen och ur vilka registreringar det kommer att vara möjligt att hitta alla objekt och data i ~ 503 393 3 sessionen om taggelementet är känt under vilket önskad datain- formation är lagrad.

Ett tredje syfte i enlighet med den föreliggande uppfinningen är att i koppelbearbetningen definieras en trafikfallsomfattning med en liknande struktur som en session och en trafikfallsregistre- ring skapas och refereras från sessionen för att lagra ex- ekveringsobjekt för ett koppel och vidare i trafikfallsregistre- ringen finns det en transaktionsregistrering som lagrar data som tillhör trafikfallet.

Ett fjärde syfte i enlighet med den föreliggande uppfinningen är att tjänster kan ändras vid vilken som helst tidpunkt genom enkel modifikation av en tagglista lagrad i en lokal databas utan att interferera med det existerande arbetande övergripande systemet.

Ett femte syfte i enlighet med den föreliggande uppfinningen är att taggelementet realiseras genom ett heltal, lämpligen som ett binärt ord, som är unikt tilldelat varje exekveringsobjekt eller dataobjekt som används i en session.

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 tillsammans 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 kommunikation 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 503 393 4 referenser till exekveringsobjekt och en transaktions- registrering för att lagra referenser till dataobjekt, 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 koppeldatasamman- 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 kommer 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 som kontrollerar ett 503 393 5 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- 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-sessionsstyrningem 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 Originerande 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 Telekommunikationstjä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- 503 393 6 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 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 gemensamma 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 Sessionsregistreringsöversikt och ger användaren ett gräns- snitt till sessionsregistreringen pá en hög abstraktionsnivà. På samma sätt refereras som Transaktignsregistreringsöversikten en användares översikt av en transaktionsregistrering och ger an- vändaren ett gränssnitt till transaktionsregistreringen på 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 503 393 7 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 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 503 393 8 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 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 och 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, C. Dataflödet startar när några data mottas av 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 med 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 telekommunikaf tionstjänstprotokollet, TSP. Data sänds i en parameter vilken förutom data innehåller taggen som identifierar den. 503 393 9 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 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. Genom anvä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.

Anta 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 nummer' 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 503 393 10 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 som finns, sessionsregistreringen och trafikfallsregistreringen. Som nämnt ovan är en uppgift för ö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 503 393 ll 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 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. 'CroServiceTemplate' 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'. 503 393 12 Det tredje och sista hanteringsobj ekttypen ä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' , 'Crotypel' och CroType2' Eftersom det 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, 'CroTypel' 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 nummer än 8 från alla 'CroTypeH Vi har dà en slutlig struktur som ut- matningsmekanismen CRO behöver för att bilda en riktig för- 503 393 13 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öringsfornnkan innehålla ett antal bitgrupper, t.ex. 16 binära 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 samma 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 :L ett femte steg 105. Denna funktion åtkommer 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 503 393 14 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 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 (12)

503 393 15 PATENTKRAV

1. Förfarande för en flexibel koppelregistreringsmekanism i ett telefon- eller telekommunikationssystem, vilket 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'att vid tidpunkten för en exekvering av en session för koppelbearbetning görs den lokala tillfälliga lagringen av' data med hjälp av minnespekare (PTR) i registreringar (SR, TR) associerade med varje exekverad session, varvid pekaren (PTR) vidare kombineras med ett taggelement (TAG) med vars hjälp speciella önskade lokalt lagrade data kommer att unikt identifieras och kan under sessionens varaktighet selektivt uppkallas av en registrerings- översiktsobjektfunktion och därefter lagras i en extern databas för efterföljande bearbetning.

2. Förfarande enligt krav l, k ä n n e t e c k n a t av att den speciella sessionen använder en sessionsregistrering (SR) och en transaktionsregistrering (TR) för lagring av pekare (PTR) och taggar (TAG) för objekt respektive data i sessionen, och ur vilka registreringar det kommer att vara möjligt under sessionens existens att ta ut vilka som helst objekt eller data i sessionen om taggelementet (TAG) är- känt under 'vilket önskad datain- formation lagras.

3. Förfarande enligt krav 2, k ä n n e t e c k n a t av att i koppelbearbetningen definieras en trafikfallsomfattning med en liknande struktur som en sessionsomfattning och en trafikfalls- registrering 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 i trafikfallsregistreringenlagrarentzansaktionsregistrering(TR) data som tillhör trafikfallet. 503 393 16

5. Förfarande enligt krav 4, k ä n n e t e c k n a t av att tjänster kan ändras vid vilken som helst tidpunkt genom enkel modifikation av en tagglista i en lokal databas utan att in- terferera med det existerande övergripande arbetande systemet.

6. Förfarande enligt krav 4, k ä n n e t e c k n a t av att taggelementet (TAG) realiseras genonnett heltalsnummer, lämpligen som ett binárt ord, unikt tilldelat varje exekveringsobjekt eller dataobjekt som skall lagras.

7. System för' koppelregistreringsmekanisnl för' ett telefoni eller telekommunikationssystem, son1gö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 d av' att med hjälp av en minnespekare (PTR) lagras lokalt temporära sessionsobjekt eller data i registreringar associerade med varje exekverad session i koppelbearbetningen som utförs, varvid pekaren (PTR) vidare kombineras med ett taggelement (TAG) med vars hjälp speciellt önskade temporärt lokalt lagrade data kommer att unikt identifieras och kan. under sessionens varaktighet selektivt uppkallas av en registreringsöversiktsobjektfunktion och därpå lagras i en extern databas för efterföljande bearbetning.

8. System enligt krav 7, k ä n n e t e c k n a t av' att den speciella sessionen använder en sessionsregistrering (SR) och en transaktionsregistrering (TR) för lagring av pekare (PTR) och taggar (TAG) för objekt respektive data i sessionen, och ur vilka registreringar det kommer att vara nñjligt under sessionens existens att ta ut vilka som helst objekt eller data i sessionen om taggelementet (TAG) är känt under' vilket önskad datain- formation lagras.

9. System enligt krav 8, k ä n n e t e c k n a t av att en trafikfallsomfattning'har en liknande struktur sonxen session- somfattning och en trafikfallsregistrering refereras frán 503 393 17 sessionsregistreringen och trafikfallsregistreringen skapas för att lagra exekveringsobjekt för ett koppel.

10. System enligt krav 9, k ä n n e t e c k n a t av att i trafikfallsregistreringenlagrarentransaktionsregistrering(TR) data som tillhör trafikfallet.

11. System enligt krav 10, k ä n n e t e c k n a t av att tjänster kan ändras vid vilken som helst tidpunkt genom enkel modifikation av en tagglista i en lokal databas utan att in- terferera med det existerande övergripande arbetande systemet.

12. System enligt krav 11, k ä n n e t e c k n a t av att taggelementet (TAG) realiseras genom ett heltalsnummer, lämpligen som ett binärt ord, unikt tilldelat varje exekveringsobjekt eller dataobjekt som skall lagras.