SE502423C2 - System för hantering av interaktion mellan tilläggstjänster i ett telekommunikationssystem - Google Patents

Description

502 423 2 vissa extra- eller tilläggsfunktioner, som skiljer olika pro- dukter av samma typ. Vissa telefoner kan exempelvis ha en åter- uppringningsknapp, som tillåter användaren att lätt slå det sist slagna numret. Vissa faxmaskiner har möjlighet att lyssna på registrerade budskap från var som helst i nätet.

I ovan definierade sammanhang förekommer vissa begrepp som kan behöva klarläggas här, och av vilka några nämns ovan och i fortsättningen. Dessa begrepp är: _ - Nätoperatör; detta är en organisation, som driver ett fysiskt kommunikationsnät. Exempel i Sverige är Telia.

- Systemtillverkare; detta är en organisation, som skapat och tillhandahåller ett kommunikationsnät för nätoperatören. I Sverige är detta Ericsson för Telia. I Nederländerna är det Ericsson och AT&T för holländska PTT.

- Användare; detta är en person eller organisation, som kan utnyttja en tjänst i ett kommunikationsnät. Begreppet användare används därför ej utan att vara relaterat till en tjänst eller grupp av tjänster. Ofta är en användare detsamma som en abon- nent.

- Tillhandahållare av tjänst; detta är en person eller organisation, som tillhandahåller en tjänst för en eller flera användare. Dagens tillhandahållare av tjänster är normalt den- samma som nätoperatören, ett förhållande, som även förväntas bestå inom en förutsebar framtid. Tillhandahållare av tjänster kan även vara användare av tjänster, som tillhandahålls av en annan tillhandahållare.

Varje användare i ett telekomunikationsnät använder detsamma huvudsakligen för att kommunicera med andra användare. För att användaren skall kunna använda funktionerna i nätet, t.ex. upprätta ett koppel, måste användaren abonnera, dvs bli abon- nent, på tillämpliga tjänster. Om en användare önskar använda basfunktioner hos systemet, måste således användaren abonnera på rätt bastjänster, och om en användare önskar utnyttja tilläggs- funktioner hos systemet måste användaren abonnera på rätt till- läggstjänster.

Genom ett abonnemang tillhandahålls således en viss tjänst för en användare. Användaren, eller tillhandahållaren av tjäns- ten på användarens vägnar, kan då aktivera motsvarande funktion.

Funktionen kommer då att utföra vissa åtgärder åt användaren. En 502 423 3 koppelbegäran aktiveras exempelvis genom att telefonluren lyfts.

'Call Forwarding' är en funktion, som när den aktiveras vidare- befordrar koppel, som är destinerade till den användare, för vilken tjänsten tillhandahålls, till en alternativ destination.

Eftersom tjänster tillhandahålls på per-användar-grundval, bör den aktiverade funktionen inte ha större inverkan på sys- temet än vad som bestäms av överenskommelse mellan användaren och tillhandahållaren av tjänster, som del av tjänstavtal. 'Call Waiting' medger t.ex. köande av koppel till en upptagen access.

När tjänsten tillhandahålls begränsas de accesser för vilka 'Call Waiting' kan köa koppel till den access, som användaren hyr av tillhandahållaren. Denna funktion sägs därför vara "akti- verad för accessen", av en användare, som äger accessen. Om accessen ägs av flera användare, som är möjligt exempelvis i ISDN, kommer endast sådana koppel att köas, vilka är destinerade för den användare, som aktiverat 'Call Waiting'.

Begreppen basfunktioner och tilläggsfunktioner, i den be- tydelse de här används, liksom nedan närmare behandlade interak- tioner, är välkända för fackmannen på området. I korthet utgörs varje basfunktion och tilläggsfunktion av kod, som exekveras av datorer i telekommunikationssystemet. I ett användningsfall sker aktivering av en önskad tílläggstjänst genom hoppinstruktion i den exekverade basfunktionens kod.

Rekommendationer rörande, och beskrivning av basfunktioner och tilläggsfunktioner förekommer inom exempelvis GSM-systemet.

Så kan t.ex. hänvisas till rekommendation 02.04 beträffande de ovan använda benämningarna, såsom 'Call Waiting' etc., på några olika tilläggsfunktioner.

I anslutning till beskrivningen av tilläggsfunktioner, vilka kan utsättas för interaktionsproblemet, förekommer även en beskrivning av ifrågavarande interaktion och dess verkan.

Det kan även finnas tilläggsfunktioner, som är tillämpbara endast för tillhandahållaren av tjänster, dvs. ingen användare har access till sådana tilläggsfunktioner. Tillhandahållaren av tjänster behöver inte abonnera på en tjänst innan dessa till- läggsfunktioner aktiveras. Många tilläggsfunktioner för nät- underhåll aktiveras exempelvis för en överföringsväg: tilläggs- funktioner som introducerar prioritetslinjer inom överförings- vägen, eller tilläggsfunktioner som automatiskt blockerar vägen 502 423 4 under vissa förhållanden. Även användare kan hyra överförings- vägar, eller snarare en användare, som representerar en grupp av användare, t.ex. en affärsgrupp. I detta fall måste användaren abonnera på en tjänst innan några tilläggsfunktioner kan aktive- ras av användaren avseende denna överföringsväg.

Ju fler tjänster som är tillgängliga desto attraktivare är en tillhandahållare av dessa tjänster för "potentiella" användare.

Det är därför väsentligt för tillhandahållaren att kunna offere- ra en konkurrenskraftig uppsättning av tjänster, både bastjäns- ter och tilläggstjänster. Utbjudande av nya tilläggstjänster anses vara det snabbaste sättet att uppnå detta på grund av att implementeringen av den ingående tilläggstjänsten endast kräver små modifieringar av basfunktionen. En stark utvidgning av antalet tilläggstjänster kan därför väntas. Detta kräver en kort introduktionscykel, dvs. från det behovet uppkommer till in- stallationen, av nya tilläggstjänster. Eftersom tillhandahållande- och aktiveringsprinciperna är mycket rakt på sak, kommer det att vara tilläggstjänstsdelen, som kan utgöra ett hinder för uppnående av korta introduktionscykler. Dessa tilläggstjänster implementeras mestadels i mjukvara.

Att utbyta ett komplett telekomsystem varje gång en ny tilläggstjänst introduceras är för dyrt. Ett minimikrav på ett system är därför att det måste vara modulärt. Ett modulärt system medger införing av nya och avlägsnande av gamla tilläggs- funktioner utan att påverka andra installerade tilläggsfunktio- ner. Varje tilläggsfunktion installeras som en separat ladd- ningsmodul.

Denna modularitet kan uppnås genom en plattform. Plattformen innehåller basfunktionerna. Den implementerar även ett eller flera gränssnitt. Varje gränssnitt länkar en eller flera till- läggsfunktioner till basfunktionerna, vilket medger interaktion mellan tilläggs- och basfunktionerna.

En tilläggsfunktion kan bestå av en eller flera länkmoduler - en per gränssnitt, som tilläggsfunktionen önskar använda. En länkmodul är en modul som kan länkas till ett gränssnitt utan att vid länkningen påverka andra moduler som är länkade till samma gränssnitt.

Varje gränssnitt består av operationer och triggrar. Triggrar är anrop till operationer, vilka när de exekverar utför specifi- 502 423 5 ka ändringar i basfunktionens beteende. När dessa ändringar uppträder sänds motsvarande trigger till de till gränssnittet länkade tilläggstjänsterna. Varje tilläggstjänst kan därpå reagera på triggern genom att beordra plattformen att utföra en eller flera operationer. Plattformen komer att schemalägga exekveringen av tilläggstjänsterna, dvs. bestämma i vilken ordning tilläggstjänster skall mottaga triggern.

