NO336307B1

NO336307B1 - Overføring av kommunikasjon mellom dataoverføringsnettverk

Info

Publication number: NO336307B1
Application number: NO20064249A
Authority: NO
Inventors: Jouni Korhonen; Tero Jalkanen; Jussi Laukkanen
Original assignee: Teliasonera Finland Oyj
Priority date: 2004-03-25
Filing date: 2006-09-20
Publication date: 2015-07-27
Also published as: US20080021980A1; DK1728370T3; WO2005094022A1; FI20045100L; EP1728370B1; NO20064249L; EP1728370A1; DE602005009807D1; ES2314637T3; FI20045100A0; FI116444B; ATE408949T1

Description

Overføring av kommunikasjon mellom dataoverføringsnettverk

Oppfinnelsen gjelder en framgangsmåte, et system og en navneserver for overføring av kommunikasjon fra et dataoverføringsnettverk til et mottakende dataoverføringsnettverk.

Bakgrunn

I et multioperatørmiljø, dvs. i et slikt datanettverksmiljøhvor en internettforbindelse kan skapes for en terminal via flere ulike servicetilbydere, må den overførende operatøren vite hvilket nettverkselement for mottakeren, overføringen skal utføres til. Derfor må den overførende operatøren kjenne alle de mottakende nettverkselementene til den mottakende operatøren for at overføringen skal bli vellykket.

I kjente fremgangsmåter har operatørene vedlikeholdt ulike statiske lister eller databaser, hvor nettverkselementene til den mottakende operatøren er lagret. Med andre ord har hver operatør lagret data på nettverkselementene brukt av hver mottakende operatør. F.eks. for dette formålet er GSM-sammenslutningen forsynt med en IR.21-database for å løse operatørnettveksling og operatørsamvirking, hvilken database har all operatørinformasjonen som er nødvendig for dannelse av koblinger.

I kommunikasjonen mellom nettverksoperatører kan et problem detekteres mellom et lukket DNS-hierarki (dvs. Domene-Navn-Service) i et samkjøringsnettverk og et DNS-hierarki til en offentlig internettforbindelse, hvilket problem gjelder bestemmelse av domenenavn. Domene-serveren brukes på kjent måte på internett for konvertering av domenenavn ("FQDN, Fully Qualified Domain Name", Fullt kvalifiserte Domenenavn) til nettverksa dresse r (slik som IP-adresser). I noen situasjoner, slik som f.eks. i drift av en IMS-serviceplattform (IP Multimedia subsystem), er det mulig at slike domenenavn må bestemmes, hvilke ikke skulle finnes i et offentlig DNS-system, men som imidlertid har domener bestemt av et offentlig DNS-system. Samtidig skal nevnte domenenavn ikke finnes i DNS-systemet til et lukket grensesnittnettverk. F.eks. i driften av et IMS-system kan det være nødvendig å bestemme, på basis av domenenavnet til en motpartsoperatør, nettverksadresser til et tilsvarende l-CSCF-elementforå rute en melding der. Den nødvendige nettverksadressen til l-CSCF kan ikke, imidlertid, forespørres fra DNS-servere i internett, siden de ikke kan lagre nettverksadresser til indre elementer av operatører for datasikkerhetsgrunner.

Fra US 20020004826 Al er det kjent en prosess for sikker levering av epost i et datamaskin-nettverksmiljø. En mottakende epostserver, f.eks. en hjemme-PC med en epostapplikasjon, mottar en dynamisk IP-adresse og en kode og registrerer dem i en dynamisk navneserver. Den leverende epostserveren, f.eks. en nettverksepostserver med en epostapplikasjon, benytter så denne koden for å løse ut den dynamiske IP-adressen for den mottakende epostserveren gjennom en prosess av ulike forespørsler fra en privat navneserver og den dynamiske navneserveren.

WO 03088625 Al beskriver en løsning for å tilveiebringe tilkoblingsbarhet mellom to ulike adresse-dataområder, et innside-dataområde og et utside-dataområde, ved etablering av koblinger gjennom en mellomliggende gateway. Hovedformålet med gatewayen er å rette trafikk fra utside-dataområdet til innside-dataområdet, men gatewayen fungerer også andre veien. Gatewayen vedlikeholder en adresse-pool og en korrekt levering er implementert ved erstatning av adresseportpar i pakkeheaderen med dataområde-spesifikk adresse gjennom n-gange-utskifting.

