DE60122109T2

DE60122109T2 - Verfahren und Systeme zur Vermittlung von Nachrichten, die mit übertragenen Teilnehmern verbunden sind, in einem mobilen Kommunikationsnetz

Info

Publication number: DE60122109T2
Application number: DE60122109T
Authority: DE
Inventors: Matthew Thomas Morrisville MCCANN; Gopala Raghavendra Cary RAO; Fulton Robert Raleigh WEST; Joseph Peter Carrboro MARSICO
Original assignee: Tekelec Inc
Current assignee: Tekelec Global Inc
Priority date: 2000-01-21
Filing date: 2001-01-12
Publication date: 2007-02-15
Anticipated expiration: 2021-01-13
Also published as: WO2001054444A1; EP1252788B1; ATE336149T1; AU2001227879A1; DE60122109D1; WO2001054444B1; EP1252788A1

Description

Technischer Bereich
Die vorliegende Erfindung bezieht sich auf das Routing bzw. Leitweglenken von Signalisierungsnachrichten in einem Kommunikationsnetzwerk, und speziell auf Verfahren und Systeme zum Verarbeiten und Routing von Signalisierungsnachrichten, welche mit portierten Teilnehmern in einem drahtlosen Kommunikationsnetzwerk verbunden sind.
Stand der Technik
Innerhalb der globalen drahtlosen Telekommunikationsindustrie teilt sich der aktuelle Trend in der Netzwerktechnologie auf zwischen dem globalen System für mobile Kommunikation (GSM) und den auf ANSI-41 basierenden Architekturen. In vielen Gesichtspunkten sind GSM- und ANSI-41-basierte Netzwerke sehr ähnlich, wobei sich die primären Unterschiede zwischen den zwei Technologien einfach auf die benutzten Protokolle beziehen, um zwischen den verschiedenen Netzwerk-Entitäten zu kommunizieren, und auf die Betriebsfrequenzen der Kommunikationshandapparate selbst. Deshalb werden der Klarheit wegen die Diskussionen der gegenwärtigen Erfindung nachfolgend auf Implementierungen des GSM-Netzwerktyps begrenzt. Es sollte jedoch gewürdigt werden, dass die vorliegende Erfindung in ähnlicher Weise in einem ANSI-41-, einem persönlichen Kommunikationsservice- (PCS-) oder in einem Netzwerk ähnlichen Typs praktiziert werden kann.
In der europäischen Patentanmeldung EP 0 944 276 wird ein Verfahren zum Portieren einer mobilen Teilnehmernummer eines Funkservice-Providers zu einem anderen veröffentlicht. Ein Verfahren zum Verarbeiten von Nachrichten in einem mobilen Kommunikationsnetzwerk wird veröffentlicht, welches eine Nachricht mit einer Kennung der angerufenen Partei empfängt, die Nachricht analysiert, um festzustellen, ob eine Verarbeitung der Nummerübertragbarkeit erforderlich ist, und falls diese erforderlich ist, dass ein Suchlauf in einer Datenbank in dem empfangenden Netzwerk und das Weiterleiten der Nachricht zu einem anderen Netzwerk durchgeführt wird. Entsprechend dieser europäischen Patentanmeldung ist es erforderlich, dass ein Eintrag in dem gebenden System HLR (Heimatregister) modifiziert werden muss, um die Anrufe in geeigneter Weise für austretende Teilnehmer leitwegzulenken bzw. zu routen. Eine derartige Modifikation bedeutet, dass das gebende HLR für jeden Anruf kontaktiert werden muss, ungeachtet ob der Teilnehmer herein portiert oder hinaus portiert wird, wodurch der Signalisierungsverkehr erhöht wird.
Im US-Patent 5,878,347 werden Verfahrensschritte, wie oben mit Bezug auf EP 0 944 276 erwähnt, veröffentlicht, und zusätzlich wird ein virtuelles HLR dargestellt, welches nicht den ursprünglichen Punktcode in Nachrichten ändert, welche an das HLR für herein portierte oder hinaus portierte Teilnehmer gesendet werden. Dies bedeutet, dass der OPC (Ursprungspunktcode) in der Nachricht durch das virtuelle HLFR zurück geroutet und nicht verändert wird. Dies kann signifikante Netzwerk-Managementprobleme auslösen, falls das Ziel-HLR einen Fehler begeht.
In der internationalen Patentanmeldung WO 99/11087 wird ein Verfahren und ein System zum Verarbeiten von Anrufen für ein Kommunikationsgerät mit einer Teilnehmernummer veröffentlicht, welche von einem ersten Operator zu einem zweiten Operator portiert bzw. befördert wird, welches speziell für die Anwendung in Systemen für mobile Kommunikation geeignet ist. In der internationalen Patentveröffentlichung ist eine spezielle Speichervorrichtung erforderlich, um die Anrufe für eingehende und ausgehende Teilnehmer zu verarbeiten, welches auf Abfragenachrichten antwortet. Die spezielle Speichervorrichtung sendet ein Signal an das anfragende MSC (mobile Schaltzentrum) zurück, um einen Anruf zu vervollständigen, was den Signalisierungsverkehr in dem Netzwerk erhöht und spezielle Stand-alone-Speichervorrichtungen erfordert.
Eine typische GSM-Netzwerk-Architektur wird in 1 dargestellt. Wie in 1 gezeigt wird, beinhaltet das typische GSM-Netzwerk, im Allgemeinen durch die Ziffer 100 angezeigt, eine Anzahl von Funktionsbauelementen oder Knoten, welche in geeigneter Weise miteinander verbunden sind, um so den gewünschten Gesamtnetzwerkdienst zu erhalten. Diese Netzwerkknoten beinhalten ein erstes Mobilschaltzentrum 110, ein Gateway-Mobilschaltzentrum 112, ein erstes Heimatregister (HLR) 114, ein zweites Heimatregister 116, ein Besucherregister (VLR) 118 und ein zweites MSC 120. Kurzum, ein HLR ist eine Datenbank, welche benutzt wird, um Teilnehmerinformation für alle Kunden innerhalb der Heimat-Service-Umgebung des GSM-Service-Providers zu speichern. Funktionsmäßig ist ein HLR über ein Signalisierungsnetzwerk mit anderen Service-Umgebungen derart verbunden, dass Teilnehmerinformation von geographisch unterschiedlichen Netzwerken effizient gemeinsam genutzt werden kann, eine Charakteristik, welche das nahtlose Roaming bzw. den Rufbereichswechsel zwischen den Netzen erleichtert. Ähnlich einem HLR-Knoten ist ein VLR-Knoten auch eine Datenbank, welche Teilnehmerinformation enthält. Jedoch wird ein VLR speziell benutzt, um Information zu speichern, welche sich auf Teilnehmer bezieht, welche nicht in ihrer Heimat-Service-Umgebung sind. Spezieller ausgedrückt, ein VLR ist ein Ort, an dem Daten, die auf den Rufbereichswechsel bezogen sind, für einen Kunden gespeichert werden, wenn der Kunde sein Handgerät außerhalb seiner zugewiesenen Heimat-Service-Umgebung aktiviert.
Wiederum können die oben beschriebenen Netzwerkelemente (HLR und VLR) im Wesentlichen als Datenbanken oder Datenbank-Verarbeitungsknoten betrachtet werden. Im Gegensatz zu diesen Datenbankknoten werden MSCs und GMSCs im Allgemeinen als Netzwerkschaltelemente identifiziert. Neben ihren vielen Funktionen sind MSCs und GMSCs verantwortlich, um zu bestimmen, welche Zellseite von einem Anruf Besitz ergreifen wird. Eine derartige Freihandsteuerung wird durch eine Kommunikationsverbindung zwischen einem MSC und einem dazugehörigen Basisstationssteuergerät-(BSC-)/Basisübertragungsstations-(BTS-)Paar (nicht gezeigt) erleichtert. Ein GMSC-Knoten hat die hinzugefügte Aufgabe, eine Verbindung zu einem oder mehreren HLR-Knoten zu liefern; auf der anderen Seite ist die Funktionalität zwischen dem MSC und dem GMSC sehr ähnlich.
Wie allgemein in 1 dargestellt wird, ist das GMSC 112 über Signalisierungsverbindungen mit zwei HLR-Datenbankknoten 114 und 116, wie oben beschrieben, gekoppelt, und demzufolge wird jeder Signalisierungsnachrichtenzugriff auf diese Datenbankknoten durch das GMSC 112 gesteuert und verwaltet. Von spezieller Relevanz für die vorliegende Erfindung sind die Signalisierungsgesichtspunkte des GSM-Netzwerkes, die oben beschrieben wurden, speziell jene Aspekte, welche mit den Signalisierungs-Interaktionen zwischen HLR, VLR und den Knoten vom MSC- oder GMSC-Typ assoziiert sind. Eine detailliertere Erklärung des Betriebes des HLR, VLR und GMSC wird nachfolgend geliefert.
Innerhalb eines GSM-Funkkommunikationsnetzwerkes wird jedem Mobiltelefon-Handapparat eine einzigartige Identifikationsnummer, welche als eine internationale mobile Teilnehmerkennung (IMSI-)Identifikationsnummer bekannt ist, zugeordnet. Im Falle der europäischen GSM-Netzwerk-Implementierungen ist der IMSI-Code typischerweise mit einem speziellen Telefonhandapparat verbunden. Bei derartigen Netzwerken kann jeder Nutzer einer oder mehreren Mobiltelefon-integrierten Dienst-Digital-Netzwerk-(MSISDN-)Nummern zugeordnet sein. In der Funktelekommunikationsindustrie sind die MSISDN-Nummern analog zu den 10-stelligen Telefonnummern in einem herkömmlichen nordamerikanischen Telefonnetzwerk. Die Tatsache, dass viele MSISDN-Nummern mit einer einzelnen IMSI-Nummer verbunden sein können, zeigt an, dass mehr als eine MSISDN-Nummer zugeordnet und benutzt werden kann, um einen einzelnen Mobiltelefon-Handapparat zu erreichen. Es sollte gewürdigt werden, dass in dieser Veröffentlichung der Term "Mobile Identifikationsnummer" (MIN) im Allgemeinen benutzt wird, um sich auf IMSI-, MSISDN-, Mobile Globale-, ANSI-41-Mobil-Identifikationsnummern (MIN) und Mobile Verzeichnisnummern (MDN) zu beziehen und auf andere Identifikationsnummern, welche mit Teilnehmern oder Diensten in einem Funkkommunikationsnetzwerk verbunden sind.
Auf jeden Fall wird eine MSISDN-Nummer gewählt, wann immer ein Nutzer mit einem speziellen Mobiltelefon-Handapparat zu kommunizieren wünscht. Wie in 1 aufgezeigt wird, bestimmt ein GMSC 112, indem er einen Teil der gewählten MSISDN-Nummer analysiert, das spezielle HLR, welches die Routinginformation, welche mit dem angerufenen Mobiltelefon verbunden ist, speichert. Durch das Wiedergewinnen und Nutzen derartiger Routinginformation ist das GSM-Netzwerk in der Lage, das gerufene Mobiltelefon in Antwort auf einen Anrufversuch zu lokalisieren, so dass eine Rufverbindung zwischen der anrufenden Partei und dem gerufenen Mobiltelefon erstellt werden kann. Es sollte auch gewürdigt werden, dass, abhängig von der Art des Anrufes oder des Signalisierungsereignisses, ein GMSC einen HLR-Suchlauf, basierend auf entweder der IMSI- oder der MSISDN-Nummer, welche mit der gerufenen oder der anrufenden Partei verbunden ist, analysieren und leiten kann.
In dem speziellen Beispiel, welches in 1 gegeben wird, initiiert ein MSC 110 eine Anfangsadressnachricht (IAM) (Nachricht 1) eines ISDN-Benutzerteils (ISUP) in einem Versuch, einen Anruf zu erstellen, welcher von einem mobilen Teilnehmer stammt, welcher durch den MSC 110 bedient wird. Fachleute von mobilen Kommunikationsnetzwerken werden schätzen, dass eine ISUP-IAM-Nachricht eine von vielen Signalisierungsnachrichten ist, welche in einem Signalisierungssystem-7-(SS7-)basierten Signalisierungsnetzwerk angewendet werden, um das Erstellen eines Telefonanrufs zu erleichtern. Eine detaillierte Diskussion von SS7-Signalisierungs-Nachrichtenarten und die damit verbundene Funktion kann in Signaling System #7 von Travis Russell, McGraw-Hill Publishing 1998 gefunden werden. Zusätzlich kann eine detaillierte Diskussion von SS7-bezogener Signalisierung innerhalb eines GSM-Netzwerkes in The GSM System for Mobile Communications von Michel Mouly und Marie-Bernadette Pautet, Cell & Sys 1992 gefunden werden.
Kehrt man zu einer Diskussion der 1 zurück, so wird gewürdigt werden, dass die ISUP-IAM-Nachricht (1) von dem GMSC 112 empfangen wird, welcher umgekehrt die Nachricht analysiert. Spezieller ausgedrückt, das GMSC 112 überprüft den MSISDN-Wert, welcher mit der angerufenen Partei verbunden ist, ebenso wie die Service-Anzeigeinformation, welche in der Nachricht enthalten ist. In 2 wird eine vereinfachte Routing-Datenbanktabelle 150 gezeigt, welche in dem GMSC 112 enthalten ist. Diese Abtast-GMSC-Routing-Datenbanktabelle 150 ist basierend auf einem Block oder Bereich der MSISDN-Nummern 152 verschlüsselt oder indiziert. Mit jedem Block oder Bereich der MSISDN-Nummern ist eine Adresse oder eine Kennung 154 eines zugeordneten HLR-Knotens zugeordnet.
Kehrt man zu 1 zurück, führt das GMSC 112 einen Suchlauf in der HLR-Routing-Tabelle 150 durch, bestimmt, dass diese Nachricht an das HLR 114 geliefert werden sollte, und formuliert nachfolgend eine Sende-Routing-Informations-(SRI-)Anforderungsnachricht 2. Beim Empfangen der SRI-Nachricht 2 untersucht das HLR 114 die Nachricht und, in einem Fall, bestimmt es, dass nicht genug Information verfügbar ist, um die geeignete Routing-Adresse zu bestimmen, welche benötigt wird, um die Original-ISUP-IAM-Nachricht 1 an ihr Ziel zu liefern. Jedoch ist in einem derartigen Szenario das HLR 114 in der Lage, die Routing-Adresse eines VLR 118 zu bestimmen, welches die Information enthält, welche notwendig ist, das Routing der ISUP-IAM-Nachricht 1 fortzusetzen. Diese Berechnung wird über einen Suchlauf in einer internen Routing-Datenbank 156 durchgeführt, wie dies in 2 gezeigt wird. Die vereinfachte Abtast-HLR-Routing-Datenkbank 156 wird durch die MSISDN-Nummer 158 verschlüsselt oder indiziert und beinhaltet einen Zeiger oder eine Adresse 160 für einen VLR-Knoten, welcher aktuell jeden MSISDN-Eintrag bedient. Folglich formuliert das HLR 114 eine Liefer-Routing-Nummer-(PRN-)Nachricht 3 und adressiert diese Nachricht an das VLR 118. Das VLR 118 führt beim Empfang der PRN-Nachricht 3 einen Datenbanksuchlauf, basierend auf der angerufenen Partei MSISDN, durch und schickt nachfolgend eine Mobiltelefon-Roaming-Nummer (MSRN) zurück, welche benutzt wird, um das MSC, welches aktuell die angerufene Partei bedient, zu identifizieren. Eine vereinfachte Abtast-VLR-Datenbank 162 wird in 2 gezeigt. Die VLR-Datenbank 162 wird durch die MSISDN-Nummer 164 verschlüsselt oder indiziert und beinhaltet einen MSRN 166, welcher mit jedem MSISDN-Eintrag verbunden ist. Kehrt man zu 1 zurück, so wird der MSRN-Wert, welcher von der VLR-Datenbank 162 extrahiert wurde, in einem PRN-Ergebnis oder einer Bestätigungs-(PRN-Ack-)Nachricht eingeschlossen, welche durch das VLR 118 formuliert wird, und an das fragende HLR 114 zurückgesandt. Bei Empfang der PRN-Ack-Nachricht 4 formuliert das HLR 114 eine SRI-Bestätigungs-(SRI Ack-)Nachricht 5, welche als eine Antwort auf die Original-SRI-Nachricht 2 dient. Die SRI Ack-Nachricht 5 beinhaltet den MSRN, welcher durch das VLR 118 geliefert wird, und sie wird an den Erzeuger der SRI-Nachricht 2 geliefert, das GMSC 112. DAS GMSC 112 empfängt die SRI Ack-Nachricht 5 und benutzt den MSRN-Wert, welcher darin enthalten ist, um das Routing-Etikett bzw. die Routing-Kennung der Original-ISUP-IAM-Nachricht 1 zu modifizieren. Eine modifizierte ISUP-IAM-Nachricht 6 wird nachfolgend hergestellt, welche an das MSC, welches aktuell die angerufene Partei bedient, adressiert wird.
Wiederum wird gewürdigt werden, dass das oben präsentierte Beispiel ein einfaches Szenario eines Erstellens eines Anrufes ist, welches in erster Linie dazu dient, den Grundaufbau eines Anrufes und die damit verbundenen Nachrichtenflussprozesse darzustellen. Wesentlich kompliziertere Ruferstellungsszenarien können in Netzwerk-Implementierungen in der Realität auftreten. Auch beziehen sich nicht alle Signalisierungsnachrichten, welche durch ein GMSC empfangen werden, notwendigerweise direkt auf Vorgänge zum Erstellen und zum Abbauen eines Anrufs und werden deshalb nicht notwendigerweise den gleichen Verarbeitungsschritten folgen, wie sie in den oben beschriebenen ISUP-IAM-Anruferstellungsbeispiel, das oben präsentiert wurde, beschrieben wurden.
In dem Abtastszenario, welches in 1 dargestellt wird, ist jedes HLR 114 und HLR 116 so konfiguriert, dass es einem vorher festgelegten Block von Teilnehmer-MSISDN-Nummern dient. Im Allgemeinen wird eine spezielle Reihe von Block- oder MSISDN- (oder IMSI-)Nummern jedem HLR in einem Netzwerk eines Service-Providers zugeordnet, wie dies weiter durch die Routing-Tabelle 150 in 2 gezeigt wird. Wieder sollte gewürdigt werden, dass die HLR-Datenbank 156- und GMSC-Routingtabelle-150-Strukturen, welche in 2 gezeigt werden, lediglich erläuternd für das Hochpegel-Informationsspeicherkonzept sind und nicht die aktuellen Datenstrukturen darstellen sollen, welche typischerweise in derartigen Netzwerkknoten implementiert sein würden. In vielen Fällen sind die Service-Provider nicht in der Lage, diese Blöcke von zugeordneten Nummern innerhalb eines gegebenen HLRs zu ändern, da Routing-Begrenzungen der GMSC, welche mit der HLR-Einheit verbunden ist, vorhanden sind. Folglicherweise haben Service-Provider keine Möglichkeit, ihre MSISDN-Nummerbasis über viele HLRs dynamisch rückzuzuordnen, um so effizienter existierende HLR-Quellen (d.h. Aufteilen der Belastung) zu nutzen. Es sollte beachtet werden, dass diese Begrenzung typischerweise das Ergebnis der Routing-Tabellenrestriktionen in den MSCs ist und im Allgemeinen nicht das von Datenbankspeicher-Restriktionen in den HLRs. D.h., obwohl die HLRs im Allgemeinen so bestückt sein können, dass sie Teilnehmer-Dateneintäge für jede IMSI- oder MSISDN-Nummern enthalten können, sind die GMSCs typischerweise nur in der Lage, Nachrichten basierend auf einem IMSI- oder MSISDN-Block, in welchen die IMSI- oder MSISDN-Nummer der Nachricht fällt, wegzulenken. Die IMSI- oder MSISDN-Blöcke weisen einen sequenziellen Bereich von IMSI- oder MSISDN-Nummern auf. Daher kommt es, dass die begrenzte Routing-Fähigkeit eines GMSC das Problem verursacht, und typischerweise nicht die HLR-Knoten.
Beispielsweise wird in 1 aller Verkehr, welcher sich auf die Anrufe bezieht, die mit einer MSISDN-Nummer zwischen 9199670000 und 9199679999 verbunden sind, zu dem HLR A 114 durch den angeschlossenen GMSC 112 geroutet. Wenn der Service-Provider beginnt, mehr und mehr Kunden zu akquirieren (d.h. Zuordnen von mehr und mehr der MSISDN-Nummern in dem zugeordneten Block oder den Reihen 9199670000 bis 9199679999), wird sich der Verkehr oder die erwartete Überlastung am HLR-A-114-Knoten entsprechend erhöhen.
Man betrachte nun, dass ein Service-Provider, welcher das HLR A 114 besitzt, dargestellt in 1, so viele neue Kunden akquiriert hat, dass entschieden wird, in ein zusätzliches HLR B 116 zu investieren. Zur Zeit der Implementierung ist das HLR B 116 mit dem MSISDN-Nummernblock 9194690000-9194699999 bestückt. Das HLR B 116 ist mit dem benachbarten GMSC 112 verbunden und wird so aktiviert, um jegliche Anrufe, welche dem vorprogrammierten MSISDN-Block entsprechen, zu bedienen.
Der größte Nachteil des bereichsbasierten Routing, welches mit derartigen vielen HLR-Konfigurationen verbunden ist, kann nun besser eingeschätzt werden. Trotz des Hinzufügens der neuen HLR-Ressourcen-Kapazität, welche durch die Einheit B dargestellt wird, muss dennoch der gesamte Anrufsverkehr, welcher mit den MSISDN-Nummern 9199670000-9199679999 assoziiert ist, noch durch ein einzelnes HLR, HLR A 114, bearbeitet werden. Selbst wenn der Service-Provider keine Kunden innerhalb des MSISDN-919469000-9194699999-Nummernbereiches besitzt, ist es für den Service-Provider nicht möglich, dynamisch den "voll zugeordneten" 9199670000-9199679999-MSISDN-Nummernblock innerhalb der unbenutzten HLR-B-116-Einheit zurückzuzuordnen oder zurückzuverteilen. Damit ist es möglich, dass ein Netzwerk-Service-Provider gezwungen wird, in einer Situation zu arbeiten, wo sich der Verkehr zum HLR A 114 sehr stark staut, während die HLR-B-116-Quelle völlig ungenutzt ist. Dies kann zu einem weniger effizienten Gebrauch von installierten Quellen führen, da es effizienter wäre, einen Lastausgleich oder ein Aufteilen des Verkehrs gleichmäßiger auf die beiden HLR-Einheiten aufzuteilen.
Es sollte gewürdigt werden, dass es zusätzlich zu den Bedenken über das Lastaufteilen ähnliche Ansätze und ähnliche Notwendigkeiten gibt, welche auftreten, wenn man das Befördern von Teilnehmern von einem Service-Provider zu einem anderen Service-Provider betrachtet, welches auf andere Weise als Nummernübertragbarkeit (NP) bekannt ist. Noch einmal, eines der zentralen Probleme, welchem ein Netzwerk-Operator in einem derartigen Szenario gegenübersteht, ist die Fähigkeit, Teilnehmerinformation unter vielen HLR-Knoten frei zu verteilen. Mit speziellem Bezug auf den Fall der mobilen Nummernübertragbarkeit wird gewürdigt werden, dass portierte mobile Teilnehmer entweder in ein Netzwerk des Operators von einem Wettbewerbsträger „hinein" portiert werden können oder aus einem Netzwerk eines Operators zu einem Wettbewerbsträger „heraus" portiert werden können. Man betrachte das vereinfachte Netzwerk, welches in 1 wiedergegeben wird, mit Bezug auf ein derartiges Szenario des "Hineinportierens". D.h., der Besitzer des Netzwerkes 100 akquiriert einen neuen mobilen Teilnehmer, welcher früher ein Kunde eines Wettbewerbsnetzwerks-Operators war. Man nehme des Beispiels wegen an, dass dieser neue mobile Teilnehmer eine MSISDN-Nummer von (919) 345-7015 besitzt und wünscht, die gleiche MSISDN-Nummer in dem Netzwerk des neuen Operators zu behalten. Durch ein Versäumnis würde diese neue Information des Teilnehmers im HLR A gespeichert und gepflegt werden, wie dies allgemein durch die GMSC-Routing-Tabelle 150 angezeigt wird, welche in 2 gezeigt wird. Folglich, wenn eine Signalisierungsnachricht, welche mit dem neuen mobilen Teilnehmer verbunden ist, welche einen HLR-Zugriff erfordert, durch das GMSC 112 empfangen wird, wird ein Suchlauf in der GMSC-Routing-Tabelle 150 durchgeführt, und die Nachricht wird nachfolgend an das HLR A 114 gelenkt. Es wird wieder gewürdigt werden, dass aufgrund der bereichsbasierten Routing-Tabellenkonfiguration des GMSC 112 eine flexible Zuordnung der herein portierten mobilen Teilnehmer innerhalb der verfügbaren HLR-Quellen signifikant verschlechtert wird.
Mit Bezug auf die "hinaus portierten" Teilnehmer oder mobilen Teilnehmer, welche aus dem Netzwerk eines Service-Providers hinausbefördert wurden, existieren die gleichen flexiblen HLR-Zuordnungseingrenzungen aufgrund der bereichsbasierten Routing-Tabellenkonfiguration im GMSC 112. Außerdem, im Falle einer Signalisierungsnachricht, welche mit einem mobilen Teilnehmer verbunden ist, welcher aus dem Netzwerk eines Service- Providers hinaus portiert wurde, wird gewürdigt werden, dass die Verarbeitung der Signalisierungsnachricht durch einen der HLR-Knoten des Operators nicht länger notwendig ist. D.h., da der Teilnehmer aus dem Netzwerk des Service-Providers hinaus portiert wurde, wird das Netzwerk des Service-Providers nicht länger als die "Heimat" des mobilen Teilnehmers betrachtet, und folglich müssen die Heimatregister (HLRs) des Service-Providers nicht länger Information speichern, welche mit dem mobilen Teilnehmer verbunden ist. Jedoch, wie dies generell in 1 und 2 angezeigt wird, wird trotz des Eliminierens der hinaus portierten Information des Teilnehmers aus den HLR-Ressourcen des Service-Providers das GMSC 112 fortfahren, die Signalisierungsnachrichten, welche mit dem mobilen Teilnehmer verbunden sind, zu einem der HLR-Knoten des Service-Providers zu lenken.
Man betrachte den Fall eines hinaustransportierten mobilen Teilnehmers mit einer MSISDN-Nummer von (919) 967-2000. Wenn das GMSC 112 eine Signalisierungsnachricht empfängt, welche mit dem hinaus portierten Teilnehmer zusammenhängt, wird ein Suchlauf in einer Routing-Tabelle 150 durchgeführt, und die Signalisierungsnachricht wird nachfolgend zu dem HLR A 114 gelenkt, trotz der Tatsache, dass Information für diesen mobilen Teilnehmer nicht länger im HLR A gepflegt wird. Ein derartiges unnötiges Routing stellt ein ineffizientes Gebrauchen sowohl der Routing- und der HLR-Datenbank-Quellen dar.
Deshalb ist ein System und ein Verfahren notwendig, effizient das Zurücklenken von Signalisierungsnachrichten auszuführen, welche sowohl herein portierten als auch heraus portierten mobilen Teilnehmern innerhalb von HLR-, Geräte-Identitätsregister-(EIR-), Authentitätszentrum-(AuC-), Kurznachricht-Service-Zentrum-(SMSC-) und anderen ähnlichen Typen von Signalisierungsdatenbank-Knoten zugeordnet sind, wo das Routing von Nachrichten in einer derartigen Weise auftritt, dass eine Normgerechtigkeit mit existierenden Signalisierungsprotokollen des industriellen Standard-Netzwerkmanagements bewahrt wird.
Offenbarung der Erfindung
Die vorliegende Erfindung beinhaltet ein Verfahren nach Anspruch 1 oder 13, ein Routing-Element nach den Ansprüchen 16 oder 19 und einen Signalübergabepunkt entsprechend Anspruch 23.
Kurze Beschreibung der Zeichnungen
1 ist ein Diagramm, welches eine mobile Telekommunikationsnetzwerk-Architektur nach dem Stand der Technik und damit verbundene Netzwerkelemente darstellt.
2 ist ein Diagramm, welches eine Abtast-Routing-Information darstellt, welche von mehreren mobilen Telekommunikationsnetzwerk-Elementen gepflegt wird.
3 ist eine schematische Zeichnung eines Signalübergabepunkt-(STP-)Schaltknotens entsprechend dem Stand der Technik.
4 ist eine Zeichnung, welche eine interne Architektur eines Portier-Steuer-Routing-(PCR-)Knotens der vorliegenden Erfindung zeigt, wobei der Nachrichtenfluss, welcher mit einem auf Ausnahmen basierten Routing-Datenbank-Suchlauf verbunden ist, dargestellt wird.
5a ist eine Tabelle, welche eine GSM-Mobilnummer-Übertragbarkeit (G-Port^TM) einer auf Ausnahmen basierten Datentabellenstruktur darstellt.
5b ist eine Tabelle, welche eine bereichsbasierte Datentabellenstruktur darstellt.
6 ist ein Diagramm, welches eine interne Architektur eines PCR-Knotens der vorliegenden Erfindung darstellt, wobei der Nachrichtenfluss dargestellt wird, welcher mit einem bereichsbasierten Standard-Routing-Datenbank-Suchlauf verbunden ist.
7a–7c sind ein Prozessflussdiagramm, welches die Verarbeitungsschritte der Signalisierungsnachricht innerhalb eines PCR-Knotens der vorliegenden Erfindung darstellt.
8 ist ein Netzwerkdiagramm, welches Signalisierungs-Nachrichtenflüsse darstellt, welche mit dem Aufbau eines Anrufes zu einem mobilen Teilnehmer verbunden sind, welcher aus dem Netzwerk eines Service-Providers hinaus portiert wurde.
9 ist eine Tabelle, welche Parameterwerte in einer SendeRouting-Informations-(SRI-)Nachricht und eine SRI-Bestätigungs-(SRI Ack-)Nachricht darstellt, welche mit dem Aufbau eines Anrufs zu einem mobilen Teilnehmer verbunden ist, welcher aus dem Netzwerk eines Service-Providers hinaus portiert wurde.
10 ist ein Netzwerkdiagramm, welches Signalisierungs-Nachrichtenflüsse darstellt, welche mit dem Aufbau eines Anrufs zu einem mobilen Teilnehmer verbunden sind, welcher aus dem Netzwerk eines Service-Providers hinaus portiert wurde.
11 ist eine Tabelle, welche Parameterwerte in einer originalen SRI-Nachricht und einer modifizierten SRI-Nachricht darstellt, welche mit dem Aufbau eines Anrufs zu einem mobilen Teilnehmer verbunden ist, welcher nicht aus dem Netzwerk eines Service-Providers portiert wurde.
12 ist ein Netzwerkdiagramm, welches Signalisierungs-Nachrichtenflüsse darstellt, welche mit einer Kurzmitteilungsservice-(SMS-)Kommunikation zu einem mobilen Teilnehmer verbunden sind, welcher aus dem Netzwerk eines Service-Providers portiert wurde.
13 ist eine Tabelle, welche Parameterwerte in einer Original-SRI-SMS-Nachricht und einer modifizierten SRI-SMS-Nachricht darstellt, welche mit einer SMS-Kommunikation zu einem mobilen Teilnehmer verbunden ist, der aus dem Netzwerk eines Service-Providers heraus portiert wurde.
14 ist ein Netzwerkdiagramm, welches Signalisierungs-Nachrichtenflüsse darstellt, welche mit einer Kurzmitteilungsservice-(SMS-)Kommunikation zu einem mobilen Teilnehmer verbunden sind, welcher nicht aus dem Netzwerk eines Service-Providers portiert wird.
15 ist eine Tabelle, welche Parameterwerte in einer originalen SRI-SMS-Nachricht und eine modifizierte SRI-SMS-Nachricht darstellt, welche mit einer SMS-Kommunikation zu einem mobilen Teilnehmer verbunden ist, welcher nicht aus einem Netzwerk des Service-Providers portiert wurde.
Detaillierte Beschreibung der Erfindung
Hier werden mehrere Ausführungsformen der vorliegenden Erfindung veröffentlicht, von denen alle ein Netzwerkelement beinhalten, welches Funktionen ähnlich denen eines Telekommunikationsnetzwerkpaket-Routing-Schalters durchführt, wie z.B. einem Signalübertragungspunkt-(STP-) oder einem Signalisierungs-Gateway-(SG-)Routing-Knoten. Wie hier benutzt, bezieht sich der Term "Signalisierungs-Gateway" auf einen Paket-Routing-Knoten, welcher in der Lage ist, Anruf-Signalisierungsnachrichten zwischen Knoten unterschiedlicher Protokolle zu routen, wie z.B. SS7-Knoten und IP-Knoten. Jede der Ausführungsformen, welche nachfolgend beschrieben werden, wendet eine interne Architektur an, welche ähnlich der von Hochleistungs-STP- und -SG-Produkten ist, welche durch den Anmelder der vorliegenden Erfindung jeweils als Eagle^® STP und IP⁷ Secure Gateway^TM vermarktet werden. Ein Blockdiagramm, welches allgemein die grundinterne Struktur des IP⁷-Secure-Gateway^TM-Produktes darstellt, wird in 3 gezeigt. Eine detaillierte Beschreibung des IP⁷ Secure Gateway^TM kann in der Tekelec-Veröffentlichung PN/909-0767-01, Rev. B, August 1999, mit dem Titel Feature Notice IP⁷ Secure Gateway^TM Release 1.0, veröffentlicht von Tekelec, gefunden werden. In ähnlicher Weise kann eine detaillierte Beschreibung des Eagle^® STP in dem Eagle^® Feature Guide PN/910-1225-01, Rev. B, Januar 1998, gefunden werden. Wie in der oben als Referenz aufgeführten Feature Notice beschrieben wird, beinhaltet ein IP⁷ Secure Gateway^TM 250 die folgenden Untersysteme: ein Pflege- und Verwaltungssubsystem (MAS) 252, ein Kommunikationssubsystem 154 und ein Applikationssubsystem 256. Das MAS 252 liefert Kommunikationen zur Pflege, das Programmladen, Peripherdienste, das Alarmverarbeiten und Systemscheiben. Das Kommunikationssubsystem 254 beinhaltet einen Interprozessor-Nachrichtentransport-(IMT-)Bus, welcher der Hauptkommunikationsbus unter allen Subsystemen in dem IP⁷ Secure Gateway^TM 250 ist. Dieses Hochgeschwindigkeits-Kommunikationssystem funktioniert wie zwei gegen den Uhrzeigersinn drehende, serielle 125-Mbps-Busse.
Das Anwendungssubsystem 256 beinhaltet Anwendungskarten, welche in der Lage sind, mit den anderen Karten über die IMT-Busse zu kommunizieren. Zahlreiche Arten von Anwendungskarten können in dem SG 250 beinhaltet sein, wobei eingeschlossen, jedoch nicht darauf begrenzt sind: ein Verbindungsinterface-Modul (LIM) 258, welches SS7-Verbindungen und X.25-Verbindungen liefert, ein Datenkommunikationsmodul (DCM) 260, welches ein TCP/IP-Interface für eine externe Überwachungsvorrichtung über Ethernet liefert, und ein Anwendungsservice-Modul (ASM) 262, welches eine globale Titelumformung liefert, Gateway-Screening bzw. Netzübergangs-Anrufaussortierung und andere Dienste. Ein Datenbank-Service-Modul (DSM) 264 kann auch vorgesehen sein, um den Dienst der Nummernübertragbarkeit zu unterstützen. Es sollte gewürdigt werden, dass zusätzlich zu herkömmlichen SS7-LIM-Karten eine oder mehrere DCM-Karten in einer ähnlichen Weise angewandt werden können, um für den Transport von Internetprotokoll-(IP-)gekapselten SS7-Nachrichten über ein IP-Netzwerk vorgesehen zu sein, wie dies in der Veröffentlichung Feature Notice IP⁷ Secure Gateway^TM Release 1.0 beschrieben wurde, auf die oben Bezug genommen wurde. Die speziellen funktionellen Komponenten eines IP⁷ Secure Gateway^TM für das Senden und Empfangen von Anwendungsteil-Transaktionsfähigkeits-(TCAP-)Nachrichten über ein Internetprotokoll-(IP-)Netzwerk werden in der allgemein zugeteilten, angehängten internationalen Patentveröffentlichung Nr. WO 00/35155 beschrieben. In ähnlicher Weise werden die funktionellen Komponenten eines IP⁷ Secure Gateway^TM für das Senden und Empfangen von Benutzerteil-ISDN-(ISUP-)Nachrichten über ein Internetprotokoll-(IP-)Netzwerk in der im Allgemeinen zugeteilten, angehängten internationalen Patentveröffentlichung Nr. WO 00/35156 beschrieben.
Interne Architektur des Portier-Steuer-Routing-Knotens
In 4 wird eine Ausführungsform eines Portier-Steuer-Routing-(PCR-)Knotens der vorliegenden Erfindung dargestellt, welche im Allgemeinen durch die Nummer 302 angezeigt wird. Der PCR 302 beinhaltet einen Interprozessor-Nachrichtentransport-(IMT-)Bus 304, welcher der Hauptkommunikationsbus unter allen internen Subsystemen innerhalb des Schalt- oder Routing-Knotens ist. In einer Ausführungsform funktioniert dieses Hochgeschwindigkeits-Kommunikationssystem wie zwei im Gegenuhrzeigersinn drehende, serielle 125-Mpbs-Busse. Mit dem IMT-Bus 304 ist eine Anzahl von verteilten Verarbeitungsmodulen oder -karten kommunikativ gekoppelt, wobei beinhaltet sind: ein Paar von Service- und Verwaltungs-Subsystemprozessoren (MASPs) 306, ein SS7-fähiger Verbindungsinterface-Modul (LIM) 308, ein Kommunikationsmodul (DCM) 330, welcher für ein Internetprotokoll (IP) geeignet ist, und ein G-Port^TM-Service-Modul (GPM) 340. Diese Module sind physikalisch mit dem IMT-Bus 304 so verbunden, dass das Signalisierungs- und andere Arten von Nachrichten zwischen allen aktiven Karten oder Modulen intern gelenkt werden können. Wegen der Einfachheit der Erläuterung sind in 4 nur eine einzelne LIM-, DCM- und GPM-Karte beinhaltet. Es sollte jedoch gewürdigt werden, dass die verteilte Multiprozessor-Architektur des PCR-Knotens 302 den Einsatz von vielen LIM-, DCM-, GPM- und anderen Karten erleichtert, von denen alle simultan an einen IMT-Bus 304 angeschlossen sein können oder mit ihm kommunizieren können.
Das MASP-Paar 306 ist adaptiert, um Service-Kommunikationen, Anfangsprogrammladen, periphere Dienste, Alarmverarbeiten und Systemscheiben zu liefern. Da das MASP-Paar 306 nicht speziell bezüglich einer Diskussion der PCR-Funktionalität relevant ist, wird hier keine detaillierte Diskussion über die Gestaltung und den Betrieb des MASP-Paares 306 gegeben. Für eine umfassende Diskussion zusätzlicher MASP-Operationen und deren Funktionalität können die Tekelec-IP⁷-Secure-Gateway^TM- und Eagle^®-STP-Veröffentlichungen, auf welche oben Bezug genommen wurde, herangezogen werden.
Sieht man sich nun die Funktionalität auf der LIM-Karte an, so ist in der dargestellten Ausführungsform das LIM 308 aus einer Anzahl von Subkomponenten aufgebaut, welche beinhalten, jedoch nicht auf diese begrenzt sind: ein SS7-MTP-Pegel-1-und-2-Schichtprozess 310, ein E/A-Puffer oder eine E/A-Warteschlange 312, ein SS7-MTP-Pegel-3-Schicht-HMDC-Prozess 314 und ein HMDT-Prozess 316. Der MTP-Pegel-1-und-2-Schichtprozess 310 liefert die notwendigen Gegebenheiten, um digitale Daten über ein spezielles physikalisches Medium/physikalisches Interface zu senden und zu empfangen, ebenso wie eine Fehlerdetektierung/-korrektur und eine aufeinander folgende Lieferung aller SS7-Nachrichtenpakete. Die E/A-Warteschlange 312 gestattet das zeitliche Puffern von eingehenden und ausgehenden Signalisierungs-Nachrichtenpaketen. Der MTP-Pegel-3-HMDC-Prozess 314 führt eine Diskriminierungsfunktion durch, wobei effektiv bestimmt wird, ob ein eingehendes SS7-Nachrichtenpaket eine interne Verarbeitung erfordert oder ob es einfach durchzuschalten ist, d.h. zu einem anderen Knoten zu routen bzw. zu lenken ist. In einer Ausführungsform untersucht der HMDC-Prozess 314 einen Service-Anzeige-Oktett-(SIO-)Wert in dem empfangenen Nachrichten paket, um zu bestimmen, ob eine interne Signalisierungs-Verbindungssteuerteil-(SCCP-)Verarbeitung erforderlich ist. Der HMDT-Prozess 316 behandelt das interne Routing der SS7-Nachrichtenpakete, welche eine zusätzliche Verarbeitung vor dem endgültigen Routing erfordern.
Das DCM 330, welches in 4 gezeigt wird, beinhaltet einen Internetprotokoll-(IP-)Niedrigpegel-Protokollprozess-332- und eine E/A-Warteschlange-334-Ausführfunktion, welche analog zu ihren SS7-basierten LIM-Gegenstücken sind, welche oben beschrieben wurden. Es sollte gewürdigt werden, dass ausgehende SS7-Nachrichtenpakete, welche über das DCM 330 gelenkt werden, aus dem PCR-Knoten 302 und in ein Internetprotokoll-(IP-)Netzwerk übertragen werden. Da das SS7-Netzwerk-Nachrichtübertragungsteil-(MTP-)Kommunikationsprotokoll und das IP-Kommunikationsprotokoll nicht von sich aus kompatibel sind, müssen alle SS7-Nachrichtenpakete, welche über ein IP-Netzwerk zu übertragen sind, zuerst in einem IP-Routing-Rahmen vor der Übertragung verkapselt werden. In einer Ausführungsform wird diese IP-Verkapselung durch den IP-Prozess 332 durchgeführt. Wieder ist in einem derartigen Gestaltungsszenario der IP-Prozess 332 das IP-Protokolläquivalent des SS7-MTP-Pegel-1-2-Schichtprozesses 310 des LIM-Moduls 308. Es wird gewürdigt werden, dass die Nachrichtenpakete, welche durch eine DCM-Karte empfangen und übertragen werden, Transportadaptionsschicht-Interface-(TALI-)Protokollnachrichten, ein Sitzungsanfangsprotokoll (SIP), M2UA, SS7-MTP3-Nutzer-Adaptionsschicht (M3UA), SS7 SCCP-Nutzer-Adaptionsschicht (SUA), H.323 oder andere Signalisierungsprotokolle enthalten können, welche über TCP/IP- oder ähnliche IP-basierte Protokolle transportiert werden können. Bevorzugte Paketformate für das Einkapseln verschiedener Arten von SS7-Nachrichten in IP-Paketen werden im Internet Engineering Task Force (IETF) INTERNET DRAFT <draft-benedyk-sigtran-tali-01.txt> mit dem Titel Transport Adapter Layer Interface, 20. Juni 2000, beschrieben, wobei diese Veröffentlichung hier insgesamt als Referenz beigefügt ist. Außerdem wird das TALI-Protokoll auch im Detail in der allgemein zugeteilten, angehängten internationalen Patentveröffentlichung Nr. WO 00/76134 beschrieben, wobei diese Veröffentlichung hier in ihrer Gesamtheit als Referenz beigefügt ist. Wieder wird gewürdigt werden, dass die Konzepte, welche in dieser Veröffentlichung beschrieben werden, nicht von dem oben als Bezug aufgeführten TALI-Signalisierungsprotokoll abhängig sind. Es können andere funktionell ähnliche Signalisierungsprotokolle innerhalb des Umfangs der vorliegenden Erfindung angewendet werden, wobei z.B. das IETF SUA/M3UA-Protokoll beinhaltet ist.
Noch einmal, die Beschreibung der LIM- und DCM-Subkomponenten, welche hier vorgesehen sind, ist auf jene Subkomponenten begrenzt, welche für die Abtastimplementierszenarien, welche innerhalb dieser Veröffentlichung erläutert werden, relevant sind. Für eine umfassende Diskussion der LIM- und DCM-Operationen und deren Funktionalität können die oben als Referenz aufgeführten Tekelec-Veröffentlichungen durchgesehen werden.
Im Allgemeinen liefert eine GPM-Karte die Steuer- und Datenbankprozesse, welche nötig sind, die erforderlichen Netzwerkadressumsetzungen durchzuführen, um das Portieren der SteuerRouting-Funktionalität, welche durch die Ausführungsformen der vorliegenden Erfindung implementiert sind, zu erreichen. Das GPM 340, welches in 4 gezeigt wird, besteht in einem Teil aus einem Signalisierungs-Verbindungssteuerteil-(SCCP-)Submodul 342, welcher ferner ein G-Port^TM-Untersystemsteuergerät beinhaltet, welches als ein Signalisierungsverbindungs-Routing-Steuergerät-(SCRC-)Prozess 344 bekannt ist. Die Zuständigkeiten des SCRC-Prozesses 344 beinhalten, sind jedoch nicht begrenzt auf: das Führen eines eingehenden SS7-Nachrichtenpaketes zu entweder einem G-Port^TM-Datenbankprozess 346 oder einem globalen Titelumsetzungs-(GTT-)Datenbankprozess 348, die Modifikation eines Nachrichtenpaketes, um Routing-Information, welche jeweils durch den G-Port^TM- oder GTT-Datenbankprozess 346 bzw. 348 zurückgeschickt wurde, und das Schaffen eines neuen Nachrichtenpaketes in Antwort auf Information, welche durch den G-Port^TM-Datenbankprozess 346 zurückgeschickt wurde.
Diese Fähigkeit, eine neue Nachricht in Antwort auf Information zu schaffen, welche von der G-Port^TM-Datenbank zurückgeschickt wurde, ist ein spezieller neuer und signifikanter Gesichtspunkt der vorliegenden Erfindung. Die SS7-Nachrichtenpakete, welche den SCRC-Prozess 344 verlassen, werden durch einen HMRT-Prozess 350 empfangen und weiterverarbeitet. Der HMRT-Prozess 350 ist verantwortlich für das externe Routing der SS7-Nachrichtenpakete, welche keine zusätzliche Verarbeitung durch den PCR-Knoten 302 erfordern. D.h., der HMRT-Prozess 350 bestimmt, zu welcher LIM- oder DCM-Karte ein SS7-Nachrichtenpaket für eine nachfolgende Außenübertragung geroutet werden sollte. Es wird auch aus 4 gewürdigt werden, dass in einer Ausführungsform GPM 340 an ein externes Bereitstellungs-Applikationsplattform-(EPAP-)Subsystem 360 über eine Ethernet-Verbindung gekoppelt ist und durch dieses bedient wird. Das EPAP-Subsystem 360 ist für die Verwaltung und den Service der G-Port^TM und GTT-Datenbanken verantwortlich, auf die mit den Prozessen 346 bzw. 348 zugegriffen wird.
G-Port^TM-Service-Modul-Architektur
Wie vorher festgestellt wurde, besteht ein Problem, welches mit dem Lastaufteilen und dem Nummernübertragen zwischen vielen HLR-Knoten verbunden ist, darin, dass herkömmliche MSCs und GMSCs nur zum blockbasierten Adressieren fähig sind. Nachdem dem so ist, wird geschätzt werden, dass eine der vorrangigsten Aufgaben des PCR-Knotens, entsprechend einer Ausführungsform der vorliegenden Erfindung, darin besteht, ein Verfahren zu liefern, mit welchem ein Netzwerk-Operator schnell und leicht Signalisierungsnachrichten, welche mit einer gegebenen angerufenen Partei zusammenhängen, zu einem speziellen Mobildienstknoten (z.B. HLR, VLR, EIR, AuC, SMSC, etc.) lenken kann. Um eine derartige Signalisierungsrückführung zu erleichtern, wendet der PCR-Knoten der vorliegenden Erfindung ein Paar von komplementären Routing-Datenbanken an, welches ein IMSI, MSISDN oder eine Kennung der gerufenen Partei, welche mit einer Signalisierungsnachricht mit der Netzwerkadresse der geeigneten Schaltstelle (STP, SG, MSC, etc.) oder den mobilen Service-Knoten (z.B. HLR; VLR, EIR, AuC, SMSC, etc.) verbunden ist, effektiv abbildet. Die oben beschriebenen Datenbanken werden als die G-Port^TM-Datenbank und die GTT-Datenbank bezeichnet. Mit Bezug auf die Kennung der gerufenen Partei wird gewürdigt werden, dass eine derartige Kennung eine E-mail-Adresse (z.B. jdoe@tekelec.com), einen gleichförmigen Quell-Lokalisierer (z.B. www.tekelec.com), eine Internetprotokoll-(IP-)Adresse (z.B. 101.100.100.100 Anschluss bzw. Port 23) oder einen anderen funktionellen ähnlichen Parameter einschließen könnte, welcher eine gerufene Partei identifiziert. So genannte Parteikennungen können in Nicht-SS7-Signalisierungs-Protokollnachrichten, wie z.B. einer SIP-Nachricht, angewendet werden.
5a und 5b sind Datenbank-Strukturdiagramme, welche dazu dienen, in erster Linie die Schlüssel oder Indizierstrukturen von Abtast-G-Port^TM- und GTT-Datenbanktabellen 370 bzw. 390 zu erläutern. Es ist davon auszugehen, dass die aktuellen G-Port^TM- und GTT-Datenbanken viele Tabellen und andere Datenstrukturen beinhalten können. Die Datenbanktabellen 370 und 390 sollen dazu dienen, beispielhaft die Datenbankfelder, welche zum Formulieren der mobilen Warteschleife-Antwortnachrichten entsprechend den Ausführungsformen der vorliegenden Erfindung benutzt werden, zu erläutern.
Die auf Ausnahmen beruhende Abtast-Routing-Regel-G-Port^TM-Datenbanktabelle 370 besteht aus mehreren Feldern, wobei beinhaltet sind: ein Schlüsselfeld 372 einer Kennung einer gerufenen Partei (CPI), ein Indikator-Schlüsselfeld 374 vom Entitätstyp, ein Punktcode-(PC-)Feld 376, ein Subsystemnummer-(SSN-)Feld 378, ein Routing-Indikator-(RI-)Feld 380, ein Entitätsadressfeld 382, ein Routing-Nummer-(RN-)Feld 384, ein Statusfeld 386 einer Nummernübertragbarkeit (NP), ein IMSI-Feld 388 und ein Feld 389 für Digit- bzw. Code-Element-Aktion (D-Aktion).
Mit speziellem Bezug auf das MSISDN-Schlüsselfeld 372 sollte beachtet werden, dass in einer anderen Ausführungsform das MSISDN-Schlüsselfeld einen kontinuierlichen Bereich oder Block von MSISDN-Werten beinhalten kann. Wenn dem so ist, so kann ein Bereich oder Block an MSISDN-Werten als "Ausnahmen" für die Standard-Routing-Regeln bezeichnet werden, welche in der zugehörigen GTT-Datenbanktabelle 390 definiert sind. Mit Bezug auf das Indikatorfeld 374 vom Entitätstyp wird gewürdigt werden, dass dieses Feld die G-Port^TM-Datenbank in die Lage versetzt, mit unterschiedlichen Routing-Instruktionen abhängig vom Typ des mobilen Dienstes, welcher erforderlich ist, zu antworten. Beispielsweise wird eine für ein HLR bestimmte Signalisierungsnachricht, welche mit der MSISDN (919) 380-3414 verbunden ist, andere Routing-Instruktionen von der G-Port^TM-Datenbank erhalten als eine für ein EIR bestimmte Signalisierungsnachricht, welche mit der gleichen MSISDN verbunden ist, wie dies in 5a angezeigt ist.
Außerdem ist ein PCR-Knoten der vorliegenden Erfindung adaptiert, um unterschiedlich auf unterschiedliche Arten von Nachrichten in bestimmten Fällen zu antworten. Beispielsweise kann der PCR-Knoten im Falle einer SRI-Signalisierungsnachricht, welche mit einem Anruf an einen portierten Teilnehmer verbunden ist, eine neue SRI-Bestätigungs-(SRI Ack-)Nachricht erzeugen und routen anstatt des einfachen Routens oder Zurückführens der Original-SRI-Nachricht. Die Fähigkeit, nicht nur die Signalisierungsnachrichten zu routen/zurückzuführen, sondern neue Signalisierungsnachrichten basierend auf Information zu erstellen, welche in der G-Port^TM-Datenbank gespeichert ist, ist ein signifikanter Gesichtspunkt eines PCR der vorliegenden Erfindung.
Das Digit-Aktionsfeld 389 liefert einen Mechanismus, mit welchem ein Operator spezifizieren kann, ob eine Routing-Information, welche von einem Suchlauf in einer G-Port^TM-Datenbank für einen speziellen MSISDN-Eintrag erhalten wurde, benutzt wird, um die vorhandene globale Titel-Digit-Information in der empfangenen Nachricht zu ersetzen, der existierenden globalen Titel-Digit-Information angehängt wird oder einfach nicht in die empfangene Nachricht eingefügt wird.
Die GTT-Datenbanktabelle 390 entsprechend der Abtast-Standard-Routing-Regel besteht aus mehreren Feldern, welche minimale und maximale MIN-Schlüsselfelder 392 bzw. 394, ein Punktcode-(PC-)Feld 396, ein Subsystemnummern-(SSN-)Feld 398, ein Routing-Indikator-(RI-)Feld 400 und ein Umsetzungstyp-(TT-)Feld 402 beinhalten.
Wieder sollte gewürdigt werden, dass die G-Port^TM- und GTT-Datenbank-Aufzeichnungsstrukturen und die Pseudodaten, welche in den 5a und 5b präsentiert werden, während diese unterstützend für die Beispiele sind, welche in dieser Veröffentlichung gegeben werden, nur erläuternd für die Grundinformation sind, welche nötig ist, um die erforderlichen Routing-Daten-Suchläufe durchzuführen. In der Praxis können die aktuellen Datenbankaufzeichnungsstrukturen und das gesamte Datenbankdesign entsprechend zu speziellen Erfordernissen der Implementierung und Systemleistungsfähigkeit variieren.
Das komplementäre Datenbankzugriffsschema, welches von dem PCR-Knoten der vorliegenden Erfindung angewendet wird, erfordert, dass die GTT-Datenbanktabelle 390 einen Satz von bereichs- oder blockbasierten Standard-Routing-Regeln enthält, während die G-Port^TM-Datenbanktabelle 370 Ausnahmen für die blockbasierten Standard-Routing-Regeln enthält. Mit bereichs- oder blockbasierten Routing-Regeln wird gemeint, dass ein Block oder ein Bereich von mobilen Identifikationsnummern (z.B. IMSI, MSISDN, etc.) mit der Netzwerkadresse oder einem speziellen HLR, EIR, AuC, Service-Steuerpunkt (SCP), etc. verbunden ist. Eine derartige bereichsbasierte Routing-Regel-Datenbankstruktur ist ähnlich den Routing-Datenbankstrukturen, welche im Allgemeinen bei herkömmlichen GMSC-Knoten angewendet werden, wie oben beschrieben. Außerdem wird ein ähnliches komplementäres Standard-Ausnahme-Routing-Datenbankschema in dem oben als Referenz ausgeführten US-Patent Nr. 09/471,946, eingereicht am 23. Dezember 1999, mit dem Titel Methods And Systems For Routing Messages In A Communications Network beschrieben.
Mit Bezug auf 5b beinhaltet die GTT- oder bereichsbasierte Standard-Datenbanktabelle 390 Schlüsselfelder in der Spalte auf der linken Seite und Datenfelder in der Spalte auf der rechten Seite. Die Schlüsselfelder repräsentieren Bereiche von mobilen Identifikations- oder MSISDN-Nummern, welche mit einem speziellen Knoten verbunden sind. Beispielsweise spezifiziert das erste Schlüsselfeld einen minimalen MSISDN-Wert von (919) 380-0000 und einen maximalen MSISDN-Wert von (919) 380-9999. Die Routing-Datenfelder entsprechend diesem MSISDN-Bereich beinhalten einen Punktcode-(PC-)Wert von 4-0-1, einen Subsystem-Nummer-(SSN-)Wert von 6, einen Routing-Indikator-(RI-)Wert der Route auf Subsystemnummer (RT-ON-SSN) und einen Umsetzungstyp-(TT-)Wert von 4. Die Daten, welche in den Datenfeldern beinhaltet sind, dienen nur der Erläuterung von Datenfeldern, welche in der bereichsbasierten Standard-GTT-Datenbanktabelle 390 beinhaltet sein können. Ähnliche Schlüsselfelder und Datenfelder werden für andere Abtast-MSISDN-Wertbereiche gezeigt.
Mit Bezug auf 5a beinhaltet die G-Port^TM oder die ausnahmenbasierte Datenbanktabelle 370 Einträge, welche Ausnahmen für Einträge in der bereichsbasierten Standard-Routing-Datenbanktabelle 390 sind. In 5a beinhaltet die Spalte auf der linken Seite einen Schlüssel-MSISDN-Wert, und die Spalte auf der rechten Seite beinhaltet Datenfelder für jeden MSISDN-Eintrag. Wieder sollte beachtet werden, dass in einer anderen Ausführungsform der Schlüssel-MSISDN-Wert einen kontinuierlichen Bereich oder Block von "Ausnahme"-MSISDN-Werten beinhalten könnte. In dem speziellen Beispiel, welches in 5a gezeigt wird, beinhaltet der erste Eintrag einen Schlüsselfeld-MSISDN-Wert von (919) 380-3833 und einen Entitätsschlüsselwert von "HLR". Die Datenfelder entsprechend dem ersten Eintrag beinhalten ein PC von 4-0-0, einen SSN-Wert von 6, einen RI-Wert von RT-ON- SSN, einen Digit-Aktions-(D-Aktions-)Wert von "kein", eine Entitätsadresse 303211234, welche die mobile Service-Entität darstellt, ein HLR A, einen Nummernübertragbarkeits-Statuswert von "Nicht Portiert" und einen verbundenen IMSI-Kennungswert von 9192220000. Wiederum dienen diese Datenfelder nur der Erläuterung von Datenfeldern, welche in der ausnahmenbasierten oder G-Port^TM-Datenbanktabelle 370 enthalten sein können.
Die duale Datenbank-Architektur, welche in dem PCR-Knoten der vorliegenden Erfindung angewendet wird, liefert eine Anzahl von subtilem Nutzen für den Netzwerk-Operator. Beispielsweise die komplementäre Eigenschaft der zwei Datenbanken minimiert optimal die Anforderungen an eine Routing-Datenbank-Speicherquelle. Außerdem wird die Aufgabe des Pflegens und Verwaltens des flexiblen Routing-Knotens stark vereinfacht, indem nur Ausnahmen zu den herkömmlichen blockbasierten Routing-Regeln explizit in die G-Port^TM-Datenbank eingegeben werden müssen. Wenn dem nicht so ist und beispielsweise ein spezieller Netzwerk-Operator Daten hatte, welche mit 500.000 mobilen Teilnehmern verbunden sind, welche in einer oder mehreren HLRs gespeichert sind, müsste der Netzwerk-Operator wenigstens eine einzige Routing-Aufzeichnung für jeden der 500.000 Teilnehmer schaffen. Die ausnahmenbasierte Struktur des flexiblen Routingknoten-Datenbanksystems erfordert einfach in einem solchen Fall, dass der Operator individuelle Routing-Aufzeichnungen in der G-Port^TM-Datenbank nur für jene MSISDN-Nummern schafft und speichert, welche nicht zu den bereichs- oder blockbasierten Regeln gehören, welche in der GTT-Datenbank spezifiziert wurden. Wenn z.B. eine Nummer von einem HLR zu einem anderen HLR portiert wird, kann die MSISDN-Nummer eine Ausnahme von den blockbasierten Regeln in dem zweiten HLR sein. In dem speziellen Fall, wo alle der MSISDN-Nummern des Operators zu den blockbasierten Regeln gehören, welche in der GTT-Datenbank spezifiziert sind, würde die G-Port^TM-Datenbank leer sein. Beim anderen Extrem, wo alle MSISDN-Nummern des Operators nicht zu den allgemeinen blockbasierten Regeln gehören, welche in der GTT-Datenbank spezifiziert sind, würde die G-Port^TM-Datenbank we nigstens einen Eintrag für jede zugeteilte MSISDN-Nummer des Operators enthalten.
Ein PCR-Knoten entsprechend der vorliegenden Erfindung erleichtert das Aufteilen der Last unter den vielen HLRs. Wenn beispielsweise ein Service-Provider original zwei HLRs im Dienst stehen hat und nachfolgend ein drittes HLR kauft, erlaubt es die G-Port^TM-Datenbank, Nummern, welche den Original-HLRs zugeordnet sind, schnell und leicht dem dritten HLR rückzuzuordnen, um so allgemein den Signalisierungsverkehr zwischen den drei HLR-Knoten auszugleichen.
G-Port^TM-Service-Modul-Operation
Mit speziellem Bezug auf die G-Port^TM- und GTT-Umsetzungsdienste beinhalten die Parameter, welche entweder direkt oder indirekt benutzt werden, um die Art des Umsetzungsdienstes (z.B. G-Port^TM-Dienst oder GTT-Dienst) zu bestimmen, welcher von einer eingehenden Signalisierungsnachricht gefordert wird, sie sind jedoch nicht beschränkt auf: einen Routing-Indikator (RI), einen Domäne-Indikator (DI), einen Globaltitel-Indikator-(GTI-)Parameter, einen Umsetzungstyp-(TT-)Parameter, einen Benummerungsplan-(NP-)Parameter und einen Art-der-Adresse-Indikators-(NAI-)Parameter. Beispielsweise kann in einer Ausführungsform ein PCR-Knoten so konfiguriert sein, dass eine empfangene SS7-Signalisierungsnachricht mit einem GTI-Wert von 4, einem TT-Wert von 10, einem NP-Wert von 1 und einem NAI-Wert von 3 eine G-Port^TM-Verarbeitung erhält. Diese Parameter, ihre Bedeutungen innerhalb des Kontexts eines SS7-Kommunikationsnetzwerks und ihr Wertebereich sind Fachleuten sehr gut bekannt, und folglich werden sie hier nicht im Detail diskutiert. Es sollte ausreichen zu sagen, dass die bevorzugte Ausführungsform eines PCR-Knotens der vorliegenden Erfindung auf einigen oder allen dieser Parameter beruht, um die Notwendigkeit für einen G-Port^TM-Umsetzungsdienst zu bestimmen. Mit speziellem Bezug auf den Domäne-Indikator (DI) wird ge würdigt werden, dass dieser Wert anzeigt, ob die Nachricht in einem ANSI- oder einem ITU-Format ist und ferner den nationalen oder internationalen Charakter der Nachricht anzeigen kann. Eine derartige Information kann sowohl explizit als auch implizit von einer empfangenen Signalisierungsnachricht erhalten werden.
Nachdem einmal die Notwendigkeit für eine G-Port^TM-Verarbeitung bestimmt worden ist, wird als Nächstes der spezifische Typ des Umsetzungsservice oder der Entitätstyp des mobilen Dienstes bestimmt. Mit speziellem Bezug auf die G-Port^TM-Umsetzungsdienste können die Arten von Diensten, welche erhältlich sind, GSM-Dienste beinhalten, wie z.B. HLR, EIR, AuC, SMSC, etc.. Das Bestimmen des speziellen G-Port^TM-Umsetzungsdienstes wird durch Untersuchen eines Subsystemnummer-(SSN-)Parameters durchgeführt, welcher in dem SCCP-Adressfeld der gerufenen Partei bzw. dem (CdAPA)-Feld der Signalisierungsnachricht enthalten ist. Wiederum ist der SSN-Parameter für Fachleute sehr gut bekannt, und folglich wird er hier nicht im Detail diskutiert. Es sollte ausreichen zu sagen, dass der flexible Routing-Knoten der vorliegenden Erfindung so konfiguriert ist, dass er gewisse SSN-Werte erkennen kann, welche die Notwendigkeit für eine spezielle Art von G-Port^TM-Umsetzungsdienst anzeigen.
Von einem Standpunkt des Betreibens aus werden Signalisierungsnachrichten, welche eine Routing-Datenbankverarbeitung erfordern, als erste durch die ausnahmenbasierte G-Port^TM-Datenbank bedient. D.h., ein Suchlauf wird in der G-Port^TM-Datenbank basierend auf dem Entitätstyp des bezeichneten Mobildienstes und einer MSISDN-Nummer, welche mit dem eingehenden Signalisierungs-Nachrichtenpaket verbunden ist, durchgeführt. Unter der Annahme, dass eine Entsprechung in der G-Port^TM-Datenbank gefunden wird, wird wiederum gewürdigt werden, dass eine nachfolgende G-Port^TM-Verarbeitung durch die Art der original empfangenen Nachricht festgelegt wird. Mit Bezug auf die Signalisierungsnachrichten, welche auf SS7-Umsetzungs-fähigkeiten des Applikationsparts (CCAP) basieren, kann der Nachrichtentyp durch eine Untersuchung eines TCAP-Operations-(OP-)Code-Wertes, welcher in der Nachricht enthalten ist, bestimmt werden. In den beispielhaften Szenarien, welche hier beschrieben und diskutiert werden, werden Sende-Routing-Informations-(SRI-) und Kurzmitteilungsservice-(SMS-)Nachrichtenarten angewendet und das Ergebnis der G-Port^TM-Verarbeitung kann abhängig davon variieren, welcher Nachrichtentyp durch das PCR empfangen wird. Es wird jedoch gewürdigt werden, dass viele Arten von Signalisierungsnachrichten definiert und aktuell in GSM-, PCS- und IS-41-Funk-Kommunikations-netzwerken angewendet werden und dass ein PCR-Knoten der vorliegenden Erfindung adaptiert werden kann, um jegliche Anzahl von Signalisierungs-Nachrichtentypen aufzunehmen.
Wie auch immer, falls während einer Suchlaufoperation eine MSISDN- und Entitätstyp-Entsprechung in der G-Port^TM-Datenbank aufgefunden wird, werden die geeigneten Routing-Daten an die G-Port^TM-Datenbank zurückgesandt und das Signalisierungs-Nachrichtenpaket wird entsprechend vor dem weiteren Routen modifiziert. In einem solchen Fall ist kein zweites Suchen der blockbasierten GTT-Datenbank erforderlich. Im Falle jedoch, dass keine MSISDN-Entsprechung in der G-Port^TM-Datenbank gefunden wird, wird ein zweites Suchen in der Standard-Bereichsbasierten-GTT-Datenbank durchgeführt.
G-Port^TM-Umsetzung
4 und 6 erläutern im Allgemeinen die zwei Routing-Datenbank-Zugriffsszenarien, welche oben kurz beschrieben wurden, während die 7a–7c ein Flussdiagramm der damit verbundenen Nachrichtverarbeitungsschritte zeigen. Spezieller ausgedrückt, 4 zeigt den Fall auf, wo der Anfangs-G-Port^TM-Datenbanksuchlauf eine MSISDN- und eine Entitätstypentsprechung findet und deshalb kein zweiter GTT-Datenbanksuchlauf erforderlich ist. Um diesen Fall zu erläutern, wird der Pfad einer typischen HLR- gebundenen SS7-Signalisierungsnachricht durch den PCR-Knoten 302 verfolgt, wobei der Pfad durch eine gestrichelte Linie in 4 angezeigt wird.
Mit Bezug auf 6, beginnend an der eingebundenen LIM-Karte 308, wird eine Signalisierungsnachricht empfangen, und ein SS7-MTP-Pegel-1-und-2-Verarbeiten wird an dem eingehenden Signalisierungs-Nachrichtenpaket durch den MTP-Pegel-1-und-2-Prozess 310 durchgeführt. Mit dem vollständigen MTP-Pegel-1-und-2-Verarbeiten wird das Signalisierungs-Nachrichtenpaket zeitweise in der E/A-Warteschlange 312 gepuffert, bevor es zu dem Datenstapel bei dem MTP-Pegel-3-HMDC-Prozess 314 durchgelassen wird. Der HMDC-Prozess 314 untersucht das Signalisierungs-Nachrichtenpaket und bestimmt, ob das Paket eine weitere Bearbeitung an dem PCR-Knoten 302 benötigt. In einer Ausführungsform ist der HMDC-Prozess 314 adaptiert, um den Zielpunktcode (DPC) und die Service-Indikator-Oktett-(SIO-)Parameter zu untersuchen, welche in dem Anfangsteil des Nachrichtenübertragungsteils (MTP) eines SS7-Signalisierungs-Nachrichtenpaketes enthalten sind. Für den Fall, dass eine Signalisierungsnachricht einen DPC-Wert entsprechend der SS7-Netzwerkadresse des PCR-Knotens und einen SIO-Wert entsprechend einer Nachricht vom SCCP-Typ enthält, wird die Nachricht als eine identifiziert, welche möglicherweise eine G-Port^TM-Verarbeitung erfordert. In dem in 4 gezeigten Beispiel wird angenommen, dass der HMDC-Prozess 314 die DPC- und SIO-Werte untersucht, welche mit der empfangenen Signalisierungsnachricht verbunden sind, und bestimmt nachfolgend, dass eine weitere Verarbeitung des Nachrichtenpaketes erforderlich ist. Wenn dem so ist, wird das Nachrichtenpaket an den HMDT-Prozess 316 weitergeleitet. Der HMDT-Prozess 316 untersucht das Paket und bestimmt, welches verteilte Verarbeitungsmodul, das mit dem IMT-Bus 304 verbunden ist, als Nächstes das Paket empfangen soll. In diesem Fall bestimmt der HMDT-Prozess 316, dass die Signalisierungsnachricht an das GPM-Modul 340 für die G-Port^TM-Verarbeitung weitergeleitet werden soll. Das Signalisierungs-Nachrichtenpaket wird dann auf dem Hochgeschwindigkeits-IMT-Bus 304 platziert und an das GPM 340 gesandt.
Mit Bezug auf 7a–7c kommt im Schritt ST1 die Signalisierungsnachricht an der GPM-Karte 340 an, und der SCCP-Prozess 342 empfängt das Paket. Innerhalb des SCCP-Prozesses 342 wird das Nachrichtenpaket an den SCRC-Steuerprozess 344 gelenkt. In den Schritten ST2 und ST3 decodiert und untersucht der SCRC-Prozess 328 jeweils die Paket-Inhaltsinformation, welche in dem Anfangsteil der Signalisierungsnachricht enthalten ist, um zu ermitteln, welche Art von Umsetzungsservice erforderlich ist. Spezieller ausgedrückt, der Routing-Indikator-(RI-)Parameter, welcher in dem Signalisierungs-Nachrichtenpaket enthalten ist, wird analysiert, um zu bestimmen, ob G-Port^TM-Subsystemverarbeitung angezeigt ist. In einer Ausführungsform zeigt ein RI-Wert des "RT-ON-GT" an, dass G-Port^TM-Verarbeitung erforderlich ist.
Nimmt man an, dass ein RI-Wert von "RT-ON-GT" in der empfangenen Signalisierungsnachricht beinhaltet ist, wird das Paket als Nächstes an den G-Port^TM-Prozess 346 geleitet, wo die GTI-, TT-, NP- und NAI-Parameter, welche in dem Signalisierungs-Nachrichtenpaket enthalten sind, analysiert werden, um zu bestimmen, ob ein G-Port^TM- oder ein GTT-Umsetzungsservice erforderlich ist. In dem in 4 dargestellten Szenario wird angenommen, dass die empfangene Signalisierungsnachricht einen RI-Wert von "RT-ON-GT", einen GTI-Wert von 4, einen Umsetzungstyp-(TT-)Wert von 10, einen "nationalen" NAI-Wert von 3 und einen "E.164"-NP-Wert von 1 besitzt und dass diese Werte kollektiv als Anzeichen für die Notwendigkeit eines G-Port^TM-Dienstes (ST4) interpretiert werden. Der Signalisierungs-Nachrichteninhalt wird dann weiter analysiert, um den speziellen Mobilservice-Entitätstyp oder den Typ des G-Port^TM-Umsetzungsservice, welcher erforderlich ist, zu bestimmen, wie dies durch den Schritt ST5 angezeigt wird. Spezieller ausgedrückt, der CdPA-SSN-Parameter wird untersucht, und der Wert von 6 wird interpretiert, dass er die Notwendigkeit für eine G-Port^TM-HLR-Typ-Umsetzung anzeigt. In diesem speziellen Beispiel, falls der designierte Mobilservice-Entitätstyp bestimmt ist, dass er irgendetwas anders als ein HLR ist (d.h. SSN nicht gleich 6), wird das Paket zu dem GTT-Datenbankprozess 348 geführt, wie dies in den Schritten ST6 bzw. ST7 angezeigt wird. Im Verarbeitungsschritt ST9 wird eine Bestimmung mit Bezug darauf durchgeführt, wie ein MSISDN-Wert aus der Signalisierungsnachricht extrahiert werden sollte. In der hier gegebenen speziellen Ausführungsform wird angenommen, dass ein Signalisierungs-Nachrichtenpaket entweder eine SRI-Nachricht oder eine Nicht-SRI-Nachricht ist. Wenn dem so ist, falls eine Signalisierungsnachricht als eine Nicht-SRI identifiziert wird (ST10), wird der MSISDN-Wert aus dem SCCP-CdPA-Feld der Nachricht extrahiert. Die MSISDN wird typischerweise innerhalb des CdPA-Feldes in einer Struktur gespeichert, welche im Allgemeinen als ein globales Titel-Digit-(GTD-)Subfeld bezeichnet wird. Wenn die Signalisierungsnachricht als eine SRI-Nachricht (ST11) identifiziert ist, wird der MSISDN-Wert von dem TCAP/MAP-MSISDN-Digit-Feld der Nachricht extrahiert.
Auf jeden Fall wird die MSISDN-Nummer, welche in dem Paket eincodiert ist, nachfolgend untersucht und konditioniert, wenn dies notwendig ist (ST12). Mit speziellem Bezug auf das oben erwähnte Nummer-Konditionieren kann eine derartige Verarbeitung notwendig sein, um sicherzustellen, dass die MSISDN kompatibel mit dem Format der Schlüsselfelddaten ist, welche in den G-Port^TM- bzw. GTT-Datenbanken gespeichert sind. Die Operationen des Nummer-Konditionierens können das Löschen von Extra-Präfix-Digits oder das Voranhängen von Extra-Digits für eine MSISDN, welche in einem Signalisierungs-Nachrichtenpaket beinhaltet ist, beinhalten, um so die Nummer zu zwingen, konform mit einem internationalen Format zu sein. Die Umwandlung einer mobilen Identifikationsnummer von einem Nummernstandard in einen anderen kann auch durchgeführt werden. Beispielsweise kann die MSISDN, welche mit einem eingehenden Signalisierungs-Nachrichtenpaket verbunden ist, von einem ersten Industriestandardformat, welches als E.214 bekannt ist, in ein zweites Industriestandardformat, welches als E.212 bekannt ist, vor den Datenbanksuchläufen umgewandelt werden. Wiederum sollte gewürdigt werden, dass derartige MSISDN-Konditionierdienste nur notwendig in dem Fall sind, wenn das Format der eingehenden MSISDN nicht konsistent mit dem entsprechenden Schlüsselfeld-Datenformat in den G-Port^TM- und GTT-Datenbanken ist.
Im Schritt ST13 wird die G-Port^TM-Datenbank durchsucht, wobei die MSISDN als wenigstens ein Teil des Suchschlüssels benutzt wird. In einer Ausführungsform kann die G-Port^TM-Datenbank eine Datentabellenstruktur ähnlich Tabelle 370 nutzen, welche in 5a gezeigt wird. Die Schlüsselfeldstruktur einer G-Port^TM-Datentabelle 370 beinhaltet ein Entitätstyp-Schlüsselfeld 374, wie zuvor diskutiert. Jedoch wird gewürdigt werden, dass in einer anderen Ausführungsform der vorliegenden Erfindung die G-Port^TM-Datenbank viele Datentabellen beinhalten kann, wobei jede Tabelle Daten enthält, welche mit einem speziellen Entitätstyp (z.B. HR, EIR, AuC, SMSC, etc.) verbunden sind. Mit einer derartigen Datenbankstruktur kann jede Tabelle nur auf MSISDN-Werte verschlüsselt oder indiziert werden.
Mit Bezug auf das G-Port^TM-Datenbanksuchen wird in dem Beispiel, welches in 4 dargestellt wird, angenommen, dass eine Entsprechung in der G-Port^TM-Datenbank gefunden wird (ST14) (d.h. es gibt einen Eintrag in der G-Port^TM-Datentabelle 370 entsprechend dem CdPA-SSN-Wert der Nachricht). Das Verarbeiten der original empfangenen Signalisierungsnachricht von diesem Punkt weiter hängt sowohl vom Typ der original empfangenen Nachricht als auch von dem portierten Status des MSISDN-Wertes ab, welcher mit der Nachricht verbunden ist (ST16). Spezieller ausgedrückt, wenn die MSISDN, welche mit der original empfangenen Nachricht verbunden ist, bestimmt wird, dass sie nicht vom Netzwerk, welches von dem PCR-Knoten bedient wird, hinaus portiert wurde (d.h. nicht portiert, nicht bekannt ist, dass sie portiert wurde, oder hineinportiert), dann werden die Routing-Daten, welche an den G-Port^TM-Datenbankprozess zurückgeführt wurden, nachfolgend innerhalb des Original-Signalisierungs-Nachrichtenpaketes codiert, wie dies durch Schritt ST17 angezeigt wird, und die modifizierte Nachricht wird von der GPM-Karte 340 über den HMRT-Prozess 350 an die außen liegende DCM-Karte 330 zur Übertragung von dem PCR-Knoten gelenkt (ST21). Es wird gewürdigt werden, dass die Routing-Information, welche durch die G-Port^TM-Datenbank zurückgeführt wurde, effektiv die Netzwerkadresse eines dazwischenliegenden (z.B. Signalübertragungspunkt, Signalisierungs-Gateways, Paket-Routers, etc.) oder eines Endzielknotens (HLR, EIR, AuC, SMSC, etc.) bildet. Wenn jedoch bestimmt wird, dass die MSISDN, welche mit der original empfangenen Nachricht zusammenhängt, aus dem Netzwerk, welches durch den PCR-Knoten bedient wird, heraus portiert wurde (ST16), dann hängt der nächste Verarbeitungsschritt von dem Typ der original empfangenen Nachricht ab. In einer Ausführungsform der vorliegenden Erfindung, falls bestimmt wird, dass die original empfangene Nachricht eine Sende-Routing-Informations-(SRI-)Nachricht ist (ST18), wird dann eine neue SRI-Bestätigungsnachricht (SRI Ack) geschaffen und codiert, wobei zum Teil die Information benutzt wird, die von dem G-Port^TM-Datenbanksuchlauf zurückgeschickt wurde (ST19), und diese neue Nachricht wird nachfolgend von dem PCR-Knoten in einer ähnlichen Weise, wie oben beschrieben, geroutet. Wenn bestimmt wird, dass die original empfangene Nachricht irgendeine andere als eine SRI-Nachricht ist, dann wird die Originalnachricht modifiziert, so dass sie die Routing-Information enthält, welche von der G-Port^TM-Datenbank-Suchlaufoperation erhalten wird, und die modifizierte Nachricht wird nachfolgend von dem PCR-Knoten geroutet.
Wiederum wird gewürdigt werden, dass mit den SS7-TCAP-basierten Signalisierungsnachrichten der Nachrichtentyp durch eine Untersuchung eines TCAP-OP-Codewertes bestimmt werden kann, welcher in der Nachricht enthalten ist. In den beispielhaften Szenarien, welche oben präsentiert wurden, wird das Schaffen einer neuen Nachricht nur für den Fall beschrieben, dass eine SRI-Nachricht mit einem Teilnehmer verbunden ist, welcher aus dem PCR-Knoten des Netzwerks des Operator hinaus portiert wurde. Jedoch wird gewürdigt werden, dass ein PCR-Knoten der vorliegenden Erfindung adaptiert werden kann, um das Schaffen einer neuen Signalisierungsnachricht in Antwort auf das Empfangen und das Verarbeiten einer Nicht-SRI-Nachricht, welche mit einem Teilnehmer verbunden ist, welcher aus dem PCR-Knoten eines Netzwerk-Operators heraus portiert wurde, zu triggern. Wiederum sind viele andere Typen von mobilen Signalisierungsnachrichten definiert und werden gegenwärtig innerhalb von GSM-, PCS- und IS-41-Funkkommunikationsnetzwerken angewendet, und ein PCR-Knoten der vorliegenden Erfindung kann adaptiert werden, um jegliche Anzahl von Signalisierungs-Nachrichtentypen aufzunehmen.
PCR-Betriebsszenarien
8 bis 15 stellen einige beispielhafte Routing-Szenarien dar, welche mit einem PCR-Knoten der vorliegenden Erfindung verbunden sind. Die Abtast-, die G-Port^TM- und die GTT-Datentabellen 370 bzw. 390, welche in 5a bzw. 5b gezeigt werden, werden benutzt, um die Erläuterung der oben aufgeführten Beispielsszenarien zu unterstützen.
Das erste Nachrichten-Routing-Szenario, welches in 8 dargestellt wird, erläutert die Verarbeitung einer Sende-Routing-Information-(SRI-)Signalisierungsnachricht durch einen PCR-Knoten der vorliegenden Erfindung. Spezieller ausgedrückt, 8 beinhaltet ein mobiles Kommunikationsnetzwerk, welches im Allgemeinen durch die Nummer 300 angezeigt wird. Das Netzwerk 300 besteht aus einem Ursprungsmobilschaltzentrum (MSC) 110, einem Gateway-MSC 112, einem abschließenden MSC 120, einem ersten Heimatregister (HLR) 114, einem zweiten HLR 116, einem Besucherregister (VLR) 118 und einem PCR-Knoten 302. Diese Knoten sind über Signalisierungsverbindungen verbunden, wie dies in 8 angezeigt wird, obwohl es gewürdigt werden wird, dass unterschiedliche Signalisierungs-Verbindungstypen zwischen unterschiedlichen Knoten angeordnet werden können. Beispielsweise kann der Signalisierungs-Verbindungsanschluss zwischen MSC 110 und GMSC 112 eine herkömmliche SS7-MTP-Typ-Signalisierungsverbindung sein, während die Signalisierungsverbindung zwischen PCR 302 und HLR 114 ein Transportadaptierschicht-Interface (TALI) – TCP/IP oder eine Strom-Steuer-Übertragungsprotokoll-(SCTP-)IP-Typ-Signalisierungsverbindung sein kann.
In jedem Fall wird zum Zwecke der Erläuterung MSC 110 einem SS7-Punktcode (PC) von 1-0-0 zugeordnet, GMSC 112 wird einem Punktcode von 1-0-0 zugeordnet, MSC 120 wird einem Punktcode von 5-0-0 zugeordnet, HLR 114 wird einem Punktcode von 4-0-0 zugeordnet, HLR 116 wird einem Punktcode von 4-0-1 zugeordnet, und der PCR-Knoten 302 wird einem Punktcode von 3-0-0 zugeordnet. Ebenso ist MSC 110 adaptiert, um eine ISDN-Nutzerpart-(ISUP-)Anfangsadressnachricht (IAM) M1 in Antwort auf eine Anruferstellungsanforderung durch eine mobil rufende Partei zu erzeugen und abzusenden. Das GMSC 112 empfängt die ISUP-IAM-Nachricht M1 und erzeugt nachfolgend eine SRI-Fragenachricht M2. Ein teilweises Auflisten des Inhalts dieser Abtast-SRI-Fragenachricht wird in 9 gegeben. Es wird gewürdigt werden, dass die SRI-Nachricht M2 zu einem Zielpunktcode (DPC) MTP-adressiert ist, 3-0-0, welcher der PC-Adresse des PCR-Knotens 302 entspricht. Ebenso wird die SRI-Nachricht M2 zu einem PCR-Knoten 203 gesendet und allgemein von diesem über eine verbindende Signalisierverbindung empfangen. Bei dem Empfang durch den PCR-Knoten 203 wird die SRI-Nachricht M2 an der GPM-Karte 340 in einer ähnlichen Weise verarbeitet, wie sie vorher beschrieben wurde und im Allgemeinen in 4 dargestellt wird. D.h., die SRI-Nachricht M2 wird am SS7-LIM 308 empfangen und nachfolgend durch den HMDC-Prozess 314 untersucht. Wie vorher diskutiert, ist der HMDC-Prozess 314 in einer Ausführungsform adaptiert, um einen MTP-DPC-Parameter-402-Wert und einen Service-Indikator-Oktett-(SIO-)Parameter-404-Wert, welche in dem empfangenen Nachrichtenpaket enthalten sind, zu untersuchen, um zu bestimmen, ob eine weitere interne SCCP-Typ-Verarbeitung erforderlich ist. In diesem Beispiel ist der DPC der empfangenen Nachricht M2 gleich der Punktcode-Adresse des PCR-Knotens 3-0-0, und der SIO-Wert zeigt an, dass das Paket eine SCCP-Typ-Nachricht enthält. Da die Nachricht M2 an den PCR-Knoten 302 adressiert ist und die Nachricht eine SCCP-Typ-Nachricht ist, leitet der HMDC-Prozess 314 das Paket an den HMDT-Prozess 316 mit Instruktionen, um die Nachricht an eine verfügbare SCCP-Karte (beispielsweise GPM) für das weitere Verarbeiten zu liefern. Folglich wird die Nachricht M2 an die verfügbare GPM-Karte 340 über einen IMT-Bus 304 zur Weiterverarbeitung geliefert.
Nach dem Empfangen durch das GPM 340 wird der SCCP-Teil der Nachricht M2 decodiert, und ein Service-Auswahl-Check wird durch den anwesenden SCRC-Prozess 344 durchgeführt. Spezieller ausgedrückt, wird der Routing-Indikator-(RI-)Parameter 420 der gerufenen Partei (CdPA), welcher in der SRI-Nachricht M2 enthalten ist, analysiert, um zu bestimmen, ob eine G-Port^TM-Subsystemverarbeitung notwendig ist. Wie in 9 angezeigt, beinhaltet die SRI-Nachricht M2 einen CdPA-RI-Wert von "RT-ON-GT", welcher die Notwendigkeit für eine G-Port^TM-Verarbeitung anzeigt. Das Paket wird dann zu dem G-Port^TM-Datenbankprozess 346 gelenkt, wo die TT 412-, GTI 414-, NP 416- und NAI-418-Parameter, welche in dem Signalisierungs-Nachrichtenpaket enthalten sind, analysiert werden, um zu bestimmen, ob ein G-Port^TM- oder GTT-Umsetzungsservice erforderlich ist. In diesem Beispielsszenario werden der Nachricht-M2-GTI-Wert von 4, der Umsetzungstyp-(TT-)Wert von 10, der "nationale" NAI-Wert von 3 und der "E.164"-NP-Wert von 1 kollektiv so interpretiert, dass sie die Notwendigkeit für einen G-Port^TM-Service anzeigen. Als Nächstes wird der CdPA-SSN-Parameter 410 untersucht, um den erforderlichen spezifischen Mobilservice-Entitätstyp oder den erforderlichen G-Port^TM-Umsetzungsdienst zu bestimmen. Spezieller ausgedrückt, der SSN-Wert von 6 wird so interpretiert, dass er die Notwendigkeit für eine G-Port^TM-HLR-Entitätstyp-Umsetzung anzeigt. Ein MSISDN-Wert, welcher mit der gerufenen Partei verbunden ist, wird als Nächstes aus dem TCAP/MAP-MSISDN-Digit-Feld 426 der Nachricht extrahiert, nachdem die Nachricht als SRI identifiziert ist.
Die G-Port^TM-Datenbank wird nachfolgend durchsucht, wobei der MSISDN-Wert der angerufenen Partei als wenigstens ein Teil des Suchschlüssels benutzt wird. Aus den 5a und 9 wird gewürdigt werden, dass ein Suchlauf in der G-Port^TM-Datenbank-Datentabelle 370, der den MSISDN-Digit-Parameter-416-Wert, (919) 380-3815, und den HLR-Entitätstyp nutzt, zu einer Entsprechung mit dem vierten Eintrag oder der Aufzeichnung 450 in der Datentabelle 370 führt.
Wie durch die G-Port^TM-Daten angezeigt wird, welche in der Aufzeichnung 450 enthalten sind, wird für die gerufene Partei MSISDN, welche mit der original empfangenen SRI-Nachricht M2 verbunden ist, bestimmt, dass sie aus dem Netzwerk, welches durch den PCR-Knoten 302 bedient wird, heraus portiert wurde, und eine neue SRI-Bestätigungs-(SRI Ack-)Nachricht wird geschaffen. Diese neue SRI Ack-Nachricht M2 wird codiert, wobei zum Teil die Information genutzt wird, die von dem G-Port^TM-Datenbanksuchlauf zurückgesandt wurde. Innerhalb der vielen Parameter in der neuen SRI-Ack-Nachricht M2, welche durch den PCR-Knoten gesetzt werden, sind von spezieller Signifikanz der CdPA-RI-Parameter 420, der MSRN-Codeparameter 432 und der Port-Statusparameter 434. Wie in 9 dargestellt wird, wird der CdPA-RI-Parameter auf "RT-ON-SSN" gesetzt, welcher anzeigt, dass keine weitere globale Titeltypumsetzung erforderlich ist, um die Nachricht M2 an den Endzielknoten zu routen. Der MSRN-Digit-Parameter 432 wird auf die Routing-Nummer des MSC, welcher gegenwärtig als die "portierte" Heim-MSC der gerufenen Partei dient, gesetzt, und der Port-Status-Parameter 434 der neuen Nachricht wird auf "Hinausportiert" gesetzt. Wenn einmal der Aufbau der SRI-Ack-Nachricht M2 vollständig ist, wird er von der GPM-Karte 340 an das geeignete außengebundene LIM oder DCM in einer ähnlichen Weise, wie oben beschrieben, geführt. In diesem speziellen Szenario wird gewürdigt werden, dass die neue SRI-Ack-Nachricht M2 zurück zum GMSC 112 gelenkt wird, welches die Original-SRI-Nachricht M1 erzeugte. Das GMSC 112 nutzt nachfolgend die Information, welche in der SRI-Nachricht M2 enthalten ist, um die Routing-Information in der originalen ISUP-IAM-Nachricht M1 zu modifizieren. Die modifizierte ISUP-IAM-Nachricht wird dann zu ihrem Endziel geroutet.
Das Nachrichten-Routing-Szenario, welches in 8 dargestellt wird und im Allgemeinen oben beschrieben wurde, zeigt einen der Schlüsselgesichtspunkte der vorliegenden Erfindung. D.h., ein PCR-Knoten der vorliegenden Erfindung ist adaptiert, um effektiv eine SRI-Signalisierungsnachricht abzufangen, welche für einen mobilen Service-Knoten (z.B. HLR) bestimmt ist, und um zu bestimmen, ob ein Zugriff auf den angeforderten mobilen Service-Knoten aktuell notwendig ist. Spezieller ausgedrückt, ein PCR-Knoten ist adaptiert, um zu bestimmen, ob eine empfangene Signalisierungsnachricht mit einer gerufenen Partei verbunden ist, welche aus einem Service-Bereich oder Netzwerk hinaus portiert wurde. Im Falle eines Kommunikationsprotokolls oder einer Interaktion, welche ein GMSC erfordert, um eine erste Signalisierungs-Fragenachricht zu einem mobilen Service-Knoten zu erzeugen und zu übertragen, und nachfolgend eine Signalisierungs-Antwortnachricht von dem mobilen Service-Knoten zu empfangen, ist ein PCR-Knoten der vorliegenden Erfindung adaptiert, um auf den GMSC-Knoten mit der Signalisierungs-Antwortnachricht mit Hilfe des mobilen Service-Knotens zu antworten, in dem Fall, dass die gerufene Partei, welche mit der Signalisierungs-Fragenachricht verbunden ist, aus dem Netzwerkbereich hinaus portiert wurde, welcher durch das GMSC bedient wird. Dies ist der Fall in dem oben erläuterten SRI-SRI Ack-Kommunikationsfolge-Szenario. Jedoch wird gewürdigt werden, dass andere ähnliche Kommunikationsfolge-Szenarien, welche Signalisierungsnachrichten anders als SRI-SRI Ack-Typ-Nachrichten beinhalten, auch durch einen PCR-Knoten angepasst werden können. Demzufolge ist ein PCR-Knoten der vorliegenden Erfindung in der Lage, insgesamt die Monopolisierung von Mobilservice-Knotenquellen durch Signalisierungs-Nachrichten-verkehr, welcher mit portierten mobilen Teilnehmern verbunden ist, welche nicht länger durch einen mobilen Service-Knoten in dem lokalen Service-Bereich des PCR-Knotens bedient werden, zu minimieren oder zu eliminieren.
In 10 wird ein Signalisierungsszenario dargestellt, welches in engem Bezug zu dem Szenario steht, welches oben diskutiert wurde und im Allgemeinen in 8 dargestellt wird. In dem Szenario der 10 erzeugt das GMSC 112 eine SRI-Signalisierungsnachricht und überträgt sie zu dem PCR-Knoten 302. Innerhalb des PCR-Knotens 302 wird die Nachricht durch das LIM 308 empfangen und in einer ähnlichen Weise verarbeitet, wie sie oben in dem vorherigen Szenario beschrieben wurde. D.h., die SRI-Nachricht M2 wird durch die Prozesse auf dem LIM 308 untersucht, und es wird bestimmt, dass ein internes Routing an die GPM-Karte 340 erforderlich ist. Die Nachricht M2 wird empfangen und durch die SCCP- und SCRC-Prozesse 342 und 344 jeweils verarbeitet, in einer Weise, die ähnlich der ist, wie sie für das vorhergehenden Szenario beschrieben wurde. Wiederum zeigt die Untersuchung der RI-, TT-, GTI-, NP-, NAI- und SSN-Parameterwerte kollektiv an, dass eine G-Port^TM-Verarbeitung erforderlich ist. Jedoch wird in diesem Fall aus dem Nachrichteninhaltsdiagramm, welches in 11 gezeigt wird, gewürdigt werden, dass die MSISDN-Nummer der angerufenen Partei (770) 454-5731 ist, und da dem so ist, ein Suchen der G-Port^TM-Datenbankdatentabelle 370 zu einer Entsprechung mit dem dritten Eintrag oder der Aufzeichnung 452 führt. Es wird aus den Abtastdaten, welche in Tabelle 370 gezeigt werden, gewürdigt werden, dass der mobile Teilnehmer, welcher der MSISDN-Nummer (770) 454-5731 entspricht, nicht portiert wurde und tatsächlich durch den HLR-Knoten 114 bedient wird. Als Ergebnis dieses Herausfindens wird die Original-SRI-Nachricht M2 einfach modifiziert, um die Routing-Information zu beinhalten, welche notwendig ist, um die Lieferung an den HLR-Knoten 114 sicherzustellen. An diesem Punkt sollte beachtet werden, dass, falls die MSISDN-Nummer (770) 454-5731 nicht identifiziert wurde einer Ausnahme zu den Standard-Routing-Regeln zugeordnet zu sein, welche in der bereichsbasierten "Standard"-GTT-Datentabelle gespeichert sind, dann wäre die SRI-Nachricht M3 modifiziert worden, so dass sie eine Ziel-Routing-Adresse entsprechend dem HLR-Knoten 116 beinhaltet. Dies ist der Fall, da die mobilen Teilnehmer entsprechend dem Bereich der MSISDN-Nummern von (770) 454-0000 bis (770) 454-9999 einem HLR-Knoten 116 zugeordnet wurden, wie dies in der GTT-Datentabelle 390 der 5b angezeigt wird. Wie vorher in dieser Veröffentlichung diskutiert, kann eine derartige Rückverteilung oder Rückzuordnung von HLR-Teilnehmerinformation durch einen Netzwerk-Operator in einem Aufwand implementiert werden, um eine Belastung von Signalisierungsverkehr auf viele HLR-Quellen aufzuteilen.
Auf jeden Fall wird in diesem Fall das DPC 402 der modifizierten SRI-Nachricht M3 auf die Netzwerkadresse des Ziel-HLR-Knotens 114 gesetzt, wie dies in 11 gezeigt wird. Der Routing-Indikator-Parameter 420 wird auch von dem Originalwert von "RT-ON-GT" auf den neuen Wert von "RT-ON-SSN" geändert, wodurch angezeigt wird, dass keine weiteren Routing-Adressen-Umsetzungen erforderlich sind, um die Nachricht an das Endziel zu liefern. Eine modifizierte SRI-Nachricht M3 wird nachfolgend vom GPM 340 über den HMRT-Prozess 350 an die außengebundene DCM-Karte 330 geführt, wie dies allgemein in 4 gezeigt wird. Es wird gewürdigt werden, dass in diesem Szenario angenommen wird, dass der Signalisierungs-Verbindungsanschluss zwischen dem PCR-Knoten 302 und dem HLR-Knoten 114 ein EP-basiertes Protokoll (z.B. TALI) anwendet. Wie weiter in 10 dargestellt, empfängt der HLR-Knoten 114 die modifizierte SRI-Nachricht M3, welche durch den PCR-Knoten 302 gesandt wurde, und erzeugt nachfolgend eine Liefer-Routing-Nummer-(PRN-)Anfragenachricht M4. Die PRN-Nachricht M4 wird an den VLR-Knoten 118 geroutet, welcher aktuell den angerufenen mobilen Teilnehmer bedient. Der VLR-Knoten 118 antwortet auf die PRN-Anfrage mit einer PRN-Bestätigungs-(PRN-Ack-)Nachricht M5, welche die gewünschte Routing-Nummer-(RN-)Information enthält, welche mit dem MSC verbunden ist, welcher aktuell die gerufene mobile Partei bedient. Der HLR-Knoten 114 empfängt eine PRN-Ack-Nachricht M5 und formuliert eine SRI-Ack-Nachricht M6, welche als eine Antwort für die originale SRI-Nachricht M2 dient. Die SRI-Ack-Nachricht M6 wird nachfolgend zurück zu dem GMSC 112 über den PCR-Knoten 302 gesandt. Mit Bezug auf die SRI-Ack-Nachricht M6 wird gewürdigt werden, dass keine G-Port^TM-Typ-Verarbeitung an dieser Nachricht durchgeführt wird und dass der PCR-Knoten 302 einfach die Nachricht M6 an das GMSC 112 routet. An diesem Punkt empfängt das GMSC 112 die SRI-Ack-Nachricht M6 und fährt mit dem Anruferstellungs-Signalisierungsprozess in einer ähnlichen Weise fort, wie sie oben in dem vorherigen Szenario beschrieben wurde.
Dadurch wird in diesem Fall ein PCR-Knoten der vorliegenden Erfindung adaptiert, um effektiv eine SRI-Signalisierungs-nachricht zu unterbrechen, welche für einen mobilen Service-Knoten (z.B. HLR) bestimmt ist, und um festzulegen, ob mobile Service-Information, welche mit einem angerufenen mobilen Teilnehmer verbunden ist, in einem mobilen Service-Knotenort gespeichert wird, welcher einem Satz von Standard- oder bereichsbasierten Routing-Regeln entspricht, oder ob die gewünschte Mobilservice-Information in einem mobilen Service-Knotenort gespeichert wird, welcher derjenige ist, welcher einer Ausnahme aus dem Satz von Standard- oder bereichsbasierten Routing-Regeln entspricht. Mit anderen Worten, ein PCR-Knoten der vorliegenden Erfindung ist adaptiert, um zwischen einem mobilen Teilnehmer zu unterscheiden, dessen Service-Information aus einem speziellen Service-Bereich hinaus portiert wurde, und einem mobilen Teilnehmer, dessen Service-Information einfach zwischen mobilen Service-Knoten portiert wurde, welche alle innerhalb des gleichen Service-Bereichs sind (d.h. von dem gleichen GMSC bedient werden).
In 12 wird ein anderes signifikantes Signalisierungsszenario präsentiert, welches durch einen PCR-Knoten der vorliegenden Erfindung angepasst ist. In diesem Fall empfängt der GMSC-Knoten 112 eine Kurznachrichtdienst-(SMS-)Signalisierungsnachricht M1 von MSC 110. Es sollte gewürdigt werden, dass in dieser Situation keine explizite Antwortnachricht in Antwort auf die SMS-Nachricht M1 erforderlich ist. Stattdessen kann die SMS-Nachricht M1 einfach an das beabsichtigte Ziel geroutet werden (d.h. an den Pager oder den Handapparat des empfangenden mobilen Teilnehmers). Demzufolge empfängt das GMSC 112 die SMS-Nachricht M1 und routet nachfolgend die Nachricht an den PCR-Knoten 302. Die LIM 308-Verarbeitung und das interne Routen der SMS-Nachricht M2 innerhalb des PCR-Knotens 302 sind ähnlich dem, was in dem vorhergehenden Szenario beschrieben wurde, und werden deshalb hier im Detail nicht wieder beschrieben. Es sollte ausrei chend sein, zu sagen, dass die SMS-Nachricht als eine identifiziert wird, welche SCCP-Typ-Verarbeitung innerhalb des PCR-Knotens 302 erfordert, und folglich wird die Nachricht M2 intern zu der GPM-Karte 340 geroutet. SCCP- und SCRC-Prozesse 342 und 344 werden wieder zu Hilfe genommen, wie dies vorher beschrieben wurde, und es wird bestimmt, dass die Nachricht eine G-Port^TM-Verarbeitung erfordert. Wie in dem damit verbunden Nachrichteninhaltsdiagramm der 13 aufgezeigt wird, wird gewürdigt werden, dass der "angerufene" mobile Teilnehmer durch einen MSISDN-Digit-Parameter-426-Wert von (919) 380-3414 identifiziert wird. Wiederum wird dieser MSISDN-Wert der angerufenen Partei benutzt, um einen Suchlauf in der G-Port^TM-Datenbanktabelle 370 durchzuführen, und in diesem Beispiel wird auch angenommen, dass die SMS-Nachricht den Zugriff auf die HLR-Entität erfordert, welche den mobilen Teilnehmer der angerufenen Partei bedient, bevor das Routing vervollständigt werden kann. Demzufolge führt ein Suchlauf in der G-Port^TM-Datenbanktabelle 370 zu einer Entsprechung mit dem vierten Eintrag oder der Aufzeichnung 450, wie dies allgemein in 5a angezeigt wird. Information, welche in dem Übereinstimmen der G-Port^TM-Datenbankaufzeichnung 450 gespeichert ist, zeigt an, dass der mobile Teilnehmer der gerufenen Partei aus dem lokalen Service-Bereich des GMSC hinaus portiert wurde. In Antwort auf diese Festlegung und aufgrund der Tatsache, dass eine explizite Antwortnachricht nicht erforderlich ist, wird die SMS-Nachricht M2 einfach modifiziert, so dass sie die Routing-Nummer (RN) beinhaltet, welche mit dem MSC verbunden ist, das aktuell als die Heimat-MSC des mobilen Teilnehmers der gerufenen Partei dient. In diesem Beispiel wird die modifizierte SMS-Nachricht M3 von dem PCR-Knoten 302 geroutet und weiter zu dem nächsten "Hop" in dem Routing-Prozess, welcher MSC 120 ist. Es sollte beachtet werden, dass der Routing-Indikator-Parameter 420 in der modifizierten SMS-Nachricht M3 auf "RT-ON-GT" gesetzt bleibt, wodurch angezeigt wird, dass eine weitere Adressenumsetzung an einem Punkt während des Restes des Routing-Prozesses erforderlich sein kann.
Wiederum wird gewürdigt werden, dass in derartigen Szenarien ein PCR-Knoten der vorliegenden Erfindung wieder adaptiert ist, um insgesamt das Monopolisieren von Mobilservice-Knotenquellen durch Signalisierungs-Nachrichtenverkehr, welcher mit portierten mobilen Teilnehmern verbunden ist, die nicht länger durch einen mobilen Service-Knoten in dem lokalen Service-Bereich des PCR-Knotens bedient werden, zu minimieren oder zu eliminieren.
Abschließend wird ein Signalisierungsszenario in 14 beschrieben, welches sehr nahe dem zweiten Szenario entspricht, welches im Detail oben präsentiert und diskutiert wird. Jedoch wird in diesem Endbeispiel gewürdigt werden, dass die Signalisierungsnachricht, welche hier betrachtet wird, eine Nachricht vom SMS-Typ ist, welche, wie vorher erwähnt, ein Typ von Signalisierungsnachricht ist, welcher keine explizite entsprechende Antwortnachricht erfordert. Dieses abschließende Szenario zeigt wieder den Wert einer PCR-Tandem-Routing-Datenbankstruktur, welche sowohl ausnahme- als auch bereichsbasierte Tabellen mit Bezug auf flexibles Rückverteilen oder Rückzuordnen mobiler Teilnehmer-Service-Information auf viele mobile Service-Knotenquellen beinhaltet.
Mit Bezug auf das spezielle Beispiel, welches in 14 gezeigt wird, wird gewürdigt werden, dass das MSC 110 eine SMS-Nachricht M1 an das GMSC 112 überträgt. Demzufolge empfängt das GMSC 112 eine SMS-Nachricht M1 und routet nachfolgend die Nachricht an den PCR-Knoten 302. Wiederum ist das LIM 308-Verarbeiten und das interne Routing der SMS-Nachricht M2 innerhalb des PCR-Knotens 302 ähnlich dem, wie es in den vorherigen Szenarien beschrieben wurde. Die SMS-Nachricht M2 wird als eine identifiziert, welche eine SCCP-Typ-Verarbeitung innerhalb des PCR-Knotens 302 erfordert, und folglich wird die Nachricht M2 intern an die GPM-Karte 340 geroutet. Die SCCP- und SCRC-Prozesse 342 und 344 werden jeweils wieder aufgerufen, wie vorher beschrieben, und es wird bestimmt, dass die Nachricht eine G-Port^TM-Verarbeitung erfordert. Wie in dem verbundenen Nach richteninhaltsdiagramm der 15 aufgezeigt, wird gewürdigt werden, dass der "angerufene" mobile Teilnehmer durch einen MSISDN-Digit-Parameter-426-Wert von (919) 380-0001 identifiziert wird. Wiederum wird dieser MSISDN-Wert der angerufenen Partei benutzt, um einen Suchlauf in der G-Port^TM-Datentabelle 370 durchzuführen, und in diesem Beispiel wird auch angenommen, dass die SMS-Nachricht einen Zugriff auf die HLR-Entität erfordert, welche den mobilen Teilnehmer der angerufenen Partei bedient, bevor das Routing vollendet werden kann. Demnach führt ein Suchlauf in der G-Port^TM-Datenbanktabelle 370 nicht zu einer Entsprechung, wie dies allgemein in 5a angezeigt wird. Demnach wird nachfolgend die GTT-Datentabelle 390 durchsucht, und eine Entsprechung wird beim Eintrag oder bei der Aufzeichnung 454 lokalisiert. Die Information, welche in der Übereinstimmungs-GTT-Datenbankaufzeichnung 454 gespeichert ist, zeigt an, dass der mobile Teilnehmer der angerufenen Partei die Service-Information besitzt, welche in dem HLR-Knoten 116 gespeichert ist, wie dies allgemein in 5b angezeigt wird. In Antwort auf diese Festlegung und aufgrund der Tatsache, dass eine explizite Antwortnachricht nicht erforderlich ist, wird einfach die SMS-Nachricht M2 modifiziert, so dass sie die Punktcode-Adresse beinhaltet, welche mit dem Ziel-HLR-Knoten 116 verbunden ist. In diesem Beispiel wird die modifizierte SMS-Nachricht M3 von dem PCR-Knoten 302 geroutet und weiter zu dem nächsten "Hop" in dem Routing-Prozess, welcher der HLR 116 ist. Es sollte beachtet werden, dass der Routing-Indikator-Parameter 420 in der modifizierten SMS-Nachricht M3 auf "RT-ON-SSN" gesetzt ist, wodurch angezeigt wird, dass keine weitere Adressumsetzung erforderlich ist.
Außerdem dient die vorausgegangene Beschreibung nur dem Zweck der Erläuterung und nicht dem Zweck der Eingrenzung, sondern die Erfindung wird durch die Ansprüche definiert.

