SE503392C2 - Förenklad bearbetning vid fleranrop - Google Patents

Description

503 392 2 Enligt teknikens stàndpunkt finns åtskilliga koncept avseende objektorienterade mjukvarustrukturer för bearbetning i ett modernt telekommunikationssystem. EP-A1-0 524 089 med titeln “Structure de logiciel pour système de télécommunications" beskriver ett system med logisk struktur för att bearbeta data, speciellt för tele- kommunikationssystem. Strukturen förenklar speciellt realtid- kommunikationen mellan objekten i enlighet med CCIT X200. EP-A1-O 524 077 med titeln "Structure de logiciel pour système de traite- ment d'informations“ beskriver en struktur som för tillämpningspro- gram döljer hárdvaru- och mjukvaruegenskaper.

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 i en gemensam databas. Informationen taggas och lagras temporärt som en registrering i databasen så länge som kommunikationenmpàgàr. Informationen är speciellt inriktad att vara direkt synlig pá en presentationsterminal för övervakning i ett operatörsstyrt växelsystem.

Ett annat problem inbegriper hur en flerkoppelsituation effektivt hanteras. Ett flerkoppel betyder att ett koppel med mer än tvâ abonnenter skall kunna sättas upp. När ett koppel upprättas från en abonnent (A) till en annan abonnent (B) sätts uppkopplingen upp på normalt sätt. När en tredje abonnent (C), som indikerat i fig. 1 anropar den första abonnenten (A) skall det vara möjligt att ansluta kopplet, dvs. att den första abonnenten (A) får en indikation att ett annat anrop kommer in och kan acceptera eller förkasta detta.

SAMMANFATTNING AV UPPFINNINGEN Det är därför ett behov i ett telekommunikationssystem att med mjukvara och/eller hårdvara skapa en standardmässig och allmän struktur för flerkoppel, 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. 503 392 3 Ett första syfte i enlighet med den föreliggande uppfinningen i en process som utnyttjar en halvkoppelprincip innefattande en session inbegripande en sessionsstyrning som hanterar halvkopplet är att skapa en första ingångsport för att hantera protokollet från en samtalsförfràgan och samtidigt också skapa en andra ingångsport för att hantera en andra samtalsförfrågan, varvid det säkerställs att den andra samtalsförfrågningen som riktas till den andra ingångs- porten inkorporerad i sessionen kommer att kunna ansluta ett pågående koppel om parten som har det pågående kopplet accepterar den andra samtalsförfrågningen.

Ett andra syfte i enlighet med den föreliggande uppfinningen är att samtalsförfrågningen kommer att tas emot av en uppkopplingsserver, vilken leder samtalsförfrágningen till sessionen.

Ett tredje syfte i enlighet med den föreliggande uppfinningen är att sessionen använder en minnesfunktion i vilken olika registre- ringar lagrar referenser i form av pekare till en lokal minnes- funktion, varvid en pekare är kombinerad med ett taggelement med vars hjälp lokalt lagrade data kommer att unikt identifieras.

Ett fjärde syfte i enlighet med den föreliggande uppfinningen är att sessionen. använder en sessionsregistrering för lagring av referenser i form av pekare till exekveringsobjekt och till dataobjekt för kopplet och från vilken registrering det kommer att vara möjligt att finna alla andra objekt i sessionen, om taggele- ment, under vilka objekt lagras, är kända.

Ett femte syfte i enlighet med den föreliggande uppfinningen är att sessionen innefattar en trafikfallsomfattning med en liknande struktur som en sessionsomfattning, och en trafikfallsregistrering refereras från sessionsregistreringen, och trafikfallsregistrering- en skapas för att lagra referenser till exekveringsobjekt för ett koppel. 503 392 4 Ett sjätte syfte i enlighet med den föreliggande uppfinningen är att en transaktionsregistrering lagrar dataobjekt som tillhör ett trafikfall.

