NO341143B1 - Samvirking - Google Patents

Description

Oppfinnelsen vedrører samvirking mellom domener, mer særskilt samvirking mellom ulike IP (Internet protocol)-baserte domener.

Utviklingen av kommunikasjonsteknologien, særlig IP-basert kommunikasjonsteknologi, og brukerterminaler har muliggjort mange kommunikasjonsmuligheter. Mens kommunikasjonsteknologien og bruken av kommunikasjonsmulighetene har gått frem med stormskritt, øker også antall domener og domeneoperatører, så som tjenesteleverandører eller konvensjonelle nettverksoperatører, i en stadig økende grad. Et grunnleggende krav for å muliggjøre bruk av ulike tjenester mellom brukere i ulike domener og for å muliggjøre kommunikasjon mellom abonnenter i ulike domener, er samvirket mellom domenene til de ulike operatørene.

Kjent teknikk inkluderer US 20020010799 som viser et relesystem med forskjellige enheter som forenkler overføringen av en pakke mellom systemer som har forskjellige ruterprotokoller. Videre er kjent teknikk også beskrevet i 3GPP TSG SA WG3 Security — S3#15bis, S3z000005, Telenor (origin GSMA), "Inter- PLMN Backbone Guidelines", Ad-Hoc meeting 08-09 November, 2000, Munich, Germany, side 1-31.

Et problem som relaterer seg til samvirkingen og den IP-baserte kommunikasjonen, særlig regningsbetaling, er at det bør finnes en mekanisme for å sikre at senderen er den som vedkommende hevder å være.

En hensikt med oppfinnelsen er å tilveiebringe en fremgangsmåte og en anordning for implementering av fremgangsmåten, for på den måten å kunne fjerne de foran nevnte ulemper og lette samvirkearrangementet mellom domenene. Hensikten med oppfinnelsen oppnås med en fremgangsmåte, et kommunikasjonssystem, en nettverksnodeog et datamaskinprogramprodukt, som alle kjennetegnes med det som er angitt i de respektive selvstendige patentkravene. Foretrukne utførelser av oppfinnelsen er angitt i de uselvstendige patentkravene.

Oppfinnelsen baserer seg på en detektering av problemet og løsning av det ved å bruke en nettverksnode via hvilken i det minste signal- og korresponderende kontrollplantrafikk med andre domener går. Nettverksnoden innbefatter eller har tilgang til en logisk, sentralisert database som inneholder informasjon som nødvendig for samvirkingen. Slik informasjon innbefatter informasjon om domener som har samvirkingsavtaler og eksempelvis adresseinformasjon som relaterer seg til domener. Når nettverksnoden mottar en melding, vil nettverksnoden bruke informasjonen i databasen for å sjekke senderens korrekthet og forekomsten av en avtale. Dersom senderen ikke er falsk og det foreligger en avtale, så vil nettverksnoden fremlede meldingen med bruk av adresseinformasjonen i databasen.

I en utførelsesform av oppfinnelsen bruker nettverksnoden informasjonen i databasen for å sjekke senderens korrekthet og at det foreligger en avtale. Dersom senderen ikke er falsk og det foreligger en avtale, så vil nettverksnoden fremsende meldingen, med bruk av adresseinformasjonen i databasen. En fordel med en slik utførelsesform er at hvert domene må sette opp og holde bare én assosiasjon, assosiasjonen til nettverksnoden, uavhengig av det antall domener hvormed domenet har samvirkingsavtaler. Utførelsesformen muliggjør således en sikret kommunikasjon, hvilket er et krav for å muliggjøre en regning. Samvirkingen med sikret kommunikasjon ifølge kjent teknikk, blir typisk implementert ved hjelp av såkalt IP-sikker (IPsec) tunnelering. Som det vil være kjent for fagfolk, må hvert domene sette opp og holde IPsec-sikkerhetsassosiasjoner med hvert av de andre domenene for IPsec-tunnelering. Typisk holdes assosiasjonene separat for inngående trafikk og for utgående trafikk. En oppsetting av, håndtering av og holding av disse assosiasjonene med flere titall eller flere hundre andre domener, er krevende og unngås med utførelsesformen.

I en annen utførelsesform av oppfinnelsen er nettverksnoden lokalisert i et pålitelig nettverk. Det faktum at nettverksnoden er i et pålitelig nettverk, løser sikringsproblemer og muliggjør utstedelse av regning, dvs. krav om betaling.

Oppfinnelsen vil nå bli beskrevet nærmere ved hjelp av foretrukne utførelseseksempler, under henvisning til tegningen hvor

Fig. 1 er et blokkskjema som viser et eksempel på et system ifølge en utførelsesform av oppfinnelsen, Fig. 2 er et blokkskjema for en proxy ifølge en utførelsesform av oppfinnelsen, Fig. 3 er et flytskjema som belyser funksjonaliteten til en proxy ifølge en utførelsesform av oppfinnelsen, og Fig. 4 er et signalkart som viser et eksempel på signalføring ifølge en utførelsesform av oppfinnelsen.

De nedenfor beskrevne eksempler er bare ment som sådanne. Selv om det i beskrivelsen kan refereres til "en", "én" eller "noen" utførelser på flere steder, så skal dette ikke nødvendigvis bety at hver slik referanse gjelder én og samme utførelse eller utførelser, eller at trekket bare gjelder for én enkelt utførelse.