Detta medför en dubbelriktad interaktion mellan plattform och tilläggstjänster.

Gränssnittet är öppet, varmed i föreliggande sammanhang avses att det dels skall vara generellt för alla tjänster, dels att det skall kunna användas av mer än en tjänst i samma system. Med andra ord finns det inte några operationer eller triggrar som är specifika för någon tilläggstjänst. Själva plattformen får inte innehålla någon kod som är specifik för någon tilläggstjänst.

Framtida uppgraderingar av plattformen måste implementera gräns- snitt, som är kompatibla med tidigare versioner. Dessa egenska- per säkerställer modularitet mellan plattformen och tilläggs- funktionerna. Tilläggsfunktionerna kan installeras, konstrueras och uppgraderas utan att påverka plattformen, och plattformen 'kan uppgraderas utan att påverka tilläggsfunktionerna.

De flesta användare kommer endast att ha aktiverat ett fåtal tilläggsfunktioner. Det är därför viktigt att hanteringen av triggrar optimeras för att undvika en mängd overhead i proces- sorkapaciteten. För varje aktivering av en basfunktion, t.ex. vid ett anrop eller en operatörprocedur, bör sålunda en trigger endast mottagas av de tilläggsfunktioner som är tillämpliga för denna specifika aktivering. Detta kan uppnås genom att bygga den länkbild, som anger vilka tilläggsfunktioner, som länkas till ett gränssnitt, under exekveringen av själva basfunktionen.

Endast tilläggsfunktioner som är aktiverade kommer då att länkas och triggrar kommer endast att sändas till dem. Om ett visst anrop exempelvis innefattar en överföringsväg, för vilken en tilläggsfunktion är aktiverad, kommer rätt länkmodul i denna tilläggsfunktion att länkas till anropet. Tilläggsfunktionen kan nu mottaga triggrar från anropet. Denna procedur benämns ofta "dynamisk länkning" (Dynamic Linking). För ytterligare optime- ring kan triggrar endast sändas till en deluppsättning av de länkade tilläggsfunktionerna, nämligen de som har uppvisat 502 423 6 intresse för denna trigger. En sådan mekanism benämnes "övervak- ning" (monitoring).

Dynamisk länkning är inte ovanlig. I C++ kan principen för "dynamisk bindning" användas för att implementera dynamisk länk- ning. I PLEX bär signaler (mekanismen som används för att kommu- nicera mellan moduler) sin destination som dynamiska data. I AXE-10 används denna i PLEX ingående funktion för att implemen- tera en "trafik-länk" (= ett aktivt anrop), där modulerna kan "inlänkas“ eller "sidolänkas“ (= dynamisk länkning).

Med den konventionella tekniken inom området är vissa problem behäftade.

När väl en plattform implementeras på ovan beskrivet sätt uppnås modularitet mellan tilläggsfunktionen och plattformen.

Genom att använda samma plattform kan olyckligtvis tilläggs- funktioner komma i konflikt med varandras beteende. För att möjliggöra lösande av en konflikt mellan två eller flera till- läggsfunktioner är det känt att konstruera de av konflikten berörda tilläggsfunktionerna så, att de interagerar med varandra för att lösa konflikten. Mellan tilläggsfunktioner i denna struktur finns sålunda ingen naturlig modularitet, som hindrar att konflikter uppstår. Jämför t.ex. 'Call Forwarding on Busy' och 'Call Waiting'. 'Call Forwarding on Busy' vidarekopplar ett koppel om användaren är upptagen. 'Call Waiting' kommer i stäl- let att köa koppel för den upptagna användaren. De två tilläggs- funktionerna måste interagera för att uppnå en överenskommelse.

Båda kan exempelvis vara aktiverade, men om den ursprungliga destinationen svarar först, stoppas ringning till den alternati- va destinationen, och om den alternativa destinationen svarar först kommer kopplet att avlägsnas från 'Call Waiting'-kön.

Så länge som det inte finns så många tilläggsfunktioner i systemet kan interaktioner rätt enkelt implementeras i själva tilläggsfunktionerna. Med växande antal tilläggsfunktioner blir den totala introduktionscykeln för varje ny tilläggsfunktion längre på grund av att fler och fler redan installerade till- läggsfunktioner måste uppgraderas. Detta kan till slut leda till en introduktionsstörning i systemet. Detta problem benämns ofta kort och gott interaktionsproblem. Varje lösning måste garantera modularitet mellan alla tilläggsfunktioner. Uppfinningen utgår från den insikten att interaktioner ej bör implementeras i 502 423 7 själva tilläggsfunktionerna. Naturligtvis får emellertid sättet detta sker på ej skapa fler problem än det löser.

I en traditionell arkitektur är koordinationsmekanismen, i form av den mjukvara som löser konflikter mellan tilläggsfunk- tionerna, logiskt en del av plattformen, men implementeras som en separat modul, dvs. den kan uppgraderas separat. Från en tilläggsfunktions synpunkt tillhör koordinationsmodulen platt- formen. Så länge som ingen koordination krävs kommer koordina- tionsmodulen endast att vidarebefordra beordrade operationer från tilläggsfunktioner till plattformen och sända triggrar från plattformen till en eller flera tilläggsfunktioner. Koordina- tionsmodulen kommer även att utföra den dynamiska länkning som krävs.

Koordinationsmodulen kommer att detektera en konflikt anting- en när en tilläggsfunktion åstadkommer en operation eller när plattformen sänder en trigger. Den logik som detekterar en konflikt benämns detekteringslogik och har access till följande information: - Tilläggsfunktioner länkade till den specifika aktiveringen.

- Tidigare operationer av länkade tilläggsfunktioner.

- Triggrar som sänts tidigare till länkade tilläggsfunktio- ner. _ _ - Den föreliggande operationen/triggern.

- Information som kan lagras i plattformen och accessas av koordinationsmodulen. T.ex. 'call-state'.

Koordinationsmodulen kan därpå utföra koordinativa aktioner för att undvika en konflikt. Detta benämns även “lösningslogik".

De innefattar: - Schemaomläggning av exekveringen av tilläggsfunktioner på en trigger.

- Ignorering, ersättning, eller utsträckning av specifika operationer från vissa tilläggsfunktioner, eller av vissa trigg- rar till vissa tilläggsfunktioner.

Denna traditionella väg leder till ett löst förhållande mellan tilläggsfunktionslogiken och interaktionslogiken, dvs. detekteringslogik plus lösningslogik, hos denna tilläggsfunk- tion. Till följd härav är inget tilläggsfunktionsrelaterat data 502 423 8 eller kod direkt åtkomligt genom koordinationsmodulen, med undantag av data lagrat i plattformen, t.ex. en databas. Inte ens data i databasen kan vara säkert. Tilläggsfunktioner kopie- rar ofta detta data under exekvering och använder därpå denna kopia för ytterligare processande. En annan följd av denna struktur är att det inte existerar någon återkoppling till tilläggsfunktionen. Tilläggsfunktionen är därför ovetande om huruvida de av densamma beordrade operationerna exekverades omodifierat, eller om den inte mottog en övervakad trigger. Till följd därav är tilläggsfunktioner så enkla som möjligt, men interaktionslogiken blir följaktligen mer komplicerad. De in- volverade komplikationerna är: - En stor del av exekveringen av tilläggsfunktioner består av operationer mot plattformen. En mycket detaljerad kännedom om tilläggsfunktionen krävs därför, förmodligen mera detaljerad än vad som i verkligheten behövs för att lösa alla möjliga kon- flikter hos tilläggsfunktionaliteten (ingen abstraktion möjlig).

