DE60214871T2

DE60214871T2 - Verfahren und vorrichtung zum auflösen einer geräteidentifikation

Info

Publication number: DE60214871T2
Application number: DE60214871T
Authority: DE
Inventors: Victor Ferraro Esparza; Miguel Cobo; Robert Khello; Isabel Plata Andres
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2001-10-29
Filing date: 2002-10-11
Publication date: 2007-09-06
Anticipated expiration: 2022-10-12
Also published as: CN101951580B; WO2003039106A3; US20030081754A1; EP1440598B1; EP1440598A2; WO2003039106A2; CN101951580A; ES2314837T3; ATE411722T1; CN1579108A; EP1725066A3; US6839421B2; EP1725066A2; AU2002339805A1; DE60229453D1; EP1725066B1; CA2464065A1; DE60214871D1; CA2464065C; ATE340490T1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf die Lieferung von internetbasierten, dialogorientierten Typen von Anwendungen, z.B., der Anwendung Sprache über IP, und Typen von Multimediaanwendungen, z.B., Streaming und Multimediameldungsservices, ohne dass der Anwender spezielle Internetadressen von entfernten Vorrichtungen oder Funktionseinheiten kennen muss, mit denen ein Anwender kommunizieren möchte, indem er diese Typen von Anwendungen verwendet.
HINTERGRUND UND ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung stützt sich auf zwei unterschiedliche Bereiche von Kommunikation: auf eine Kommunikation, die auf Datenpaketen basiert, in dem sie Internetadressen verwendet und eine Kommunikation, die auf Verbindungen basiert, in der sich eine Telefon-(oder ein andere Kennung) Nummernportabilität entwickelt hat, um einem Teilnehmer zu ermöglichen eine Teilnehmertelefonnummer oder andere Kommunikationskennungen geografisch und/oder zwischen Serviceanbietern zu "portieren". Nachrichtenvermittlung auf der Basis von Paketen wird zuerst adressiert.
Wenn mit einem Netzwerk verbundene Computer kommunizieren, werden Internetprotokoll-(IP)Adressen verwendet, um diese Computer zu identifizieren, und sie entsprechen ganzen Zahlen mit 32 Bit für die IP Version 4, oder mit 128 Bit für die IP Version 6. Obwohl solche IP Adressen eine geeignete, kompakte Repräsentation zur Spezifizierung der Quelle und des Zieles liefert, für Pakete, die quer durch ein Internet geschickt werden, bevorzugen es Humananwender, Computern aussprechbare, leicht zu merkende Namen zuzuordnen. Als ein Ergebnis wurde das Domainnamensystem (DNS)entwickelt, um ein Schema zur Zuordnung sinnvoller Namen höchster Ebene für einen großen Satz von Computern zu liefern, und um einen Mechanismus zur Verfügung zu stellen, der Computernamen höchster Ebene auf IP Adressen abbildet.
Gewöhnlich kann das Domainnamensystem als eine verteilte, gemeinsame Datenbank mit Domainnamen und entsprechenden IP Adressen betrachtet werden. Domainserver, üblicher DNS Server genannt, enthalten diese Datenbanken. Ein Beispiel eines gewöhnlichen DNS Servers ist eine UNIX Maschine, auf der eine Version der Berkeley Internet Benennungssoftware (BIND) läuft. Ein Domainname könnte aus einer Sequenz von Unternamen, getrennt durch ein Begrenzungszeichen – dem Punkt, bestehen. Individuelle Teile des Namens könnten Orte oder Gruppen repräsentieren, jedoch bezieht sich das Domainnamensystem einfach auf jeden Teil eines Namens als ein Kennzeichen. Ein Beispiel eines solchen Domainnamens ist eine Internetadresse wie http://www.ericsson.se oder eine Emailadresse wie narre@ericsson.com. Das Kennzeichen nach dem Punkt ist der Ortsname, der von einer zentralen Instanz autorisiert wird. Die/das Kennzeichen vor dem Punkt sind (ist) Teil des Namens der von dem speziellen Ort kontrolliert wird. Hier ist die höchste Ebene der Internetdomain, die dem Ort entspricht, der Landescode "se" für Schweden, und für die Emailadresse ist die höchste Ebene der Domain "com".
Domainserver sind konzeptionell in einer Baumstruktur angeordnet, die einer Namenshierarchie entspricht. Die Baumwurzel ist ein Server, der die Domains der höchsten Ebene (oder Ränge) erkennt und weiß, welcher Server die jeweilige Domain zuordnet. Angesichts eines zuzuordnenden Namens, kann die Wurzel den korrekten Server für diesen Namen auswählen. Auf der nächsten Ebene oder dem nächsten Rang liefert jeder eines Satzes von Namenservern Zuordnungsantworten für eine Domain der höchsten Ebene, z.B., se. Ein Server in dieser Domain weiß, welche Server jede der Unterdomains unterhalb ihrer Domain zuordnen kann. In der dritten Ebene des Baumes liefern Namenserver Antworten für Unterdomains, z.B., ericsson unter se. Der konzeptionelle Baum setzt sich mit einem Server auf jeder Ebene fort, für die eine Unterdomain definiert wurde.
Verbindungen im konzeptionellen Baum zeigen jedoch keine physikalischen Netzwerkverbindungen an. Stattdessen zeigen sie auf andere Namenserver. Konzeptionell schreitet die Domainnamenzuordnung von oben nach unten fort, beginnend mit dem "Wurzel" Namenserver und fortschreitend zu Servern, die an den Zweigen oder Blättern des Baumes lokalisiert sind. Es gibt zwei Wege das Domainbenennungssystem zu verwenden:

(1) durch das Kontaktieren des Namenservers einen nach dem anderen, oder
(2) durch eine Anfrage an das Namenserversystem, die vollständige Zuordnung durchzuführen.