Foreliggende oppfinnelse er virtuelt anvendbar for alle kommunikasjonssystemer med samvirking mellom ulike domener, og er særlig anvendbar for domener som støtter IP-baserte tjenester. Et domene er typisk et nettverk som betjenes av én enkelt administrativ myndighet, og uttrykket domene er her ment å dekke ulike nettverk som dekker både domenene til tjenesteleverandører som kjøper de ønskede bærertjenestene og domener til nettverkoperatører. Kommunikasjonssystemet kan være et fast kommunikasjonssystem og/eller et trådløst kommunikasjonssystem eller kombinasjoner av disse. Et eksempel på et slikt system er et IP-basert system, så som det tilgangsuavhengige IMS (IP-multimedia-subsystem) som har en lagdelt arkitektur hvor brukertrafikken er i brukerplanet og signaltrafikken, herunder sesjondrivingen, i brukerkontrollplanet. Kommunikasjonssystemer, særlig trådløse kommunikasjonssystemer, utvikles raskt. Slik utvikling kan kreve ekstra endringer av oppfinnelsen. Samtlige ord og uttrykk som benyttes her skal derfor tolkes i bred forstand, og de brukes bare for å illustrere eller belyse oppfinnelsen og ikke for å begrense den. Hva oppfinnelsen angår så er det relevante punktet funksjonen og ikke nettverksnoden hvor oppfinnelsen ligger.

Nedenfor skal oppfinnelsen beskrives med bruk av et system som bruker IMS og GRX (GPRS Roaming Exhange), som et eksempel på et system hvor oppfinnelsen kan anvendes, uten at oppfinnelsen skal være begrenset til slik anvendelse. Det skal nevnes at systemene, nettverkene og sendermetodene som benyttes, i og for seg er irrelevante med hensyn til oppfinnelsen. Derfor krever disse ingen nærmere detaljert beskrivelse. Foreliggende oppfinnelse relaterer seg primært til en nettverksnode via hvilken nettverksnodeforbindelsesetableringer mellom IP-baserte domener, eller i noen tilfeller også innenfor et IP-basert domene, kan gå, og nettverksnoden innbefatter en database som inneholder domenerelatert informasjon, beskrevet nærmere nedenfor, eller har tilgang til slik informasjon. Nettverksnoden er fordelaktig lokalisert i et pålitelig nettverk utenfor domenene. Nedenfor skal kombinasjonen av den eksterne noden og den korresponderende databasen benevnes som en proxy, uavhengig av hvorvidt de i virkeligheten er lokalisert i én og samme enhet.

Fig. 1 viser en meget forenklet systemarkitektur som bare innbefatter et kommunikasjonssystem 1, tre brukerinnretninger 2, 2', 2", ulike IP-baserte domener 3, 3', 3" og to pålitelige nettverk 4, 4'. Hvert av de ulike domenene er fortrinnsvis bare forbundet, direkte eller via ett eller flere domener og/eller pålitelige nettverk med eller uten en proxy, med en proxy, 41,41' som er lokalisert i et pålitelig nettverk. Ifølge en utførelsesform av oppfinnelsen kan imidlertid oppfinnelsen implementeres selv når et domene er forbundet med to eller flere proxyer og/eller når proxyen er lokalisert i domenet. For fagfolk tør det være klart at systemet også innbefatter andre innretninger, nettverksnoder, system enheter, funksjoner og strukturer som ikke krever nærmere beskrivelse her.

Brukerinnretningene illustrerer ulike endepunkter i en kommunikasjon, og de kan være mobile terminaler eller faste terminaler, så som PCer eller mobiltelefoner. Typen og funksjonaliteten til brukerinnretningene er irrelevant for oppfinnelsen og krever derfor ingen nærmere beskrivelse her.

Domenene kan være av samme type eller av ulike typer. De kan være domener til operatører som både er tjenesteleverandører og tilgangsoperatører, eller domener til tjenesteleverandører som kjøper tilgangstjenesten. Sistnevnte innbefatter ulike ADSL-tjenesteleverandører og andre private nettverk. Domenene kan bruke den samme protokollen eller ulike protokoller, eller ulike versjoner av samme protokoll. Et domene kan være et åpent domene eller et lukket domene. I eksemplet i fig. 1 er et domene 2 (TMS1) et domene av IMS-typen som bruker SIP, et domene 2" (IMS 2) er også et IMS-type-domene som bruker samme eller en annen versjon av SIP, og et domene 2' er et privat domene som eksempelvis bruker H.323. IMS-type- domenene innbefatter typisk en GGSN (Gateway GPRS Support Node) via hvilken kontrollplan- og brukerplantrafikk går til og fra brukerinnretningene til IMS-delen av domenet. IMS-delen innbefatter typisk én eller flere samtalesesjon-kontrollfunksjoner CSCF og en BG (border gateway) som fordelaktig er forbundet med proxyen. Brukerplantrafikk til andre domener går typisk fra GGSN til BG og derfra enten til proxyen eller direkte til en BG i et annet domene, mens kontrollplantrafikken går fra GGSN til korresponderende CSCF/CSCF'er, derfra til en GB og så til proxyen.

Et pålitelig nettverk 4, 4' som inneholder en proxy 41,41', kan være basert på et sentralisert IP (Internet Protocol)-rutingsnettverk for en GRX, hvilket muliggjør forbindelse mellom ulike domener, roaming og et lukket system. GRX tilveiebringer et pålitelig nettverk, dvs. at tilgangen kontrolleres med mulighet for å garantere et visst tjenestenivå med forutsigbare forsinkelser, slik at således også IMS-brukerne kan tilbys mange tjenestetyper som krever et spesifikt tjenestenivå og forutsigbare forsinkelser, så som deling av sanntid-videoer. En annen fordel ved å bruke GRX som et mellomdomenenettverk er det faktum at som følge av kommersielle betalingsprosedyrer må nettverket være sikret og pålitelig, hvilket GRX er, og derfor kan den proxy via hvilken den mellom-domenetrafikken rutes, også benyttes for betalingsformål. Nok en fordel er at det kan brukes en eksisterende nettverksinfrastruktur, slik at man unngår behovet for bygging av en ny nettverksinfrastruktur.