- Om visst data krävs för ett korrekt beslut, måste detta data extraheras från de operationer som tilläggsfunktionen beordrar. Datat måste lagras tills det efterfrågas av interak- tionslogiken. Ändringar i datat måste likaså övervakas genom extrahering av dessa ändringar från efterföljande operationer.

Förutom komplexiteten med övervakning av datat och dess ändring- ar, kräver det återigen en detaljerad kännedom om tilläggsfunk- tionens interna arbetssätt.

- Alla ändringar i en tilläggsfunktions exekveringsflöde måste övervakas omsorgsfullt av detekteringslogiken, om olika grenar i exekveringsflödet kan leda till olika konflikttyper.

Ett löpande tillstånd hos tilläggsfunktionen måste upprätthållas i koordinationsmodulen. Eftersom beslutslogik och iterationslo- gik ej kan övervakas direkt, måste operationer och deras data tolkas för att erhålla den nödvändiga informationen. Återigen kräver detta detaljerad kännedom om tilläggsfunktionens inre arbetssätt.

- Exekveringsflödet i tilläggsfunktionen kan ej påverkas på. annat sätt än genom att returnera ett specifikt resultat för en operation, eller sända triggrar till tilläggsfunktionen. Dessa resultat och triggrar är inte specifika för tilläggstjänsten.

Till följd härav är möjligheterna att påverka tilläggstjänstens 502 423 9 uppförande minimala. Efter att en konflikt lösts kan det krävas att tilläggsfunktionen fortsätter på annat sätt än tidigare.

Detta kanske inte är möjligt. Lösningslogiken måste då även ta över alla normala, icke konfliktande funktioner hos tilläggs- funktionen, tills tilläggsfunktionen kan triggas på sådant sätt att den skulle kunna fortsätta. Under mellantiden måste till- läggsfunktionen blockeras.

Vissa av de beskrivna negativa effekterna kan delvis kompen- seras. En tilläggsfunktion kan exempelvis sända viss information till koordinationsmodulen, såsom ett tillstånd att ange besluts- flödet i tilläggsfunktionen. Eftersom tilläggsfunktionen ej är medveten om när denna information skulle behöva tillämpas, behöver den alltid sändas. Detta leder till ineffektiv använd- ning av minne och processorkapacitet. En annan möjlighet är att undvika de negativa effekterna genom att endast ange enkla interaktioner. Sådana interaktioner styrs ofta av prioriteter som är tilldelade till tilläggsfunktionerna. Dessa prioriteter beslutar schemaläggning av tilläggsfunktionerna (högre prioritet före lägre prioritet) eller kan leda till blockering av låg- prioriterade tilläggsfunktioner. System som utnyttjar denna arkitektur har i praktiken visat sig vara tämligen framgångsrika vid hantering av dessa enkla interaktioner, eftersom interak- tionslogiken ganska lätt kan styras av tabeller. Ett exempel är den önskade interaktionen mellan 'Call Forwarding on Busy' och 'Call Waiting'. Båda agerar på en trigger 'Busy Access'. 'Call Forwarding' skulle då vidareleda anropet till en alternativ destination, medan 'Call Waiting' skulle köa anropet för acces- sen tills den blir tillgänglig. Interaktionen skulle kunna vara att blockera 'Call Forwarding' så att anropet i stället kan köas.

"Intelligentare" lösningar föredras emellertid ofta. I fallet 'Call Forwarding' och 'Call Waiting' skulle man exempelvis kunna besluta att göra bådadera och låta interaktionen besluta på grundval av den som svarar på anropet först. Detta skulle exem- pelvis kräva möjligheten att eliminera 'Call Waiting' om den alternativa destinationen svarar. En annan möjlighet är att vidareleda anropet om 'Call Waiting' av någon anledning ej lyckas, t.ex. för att inga resurser finns tillgängliga för att sända en ton till användaren, eller på grund av time-out från 502 423 10 användaren. Detta skulle kräva sändande av 'Busy'-triggern igen, men endast till 'Call Forwarding', och endast om det föreliggan- de tillståndet hos anropet skulle vara kompatibelt med 'Call Forwarding'.

Tilläggsfunktionens konstruktion blir sålunda enklare men interaktionslogikens konstruktion blir mer komplicerad som resultat. Detta var acceptabelt när inte så många tilläggsfunk- tioner fanns installerade. Tillhandahållare av tjänster har vanligen inga strikta krav på interaktioner, varför de flesta interaktioner hålls så enkla som möjligt. I och med att använda- re blir mer medvetna om tillgängliga och potentiella tilläggs- funktioner kräver de fler tilläggsfunktioner snabbare och mer komplicerade interaktioner.

US 5 115 432 beskriver en arkitektur för datakommunikation anpassad för kommunikation över (höghastighets-) nätverk. Med datakommunikation avses här exempelvis fil-, röst- eller video- data. Arkitekturen består av två nivåer. Den högre nivån består av ett antal oberoende "horisontalfunktioner" som utförs paral- lellt. Den lägre nivån består av basfunktioner gentemot nätver- ket. Alla lågnivåfunktioner och motsvarande processer utföres i en funktion för styrning av access till nätverket. Eventuella beroenden mellan horisontalfunktionerna löses med hjälp av en därför avsedd funktion. Arkitekturen erbjuder således dessa "horisontalfunktioner" att interagera på en nivå som är skild från den låga nivån.

EP 228 053 hänför sig till ett sätt för att kontrollera ett telekommunikationssytem i realtid. En struktur beskrivs, som medger att tilläggsfunktioner enkelt kan modifieras/programmeras samt att interaktioner mellan olika tilläggsfunktioner kan lösas på ett enkelt sätt. Lösningen enligt dokumentet är att pro- grammen skrivs med hjälp av "scripts" på ett “non procedural language" och består av ett antal tripletter. Interaktionen mellan dessa "scripts" medger att "scripts" med en högre nivå kan tillåta "scripts" på en lägre nivå att implementeras om dess tripletter indikerar detta.

US 4 928 304 beskriver ett elektroniskt växelsystem för ett telekommunikationsnät, i form av en telefonväxel och en därtill kopplad extern dator. Programsekvenser nödvändiga för standard- funktioner finns lagrade i minnesenheter i telefonväxeln. Pro- 502 423 11 gram för att genomföra tjänster som bara en del av abonnenterna har tillgång till, finns lagrade i den externa datorn. Via den externa datorn kan man, med hjälp av ett dator-gränssnitt, styra vissa funktioner hos telefonväxeln. Denna arkitektur innebär att ändringar av de olika tilläggsfunktionerna enkelt kan genomföras genom att göra ändringar i den externa datorns program.

Syftet med föreliggande uppfinning är att åstadkomma en ny grundarkitektur, som medger ti1läggsfunktionstransparens i plattformen och interaktionstransparens i tilläggsfunktionerna.

Med grundarkitektur avses här arkitekturen på gränssnittsnivå, dvs. där de olika typerna av gränssnitt är identifierade, möjli- ga principer för bildande av gränssnitten, samt hur och genom vilken typ av mjukvara de används.

Detta syfte uppnås, enligt den första aspekten, vid ett system av inledningsvis definierat slag genom att interaktionslogiken innefattar interaktionsmoduler, varje tilläggsfunktion likaledes implementerar åtminstone ett öppet gränssnitt, vilket medger interaktion mellan interaktions- modulerna på sådant sätt att nya interaktionsmoduler, som är avsedda att interagera med tilläggsfunktionen genom användning av detta gränssnitt, kan adderas till systemet utan att påverka denna tilläggsfunktion, dessa öppna gränssnitt används av interaktionsmodulerna för att interagera med tilläggsfunktionerna på sådant sätt att konflikter mellan tilläggsfunktionerna undviks.