In beiden Fällen führt eine Clientsoftware eine Domainnamenabfrage durch, die den zuzuordnenden Namen enthält, eine Angebe der Klasse des Namens, den Typ der gewünschten Antwort und einen Code, der spezifiziert, ob der Namenserver den Namen vollständig übersetzen soll. Er sendet die Anfrage zur Zuordnung an einen DNS Server.
Wenn ein DNS Server eine Anfrage erhält, prüft er, ob sich der Name in der Unterdomain liegt, für die er autorisiert ist. Wenn ja, übersetzt er den Namen in eine Adresse laut seiner Datenbank und hängt eine Antwort an die Anfrage, bevor er sie an den Klienten zurücksendet. Wenn der DNS Server den Namen nicht vollständig zuordnen kann, prüft er, welchen Interaktionstyp der Klient spezifiziert hat. Wenn der Klient eine vollständige Zuordnung gefordert hat, (d.h., rekursive Zuordnung), kontaktiert der Server einen DNS Server, der den Namen zuordnen kann und sendet die Antwort an den Klienten zurück. Wenn der Klient nicht rekursive Zuordnung gefordert hat, (d.h., iterative Zuordnung), kann der Namenserver keine Antwort liefern. Stattdessen erzeugt er eine Antwort, die den Namenserver spezifiziert, den der Klient als Nächstes kontaktieren soll, um den Namen zuzuordnen.
Das dynamische Hostkonfigurationsprotokoll (DHCP) liefert automatisierte Prozeduren, mit denen ein Masterknoten eine IP Adresse einem Server im Internet zuordnen kann, z.B., einem DNS Server. Gewöhnlich können IP Adressen an eine Funktionseinheit entweder statisch vergeben werden, d.h., eine feste IP Adresse, oder dynamisch, d.h., nur solange wie die Funktionseinheit aktiv mit dem Internet aktiv verbunden ist. Benutzervorrichtungen, wie eine Computereinheit oder eine mobile Vorrichtung in einem Paketfunksystem (z.B., GPRS) sind normal vergebene, temporäre Internetadressen. Obwohl konzeptionell ziemlich einfach, kann die Zuordnung von IP Adressen unter Verwendung von DNS in der Praxis komplex und zeitraubend sein.
Das Internet und das Domainbenennungssystem wurden entworfen, um Paketverkehr zum Ermöglichen von Kommunikation von Computern zu tragen. Andere Netzwerktypen wurden entworfen, um Leitungsvermittlungsverkehr zu tragen. Ein Beispiel eines Leitungsvermittlungsnetzwerks ist ein Legacynetzwerk, das Kontrollsignalisierung anwendet, unter Verwendung des gut eingeführten Signalisierungssystem Nu. 7 (SS-7), wie von verschiedenen Standardinstitutionen definiert. Die Leitung eines Telefonanrufs durch ein Legacynetzwerk verwendet einen strukturierten Telefonnummernplan. Solche strukturierten Regeln werden von der internationalen Telekommunikationsunion (ITU) in der E-Serienempfehlung E.164 definiert. E.164 Nummerierung ist in allen Domains von Telekommunikationssystemen anwendbar, verdrahtete und drahtlose Systeme einschließend. Jeder physikalischer Knoten, lokale Vermittlungsstelle genannt, wird einer oder mehreren einzigartigen Vermittlungsnummerngruppen zugeordnet. Die Telefonnummer eines Teilnehmer enthält typischer Weise sowohl eine Vermittlungsnummerngruppe (typischer Weise in Blöcken von 10000 Nummern) für die Vermittlungsstelle, mit der der Abonnent verbunden ist, als auch eine Nummer in der Gruppe, die für den Teilnehmer spezifisch ist.
Z.B. hat ein Abonnent mit einer Telefonnummer 881-1657, der mit einer lokalen Vermittlungsstelle verbunden ist, die eine Vermittlungsnummerngruppe 881 besitzt, innerhalb dieser Gruppe eine Teilnehmernummer 1657. Daher ist die Telefonnummer in dem Sinne geografisch, dass es eine definierte Beziehung zwischen der Telefonnummer und einem geografischen Bereich gibt, der von der Vermittlungsstelle bedient wird, mit der der Abonnent verbunden ist. Es gibt auch nicht geografische Telefonnummern, in denen keine geografische Beziehung existiert. Z.B. werden gebührenfreie Nummern, virtuelle Privatnetzwerksnummern und universale Zugriffsnummern typischer Weise von intelligenten Netzwerken (IN) bedient. IN Services werden von einem Servicekontrollpunkt (SCP) kontrolliert und ausgeführt, der Daten verwendet, die in einer Servicedatenfunktion (SDF) gespeichert sind.
Wenn ein Abonnent physikalisch umzieht, oder den Serviceanbieter wechselt, ist es für den Teilnehmer wünschenswert, nicht seine Telefonnummer ändern zu müssen. Entsprechend erlauben Nummernportabilitätsservices einem Teilnehmer seine Telefonnummer zu "portieren" oder dorthin zu transferieren, wohin der Abonnent physikalisch umzieht, oder zu einem anderen Serviceanbieter. In ähnlicher Weise wird eine mobile Teilnehmer- E-164 Identifikationsnummer, wie die integrierte digitale Servicenetzwerknummer des mobilen Teilnehmers (MSISDN), verwendet, um den mobilen Teilnehmer zu identifizieren, die Abonnierung des Teilnehmer und den aktuellen Ort des Teilnehmer. Wenn ein mobiler Abonnent den Serviceanbieter wechselt, wird eine mobile Teilnehmernummernportabilitätsdatenbank aktualisiert, um die Änderung zu reflektieren. Das öffentlich zugängliche U.S. Patent Nu. 6,064,887 beschreibt ein Beispiel einer mobilen Teilnehmernummernportabilität in einem Telekommunikationsnetzwerk, das einem mobilen Teilnehmer erlaubt, seine MSISDN zu behalten, wenn er Serviceanbieter wechselt.
Neuerlich fanden in der Internetkonstruktionsarbeitsgruppe (IETF) und anderen Foren Diskussionen über die Möglichkeit statt, einem Benutzer zu erlauben, eine Telefonnummer, hier im Folgenden "E-164 Nummer" genannt, in eine Computervorrichtung mit dem Ziel einzugeben, die E.164 Nummer als eine DNS Anfrage zu behandeln, für die eine entsprechende Internetadresse vom DNS geliefert wird. Dieser spezielle Type von DNS Anfrage wird ENUM Anfrage genannt. Eine neuerliche IETF Anfrage zur Kommentierung (RFC) 2916 mit dem Titel "E.164 Nummer und DNS", legt die mögliche Nutzung des Domainbenennungssystem zur Speicherung von E.164 Telephonienummern dar. Der DNS könnte dann benutzt werden, um verfügbare Services, die mit einer E.164 Nummer verbunden sind, zu identifizieren.
Das U.S. Patent Nu. 6,021,126 veröffentlicht einen Vermittlungsknoten, der Portabilitätsnummerninformation von einem Nummernportabilitätsdatenbankknoten im Leitungsvermittlungsnetz anfordert. Dasselbe Dokument schlägt alternativ vor, dass der Vermittlungsknoten die Portabilitätsnummerninformation von einem DNS Server in einem Paketvermittlungsnetz über einen Internetgatewayrouter anfordert.
Ein Problem bei der Verwendung des Domainbenennungssystems zur Zuordnung von E.164 Telefonnummern zu anderen entsprechenden Adressen, wie Internetadressen, besteht darin, dass ein Leitungsknoten, wie ein Gateway MSC, der einen Anruf mit einer gerufenen Partei empfängt, nicht weiß, ob die E.164 Telefonnummer der gerufenen Partei eine portierte Nummer ist. Wenn die E.164 Nummer zu einem anderen Netzwerkbetreiber übertragen wurde, besitzt der Leitungsknoten nicht genügend Information um den Anruf richtig weiterzuleiten. Eine weitere Einschränkung ist, dass ein MSC (oder GMSC) nicht "dieselbe Sprache spricht" wie das DNS System.
Die vorliegende Erfindung überwindet diese Probleme durch die Lieferung einer effizienten Schnittstelle und Serviceaustausch zwischen einem Leitungsvermittlungs-Nachrichtenverkehrsnetz und einem Domainbenennungssystem in einem Paketvermittlungs-Nachrichtenverkehrsnetz.
Die Erfindung bezieht sich auf ein Verfahren zur Lieferung von Kommunikationsservices an einen Teilnehmer über eine Nummernportabilitätsdatenbank in einem Leitungsvermittlungsnetz, wie in Anspruch 1 definiert.
Sie bezieht sich auch auf einen Nummernportabilitätsknoten, wie in den Ansprüchen 24 und 29 definiert. Darüber hinaus bezieht sie sich auf ein entsprechendes computerlesbares Produkt, wie in Anspruch 41 definiert.
Ein Knoten in dem Leitungsvermittlungs-Nachrichtenverkehrsnetz empfängt von einer ersten Funktionseinheit eine Anforderung für einen ersten Service, der eine zweiten Funktionseinheit, assoziiert mit einer zweiten Funktionseinheitsbezeichnung einbezieht. Eine Meldung wird vom Leitungsvermittlungsnetzwerk-Nummernportabilitätsdatenbank-Knoten an einen DNS Server im Paketvermittlungsnetz gesendet, einen zweiten Service anfordernd, der sich auf die zweite Funktionseinheitsbezeichnung bezieht. Das Resultat des zweiten Service aus dem DNS Server wird zum Liefern des ersten Service verwendet. Z.B., könnte der erste Service eine elektrische Kommunikation zwischen der ersten und zweiten Funktionseinheit sein, und der zweite Service könnte die Zuordnung der zweiten Funktionseinheitsbezeichnung sein. Eine solche Zuordnung könnte eine Zuordnung einer Nummer, eines Namens, oder einer Adresse sein, die mit der zweiten Funktionseinheit assoziiert ist. Andere exemplarische zweite Services enthalten einen Vorauszahlungsservice, in dem der DNS Server verwendet wird, vorausbezahlte Abrechnungsinformation für die erste oder zweite Funktionseinheit abzurufen. Alternativ könnte der DNS Server verwendet werden, um auf andere Typen von Servern (wie einen Wetterserviceserver oder einen Nachrichtenserver) zuzugreifen, die mit einer speziellen Funktionseinheitsbezeichnung assoziiert sind. Ein Leitungsvermittlungsleitknoten im Leitungsvermittlungsnetz sendet eine Leitanforderungsmeldung mit der zweiten Funktionseinheitsbezeichnung an einen Nummernportabilitätsdatenbank-(NPDB)Knoten. Die Meldung enthält einen Hinweis, dass eine DNS Zuordnung für die zweite Funktionseinheitsbezeichnung benötigt wird. Der NPDB Knoten fordert von einem DNS Server eine Zuordnung der zweiten Funktionseinheitsbezeichnung an, der ein Zuordnungsergebnis zurücksendet, das anzeigt, ob die zweite Funktionseinheitsbezeichnung zwischen Netzwerkbetreibern übertragen ("portiert") wurde. Falls keine Übertragung existiert, d.h., keine Nummernportierung, wird die elektronische Kommunikation auf eine Weise geleitet, die keine Abrechnungsnummernportabilität berücksichtigt. Andererseits, wenn die zweite Funktionseinheitsbezeichnung portiert wurde, liefert der DNS Server den Leitungsknoten im Leitungsvermittlungs-Nachrichtenverkehrsnetz mit einem Zuordnungsergebnis, das das Heimatnetzwerk der zweiten Funktionseinheit identifiziert. Die vom DNS Service gelieferte Zuordnung könnte eine Zuordnung einer Nummer, eines Namens, oder einer Adresse enthalten, die mit der zweiten Funktionseinheit assoziiert ist.
In einer exemplarischen Anwendung, in der das Leitungsvermittlungsnetz ein mobiles Netzwerk, und das Paketvermittlungsnetz das Internet ist, empfängt im mobilen Netzwerk ein Gatewaymobilschaltzentrum (GMSC) eine Anrufaufbaumeldung, gedacht für eine gerufene Funktionseinheit, die eine gerufene Funktionseinheitstelefonnummer enthält. Das GMSC fragt einen Nummernportabilitäts-Datenbankknoten im Leitungsvermittlungsnetz unter Verwendung der gerufenen Funktionseinheitstelefonnummer ab, dabei anzeigend, dass die DNS Zuordnung benötigt wird. Der Nummernportabilitäts-Datenbankknoten generiert eine ENUM Abfrage an den DNS Server unter Verwendung der gerufenen Funktionseinheitstelefonnummer. Der DNS Server führt die DNS Zuordnung aus und sendet einen NAPTR Datenblock mit einer Internetadresse (URL)zurück, die der gerufenen Funktionseinheitstelefonnummer entspricht.
Der Inhalt des NAPTR Datenblocks variiert abhängig davon, ob die gerufene Funktionseinheitstelefonnummer zwischen Netzwerkbetreibern portiert worden ist. Wenn die Nummer portiert wurde, liefert die DNS Zuordnung einem Präfix für die gerufene Funktionseinheitstelefonnummer. Entsprechend wird eine Rufaufbaumeldung an eine Standortverzeichnis-(HLR)Datenbank gesendet, die im Heimatnetz der gerufenen Funktionseinheit lokalisiert ist. Das HLR fordert von einer Aufenthaltsverzeichnis-(VLR) Datenbank, die aktuell die gerufene Partei bedient, eine Wegesuchnummer. Sobald sie diese Wegesuchnummer erhalten hat, wird sie dem GSSC zur Verfügung gestellt. Das GSM hat dann genügend Information, um den Anruf an die gerufene Funktionseinheit weiterzuleiten. Exemplarische Signalisierungsimplementierungen werden in größerem Detail weiter unten beschrieben, das SS7 Signalisierungsprotokoll zu verschiedenen Typen von existierenden Nummernportabilitätsdatenbanken verwendend.
Eine spezielle Ausführung der vorliegenden Erfindung adressiert ein Problem, das für mobile Nachrichtenverkehrsnetze speziell ist. In mobilen Nachrichtenverkehrsnetzen werden Teilnehmerservices und andere Information, die die Subskription eines Teilnehmer betreffen, in der Datenbank des Heimatbetreibernetzes gespeichert, d.h., im Standortverzeichnis (HLR), das auf den internationalen Mobilteilnehmeridentitäts-(IMSI)Nummern der Teilnehmer basiert. Andererseits verwendet die Wegesuchinformation, die in den Rufaufbauprozeduren verwendet wird, integrierte digitale Servicenetzwerknummern der mobilen Teilnehmer (MSISDN). Daher besteht eine Inkompatibilität des mobilen Identifizierungsmerkmals, wenn ein Knoten wie der GMSC einen Ruf weiterleiten muss, der auf der MSISDN der gerufenen Funktionseinheit basiert, jedoch bestimmte Information bezüglich der gerufenen Funktionseinheit benötigt, die in der HLR Datenbank gespeichert ist, die auf der IMSI der gerufenen Funktionseinheit basiert.
Die vorliegende Erfindung löst dieses Problem unter Verwendung des Domainbenennungssystems (DNS), um eine Beziehung zwischen einer MSISDN eines mobilen Teilnehmers und einer IMSI zu administrieren. Daher, wird, wenn mit der MSISDN des mobilen Teilnehmers eine Rufaufbaumeldung empfangen wird, eine ENUM Meldung an einen DNS Server gesendet, eine Zuordnung der MSISDN der gerufenen Funktionseinheit anfordernd. Der DNS Server verwendet die MSISDN in der ENUM Anfrage, um einen entsprechenden NAPTR Datenblock zu erhalten, der die IMSI der gerufenen Funktionseinheit enthält. Die zurückgegebene IMSI wird verwendet, um den Anruf weiterzuleiten. Eine ähnliche Beziehung kann im DNS zwischen der MSISDN der gerufenen Funktionseinheit (oder einem anderen Identifikationsmerkmal) und einem mobilen, globalen Titel (MGT) (oder einem anderen Identifikationsmerkmal), der mit der gerufenen Funktionseinheit assoziiert ist, administriert werden.
KURZBESCHREIBUNG DER ABBILDUNGEN
Die vorhergehenden und andere Aufgaben, Eigenschaften und Vorteile der Erfindung werden aus der folgenden Beschreibung von bevorzugten, nicht limitierenden Beispielausführungen offenkundig, die ebenso in den beiliegenden Abbildungen dargestellt werden. Die Abbildungen sollten nicht skaliert werden, sondern es wurde stattdessen Wert auf die Illustration der Prinzipien der Erfindung gelegt.
1 stellt ein Nachrichtenverkehrssystem dar, in dem die vorliegende Erfindung angewendet wird;
2 ist ein Flussdiagramm, das einen Satz von exemplarischen Prozeduren zur Implementierung der vorliegenden Erfindung im Kontext mit dem Nachrichtenverkehrssystem der 1 darstellt;
3 ist ein vereinfachtes Funktionsblockdiagramm des in 1 gezeigten Leitungsvermittlungsnetzknotens;
4 ist ein Flussdiagramm, das einen Satz von Prozeduren für eine Beispielanwendung der vorliegenden Erfindung in einem mobilen Nachrichtenverkehrskontext, in dem ein Nummernportabilitäts-Datenbankknoten verwendet wird, um die DNS Zuordnung zu koordinieren;
5 ist ein Diagramm, das ein mobiles Netzwerk und das Internet darstellt, in dem zwei Beispiele gezeigt werden, in denen die vorliegende Erfindung in einem Nummernportabilitätskontext implementiert werden könnte;
6 ist ein Signalisierungsdiagramm, das sich auf die vorliegende Erfindung bezieht, Beispielsignale darstellend, die ein Leitungsvermittlungsnetz-Signalisierungsprotokoll verwenden;
7 ist ein Signalisierungsdiagramm, das die vorliegende Erfindung darstellt, ein weiteres Signalisierungsprotokoll verwendend; und
8 stellt ein weiteres Nachrichtenverkehrsnetz dar, in dem die vorliegende Erfindung in einem Nummernportabilitäts-Datenbankknoten und in anderen Knoten für andere Netzwerke implementiert werden könnte.
DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zur Erklärung und nicht zur Begrenzung spezifische Details dargelegt, wie spezielle Ausführungen, Prozeduren, Techniken, etc., um ein vollständiges Verstehen der vorliegenden Erfindung zu liefern. Jedoch wird es einem Fachmann klar werden, dass die vorliegende Erfindung in anderen Ausführungen praktiziert werden könnte, die sich von diesen spezifischen Details entfernen. In einigen Fällen werden detaillierte Beschreibungen von wohl bekannten Verfahren, Protokollen, Software- und Hardwareplattformen, Interfaces, Vorrichtungen und Signalisierungstechniken weggelassen, um die Beschreibung der vorliegenden Erfindung nicht mit unnötigen Details zu verschleiern. Darüber hinaus werden in einigen Abbildungen individuelle Funktionsblöcke gezeigt. Die Fachleute werden anerkennen, dass die Funktionen unter Verwendung individueller Hardwareschaltkreise implementiert werden könnten, dabei Software verwendend, die im Zusammenhang mit einem geeignet programmierten, digitalen Mikroprozessor oder einem Universalcomputer verwendet wird, und dabei einen anwendungsspezifischen, integrierten Schaltkreis (ASIC), und/oder einen oder mehrere digitale Signalprozessoren (DSPs) verwendend.
Die 1 stellt ein allgemeines Nachrichtenverkehrssystem 10 dar, das eine Beispielanwendung der Erfindung illustriert. Eine erste Funktionseinheit 12 sendet eine Kommunikationsanforderung mit einer gerufenen Funktionseinheit an ein Leitungsvermittlungs-(CS)Netzwerk 14, die an einen Leitungsvermittlungsnetzknoten 16 geliefert wird, der Wegesuchservices zur Verfügung stellt. In der Anforderung ist eine Bezeichnung enthalten, die mit der gerufenen Funktionseinheit assoziiert ist. Der Begriff "Funktionseinheit" wird im allergemeinsten Sinn verwendet und enthält (ist jedoch nicht limitiert) jede Benutzervorrichtung, jede Serviceanwendung, oder jede Verarbeitungseinheit, ob benutzerspezifisch, oder netzwerkspezifisch, oder beides. Die gerufene Funktionseinheitsbezeichnung enthält jeden Bezeichnungstyp. In einigen Situationen sollte die gerufene Funktionseinheitsbezeichnung zugeordnet werden, um Kommunikation zwischen der ersten Funktionseinheit 12 und der gerufenen Funktionseinheit zu erlauben.
Um diesen Zuordnungsprozess zu ermöglichen fordert der Leitungsvermittlungsnetzknoten 16 einen Zuordnungsservice von einem Domainbenennungssystem-(DNS)Server 20 an, der mit einem Paketdatennetz 18 gekoppelt ist. Wie oben beschrieben ist das Domainbenennungssystem ein Teil des Paketdatennetzes 18, z.B., dem Internet. Der DNS Server initiiert den Zuordnungsservice unter Verwendung des DNS, indem er die gerufene Bezeichnung verwendet und das Zuordnungsergebnis an den Leitungsvermittlungsnetzknoten 16 zur weiteren Verarbeitung der Anforderung der ersten Funktionseinheit liefert. Der Leitungsvermittlungs-Kernnetzknoten 16 könnte einige Services auf der Basis des Zuordnungsergebnisses selbst durchführen, oder er könnte das Zuordnungsergebnis an einen anderen Knoten im Leitungsvermittlungsnetz 14 zur weiteren Verarbeitung der Anforderung der ersten Funktionseinheit liefern.
Das Flussdiagramm in der 2 stellt Beispielprozeduren dar, die mit einer Beispielimplementierung der vorliegenden Erfindung im Nachrichtenverkehrssystem 10 assoziiert sind, das in 1 gezeigt wird. Eine Anforderung nach einem ersten Service wird über das Leitungsvermittlungsnetz 14 empfangen, z.B., ein Anruf von einer ersten Funktionseinheit 12 an eine zweite gerufene Funktionseinheit (nicht gezeigt), die eine zweite assoziierte Funktionseinheitsbezeichnung (Block 30) besitzt. Eine Meldung wird an den DNS Server 20 in einem Paketvermittlungs-Datennetzwerk 18 gesendet, die einen DNS Service anfordert, der sich auf die zweite Funktionseinheitsbezeichnung bezieht (Block 32). Ein Ergebnis wird vom DNS Server 20 über das Leitungsvermittlungsnetz (Block 34) empfangen. Das Leitungsvermittlungsnetz stellt den ersten Service unter Verwendung des DNS Ergebnisses zur Verfügung (Block 36).
3 stellt in einem vereinfachten Funktionsblockformat den Leitungsvermittlungsnetzknoten 16, gezeigt in 1, dar. Der Leitungsvermittlungsnetzknoten 16 enthält ein Leitungsvermittlungsserviceinterface 42, das mit einem Servicekontroller gekoppelt 34 ist, das wiederum an ein DNS Serviceinterface 46 gekoppelt ist, und vielleicht an andere Hilfsmittel, wie eine Datenbank 46. Die Funktionen der Blöcke 42, 44 und 46 könnten bevorzugt unter Verwendung von Softwarecode durchgeführt werden, der auf einem geeigneten Mikroprozessor oder anderen Computerschaltkreisen ausgeführt wird.
Das Leitungsvermittlungsserviceinterface 42 empfängt Anforderungen für eine DNS Zuordnung von einem oder mehreren Leitungsvermittlungsknoten, z.B., einem Leitungsvermittlungswegesuchknoten. Dieses Interface 42 verwendet Standardkontrollsignalprotokolle, die im Leitungsvermittlungsnetz verwendet werden, z.B., Signalisierungssystem-7Signalisierung (SS7). Der Servicekontroller 44 analysiert die Signalisierungsmeldungen und erkennt die gerufene Funktionseinheitsbezeichnung und jede Anzeige, ob die DNS Zuordnung für die gerufene Funktionseinheitsbezeichnung gefordert wird. Falls ja, koordiniert sich der Servicekontroller 44 mit dem DNS Serviceinterface 46, so dass das DNS Serviceinterface 46 eine geeignete Abfrage generiert, indem er ein Paketvermittlungs-Netzwerksignalisierungsprotokoll verwendet, das vom Domainbenennungssystem erkannt und benutzt wird. Das DNS Serviceinterface 46 empfängt das DNS Zuordnungsergebnis im PS Netzwerkkontrollsignalisierungsformat und sendet es zum Servicekontroller 44 zurück, der es wiederum an das CS Serviceinterface 44 liefert. Das CS Serviceinterface 44 formatiert das Zuordnungsergebnis in eine Leitungsvermittlungs-Netzsignalisierungsmeldung, z.B., eine CS Wegesuchmeldung.
Diese Funktionen des Leitungsvermittlungsnetzknotens 16 könnten in jedem aus der Vielfalt der Knoten implementiert werden, die in dem Leitungsvermittlungsnetz existieren, oder ein neuer Knoten könnte zum Leitungsvermittlungsnetz hinzugefügt werden. Natürlich ist es wahrscheinlich in existierenden Netzen vorzuziehen, einfach Softwarecode, der diese Funktionen implementiert, zu einem existierenden Knoten hinzuzufügen, um Kosten und andere Nachteile zu minimieren, die mit dem Neukonfigurieren oder dem Hinzufügen von Knoten in oder zu einem Netzwerk assoziiert sein könnten.
Die vorliegende Erfindung liefert eine Anzahl von Vorteilen. Erstens erlaubt sie den Leitungsvermittlungs-Netzfunktionseinheiten Zugriff zu Services zu bekommen und sie zu empfangen, die von einem auf Paketen basierendem Netzwerk geliefert werden, in diesem Fall DNS Services. Auf Paketen basierende Services bieten Flexibilitäten und Optionen, die in einem Leitungsvermittlungsnetz nicht angeboten oder anderweitig nicht praktikabel sein könnten. Zweitens kann dieser Zugriff zu IP Netwerkservices ohne größere Konfiguration oder Ausgaben einfach durch die Implementierung der vorliegenden Erfindung unter Verwendung von Softwarecode in einem existierenden Knoten im Leitungsvermittlungsnetz erreicht werden. Drittens könnten Netzbetreiber einen Vorteil aus der DNS IP Infrastruktur ziehen, um sowohl die Nummernportabilitätszuordnung als auch andere Services zu verbessern, die eine Nummernbehandlung in Leitungsvermittlungsdomains verwenden. Z.B., könnten existierende Leitungsvermittlungsdomain-Benennungsservices, wie eine vorausbezahlte Zuordnung, die auf einem gerufenen E.164 Nummernservice basiert und eine lokale Benennungsplanübersetzung in einen speziellen Leitungsvermittlungsservice, (z.B., Verbindung zu einem Notfallzentrum, Verbindung zu Informationszentren, etc.), auch von der Nummernzuordnung profitieren, die durch das DNS geliefert wird.
Ein Beispiel mit mehr Einzelheiten, das die vorliegende Erfindung in einer nicht limitierenden Weise implementiert, wird nun weiter unten im Kontext beschrieben, in dem das Leitungsvermittlungssystem ein mobiles/zellulares Netzwerk ist und das Paketvermittlungsnetz das Internet ist. Es wird auf das Flussdiagramm Bezug genommen, das Beispielprozeduren in der 4 darstellt. Ein Leitungsvermittlungs-Wegesuchknoten in einem zellularen Netzwerk empfängt von einem mobilen Teilnehmer eine Rufaufbaumeldung an eine gerufene Funktionseinheit, die eine mit der gerufenen Funktionseinheit assoziierte Nummer enthält (Block 50). Der Leitungsvermittlungs-Wegesuchknoten sendet eine Wegesuchanforderungsmeldung an einen existierenden Nummernportabilitäts-(NPDB)Knoten im Leitungsvermittlungsnetz, der die gerufene Funktionseinheits-Telefonnummer und eine Anforderung für eine DNS Zuordnung (Block 51) enthält. Daher enthält in diesem Beispiel die Nummernportabilitätsdatenbank im Leitungsvermittlungsnetz eine auf Software basierende Funktionalität, die Zugriff zu den DNS Zuordnungsservices liefert, die vom Internet angeboten werden. Natürlich könnten andere Knoten Mobilnetz diese Funktionen auch ausführen.
Die Nummernportabilitätsdatenbank interpretiert, wie oben erklärt, Leitungsvermittlungs-Signalisierungsprotokollmeldungen, wie SS7 Meldungen, die im zellularen Netzwerk verwendet werden, und extrahiert aus ihnen Information, wie die gerufene Funktionseinheits-Telefonnummer und eine Anforderungsanzeige für eine DNS Zuordnung. Die Information wird benutzt, um eine Anforderung an einen DNS Server zu formatieren, die eine DNS Zuordnung der Telefonnummer anfordert. Speziell in diesem Beispiel sendet der Nummernportabilitätsdatenbankknoten eine ENUM Anfrage an einen DNS Server (Block 53). In diesem nicht limitierendem Beispiel werden herkömmliche, mobile und feste Telefonnummern, bezeichnet als E.164 Nummern, in der ENUM Anfrage gesendet. Jedoch könnten andere Bezeichnungsschemata verwendet werden, um den Ort einer Benutzersubskription, ein Gerät des Benutzers und eine Serviceanwendung des Benutzers sowohl in öffentlichen als auch in privaten Umgebungen zu identifizieren. Mit anderen Worten, die vorliegende Erfindung ist nicht auf ein spezielles Bezeichnungs- oder Bennennungsschema begrenzt.
ENUM Abfragen werden in der Internetkonstruktionsarbeitsgruppen-(IETF)Anforderung zu Kommentaren (RFC) 2916 erklärt, die die ENUM Prozeduren zum Senden von E.164 Nummern in die DNS Infrastruktur beschreibt. ENUM kann als ein Format für eine DNS Anfrage betrachtet werden, die Bezeichnungsinformation, wie die E.164 Nummern, transportiert. Ein spezielles Beispiel, wie eine ursprüngliche E.164 Telefonnummer in ein ENUM Meldungsformat konvertiert wird, wird in der öffentlich zugänglichen U.S. Patentanmeldung, veröffentlicht am 9. Januar 2003 als US 2003007482 , mit dem Titel "Verfahren und Vorrichtung zur Zuordnung einer Funktionseinheitsbezeichnung in eine Internetadresse unter Verwendung eines Domainnamensystem-(DNS) Servers und einer Funktionseinheitsbezeichnungs-Portabilitätsdatenbank".
Gemäß RFC2916, verwendet das Domainbenennungssystem eine ENUM Anfrage um einen Benennungsautoritätszeiger-(NAPTR)Datenblock abzurufen, der mit der E.164 Nummer der gerufenen Funktionseinheit assoziiert ist. Die DNS Antwort auf die ENUM Abfrage enthält einen oder mehrere NAPTR Datenblöcke. Die der E.164 Nummer entsprechen, und jeder NAPTR Datenblock enthält einen oder mehrere einheitliche Hilfsmittelbezeichnungen (URIs), die der Funktionseinheit entsprechen. Von einem URI könnte ein Service und/oder eine Adresse abgeleitet werden, die der gerufenen Funktionseinheitsbezeichnung entspricht. Es wird wieder auf die oben identifizierte Anwendung für spezielle Beispiele Bezug genommen.
Entsprechend gibt der DNS Server einen NAPTR Datenblock für die gerufene Funktionseinheits-Telefonnummer (Block 54) zurück, und der Nummernportabilitäts-Datenbankknoten sendet das Zuordnungsergebnis an den Leitungsvermittlungs-Wegessuchknoten (Block 55). Der Leitungsvermittlungs-Wegesuchknoten leitet den Ruf des mobilen Teilnehmers unter Verwendung des DNS Zuordnungsergebnisses (Block 56) weiter.
Mit Bezug auf die 5, die ein Nachrichtenverkehrssystem zeigt, könnten die in 4 dargelegten Prozeduren angewendet werden. Ein mobiles Leitungsvermittlungsnetz 60 wird mit zwei mobilen Schaltzentren (MSCs) 62 und 63 dargestellt, von denen eines mit einem Gateway MSC (GMSC) 64 gekoppelt ist. Das mobile Leitungsvermittlungsnetz 60 enthält auch zwei Nummernportabilitätsdatenbanken, gewöhnlich in 65 und 66 angezeigt. Der intelligente Netzwerk-(IN)Typ der NPDB 65 an der Spitze der Abbildung enthält ein intelligentes Netzwerkanwendungsteil-(INAP)Protokoll, und der Signalisierungsrelaisfunktions-(SRF)Typ der NPDB 66 am Boden der Abbildung verwendet ein mobiles Anwendungsteil-(MAP)Protokoll. Beide Protokolle verwenden SS7 Signalisierung. Das Paketvermittlungsnetz 61 enthält unter anderem einen DNS Server 75, der mit einem DNS gekoppelt ist, der symbolisch in 76 angezeigt wird.
Ein Anruf zur gerufenen Funktionseinheit, der von einem Mobiltelefon im Mobilnetz 60 initiiert wird, wird an MSC 63 weitergegeben, das den Ruf in einer SS7 Anfangsadressenmeldung (IAM), die das MSISDN der gerufenen Funktionseinheit enthält, an das Gateway MSC 64 weitergibt. Abhängig vom Typ der Nummernportabilitätsdatenbank, die im Mobilnetz 61 sein könnte, formuliert der Gateway-MSC 64 Wegesuchknoten eine SS7 Sendewegesuchinformations-(SRI)Anforderungsmeldung, die sowohl die MSISDN der gerufenen Funktionseinheit als auch eine Anzeige liefert, dass eine DNS Zuordnung gefordert wird. Wenn die Nummernportabilitätsdatenbank auf einem intelligenten Netzwerk (IN) basiert, dann wird eine Anfangserkennungspunkt-(IDP)Meldung einschließlich der MSISDN Nummer an die IN Nummernportabilitätsdatenbank 67 weitergeleitet, zusammen mit einem Serviceschlüssel mit einer "DNS Zuordnung gefordert Anzeige". Die IN-NPDB 67 kommuniziert mit dem GMSC unter Verwendung der auf dem INAP Protokoll basierenden Signalisierungsinformation.
Die Softwarefunktionseinheit in der NPDB, #7DR69 genannt (SS7 Domainnamenfinder), analysiert die IDP Meldung und erkennt die MSISDN und über den Serviceschlüssel die Tatsache, das eine DNS Zuordnung gefordert wird. Die #7DR69 liefert die MSISDN an einen Domainnamen-(DN)Finder 70, der eine ENUM Anfrage unter Verwendung der MSISDN Nummer formuliert und an das Domainbenennungssystem 75 sendet. Eine E.164 Zuordnung wird im DNS 76 durchgeführt, und das Zuordnungsergebnis wird an den DN Finder 70 zurückgesendet. Der DN Finder 70 leitet das Zuordnungsergebnis über den#7DR69 an den SCP 67 weiter, der eine SS7 Verbindungsmeldung (CONNECT) zurück an den GMSC 64 sendet. Die Verbindungsmeldung (CONNECT) enthält die MSISDN Nummer und einen entsprechenden Präfix, ob die MSISDN Nummer portiert worden ist. Das Präfix zeigt den Ort des aktuellen Heimatbetreibernetzes der gerufenen Telefonnummer an. Der Gateway MSC 64 hat nun genügend Information, um den Anruf weiterzuleiten, da das Präfix Wegesuchinformation für das Heimatnetz der gerufenen Funktionseinheit liefert. Entsprechend sendet der Gateway eine SS7 Anfangsadressenmeldung (IAM), die sowohl das Präfix als auch die MSISDN Nummer für die gerufene Funktionseinheit enthält.
Alternativ könnte der Gateway MSC 64 mit einem Signalisierungsrelaisfunktions-(SRF)Typ des Nummernportabilitätsknoten 71 kommunizieren, der eine hereinkommende SS7 Sendewegesuchinformation-(SRI)MAP Meldung weiterleiten oder zurückantworten kann. Der SRF Nummernportabilitätsknoten 71 kommuniziert mit dem GMSC 64 unter Verwendung der SS7 Signalisierung. Der GMSC 64 sendet eine Sendewegesuchinformations-(SRI)Meldung, die (1) die MSIOSDN Nummer der gerufenen Funktionseinheit und (2) ein Übersetzungstyp-(TT)Feld enthält, das anzeigt, dass eine DNS Zuordnung gefordert wird. Das SS7 Protokoll ist mit dem mobilen Anwendungsteil-(MAP)/Signalisierungsverbindungskontrollteil (SCCP) 72 gleich lautend. Das SRF-NPDB 71 könnte die hereinkommende SRI Meldung auf der SCCP Ebene an ein Standortsverzeichnis-(HLR)Typ der Datenbank (wie weiter unten im Detail beschrieben wird) weiterleiten oder dem GMSC mit einer SRI Empfangsbestätigung antworten.
Die #7DR Funktionseinheit 73 analysiert die SRI Meldung und erkennt die im TT Feld geforderte DNS Zuordnung. Entsprechend leitet sie die MSISDN Nummer an den DNS Finder 74 weiter, der eine ENUM Anfrage mit der MSISDN erzeugt und sie an den DNS Finder 75, wie oben beschrieben, weiterleitet. Das DNS Zuordnungsergebnis, d.h., ein NAPTR Datenblock, wird in einer SRI Empfangsbestätigungsmeldung, die sowohl das Heimatnetzpräfix der gerufenen Funktionseinheitsbezeichnung (unter der Annahme, das die Nummer portiert ist) als auch die MSISDN Nummer enthält, an das GMSC 64 zur Wegesuche geliefert.
Die 6 stellt ein Signalisierungsdiagramm für das Signalisierungsszenario, in dem die Nummernportabilitätsdatenbank ein Signalisierungsrelaisfunktions-(SRF)Typ des NPDB ist. Das Signal (1) ist eine Anfangsadressenmeldung (IAM), die die MSISDN der gerufenen Funktionseinheit enthält. Das IAM wird zum Gateway MSC des Nummernbereichs im Heimatnetz für die rufende Funktionseinheit weitergeleitet. Wenn das GMSC die IAM Meldung (2) empfängt, sendet es eine SRI Meldung an den Nummernportabilitäts-Datenbankknoten mit einem Übersetzungstypfeld, das anzeigt, dass eine DNS Zuordnung für diese Nummer gefordert wird. Die #7DR Funktionseinheit analysiert das Übersetzungstypfeld und weist den DNS Finder an, eine ENUM Anfrage für die gerufene MSISDN Nummer (4) zu formulieren. Als Antwort zur ENUM Anfrage, liefert der DNS Server schließlich einen assoziierten, mit dieser Nummer verbundenen NAPTR Datenblock, der entweder eine URL mit IMSI Information (5.1) oder ein URL mit einem Präfix plus MSISDN Information für die gerufene Funktionseinheit (5.2) enthält. Der NAPTR Datenblockinhalt wird von dem #7DR Funktionseinheit analysiert, um festzustellen, ob die Nummer der gerufenen Funktionseinheit portiert ist (6). Wie oben beschrieben beschreibt "das Portieren" den Transfer einer Nummer zwischen Netzwerkbetreibern. Die Nummernportabilität erlaubt einem mobilen Teilnehmer sein Subskriptionsnetz zu ändern, während er seine ursprüngliche MSISDN beibehält.
In der Meldung 5.1, enthält der NAPTR Datenblock eine Telefon URL, die keinen Präfix für das MSISDN enthält, das anzeigt, dass die gerufene Funktionseinheitsbezeichnungsnummer nicht portiert ist. Jedoch liefert in einem anderen vorteilhaften Aspekt der vorliegenden Erfindung die NAPTR Datenblock-Telefon URL die IMSI für die gerufene Funktionseinheit, die zum Service des Anrufs benutzt werden kann. Datenbanken des Typs HLR speichern nämlich herkömmlicher Weise Teilnehmerinformation unter der IMSI des Teilnehmers. Andererseits wird die wegesuche auf der Basis der MSI) SDN Nummer des mobilen Teilnehmers durchgeführt. Dieser Aspekt der vorliegenden Erfindung erlaubt dem DNS, die Beziehung zwischen einer IMSI und MSISDN eines Teilnehmers zu administrieren, um die Wegesuche nicht portierter Nummern zu unterstützen. Mit anderen Worten, der NAPTR Datenblock liefert der SRF Nummernportabilitätsdatenbank 71 die IMSI der gerufenen Partei, so dass die SS7 Sendewegesuchinformationsmeldung erneut geleitet werden kann, oder vom SRF-NPDB 71 an die HLR Datenbank der gerufenen Partei mit der IMSI des Teilnehmers "weitergeleitet" werden kann.
Mit der IMSI ist die HLR in der Lage geeignete Information nachzulesen und dann eine Wegesuchnummer für die gerufene Funktionseinheit aus dem MSC/Aufenthaltsverzeichnis (VLR) anzufordern, in dem der gerufene Teilnehmer aktuell registriert ist, Das MSC/VLR sendet eine Mobilstationswegesuchnummer (MSRN) an das HLR zurück. Das HLR sendet eine Sendewegesuchinformation-(SRI)Bestätigungsmeldung mit der Wegesuchnummer (MSRN) des mobilen Teilnehmers an das GMSC. Dies erlaubt dem GMSC eine Anfangsadressemeldung unter Verwendung des MSRN zu generieren, um den Anruf richtig an das besuchte Netz zu leiten.
Alternativ erkennt, wenn der NAPTR Datenblock eine Telefon URL mit einem Heimatpräfix plus der MSISDN (5.2) zurücksendet, die NAPTR Datenblockanalyse durch den #7DR, dass die MSISDN portiert ist. Die SRF-NPDB sendet eine SRI Bestätigungsmeldung an die GMSC, die das Präfix berichtet, das mit einer Wegesuchnummer des Heimat- oder Subskriptionsnetzes des gerufenen Teilnehmers zusammen mit der MSISDN korrespondiert. Als ein Ergebnis formuliert dann das Gateway MSC die Anfangsadressenmeldung unter Verwendung des Heimat/Subskriptionsnetzpräfix und der MSISDN zur Wegesuche zum Heimat/Subskriptionsnetz.
Ein ähnlicher Signalisierungsdiagrammtyp wird in der 7 für eine intelligente Netztypnummernportabilitätsdatenbank gezeigt. Der Anruf wird zur Gateway- MSC/Schaltservicefunktion (SSF) des Nummernbereichs im Subskriptionsnetzwerk des rufenden mobilen Teilnehmers geleitet (1). Wenn die GMSC/SSF die Anfangsadressenmeldung mit der MSISDN der gerufenen Funktionseinheit empfängt, sendet es eine IN Datenbankanfrage an die IN Nummernportabilitätsdatenbank mit einem speziellen Serviceschlüssel, der anzeigt, dass eine DNS Zuordnung für diese Nummer gefordert wird (2). Die #7DR Funktionseinheit im Knoten analysiert den Serviceschlüssel (3) und veranlasst den DNS Finder im Knoten, eine geeignete ENUM Anfrage an einen DNS Server zu formulieren (4). In der Antwort auf die ENUM Anfrage werden ein oder mehrere assoziierte NAPTR Datenblöcke für diese MSISDN zurückgesendet. In (5.1), enthält der NAOTR Datenblock eine URL mit dem Heimat/Subskriptionsnetzpräfix plus der MSISDN Nummer, die anzeigt, dass die Nummer portiert worden ist.
Der Inhalt des NAPTR Datenblocks wird von #7DR bei (6) analysiert, und eine intelligente Netzwerkanwendungsteil-(INAP)Protokollverbindungs-(CONNECT)Meldung wird an das GMSC/SSF zusammen mit dem Heimat/Subskriptionsnetzpräfix und der MSISDN Nummer gesendet (7.1). Diese Information erlaubt der GMSC/SSF eine geeignete IAM Wegesuchmeldung mit dem Präfix und der MSISDN Nummer zu formulieren (8.1). Alternativ erkennt das #7DR, wenn der NAPTR Datenblock nur die URL für die MSISDN (5.2) enthält, das die gerufene Teilnehmernummer nicht portiert worden ist (6) und sendet eine INAP Fortsetzungs-(CONTINUE)Meldung zurück an das GMSC/SSF (7.2), das eine IAM Wegesuchmeldung mit gerade der MSISDN Nummer formuliert (8.2).
Die vorliegende Erfindung ist nicht auf irgendeines der speziellen Implementierungsdetails oder spezielle oben beschriebene Anwendungen beschränkt. Allerdings könnten unterschiedliche Typen von Netzwerken unterschiedliche Typen von Knoten verwenden, um Zugriff auf Domainbenennungsystem-Zuordnungsservices zu zur Verfügung zu stellen. Mit Bezug auf einige, in der 8 gezeigten Beispiele, könnten ein Leitungsvermittlungsmobilnetz 100 und das Leitungsvermittlungsfestnetz 102 jeweils eine entsprechende Nummernportabilitätsdatenbank 104 und 106 verwenden, um die ENUM Anfrage und die NAPTR Datenblockanalyse zu instrumentieren. Ein IP Multimedia-(IM)System 110 für sowohl eine Festnetz als auch ein Mobilnetz könnte eine Dienrufservicekontrollfunktion-(S-CSCF)Funktionseinheit für das das Mobilnetz verwenden und eine Managementgateway-Kontrollfunktion-(MGCF)Funktionseinheit im festen IM Netz, um eine ENUM Anfrage und NAPTR Datenblockanalyse durchzuführen. Darüber hinaus könnte ein Multimediameldungssystem-(MMS)Netz 112 ein Multimediameldungs-Servicezentrum (MMS-C) verwenden, um ebenso diese Funktionen durchzuführen.
Unter Verwendung der vorliegenden Erfindung, könnte Nummernportabilitäts-Nachschlaginformation unter demselben Ansatz angefragt werden, unabhängig vom Abfragesystem, und daher unabhängig von der Anrufkontrolltechnologie. Die Administration der Nummernportabilitätsinformation wird unter Verwendung dieses gemeinsamen Ansatzes durchgeführt, in dem die DNS alle anfragenden Funktionseinheiten bedient. Die Erfindung könnte in jeder der E.164 (oder anderen Nummerierungen) nummerierungsbezogenen Prozeduren verwendet werden, in denen ein E.164 Zuordnungsprozess involviert ist.
Während die vorliegende Erfindung mit Bezug auf spezielle Beispielausführungen beschrieben wurde, werden die Fachleute anerkennen, dass die vorliegende Erfindung nicht auf diese spezifischen Ausführungen beschränkt ist, die hier beschrieben und dargestellt sind. Unterschiedliche Formate, Ausführungen, Adaptionen neben den gezeigten und beschriebenen, sowohl wie viele Modifikationen, Variationen und äquivalente Anordnungen könnten ebenso verwendet werden, um die Erfindung zu implementieren. Z.B., ist der DNS/ENUM Prozess relevant für die Server zu Server Kommunikation ohne irgendeinen Onlinebenutzer. Daher muss verstanden werden, obwohl die vorliegende Erfindung in Bezug auf die bevorzugten Beispielausführungen beschrieben ist, dass diese Offenlegung nur illustrativ und exemplarisch für die vorliegende Erfindung ist. Der Geltungsbereich der Erfindung wird in den beigefügten Ansprüchen beschrieben:

Claims

Ein Verfahren für ein Leitungsvermittlungs-Kommunikationsnetzwerk (14), um einem Teilnehmer Kommunikationsservices zur Verfügung zu stellen, das Erhalten einer Anforderung über das Leitungsvermittlungsnetzwerk (14) von einem ersten Objekt (12) für einen ersten Service enthaltend, der ein zweites Objekt einschließt, das mit einem zweiten Objektidentifikator assoziiert ist, folgendes enthaltend: einen Leitungsvermittlungs-Wegesuchknoten (16) im Leitungsvermittlungs-Kommunikationsnetzwerk (14), eine Wegesuchanforderungsmeldung an eine Nummernportabilitätsdatenbank in dem Leitungsvermittlungs-Kommunikationsnetzwerk (14) mit einem zweiten Objektidentifikator sendend; gekennzeichnet durch: das Senden einer Meldung an einen Domainnamensystem(DNS) Server (20) in einem Paketvermittlungsnetzwerk (18) von der Nummernportabilitätsdatenbank, einen zweiten, mit dem zweiten Objektidentifikator verwandten, Service anfordernd; das Empfangen des Ergebnisses des zweiten Service vom DNS Server (20) ; und das Liefern des ersten Service unter Verwendung des Ergebnisses.
Das Verfahren im Anspruch 1, worin der erste Service eine elektronische Kommunikation zwischen ersten und zweiten Objekten ist, und der zweite Service eine Zuordnung des zweiten Objektidentifikators ist.
Das Verfahren in Anspruch 1, worin die Wegesuchanforderung weiterhin anzeigt, dass eine DNS Zuordnung für den zweiten Objektidentifikator benötigt wird, und worin der DNS Server ein Zuordnungsergebnis zurückgibt.
Das Verfahren im Anspruch 3, worin das Ergebnis der DNS Zuordnung anzeigt, ob der zweite Objektindikator zwischen Netzwerkbetreibern übertragen worden ist.
Das Verfahren im Anspruch 4, worin, wenn der zweite Objektindikator nicht zwischen Netzwerkbetreibern übertragen wurde, das Verfahren weiterhin enthält: Verarbeitung der elektronischen Kommunikation in einer Behandlung, die Nummernportabilität nicht in Betracht zieht, und worin, wenn der zweite Objektindikator zwischen Netzwerkbetreibern übertragen worden ist, das Verfahren weiterhin enthält: Verarbeitung der elektronischen Kommunikation in einer anderen Behandlung, die Nummernportabilität in Betracht zieht.
Das Verfahren im Anspruch 5, worin die unterschiedliche Verarbeitungsbehandlung das Liefern eines Wegesuchknoten im Leitungsvermittlungs-Kommunikationsnetzwerk mit einer Wegesuchnummer enthält, die ein Heimatnetzwerk des zweiten Objekts identifiziert.
Das Verfahren im Anspruch 1, worin der erste Service eine elektronische Kommunikation zwischen ersten und zweiten Objekten ist, und der zweite Service eine, mit dem zweiten Objekt assoziierten Zuordnung einer Nummer, eines Namens, oder einer Adresse ist.
Das Verfahren im Anspruch 1 zur Lieferung von Rufservices an einen mobilen Teilnehmer, folgende s enthaltend: empfangend von einem mobilen Teilnehmer an einem Leitungsvermittlungsknoten (65, 66) in einem zellularen Netzwerk (60) eine Rufaufbaumeldung zu einem gerufenem Objekt, eine gerufene Objekttelefonnummer enthaltend; die Nummernportabilitätsdatenbank eine Meldung an ein Domainnamensystem-(DNS)Server (75) in ein Paketvermittlungsnetzwerk (61) sendend, eine Zuordnung der gerufenen Objekttelefonnummer anfordernd; und unter Verwendung des Zuordnungsresultats für den mobilen Teilnehmer einen Weg suchend.
Das Verfahren im Anspruch 8, worin der Leitungsvermittlungsknoten eine Nummernportabilitätsdatenbank (67,71) im Leitungsvermittlungsnetzwerk (60) unter Verwendung der gerufenen Objekttelefonnummer und einer Anzeige abfragt, dass eine DNS Zuordnung für die gerufene Objekttelefonnummer benötigt wird.
Das Verfahren im Anspruch 9, worin die Nummernportabilitätsdatenbank (67,71) eine ENUM Abfrage an den DNS Server (75) generiert, die gerufene Objekttelefonnummer enthaltend, und der DNS Server (75) eine NAPTR Datenblock zurückgibt, einen universellen Hilfsmittelpositionsgeber enthaltend, entsprechend zu der gerufenen Objekttelefonnummer.
Das Verfahren im Anspruch 10, worin der NAPTR Datenblock variiert, abhängig davon, ob die gerufene Objekttelefonnummer zwischen Netzwerkbetreibern übertragen worden ist.
Das Verfahren im Anspruch 11, worin, wenn die gerufene Objekttelefonnummer nicht zwischen Netzwerkbetreibern übertragen wurde, das Verfahren folgendes enthält: das Verarbeiten der Rufaufbaumeldung in einer ersten Behandlung, die Nummerportabilität nicht in Betracht zieht, und worin, wenn die gerufene Objekttelefonnummer zwischen Netzwerkbetreibern übertragen worden ist, das Verf ahren weiterhin enthält: das Verarbeiten der Rufaufbaumeldung in einer zweiten Behandlung, die Nummernportabilität in Betracht zieht.
Das Verfahren im Anspruch 12, worin die zweite Behandlung das Informieren des Leitungsvermittlungsknotens über das Heimatnetzwerk der gerufenen Partei beinhaltet.
Das Verf ahren im Anspruch 13, worin die erste Behandlung das Wegesuchen der Rufaufbaumeldung zu einem Standortverzeichnis (HLR) für das gerufene Objekt enthält, das HLR eine Wegesuchnummer von einem Gastortsverzeichnis (VLR), gerade die gerufene Partei bedienend, anfordert und die vom VLR zurückgegebene Wegesuchnummer an den Leitungsvermittlungsknoten liefert.
Das Verfahren im Anspruch 8, worin Objekte in dem Leitungsvermittlungsnetzwerk ein SS7 Signalisierungsprotokoll anwenden.
Das Verfahren im Anspruch 15, worin der Leitungsvermittlungsknoten ein mobiles Gatewayschaltzentrum (GMSC) ist, das die Nummernportabilitätsdatenbank unter Verwendung des mobilen Verwendungsteil-(MAP)Protokolls und eines speziellen Übersetzungstyps (TT) während des Anforderns der DNS Zuordnung abfragt.
Das Verfahren im Anspruch 15, worin der Leitungsvermittlungsknoten das mobile Gatewayschaltzentrum (GMSC) ist, das die Nummernportabilitätsdatenbank unter Verwendung eines intelligenten Netzwerkverwendungsteil-(INAP)Protokolls und eines speziellen Service während des Anforderns der DNS Zuordnung abfragt.
Das Verfahren im Anspruch 8, worin das gerufene Objekt eine entsprechende integrierte, digitale Servicenetzwerknummer des mobilen Teilnehmers (MSISDN) und eine internationale Mobilteilnehmeridentität (IMSI) besitzt, wobei das Verfahren weiterhin enthält: das Administrieren einer Beziehung zwischen der MSISDN des mobilen Teilnehmers und der IMSI in der DNS.
Das Verfahren in Anspruch 18, worin das gerufene Objekt eine entsprechende integrierte, digitale Servicenetzwerknummer des mobilen Teilnehmers (MSISDN) und eine internationale Mobilteilnehmeridentität (IMSI) besitzt, weiterhin enthaltend: das Ändern der MSISDN für das gerufene Objekt in das IMSI für das gerufene Objekt und das Verwenden des IMSI des gerufenen Objekts um den Anruf zum gerufenen Objekt zu führen.
Das Verfahren im Anspruch 1 zur Lieferung eines Rufservices, wobei das zweite Objekt ein gerufenes Objekt mit einer entsprechenden integrierten, digitalen Servicenetzwerknummer des mobilen Teilnehmers (MSISDN) und einer internationalen Mobilteilnehmeridentität (IMSI) ist, weiterhin gekennzeichnet durch: das Administrieren einer Beziehung zwischen der MISDN und IMSI des gerufenen Objekts im Domainnamensystem (DNS).
Das Verfahren im Anspruch 20, weiterhin enthaltend: das Empfangen einer Rufaufbaumeldung an das gerufene Objekt, die MSISDN des gerufenen Objekts enthaltend; das Senden einer Meldung durch die Nummernportabilitätsdatenbank an einen DNS Server, eine Zuordnung der MSISDN des gerufenen Objekts anfordernd; das Empfangen der IMSI aus dem DNS Server für die gerufene Objekttelefonnummer und das Wegesuchen für den Anruf unter Verwendung der IMSI.
Das Verfahren im Anspruch 21, weiterhin enthaltend: das Administrieren einer Beziehung im DNS zwischen der MSISDN des gerufenen Objekts und einem mobilen, globalen Titel (MGT), der mit dem gerufenen Objekt assoziiert ist.
Das Verfahren im Anspruch 22, weiterhin enthaltend: das Empfangen einer Rufaufbaumeldung an das gerufene Objekt, die MSISDN des gerufenen Objekts enthaltend, das Senden einer Meldung an einen Domainnamensystem(DNS) Server, eine Zuordnung der MSISDN des gerufenen Objekts anfordernd; das Empfangen des MGT für die gerufene Objekttelefonnummer vom DNS Server und das Wegesuchen für den Anruf unter Verwendung des MGT.
Eine Nummernportabilitätsknoten (64,65) für ein Leitungsvermittlungs-Kommunikationsnetzwerk (14), der einen Nummernportabilitätsservice liefert, wobei der Nummernportabilitätsknoten (65,66) elektronische Verarbeitungsschaltkreistechnik, gekoppelt mit einer Nummernportabilitätsdatenbank (67, 71) im Leitungsvermittlungs-Kommunikationsnetzwerk (14) enthält und weiterhin ein Leitungsvermittlungs-Serviceinterface (42) zum Empfangen einer Anforderung aus einem ersten Objekt im Leitungsvermittlungs-Kommunikationsnetzwerk (14) enthalten, ein zweites Objekt, assoziiert mit einem zweiten Objektidentifikator, einschließend, gekennzeichnet durch: einen Kontroller (44) zum Analysieren der Anforderung und zum Festlegen, dass der zweite Objektidentifikator in einem Domainnamensystem (DNS) verarbeitet werden soll, und ein DNS Serviceinterface (46) zum Generieren und Senden einer Meldung an einen DNS Server (20) in einem Paketvermittlungsnetzwerk (18) DNS-Verarbeitung des zweiten Objektidentifikators anfordernd, worin der Kontroller (44) konfiguriert ist, um eine DNS-Antwort über das DNS Serviceinterface (46) zu empfangen und die DNS-Antwort an das erste Objekt zu liefern.
Der Knoten im Anspruch 24, worin die DNS-Verarbeitung eine Zuordnung des zweiten Objektidentifikators einschließt.
Der Knoten in Anspruch 24, worin die DNS-Antwort anzeigt, ob der zweite Objektidentifikator zwischen Netzwerkbetreibern übertragen worden ist.
Der Knoten im Anspruch 26, worin, wenn der zweite Objektidentifikator zwischen Netzwerkbetreibern übertragen worden ist, der Kontroller konfiguriert ist, um einen Wegesuchknoten im Leitungsvermittlungs-Kommunikationsnetzwerk mit einer Wegesuchnummer, die ein Heimatnetzwerk des zweiten Objekts identifiziert, zur Verfügung zu stellen.
Der Knoten im Anspruch 24, worin die DNS-Verarbeitung eine Zuordnung einer Nummer, eines Namens oder Adresse des zweiten Objektidentifikators einschließt.
Ein Nummernportabilitätsknoten (65,66) für ein Leitungsvermittlungs-Kommunikationssystem (14) enthaltend eine elektronische Verarbeitungsschaltkreistechnik, die an eine Nummernportabilitätsdatenbank (67,71) gekoppelt ist und im Leitungsvermittlungs-Kommunikationsnetzwerk (14) enthalten ist, und die Verarbeitungsschaltkreistechnik ist konfiguriert, um die folgenden Aufgaben durchzuführen: empfange von einem Leitungsvermittlungs-Wegesuchknoten (64) eine Anforderung, eine gerufene Objekttelefonnummer einschließend, die mit einer Rufaufbaumeldung an das gerufene Objekt assoziiert ist; darin gekennzeichnet, dass sie auch konfiguriert ist: um eine Meldung an den Domainnamensystem-(DNS)Server (75) in einem Paketvermittlungs-Kommunikationsnetzwerk (61) zu senden, eine Zuordnung der gerufenen Objekttelefonnummer anfordernd; empfange ein Zuordnungsresultat vom DNS Server (75) für die gerufene Objekttelefonnummer; und liefere das Zuordnungsresultat an den Wegesuchknoten (64) zur Verwendung bei der Wegesuche des Anrufs.
Der Nummernkompatibilitätsknoten im Anspruch 29, worin die Anforderung eine Nummernportabilitäts-Datenbankabfrage ist, anzeigend, dass eine DNS Zuordnung für die gerufene Objekttelefonnummer benötigt wird.
Der Nummernportabilitätsknoten im Anspruch 30, worin die elektronische Datenverarbeitungsschaltkreistechnik (70,74) konfiguriert ist, um eine ENUM Abfrage an den DNS Server, die gerufene Objekttelefonnummer einschließend, zu generieren und um vom DNS Server einen NAPTR Datenblock zu empfangen, der einen universalen Hilfsmittelpositionsgeber, der gerufenen Objekttelefonnummer entsprechend, einschließt.
Der Nummernportabilitätsknoten im Anspruch 30, worin der Inhalt des NAPTR Datenblocks abhängig davon variiert, ob die gerufene Objekttelefonnummer zwischen Netzwerkbetreibern übertragen worden ist.
Der Nummernportabilitätsknoten im Anspruch 32, worin, wenn die gerufene Objekttelefonnummer zwischen Netzwerkbetreibern übertragen worden ist, die elektronische Datenverarbeitungsschaltkreistechnik konfiguriert ist, um die Rufaufbaumeldung unter Berücksichtigung der Nummernportabilität zu verarbeiten.
Der Nummernportabilitätsknoten im Anspruch 33, worin die elektronische Datenverarbeitungsschaltkreistechnik konfiguriert ist, um den Leitungsvermittlungsknoten über einen Heimatnetzwerksidentifikator der gerufenen Partei zu informieren.
Der Nummernportabilitätsknoten im Anspruch 34, worin, wenn die gerufene Objekttelefonnummer zwischen Netzwerkbetreibern übertragen worden ist, die elektronische Datenverarbeitungsschaltkreistechnik konfiguriert ist, um Rufaufbaumeldung zu einem Standortverzeichnis (HLR) für das gerufene Objekt zu führen, so dass das HLR eine Wegesuchnummer aus einem Gastortsverzeichnis (VLR) erhalten könnte, das gerade die gerufene Partei bedient, und die Wegesuchnummer an den Leitungsvermittlungsknoten liefern könnte.
Der Nummerportabilitätsknoten im Anspruch 29, worin der Leitungsvermittlungsknoten und der Nummernportabilitätsknoten ein SS7 Signalisierungsprotokoll anwenden.
Der Nummerportabilitätsknoten im Anspruch 29, worin der Leitungsvermittlungsknoten eine mobiles Gatewayschaltzentrum (GMSC) (64) ist, das die Nummernportabilitätsdatenbank unter Verwendung des mobilen Verwendungsteil-(MAP)Protokolls und eines speziellen Übersetzungstyps (TT) während des Anforderns der DNS Zuordnung abfragt.
Der Nummerportabilitätsknoten im Anspruch 29, worin der Leitungsvermittlungsknoten ein mobiles Gatewayschaltzentrum (GMSC) (64) ist, das die Nummernportabilitätsdatenbank unter Verwendung des intelligenten Netzwerkverwendungsteil-(INAP)Protokolls und eines speziellen Service während des Anforderns der DNS Zuordnung abfragt.
Der Nummernportabilitätsknoten im Anspruch 29, worin das gerufene Objekt eine entsprechende, integrierte, digitale Servicenetzwerknummer des mobilen Teilnehmers (MSISDN) und eine internationale Mobilteilnehmeridentität (IMSI) besitzt, wobei die elektronische Verarbeitungsschaltkreistechnik konfiguriert ist, um im DNS eine Beziehung zwischen der MSISDN und der IMSI des mobilen Teilnehmers zu administrieren.
Der Nummernportabilitätsknoten im Anspruch 39, worin die elektronische Verarbeitungsschaltkreistechnik konfiguriert ist, um das MSISDN für das gerufene Objekt in das IMSI für das gerufenen Objekt zu ändern, es so verwendend, dass das IMSI benutzt werden kann, den Ruf zum gerufenen Objekt zu führen.
Ein Computer lesbares Produkt, ein Computer benutzbares Medium enthaltend, das Computer lesbaren Code besitzt, der hierin integriert ist, angepasst, um die Eigenschaften des Nummernportabilitätsknoten des Anspruchs 29 zu implementieren und weiterhin enthaltend: Code, um eine E.164 Typ Nummer in einer Signalisierungsnummer-7(SS7)Meldung zu empfangen; Code, um eine DNS Zuordnungsanforderung für die E.164 Typnummer zu generieren und an einen Domainnamenerzeugungssystem-(DNS)Server (75) zu senden; und Code, um eine Zuordnungsantwort zurückzugeben, die Information darüber gibt, ob die E.164 Nummer eine portierte Nummer ist.
Das Computer lesbare Produkt gemäß dem Anspruch 41, worin die DNS Anforderung eine ENUM Abfrage ist und die Zuordnungsantwort einen NAPTR Datenblock beinhaltet, der mit der E.164 Nummer assoziiert.
Das Computer lesbare Produkt gemäß dem Anspruch 41, worin die Information ein Präfix ist, der notwendig ist, um die E.164 Nummer zu leiten.
Das Computer lesbare Produkt gemäß dem Anspruch 41, worin die SS7 Meldung eine Sendungsleitungsinformations-(SRI) Meldung ist, die eine DNS Zuordnungsanforderung in einem Übersetzungstyp-(TT)Feld enthält.
Das Computer lesbare Produkt gemäß dem Anspruch 41, worin die SS7 Meldung eine (IDP) Meldung ist, die eine DNS Zuordnungsanforderung in einem Serviceschlüssel enthält.