De statiske listene og konfigurasjonene brukt i kjente fremgangsmåter skaper ikke en sentralisert eller distribuert løsning for innsamling av data. Statiske lister og konfigurasjoner krever vedlikehold, siden det kan være flere hundre samarbeidende operatører og serve ra dresse r, hvilke kan endres eller servere kan legges til eller fjernes. På grunn av dette trengs det en forbedret fremgangsmåte og system for utføring av databasespørringer. I tillegg trengs en fremgangsmåte for å bestemme adressene til de indre nettverkselementene til det beskrevne IMS-systemet. Den foreliggende oppfinnelsen skaper en løsning for å møte de ovenfor beskrevne kravene.

Som nevnt ovenfor gjelder den foreliggende oppfinnelsen koblinger mellom dataoverføringsnettverk til operatører i et multioperatørmiljø, for eksempel et IMS-miljø. Formålet med oppfinnelsen er å gjøre det mulig for den overførende operatøren å forespørre den mottakende operatøren før dannelse av en kobling, om dataene til nettverkselementet som trengs for overføringen. Ved hjelp av oppfinnelsen mottar den overførende operatøren de nødvendige data fra serverne til den mottakende operatøren, som typisk kan være endrende. Som et eksempel kan nevnes en nettverksadresse til et multimediameldingssenter, som kreves for dannelse av en kobling til senteret og for overføring en multimediamelding via et grensesnittnettverk. Dersom det erønskelig kan den mottakende operatøren endre nettverksadressen til multimediameldings-senteret eller, f.eks. legge til et annet multimediameldingsenter. Derfor må det løses hvordan lasten distribueres og meldingene overføres mellom disse to sentrene.

Oppfinnelsen beskriver en fremgangsmåte, hvilken ved utnyttelse det er mulig, i stedet for direkte faste koblinger, å skape en dynamisk spørring til den private databasen til den mottakende operatøren, som gir et svar om egenskapene for det krevde nettverkselementet (slik som f.eks. nettverksadressen til l-CSCF til den mottakende operatøren). På denne måten trenger ikke den overførende operatøren å vedlikeholde og lagre disse egenskapene.

Med systemet i samsvar med den foreliggende oppfinnelsen kan de ovenfor beskrevne problemene med bestemmelse av domenenavn adresseres på en slik måte at hver operatør bare kjenner adressen til en privat navneserver til en nettvekslingsoperatør eller samvirkende operatør, hvilken private navneserver er anordnet til å bestemme og lagre deønskede domenenavnene og nettverksadressene til de indre elementene til operatøren. Denne typen fremgangsmåte reduserer mengden av statiske dannede data mellom nettvekslingsoperatører (siden operatørene ikke trenger å vite adressene til de ulike serverne til nettvekslingsoperatøren, men bare adressen til nevnte private navneserver).

For å beskrive det mer presist, er den foreliggende fremgangsmåten hovedsakeligkarakterisertved at det som er angitt i de selvstendige kravene. Noen utførelsesformer er beskrevet i de avhengige kravene.

Med den foreliggende oppfinnelsen trengs ingen statiske lister, hvilket reduserer manuelt arbeid. Vanligvis endrer operatørene sine egne data, for eksempel kan en nettverksadresse endres, hvilket resulterer i at hver samvirkende operatør manuelt må oppdatere deres egen liste eller på annen måte endre adressene for kommunikasjon. Automatisering reduserer mulighetene for menneskelige feil i f.eks. oppdatering av nettverksadresser.

Mange problemer er løst ved å tilby den overførende operatøren adressen til bare en intern database for mottakeren. Den overførende operatøren kan på denne måten direkte spørre fra denne databasen, f.eks. alle nettverksadressene til multimediameldingssentre, i hvilket tilfelle mottakeren fritt kan variere adressen til sitt eget senter uten at overføreren trenger å oppdatere denne dataen. Informasjonen som den overførende operatøren trenger er bare adressen til den private databasen til mottakeren, all annen informasjon kan deretter direkte spørres fra denne databasen.