Enligt uppfinningen uppnås syftet vid ett system av inled- ningsvis definierat slag enligt den andra aspekten, genom att även interaktionslogiken består av länkmoduler, och att dessa länkmoduler och tilläggsfunktionernas länkmoduler är belägna i var sitt plan, varvid tilläggsfunktionerna och deras nämnda gränssnitt är transparenta för interaktionslogiken, och interak- tionslogikens länkmoduler är länkningsbara till tilläggsfunktio- nerna.

Hed det ovan och i fortsättningen använda begreppet implemen- tering avses i mjukvarusammanhang konstruktion av program som är nödvändiga för att uppfylla en viss specifikation. Specifika- tionen definierar vad man vill att mjukvaran skall göra, och so2i42s 12 skulle kunna vara ett dokument i klarspråk. Implementering av ett gränssnitt i mjukvarusammanhang innebär implementering av all mjukvara som krävs för att kunna länka andra moduler till gränssnittet, under antagande av att mjukvaran som implementerar gränssnittet är installerad. Gränssnitt specificeras vanligen separat på grund av att genom ett gränssnitt sammanlänkade moduler vanligen är konstruerade av olika konstruktörer, eller till och med olika företag. Länkning innebär att en till ett gränssnitt länkad modul kan utföra operationer definierade i gränssnittet, och mottager triggrar, som är definierade i gräns- snittet när de är tillämpliga. I det senare fallet måste mjuk- varan som implementerar gränssnittet säkerställa att triggern sänds till de länkade modulerna.

Ett gränssnitt kan ej implementeras utan att språket på något sätt stöder modulär konstruktion, dvs varje modul kan konstrue- ras separat, men modulerna kommer att interagera efter konstruk- tionen (och detta kan ske under kompilering, under installation eller under exekvering) för att åstadkomma komplett implemente- ring av mjukvarudelen. Alla moderna språk åstadkommer redan modulär konstruktion. De flesta språk implementerar emellertid endast begreppet "operationer" (även kallade metoder, meddelan- den osv, beroende på det använda språket) som medel för att åstadkomma interaktion. På senare tid har det emellertid dykt upp allt flera språk, som implementerar även triggrar (eller "händelser" eller "detekteringspunkter", återigen beroende på det använda språket). Dessa benämns mestadels "visuella" språk, varvid det mest kända är "Visual Basic" för MS-Windows. I själva verket kan det i praktiken vara bättre att inte använda benäm- ningen operation alls, utan endast triggrar, eftersom de i princip innebär samma sak. Den enda lilla skillnaden är att i ett öppet gränssnitt den modul som implementerar gränssnittet måste sända triggern till flera moduler, emedan modulerna som är länkade till detta gränssnitt endast kommer att kunna sända triggrar (operationer) till de moduler som implementerar gräns- snittet. Men i princip innebär det i båda fallen att en modul sänder information till en annan och att den andra modulen då kan reagera på denna information på ett passande sätt.

För att belysa definitionen ovan av uppfinningen enligt den första aspekten kan vidare följande nämnas. 502 423 13 Vid sammanlänkning av två moduler är allt som behövs att modulerna skall kunna utbyta information avseende triggrarna och operationerna i gränssnittet. Dessa är minnesadresserna för alla operationer och triggrar (dvs operationens eller triggerns första instruktion). Minnesadressen för operationen hålls av modulen som implementerar gränssnittet, medan minnesadressen för triggrarna hålls av moduler som länkas till gränssnittet, och dessa kan vara olika för olika länkmoduler. När en länkmodul installeras kommer den att hämta de adresser för gränssnittets operationer, till vilka länkning skall ske, från en databas (det antas att mjukvaran som implementerar gränssnittet redan har installerats och lagrat denna information i databasen), och den kommer att sända information avseende mottagna triggrar till modulerna som implementerar gränssnittet. Dessa kommer att lagras i tabeller på vardera sidan. Närhelst en operation utförs kommer modulen som utför operationen att titta i tabellerna som innehåller adresserna för operationen, för att finna den korrek- ta adressen att hoppa till. När en trigger sänds till en speci- fik funktion, kommer omvänt modulen som implementerar gränssnit- tet att titta i de tabeller den har för funktionen, och som innehåller adresserna för triggern i funktionen, för att finna rätt adress i funktionen att hoppa till. Ovanstående utförs mestadels av operativsystemet.

Operationer och triggrar är kontextkänsliga, t.ex. en opera- tion kan gälla för ett visst koppel. Med det sätt att arbeta, som processorer har idag, innebär detta att samma instruktion kan exekveras (så att samma minnesadresser kan användas), men dessa instruktioner kommer att arbeta med koppelspecifika data.

En referens till var dessa data kan återfinnas (benämnd instans) sänds även tillsammans med operationen. Omvänt gäller detsamma.

De åtgärder som skall utföras vid mottagning av en trigger kan även vara beroende på tillståndet hos denna instans.

Eisælässkrixnins Utföringsformer av uppfinningen skall nu beskrivas närmare nedan med hänvisning till bifogade ritningar, på vilka fig. 1 i blockschemaform åskådliggör de allmänna principerna för uppbyggnad av arkitekturen hos ett system enligt uppfin- ningen, med ett tilläggsfunktionsplan och ett interaktionslogik- 502 423 14 plan, fig. 2 likaledes i blockschemaform åskådliggör hur i arkitek- turen enligt fig. 1 gränssnittet mellan en tilläggsfunktion och interaktionsplanet kan innehålla flera generella gränssnitt, fig. 3 i flödesschemaform åskådliggör interaktion mellan två tilläggsfunktioner, fig. 4 i blockschemaform åskådliggör en modul för generella funktioner, fig. 5 i ett block- och flödesschema åskådliggör ett sätt att lösa konflikter mellan tilläggsfunktioner.

En ei lifi . E I fig. 1 visas ett telekommunikationssystem strukturerat att omfatta en uppsättning basfunktioner i en plattform 2 och en uppsättning tilläggsfunktioner 4 i ett plan 6. Tilläggsfunktio- nerna 4 är var och en anslutbar till en viss basfunktion för att utgöra ett tillägg till och modifiera denna basfunktion. Bas- funktionerna implementerar ett eller flera öppna gränssnitt 8, vilka är generella för alla tilläggsfunktioner, och vilka medger interaktion mellan basfunktionerna och tilläggsfunktionerna på sådant sätt att nya tilläggsfunktioner kan tillföras systemet utan att påverka basfunktionerna. Interaktionslogik finnes i ett plan 10 för att lösa problem med att de respektive beteendena hos två tilläggsfunktioner, som samtidigt är anslutna till en viss basfunktion, kan komma i konflikt med varandra.

Varje tilläggsfunktion 4 implementerar likaledes åtminstone ett generellt gränssnitt 12, vilket medger interaktion mellan en tilläggsfunktion och interaktionshanterare 14, som ingår i interaktionslogiken 10. Såsom kommer att framgå nedan är gräns- snittet 12 närmare bestämt så konstruerat att ifrågavarande interaktion sker på så sätt att nya interaktionshanterare, som är avsedda att interagera med den ifrågavarande tilläggsfunktio- nen genom användning av detta gränssnitt, kan adderas till systemet utan att påverka tilläggsfunktionen.

Gränssnitten 12 används av interaktionshanterarna 14 för att interagera med tilläggsfunktionerna 4 på sådant sätt att kon- flikter mellan tilläggsfunktionerna undviks.

Det i fig. 1 visade systemet kan användas för hantering av utnyttjandet av basfunktioner och tilläggsfunktioner i ett 502 423 15 telekommunikationsnät, som innehåller ett flertal användare, som kan anropa varandra och abonnerar på bastjänster och tilläggs- funktioner avseende bas- resp. tilläggsfunktionerna.