Claims

Verfahren zum Verarbeiten von Nachrichten in einem mobilen Kommunikationsnetzwerk, wobei das Verfahren aufweist: bei einem Telekommunikationsnetzwerk-Wegleitelement (302), welches einen Knoten mit der Verarbeitungsfähigkeit für SS7-Signalübertragung und Übertragbarkeit bzw. Portierbarkeit einer mobilen Nummer beinhaltet: (a) Empfangen einer Nachricht, welche sich auf eine Kommunikation in einem mobilen Kommunikationsnetzwerk bezieht, wobei die Nachricht die Kennung einer angerufenen Partei beinhaltet, welche früher mit einer Teilnehmeraufzeichnung in einem ersten HLR bzw. Heimatregister in einem Netzwerk eines ersten Service-Providers verbunden ist; (b) Analysieren von Information in der Nachricht, um zu bestimmen, ob die Mobilnummer-Portierbarkeit-Verarbeitung für die Nachricht erforderlich ist; (c) in Antwort auf das Bestimmen, dass die Mobilnummer-Portierbarkeit-Verarbeitung für die Nachricht erforderlich ist, Durchführen eines Suchlaufs in einer ersten Datenbank (370), welche in dem Telekommunikationsnetzwerk-Wegleitelement (302) platziert ist, basierend auf der Kennung der angerufenen Partei, um zu bestimmen, ob die angerufene Partei in ein Netzwerk eines zweiten Service-Providers, welches ein zweites HLR (114) beinhaltet, portiert wurde; und dadurch gekennzeichnet: (d) dass in Antwort auf das Bestimmen, dass die angerufene Partei in das Netzwerk des zweiten Service Providers portiert wurde, das Einfügen eines Punktcodes des Telekommunikationsnetzwerk-Wegleitelementes (302) in ein entstehendes Punkt-Codefeld der Nachricht und Weiterleiten der Nachricht an das zweite HLR (114).
Verfahren nach Anspruch 1, in welchem das Empfangen einer Nachricht das Empfangen einer Signalisiersystem-7-(SS7-)Zeichengabenachricht bzw. Signalisiernachricht beinhaltet.
Verfahren nach Anspruch 2, in welchem das Empfangen einer SS7-Signalisiernachricht das Empfangen einer Internet-Protokollverkapselten SS7-Signalisiernachricht beinhaltet.
Verfahren nach Anspruch 1, in welcher das Empfangen einer Nachricht das Empfangen einer Sendewegleitinformations-Signalisiernachricht beinhaltet.
Verfahren nach Anspruch 1, in welchem das Empfangen einer Nachricht das Empfangen einer Sitzung-Initiier-Protokoll-Signalisiernachricht beinhaltet.
Verfahren nach Anspruch 1, in welchem die Kennung der angerufenen Partei eine ISDN-Nummer des mobilen Teilnehmers beinhaltet.
Verfahren nach Anspruch 1, in welchem die Kennung der angerufenen Partei eine Telefonnummer beinhaltet, welche mit einem Festnetzteilnehmer verbunden ist.
Verfahren nach Anspruch 1, in welchem die Kennung der angerufenen Partei eine elektronische Mail-(E-mail-)Adresse oder eine IP-Adresse beinhaltet.
Verfahren nach Anspruch 1, in welchem die Analysierinformation in der Nachricht, um zu bestimmen, ob die Mobilnummer-Portierbarkeit-Verarbeitung erforderlich ist, das Überprüfen wenigstens eines der folgenden Parameter beinhaltet: eines Umsetzungstyp-Parameters, eines globalen Titelindikator-Parameters, eines Nummerierungsplan-Parameters und eines Adresse-Ursprung-Indikator-Parameters.
Verfahren nach Anspruch 1, in welchem das Empfangen einer Nachricht das Empfangen einer Kurzmitteilungsdienst-Nachricht beinhaltet.
Verfahren nach Anspruch 1, in welchem das Durchführen einer Suchlaufs in einer ersten Datenbank das Durchführen eines Suchlaufs in einer auf Ausnahmen basierenden Wegleitdatenbank beinhaltet, welche Einträge besitzt, welche Ausnahmen bezüglich von Bereichen der Kennungen der angerufenen Partei sind.
Verfahren nach Anspruch 11, welches aufweist: in Antwort auf das Fehlschlagen, einen Eintrag entsprechend der Kennung der gerufenen Partei in der ersten Datenbank zu ermitteln, das Durchführen eines zweiten Suchlaufs in einer zweiten Datenbank, basierend auf der Kennung der angerufenen Partei, wobei das Durchführen eines Suchlaufs in der zweiten Datenbank das Durchführen eines Suchlaufs in einer bereichsbasierten Wegleitdatenbank beinhaltet, welche Einträge entsprechend zu den Bereichen der Kennungen der angerufenen Partei besitzt.
Verfahren zum Wegleitlenken von Kurzmitteilungsdienstnachrichten, welche an portierte mobile Teilnehmer gerichtet sind, wobei das Verfahren aufweist: bei einem Telekommunikationsnetzwerk-Wegleitelement (302), welches SS7-Signalübertragungsfähigkeiten und Übertragbarkeit- bzw. Portierbarkeit-Verarbeitungsfähigkeiten einer Mobilnummer beinhaltet: (a) Empfangen einer Kurzmitteilungsdienstnachricht von einer Mobil-Vermittlungsstelle (112); (b) Bestimmen, ob die Portierbarkeits-Verarbeitung der Mobilnummer für die Kurzmitteilungsdienstnachricht erforderlich ist; (c) in Antwort auf das Bestimmen, dass die Portierbarkeits-Verarbeitung der Mobilnummer für die Kurzmitteilungsdienstnachricht erforderlich ist, Durchführen eines Suchlaufs in einer Mobilnummer-Portierbarkeitsdatenbank, welche in dem Telekommunikationsnetzwerk-Wegleitelement (302) platziert ist, um Wegleitinformation für die Kurzmitteilungsdienstnachricht zu bestimmen; und dadurch gekennzeichnet, dass: (d) ein Punktcode des Telekommunikationsnetzwerk-Wegleitelements (302) in ein entstehendes Punkt-Codefeld der Kurzmitteilungsdienstnachricht eingefügt wird und die Kurzmitteilungsdienstnachricht an eine zweite Mobil-Vermittlungsstelle (120) basierend auf der Wegleitinformation weitergeleitet wird.
Verfahren nach einem der Ansprüche 1 bis 13, in welchem die Schritte bei einem Signalübertragungspunkt (STP) durchgeführt werden.
Verfahren nach einem der Ansprüche 1 bis 13, in welchem die Schritte bei einem SS7/IP-Gateway bzw. -Netzübergang durchgeführt werden.
Telekommunikationsnetzwerkelement (302), welches die Funktionalität einer SS7-Signalübertragung und die Funktionalität einer Mobilnummer-Portierbarkeits-Verarbeitung beinhaltet, welches aufweist: (a) ein Kommunikationsmodul (308) zum Empfangen von Nachrichten, wobei die Nachrichten jeweils eine Kennung einer angerufenen Partei beinhalten, welche früher mit einer Teilnehmeraufzeichnung in einem ersten HLR bzw. Heimatregister in einem Netzwerk eines ersten Service-Providers verbunden war; (b) eine erste Datenbank (370), welche in dem Telekommunikationsnetzwerk-Wegleitelement (302) platziert ist, welche Information enthält, ob das Portierbarkeits-Verarbeiten der Mobilnummer für die Nachrichten und die Information erforderlich ist oder ob die in jeder Nachricht identifizierte angerufene Partei in ein Netzwerk eines zweiten Service-Providers, welches ein zweites HLR beinhaltet, portiert wurde, und (c) ein Datenbank-Steuergerät (346) zum Bestimmen, basierend auf der Information in der ersten Datenbank (370), ob die Mobilnummer-Portierbarkeits-Verarbeitung für jede Nachricht erforderlich ist und ob die angerufene Partei ein einportierter Teilnehmer ist, und dadurch gekennzeichnet, dass in Antwort auf das Bestimmen, dass die Mobilnummer-Portierbarkeits-Verarbeitung für jede Nachricht erforderlich ist und dass die angerufene Partei ein einportierter Teilnehmer ist, Einfügen eines Punktcodes des Telekommunikationsnetzwerk-Wegleitelementes in ein entstehendes Punktcodefeld der Nachricht und Weiterleiten der Nachricht an das zweite HLR.
Telekommunikationsnetzwerk-Wegleitelement (302) nach Anspruch 16, in welchem das Kommunikationsmodul (308) ein Signalisiersystem-7-Verbindungsinterface-Modul besitzt, welches für das Übertragen eines Nachrichtenteils fähig ist.
Telekommunikationsnetzwerk-Wegleitelement (302) nach Anspruch 16, in welchem das Kommunikationsmodul (308) ein Datenkommunikationsmodul beinhaltet, welches für das Übertragen eines Steuerungsprotokoll/Internetprotokoll-Transportadapter-Schicht-Interface fähig ist.
Telekommunikationsnetzwerk-Wegleitelement, welches SS7-Signalübertragungsfähigkeiten und Fähigkeiten zum Nummer-Portierbarkeits-Verarbeiten besitzt, wobei das Telekommunikationsnetzwerk-Wegleitelement (302) aufweist: (a) ein Kommunikationsmodul (308) zum Empfangen einer ersten Nachricht von einer Mobilvermittlungsstelle (112) in einem Netzwerk eines ersten Service-Providers; (b) eine erste Datenbank (370), welche Einträge entsprechend den Kennungen der angerufenen Partei enthält, wobei die Einträge jeweils individuelle Mobilteilnehmernummer-Portierbarkeitsinformation beinhalten; und (c) ein Datenbanksteuergerät (346), um zu bestimmen, ob basierend auf der Information in der ersten Datenbank (370) eine Nummer-Portierbarkeits-Verarbeitung für die erste Nachricht erforderlich ist, und in Antwort auf das Bestimmen, dass Nummer-Portierbarkeits-Verarbeitung für die erste Nachricht erforderlich ist, zu bestimmen, ob die erste Nachricht Wegleitinformation für einen Teilnehmer anfordert, dessen Verzeichnisnummer von einem ersten HLR (114) in dem Netzwerk des ersten Service-Providers herausportiert wurde, und dadurch gekennzeichnet, dass in Antwort auf das Bestimmen, dass die Teilnehmernummer aus dem Netzwerk des ersten Service-Providers herausportiert wurde, eine Antwort mit Hilfe des ersten HLR (114) formuliert wird, welche Wegleitinformation zum Kontaktieren des Netzwerkes des zweiten Service-Providers beinhaltet, und Weiterleiten der Antwort an das MSC (112) in dem Netzwerk des ersten Service-Providers.
Telekommunikationsnetzwerk-Wegleitelement (302) nach Anspruch 19, in welchem die erste Nachricht eine Sende-Wegleitinformationsnachricht ist.
Telekommunikationsnetzwerk-Wegleitelement (302) nach Anspruch 19, in welchem die erste Nachricht eine Sitzungsinitiier-Protokollnachricht ist.
Telekommunikationsnetzwerk-Wegleitelement (302) nach Anspruch 19, in welchem das Datenbanksteuergerät (346) bestimmt, ob die Mobilnummer-Portierbarkeits-Verarbeitung durch das Überprüfen wenigstens eines der Parameter des Übertragungstyps, des globalen Ti telanzeige-Nummerierungsplans und des Adressenursprungs der Nachricht erforderlich ist.
Signalübertragungspunkt (302), welcher aufweist: (a) eine interne Mobilnummer-Portierbarkeit-Datenbank (370), welche Information für das Antworten auf Anforderungen für Wegleitinformation für portierte Mobilnummern, im Auftrag eines HLR (114), enthält; und (b) ein Datenbanksteuergerät (346), um einen Suchlauf in der Mobilnummer-Portierbarkeit-Datenbank in Antwort auf eine Anforderung für Wegleitinformation für eine portierte Mobilnummer und für das Antworten im Auftrag eines HLR (114) durchzuführen, wobei Information benutzt wird, welche von der Mobilnummer-Portierbarkeit-Datenbank (370) extrahiert ist.