I tillegg, med den foreliggende oppfinnelsen er bruken av offentlige domenenavn mulig i et privat grensesnittnettverk. Oppfinnelsen er nyttig, spesielt i et GRX-nettverk, hvor DNS-tjenesten til det offentlige internett ikke kan benyttes siden GRX-adressene må forbli i GRX-nettverket og de kan ikke brukes utenfor nevnte nettverk.

Eksempel

I det følgende er oppfinnelsen mer detaljert beskrevet med henvisning til de vedlagte tegningene, hvor: Fig. 1 viser et eksempel av et datanettverkssystem, hvilket benytter domenenavnserveren i samsvar med oppfinnelsen. Fig.l viser hovedprinsippet av løsningen i samsvar med oppfinnelsen. Systemet i samsvar med oppfinnelsen omfatter operatørnettverk A, B og nettverkselementene omfattet av dem, hvilke er kjent som f.eks. domenenavnservere. Nettverkselementene omfattet av operatørnettverkene A, B avhenger av nettverkstypen det er snakk om og er kjent som slike. F.eks. i Fig. 1 er operatør- nettverkene A, B IMS-nettverk, i hvilket tilfelle de omfatter elementer kjent for IMS-nettverk, slik som minst l-CSCF og S-CSCF som implementerer ringe-/sesjon-kontrollfunksjonen. | eksempelet i Fig. 1 fungerer det viste l-CSCF ("Interrogating-CSCF", spørrende-CSCF) elementet I som et såkalt kontaktpunkt og danner en aksess til nevnte operatørnettverk B. Alle sesjonene adressert til en abonnent av operatørnettverket B er først mottatt i nevnte element I. Kontrollelementet S vist på siden til operatørnettverk A, slik som et S-CSCF-element, utfører sesjonskontrolltjenester for terminalen. Brukerregistrering og identifikasjon av registrerte brukere finner sted på en kjent måte i dette kontrollelementet S, som også kan håndtere sesjonskontroll på vegne av de registrerte brukerne. For forenkling har andre elementer som tilhører nettverket blitt utelatt av Fig. 1, siden de opererer i fremgangsmåten til oppfinnelsen på en kjent måte, slik som de er kjent og er nødvendigvis ikke avhengige av arrangementet i samsvar med oppfinnelsen. I tillegg noteres det at operatørnettverkene A, B kan omfatte slike elementer, som er vist i forbindelse med bare et operatørnettverk A eller B.

I tillegg kan operatørnettverket A omfatte en lokal navneserver D ("DNS, Domain Name Server", DomeneNavnServer), hvilken omfatteren resolver, hvilken konverterer f.eks. fullt kvalifiserte domenenavn (FDQN) til IP-adresser på en kjent måte for dette. I tillegg er det mulig å anordne en kobling 7 for operatørnettverket til en operatørdatabase DB, slik som, f.eks. en IR.21 type operatørdatabase. I tillegg er det i samsvar med foreliggende oppfinnelsen anordnet en privat operatørnavneserver PD i operatørnettverket B, hvilken server lagrer nettverksadressene til de indre elementene til operatørnettverket og annen nødvendig informasjon for å danne en kobling.

Driften av det ovenfor beskrevne systemet er ytterligere beskrevet med henvisning til Fig. 1. En abonnent ("subscriber") av operatørnettverket A, kalt A-abonnent, gjør en tilkobling (1), f.eks. ved å sende "SIP INVITE"-melding til en abonnent ("subscriber") av operatørnettverket B, kalt B-abonnent (f.eks. b.subscriber@operatorB.com). Begge nevnte abonnenter er IMS-abonnenter i dette eksempelet. A-abonnenten bruker den offentlige nettverksadressen til B-abonnenten (slik som IMS-adresse, offentlig SIP URL), hvor området til operatørnettverket B (operatorB.com) er et offentlig registrert domenenavn på internett. Kontrollelementet S til operatørnettverket A, her S-CSCF-elementet, utfører styring av meldingen mot operatørnettverk B.