Grundtanken hos uppfinningen är att tilläggsfunktioner 4, liksom plattformen 2, skall implementera ett generellt gräns- snitt, som kan användas av interaktionslogiken 10.

De två planen 6 resp. 10 består vardera av en eller flera modu- lära produkter.

På samma sätt som plattformen 2 och gränssnitten 8 mellan plattform och tilläggsfunktioner bör vara transparenta för de användande tilläggsfunktionerna, måste tilläggsfunktionerna 4 och deras gränssnitt 12 mellan tilläggsfunktioner och interak- tionslogik vara transparenta för den användande interaktions- logiken. Vidare skall länkmoduler 16 i interaktionslogikplanet 10 länkas dynamiskt till aktiverade tilläggsfunktioner.

Varje interaktionshanterare 14 är i stånd att lösa en speci- fik interaktionskonflikt och består av åtminstone en länkmodul 16 per tilläggsfunktion, som används av interaktionshanteraren.

När en ny tilläggsfunktion 4 introduceras, skall den uppträda med alla de nödvändiga länkmodulerna 16 i de olika interaktions- hanterarna 14 som krävs för att hantera alla interaktioner med andra tilläggsfunktioner 4.

En laddningsmodul består av länkmoduler 16 i samma interak- tionshanterare 14, vilka beror av varandra.

När en länkmodul 16 inte används längre, antingen genom att tilläggsfunktionen vars gränssnitt den använder avlägsnas, eller på grund av att den ej längre används av någon annan länkmodul i interaktionshanteraren, avlägsnas den laddningsmodul, i vilken länkmodulen ingår.

Hed hänvisning till fig. 2 kan det gränssnitt 12 en tilläggs- funktion 4 bildar mot interaktionslogikplanet 10 bestå av flera generella delar 18,20,22, dvs. operationer och triggrar som är identiska i olika tilläggsfunktioner. En tilläggsfunktion analy- seras på ett tidigt stadium för att identifiera dess egenskaper.

Varje egenskap kommer då att relateras till ett generellt gräns- snitt. Det finns exempelvis en tilläggsfunktion, som inte accep- terar att vissa koppel fortsätter, vilka bastjänsten normalt skulle tillåta fortsätta. Denna tilläggsfunktion modifierar därmed bastjänstens beteende så att kopplet upplöses. Alla 502 423 16 tilläggsfunktioner som medför upplösning av ett koppel måste t.ex. stödja det generella gränssnittet 18 'release-call', dvs "upplös koppel". Detta gränssnitt 18 kommer att bestå av vissa triggrar och operationer, som kan tillämpas på tilläggsfunktio- ner som upplöser kopplet. En 'call-to-be-released'-trigger och en 'hold-release'-operation skulle t.ex. även kunna bilda del av detta generella gränssnitt 18.

Detta att ett gränssnitt, som bildas av tilläggsfunktioner, kan innehålla flera generella delar, som är identiska för en grupp tilläggsfunktioner, medger mera generell detekterings- och lösningskod, som kan användas av alla interaktionshanterare. Det medger även s.k. scriptprogrammering. Denna typ av programmering utvecklas idag för konstruktion av tilläggsfunktioner, och som exempel kan nämnas Ericssons SSI (Service Script Interpreter), jfr Ericsson Review nr 67, 1990. En tilläggsfunktion skapas genom sammanlänkning av generella moduler, vilka även benämns "SIB" (Service Independent Building Blocks). Länkarna mellan dessa SIB benämns "script". Denna script länkas dynamiskt till ett gränssnitt och tolkas därpå. Varje SIB utför en aktion på en hög abstraktionsnivå och använder plattforms-tilläggsfunktion- gränssnittet för att implementera denna aktion. Nya SIB kan konstrueras utan att påverka plattformen. Arkitekturen enligt uppfinningen medger att dessa samma produktivitetsökande verktyg kan användas i interaktionslogikplanet 6.

Med hänvisning till fig. 3 skulle t.ex. interaktionen: Block 'Call Forwarding on Busy' if 'Call Waiting applies' kunna skapas med användning av ett fåtal SIB. De SIB som krävs är 'Block Feature' 24, som blockerar den tilläggsfunktion till vilken nämnda script är länkad, en SIB 26 som sänder information från en länkmodul till en annan i samma interaktionshanterare, en SIB 28 som mottar denna information, och en SIB 30 som värderar den mottagna informationen för beslut. Dessa SIB länkas tillsammans till bildande av två script: en som är länkad till 'Call Waiting' 32, och en annan som är länkad till 'Call Forwarding' 34.

Sänd-SIB 26 kommer att sända informationen 'feature applies' 36 till den mottagande SIB 28 i 'Call Forwarding', där 'feature' är fyllt med namnet hos den tilläggsfunktion 32 till vilken SIB 26 är länkad. I detta fall gäller 'Call Waiting'. Informationen 502 4-23 17 sänds vid mottagande av triggern 'feature applies' från 'Call Waiting' 32. Denna trigger utgör del av det generella gränssnit- tet och indikerar att tilläggsfunktionen 32 begär att få verka för första gången efter aktivering av basfunktionen. Informatio- nen mottages av den mottagande SIB 28 vid 'Call Forwarding' 34.

Den erfordrade synkroniseringen mellan sändande och mottagan- de SIB 26 resp. 28 (varvid informationen kan behöva buffras, beroende på vilken script som exekverar först), hanteras inuti de båda SIB. Väl mottagen matas denna information till värde- rings-SIB 30, som kommer att använda Call Forwarding-specifika tabeller, (vilken referens lagrades i SIB när ifrågavarande script skapades), för att kunna fatta ett beslut. Varje möjligt beslut kommer att leda till en separat utgång. I detta fall kommer 'Call Forwarding applies' 38 att leda till en utgång, till vilken 'Block Feature' 24 kommer att länkas. Denna SIB 24 blockerar den tilläggsfunktion 34, till vilken ifrågavarande script är länkad. För att göra detta skulle den kunna övervaka den generella triggern 38 'feature-applies' och därefter beordra den generella operationen 40 'restrict-feature', beordrande tilläggsfunktionen 34 att inte agera.

I stället för 'Call Waiting applies' kan sändande script sända mer allmän information, t.ex. 'Tone-sending feature ac- tive', innebärande att 'Call Waiting' kommer att sända en ton till den upptagna användaren. I detta fall behöver scriptet på 'Call Forwarding' ej uppgraderas varje gång en tilläggsfunktion införs och sänder en ton, och som måste leda till blockering av 'Call Forwarding' inom samma interaktionshanterare.

SIB specifika för tilläggsfunktioner kan likaså skapas, men de mer generella SIB kan användas ju större produktivitetsvins- ten är.

Ehuru ej så tydligt framgående av figur 1 kan interaktions- logikplanet 10 även använda gränssnittet 8 mellan tilläggsfunk- tion 4 och plattform 2. I allmänhet har ett "högre" plan till- gång till alla "lägre" plan. Under plattformen kommer operativ- systemet att befinna sig, som även är tillgängligt för tilläggs- funktionsplanet, och för interaktionslogikplanet.

På grund av att båda planen, och de gränssnitt, som de implementerar eller använder, följer samma principer, kommer det att finnas funktioner som är mycket lika i de olika planen. Med 502 423 18 hänvisning till fig. 1 och 4 kan dessa funktioner ingå i en modul 40 för generella funktioner. Funktionerna i denna modul används av båda planen 6 och 10, eller vid hanteringen av de olika gränssnitten 8 och 12.

