NO323264B1 - terminaladministrator for aksess til multiple heterogene telekommunikasjonsnettverk - Google Patents

Description

OPPFINNELSENS OMRÅDE

Den foreliggende oppfinnelse angår en fremgangsmåte og et system for å tilveiebringe serviceaksess til applikasjoner på flere heterogene nett. Selv om den foreliggende oppfinnelsen har opphav i mobile kommunikasjoner kan den anvendes i hele telekommunikasjonsområdet. Videre, med konvergens mellom telekom-munikasjon og datamaskiner kan denne oppfinnelsen også anvendes i datakom-munikasjon på pakkebaserte nettverk slik som IP (Internet Protocol) baserte nettverk.

BAKGRUNN

For å fremme utviklingen av tredjeparts applikasjoner 3GPP (Third Genera-tion Partnership Project ( http:// www. 3app. ora). som er standardiseringsorganet for tredje generasjons mobile systemer (UMTS), introduserte åpen serviceaksess (Open Service Access, OSA) for tredje generasjons mobilsystemer (UMTS). OSA-standarder er definert i 3GPP, Virtual Home Environment; Open Service Architecture ( Release 4). Valbonne, 2001. (3GPP TS 23.127, V4.1.0,2001-04).

OSA tillater applikasjonene aksess til nettverksservice-muligheter slik som oppkallskontroll (Cali Control, CC), brukerstatus (User Status, US), meldingsfor-midling (Messaging, M), stedsinformasjon (Location Information, LI), osv. gjennom åpne grensesnitt. En slik arkitektur vil med sikkerhet spille en nøkkelrolle i realiser-ingen av én eller flere "killer"-applikasjoner, som er nødvendige for suksessen av UMTS. Det er verdt å understreke at ingen i dag kjenner enda hva som kommer til å bli en slik "killer"-applikasjon. For GSM kunne ingen forutsi at SMS (Short Mes-sage Service) har blitt en "killer"-applikasjon.

OSA er kun tiltenkt for mobile nettverk. Imidlertid, med konvergens mellom telekom og databehandling, mellom faste og mobile, er det essensielt at en applikasjon er i stand til å fungere ordentlig uavhengig av det underliggende nettverket. Som en konsekvens av dette er det nødvendig å strekke dekningen av OSA til å omfatte også andre nettverk enn mobile slik som PSTN/ISDN og også IP-baserte nettverk. Det er verdt å merke seg at IP-baserte nettverk både kan være kabelbaserte og trådløse slik som f.eks. trådløst LAN (802.11), HiperLAN, eller Bluetooth. Situasjonen er avbildet i.

Uheldigvis var OSA kun tiltenkt for mobile nettverk og det er ikke spesifisert hvordan OSA skal implementeres for heterogene nettverk. Videre, OSA, som spesifisert av 3GPP, er ikke tilstrekkelig til å kunne anvendes på heterogene nettverk. Den foreliggende oppfinnelsen foreslår forskjellige utførelsesformer for å implementere OSA på toppen av flere forskjellige nettverk. Tilleggsfunksjonalitet til OSA er også påkrevet og foreslått av denne oppfinnelsen.

Iht. kunnskapen til oppfinnerne finnes det ingen løsning på problemet beskrevet over på det foreliggende tidspunkt. Selv for Parlay Architecture ( http:// www. parlav. org). som OSA er basert på, er det ingen aktivitet for å implementere Parlay på heterogene nettverk. Selv om det er vist i noen overblikk over Parlay-arkitekturen en Parlay API som dekker mobile nettverk, ISDN og IP-baserte nettverk, finnes det ingen spesifikasjon for denne implementeringen.

SAMMENFATNING AV OPPFINNELSEN

I et første aspekt tilveiebringer oppfinnelsen et telekommunikasjonssystem som tilveiebringer applikasjonsserviceaksess på et flertall heterogene nettverk, omfattende en åpen serviceaksess (OSA) utvidelse med minst ett rammeverk som tilveiebringer grensesnitt mellom applikasjonene og de flere heterogene nettverk, der telekommunikasjonssystemet er kjennetegnet ved at serviceaksessutvidelsen omfatter en terminal ID administrator som tilveiebringer informasjon til applikasjonene ved valg av det påkrevde nettverk basert på terminal ID.

I et andre aspekt tilveiebringer oppfinnelsen et telekommunikasjonssystem som tilveiebringer utvidet åpen serviceaksess for applikasjoner på multiple heterogene nettverk idet systemet omfatter ett felles rammeverk for nevnte nettverk og én serviceevnefunksjbn (SCF) for hvert nettverk for å tilveiebringe et nettverksspesifikt grensesnitt, der telekommunikasjonssystemet er kjennetegnet ved at serviceevnefunksjonene omfatter en generell serviceegenskap som indikerer hvilket underliggende nettverk en SCF samvirker med.

Den generelle serviceegenskapen kan uttrykkes som en streng som inneholder et <operatør, nettverk> par.

I denne utførelsesformen velger også en terminal ID administrator den påkrevde nettverksservice-evnetjenésten for en applikasjon basert på terminal ID. Terminal ID administratoren kan inkludere en database/register som inneholder mappeinformasjon mellom applikasjonene og terminal I D-ene. Terminal ID administratoren kan også omfatte en database/register som inneholder mappeinformasjon mellom applikasjoner og serviceevnefunksjonforekomstene, mellom serviceevnefunksjonforekomstene og nettverkene, og mellom nettverkene og terminal ID-ene. Terminal ID administratoren kan oppdateres i sanntid. Et grensesnitt mellom den anmodende applikasjonen og terminal ID administratoren tilveiebringes av en terminaladministrator (TA SCF) som inneholder grensesnittklasser for applikasjonsanmodninger. Terminaladministratoren (TA SCF) inkluderer programanordninger for å tillate en applikasjon å få en referanse for den korrekte serviceevne-funksjonforekomsten for en gitt terminal, for å spørre serviceevnefunksjonforekomstene om flere terminal ID-er samtidig, for å få en nettverks ID for en gitt terminal, for å få referansene til alle dens serviceevnefunksjonforekomster, og for å få referansene for alle dens serviceevnefunksjonforekomster i et spesifikt nettverk.

I et tredje aspekt tilveiebringer oppfinnelsen et telekommunikasjonssystem som tilveiebringer utvidet åpen serviceaksess for applikasjoner på multiple heterogene nettverk, idet systemet omfatter ett unikt felles rammeverk for nettverkene og en felles serviceevnefunksjon (SCF) for nettverkene som tilveiebringer et felles nettverksgrensesnitt, der telekommunikasjonssystemet er kjennetegnet ved at serviceevnefunksjonene omfatter en generell serviceegenskap som indikerer hvilket underliggende nettverk en SCF samhandler med.

Denne generelle serviceegenskapen kan uttrykkes som et sett av strenger, der hver streng inneholder et <operatør, nettverk> par. Grensesnittet kan inkludere serviceevnefunksjonklasser som tilveiebringer én-til-mange mapping mellom applikasjoner og grensesnittene for de underliggende nettverkene.

Videre kan den felles serviceevnefunksjonen inkludere en mappeanordning for å mappe grensesnittklasser på nettverksgrensesnittene og en dispatcheranordning som oversender en anmodning fra en applikasjon til en korrekt nettverksgrensesnittklasse. Et registreringsgrensesnitt mellom mappeanordningen og dispatcheranordningen kan muliggjøre registrering av nettverkene hos dispatcheren. Dispatcheranordningen inkluderer velgeanordninger for å velge den riktige serviceevnefunksjonen (SCF) for en anmodning som ankommer fra en applikasjon. En terminal ID administrator velger den påkrevde nettverksserviceevnefunksjonen (SCF) for en applikasjon basert på terminal ID. Mappeinformasjon mellom applikasjoner og terminal ID-ene kan inkluderes i en terminal ID administrator data-base/register. Databasen/registeret inkluderer mappeinformasjon mellom applikasjoner og serviceevnefunksjonforekomstene, mellom serviceevnefunksjonforekomstene og nettverkene, og mellom nettverkene og terminal I D-ene. Også i denne utførelsesformen er terminal ID administratoren oppdaterbar i sanntid. Terminal ID administratoren (TA SCF) tilveiebringer et grensesnitt for SCF dispatcheranordningen, og terminal ID administratoren omfatter programanordningen som når de kjøres tilveiebringer henting av en referanse for den korrekte serviceevnefunksjonen for en gitt terminal for å oversende anmodningen til den SCF forekomsten, som inkluderer å hente terminal ID som applikasjonen håndterer, å hente applikasjonens ID for den anmodende applikasjonen, og referansene for serviceevnefunksjonforekomstene returnert av SCF forekomsten.

I et fjerde aspekt tilveiebringer oppfinnelsen et telekommunikasjonssystem som tilveiebringer utvidet åpen serviceaksess for applikasjoner på multiple heterogene nettverk, idet systemet omfatter et rammeverk for hvert nettverk, der hvert rammeverk har en serviceevnefunksjon (SCF) for nevnte nettverk som tilveiebringer et nettverksspesifikt grensesnitt, der telekommunikasjonssystemet er kjennetegnet ved at hvert nettverk omfatteren terminal ID informator som tilveiebringer en serviceevnefunksjon til applikasjonene angående nettverksvalg basert på terminal ID.

Hvert rammeverk kan da inkludere en mekanisme som muliggjør valg av en serviceevnefunksjon i et annet rammeverk og mottak av en referanse for nevnte serviceevnefunksjon. De valgbare serviceevnefunksjonene for rammeverkene kan forhåndsdefineres. Terminal ID informatoren returnerer en streng som inneholder et <Terminal ID, tilhører (Sann/Usann)> par til den spørrende applikasjonen. Alle rammeverkene kan inkludere programanordninger som utfører når de anmodes, en gjensidig autentiseringsprosedyre. Dette kan være tilfellet når andre rammeverk som anmoder informasjon om serviceevnemulighetene som tilbys av nevnte nettverk. For å muliggjøre dette kan rammeverket omfatte et utvidet grensesnitt. Det utvidede grensesnittet kan også inkludere programanordninger som utfører en anmodningsprosedyre som returnerer en identitet for det spørrende rammeverket sammen med en liste av de forhåndsdefinerte serviceevnefunksjonene som tilbys til nevnte rammeverk og en henteprosedyre som gjør det mulig for et rammeverk å anmode andre rammeverk og returnere referanser for serviceevnefunksjonforekomstene i overensstemmelse med serviceegenskapene spesifisert av den anmodende applikasjonen. Terminal ID administratoren velger den påkrevde nettverksserviceevnefunksjonen for en applikasjon basert på terminal ID. Velging muliggjøres av en mappefunksjon basert på en database/register som samvirker med terminal ID administratoren. Databasen/registeret kan også inneholde mappeinformasjon mellom applikasjoner og serviceevnefunksjonforekomstene, mellom serviceevnefunksjonforekomstene og nettverkene, og mellom nettverkene og terminal I D-ene. Et informasjonsgrensesnitt som tilveiebringer informasjon til terminal ID administratoren angående terminal ID områder som støttes av hvert rammeverk kan også være inkludert i terminal ID administratoren. Terminal ID administratoren er oppdaterbar i sanntid.

De heterogene nettverkene inkluderer, men er ikke begrenset til, telekom-munikasjonsnettverk kabelbaserte eller trådløse, f.eks. mobile, UMTS, GSM, PSTN/ISDN eller datanettverk slik som et pakkebasert nettverk, f.eks. IP (kabel), trådløst LAN, Bluetooth eller Hiper LAN (trådløst).

Det beskrives også en fremgangsmåte for å tilveiebringe applikasjonsserviceaksess på flere heterogene nettverk, omfattende implementering av en åpen serviceaksess (OSA) utvidelse med minst ett rammeverk i et applikasjons-programmeringsgrensesnitt (API) for de heterogene nettverk som tilveiebringer grensesnitt mellom applikasjonene og de flere heterogene nettverk.

Det beskrives også et program for et applikasjonsprogrammeringsgrense-snitt (API) for å tilveiebringe åpen serviceaksess for applikasjonene til flere heterogene nettverk, idet programmet omfatter et sett av instruksjoner for å utføre fremgangsmåten og implementere systemet over.

Det beskrives også et datalesbart medium som har lagret derpå et applika-sjonsprogrammeringsgrensesnitt (API) for å tilveiebringe åpen serviceaksess for applikasjoner til flere heterogene nettverk, idet det datamaskinlesbare mediet omfatter et sett med instruksjoner for å utføre fremgangsmåten og å implementere systemet over.

Denne oppfinnelsen vil være til nytte for forskjellige aktører innenfor tele-kommunikasjon og tilstøtende og samvirkende områder, slik som f.eks. nettverks-operatører, service/applikasjonstilbydere og brukere på forskjellige måter. Nett-verksoperatørene kan være i stand til å tilveiebringe mer fleksible tjenester til applikasjonene. De oppnår derfor et større antall applikasjoner og som en følge av dette høyere trafikk og større antall brukere. Service/applikasjonstilbyderne kan utvikle applikasjoner lettere og også mer interessante applikasjoner. De trenger ikke å være opptatt med forskjellige nettverk. Applikasjonene blir mer generiske siden de kan kjøres på heterogene nettverk. Ganske mye gjenbruk og besparelser kan oppnås siden den samme applikasjonen kan utnyttes i forskjellige nettverk. Bruk-eren vil glede seg over et større område med applikasjoner, som gjøres mulig av OSA API på heterogene nettverk. Selv om denne oppfinnelsen angår OSA kan den også anvendes i PARLAY arkitekturen siden OSA baseres ganske mye på

PARLAY.

Som nevnt over løser den foreliggende oppfinnelsen et problem for service/applikasjonstilbydere siden det er enklere å utvikle applikasjoner for heterogene nettverk. På samme tid tilveiebringer den en mulighet til nettverksoperatø-rer som har heterogene nettverk (f.eks. faste og mobile, telekom og IP-baserte). Oppfinnelsen er definerte i de vedføyde kravene.

Oppfinnelsen er angitt i de vedføyde patentkrav.

KORT BESKRIVELSE AV TEGNINGER

Utførelsesformer av oppfinnelsen vil nå beskrives med referanse til de følg-ende tegninger, der: fig. 1 avbilder til venstre en nåværende arkitektur der applikasjoner aksesserer et mobilt nettverk via OSA, og på den høyre siden et utvidet OSA for heterogene nettverk iht. en utførelsesform av den foreliggende oppfinnelsen,

fig. 2 viser et utvidet OSA for heterogene nettverk ifølge en første utførelsesform av oppfinnelsen, som benytter et felles rammeverk men hvor hvert rammeverk har sine egne SCF-er,

fig. 3 viser forholdene opprettholdt av TA i den første utførelsesformen av oppfinnelsen,

fig. 4 viser noen av egenskapene til terminal ID administratoren i den første utfør-elsesformen av oppfinnelsen,

fig. 5 illustrerer bruk av terminal administrator SCF i den første utførelsesformen

av oppfinnelsen,

fig. 6 er et riss av en implementering av den foreliggende oppfinnelsen som benytter et felles rammeverk og en felles SCF som inneholder alle underliggende

nettverk,

fig. 7 viser bruk av en SCF iht. en ytterligere utførelsesform av oppfinnelsen,

fig. 8 viser et eksempel på en implementering av en andre utførelsesform av oppfinnelsen,

fig. 9 er et riss av en dispatcherfunksjon i OSA iht. en andre utførelsesform av

oppfinnelsen,

fig. 10 illustrerer forholdene som opprettholdes av terminal ID administratoren iht.

en andre utførelsesform av oppfinnelsen,

fig. 11 viser en tredje utførelsesform av oppfinnelsen som benytter ett rammeverk

for hvert underliggende nettverk,

fig. 12 illustrerer kommunikasjon og samarbeid mellom rammeverk iht. en fjerde

utførelsesform av oppfinnelsen,

fig. 13 illustrerer bruk av US SCF i både GSM-nettverket og det IP-baserte nettverket iht. utførelsesformen vist i fig. 12, og

fig. 14 viser kommunikasjon mellom rammeverk via OSA-rammeverk kommunika-sjonsgrensesnitt iht. en fjerde utførelsesform av oppfinnelsen.

DETALJERT BESKRIVELSE AV OPPFINNELSEN

Denne oppfinnelsen består av to hovedpunkter:

• Forslaget å anvende OSA på heterogene nettverk.

• Utførelsesformer for implementering av OSA på heterogene nettverk.

For hver utførelsesform beskrives de påkrevde ytterligere funksjonene og deres innarbeidelse i OSA.

Denne oppfinnelsen tilveiebringer utvidet dekning for OSA (Open Service Access), som opprinnelig var tiltenkt tredje generasjons mobile nettverk, på heterogene nettverk, dvs. omfattende også PSTN, ISDN og IP-baserte nettverk (Internet, Intranet). I det følgende vil fire utførelsesformer for å implementere OSA på heterogene nettverk bli beskrevet. Problemene relatert til hver utførelsesform vil bli undersøkt og påkrevde ytterligere funksjoner og trekk presentert.

Utførelsesform 1: Et felles OSA rammeverk for alle nettverk og en serviceevnefunksjon (SCF) for hvert nettverk.

I denne utførelsesformen er et enkelt OSA rammeverk inkorporert i alle nettverk, men hvert nettverk har sine egne serviceevnefunksjoner (Service Capability Features, SCF-er). GSM/UMTS nettverkene vil ha sine SCF-er slik som oppkallskontroll (Cali Control, CC) SCF, brukerinteraksjon (User Interaction, Ul) SCF, brukerstatus (User Status, US), SCF osv. Det samme gjelder for PSTN/ISDN nettverket og det IP-baserte nettverket som vist i fig. 2.

Følgelig mappes hver SCF på grensesnittene spesifikt for hvert nettverk. Hvordan denne mappingen gjøres avhenger av nettverket. F.eks. mappes CC SCF som er ansvarlig for GSM-nettverket på grensesnittene ved å utstede oppkallskontroll i GSM-nettverket. Det samme gjelder for CC SCF i PSTN/ISDN nettverket og det IP-baserte nettverket. Dette etterlater oss med et standardisert CC API til nettverksevnetjenestene for oppkallskontroll for hvert av nettverkene i vårt heterogene nettverksmiljø, som tillater tredjeparts applikasjoner å bruke oppkalls-styringsmulighetene/evnene i alle nettverkene. Det samme gjelder for andre SCF-er.

Påkrevet ytterligere funksjonalitet

A. SCF navngivningssystem

En SCF for hvert underliggende nettverk må identifiseres og registreres med OSA rammeverket. På denne måten må verdiene til serviceegenskapene for SCF indikere hvilket nettverk hver SCF hører til. Det er også nødvendig å gjenkjenne eieren av nettverket, dvs. nettverksoperatøren. I denne hensikt introduse-res en generell serviceegenskap kalt " underliggende nettvenV som indikerer hvilket underliggende nettverk en SCF samvirker med. Egenskapsverdien er en streng som består av et par: <operatør, nettverk>. F.eks. for en brukerstatus SCF kan verdien være: <Telenor, GSM>, eller <Netcom, GSM>, eller <Telenor, IP-basert ( SIP) >.

B. Valg av SCF forekomst basert på terminal ID

Et hovedproblem for applikasjonene er hvordan den korrekte SCF forekomsten skal velges kun basert på terminal-identifikatorene, terminal I D-ene. Terminal I D-ene kan være et regulært telefonnummer, et navn eller en IP-adresse. F.eks. behøver applikasjonen å abonnere på den rette CC SCF hvis den ønsker å etablere et oppkall for visse terminaler. Noen terminal I D-er er ikke omfattet av GSM-nettverket f.eks. SIP-adresser, og oppkallsanmodninger for disse terminalene bør derfor ikke adresseres til GSM-nettverket, men til det IP-baserte nettverket.

Et annet spørsmål er når applikasjonen ønsker å etablere et kall f.eks. en "klikk for oppkall"-applikasjon, da må den velge hvilket underliggende nettverk for å etablere oppkallet, dvs. hvilken CC SCF forekomst som skal benyttes.

Videre kan problemer opptre når en applikasjon benytter f.eks. brukerstatus SCF. Brukerstatus (US) SCF tillater applikasjoner å erverve statusen (Reachable, Unreachable og Busy) for brukerens terminaler. US SCF for GSM-nettverket er kun i stand til å levere brukerstatuser for terminaler i området for GSM-nettverket (GSM-telefoner registrert i HLR), US SCF for det IP-baserte nettverket er kun i stand til å levere brukerstatus for brukerne registrert i SIP-serveren, etc. En applikasjon som ønsker å sjekke brukerstatusen til en bruker må velge den rette SCF forekomsten, dvs. det rette underliggende nettverket, iht. brukerens terminal ID. F.eks., dersom terminal ID er et GSM-nummer, må applikasjonen velge US SCF forekomsten for GSM-nettverket. Applikasjonen kan da erverve den anmodede brukerstatus ved å benytte den valgte US SCF forekomsten.

Fra eksemplene over kan vi observere at applikasjonene har problemer med å velge den korrekte SCF forekomsten når handlinger utføres på SCF-er. De må ha informasjon om terminalnavngivning/nummerering, dvs. hvilke terminaler som hører til hvilke nettverk. Videre, bør det være en link mellom terminal ID-ene og den korrekte SCF forekomsten. Slik informasjon er ikke statisk men utsatt for hyppige endringer og behøver å oppdateres ofte siden mennesker endrer sine terminaler, operatører og abonnementer ofte. Det er derfor et behov for en ytterligere funksjon terminal ID administrator, som assisterer applikasjonen i valget av SCF basert på terminal I D-er.

Terminal ID administrator ( TA) inkluderer en database/registerservice

som inneholder mappingen mellom applikasjoner og SCF forekomstene, mappingen mellom SCF-forekomstene og nettverkene og til sist mappingen mellom nettverkene og terminal ID-ene, som vist i fig. 3. Tallene i figuren indikerer relasjonen. 1 betyr én og nøyaktig én mens +1 betyr én eller mer. En applikasjon kan ha én eller flere SCF forekomster. Én SCF forekomst har én og kun én applikasjon. Én SCF har ett og kun ett nettverk mens ett nettverk kan ha én eller flere SCF. Ett nettverk har én eller flere terminaler, men én terminal hører til ett og kun ett nettverk. TA tillater nettverksoperatører å registrere endringer når de inntreffer, og tillater applikasjoner å spørre om informasjon om alle mappingene nevnt over, f.eks. SCF forekomsten for et sett med terminal ID-er som illustrert i fig. 4.

TA tilveiebringer nyttig funksjonalitet for alle applikasjoner som benytter OSA. TA bør derfor være tilgjengelig for applikasjoner. I denne hensikt er en OSA serviceevnefunksjon (Service Capability Feature, SCF), si terminal administrator SCF (TA SCF), implementert hvilke abstrakter sammenfatter funksjonaliteten til TA som en standard API. TA SCF inneholder grensesnittklasser for applikasjons-spørringer. TA SCF-grensesnittet for applikasjonsspørringer inneholder de følg-ende metoder som kan benyttes av applikasjonene:

getSCFinstance ( <terminallD>, <applicationlD><SCFreference>),

<terminallD> er terminal ID f. eks. telefonnummer som applikasjonen håndterer <applicationlD> er ID forden anmodende applikasjon

<SCFreference> er referanse for SCF- forekomsten returnert av TA SCF

Denne fremgangsmåten tillater en applikasjon å hente referansen til den korrekte SCF-forekomsten for en gitt terminal, f.eks. et telefonnummer.

getListofSCFinstances ( <iistofTerminallD>, <applicationlD>, <listof SCFreferences>)

<ttstofTerminallD> er listen for terminal ID- ene for å finne SCF- forekomsten for <applicationlD> er ID forden anmodende applikasjon

<listof SCFreferences> er listen av referanser og tilsvarende terminal ID returnert av TA SCF

Denne fremgangsmåten tillater en applikasjon å spørre SCF-forekomstreferansene om flere terminal I D-er samtidig.

getNetworklD( <terminallD>, <applicationlD><NetworklD>),

<terminallD> er terminal ID som applikasjonen håndterer

<applicationlD> er ID for den anmodende applikasjon

<NetworklD> er ID til nettverket, som terminalen hører til, returnert av TA SCF Denne fremgangsmåten tillater en applikasjon å hente nettverks ID for en gitt terminal.

getAUSCFinstance,( <applicationlD><ListofSCFreferencse>),

<applicationlD> er ID til den anmodende applikasjon

<SCFreference> er listen til SCF- forekomstreferansene foren applikasjon returnert ved TA SCF

Denne fremgangsmåten tillater en applikasjon å hente referansene over alle dens SCF-forekomster.

getAIISCFinstance,( <applicationlD>, <networklD>, <ListofSCFreferencse>), <applicationlD> er ID til den anmodende applikasjon

<networklD> er ID til nettverket, f. eks. <Telenor, GSM>, <OperatorX, ISDN>, <OperatorY, IP- ba$ ed>, etc.

<SCFreference> er listen til SCF- forekomstreferansene foren applikasjon returnert ved TA SCF

Denne fremgangsmåten tillater en applikasjon å hente referansene til alle dens

. SCF-forekomster på et spesifikt nettverk.

Eksempel

La oss anta at en applikasjon ønsker å erverve brukerstatusen for en terminal ID, f.eks. telefonnummer 12345678. Applikasjonen senderen spørring til TA SCF (getSCFinstance), som inkluderer <terminal ID> = 12345678 og navnet på SCF, <SCFtype> = "User Status". Som svar mottar applikasjonen objektreferansen til User Status SCF som den anmodende terminal ID hører til. Nå kan applikasjonen benytte den korrekte US SCF uten å være opptatt av de underliggende nettverkene. På denne måten, ved å benytte TA SCF, oppfyller denne utførelses-formen målene til OSA.

Utførelsesform 1 som forklart over er oppsummert i fig. 5.

Utførelsesform 2: Et felles rammeverk og en felles SCF (Service Capablllty Feature) for alle nettverk

I denne utførelsesformen av oppfinnelsen inneholder et enkelt OSA rammeverk alle nettverk og en SCF representerer alle underliggende nettverk. F.eks. vil oppkallskontroll SCF inneholde oppkallskontrollevner for GSM/UMTS-nettverk, PSTN/ISDN-nettverk og det IP-baserte nettverket. Det samme gjelder for andre SCF-er som vist i fig. 6.

På denne måten kommuniserer hver SCF med alle nettverk. F.eks. mappes CC SCF på grensesnittene som utsteder oppkallskontroll i GSM-nettverket, PSTN/ISDN-nettverket og det IP-baserte nettverket. Applikasjonene er i stand til å utføre oppkallskontroll på alle nettverk ved å benytte kun en enkelt CC SCF. Det samme gjelder for andre SCF.

Ytterligere funksjonalitet

A. SCF-navngivningsplan

En SCF representerer nå flere underliggende nettverk og det er nødvendig å spesifisere hvert eneste av dem. Det er også nødvendig å gjenkjenne eieren av hvert nettverk dvs. nettverksoperatøren for hvert nettverk.

I denne utførelsesformen av oppfinnelsen er det introdusert en generell serviceegenskap (General Service Property) kalt " underliggende nettverk", som indikerer hvilket underliggende nettverk en SCF samhandler med. Egenskapsverdien er et sett med strenger hvor hver streng inneholder et par: <operatør, nettverlo. F.eks. for en brukerstatus (US) SCF kan verdien være: { <Tetenor, GSM>, <Netcomt GSM>, <Telenor, IP- based ( SIP) >). Dette er illustrert i eksempelet i fig. 7.1 fig. 7 velger applikasjonen (trades) brukerstatus SCF i GSM-nettverket og det IP-baserte nettverket, ved å benytte de ønskede serviceegenskapene i OSA-rammeverket. Dette er indikert ved 1 i fig. 7. OSA-rammeverket godkjenner deretter servicetradingen, utfører en ny forekomst av en brukerstatus SCF, som kan samhandle både med GSM/UMTS-nettverket og det IP-baserte nettverket, og returnerer deretter en referanse til brukerstatusforekomsten, til applikasjonen, som vist ved 1.1 'New' i flg. 7.

B. Dispatchingfunksjon

Hver SCF er i denne utførelsesformen nå ansvarlig for alle underliggende

nettverk, derfor må grensesnittklassene (Interface Classes) til en SCF mappes på alle grensesnittene for hvert nettverk (én-til-mange mapping). F.eks. må oppkalls-kontrollgrensesnittklassene (Cali Control Interface Classes) implementere mappingen mellom OSA oppkallskontroll API til SS7 INAP for PSTN/ISDN-nettverket, mappingen mellom OSA oppkallskontroll API og SIP-protokollen for det IP-baserte nettverket og mappingen mellom OSA oppkallskontroll API og til CAMEL for GSM/UMTS-nettverket. Dette er vist i fig. 8.

Siden nettverksutstyret i hvert underliggende nettverk kan utvikles av forskjellige leverandører, f.eks. IN-systemene for GSM er utviklet av Ericsson, Alcatel; SIP-servere utviklet av HotSip, Dynamicsoft, Ubiquity, etc.) vil noen problemer inntreffe. Hver leverandør er kun i stand til å implementere mappingen av OSA-grensesnittklassene til grensesnittene til deres nettverksutstyr. I tillegg er løs-ningen ikke fleksibel siden det er påkrevet at en leverandør utvikler mappingene fra OSA-grensesnittklassene til alle de nettverksspesifikke grensesnittene i alle heterogene nettverk.

I denne utførelsesformen av den foreliggende oppfinnelsen gjøres noen nødvendige modifikasjoner til OSA. En SCF er delt i to separate komponenter: • Én komponent implementerer mappingene fra OSA-grensesnittklassene til grensesnittene til de underliggende nettverkene. • En annen komponent er ansvarlig for å oversende en anmodning fra en applikasjon til den korrekte SCF koplet til det korrekte underliggende nettverket.

Ved å splitte SCF i to komponenter behøver nettverksutstyrleverandører kun å utvikle mappingen av OSA-grensesnittklassene til grensesnittene på deres nettverksutstyr (én-til-én mapping) mens applikasjoner må håndtere kun én SCF-forekomst selv om SCF samhandler med mange heterogene nettverk. Komponenten som implementerer grensesnittmappingene er praktisk identisk til SCF-ene spesifisert i OSA.

Komponenten ansvarlig for å oversende anmodninger fra applikasjoner, " SCF dispatcher", er en tilleggsfunksjon til OSA. Grensesnittet til applikasjonene må selvfølgelig være det samme som spesifisert for hver SCF i OSA-spesifikasjonen.

I tillegg finnes det et "registreringsgrensesnitt" mellom de to SCF-komponentene, som muliggjør SCF-ene for hvert nettverk å registrere hos " SCF dispatcheren". Den nettverksspesifikke SCF tilveiebringer " SCF dispatcheren" en referanse til seg selv og serviceegenskapene som den støtter. På denne måten har " SCF dispatcheren" kjennskap til mulighetene for den nettverksspesifikke SCF og er da i stand til å registrere seg selv med OSA-rammeverket, å forsyne serviceegenskapene som den støtter, dvs. summen av alle serviceegenskapene tilveie-brakt av hver nettverksspesifikke SCF-forekomst.

For applikasjon vil en forekomst av SCF dispatcher bli skapt Avhengig av hvilket underliggende nettverk som applikasjonen har tillatelse til å bruke service-egenskaper på, vil respektive forekomster av SCF for hvert nettverk bli opprettet. SCF dispatcherforekomsten lagrer referansene til alle disse SCF-forekomstene. "SCF dispatcheren" inkorporerer også funksjonalitet for å velge den rette SCF-forekomsten når en anmodning ankommer fra en applikasjon. For å illustrere nød-vendigheten av en slik funksjon, la oss anta at en applikasjon anmoder om status til en bruker til US SCF. Applikasjonen har en servicen i våavtaleind i kasjon som tillater den å benytte US SCF for GSM-nettverket, PSTN/ISDN-nettverket og IP-baserte nettverket (SIP). US SCF ("US SCF dispatcher") er i stand til å samhandle med alle tre underliggende nettverk. På denne måten må den være i stand til å be-stemme hvilket underliggende nettverk som anmodningen relateres til, for å kunne oversende anmodningen til den korrekte US SCF forekomsten. Dette er faktisk det samme krav som beskrevet i den tidligere utførelsesform 1, nemlig å velge den

korrekte SCF-forekomsten basert på terminal ID.

Derfor bør "SCF dispatcheren" benytte terminal ID administratoren (TA) for å spørre etter SCF-forekomsten fra terminal ID. "SCF dispatcheren" er da i stand til å oversende anmodningen fra applikasjonen til den korrekte SCF-forekomsten, ved å benytte resultatet fra spørringen til terminal ID administratoren. Merk at alle responser og rapporter fra nettverk SCF-ene går gjennom "SCF dispatcheren" før de blir sendt til den respektive applikasjonen. Dette er illustrert i fig. 9.

C. Valg av SCF-forekomst basert på terminal ID

Det er et behov for en terminal ID administrator som også vist i fig. 9. Terminal ID administratoren (TA) inneholder en database/registerservice som inneholder mappingen mellom applikasjoner og SCF-forekomstene, mappingen mellom SCF-forekomstene og nettverk og til sist mappingen mellom nettverk og terminal ID-ene. Forholdene opprettholdt av terminal ID administratoren er vist i fig. 10. Nummerne i figuren indikerer relasjonen. 1 betyr én og nøyaktig én, mens +1 betyr én eller mer.

Terminal ID administratoren gjør det mulig for nettverksoperatører å registrere endringer når de inntreffer. Terminal ID administratoren tilbyr også et grensesnitt til SCF-dispatcherne som inneholder den følgende metoden: getSCFinstance( <terminallD>, <applicationlD><SCFreference>), hvor <terminaUD> er terminal ID som applikasjonen håndterer

<applicationlD> er ID forden anmodende applikasjon og

<SCFreference> er referansen til SCF- forekomsten returnert av SCF- forekomsten Denne fremgangsmåten tillater SCF dispatcherne å hente referansen til den korrekte SCF-forekomsten for en gitt terminal for å oversende anmodningen til den SCF-forekomsten.

Terminal ID administratoren i denne andre utførelsesformen er ikke synlig og tilgjengelig for applikasjonene på den samme måten som i den første utførel-sesformen, men eksisterer kun på innsiden av rammeverket, f.eks. for SCF-dispatcheren.

Eksempel

La oss anta at en applikasjon ønsker å erverve brukerstatusen til en terminal ID, f.eks. telefonnummer 12345678. Applikasjonen sender en spørring til CC SCF dispatcheren, som inkluderer <terminal ID> = 12345678 og navnet på SCF, <SCFtype> = "brukerstatus". CC SCF dispatcheren sender en anmodning (getSCF instance) til terminal ID administratoren via terminal ID til SCF-forekomstmapping. Som svar mottar CC SCF dispatcheren objektreferansen til brukerstatus SCF som den anmodende terminal ID hører til. Nå kan dispatcheren benytte den korrekte US SCF uten å være bekymret med underliggende nettverk.

Utførelsesform 3: Et rammeverk for hvert nettverk

I denne utførelsesformen inneholder ett OSA rammeverk kun ett underliggende nettverk. F.eks. har OSA-rammeverket i GSM-nettverket kun ansvar for serviceevnene i GSM-nettverket, den kontrollerer slik alle SCF-er (CC SCF, US SCF vist i fig. 11) i GSM-nettverket. Det samme gjelder for PSTN/ISDN-nettverket og det IP-baserte nettverket som vist i fig. 11.

Hver SCF er mappet på grensesnittene spesifikke for hvert nettverk. F.eks. er CC SCF i GSM-nettverket mappet på grensesnittene som utsteder oppkallskontroll (Cali Control) i GSM-nettverket. Det samme gjelder for CC SCF i PSTN/ISDN-nettverket og det IP-baserte nettverket. Dette tillater applikasjoner å gjøre bruk av serviceegenskapene i alle underliggende nettverk, ved å adressere til hvert OSA rammeverk separat.

Tilleggsfunksjonalitet

A. Valg av rammeverk basert på terminal ID-er

Applikasjonene må vite hvilket rammeverk som skal adresseres gitt en terminal ID. I denne utførelsesformen har hvert rammeverk SCF " terminal ID informator". Terminal ID informatoren SCF har et grensesnitt som tillater applikasjoner å spørre om en terminal hører til et underliggende nettverk støttet av rammeverket. Spørreprosedyren kan uttrykkes som følger: TerminallnfoReq <Terminal ID, betong ( True/ False) >

Terminal ID sammen med en sann eller usann returneres fra SCF-grensesnittet

gjennom OSA rammeverket til den spørrende applikasjonen. Hvis terminalen ikke hører til rammeverket, returnerer prosedyren en usann og applikasjonen fortsetter å spørre andre rammeverk helt til den mottar et sant som svar. Applikasjonen kan da velge å benytte den ønskede SCF. Sann/usann er Bolsk representert.

Eksempel

En applikasjon ønsker å erverve brukerstatus for en terminal ID, f.eks. telefonnummer 12345678. Applikasjonen sender en spørring til et OSA rammeverk, som inkluderer <terminal ID> = 12345678 og navnet på SCF, <SCFtype> = "brukerstatus". OSA rammeverket videresender anmodningen til terminal ID informator SCF. Hvis terminal ID eksisterer i det rammeverket, returnerer informator SCF grensesnittet en sann til OSA rammeverket. Applikasjonen vil da velge å benytte den ønskede SCF. Hvis en usann returneres, vil applikasjonen sende anmodningen til et annet OSA rammeverk.

Utførelsesform 4: Kommunikasjon og samarbeid mellom forskjellige OSA rammeverk

I denne utførelsesformen inneholder ett OSA rammeverk kun et enkelt underliggende nettverk, slik som i den tredje utførelsesformen. Imidlertid i tillegg, er kommunikasjon og samarbeid muliggjort mellom rammeverkene. Driftssam-arbeid mellom rammeverkene etableres og applikasjoner kan være nødt til å håndtere kun ett OSA rammeverk for å kunne være i stand til å benytte serviceevnene fra mange heterogene nettverk (se fig. 12).

I tillegg til SCF-ene i "hjemme" rammeverket, kan applikasjonene også benytte SCF-ene som hører til andre rammeverk i andre nettverk ved ganske enkelt å utstede anmodninger mot deres "hjemme" rammeverk. Rammeverket vil da kommunisere med det aktuelle rammeverket for å spørre etter referansen til SCF-forekomsten. Hvis ingen slik forekomst ble skapt for applikasjonen, vil det "frem-mede" rammeverket skape én og returnere referansen til "hjemme" rammeverket. "Hjemme" vil da returnere referansen til den anmodende applikasjon. For en serviceevnefunksjon kan applikasjonen ha referanser til flere SCF forekomster, som representerer forskjellige nettverk slik som GSM, PSTN eller iP. Serviceegenskapene for hver SCF forekomst er derfor differensiert. Terminal ID administratoren vil, når gitt en terminal ID, returnere referansen til den SCF som skal benyttes. Dette er illustrert i fig. 13 som viser anvendelse av US SCF i både GSM- nettverket og IP-baserte nettverket.

La oss anta at en applikasjon velger en brukerstatus SCF i GSM-nettverket og en brukerstatus SCF i det IP-baserte nettverket, ved å benytte rammeverket i GSM-nettverket. (1. og 2. i fig. 13.) US i GSM-nettverket forhandles på vanlig måte som definert av OSA. Rammeverket i GSM-nettverket bør deretter spørre rammeverket i det IP-baserte nettverket om å skape en ny US SCF forekomst, ved å benytte serviceegenskapene tilført av applikasjonen og returnere en referanse til US forekomsten til applikasjonen. (Referansen er en peker til den opprettede SCF forekomsten. Den faktiske utførelsesformen er avhengig av implementasjonen.) Derfor, omfatter OSA grensesnittet i denne utførelsesformen mekanismer for å gjøre det mulig for et nettverk å velge en SCF i et annet nettverk og til å være i stand til å motta en referanse til SCF forekomsten. I fig. 13 er dette 2-1. hvor OSA rammeverket i GSM-nettverket velger (forhandler) med US SCF i det IP-baserte nettverket ved å benytte en fremgangsmåte i OSA rammeverkkommunikasjon API i OSA rammeverket i det IP-baserte nettverket. Da returnerer rammeverket referansen for SCF forekomsten til applikasjonen ved å benytte en vanlig forhandlings-funksjon spesifisert av OSA standarden. 12-2. i fig. 13 godkjenner OSA rammeverket for det IP-baserte nettverket serviceforhandlingen og skaper en ny forekomst av en US SCF for det IP-baserte nettverket og returnerer en referanse til SCF til OSA rammeverket i GSM-nettverket, som deretter returnerer referansen til SCF-applikasjonen.

Tilleggsfunksjonalitet

A. Kommunikasjon mellom rammeverk

Rammeverkene for OSA for de forskjellige underliggende nettverkene kjenner til hverandre og samarbeider for å tjene applikasjonene. Hvilke SCF-er som tilbys mellom de foreskjellige rammeverkene er definert på forhånd. I tillegg er de følgende funksjonene inkludert i OSA rammeverkene:

Autentisering mellom rammeverkene

For å forhindre ulovlig bruk og angrep er det foretrukket å ha en sterk gjensidig autentiseringsprosedyre mellom rammeverkene før enhver videre operasjon mellom disse tillates. Autentiseringsprosedyren kan være en hvilken som helst kjent i teknikken.

Servicehandlinger mellom rammeverk

I denne utførelsesformen av oppfinnelsen er et hvert rammeverk utvidet med et grensesnitt som tillater andre rammeverk å anmode om informasjon om de SCF som tilbys av rammeverket. Grensesnittet inkluderer derfor den følgende SCF anmodningsmetoden: SCFrequest ( <requestingFrameworklD>, <ListOfSCFoffered>), hvor <æquestingFrameworklD> er identiteten til det anmodende rammeverk og <ListOfSCFoffered> er listen over de tilbudte SCF som tilbys til det anmodende rammeverk. Denne listen kan være forskjellig avhengig av det anmodende rammeverk.

Når listen over tilbudte SCF mottas, lagrer det anmodende OSA rammeverk listen med tilbudte SCF på samme måten som "lokalt" registrerte SCF. På denne måten er det muliggjort å vise den til de anmodende applikasjonene. Det lagrer også in-formasjonen om hvilke OSA rammeverk som eier hvilke SCF.

Serviceanvendelse mellom rammeverk

Hvert rammeverk er utvidet med et grensesnitt som tillater andre rammeverk å benytte dets SCF-er. Grensesnittet inkluderer de følgende metoder: getSCFinstance( <setvicelD>, <serviceProperties>, <reference>, <frameworklD>, <applicationlD>), hvor

<servicelD> er ID til den anmodende SCF,

<serviceProperties> er listen over egenskaper spesifisert av applikasjonen som hører til det anmodende nettverk,

<reference> er referansen til SCF forekomsten,

<frameworklD> er ID til det anmodende rammeverk,

<applicationlD> er ID til den anmodende applikasjon.

Med denne fremgangsmåten kan et OSA rammeverk anmode et annet rammeverk om å returnere referansen til SCF forekomsten iht. serviceegenskapene forespurt av dens applikasjon. Hvis ingen slik forekomst eksisterer, vil rammeverket lage en. OSA rammeverket må lagre den mottatte referansen med dets respektive OSA rammeverk. Et OSA rammeverk bør ha en liste over SCF forekomstreferanser og deres respektive rammeverk. Kommunikasjon mellom OSA rammeverkene, ved å benytte grensesnittene spesifisert over, er vist i fig. 14.

B. Terminal ID administrator

Gitt en terminal ID behøver applikasjonen å vite hvilken SCF forekomst som skal benyttes siden terminalene kan høre til forskjellige nettverk og derfor hånd-teres av forskjellige SCF forekomster. Igjen behøver disse applikasjonene assi-stanse fra rammeverket. I denne utførelsesformen er hvert rammeverk utstyrt med en terminal ID administrator (TA), som er implementert som en SCF. TA SCF er lik til den beskrevet i utførelsesform 1.1 tillegg er TA SCF utstyrt med terminal ID områder støttet av hvert OSA rammeverk. (En terminal ID kan f.eks. være et telefonnummer eller en IP-adresse eller et navn.) Disse kan tilføres på forskjellige måter slik som off-line installasjon, ved å muliggjøre samvirke mellom TA-ene eller ved å ha en felles informasjonsdatabase.

Eksempel

En applikasjon ønsker å erverve brukerstatus for en terminal ID, f.eks. telefonnummer 12345678. Applikasjonen sender en spørring til et OSA rammeverk, som inkluderer <terminal ID> = 12345678 og navnet til SCF, <SCFtype> = "brukerstatus". OSA rammeverket sender videre anmodningen til terminal ID administrator SCF. Hvis terminal ID eksisterer i det rammeverket, vil applikasjonen da velge å benytte den ønskede SCF. Hvis den anmodende terminal ID er på utsiden av de områdene som støttes av OSA, vil OSA rammeverket anmode et annet rammeverk iht. rammeverklisten over SCF forekomstreferansene og deres respektive rammeverk.

Ved å ha beskrevet foretrukkede utførelsesformer av oppfinnelsen vil det være tydelig for de faglærte i teknikken at andre utførelsesformer som inneholder konseptene kan benyttes. Disse og andre eksempler på oppfinnelsen illustrert over er kun tenkt som eksempler og det faktiske omfanget av oppfinnelsen skal bestemmes fra de følgende kravene.

Claims (35)

1. Telekommunikasjonssystem som tilveiebringer appiikasjonsserviceaksess på et flertall heterogene nettverk, omfattende en åpen serviceaksess (OSA) utvidelse med minst ett rammeverk som tilveiebringer grensesnitt mellom applikasjonene og de flere heterogene nettverk, karakterisert ved at serviceaksessutvidelsen omfatter en terminal ID administrator som tilveiebringer informasjon til applikasjonene ved valg av det påkrevde nettverk basert på terminal ID.

2. Telekommunikasjonssystem som tilveiebringer utvidet åpen serviceaksess for applikasjoner på multiple heterogene nettverk idet systemet omfatter ett felles rammeverk for nevnte nettverk og én serviceevnefunksjon (SCF) for hvert nettverk for å tilveiebringe et nettverksspesifikt grensesnitt, karakterisert ved at serviceevnefunksjonene omfatter en generell serviceegenskap som indikerer hvilket underliggende nettverk en SCF samvirker med.

3. Telekommunikasjonssystem ifølge krav 2, karakterisert ved at den generelle serviceegenskap er en streng som inneholder et <operatør, nettverk> par.

4. Telekommunikasjonssystem ifølge krav 2, karakterisert ved en terminal ID administrator som velger den påkrevde nettverksserviceevnefunksjonen for en applikasjon basert på terminal ID.

5. Telekommunikasjonssystem ifølge krav 4, karakterisert ved at terminal ID administratoren omfatter en data-base/register som inneholder mappeinformasjon mellom applikasjoner og terminal ID-ene.

6. Telekommunikasjonssystem i henhold til et av kravene 4 eller 5, karakterisert ved at terminal ID administratoren omfatter en data-base/register som inneholder mappeinformasjon mellom applikasjoner og serviceevnefunksjonforekomstene, mellom serviceevnefunksjonforekomstene og nettverkene og mellom nettverkene og terminal ID-ene.

7. Telekommunikasjonssystem ifølge krav 4, karakterisert ved at terminal ID administratoren kan oppdateres i sanntid.

8. Telekommunikasjonssystem ifølge krav 4, karakterisert ved en terminaladministrator (TA SCF) som inneholder grensesnittklasser for applikasjonsanmodninger, for å tilveiebringe et grensesnitt mellom den anmodende applikasjon og terminal ID administratoren.

9. Telekommunikasjonssystem ifølge krav 2, karakterisert ved at terminaladministratoren (TA SCF) omfatter programanordninger for å tillate en applikasjon - å hente en referanse til den korrekte serviceegenskaptjenesteforekomsten for en gitt terminal, - å anmode om serviceevneforekomstreferansene til flere terminal ID-er samtidig, - å hente en nettverks ID til en gitt terminal, - å hente referansene til alle dens serviceevnefunksjonforekomster, og - å hente referansene over alle dens serviceevnefunksjonforekomster på et spesifikt nettverk.

10. Telekommunikasjonssystem som tilveiebringer utvidet åpen serviceaksess for applikasjoner på multiple heterogene nettverk, idet systemet omfatter ett unikt felles rammeverk for nettverkene og en felles serviceevnefunksjon (SCF) for nettverkene som tilveiebringer et felles nettverksgrensesnitt, karakterisert ved at serviceevnefunksjonene omfatter en generell serviceegenskap som indikerer hvilket underliggende nettverk en SCF samhandler med.

11. Telekommunikasjonssystem ifølge krav 10, karakterisert ved at den generelle serviceegenskap er et sett med strenger, der hver streng inneholder et <operator, nettverk> par.

12. Telekommunikasjonssystem i henhold til krav 10, karakterisert ved at grensesnittet omfatter serviceevnegrensesnitt-klasser som tilveiebringer én-til-mange mapping mellom applikasjoner og grensesnittene til de underliggende nettverkene.

13. Telekommunikasjonssystem i henhold til krav 10, karakterisert ved at den felles serviceevnefunksjon omfatter en mappeanordning for mapping av grensesnittklasser på nettverksgrensesnittene og en dispatcheranordning som oversender en anmodning fra en applikasjon til en korrekt nettverksgrensesnittklasse.

14. Telekommunikasjonssystem i henhold til krav 13, karakterisert ved et registreringsgrensesnitt mellom mappeanordningen og dispatcheranordningen som muliggjør registrering av nettverkene hos dispatcheren.

15. Telekommunikasjonssystem i henhold til krav 13, karakterisert ved at dispatcheranordningen omfatter valganordninger som velger den korrekte serviceevnefunksjon (SCF) for en anmodning som ankommer fra en applikasjon.

16. Telekommunikasjonssystem i henhold til krav 10, karakterisert ved en terminal ID administrator som velger den påkrevde nettverksserviceevnefunksjonen (SCF) for en applikasjon basert på terminal ID.

17. Telekommunikasjonssystem i henhold til krav 12, karakterisert ved at terminal ID administratoren omfatter en data-base/register som inneholder mappeinformasjon mellom applikasjoner og terminal ID-ene.

18. Telekommunikasjonssystem i henhold til et av kravene 16 eller 17, karakterisert ved at terminal ID administratoren omfatter en data-base/register som inneholder mappeinformasjon mellom applikasjoner og serviceevnefunksjonforekomstene, mellom serviceevnefunksjonforekomstene og nettverkene, og mellom nettverkene og terminal ID-ene.

19. Telekommunikasjonssystem i henhold til krav 16, karakterisert ved at terminal ID administratoren er oppdaterbar i sanntid.

20. Telekommunikasjonssystem i henhold til krav 16, karakterisert ved at terminal ID administratoren (TA SCF) tilveiebringer et grensesnitt for SCF dispatcheranordningen, idet terminal ID administratoren omfatter programanordninger som tilveiebringer - å hente en referanse for den korrekte serviceevneforekomstforen gitt terminal for å oversende anmodningen til den SCF forekomsten, som inkluderer - å hente terminal ID som applikasjonen håndterer, - å hente applikasjon ID til den anmodende applikasjon, og referansene for serviceevnefunksjonforekomstene returnert av SCF forekomsten.

21. Telekommunikasjonssystem som tilveiebringer utvidet åpen serviceaksess for applikasjoner på multiple heterogene nettverk, idet systemet omfatter et rammeverk for hvert nettverk, der hvert rammeverk har en serviceevnefunksjon (SCF) for nevnte nettverk som tilveiebringer et nettverksspesifikt grensesnitt, karakterisert ved at hvert nettverk omfatter en terminal ID informator som tilveiebringer en serviceevnefunksjon til applikasjonene angående nettverksvalg basert på terminal ID.

22. Telekommunikasjonssystem i henhold til krav 21, karakterisert ved at terminal ID informatoren returnerer en streng som inneholder et <terminal ID, tilhører (sann/usann)> par til den anmodende applikasjonen.

23. Telekommunikasjonssystem i henhold til krav 21, karakterisert ved at hvert rammeverk omfatter en mekanisme som muliggjør valg av en serviceevnefunksjon i et annet rammeverk og mottak av en referanse til nevnte serviceevnefunksjon.

24. Telekommunikasjonssystem i henhold til krav 23, karakterisert ved at de valgbare serviceevnefunksjonene for rammeverkene er forhåndsdefinert.

25. Telekommunikasjonssystem i henhold til krav 21, karakterisert ved at alle rammeverkene omfatter en gjensidig autentiseringsprosedyre.

26. Telekommunikasjonssystem i henhold til krav 21, karakterisert ved at hvert rammeverk omfatter et utvidet grensesnitt som muliggjør andre rammeverk å anmode om informasjon om serviceevnefunksjonene tilbudt av nevnte rammeverk.

27. Telekommunikasjonssystem i henhold til krav 26, karakterisert ved at det utvidede grensesnitt omfatter en anmodningsprosedyre som returnerer en identitet for det anmodende rammeverk sammen med en liste over de forhåndsdefinerte serviceevnefunksjonene som tilbys av nevnte rammeverk, og en henteprosedyre som muliggjør et rammeverk å anmode et annet rammeverk om å returnere referanser over serviceevnefunksjonforekomstene i overensstemmelse med serviceegenskapene spesifisert av den anmodende applikasjon.

28. Telekommunikasjonssystem i henhold til krav 21, karakterisert ved en terminal ID administrator som velger den påkrevde nettverksserviceevnefunksjonen for en applikasjon basert på terminal ID.

29. Telekommunikasjonssystem i henhold til krav 28, karakterisert ved at terminal ID administratoren omfatter en data-base/register som inneholder mappeinformasjon mellom applikasjoner og terminal ID-ene.

30. Telekommunikasjonssystem i henhold til et av kravene 28 eller 29, karakterisert ved at terminal ID administratoren omfatter en data-base/register som inneholder mappeinformasjon mellom applikasjoner og serviceevnefunksjonforekomstene, mellom serviceevnefunksjonforekomstene og nettverkene, og mellom nettverkene og terminal ID-ene.

31. Telekommunikasjonssystem ifølge krav 28, karakterisert ved at terminal ID administratoren omfatter et informasjonsgrensesnitt som tilveiebringer terminal ID administratoren med informasjon angående terminal ID områdene støttet av hvert nettverk.

32. Telekommunikasjonssystem ifølge krav 28, karakterisert ved at terminal ID administratoren er oppdaterbar i sanntid.

33. System ifølge ett av kravene 1,2,10 eller 21, karakterisert ved at nettverkene er minst ett telekommunikasjonsnett-verk og minst ett datanettverk.

34. System ifølge krav 33, karakterisert ved at telekommunikasjonsnettverket er trådløst eller kabelbasert, f.eks. mobilt, UMTS, GSM, PSTN/ISDN.

35. System ifølge krav 33, karakterisert ved at datanettverket er et pakkebasert nettverk, f.eks. IP (kabelbasert), trådløst LAN, Bluetooth eller Hiper LAN (trådløst).