Ett sjunde syfte i enlighet med den föreliggande uppfinningen är att taggelementet realiseras med ett heltal som unikt tilldelas varje exekveringsobjekt eller dataobjekt som används.

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 illustrerar ett allmänt fall som inbegriper en flerkop- pelsituation, Figur 2 .illustrerar allmänt principen som använder ett halvkoppel A och ett halvkoppel B, Figur 3 är en illustration av en session med en sessionsstyrning, SC, som hanterar åtskilliga trafikfall inbegripande för varje trafikfall ett respektive originerande koppel, OC i kommunikation med andra trafikfall inbegripande ett respektive terminerande koppel, TC, Figur 4 visar en sessionsstyrning, SC som använder i enlighet med förfarandet och systemet enligt den föreliggande upp- finningen en sessionsregistrering för att lagra referen- ser till exekveringsobjekt och en transaktionsregistre- ring för att lagra referenser till dataobjekt, Figur 5 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 Figur Figur Figur Figur Figur Figur Figur 6 7 8 9 10 11 12 13 503 392 5 är den demonstration av objekt som styr dataflödet i en session, visar ett exempel när data för ett debiteringsunderlag uttas från en session, visar' i ett: enkelt exempel sambandet mellan skapade skötta objekt, visar den fullständiga statiska överblicken i enlighet med det enkla exemplet i fig. 8, illustrerar hur en statisk process representerad av uppkopplingsservern startar en dynamisk process med hjälp t' .Å-O-r av sessionsstyrningen visad i fig. 4, visar stegen för att skapa en session för ett halvkoppel när abonnenten inte har något aktivt koppel, visar stegen i linje med stegen enligt fig. ll i enlighet med den föreliggande uppfinningen för att ansluta en session när parten redan har ett aktivt koppel, samt är en sammanfattning av bearbetning av en flerkoppelför- bindelse inbegripande tre abonnenter i enlighet med den föreliggande uppfinningen.

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 503 392 6 kopplet i två halvor, ett Halvkoppel A och ett Halvkoppel B. Detta illustreras i fig. 2. Mjukvaran som kontrollerar ett halvkoppel exekveras i en process benämnd en Session. En session kan hantera ett eller flera Trafikfall samtidigt (till exempel i en flerkoppel- situation). Trafikfallet definierar funktionaliteten och data som hanterar ett koppel i en session. Notera även att ett trepartskop- pel 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 Trafikfallsomfatt- ningen. Detta illustreras i fig. 3. Sessionsomfattningen kontrolle- ras av Grundflödes-sessionsstyrningen, SC. Huvuduppgiften för ses- sionsstyrningen är att verka som en kommandotolk gentemot Åtkomst- protokollet, ACP och göra en tjänstanalys på dessa kommandon (Med- delanden). Detta inbegriper då, till exempel, initiering och termi- nering av nya trafikfall, distribution av information från åtkomst- protokollet till rätt trafikfall, initiering av nya tjänster, osv.

Varje trafikfall i sessionen styrs av ett basflöde. Ett sådant bas- flöde kan vara antingen ett Originerande koppel, OC eller ett ïgg; minerande 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 hante- ring av Telekommunikationstjänstprotokollet, TSP, mellan halvkop- pel), beställning av upprättande/urkopplande av förbindelser (till exempel en talförbindelse), beställning av adressinformations- analys, 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 Dataobjek . 503 392 7 Ett exekveringsobjekt kommer att exekveras i sessionen, t. ex. styrobjekt, protokollobjekt, resursobjekt, osv. Ett rent dataobjekt kommer att innehålla data mottagna till exempel frán ett Tele- tjä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 Sessionsregistrering och används för att lagra pekare till protokollobjekt instantierade av styr- och resursobjekt i sessionen. Objekten lagrade i sessionsregistre- ringen är gemensamma för hela sessionen. För lagring av referenser till rena dataobjekt används en Transaktionsregistrering. Pá liknande sätt som sessionsregistreringen lagrar pekare till objekt används också transaktionsregistreringen (också kallad .koppel- registrering) för att lagra pekare till rena dataobjekt instantie- rade 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änssnitt till sessionsregistreringen pà en hög abstraktionsnivà. På samma sätt refereras som Transaktionsregistreringsöversikten en an- vändares översikt av en transaktionsregistrering och ger användaren ett gränssnitt till transaktionsregistreringen pá en hög abstrak- tionsnivà.

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 trafikfallsregistreringrefererastillenflkafikfallsregistrerings- översikt och ger användaren ett gränssnitt till sessionsregistre- ringen pà en hög abstraktionsnivá. 503 392 8 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 telekommunikationssys- tem behöver vi en lämplig datastruktur. Data måste struktureras för att göra det möjligt att implementera och underhålla tillämp- ningarna. 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 sammanfattning ä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 3 ä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 3 innehåller sessionen ett eller flera trafik- fall, 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 telekommunikationstjänstprotokoll, TSP.