Kontrollelementet S til operatørnettverket A utfører en spørring (2) til en lokal navneserver D. Denne lokale navneserveren D omfatter data om nettverksadressene til den private operatør-navneserveren PD til operatørnettverket B. Den lokale navneserveren D kan ha søkt denønskete adressedataen, f.eks. fra en operatørdatabase DB.

Den lokal navneserveren (3) spør den private navneserveren PD til operatørnettverket B om adressen til kontaktpunktet til nevnte nettverk B, slik som l-CSCF-elementet. Etter mottak av denne overfører (4) den lokale domenenavnserveren D til operatørnettverket A dataen til kontroll elementet S, hvilket videre overfører (5) kommunikasjonen til kontaktpunktet I for operatør-nettverket B. Dette kontaktpunktet I opererer som aksess til operatørnettverket B og på denne måten ruter meldingen videre til B-abonnenten.

Med systemet i samsvar med den beskrevne oppfinnelsen trenger nødvendigvis ikke den lokale navneserveren D for operatørnettverket A å omfatte mer enn en nettverksadresse for hver operatør som de kommunisere med. Den private operatørnavneserveren PD i samsvar med oppfinnelsen omfatter nettverksadressene til serverne til nevnte nettverksoperatør, i hvilket tilfelle operatørnettverket A bare må vite adressen til nevnte private operatørnavneserver PD. Denne private operatørnavneserveren PD, er i samsvar med oppfinnelsen lagt til operatør-nettverket og den hører ikke direkte til grensesnittnettverket (slik som GRX) eller det offentlige internett. Den private operatørnavneserveren PD i samsvar med oppfinnelsen kan være basert på en DNS-løsning eller være f.eks. en LDAP-database (Lightweight Directory Access Protocol), som er en registertjeneste som er kjent i seg selv.

Det er også klart at systemet i samsvar med oppfinnelsen likedan kan implementeres i noen andre typer nettverksmiljø enn nevnte IMS-system. Følgelig må også abonnenter av nettverksmiljøet det er snakk om og også de indre nettverkselementene av slike dataoverføringsnettverk kan være karakteristiske for dette nettverket. Det er innlysende at ideen av oppfinnelsen kan benyttes i forbindelse med ulike nettverkselementer.

Oppfinnelsen er beskrevet ovenfor i samsvar med en utføreIsesform. Det skal imidlertid noteres at løsningen i samsvar med oppfinnelsen også likedan kan benyttes i andre miljø. Følgelig er oppfinnelsen ikke begrenset til utførelsesformen beskrevet ovenfor, men trekkene av oppfinnelsen kan variere innenfor omfanget av de vedlagte kravene.

Claims

1. Fremgangsmåte for bestemmelse av et aksesspunkt (I) i dataoverføring mellom et første operatørnettverk (A) og minst et andre operatørnettverk (B), det første operatørnettverket (A) omfatter en første navneserver (D) og det andre operatørnettverket (B) omfatter et aksesspunkt (I) for mottak av kommunikasjon fra et annet operatørnettverk, hvilken fremgangsmåte omfatter forespørsel (2) om en nettverksadresse til aksesspunktet til det andre operatørnettverket (B) fra nevnte første navneserver (D) som respons på deteksjon av en tilkoblingsetableringsmelding fra det første operatørnettverket (A) til det andre operatørnettverket (B),karakterisert ved overføring (3) av forespørselen fra nevnte første navneserver (D) til en andre navneserver (PD) omfattet av det andre operatørnettverket (B), hvor den andre navneserveren (PD) omfatter nettverksadresser til aksesspunkter for det andre operatørnettverket (B); bestemmelse av en nettverksadresse til det forespurte aksesspunktet i den andre navneserveren (PD); overføring (4) av et svar på responsen omfattende bare nettverksadressen til det forespurte aksesspunktet til et kontrollelement (S) til det første operatørnettverket (A); og oppsett (5) av en tilkobling fra kontrollelementet (S) til det første operatørnettverket (A) for aksesspunktet (I) til det andre operatørnettverket (B) på grunnlag av nettverksadressen til aksesspunktet (I), hvor aksesspunktet (I) til det andre operatørnettverket (B) ruter meldinger med opphav fra det første operatørnettverket til tilsiktet nettverksadresse i det andre nettverket (B).