De flesta funktioner som krävs för att hantera dynamisk länkning kommer t.ex. att bilda del av denna modul. För gräns- snittet 8, plattform-tilläggsfunktionsplan, bestäms de för dynamisk länkning avsedda länkmodulerna av de ingående olika aktiveringsprofilerna, t.ex. användare, access, väg. Dessa profiler analyseras, vanligen genom att tyda tabeller 42, tills en uppsättning länkmoduler påträffas, varpå dessa moduler länkas dynamiskt. I princip måste samma funktion länka interaktions- moduler, med undantag av att typen av ingång är olika. Platt- formen kommer att trigga denna funktion när en ny profil införs och en tilläggsfunktion kommer att trigga denna funktion först innan den sänder triggern 'feature applies'. Även schemaläggningen implementeras i modulen 40 för generel- la funktioner. Denna funktion 44 triggas av en trigger kommande från plattformen 2 eller en tilläggsfunktion. Den kommer även att acceptera vissa operationer, vilka kommer att ändra schema- läggning. u Både tilläggsfunktionsplanet 6 och interaktionslogikplanet 10 kräver kommunikation mellan olika länkmoduler i samma basfunk- tion, t.ex. genom sändning och mottagning av SIB. Modulen 40 för generella funktioner kommer att innehålla funktioner 46 som underlättar detta, särskilt för att ansluta ett flertal länk- moduler. Även plattformen 2 kan använda detta, eftersom flera separata aktiveringar av en basfunktion kan kräva kommunikation.

Ett konferensanrop består t.ex. av ett antal separata men sam- hörande anrop, vilka kan betraktas som länkmoduler från opera- tivsystemets synpunkt.

Effektiviteten hos arkitekturen enligt uppfinningen beror på strukturen i interaktionslogikplanet. Det skulle kunna vara ett önskemål att struktureringen i interaktionslogikplanet t.ex. inte bör leda till fler konflikter mellan interaktionsmoduler än antalet konflikter som löses i tilläggsfunktionsplanet. Sett från en annan synpunkt kommer det emellertid att vara lättare att identifiera en sådan struktur, eftersom valet är endast begränsat av tekniska överväganden. I exempelvis tilläggsfunk- f-fv 502 423 19 tionsplanet styrs struktureringen i olika tilläggsfunktioner i hög grad av marknadsöverväganden. Varje funktion säljs i princip separat, varför den måste ha ett marknadsvärde oberoende av andra funktioner.

Olika strukturering i interaktionslogikplanet kommer van- ligtvis att leda till olika principer för de gränssnitt som tilläggsfunktionerna måste implementera, och olika typer av SIB.

Principerna för gränssnitt bör styras genom val av generella gränssnitt.

Först skall en kombinationsbaserad lösning behandlas. I denna struktur representerar varje interaktionshanterare 14 en unik uppsättning tilläggsfunktioner 4 som kräver lösning om de alla ingår i samma anrop. Modularitet i interaktionslogikplanet 10 uppnås genom att ersätta två eller flera konfliktande moduler med en separat. För anrop innefattande tilläggsfunktioner A och B, skulle t.ex. en interaktionshanterare 'A-B' hantera inter- aktionerna. Om tilläggsfunktionen C skall länkas till anropet ersätts 'A-B' med 'A-B-C'. Eftersom 'A-B-C' kan avlägsnas så snart endera A, B eller C avlägsnas, är laddningsmodulerna i interaktionslogikplanet lika den kompletta interaktionshantera- 'ren. När en ny tilläggsfunktion införs kan varje kombination med andra moduler, dvs tilläggsfunktioner eller interaktionshantera- re, kräva en ny interaktionshanterare. Det tidigare beskrivna exemplet med 'Call Forwarding on Busy' och 'Call Waiting' skulle motsvara denna struktur.

En möjlighet, benämnd 'Flexible Service Profile', strävar till lösning av konflikter mellan tilläggsfunktioner på per- användarbasis. Idén är att skapa separata tjänstescript vilka innehåller flera tilläggsfunktioner. Alla interaktioner är hårdkodade i dessa script. Idén är inspirerad av IN (Intelligent Networks), där IN-användarna per definition är användare, som tillhandahåller en tjänst (IN-tjänst) till andra användare i nätet. Det är även inom detta sammanhang SIB användes först. Med användning av den nya arkitekturen skulle interaktionslogik- planet kunna implementera de verkliga tjänste-scripten. En användare skulle aktivera en interaktionshanterare snarare än en uppsättning tilläggsfunktioner. Tjänstescripten triggar starten av rätt tilläggsfunktioner. Detta kräver viss extra program- mering i tilläggsfunktionerna. Förutom detta är gränssnittet, 502 423 20 som tilläggsfunktionerna måste implementera och de erfordrade SIB desamma som för kombinationsbaserad lösning.

I fig. 5 visas ett exempel på denna lösning. Pilarna som kommer in i SIB uppifrån anger de parametrar för SIB som in- ställs vid skapande av scriptet. Användar-profilen 50 har 'My- Service' 52 aktiverad. 'MyService' har sin egen profil för denna användare, innehållande sina specifika data för användaren och referenser till länkmoduler för tilläggsfunktionen. Denna profil är länkad till användaren. När en aktiverad basfunktion finner att dess särskilda användare utgör destination för ett koppel, anropas systemets dynamiska länkningsfunktioner i modulen för generella funktioner, med en referens till profilen som ingång.

Länkarna från profilen till aktiverade tilläggsfunktioner spåras och därifrån spåras länkarna till länkmodulerna. Rätt länkmodu- ler länkas, jfr pil 54, därpå till anropet.

'MyService' 52 kommer inte att manipulera kopplet förrän användaren visar sig vara upptagen. Den första uppgiften för scripten är därför att övervaka 'busy'-triggern. Som en optime- ring skulle användar-profilen kunna struktureras på ett sådant sätt att den dynamiska länkningen av 'MyService' ej görs förrän upptaget-tillståndet uppträder. Detta kräver att användarprofi- len analyseras flera gånger i kopplet. Pilen 56 anger beteendet av 'busy'-triggern, vilket bringar wait-SIB 58 att göra sorti enligt pil 60. . I Nu är det dags för 'MyService' 52 att bestämma hur konflikten mellan 'Call Waiting' och 'Call Forwarding' skall hanteras. I detta fall beslutar 'MyService' 52 att utföra 'Call Waiting' 62 och inte 'Call Forwarding'. Som ett alternativ skulle valet kunna lagras i 'MyService'-profilen för användaren. Pilen 64 anger den dynamiska länkningen av 'Call Waiting' 62 och starten av exekveringen av 'Call Waiting'. 'MyService' kommer att anropa den dynamiska länkningsfunktionen 42 i modulen 40 för generella funktioner med en global referens till rätt länkmodul i 'Call Waiting' och sin egen referens. Den senare krävs på grund av att 'MyService' 52 måste vara länkad till 'Call Waiting' 60 så att den kan övervaka uppförandet av 'Call Waiting'. Detta kan behöva vara en separat länkmodul i 'MyService', eftersom scriptet använder ett nytt gränssnitt.

Efter att 'Call Waiting' har startat kommer 'Call Waiting' 62 502 423 21 och 'HyService' 52 att exekvera parallellt. Åtgärden enligt pil 66 leder till nästa SIB, som är wait-SIB 68. Denna wait-SIB 68 väntar på triggern 'Result' 70 från 'Call Waiting'. Detta resul- tat kommer att ange OK: 'Call Waiting' framgångsrikt slutfört, eller 'ej 0K': fel uppträdde i 'Call Waiting'. När det anländer, pil 72, kommer vänta-SIB 68 att välja en separat utgång för varje möjligt resultat. Om resultatet är OK är scriptet slut- fört. Om inte kommer länk-SIB 74 enligt pil 76 att länka 'Call Forwarding' 78 i stället. Det kan noteras att detta script ej är fullständigt, eftersom vid resultatet 'ej OK' 'MyService' först bör kontrollera huruvida kopplet befinner sig i ett tillstånd som är kompatibelt med 'Call Forwarding' 78.