Uttrykket "pålitelig nettverk" er her ment å betegne alle typer pålitelige nettverk som kan inneholde en proxy ifølge en utførelsesform av oppfinnelsen. Det skal nevnes at teknologien i et nettverk som inneholder proxyen, ikke har noen betydning som sådan relativt oppfinnelsen, så lenge man bare har den ønskede påliteligheten, dvs. i det minste kontrollerbar tilgang. Det pålitelige nettverket kan således være et privat IP-basert nettverk eller et offentlig kommunikasjonsnettverk. Også internett kan brukes som et pålitelig nettverk, forutsatt at man treffer sikringstiltak.

Ulike utførelsesformer av en proxy ifølge oppfinnelsen vil bli beskrevet nærmere nedenfor under henvisning til fig. 2, 3 og 4.

Selv om det ikke er vist i fig. 1, kan proxyen være forbundet med DNS (domenenavnserver) og/eller en NP-database (Number portability) og/eller en ENUM (elektronisk nummerering)-database og/eller til en korresponderende server/database som inneholder adresseinformasjon. Det samme gjelder for ulike servere som inneholder abonnentinformasjon. Proxyen kan også ha såkalt legacy-tilgang til et SS7 (signalsystem)-nettverk via en signalport for anmodning om informasjon fra en operatør som ikke har en ENUM-database. Implementeringen og funksjonen til disse serverne/databasene og hvordan proxyen innhenter den ønskede informasjonen, har ingen betydning med hensyn til oppfinnelsen og blir derfor ikke nærmere omtalt her.

Fig. 2 er et blokkskjema som viser en proxy ifølge en utførelsesform av oppfinnelsen. Proxyen kan eksempelvis være en SIP (session initiation protocol)-nettverkstilgangsport. I utførelsen i fig. 2 inneholder proxyen 41 en samvirkingsfunksjon 41-10 (IWF) ifølge en utførelsesform av oppfinnelsen, og en database 41-0. Alternativt kan proxy ha tilgang til en korresponderende database. Uttrykket database er her ment å dekke ulike løsninger som benyttes for lagring av data, så som lagring av data i én eller flere filer eller bruk av en desentralisert database. Eksempler på ulike utførelser av samvirkingsfunksjonen er beskrevet nærmere nedenfor under henvisning til figurene 3 og 4. Det tør være klart for fagfolk at en proxy også innbefatter andre enheter, funksjoner og strukturer, som ikke krever noen nærmere beskrivelse her. Eksempler på slike innbefatter én eller flere prosessorer, minne, inngangs-/utgangsbuss, ulike nettverksgrensesnitt, etc.

Databasen 41-0 inneholder for hvert domene det logiske navnet 41-1 til domenet, adressen 41-2 som benyttes når trafikk rutes til domenet, avtalene 41-3, dvs. informasjon vedrørende domener hvormed domenet har avtalt å samvirke, en modus 41-4 som benyttes med domenet og kapabilitet 41-5 informasjon vedrørende domenet.

Det logiske navnet 41-1 til domenet kan være en vertsdel i en logisk IP-adresse, dvs. en IP-adresse i formen a@x. v hvor vertsdelen kommer etter @-tegnet. Et logisk navn kan også være navnet til en operatør, et oppringt nummer eller en del av det oppringte nummeret, eksempelvis i domener som ikke bruker IP-adressering. Adressen 41-2 er den aktuelle rutingsadressen som brukes når trafikken rutes til (eller mot) domenet fra denne proxyen. Adressen er typisk en adresse til en portnettverksnode i domenet. Den kan også være adressen til en proxy hvortil domenet er forbundet. Dersom domenet bruker IP-adressering, vil adressen typisk være den nummeriske formen til den nummeriske IP-adressen.

Avtaleseksjonen 41-3 inneholder fordelaktig de logiske navnene til de domener som har samvirkingsavtaler med det aktuelle domenet. Dersom det aktuelle domenet er forbundet med denne proxyen, så er de alle fordelaktig partnerdomener. For domener som er forbundet med en annen proxy, er det tilstrekkelig at avtaleseksjonen inneholder de partnerdomener som er forbundet med denne proxyen. Laging av en avtale med et nytt domene krever derfor i sin enkleste form bare en addering av partnerdomenets logiske navn til avtaleseksjonen i databasen, hvoretter samvirkingen kan begynne, forutsatt at annen domenerelatert informasjon allerede er lagret. Selv om det ikke er vist i fig. 2, kan databasen også lagre avtalespesielle vilkår eller regler som bare gjelder for forbindelsene til og fra det domenet som avtalen relaterer seg til. Et eksempel på en avtaleegen informasjon er informasjon om hvorvidt brukerplantrafikken er rutet via proxyen eller ikke. Modus 41-4 informasjonen indikerer hvorvidt operatøren ønsker eller ikke ønsker at proxyen skal være en transparent proxy (T) eller en rygg-til-rygg-brukeragent (back-to-back user agent) (B2B)-proxy som endrer overtekstene i SIP-meldingene. Rygg-til-rygg-brukeragenten deltar i en forbindelse ved å motta og prosessere meldinger som en korresponderende server, så som en brukeragentserver, og ved å delta i alle samtaleanmodninger og ved å bestemme hvordan anmodningen skal besvares og hvordan utgående samtaler initieres, dvs. som en korresponderende brukeragentklient.

Kapabilitetsinformasjonen 41-5 inneholder informasjon vedrørende domenets egenskaper og indikerer de protokoller og fordelaktig de prosedyrer hvormed nettverkselementene i domenet utveksler informasjon. Eksempler på slik informasjon i IMS er SIP-profilnummeret, brukerdatatype(r), verdier av SDP-attributter og den benyttede IP-versjonen. På grunnlag av denne informasjonen vil proxyen vite hvilken meldingstype og informasjon som kan sendes til domenet, og kan, som svar på en melding som er i et annet format enn det som brukes av domenet, endre disse til et egnet format.