2. Fremgangsmåte i samsvar med patentkrav 1,karakterisert vedat nevnte andre navneserver (PD) er en domeneserver omfattende, på en sentralisert måte, nettverksadresser til andre nettverkselementer av nevnte andre operatørnettverk (B).

3. Fremgangsmåte i samsvar med patentkrav 1 eller 2,karakterisert vedat fremgangsmåten omfatter at det i den nevnte første navneserveren (D) opprettholdes nettverksadressedata for minst en andre navneserver for hvert operatørnettverk, som det første operatørnettverket (A) kommuniserer med.

4. Telekommunikasjonssystem omfattende: et første operatørnettverk (A) og minst et andre operatørnettverk (B), det første operatørnettverket (A) omfatter en første navneserver (D) og et kontrollelement (S) for implementering av ringe-/sesjon-kontrollfunksjon, og det andre operatørnettverket (B) omfatter et aksesspunkt (I) for å motta kommunikasjon fra andre operatørnettverk, kontrollelementet (S) er konfigurert for å forespørre (2) om en nettverksadresse på det andre operatørnettverkets (B) aksesspunkt (I) fra den nevnte første navneserveren (D) som reaksjon på deteksjon av en tilkoblingsetableringsmelding fra det første operatørnettverket (A) til det andre operatørnettverket (B),karakterisert vedat nevnte første navneserver (D) er konfigurert for å overføre (3) forespørselen til en andre navneserver (PD) omfattet av det andre operatørnettverket (B), hvor den andre navneserveren (PD) omfatter nettverksadresser til aksesspunkter for det andre operatørnettverket (B); den andre navneserveren (PD) er konfigurert til å bestemme nettverksadressen til det forespurte aksesspunktet og overføre (4) et svar på responsen omfattende bare nettverksadressen til det forespurte aksesspunktet til kontrollelementet (S) til det første operatørnettverket (A); kontrollelementet (S) til det første operatørnettverket (A) er konfigurert for å sette opp (5) en tilkobling til aksesspunktet (I) til det andre operatørnettverket (B) på grunnlag av nettverksadressen til aksesspunktet (I); aksesspunktet (I) er konfigurert for å håndtere rutingen av meldinger med opphav fra det første operatørnettverket til tiltenkt nettverksadresse i det andre operatørnettverket (B).

5. System i samsvar med patentkrav 4,karakterisert vedat den andre navneserveren (PD) er en domenenavnserver omfattende, på sentralisert måte, nettverksadresser til andre nettverkselementer i nevnte andre operatørnettverk (B).

6. System i samsvar med patentkrav 4 eller 5,karakterisert vedat den andre navneserveren er en LDAP-database.

7. System i samsvar med patentkrav 4 eller 5 eller 6,karakterisert vedat minst ett av operatørnettverkene er et IMS-dataoverføringsnettverk og et grensesnittnettverk mellom operatørnettverkene er et GRX-nettverk.

8. System i samsvar med patentkrav 7,karakterisert vedat aksesspunktet (I) til det andre operatørnettverket (B) et l-CSCF-kontaktpunkt.

9. Navneserver (PD) for lagring av navn, hvilken navneserver (PD) er anordnet i et operatørnettverk, hvori navneserveren er en privat navneserver omfattende nettverksadresser til aksesspunktene (I) til operatørnettverket (B), hvilke aksesspunkter (I) er innrettet for å motta kommunikasjon fra et andre operatørnettverk (A) omfattende et kontrollelement (S) som implementerer en ringe-/sesjon-kontrollfunksjon og håndtere rutingen av meldinger med opphav fra andre operatørnettverk (A) til tiltenkt nettverksadresse i operatørnettverket (B),karakterisertved at navneserveren er konfigurert for å: - motta en forespørsel fra en navneserver (D) til det andre operatørnettverket (A) angående en nettverksadresse til aksesspunktet til operatørnettverket (B); - bestemme, på grunnlag av forespørselen, nettverksadressen til det forespurte aksesspunktet (I); og - returnere bare nevnte nettverksadresse for aksesspunkt (I) til kontrollelementet (S) for det andre operatørnettverket (A).

10. Navneserver i samsvar med patentkrav 9,karakterisert vedat navneserveren er en LDAP-database.