Flera olika lösningar för att undvika konflikten är möjliga.

Med detta koncept är det möjligt att konstruera flera lösningar för samma kombination av ingående tilläggsfunktioner och till- lämpa dem på olika användare. Struktureringen i interaktions- logikplanet bestäms av den kombination av tilläggsfunktioner som kan aktiveras samtidigt för en enda användare. En interaktione- hanterare kan vara i stånd att hantera flera alternativ, och låta det tillämpliga alternativet beslutas av användardata, eller de kan hanteras av separata interaktionshanterare.

Det finns flera koncept som tar hand om interaktionsproble- met. Hittills har varje sådant koncept innehållit både fördelar och nackdelar. Den kombinationsorienterade lösningen leder t.ex. fortfarande till att en stor mängd av interaktioner skall imple- menteras, desto mer på grund av konflikter mellan de olika interaktionshanterarna, vilket kräver ännu en för att lösa detta. 'Flexible Service Profiles' tar endast hand om interak- tionen för en enda användare. I varje koppel ingår emellertid åtminstone två användare och mer sofistikerade tilläggsfunk- tioner kan leda till att ett stort antal användare ingår i samma koppel. Ju flera användare med olika aktiverade tilläggsfunk- tioner eller olika alternativ för deras interaktioner som kräver en specifik ny tilläggsfunktion, ju fler nya "paket" innehållan- de den nya tilläggsfunktionen måste konstrueras.

Ett annat koncept benämnt 'negotiation' tar endast hand om den del som saknas i 'Flexible Service Profiles': endast in- teraktioner mellan användare beaktas.

Uppfinningen har en rad fördelar. 502 423 22 En egenskap hos systemet enligt uppfinningen är att samma principer och krav gäller för både gränssnittet mellan plattform och tilläggsfunktion, och gränssnittet mellan tilläggsfunktion och interaktionslogik. Huvudkravet för båda gränssnitten är t.ex. att det måste vara stabilt, kompatibelt bakåt mot äldre versioner och ha en riktig abstraktionsnivå. Detta ger följande reultat: - Gränssnittet mellan tilläggsfunktion och interaktionslogik kan från redan existerande implementationer av gränssnittet mellan plattform och tilläggsfunktioner dra fördel av redan uppnådd erfarenhet, och erfarenhet, som kommer att uppnås. Så länge som de principer som styr det senare gränssnittet utveck- las i en positiv riktning, kommer det förstnämnda gränssnittet likaledes att utvecklas i en positiv riktning. Det är absolut nödvändigt för varje arkitektur att principer kan definieras för stabila och bakåt mot tidigare versioner kompatibla gränssnitt.

Annars kan modularitet mellan plattform och tilläggsfunktioner ej existera, vilket i och för sig skulle göra varje försök att förkorta introduktionscykeln för tilläggsfunktioner omöjlig.

Till följd härav har stor uppmärksamhet ägnats åt hur man skall definiera sådana principer.

- För att uppnå målen måste de produkter som implementerar gränssnittet ha en klar struktur. Implementering av ett sådant gränssnitt medför därför förbättring av tilläggsfunktionens totala kvalitet.

- Nya verktyg och språk utvecklas för att underlätta specifi- cering och implementering av gränssnitt. Flera språk innehåller redan en separat specifikation av ett öppet gränssnitt, t.ex.

Pascal, C++. Gränssnittet mellan tilläggsfunktion och interak- tionslogik kommer att omedelbart kunna dra fördel av varje framsteg inom detta område.

- Nya verktyg och språk utvecklas för att underlätta specifi- cering och implementering av tilläggsfunktioner, t.ex. klar- görande språk, SIB. De flesta av dessa förutsätter att ett öppet gränssnitt används av tilläggsfunktionerna. Genom uppfinningen kan samma verktyg och språk användas för att implementera de erfordrade interaktionerna. Den traditionella arkitekturen grundar sig huvudsakligen på tabeller för detektering och prio- ritetsinställningar för lösning. De drar inte fördel av dessa 502 423 23 nya teknologier.

En annan egenskap hos arkitekturen enligt uppfinningen är den optimala återanvändningen av tilläggsfunktionsdata och -kod: - Eftersom inga andra funktioner hos en tilläggsfunktion behöver modifieras än de funktioner som omedelbart påverkas av interaktionen, kommer färre konflikter att påträffas senare i konstruktionen, eftersom lösningslogiken aldrig kommer att behöva implementera normala funktioner hos tilläggsfunktionen.

Detta kommer att leda till en snabbare implementering av en interaktion.

- En optimal användning av minne och processorkapacitet kan lättare uppnås, eftersom ingen information behöver lagras "ifall att", såsom skulle vara fallet om tilläggsfunktionen aktivt måste sända information till koordinationsmodulen. Ju effek- tivare funktionen är som hanterar dynamisk länkning av interak- tionskomponenter, ju större fördel uppnås. Eftersom denna funk- tion utgör del av modulen för generella funktioner kan den förbättras utan att påverka tilläggsfunktioner eller interak- tionshanterare.

Avsikten är att uppnå en effekt motsatt den hos konventionell arkitektur snarare än att förenkla konstruktionen av tilläggs- funktioner och tvinga interaktionerna att hantera de extra komplikationerna till följd härav. Den konventionella arkitektu- ren strävar efter att förenkla konstruktionen av tilläggsfunk- tioner, och komplicerar sålunda konstruktionen av interaktioner.

Detta är priset för interaktioner som fortsätter att öka med varje ny tilläggsfunktion. Därför kommer uppfinningen inte bara att leda till mer förutsägbara och stabila ledtider, utan även kortare medelledtider i ett system, som redan har en rimlig mängd tillläggsfunktioner.

Claims (38)

'n 5024423 24 Eategtkrav

1. System för hantering av utnyttjandet av basfunktioner och tilläggsfunktioner i ett telekommunikationsnät, som innehåller ett flertal användare, som kan anropa varandra och abonnerar på bastjänster och tilläggsfunktioner avseende bas- resp. tilläggs- funktionerna, i vilket system en plattform (2) innehåller basfunktionerna och implementerat gränssnitt (8), vilka vart och ett länkar en eller flera av tillläggsfunktionerna (4) till plattformen, varje tilläggsfunktion består av en eller flera länkmoduler (4), en per gränssnitt, som tilläggsfunktionen önskar använda, interaktions-logik (10) finnes för att detektera och lösa konflikt mellan tilläggsfunktioner, kännetecknat av att även interaktionslogiken består av länkmoduler (16), och att dessa länkmoduler och tilläggsfunktionernas länkmoduler (4) är belägna i var sitt plan (10; 6), varvid tilläggsfunktionerna och deras nämnda gränssnitt är transparenta för interaktionslogiken, och interaktionslogikens länkmoduler är länkningsbara till tilläggsfunktionerna.

2. System enligt krav 1, kännetecknat av att interaktions- logikens plan (10) innefattar ett antal funktioner i form av interaktionshanterare (14), som var och en är i stånd att lösa en specifik konflikt.

3. System enligt krav 2, kännetecknat av att varje inter- aktionshanterare (14) består av flera länkmoduler (16), åtmins- tone en per tilläggsfunktion, vars gränssnitt interaktionshante- raren använder.