Det tør være klart at denne type av i det minste logisk sentralisert database i domener med samvirkingsavtaler, medfører den fordelen at eksempelvis adresseinformasjon og kapabilitetsinformasj on bare behøver å bli lagret én gang i et system. Oppdateringen av informasjonen muliggjøres også, fordi den bare krever én oppdatering.

Fig. 3 er et flytskjema som belyser funksjonaliteten til en proxy ifølge en utførelsesform av oppfinnelsen. I utførelsen i fig. 3 antas det for enkelthets skyld at en sesjon-invokasjon er akseptert. Brukerplantrafikken går altså gjennom proxyen, og proxyen holder sesjonsinformasjon sesjon-spesifikt. En annen forutsetning er at den sesjonsrelaterte trafikken i denne utførelsesformen inneholder en indikasjon på basis av hvilken proxyen gjenkjenner den sesjonen hvortil trafikken relaterer seg, slik at det derved bare sjekkes én sesjonsoppsettingsmelding. Det tør imidlertid være klart for fagfolk at denne sjekkingsprosedyren eller noen av de etterfølgende trinn, kan gjennomføres for hver mottatt melding. For enkelthets skyld er en videre forutsetning at én-til-mange kommunikasjon er transparent for proxyen, dvs. at proxyen bare mottar meldinger som har en enkelt mottaker. Fagfolk vil imidlertid vite hvordan utførelsesformen kan implementeres dersom én-til-mange kommunikasjon ikke er transparent for proxyen.

Sjekkingsprosedyren i fig. 3 begynner når proxyen mottar en melding i trinnet 300. Som respons på mottaket av meldingen vil proxyen i trinnet 301 sjekke hvorvidt meldingen er en sesjon-termineringsrelatert melding, så som en SIP-bye-melding. Hvis ikke, sjekker proxyen i trinnet 302 hvorvidt meldingen er en sesjonsoppsettingsmelding, så som en SIP-påkallingsmelding. Dersom den er det, så vil proxyen i trinnet 303 sjekke, ved hjelp av informasjonen i databasen, senderens navn, så som IP-vertsnavnet, i meldingen så vel som den adressen hvorfra meldingen er mottatt. Med andre ord, ved hjelp av eksemplet i fig. 2 og forutsatt at senderens navn i meldingen er domene 1, sjekkes det hvorvidt meldingen er mottatt fra 1.2.3. Ved å gjennomføre slik sjekking sikrer proxyen at senderen er den vedkommende hevder å være, dvs. at falske invitasjoner gjenkjennes på dette trinnet.

Dersom meldingen inneholder samme navn-adresseparet som i databasen (trinn 304), så vil proxyen, i trinnet 305, finne det riktige domenet på grunnlag av en mottakers navn i meldingen. Mottakerens navn er typisk i et format MSISDN (mobilabonnent ISDN nummer) eller NAI (nettverksaksessidentifiserer), dvs. en logisk IP-adresse a@x. v. Dette trinnet kan innbefatte en ENUM/MAP-forespørsel for å finne det riktige domenet, og eventuelt en riktig rutingsadresse, dersom mottakerens navn er i MSISDN-formatet og/eller dersom navnet er et portet navn.

(Portet navn betyr at abonnenten har endret en operatør uten å endre det logiske navnet). Dersom mottakerens navn er i NAI-formatet og navnet ikke er portet til et annet domene, så vil proxyen helt enkelt bruke vertsdelen av NAI. Domeneoperatøren kan således overlate spørsmål som relaterer seg til domene/nummer-bæreevnen for løsning av den operatøren som tilveiebringer proxyen. Dette muliggjør at også ikke-offentlige domener kan endres som offentlige, slik at håndteringen av disse domener derved lettes.

Proxyen vil så i trinnet 306 sjekke ved hjelp av brukerinformasjon i proxy ens database hvorvidt det foreligger en gyldig avtale mellom senderens domene og mottakerens domene. Foreligger det en avtale, så vil proxyen i trinnet 307 initiere sesjon-informasjon om denne sesjonen og i trinnet 308 foreta en sammenligning, ved hjelp av informasjonen som er lagret i databasen, av kapabilitetene til senderens domene og kapabilitetene i mottakerens domene. Dersom kontrollplankapabilitetene atskiller seg mellom de to (trinn 309), så vil proxyen i trinn 310 foreta de nødvendige endringer i meldingen og i trinn 310 legge informasjon vedrørende de ønskede kontrollplanendringer eller en indikasjon om at de er nødvendige, til sesjon-informasjonen. En forskjell som krever kontrollplan-trafikkendring kan være at senderens domene bruker IP-versjon 4 mens mottakerens domene bruker IP-versjon 6, slik at meldingen derfor må endres fra en IP-versjon 4 melding til en IP-versjon 6 melding. Etter endringene, eller dersom det ikke er nødvendig med noen endringer (trinn 309), vil proxyen i trinn 311 sjekke hvorvidt senderdomenets modus i databasen er transparent. Dersom modusen ikke er transparent (trinn 311), vil proxyen i trinn 312 foreta de nødvendige endringer i toppteksten og vil i trinn 312 til sesjon-informasjonen legge til en indikasjon eller informasjon om at B2B-modusen skal brukes. Etter endringene, eller dersom ingen endringer er nødvendig (trinn 311), vil proxyen sjekke, trinn 313, hvorvidt brukerplankapabilitetene atskiller seg mellom de to. Er det tilfellet, så vil proxyen i trinnet 340 legge informasjon til sesjon-informasjonen vedrørende de ønskede brukerplanendringene eller en indikasjon om at de er nødvendige. Et eksempel på brukerplanendringer er endring av kodeks, så som en VoIP-kodeks som endres til en PoC-kodeks (push-to-talk-over-cellular). Etter en oppdatering av sesjon-informasjonen, eller dersom det ikke er nødvendig med endringer (trinn 313), vil proxyen i trinn 315 fremlede den eventuelt endrede melding til adressen til mottakerens domene i proxyens database.