Som indikerat i figur 4 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 503 392 9 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 5 ä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 1 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 trafik- fallet används följaktligen en transaktionsregistrering, 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 exekveringsobjekten eller dataobjekten kan åtkommas.

Figur 6 demonstrerar mera i detalj dataflödet genom en session som exekverar ett originerande koppel, OC. 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 transaktionsregist- reringsöversiktsobjekt, TR_View. Ovanstående exempel illustrerar när data sänds av utmatningsagenten till det andra halvkopplet via telekommunikationstjänstprotokollet, TSP. Data sänds i en parameter vilken förutom data innehåller taggen som identifierar den. 503 392 10 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 1 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 392 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 7 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 392 12 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- pelfl.

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 pa '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 392 13 Det tredje och sista hanteringsobjekttypen är 'CroCustomerTempla- te' som är ett hanterat objekt för en speciell kund i en speciell utmatningstyp, 'CroType'.

Figur 8 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.

- 'CroServiceTemplate' 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 l, 2, 6, och 9.

Vi kan sedan definiera två utmatningstyper, 'CroType1' konstrue- rad så att den kommer att kunna utmata data relaterade till båda tjänsterna och 'CroType2' konstruerad så att den kommer att kunna utmata data relaterade till baskopplet. I figur 8 å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 1 totalt fyra 'CroCusto- mer'I'emplate' . I figur 9 demonstreras den resulterande strukturen.- Kund A kräver alla möjliga taggar ur 'CroTypel' och tagg nr 1 och 2 ur 'CroType2' och kund B kräver taggar med lägre nummer ä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- 503 392 -14 CRO behöver för att bilda en riktig fördelning. Vi har specificerat vilka datafält alla olika kunder behöver ur alla olika 'CroType'.

En slutlig del av dataflödet i figur 6 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öringsform kan 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.

Som redan nämnt är ett sätt att strukturera mjukvara i ett koppelbearbetande växelsystem för telefoni att dela styrningen av kopplet i två halvor. Detta refereras till som halvkoppelprincipen och betyder att varje del av ett koppel styrs av dess egna mjuk- vara. Genom kombination av detta med ett lämpligt allmänt protokoll mellan dessa koppelhalvor är det möjligt att bygga upp ett system som är mycket enkelt att utsträcka med nya telefontillämpningar.

Denna struktur demonstreras även i fig. 2.

Nu kommer att beskrivas ett sätt, till exempel med hjälp av objekt- orienterad programmering, i vilket i enlighet med den föreliggande uppfinningen en av dessa koppelhalvor kan struktureras för att göra det lätt att ansluta ett koppel till ett redan upprättat koppel, det vill säga flerkoppel, vilket till exempel kan vara ett "trepartskoppel" som diskuterats ovan.