4. System enligt krav 3, kännetecknat av att vid introduktion av en ny tilläggsfunktion (4) införs den i systemet tillsammans med alla nödvändiga länkmoduler (16) i de olika interaktions- hanterarna (14) som krävs för att hantera interaktioner med andra tilläggsfunktioner.

5. System enligt krav 4, kännetecknat av att länkmoduler (16) i samma interaktionshanterare (14) som beror av varandra bildar en laddningsmodul.

6. System enligt krav 5, kännetecknat av att när en länkmodul (16) inte längre används, avlägsnas den laddningsmodul i vilken länkmodulen ingår. 502 423 25

7. System enligt något av krav 1-6, kännatacknat av att ett av en tilläggsfunktion (4) implementerat gränssnitt (12) är i stånd att innehålla flera generella delar i form av operationer och triggrar, vilka är identiska i olika tilläggsfunktioner.

8. System enligt något av föregående krav, kännatecknat av att interaktionslogikplanet (10) även använder gränssnitt (8) mellan tilläggsfunktion (4) och plattform (2).

9. System enligt krav 8, kännetecknat av att interaktions- logikplanet (10) är uppdelat i ett detekteringsplan och ett lösningsplan med tillhörande länkmoduler.

10. System enligt krav 8, kännetecknat av att lösningsplanet är så strukturerat att flera lösningsmoduler kan använda samma detekteringsmodul.

11. System enligt krav 9 eller 10, kännatecknat av att detekteringsplanet är i stånd att implementera gränssnitt be- stående endast av triggrar.

12. System enligt krav 11, kännetecknat av att lösningsplanet innefattar operationer, som förbigår dekteringsplanet för att direkt använda det av en tilläggsfunktion implementerade gräns- snittet.

13. System enligt något av föregående krav, kännatecknat av en modul (40) för generella funktioner, vilka är mycket lika i de olika planen, och som används av de senare och vid hantering av gränssnitt. .

14. System enligt krav 13, kännetecknat av att funktioner (42) för hantering av dynamisk länkning ingår i modulen för generella funktioner. I

15. System enligt krav 13 eller 14, kännetecknat av att en funktion schemaläggning (44) av exekveringen av tilläggsfunktio- ner ingår i modulen för generella funktioner.

16. System enligt krav 15, kännetecknat av att funktionen schemaläggning aktiveras av en funktion från plattformen eller en tilläggsfunktion.

17. System enligt något av krav 13-16, kännetecknat av att modulen för generella funktioner (40) tar emot operationer, som ändrar en viss schemaläggning av exekveringen av tilläggsfunk- tioner.

18. System enligt något av krav 13-17, kännetecknat av att modulen för generella funktioner innehåller funktioner, som 502 423 26 hanterar kommunikation hos de båda planen mellan olika länk- moduler i samma tilläggsfunktion.

19. System enligt något av krav 13-18, kännetecknat av att modulen för generella funktioner innehåller funktioner (46) som hanterar kommunikation i plattformen.

20. Telekommunikationssystem strukturerat att omfatta en uppsättning (2) basfunktioner och en uppsättning (6) tilläggs- funktioner, vilka tilläggsfunktioner var och en är anslutbar till en viss basfunktion för att utgöra ett tillägg till och modifiera denna basfunktion, varvid basfunktionerna implementerar ett eller flera öppna gräns- snitt (8), vilkas funktionalitet ej är specifik för någon till- läggsfunktion, och vilka medger interaktion mellan basfunktio- nerna och tilläggsfunktionerna på sådant sätt att nya tilläggs- funktioner kan tillföras systemet utan att påverka basfunktio- nerna, interaktionslogik (10) finnes för att lösa problem med att de respektive beteendena hos två tilläggsfunktioner, som samtidigt är anslutna till en viss basfunktion, kan komma i konflikt med _varandra, kännetecknat av att interaktionslogiken innefattar interaktionsmoduler (16), varje tilläggsfunktion (4) likaledes implementerar åtminstone ett öppet gränssnitt (12), vilket medger interaktion mellan interaktionsmodulerna på sådant sätt att nya interaktionsmodu- ler, som är avsedda att interagera med tilläggsfunktionen genom användning av detta gränssnitt, kan adderas till systemet utan att påverka denna tilläggsfunktion, dessa öppna gränssnitt används av interaktionsmodulerna för att interagera med tilläggsfunktionerna på sådant sätt att konflikter mellan tilläggsfunktionerna undviks.

21. System enligt krav 20, kännetecknat av att inter- aktionslogiken (10) innefattar ett antal funktioner i form av interaktionshanterare (14), som var och en är i stånd att lösa en specifik konflikt.

22. System enligt krav 21, kännetecknat av att varje in- teraktionshanterare (14) består av flera länkmoduler (16), åtminstone en per tilläggsfunktion, vars gränssnitt inter- aktionshanteraren använder. 502 423 27

23. System enligt krav 22, kännetecknat av att vid introduk- tion av en ny tilläggsfunktion (4) införs den i systemet till- sammans med alla nödvändiga länkmoduler (16) i de olika inter- aktionshanterarna (14) som krävs för att hantera interaktioner med andra tilläggsfunktioner.

24. System enligt krav 23, kännatecknat av att länkmoduler (16) i samma interaktionshanterare (14) som beror av varandra bildar en laddningsmodul.

25. System enligt krav 24, kännetecknat av att när en länk- modul (16) inte längre används, avlägsnas den laddningsmodul i vilken länkmodulen ingår.

26. System enligt något av krav 20-25, kännatacknat av att ett av en tilläggsfunktion (4) implementerat gränssnitt (12) är i stånd att innehålla flera generella delar i form av operatio- ner och triggrar, vilka är identiska i olika tilläggsfunktioner.

27. System enligt något av krav 20-26, kännetecknat av att interaktionslogiken (10) även använder gränssnitt (8) mellan tilläggsfunktion (4) och en systemplattform (2).

28. System enligt krav 27, kännetecknat av att interaktions- logiken (10) är uppdelad i ett detekteringsplan och ett lös- bningsplan med tillhörande länkmoduler.

29. System enligt krav 27, kännetecknat av att lösningsplanet är så strukturerat att flera lösningsmoduler kan använda samma detekteringsmodul. .

30. System enligt krav 28 eller 29, kännetecknat av att detekteringsplanet är i stånd att implementera gränssnitt be- stående endast av triggrar.

31. System enligt krav 30, kännetecknat av att lösningsplanet innefattar operationer, som förbigår dekteringsplanet för att direkt använda det av en tilläggsfunktion implementerade gräns- snittet.

32. System enligt något av krav 20-31, kännetecknat av en modul (40) för generella funktioner, vilka är mycket lika i olika plan hos systemet, och som används av de senare och vid hantering av gränssnitt.

33. System enligt krav 32, kännetecknat av att funktioner (42) för hantering av dynamisk länkning ingår i modulen för generella funktioner.

34. System enligt krav 32 eller 33, kännetacknat av att en 502 423 28 funktion schemaläggning (44) av exekveringen av tilläggsfunktio- ner ingår i modulen för generella funktioner.

35. System enligt krav 34, kännetecknat av att funktionen schemaläggning (44) aktiveras av en funktion från en system- plattform eller en tilläggsfunktion.

36. System enligt något av krav 32-35, kånnetecknat av att modulen för generella funktioner (40) tar emot operationer, som ändrar en viss schemaläggning av exekveringen av tilläggsfunk- tioner.

37. System enligt något av krav 32-36, kännatecknat av att modulen för generella funktioner innehåller funktioner, som hanterar kommunikation hos plan mellan olika länkmoduler i samma tilläggsfunktion.

38. System enligt något av krav 32-37, känneteoknat av att modulen för generella funktioner innehåller funktioner (46) som hanterar kommunikation i plattformen.