Proxyen initialiserer så i trinn 316 en betalingsbelastningsinformasjon om den aktuelle sesjonen.

Dersom det ikke forefinnes en gyldig avtale mellom senderens domene og mottakerens domener (trinn 306), eller dersom invitasjonen var en falsk invitasjon (trinn 304), vil proxyen sende en feil i trinn 317.

Dersom meldingen ikke relaterer seg til termineringen av en sesjon (trinn 301) eller til etableringen av sesjonen (trinn 302), betyr dette at den er en annen sesjonsrelatert trafikk, og proxyen vil da i trinn 318 gjennomføre de nødvendige belastningsrelaterte prosedyrer, dersom slike finnes, og de ønskede endringer, dersom slike er nødvendige, og vil så lede trafikken til adressen til mottakerens domene i proxyens database. Da proxyen vet hvordan den skal endre trafikken, inkludert det reelle innholdet i trafikken, behøver senderens domene eller mottakerens domene ikke å gjennomføre slike endringer, og behøver heller ikke å holde den nødvendige informasjonen.

Dersom meldingen relaterer seg til termineringen av sesjonen (trinn 301), så vil proxyen i trinnet 319 gjennomføre de nødvendige endringer, dersom slike er nødvendige, og vil så lede trafikken til adressen til mottakerens domene i proxyens database. Proxyen avslutter belastningen og stryker sesjon-informasjonen i trinnet 319.

Av det som er sagt foran tør det gå frem at de foran beskrevne trinn som relaterer seg til betalingsbelastning, muliggjør både bit-basert belastning og en belastning som baserer seg på noe annet, så som en tjenestespesifikk belastning basert på SIP/SDP-meldinger. Implementeringen av den aktuelle belastningen, så som dannelse av belastningsdataregistreringer etc, har ingen spesiell betydning i forbindelse med oppfinnelsen og er derfor ikke beskrevet nærmere her.

Av det som er sagt foran går det frem at proxyen muliggjør at forbindelsesbenene

kan være ulike forbindelsestyper. Eksempelvis kan et forbindelsesben være en VoIP (tale over IP)-forbindelse eller en forbindelse i samsvar med en H.323- eller en SIP-versjon, uavhengig av forbindelsestypen til det andre benet. Proxyen gjennomfører de nødvendige endringene på basis av informasjonen i proxyens database.

Fig. 4 viser signalering i samsvar med en utførelsesform av oppfinnelsen. I eksemplet i fig. 4 forutsettes det for enkelthets skyld at domenene MOI, M02 og M03 bruker like IMS-nettverk, og pålitelige nettverk som inneholder proxy 1 og proxy 2 er GRX-nettverk. Nok en forutsetning her er at i én-til-mange kommunikasjoner vil proxyen gjennomføre multiplikasjonen av den inviterende meldingen.

I eksemplet i fig. 4 starter brukeren A, en klient i domenet MOI, en spillsesjon ved å sende en kontrollplanmelding 4-1 for derved å invitere to venner, brukerne B og C, til å ta del i spill sesjonen. Meldingen kan være en SIP-melding. Systemet, eksempelvis CSCF, i MOI ser i punktet 4-2 at sesjonsetableringen er forbrukerne B og C, som ikke er hjemmebrukere, dvs. at de er klienter i andre domener. MOI merker dette på basis av identifisererne, så som MSISDN eller NAI som nevnt foran i forbindelse med fig. 3, for mottakerne, dvs. brukerne B og C. MOI kan bruke en statisk liste, MAP (mobil applikasjonsdel)-spørring, en ENUM-spørring, etc. Fordi brukerne B og C ikke er hjemmebrukere, ledes meldingen 4-1 (eksempelvis via en grenseport) til proxyen 1 i det pålitelige nettverket hvortil proxy MOI er forbundet.

Proxy 1 gjennomfører i punktet 4-3 en sjekking ved hjelp av sin database. Avhengig av implementeringen av proxyen 1, kan sjekkingen inneholde ett eller flere av de trinn som er beskrevet foran i forbindelse med fig. 3.1 dette eksemplet ser proxy 1 at MOI har en avtale med M02, operatøren til brukeren B, og med M03, som er operatøren til brukeren C. Fordi domenene i dette eksemplet er like, er det ikke nødvendig med noen endringer av meldingene. Det er bare adressefeltet som endres i dette eksemplet. Proxyen vil derfor lede innholdet i meldingen 4-1 mot de adresser som er lagret i databasen for proxyen 1 for M02 og M03. Fordi M02 også er forbundet med proxy 1, blir meldingen 4-1', som inneholder meldingen 4-1 og brukeren B som en mottaker, sendt til M02, mer presist til den nettverksnoden hvis adresse er i databasen, som så leder meldingen 4-1' til brukeren B. M03 er forbundet med en annen proxy, proxy 2, hvis adresse er i databasen for proxyen 1 for M03, og derfor sender proxy 1 meldingen 4-1 til proxyen 2 i meldingen 4-1". Denne meldingen inneholder meldingen 4-1 og brukeren C som en mottaker. Imidlertid er proxy 1 ikke klar over at adressen er for en annen proxy.

Proxy 2 gjennomfører i punktet 4-3a en sjekking ved hjelp av sin database. Avhengig av implementeringen av proxyen 2, kan sjekkingen innbefatte ett eller flere av de trinn som er beskrevet foran i forbindelse med fig. 3.1 dette eksemplet ser proxy 2 at MOI har en avtale med M03 og at det ikke er nødvendig med noen endringer av meldingene. Proxy 2 leder meldingen 4-1" til M03 på basis av adressen til M03 i databasen til proxy 2. M03 leder så meldingen 4-1" til brukeren

C.