Som redan beskrivet refereras som en session en mjukvara och/eller hårdvara, som hanterar ett objekt för ett halvkoppel. Sessionen är en dynamisk process som uppstartas av uppkopplingsservern (SUS). En. session har som redan nämnts en huvudkontrolldel kallad sessions- styrning (SC) och en lagringsstruktur kallad en sessionsregistre- 503 392 15 ring (SR). I sessionsregistreringen lagras referenser till alla exekveringsobjektcxflxdatastrukturer'för sessionen. Detta illustre- ras även i fig. 10.

När ett koppel startas kommer en uppkopplingsserver (SUS) att ta emot en samtalsförfràgan pá sin portagent. Uppkopplingsservern kontrollerar först att denna förfrågan är giltig, dvs., att destinationen är korrekt. Sedan kontrollerar uppkopplingsservern om en ny session skall skapas eller om en existerande session kan anslutas (en existerande session indikerar att den uppropade parten redan har ett aktivt koppel). Fig. 10 indikerar denna situation.

I fallet när den anropade parten inte har något aktivt koppel skapar uppkopplingsservern längs vägen 1 i fig. ll en ny dynamisk session för den anropade parten. I detta exempel skapas en sessionsprotokollagent, PA-B, i fig. 11 vid 2 för att hantera protokollet från samtalsförfrágan. Dà startas styrlogiken CL vid 3a och 3b för att ta över sessionen. Styrlogiken skapar en datastruk- tur vid 4 refererad till som sessionsregistreringen, som disku- terats tidigare, för att lagra information om sessionen före att en protokollinmatningsport startas vid 5, i detta fall PEP-B för att hantera de mottagna meddelandena. För att göra det möjligt för ett annat koppel att ansluta till sessionen startar även styrlogiken vid (5 en annan protokollinmatningsport PEP-A. Samtalsförfràgan kommer nu vid 7 att överföras till protokollagenten PA-B vilken kontrollerar denna före att vid 8 överföra den till styrlogiken CL.

Fortsättningen beror av vad samtalsförfrágan innehåller och hur styrlogiken skall hantera detta och kommer att vara uppenbart för fackmannen.

En viktig punkt här är att objektet PEP-A, den andra inmatnings- porten skapas vid detta tillfälle. Om den inte skapas vid detta tillfälle màste detta göras vid ett senare steg eftersom det finns en risk att få en annan förfrågan till samma abonnent. Vid en senare tidpunkt finns det uppenbart en risk att en annan process 503 392 16 kommer att skapas parallellt med den existerande processen. I detta fall skulle det vara komplicerat att uppnå den önskade flexibilite- ten för att ansluta till det pågående kopplet, om överhuvud taget ens möjligt. Alltså är det viktiga att styrlogiken CL genom att skapa två protokollinmatningsportar (PEP-B och PEP-A) möjliggör att ett annat koppel enkelt ansluter till denna pågående session.

Om den anropade parten redan har ett aktivt koppel, det vill säga att en session redan existerar för denna part när uppkopplingsser- vern får en annan samtalsförfrågan ll för denna part, kommer uppkopplingsservern att upptäcka detta och sedan försöka ansluta till den existerande sessionen som illustrerat i fig. 12. Upp- kopplingsservern kontrollerar först databasen, dvs. sessions- registreringen, för adresser till den tillgängliga protokollin- matningsporten PEP-A och överför sedan vid 12 samtalsförfrågan till denna port. Protokollinmatningsporten PEP-A alstrar då en pro- tokollagent PA-A vid 13 och sänder ett meddelande vid 14 till styrlogiken CL att ett meddelande kommer på den skapade pro- tokollagenten PA-A. Denna förfrågan om samtal som nu har överförts från uppkopplingsservern SUS-A till protokollagenten PA-A (vid 16) kommer att sändas till styrlogiken 17, som börjar hantera med- delandet. Fortsättningen beror på vad samtalsförfrågan innehåller och hur styrlogiken CL skall hantera detta.

Det viktiga här är att uppkopplingsservern SUS-A kan nå information om var protokollinmatningsporten är. Denna information hittas i sessionsregistreringen SR. Uppkopplingsservrarna SUS-A och SUS-B har en gemensam data-area, möjligen i en allmänn lokal databas där information om sessionerna lagras.

Om ännu en annan förfrågan om samtal kommer till uppkopplingsser- vern SUS-A för samma part som tidigare, som redan har två koppel aktiva, kommer uppkopplingsservern att överföra meddelandet till protokollinmatningsporten PEP-A. Protokollinmatningsporten PEP-A kommer då att skapa en ny protokollagent (en andra PA-A) som 503 392 17 beskrivet tidigare. Denna nya förfrågan kommer INTE att överföras till den existerande protokollagenten PA-A eftersom det finns två olika samtal som inte skall blandas. Strukturen sålunda beskriven öppnar upp ett sätt att enkelt utsträcka sessionen för en flerkop- peltjänst utan att faktiskt interferera med det övergripande telekommunikationsväxelsystemet.

Fig. 13 demonstrerar en sammanfattning av ett flerkoppelbearbet- ningsfall som inbegriper tre abonnenter. PA-A och PA-B tillhör här två olika trafikfall men hanteras av samma session och sessions- styrning SC. I ett av trafikfallen är abonnenten B det terminerande kopplet, medan i den andra trafikfallet abonnenten C är ett originerande koppel. Eftersom båda dessa trafikfall hanteras av samma session kommer det att vara enkelt för abonnenten A eller B att åtkommas av abonnenten C: som till exempel försökte anropa abonnent A eller B redan upptagna av ett samtal.

Sammanfattningsvis, för varje ny samtalsförfrågan som tas emot för en speciell part kommer en ny protokollagent att skapas för att hantera samtalet. Alla exekveringsobjekt och.dataobjekt som tillhör den speciella sessionen kommer att vara definierade av sin TAG i sessionsregistreringen och respektive pekare PTR kommer att ge en adress till lagringspositionen i minnet. Fördelarna kommer att vara: 0 det visade förfarandet skapar en standardmässig och allmän struktur gemensam för alla telekommunikationstillämpningar, vilket gör det möjligt att utsträcka med vilket som helst antal koppel till en speciell part, o förfarandet skapar en struktur som är enkel att utsträcka med nya samtal (TSP-samtal). Detta görs utan att påverka grund- funktionerna, 0 förfarandet skapar en struktur som betyder att all hantering av data och växelverkan för en speciell part kan centraliseras i en dynamisk process, samt 503 392 18 0 ur karakteristiksynvinkel, prestationsförmága och minnesan- vändning, betyder detta att all koordination och datamanipule- ring kan utföras i den dynamiska processen utan någon mellan- processkommunikation.

Det kommer att inses av fackmannen att olika modifikationer och ändringar kan göras på hårdvaran/mjukvaran :L 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 (14)

503 392 '19 PATENTKRAV

1. Förfarande för att strukturera bearbetning av flerkoppel i ett telekommunikationssystem, lämpligen genom mjukvara, som skapar en standardmässig och allmän struktur, vilken gör det möjligt att utsträcka systemet med nya tjänster utan att påverka en redan existerande huvudfunktionshárd- och mjukvara för systemet med användning av halvkoppelprincipen, k ä n n e t e c k n a t av att i en process som använder halvkoppelprincipen innefattande en session innehållande en sessionsstyrning (SC) som hanterar halvkopplet skapas en första inmatningsport (PEP-B) för att hantera protokollet för en samtalsförfràgan och samtidigt skapas också en andra inmatningsport (PEP-A) för att hantera en andra samtals- förfrågan, varvid det säkerställs att denna andra samtalsförfrágan riktad till den andra inmatningsporten inkorporerad i sessionen kommer att vara i stånd att ansluta ett pågående koppel om parten som har det pàgàende kopplet accepterar denna andra samtalsför- frågan.

2. Förfarande enligt krav 1, k ä n n e t e c k n a t av att samtalsförfràgan tas emot av en uppkopplingsserver, som riktar samtalsförfràgan till sessionen.

3. Förfarande enligt krav 2, k ä n n e t e c k n a t av att sessionen använder en minnesfunktion i vilken olika registreringar lagrar referenser i form av pekare till en lokal minnesfunktion, varvid en pekare (PTR) kombineras med ett taggelement (TAG) med hjälp av vilket lokalt lagrade data kommer att unikt identifieras.

4. Förfarande enligt krav 3, k ä n n e t e c k n a t av att sessionen använder en sessionsregistrering (SR) för lagrande av referenser i form av pekare till exekveringsobjekt och till dataobjekt i kopplet och ur vilken registrering det kommer att vara möjligt att lokalisera alla andra objekt i sessionen, om taggele- ment (TAG) är kända under vilka objekt lagras. 503 392 20

5. Förfarande enligt krav 4, k ä n n e t e c k n a t av att sessionen innefattar en trafikfallsomfattning med en liknande struktur som sessionsomfattningen och en trafikfallsregistrering som refereras från sessionsregistreringen (SR) och trafikfalls- registreringen skapas för att lagra referenser till exekverings- objekt för ett koppel.

6. Förfarande enligt krav 5, k ä n n e t e c k n a t av att en transaktionsregistrering (TR) lagrar dataobjekt som tillhör trafikfallet.

7. Förfarande enligt krav 6, k ä n n e t e c k n a t av att taggelementet (TAG) realiseras med ett heltalsnummer unikt tilldelat till varje använt exekveringsobjekt eller dataobjekt.

8. System för bearbetning av flerkoppel i växel för telefoni, lämpligen med hjälp av mjuk- och/eller hårdvara, som skapar en standardmässig 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 huvudhårdvara och mjukvara i systemet som använder halvkoppelprincipen, k ä n n e t e c k n a t av att i en process som använder halvkoppelprincipen innefattande en session som innehåller sessionsstyrning (SC) som hanterar halv- kopplet skapas en första inmatningsport (PEP-B) för att hantera protokollet från en samtalsförfrågan och samtidigt alstras även en andra inmatningsport (PEP-A) för att hantera en andra samtalsför- frågan, varvid det säkerställs att denna andra samtalsförfrågan riktad till den andra inmatningsporten inkorporerad i sessionen kommer att vara i stånd att ansluta ett pågående koppel om parten som har det pågående kopplet accepterar denna andra samtalsför- frågan.

9. System enligt krav 8, k ä n n e t e c k n a t av att denna samtalsförfrågan tas emot av en uppkopplingsserver (SUS) som riktar förfrågan till sessionen. 503 392 21

10. System enligt krav 9, k ä n n e t e c k n a t av att sessionen använder en minnesfunktion i vilken olika skilda registreringar lagrar referenser i form av pekare till en lokal minnesfunktion, varvid en pekare (PTR) kombineras med ett taggele- ment (TAG) med hjälp av vilket lokalt lagrade data kommer att vara unikt identifierade.

11. ll. System enligt krav 10, k ä n n e t e c k n a t av att sessionen använder en sessionsregistrering (SR) för lagrande av referenser 1 form av pekare till exekveringsobjekt och till dataobjekt i kopplet och ur vilken registrering det kommer att vara möjligt att lokalisera alla andra objekt i sessionen, om taggele- ment (TAG) är kända under vilka objekt lagras.

12. System enligt krav ll, k ä n n e t e c k n a t av att sessionen innefattar en trafikfallsomfattning med en liknande struktur som sessionsomfattningen och en trafikfallsregistrering som refereras fràn sessionsregistreringen (SR) och trafikfalls- registreringen skapas för att lagra referenser till exekverings- objekt för ett koppel.

13. System enligt krav 12, k ä n n e t e c k n a t av att en transaktionsregistrering (TR) lagrar dataobjekt som tillhör trafikfallet.

14. System enligt krav 13, taggelementet (TAG) realiseras med ett heltalsnummer unikt tilldelat till varje använt exekveringsobjekt eller dataobjekt.