Både brukeren B og brukeren C aksepterer den invitasjonen som bruker A sender, og sender korresponderende svar. Bruker B's svar, dvs. meldingen 4-4, sendes via M02 til proxy 1, som i punktet 4-3' gjennomfører sjekkingsprosedyren ved hjelp av databasen. Avhengig av implementeringen kan denne sjekkingen være den samme gjennomført i punktet 4-3 som respons på mottaket av meldingen 4-1, eller den kan innbefatte bare noen av trinnene i den sjekkingen som gjennomføres i bindingen 4- 3. Proxy 1 leder svaret, dvs. meldingen 4-4, til MOI på basis av adressen til MOI i databasen til proxyen 1. MOI leder svaret til bruker A.

Bruker Cs svar, dvs. en melding 4-5, sendes via M03 til proxyen 2, som så i punktet 4-3a' gjennomfører sjekkingsprosedyren ved hjelp av databasen. Avhengig av implementeringen kan denne sjekkingen være den samme som den som gjennomføres i punktet 4-3a som respons på mottaket av meldingen 4-1' eller den kan innbefatte bare noen av trinnene i den sjekkingen som gjennomføres i punktet 4-3a. Proxy 2 vil så lede svaret til proxy 1 på basis av adressen til MOI som gis i databasen til proxyen 2. Proxy 1 vil så i punktet 4-3" gjennomføre en lignende sjekking ved hjelp av databasen, på samme måte som i punktet 4-3'. Proxy 1 leder meldingen 4-5 til MOI på basis av adressen til MOI som gitt i proxyens 1 database. MOI leder svaret til bruker A.

Som respons på de mottatte svarene vil bruker A begynne å etablere en dataforbindelse for spillet mellom brukerne A, B og C. Dette beskrives imidlertid ikke nærmere her. Dataforbindelsen er en brukerplanforbindelse og dens ruting i MO'ene kan være en annen enn rutingen av et korresponderende kontrollplansignal. Det er også mulig at, selv om kontrollplansignal ene hele tiden går gjennom en proxy eller proxy er, brukerplandatasendingen ikke går gjennom en proxy eller proxyer dersom domenene er forbundet med hverandre.

I en annen utførelsesform av oppfinnelsen sendes alle invitasjonene til proxyen, uavhengig av hvorvidt de målrettes mot samme nettverk. Med andre ord, sjekkingen i punktet 4-2 utelates og også invitasjoner som er rettet til andre brukere av MOI, rutes til proxy 1. Fordelen med denne løsningen er at proxyen sørger for sikringsspørsmålene og domene/nummer-portabilitetsspørsmålene, slik at en operatør kan outsource disse oppgavene til proxy-tjenesteleverandøren og operatørens behov for bygging av en separat infrastruktur for disse problemene derfor unngås.

Dersom tunnelering brukes, kan det foreligge én tunnel mellom bruker A og proxy 1, en annen fra proxy 1 til bruker B og nok en fra proxy 1 til bruker C eller, alternativt, en tunnel fra proxy 1 til proxy 2, og nok en annen tunnel fra proxy 2 til bruker C. Er proxyen både et endepunkt og et startpunkt for en tunnel, så vil proxyen kunne overvåke trafikken og utføre de nødvendige funksjoner.

De foran beskrevne trinn, punkter, meldinger og relaterte funksjoner i fig. 3 og 4 er ikke gitt i en absolutt kronologisk orden, og noen av trinnene og/eller punktene og/eller operasjonene kan gjennomføres samtidig eller i en rekkefølge atskilt fra den her beskrevne. Andre funksjoner kan også utføres mellom trinnene/punktene eller i trinnene/punktene. Noen av trinnene/punktene eller en del av trinnene/punktene kan også utelates. Andre meldinger kan overføres og/eller andre trinn/punkter kan også gjennomføres mellom de viste og beskrevne. Meldingene er bare eksempler og kan også innbefatte annen informasjon. Videre kan meldingene atskille seg fra de foran nevnte operasjoner.

Selv om oppfinnelsen her er beskrevet under den forutsetningen at den eksterne proxyen utfører sjekkingen, vil fagpersoner forstå at et domene kan innbefatte en portåpning, eller en korresponderende nettverksnode, som kan gjennomføre noen eller samtlige av de foran beskrevne sjekkinger. Et eksempel er en implementering hvor portåpningen i domenet sjekker hvorvidt det foreligger en avtale, mens proxyen i det pålitelige nettverket tar seg av de andre sjekkingstrinnene.

System- og nettverksnodene som implementerer den inventive funksjonen, innbefatter ikke bare tidligere kjente midler, men også midler for sjekking av hvorvidt en avtale foreligger, samt fordelaktig midler for sjekking av hvorvidt senderen er den som han eller hun sier han/hun er. Mer nøyaktig, de innbefatter midler for implementering av en utførelsesform ifølge oppfinnelsen. Eksisterende systemer og nettverksnoder som innbefatter prosessorer og minne, kan brukes i funksjonene ifølge oppfinnelsen. Samtlige modifikasjoner og konfigurasjoner som er nødvendige for implementering av oppfinnelsen, kan gjennomføres som rutiner som kan implementeres som adderte eller oppdaterte software-rutiner, applikasjonskretser (ASIC) og/eller programmerbare kretser. Generelt innbefatter programprodukter rutiner, program, moduler, objekter, komponenter, segmenter, skjema, datastrukturer, etc. som gjennomfører spesielle oppgaver eller implementerer spesielle abstrakte datatyper, og som kan lagres i et datamaskinlesbart datalagringsmedium og kan nedlastes i en anordning, så som nettverksnoder.

For en fagperson vil det være klart at ettersom teknologien utvikles, kan det inventive konseptet implementeres på ulike måter innenfor rammen av patentkravene. Oppfinnelsen og dens utførelseseksempler er ikke begrenset av de foran beskrevne eksempler, men kan variere innenfor rammen av patentkravene.

Claims (8)

1. Nettverksnode (41) i et kommunikasjonssystem innbefattende minst ett senderdomene og ett eller flere mottakerdomener, hvor nettverksnoden er en sesjonsinitierende protokoll nettverkstilgangsport konfigurert for å holde sesjonsinformasjon sesjon-spesifikt, og nettverksnoden er anordnet for å gjenkjenne sesjonen hvortil trafikken relaterer seg, på basis av en indikasjon som er inneholdt i sesjonsrelatert trafikk; å sjekke hvorvidt meldingen er en sesjon-termineringsrelatert melding, som respons på mottak av en til en mottagers domene bestemte melding; dersom meldingen ikke er en sesjon-termineringsrelatert melding, å sjekke om meldingen er en sesjonsoppsettingsmelding relatert til etablering av en sesjon; dersom meldingen er en sesjonsoppsettingsmelding er nettverksnoden anordnet til å innhente i det minste navn (41-1)- og adresse (41-2)-informasjon om domener og informasjon om samvirkingsavtaler (41-3) mellom domener fra en database, den samvirkende avtalen inneholder domenespesifikke i det minste logiske navn på partnerdomener; å sjekke hvorvidt et adressepar omfattende det logiske navn til senderens domene og rutingadressen til senderens domene, adresseparret er navn- og adresseinformasjon innhentet fra databasen, er det samme som et adressepar dannet av det logiske navnet til senderens domene i sesjonsoppsettingsmelding og en adresse indikerer hvorfra nettverksnoden mottar sesjonsoppsettingsmeldingen; dersom adresseparrene ikke er de samme, sende en feil; dersom adresseparrene er de samme: å finne, ved å bruke nevnte informasjon som innhentet fra databasen, mottagerens domene på basis av mottagerens navn i sesjonsoppsettingsmeldingen; å sjekke, ved å benytte nevnte informasjon innhentet fra databasen, hvorvidt det foreligger en gyldig avtale mellom senderens domene og mottakerens domene; dersom det ikke foreligger en gyldig avtale mellom senderens domene og mottakerens domene å sende en feil; dersom det foreligger en gyldig avtale mellom senderens domene og mottakerens domene: å initiere sesjon-informasjon om sesjonen; å sammenlikne ved å benytte informasjon som er innhentet fra databasen, kapabilitetene til senderens domene med kapabilitetene til mottakerens domene, og dersom kontrollplankapabilitetene er forskjellige, å foreta de nødvendige endringene i sesjonsoppsettingsmeldingen og legge til sesjon-informasjonen, en indikasjon på at kontrollplanendringene er nødvendige eller en informasjon om de nødvendige kontrollplanendringene, å sjekke ved å benytte nevnte informasjon innhentet fra databasen, hvorvidt proxy moduset som er ønsket av senderens domene er et transparent proxy modus, dersom modusen ikke er transparent, å foreta de nødvendige endringer i toppteksten sesjonsoppsettingsmeldingen og legge til sesjon-informasjonen, en indikasjon eller en informasjon om at rygg-til-rygg-brukeragent skal benyttes, å sjekke ved å benytte nevnte informasjon innhentet fra databasen, hvorvidt brukerplankapabilitetene til senderens domene og brukerplankapabilitetene til mottakerens domene er forskjellige, og dersom brukerplankapabilitetene er forskjellige å legge til sesjon-informasjonen, en indikasjon på at brukerplanendringene er nødvendige eller en informasjon om de nødvendige brukerplanendringene, å fremlede sesjonsoppsettingsmeldingen til brukerens domeneadresse, idet nevnte informasjon er innhentet fra databasen; å initialisere, etter å fremlede sesjonsoppsettingsmeldingen, betalingsbelastningsinformasjon om sesjonen, dersom meldingen ikke er en sesjon-termineringsrelatert melding og ikke sesjonsoppsettingsmelding relatert til etablering av en sesjon, er meldingen annen sesjonsjonsrelatert informasjon, og nettverksnoden er anordnet for å utføre påkrevde belastningsrelaterte prosedyrer, dersom slike finnes, og de påkrevde endringer, dersom slike er nødvendige, og lede meldingene til adressen til mottakerens domene idet nevnte informasjon er innhentet fra databasen og dersom meldingen er en sesjon-termineringsrelatert melding, er nettverksnoden anordnet for å utføre de påkrevde endringene, dersom slike finnes, og fremlede meldingen til brukerens domeneadresse, idet nevnte informasjon er innhentet fra databasen, for å avslutte betaling og slette sesjonsinformasjon.

2. Nettverksnode (41) ifølge krav 1, hvori nettverksnoden (41) videre er anordnet som respons på en mottaker,som har endret et abonnement fra en første operatør til en andre operatør uten å endre det logiske navnet for i det minste å finne ut den andre operatørens domene.

3. Nettverksnode (41) ifølge et av de foregående krav, hvori nettverksnoden (41) videre er anordnet til både å være et tunnelendepunkt og et tunnel startpunkt for mellomdomenetunnelering.

4. Kommunikasjonssystem (1) innbefattende minst et senderdomene (3) og ett eller flere mottakerdomener (3', 3") en database(41-0) for å holde i det minste navn og adresseinformasjon på nevnte domener og informasjon på samvirkingsavtaler mellom nevnte domener, den samvirkende avtale inneholder domenespesielle i det minste logiske navn på partnerdomene til et domene, navn og adresseinformasjonen omfatter domenespesielle adressepar til et domenes logiske navn og rutingadressen til domenet, hvilken database er ekstern til nevnte domener et eller flere nettverk (4, 4') har i det minste kontrollerbar tilgang og omfatter én eller flere nettverksnoder i følge krav 1, 2 eller 3, det ene eller flere nettverk er ekstern til nevnte domener og kobler senderens domene og den ene eller flere av mottakerens domene hvori systemet (1) er anordnet for å rute i det minste signaler til og fra senderdomenet (3, 3') via en eller flere nettverksnoder (41) ved bruk av enhver av fremgangsmåtene som er angitt i krav 6 eller 7, nevnte en eller flere nettverksnoder (41) innbefatter den nevnte databasen eller er anordnet med tilgang til databasen.

5. Kommunikasjonssystem ifølge krav 4, hvori domenene (3, 3', 3") er basert på IMS og at nettverket (4, 4') er basert på GRX.

6. Fremgangsmåte for tilveiebringelse av mellomdomenekommunikasjon i kommunikasjonssystem omfattende i det minste en senders domene og en eller flere av mottakers domener, hvilken fremgangsmåte innbefatter: å motta (300) i en nettverksnode som er en sesjonsinitierende protokoll nettverkstilgangsport konfigurert for å holde sesjonsinformasjon sesjon-spesifikt, netteverksnoden og gjenkjenne en melding hvortil trafikken relaterer seg, en melding til en mottagers domene, på basis av en indikasjon som er inneholdt i sesjonsrelatert trafikk; å sjekke (301) ved nettverksnoden, hvorvidt meldingen er en sesjon-termineringsrelatert melding, dersom meldingen ikke er en sesjon-termineringsrelatert melding, å sjekke (302) ved nettverksnoden hvorvidt meldingen er en sesjonsoppsettingsmelding relatert til etablering av en sesjon; dersom meldingen er en sesjonsoppsettingsmelding omfatter fremgangsmåten videre innhente ved nettverksnoden, fra en database i det minste navn- og adresseinformasjon vedrørende domener og informasjon vedrørende samvirkingsavtaler mellom ulike domener, samvirkingsavtalen inneholder domenespesielle i det minste logiske navn til et domenes partnerdomer; å sjekke (303) ved nettverksnoden hvorvidt et adressepar omfattende det logiske navn til senderens domene og rutingadressen til senderens domene, adresseparret er navn- og adresseinformasjon innhentet fra databasen, er det samme som et adressepar dannet av det logiske navnet til senderens domene i sesjonsoppsettingsmeldingen og en adresse indikerer hvorfra sesjonsoppsettingsmeldingen var; dersom adresseparrene ikke er de samme (304), sende (317) en feil ved nettverksnoden; dersom adresseparrene er de samme (304): finne ut (305) ved nettverksnoden ved å bruke nevnte informasjon som innhentet fra databasen, mottagerens domene på basis av mottagerens navn i sesjonsoppsettingsmeldingen; å sjekke (309), ved å benytte nettverksnoden nevnte informasjon innhentet fra databasen, hvorvidt det foreligger en gyldig avtale mellom senderens domene og mottakerens domene; dersom det ikke foreligger en gyldig avtale (306 )mellom senderens domene og mottakerens domene å sende (317) en feil ved nettverksnoden; dersom det foreligger en gyldig avtale (306) mellom senderens domene og mottakerens domene: å initialisere (307) ved nettverksnodesesjoninformasjon for sesjonen; å sammenlikne (308) ved å benytte nevnte nettverksnodeinformasjon som er innhentet fra databasen, kapabilitetene til senderens domene med kapabilitetene til mottakerens domene, og dersom kontrollplankapabilitetene er forskjellige (309), å foreta (310) de nødvendige endringene i sesjonsoppsettingsmeldingen og legge til sesjon-informasjonen, en indikasjon på at kontrollplanendringene er nødvendige eller en informasjon om de nødvendige kontrollplanendringene; å sjekke (311) ved å benytte nevnte nettverksnodeinformasjon innhentet fra databasen, hvorvidt proxy moduset som ønsket ved senders domene er transparent proxy modus, og dersom modusen ikke er transparent, å foreta de nødvendige endringer i toppteksten til sesjonsoppsettingsmeldingen og legge til sesjon-informasjonen, en indikasjon eller en informasjon om at rygg-til-rygg-brukeragent skal benyttes, å sjekke (313) ved å benytte nevnte nettverksnodeinformasjon innhentet fra databasen, hvorvidt brukerplankapabilitetene til senderens domene og brukerplankapabilitetene i mottakerens domene er forskjellige, og dersom de er forskjellige, å legge (314) en indikasjon på at brukerplanendringene er nødvendige til sesjon-informasjonen eller en informasjon om de nødvendige brukerplanendringene, å fremlede (315) ved nettverksnoden, sesjonsoppsettingsmeldingen til brukerens domeneadresse, idet nevnte informasjon er innhentet fra databasen; å initialisere (316), etter å fremlede sesjonsoppsettingsmeldingen, betalingsbelastningsinformasjon om sesjonen, dersom meldingen ikke er en sesjontermineringsrelatert melding og ikke en sesjonsoppsettingsmelding relatert til etablering av en sesjon, er meldingen annen sesjonsjonsrelatert informasjon, og fremgangsmåten omfatter å utføre (318) ved nettverksnoden påkrevde betalingsrelaterte prosedyrer, dersom slike finnes, og de påkrevde endringer, dersom slike er nødvendige, å lede ved nettverksnoden meldingene til adressen til mottakerens domene idet nevnte informasjon er innhentet fra databasen og dersom meldingen er en sesjon-termineringsrelatert melding, omfatter fremgangsmåten å utføre (319) ved nettverksnoden de påkrevde endringene, dersom slike er nødvendige, og fremlede ved nettverksnoden meldingen til adressen til mottagerens domene, idet nevnte informasjon er innhentet fra databasen, avslutte ved nettverksnoden, betaling og slette ved nettverksnoden sesjonsinformasjon.

7. Fremgangsmåte ifølge krav 6, hvori denne omfattervidere å finne (305), som respons på en mottaker som har endret et abonnement fra en første operatør til en andre operatør uten å endre det logiske navnet for i det minste domenet til den andre operatøren

8. Datamaskinprogramprodukt innlagt i et datamaskinlesbart medium og innbefattende programinstruksjoner, idet gjennomføringen av programinstruksj onene bevirker at en anordning som inneholder datamaskinprogramproduktet til å utføre fremgangsmåten i følge krav 6 eller 7.