DE69925171T2

DE69925171T2 - Routingelement zum Routen einer Signalisierungsnachricht durch ein Kommuni- kationsnetzwerk

Info

Publication number: DE69925171T2
Application number: DE69925171T
Authority: DE
Inventors: Fulton Robert WEST; Matthew Thomas MCCANN; Raghavendra Cary GOPALA RAO
Original assignee: Tekelec Inc
Current assignee: Tekelec Global Inc
Priority date: 1999-12-23
Filing date: 1999-12-23
Publication date: 2006-01-19
Anticipated expiration: 2019-12-24
Also published as: ATE295037T1; EP1247378A1; DE69925171D1; AU2386500A; EP1247378A4; WO2001048981A1; EP1247378B1

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft das Routing von Signalisierungsnachrichten in einem Kommunikationsnetz und insbesondere Verfahren und Systeme zum Liefern eines Vermittlungsknotens, welcher eine flexible Funktionalität zum Routen von Nachrichten enthält.
Stand der Technik
Innerhalb der globalen drahtlosen Telekommunikationsindustrie ist der derzeitige Trend in der Netzwerktechnologie zwischen auf einem globalen System für mobile Kommunikationen (GSM) und American National Standards Institute (ANSI)-41 basierenden Architekturen unterteilt. In vieler Hinsicht sind sich auf GSM und ANSI-41 basierende Netze sehr ähnlich, wobei die Hauptunterschiede zwischen den zwei Technologien einfach die Protokolle, welche zum Kommunizieren zwischen den verschiedenen Netzentitäten verwendet werden, und die Operationsfrequenzen der Kommunikationshandapparate selbst betreffen. Zur Klarheit werden die Erörterungen der vorliegenden Erfindung an sich von nun an auf Netzausführungen der GSM-Art beschränkt sein. Es sollte jedoch klar sein, dass die vorliegende Erfindung ähnlich in einem ANSI-41-Netz, einem Netz für persönliche Kommunikationsdienste (PCS) oder einem Netz einer ähnlichen Art ausgeübt werden kann.
Eine typische Architektur eines GSM-Netzes ist in 1 veranschaulicht. Wie in 1 gezeigt, beinhaltet das typische GSM-Netz, welches allgemein durch die Nummer 100 gezeigt wird, eine Anzahl von Funktionselementen oder Funktionsknoten, welche entsprechend aneinander angeschlossen sind, um den erwünschten Gesamtnetzdienst zu erhalten. Diese Netzwerkknoten beinhalten ein Heimatregister (HLR) 116, ein Besucherregister (VLR) 118, eine Geräteidentifizierungsdatei (EIR) 120, ein Berechtigungszentrum (AuC) 122, eine Mobilfunk-Vermittlungsstelle (MSC) 110 und eine Netzübergangs-Funkvermittlung (GMSC) 112. Kurz gefasst ist das HLR 116 eine Datenbank, welche zum Speichern von Teilnehmerinformationen für alle Kunden innerhalb des Hausdienstleistungsgebietes des GSM-Dienstanbieters verwendet wird. Das HLR 116 ist funktionell durch ein Signalisierungsnetz mit anderen Dienstleistungsgebieten verbunden, damit Teilnehmerinformationen effektiv zwischen geografisch unterschiedlichen Netzen gemeinsam genutzt werden können, ein Kennzeichen, welches ein nahtloses Verbindungsnetz-Roaming ermöglicht. Wie das HLR 116 ist auch das VLR 118 eine Datenbank, welche Teilnehmerinformationen enthält. Das VLR 118 wird jedoch insbesondere zum Speichern von Informationen verwendet, welche Teilnehmer betreffen, die sich nicht in ihrem Hausdienstleistungsgebiet befinden. Genauer befindet sich das VLR 118 dort, wo auf das Roaming bezogene Daten für einen Kunden gespeichert werden, wenn der Kunde seinen Handapparat außerhalb seines bezeichneten Hausdienstleistungsgebietes aktiviert. Der EIR-Knoten 120 speichert Informationen, welche die Identifikationsseriennummern der Handapparate aller Kunden betreffen, welche innerhalb des Dienstleistungsgebietes aktiviert wurden, wobei der AuC-Knoten 122 Sicherungs- oder Verschlüsselungscodedaten enthält, welche mit jedem der Handapparate assoziiert werden.
Man kann sich die oben beschriebenen vier Netzelemente (HLR, VLR, EIR, AuC) im Wesentlichen als Datenbanken oder Datenbankverarbeitungsknoten vorstellen. Im Gegensatz zu diesen Datenbankknoten werden die MSC 110 und GMSC 112 allgemein als Netzvermittlungselemente identifiziert. Unter den vielen Funktionen derselben sind die MSC 110 und GMSC 112 für das Bestimmen zuständig, welche Zellenstelle einen Anruf in Besitz nehmen wird. Solch eine Gesprächsumschaltungssteuerung wird durch eine Kommunikationsverbindung zwischen der MSC 110 und einem zugeordneten Basisstationscontroller (BSC)/ Funk-Basisstation (BTS)-Paar 124 ermöglicht. Eine Tx/Rx-Zellenstelle 126 kann mit jedem BTS/BSC-Paar 124 assoziiert werden. Die GMSC 112 weist den zusätzlichen Unterschied auf, dass sie eine Netzübergangsschnittstelle zum öffentlichen Fernsprechwählnetz (PSTN) 114 liefert; ansonsten ähnelt sich die Funktionalität der MSC 110 und der GMSC 112 sehr.
Wie allgemein in 1 veranschaulicht, ist zudem die GMSC 112 auch über Signalisierungsverbindungen an die oben beschriebenen vier Datenbankknoten gekoppelt und an sich wird der gesamte Signalisierungsnachrichtenzugriff auf diese Datenbankknoten durch die GMSC gesteuert und verwaltet. Zwar wurde dies nicht in 1 veranschaulicht, aber die MSC kann auch direkt an die Datenbankknoten gekoppelt sein.
Für die vorliegende Erfindung sind die Signalisierungsaspekte des oben beschriebenen GSM-Netzes von besonderer Relevanz, insbesondere jene Aspekte, welche mit den Signalisierungsinteraktionen zwischen einem HLR-Datenbankknoten und einem Knoten einer MSCoder GMSC-Art assoziiert werden. Um diese Signalisierungsinteraktionen besser zu verstehen, ist unten eine detailliertere Erklärung der HLR-Operation geliefert.
Innerhalb eines drahtlosen GSM-Kommunikationsnetzes ist jedem Handapparat 128 eines Mobiltelefons eine einmalige Identifikationsnummer zugewiesen, welche als internationale Mobilfunkteilnehmerkennungs- (IMSI) Identifikationsnummer bekannt ist. Bei europäischen Netzausführungen der GSM-Art, wird der IMSI-Code üblicherweise mit einem bestimmten Telefonhandapparat assoziiert. In solchen Netzen kann jedem Benutzer auch eine oder mehrere Nummern eines Mobiltelefon-ISDN-Netzes (MSISDN) zugewiesen werden. In der drahtlosen Telekommunikationsindustrie sind die MSISDN-Nummern bis zu den Telefonnummern mit 10 Ziffern in einem herkömmlichen nordamerikanischen verdrahteten Netz analog. Die Tatsache, dass mehrere MSISDN-Nummern mit einer einzigen IMSI-Nummer assoziiert werden können, zeigt, dass mehr als eine MSISDN-Nummer zugeordnet und verwendet werden kann, um einen einzigen Mobiltelefonhandapparat zu erreichen. Es sollte klar sein, dass in dieser Offenbarung der Ausdruck „Mobilfunk-Identifikationsnummer" (MIN) allgemein verwendet wird, um auf die IMSI, das MSISDN, den Mobilfunk-Globaler-Titel bzw. Mobile Global Title (MGT), die ANSI-Mobilfunk-Identifikationsnummern (MIN) und Mobilfunkverzeichnisnummern (MDN) und andere mit Teilnehmern oder Diensten in einem drahtlosen Kommunikationsnetz assoziierte Identifikationsnummern Bezug zu nehmen.
In jedem Fall wird eine MSISDN-Nummer gewählt, sobald ein Benutzer mit einem bestimmten Mobiltelefonhandapparat kommunizieren will. Eine MSC oder GMSC bestimmt durch das Analysieren eines Teils der gewählten MSISDN-Nummer das bestimmte HLR, welches die Routinginformationen speichert, welche mit dem angerufenen Mobiltelefon assoziiert werden. Durch das Auslesen und Verwenden solcher Routinginformationen ist das GSM-Netz fähig das angerufene Mobiltelefon in Erwiderung auf einen Anrufversuch zu lokalisieren, so dass eine Anrufverbindung zwischen der anrufenden Partei und dem angerufenen Mobiltelefon hergestellt werden kann. Es sollte auch klar sein, dass eine MSC abhängig vom Wesen des Anruf- oder Signalisierungsereignisses alternativ den HLR-Suchlauf basierend auf der mit der angerufenen oder anrufenden Partei assoziierten IMSI- oder MSISDN-Nummer analysiert und durchführt.
2 veranschaulicht eine typische GSM-Netzarchitektur, welche allgemein durch die Nummer 150 gezeigt ist und eine GMSC 154 beinhaltet, welche mit sowohl einer MSC 152 als auch einer einzelnen HLR-Einheit 156 verbunden ist. Die GMSC 154 beinhaltet eine Routingtabelle 160, wohingegen das HLR 156 eine Datenbanktabelle 158 beinhaltet. 3 veranschaulicht auch eine typische GSM-Netzarchitektur, welche allgemein durch die Nummer 180 gezeigt wird und eine GMSC 182 beinhaltet, welche mit mehreren HLR-Einheiten verbunden ist. Genauer ist eine GMSC 182 über Signalisierungsverbindungen mit dem HLR A 186, HLR B 190 und HLR C 194 und notwendigerweise mit den HLR-Datenbanktabellen 188, 192 bzw. 196 verbunden. In den 2 und 3 können die GMSCs 154 und 182 am SS7-Netz 162 angeschlossen sein.
In den in den 2 und 3 veranschaulichten Beispielen ist jedes der HLRs zum Bedienen eines im Voraus bestimmten Blocks an MSISDN-Nummern des Teilnehmers vorgesehen. Im Allgemeinen wird eine bestimmte Reihe oder ein bestimmter Block an MSISDN (oder IMSI-) Nummern jedem HLR in einem Netz des Dienstanbieters im Voraus zugeordnet. Es sollte klar sein, dass die in den 2 – 3 gezeigten Strukturen der HLR-Datenbank und GMSC-Routingtabelle nur für das höhere Informationsspeicherkonzept veranschaulichend sind und nicht die Ist-Datenstrukturen darstellen sollen, welche typischerweise in solchen Netzwerkknoten ausgeführt werden würden. In vielen Fällen können die Dienstanbieter diese Blöcke zugeordneter Nummern innerhalb einer gegebenen HLR-Einheit wegen Routingbeschränkungen der MSC nicht ändern, welche mit der HLR-Einheit assoziiert wird. Folglich haben die Dienstanbieter keine Möglichkeit, ihre MSISDN-Nummerbasis dynamisch über mehrere HLRs neu zuzuordnen, um bestehende HLR-Einrichtungen effektiver zu nutzen (d.h. Lastverbund). Es sollte angemerkt werden, dass diese Beschränkung üblicherweise aus den Beschränkungen der Routingtabelle in den MSCs und allgemein nicht aus den Beschränkungen der Datenbankspeicher in den HLRs resultiert. D.h. die HLRs können zwar allgemein derart bestückt sein, Teilnehmerdateneinträge für jede IMSIoder MSISDN-Nummer zu enthalten, aber die MSCs sind üblicherweise nur zum Routen von Nachrichten basierend auf einem IMSI- oder MSISDN-Block fähig, zu welchem die IMSI- oder MSISDN-Nummer der Nachricht gehört. Diese IMSI- oder MSISDN-Blöcke bestehen aus einem sequenziellen Bereich von IMSI- oder MSISDN-Nummern. Folglich ist es die beschränkte Routingfähigkeit einer MSC oder GMSC, welche das Problem verursacht, und üblicherweise nicht die HLR-Knoten.
In 2 wird beispielsweise der gesamte Verkehr, welcher Anrufe betrifft, welche mit einer MSISDN-Nummer zwischen 9199670000 und 9199679999 assoziiert werden, durch die assoziierte GMSC 154 zum HLR A 156 geleitet werden. Da der Dienstanbieter beginnt immer mehr Kunden zu erwerben (d.h. immer mehr der MSISDN-Nummern im zugeordneten Block oder in der zugeordneten Reihe 9199670000 bis 9199679999 zuordnet), wird folglich der am HLR A-Knoten 156 erfahrene Verkehr oder der Verkehrstau zunehmen.
Bedacht sei, dass ein Dienstanbieter, welcher die in 2 veranschaulichten Netzelemente besitzt, so viele neue Kunden erworben hat, dass er sich entschieden hat in ein zusätzliches Paar an HLRs zu investieren. Dieses Szenario ist allgemein in 3 veranschaulicht, wobei die zwei zusätzlichen HLRs als HLR B 190 und HLR C 194 gekennzeichnet sind. Bei der Implementierung wird das HLR B 190 mit einem MSISDN-Nummerblock 919968000 – 9199689999 und HLR C 194 mit einem MSISDN-Nummerblock 9199690000 – 9199699999 bestückt. Diese zwei HLRs sind mit einer angrenzenden GMSC 182 verbunden und aktiviert, um alle Anrufe zu bedienen, welche den vorprogrammierten MSISDN-Blöcken derselben entsprechen.
Der Hauptnachteil solcher mehrfachen HLR-Konfigurationen ist nun verständlicher. Wie allgemein in 3 gezeigt, muss trotz der Hinzufügung der neuen HLR-Einrichtungskapazität, welche durch die Einheiten B und C dargestellt ist, der gesamte Anrufverkehr, welcher mit den MSISDN-Nummern 9199670000 – 9199679999 assoziiert wird, immer noch durch ein einzelnes HLR, HLR A 188, abgewickelt werden. Sogar wenn der Dienstanbieter keine Kunden innerhalb des Bereiches der MSISDN-Nummern von 9199680000 – 9199699999 hat, ist es für den Dienstanbieter nicht möglich, den „vollständig zugeordneten" MSISDN-Nummerblock 9199670000 – 9199679999 unter den unbenutzten Einheiten des HLR B 192 und HLR C 196 dynamisch neu zuzuordnen oder neu zu verteilen. Folglich ist es durchaus möglich, dass der Dienstanbieter in einer Situation tätig sein wird, in welcher der Verkehr zum HLR A 188 sehr überlastet ist, während die Einrichtungen des HLR B 192 und HLR C 196 völlig unbenutzt sind. Dies kann zu einer ineffizienten Verwendung installierter Einrichtungen führen, da es effizienter wäre die Last auszugleichen oder den Verkehr gleichmäßiger unter den drei HLR-Einheiten aufzuteilen.
Es sollte klar sein, dass zusätzlich zu den Anliegen der Lastverteilung ähnliche Probleme und Notwendigkeiten bestehen, welche auftreten, wenn die Portierung bzw. Übertragbarkeit von Teilnehmern von einem Dienstanbieter zu einem anderen in Betracht gezogen wird, was andernfalls als Nummerübertragbarkeit (LNP) bekannt ist. Das Hauptproblem ist wieder einmal die Fähigkeit Teilnehmerinformationen unter mehreren HLR-Knoten frei zu verteilen. Eine detaillierte Erörterung der genauen Probleme, welche mit der LNP assoziiert werden, ist nicht in dieser Offenbarung geliefert, da die höheren Probleme und Anliegen die gleichen, wie jene für das hierin beschriebene Szenario der Lastverteilung sind.
Das amerikanische Patent Nr. 5,878,347 (Joensuu und andere), (hiernach „das Patent "347"), dessen Offenbarung hiermit durch Verweis in seiner Gesamtheit enthalten ist, offenbart einen Ansatz zum Lösen einiger Probleme, welche oben identifiziert und erörtert wurden. Die im Patent "347 beschriebene Lösung beinhaltet die Ausführung eines neuen Netzwerkelements, auf welches als ein virtuelles HLR (vHLR) Bezug genommen wird. 4 der vorliegenden Anmeldung und der folgenden Beschreibung veranschaulicht die Funktion des vHLR im Patent "347. In Bezug auf das in 4 veranschaulichte Kommunikationsnetz 210 ist ein vHLR-Knoten 214 im Kommunikationsnetzweg zwischen einer GMSC-212 und einer Vielzahl von HLR-Knoten, HLR A 218, HLR B 222 und HLR C 226, angeordnet. Die HLRs 218, 222 und 226 beinhalten die Teilnehmerdatenbanken 220, 224 bzw. 228. Die GMSC 212 sendet Signalisierungsnachrichten zum vHLR-Knoten 214, welcher eine Teilnehmerinformation anfordert, wobei der bestimmte Teilnehmer mit einer Mobiltelefonidentifikationsnummer einer IMSI- oder MSISDN-Art assoziiert wird. Das vHLR 214 beinhaltet keine Teilnehmerinformationen; das vHLR 214 beinhaltet eher eine Routingtabelle 216, welche IMSI- oder MSISDN-Nummern mit einem bestimmten HLR korreliert. Genauer beinhaltet die Routingtabelle 216 Informationen, welche IMSI- oder MSISDN-Nummern mit einer entsprechenden Netzadresse in Verbindung bringen, welche mit dem HLR assoziiert wird, welches diesen IMSI- oder MSISDN-Teilnehmer bedient.
Die durch das Patent "347 offenbarte Technik zum Routen von Informationen ist ein entscheidendes Element der hierin beschriebenen Erfindung. Wie allgemein in 4 veranschaulicht, führt ein vom SS7-Netzwerk 162 ausgehender Anruf zu einem MSISDN = 9199690000 (232), welches an die GMSC 212 übertragen wird. Die GMSC 212 erzeugt eine Nachricht 234 und sendet die Nachricht zum vHLR 214, und wenn der vHLR-Knoten 214 eine Nachricht 234 von der assoziierten GMSC 212 empfängt, wird die Nachricht an den vHLR-Knoten 214 adressiert und direkt zu demselben weitergesendet. Der vHLR-Knoten 214 führt einen Tabellensuchlauf durch, wie oben beschrieben wurde, und routet die Nachricht erneut zum angemessenen HLR-Knoten, in diesem Fall zum HLR C 228. Die Funktion des erneuten Routens wird durch das Ändern des Zielpunkcodes (DPC) des Routingetiketts der Nachricht 236 so erreicht, dass der ursprüngliche DPC (PC = vHLR) durch einen neuen DPC (PC = HLR C) ersetzt wird. Es ist wichtig und sollte angemerkt werden, dass der vHLR-Knoten 214 nicht die Ursprungsvermittlungsadresse (OPC) des Routingetiketts der Nachricht ändert. D.h., die OPC der eingehenden Nachricht 234 gleicht der OPC der abgehenden Nachricht 236, welche der Punktcode der GMSC 212 ist. Folglich kommt die Nachricht am HLR C 228 mit einer OPC an, welche gleich dem Punktcode des GMSC-Knotens 212 ist. Das HLR C 228 antwortet dann mit einer Nachricht 238, welche an die GMSC 212 adressiert ist. Die Antwortnachricht 238 des HLR C wird nicht durch den vHLR-Knoten 214 zurückgeleitet.
Zwar kann solch ein Routingverfahren ein oder mehrere „Funkfelder" des Routings bewahren, aber aus Perspektive der Netzverwaltung stellt dieses Routingverfahren mindestens ein bedeutendes Problem dar. D.h., wenn ein HLR unfähig werden sollte einen Dienst zu liefern, erfordert die SS7-Signalisierungskonvention, dass das HLR eine den SP vor dem beeinträchtigten Zustand oder dem Außerbetriebszustand des HLR warnende Nachricht zu irgendeinem Signalisierungspunkt (SP) sendet, welcher versucht mit demselben zu kommunizieren. Angesichts des oben beschriebenen Nachrichtenflusses wird klar sein, dass in solch einem Außerbetrieb-Szenario das HLR C 226 eine Netzverwaltungsnachricht zur Nachrichtenquelle der eingehenden HLR C-Nachricht 236 senden würde. Die Nachrichtenquelle der eingehenden HLR C-Nachricht 236 wird durch das OPC-Feld des Routingsetiketts der Nachricht 236 identifiziert. Wie oben beschrieben wurde, ändert der Knoten des vHLR 214 nicht das OPC-Feld des Routingetiketts, sondern überlässt stattdessen den OPC-Satz der Adresse der GMSC 212. Folglich werden Netzverwaltungsnachrichten, welche durch das HLR C 226 gesendet wurden, an die GMSC 212 adressiert werden. Das Problem mit solch einem Nachrichtenroutingschema ist, dass die GMSC 212 keine „Kenntnis" darüber besitzt eine Nachricht zum HLR C 226 gesendet zu haben. Es wird wieder einmal klar sein, dass der DPC der Nachricht 234, welche ursprünglich durch die GMSC 212 gesendet wurde, die Netzadresse des vHLR 214 war. D.h. die GMSC 212 besitzt die Kenntnis über eine an das vHLR 214 gesendete Nachricht, aber keine Kenntnis über eine bestimmte Nachricht, welche für das HLR C 226 bestimmt ist. Die Implementierung solch eines SS7-Nachrichtenroutingschemas würde daher ein großes Problem für Betreiber von SS7-Netzen darstellen, welche eine große Anzahl von Netzelementen erworben und eingesetzt haben, welche gemäß SS7-Kommunikationsprotokollen der Industrienorm und Netzverwaltungsverfahren arbeiten.
Daher bedarf es einem neuartigen System und Verfahren zum Umleiten von Signalisierungsnachrichten unter mehreren HLR, EIR, AuC und anderen ähnlichen Knoten der Signalisierungsdatenbankart, wobei sich das Routen von Nachrichten derart ereignet, um eine Übereinstimmung mit bestehenden Netzverwaltungs-Signalisierungsprotokollen der Industrienorm zu wahren.
US-A-5,457,736 beschreibt ein System und Verfahren, welche adaptiert wurden mikrozellulare persönliche Kommunikationsdienste (PCS) durch die Verwendung einer verbesserten Architektur einer verteilten Funkanschlusssteuerung (DRPC) zu liefern. Es erzielt die erwünschte Übergabe mit einer minimalen Wirkung der bestehenden eingebetteten Basis an Schaltern durch das Erzeugen erneuter Anrufe von Soll-Funkanschlusssteuerungen (RPCs) durch die Schalter, um die RPCS zu verankern und die Trägerkanäle ohne das Wissen der Schalter intern zu überbrücken. Das System weist ein Heimatregister (HLR) zum Speichern und Liefern von Teilnehmerdaten und Verfolgen, wo die mobilen Anschlüsse registriert sind, auf, um Anrufe zuzustellen. Das System beinhaltet zudem eine Dienststeuerungsstelle (SCP), welche in elektrischer Kommunikation mit dem Schalter geliefert ist.
US-A-5,878,347 beschreibt ein Verfahren und eine Vorrichtung zum Übertragen eines Telekommunikationsdatensignals zu einem Mobiltelefon, welches von einem ersten Heimatregister (HLR) zu einem zweiten HLR verlegt wurde. Solch ein Datensignal weist ein eingehendes Sprachdatensignal und ein Datensignal eines Kurznachrichtendienstes (SMS) auf. Eine Netzadresse, welche ein HLR darstellt, welches mit dem Mobiltelefon und der mit dem Mobiltelefon assoziierten Mobilfunk-Identifikationsnummer assoziiert wird, werden in der zentralen Datenbasis korreliert und gespeichert. Jedes Mal, wenn ein eingehendes Datensignal durch den Netzübergangsknoten innerhalb des Telekommunikationsnetzes empfangen wird, wird ein die Routinginformation für dieses Datensignal anforderndes Signal zur zentralen Datenbasis übertragen anstelle das HLR zu bedienen.
Offenbarung der Erfindung
Nach einem Aspekt beinhaltet die vorliegende Erfindung einen flexiblen Routingknoten. Der flexible Routingsknoten beinhaltet ein Kommunikationsmodul, welches zum Übertragen und Empfangen von Datenpaketen über ein Netzwerk fähig ist. Eine bereichsbezogene Datenbank beinhaltet bereichsbezogene Regeldatensätze, welche durch Blöcke von Identifikationsnummern mit einem Index versehen sind. Eine ausnahmebezogene Datenbank beinhaltet ausnahmebezogene Regeldatensätze, welche durch eine einzige Identifikationsnummer mit einem Index versehen sind. Eine Subsystemsteuerung der Datenbank greift auf mindestens eine der Datenbanken zu, um Routinginformationen für das Datenpaket abzufragen. Da der flexible Routingknoten sowohl bereichsbezogene als auch ausnahmebezogene Datenbanken enthält, wird die Flexibilität beim Zuordnen der Mobilfunk-Identifikationsnummern unter den HLRs erhöht. Die Subsystemsteuerung der Datenbank ist adaptiert die Signalisierungsnachricht anfangs zur ausnahmebezogenen Datenbank zu leiten und einen Suchlauf in der ausnahmebezogenen Datenbank basierend auf einer Mobilfunk-Identifikationsnummer in der Signalisierungsnachricht durchzuführen, um die Routinginformation zu lokalisieren; die Subsystemsteuerung der Datenbank ist adaptiert die Signalisierungsnachricht zur bereichsbezogenen Datenbank in Erwiderung auf das Scheitern des Lokalisierens der Routinginformation in der ausnahmebezogenen Datenbank zu leiten; und die Subsystemsteuerung der Datenbank ist adaptiert die von der bereichsbezogenen Datenbank zurückgesendete Routinginformation in die Signalisierungsnachricht einzubauen.
Folglich ist es eine Aufgabe der vorliegenden Erfindung einen flexiblen Routingknoten zu liefern, welcher zum Durchführen der Suchläufe sowohl der bereichsbezogenen als auch ausnahmebezogenen Datenbank fähig ist.
Es ist eine andere Aufgabe der vorliegenden Erfindung einen flexiblen Routingknoten zu liefern, welcher mit den Netzverwaltungsverfahren der Industrienorm übereinstimmt.
Einige Aufgaben der Erfindung wurden hierin oben erwähnt und andere Aufgaben werden offensichtlich werden, während die Beschreibung fortfährt, wenn in Verbindung mit den beiliegenden Zeichnungen genommen, die hierin unten am besten beschrieben wurden.
Kurze Beschreibung der Zeichnungen
1 ist ein Netzdiagramm, welches eine Architektur eines drahtlosen GSM-Telekommunikationsnetzes des Stands der Technik veranschaulicht.
2 ist ein Netzdiagramm, welches eine Ausführung eines drahtlosen GSM-Telekommunikationsnetzes des Stands der Technik veranschaulicht, welches einen einzigen HLR-Knoten beinhaltet.
3 ist ein Netzdiagramm, welches eine Ausführung eines drahtlosen GSM-Telekommunikationsnetzes des Stands der Technik veranschaulicht, welches mehrere HLR-Knoten beinhaltet.
4 ist ein Netzdiagramm, welches eine Architektur eines drahtlosen GSM-Telekommunikationsnetzes des Stands der Technik veranschaulicht.
5 ist ein schematisches Diagramm eines Vermittlungsknotens eines Zeichengabe-Transferpunktes des Stands der Technik.
6 ist ein schematisches Netzdiagramm, welches ein erstes Routingdatenbank-Zugriffsszenario nach einer bevorzugten Ausführungsform eines flexiblen Routingknotens der vorliegenden Erfindung veranschaulicht.
7 ist ein schematisches Netzdiagramm, welches ein zweites Routingdatenbank-Zuriffsszenario nach einer bevorzugten Ausführungsform eines flexiblen Routingknotens der vorliegenden Erfindung veranschaulicht.
8 ist ein schematisches Netzdiagramm, welches eine alternative Netzwerkimplementierung eines flexiblen Routingknotens der vorliegenden Erfindung veranschaulicht.
9a ist eine Tabelle, welche ein Beispiel einer G-FLEX^TM-Datenbankstruktur veranschaulicht, welche in einer bevorzugten Ausführungsform eines flexiblen Routingknotens der vorliegenden Erfindung verwendet wird.
9b ist eine Tabelle, welche ein Beispiel einer GTT-Datenbankstruktur veranschaulicht, welche in einer bevorzugten Ausführungsform eines flexiblen Routingknotens der vorliegenden Erfindung verwendet wird.
10a ist eine Tabelle, welche teilweise den Inhalt einer Signalisierungsnachricht veranschaulicht, welche durch einen flexiblen Routingsknoten der vorliegenden Erfindung in einem ersten Beispielszenario empfangen und verarbeitet wird.
l0b ist eine Tabelle, welche teilweise den Inhalt einer Signalisierungsnachricht veranschaulicht, welche durch einen flexiblen Routingsknoten der vorliegenden Erfindung in einem zweiten Beispielszenario empfangen und verarbeitet wird.
l0c ist eine Tabelle, welche teilweise den Inhalt einer Signalisierungsnachricht veranschaulicht, welche durch einen flexiblen Routingsknoten der vorliegenden Erfindung in einem dritten Beispielszenario empfangen und verarbeitet wird.
11 ist ein Ablaufplan, welcher das durch einen flexiblen Routingknoten der vorliegenden Erfindung ausgeführte Übersetzungsverfahren veranschaulicht.
Detaillierte Beschreibung der Erfindung
Nach einer Ausführungsform beinhaltet die vorliegende Erfindung einen flexiblen Routingknoten zum Kommunizieren mit einer GMSC und HLRs in einem Netzwerk. In einer bevorzugten Ausführungsform setzt ein flexibler Routingknoten eine interne Architektur ein, welche der eines Hochleistungs-STP ähnelt, welcher durch den Rechtsnachfolger der vorliegenden Anmeldung als EAGLE^®STP auf den Markt gebracht ist. Ein Blockdiagramm eines EAGLE^®STP wird in 5 gezeigt. Eine detaillierte Beschreibung des EAGLE^®STP kann in Eagle Feature Guide PN/9110-1225-01, Rev. B, Januar 1998, veröffentlicht durch Tekelec, gefunden werden, dessen Offenbarung hiermit durch Verweis hierin enthalten ist. Wie in dieser Veröffentlichung beschrieben, beinhaltet ein EAGLE^®STP 250 die folgenden Subsysteme: ein Wartungs- und Verwaltungssubsystem (MAS) 252, ein Kommunikationssubsystem 254 und ein Anwendungssubsystem 256. Das MAS 252 liefert Wartungskommunikationen, die Ureingabe, periphere Dienste, die Alarmbehandlung und Systemplatten. Das Kommunikationssubsystem 254 beinhaltet einen Interprozessor-Nachrichtenübertragungs-Bus (IMT-Bus), welcher der Hauptkommunikationsbus unter allen Subsystemen im EAGLE^®STP 250 ist. Dieses Hochgeschwindigkeits-Kommunikationssystem wirkt wie zwei sich gegenläufig drehende serielle Busse mit 125 Mbps Das Anwendungssubsystem 256 beinhaltet Anwendungskarten, welche zum Kommunizieren mit anderen Karten durch die IMT-Busse fähig sind. Zahlreiche Arten von Anwendungskarten können im Zeichengabetransferpunkt (STP) 250 einschließlich Folgendem enthalten sein: einem Linkschnittstellenmodul bzw. Verbindungsschnittstellenmodul (LIM) 258, welches SS7-Verbindungen und X.25-Verbindungen liefert, ein Anwendungskommunikationsmodul (ACM) 260, welches eine TCP/IP-Schnittstelle zu einem externen Überwachungsgerät über Ethernet liefert, und ein Anwendungsdienstmodul (ASM) 262, welches eine Übersetzung des Global Title, ein Netzübergangsscreening und andere Dienste liefert. Ein Übersetzungsdienstmodul (TSM) 264 kann auch zur Nummerübertragbarkeit geliefert werden. Eine detaillierte Beschreibung des EAGLE^®STP ist in dem oben genannten Feature Guide geliefert und muss nicht hierin detailliert beschrieben werden.
6 ist ein schematisches Diagramm eines vereinfachten GSM-Netzes 300, welches einen flexiblen Knoten 302 nach einer Ausführungsform der vorliegenden enthält. Zusätzlich zum flexiblen Routingknoten 302 beinhaltet das GSM-Netz 300 ein SS7-Signalisierungsnetz 346, eine Netzübergangs-Funkvermittlung (GMSC) 348, ein Internet-Protokoll-Netz (IP-Netz) 350, ein erstes Heimatregister (HLR) 352, ein zweites HLR 354 und ein drittes HLR 356.
In der veranschaulichten Ausführungsform beinhaltet der flexible Routingsknoten 302 einen Hochgeschwindigkeitskommunikationsbus 304 der Interprozessor-Nachrichtenübertragung (INT). Eine Anzahl von verteilten Verarbeitungsmodulen oder Verarbeitungskarten sind auf kommunikative Weise an den IMT-Bus 304 gekoppelt, welche Folgendes beinhalten: ein Paar an Wartungs- und Verwaltungssubsystemprozessoren (MASPs) 306, ein SS7 freigegebenes Verbindungsschnittstellenmodul (LIM) 308, ein IP freigegebenes Datenkommunikationsmodul (DCM) 336 und ein G-FLEX^TM-Datenbankmodul (GDM) 322. Diese Module sind physikalisch am IMT-Bus 304 durch die Busschnittstellen 318, 324 bzw. 338 angeschlossen. Zur Einfachheit der Veranschaulichung ist nur ein einziges LIM 308, GDM 322 und DCM 336 in 6 enthalten. Es sollte jedoch klar sein, dass die verteilte Mehrprozessorarchitektur des Knotens 302 den Einsatz mehrere LIM-, GDM- und DCM-Karten ermöglicht, welche alle gleichzeitig am IMT-Bus 304 angeschlossen sein könnten.
Das MASP-Paar 306 implementiert die oben beschriebenen Wartungs- und Verwaltungssubsystemfunktionen. Da das MASP-Paar 306 für eine Erörterung der flexiblen Routingattribute der vorliegenden Erfindung nicht insbesondere relevant ist, wird für eine detailliertere Beschreibung dieser Systembauteile auf die oben erwähnten EAGLE^®-Veröffentlichungen von Tekelec verwiesen.
In Hinblick auf die Funktionalität der LIM-Karte besteht in der veranschaulichten Ausführungsform das LIM 308 aus einer Anzahl von Subbauteilen, welche Folgendes beinhalten, aber nicht darauf beschränkt sind: ein Schichtverfahren 310 der SS7-MTP-Protokollschicht 1 und 2, einen Ein-/Ausgabe-Puffer oder Warteschlange 312, ein HMDC-Verfahren 314 der SS7-MTP-Protokollschicht 3, und ein HMDT-Verfahren 316. Das Schichtverfahren 310 der MTP-Protokollschicht 1 und 2 liefert die Einrichtungen, welche zum Senden und Empfangen digitaler Daten über ein bestimmtes physikalisches Medium/eine physikalische Schnittstelle notwendig sind, und um die Fehlererfassung/-korrektur und geordnete Weitersendung aller SS7-Nachrichtenpakete zu liefern. Die Ein-/Ausgabe-Warteschlange 312 liefert das temporäre Puffern eingehender und ausgehender Signalisierungsnachrich tenpakete. Das HDMC-Verfahren 314 der MTP-Protokollschicht 3 führt eine Funktion zur Selektion von Signalen durch und bestimmt effektiv, ob ein eingehendes SS7-Nachrichtenpaket eine interne Verarbeitung erfordert oder einfach durchzuschalten ist, d.h. zu einem anderen Knoten zu routen ist. Das HDMT-Verfahren 316 handhabt das interne Routing der SS7-Nachrichtenpakete, welche eine zusätzliche Verarbeitung vor dem Endrouting erfordern.
Allgemein liefert eine GDM-Karte die Datenbanken und Datenbanksteuerverfahren, welche zum Durchführen der erforderten Netzadressenübersetzungen notwendig sind, um die flexible Routingfunktionalität zu erzielen, welche durch die Ausführungsformen der vorliegenden Erfindung implementiert wurde. Das in 6 gezeigte GDM 322 besteht zum Teil aus einem Untermodul 326 des SCCP (Signaling Connection Corntrol Part), welches zudem eine Datenbanksubsystemsteuerung aufweist, welche als ein Verfahren 328 des Routingcontrollers der Signalisierungsverbindung (SCRC) bekannt ist. Das SCRC-Verfahren 328 ist für die Nummeraufbereitung, das Leiten eingehender SS7-Nachrichtenpakete zu entweder einem Verfahren 330 der G-FLEX^TM-Datenbank oder einem Verfahren 332 der Datenbank der Global-Title-Übersetzung (GTT) und für die Modifikation der Nachrichtenpakete zuständig, um Routinginformationen zu beinhalten, welche durch die Verfahren 330 bzw. 332 der G-FLEX^TM- oder GTT-Datenbank zurückgesendet wurden. Das SCRC-Verfahren 328 verlassende SS7-Nachrichtenpakete werden durch ein HMRT-Verfahren 334 empfangen und weiterverarbeitet. Das HMRT-Verfahren 314 ist für das externe Routing von SS7-Nachrichtenpaketen zuständig, welche keine zusätzliche Verarbeitung durch den flexiblen Routingknoten 302 erfordern. D.h., das HMRT-Verfahren 334 bestimmt zu welcher LIM- oder DCM- Karte ein SS7-Nachrichtenpaket zur anschließenden abgehenden Übertragung geleitet werden sollte. Aus 6 wird auch hervorgehen, dass das GDM 322 über eine Ethernet-Verbindung 333 an ein OAM-Subsystem 335 gekoppelt ist und von demselben bedient wird. Das OAM-Subsystem 335 ist zur Verwaltung und Wartung der G-FLEX^TMund GTT-Datenbanken 330 bzw. 332 zuständig.
Das in 6 gezeigte DCM 336 beinhaltet ein HMCG-Verfahren 340, welches für das Überwachen eines Verkehrsstaus auf den assoziierten DCM-Verbindungssätzen und das interne Übertragen dieser Verbindungs-Verkehrsstauungsinformationen zu gleichschichtigen Verfahren auf andere Module über den IMT-Bus 304 zuständig ist. Solche Verbindungs-Verkehrsstauungsinformationen werden durch das HMRT-Verfahren 334 während abgehenden Verbindungsauswahloperationen verwendet. Es sollte klar sein, dass abgehende SS7-Nachrichtenpakete, welche durch das DCM 336 geroutet werden, aus dem flexiblen Routingknoten 302 und in ein Internetprotokoll-Netz (IP-Netz) 350 übertragen werden. Da das SS7-Kummunikationsprotokoll und das IP-Kommunikationsprotokoll nicht inhärent kompatibel sind, werden alle SS7-Nachrichtenpakete, welche in das IP-Netz 350 zu senden sind, vor der Übertragung erst innerhalb eines IP-Routingumschlags gekapselt. Diese IP-Kapselung wird durch ein IP-Kapselungsverfahren 342 durchgeführt. Das IP-Kapselungsverfahren 342 ist das IP-Protokoll, welches dem Schichtverfahren 310 der SS7-MTP-Protokollschicht 1-2 des LIM-Moduls 308 entspricht. Bevorzugte Paketformate zum Kapseln verschiedener Arten von SS7-Nachrichten in IP-Pakete wird in Internet Engineering Task Force (IETF) INTERNET DRAFT mit dem Titel Transport Adapter Layer Interface, 28. Mai 1999, beschrieben, dessen Offenbarung durch Verweis vollständig hierin enthalten ist.
Die Beschreibung der hierin gelieferten LIM- und DCM-Subbauteile ist wieder einmal auf jede Subbauteile beschränkt, welche für die in den 6 und 7 veranschaulichten Beispielausführungsszenarien relevant sind. Für eine umfassende Erörterung zusätzlicher Operationen und der Funktionalität des LIM und DCM kann in den oben erwähnten Veröffentlichungen von Tekelec nachgeschlagen werden.
Insbesondere in Bezug auf das in 6 veranschaulichte Szenario ist die Netzübergangs-Funkvermittlung 348 auf kommunikative Weise über eine SS7-Kommunikationsverbindung 320 an den flexiblen Routingknoten 302 gekoppelt. Genauer ist der GMSC-Knoten 348 über die SS7-Kommunikationsverbindung 320 am LIM 308 angeschlossen. Das DCM-Modul 336 ist über eine IP-Kommunikationsverbindung am externen IP-Netz 350 angeschlossen. Innerhalb des IP-Netzes 350 liegen die HLR-Knoten 352, 354 und 356 und sind an dasselbe angeschlossen. An sich besteht ein IP-Kommunikationsweg zwischen dem DCM-Modul 336 des flexiblen Routingknotens 302 und jedem der HLR-Knoten 352, 354 und 356. Der IP-Kommunikationsweg kann ein TCP/IP oder UDP/IP sein. Es sollte klar sein, dass eine alternative Ausführungsform des flexiblen Routingknotens 302 nach einer Ausführungsform der vorliegenden Erfindung das Kommunikationsprotokoll, welches zwischen der GMSC 348 und dem flexiblen Routingknoten 302 implementiert ist, ein IP- oder anderes Protokoll, welches kein SS7-Protokoll ist, wie z.B. eine asynchrone Übermittlung (ATM) oder synchrones optisches Netz (SONST) sein. Beispielsweise könnte eine IP-Kommunikationsverbindung genauso effektiv zwischen der GMSC 348 und dem flexiblen Routingknoten 302 verwendet werden. In solch einem Fall würde ein angemessen konfiguriertes DCM-Modul das in 6 gezeigte LIM 308 ersetzen. Ähnlich könnte das zwischen dem flexiblen Routingknoten 302 und den HLR-Knoten 352, 354 und 356 implementierte Kommunikationsprotokoll ein SS7-, Zwischennorm-41- (IS-41-), GSM- oder anderes Protokoll sein, welches kein IP-Protokoll ist. Beispielsweise könnte eine SS7-Kommunikationsverbidnung zwischen dem flexiblen Routingknoten 302 und den HLR-Knoten 352, 354 und 356 eingesetzt werden. In solch einem Fall würden mehrere LIM-Module das in 6 gezeigte DCM 336 ersetzen.
Wie oben erwähnt, ist ein mit der Lastverteilung und Nummerübertragbarkeit unter mehreren HLR-Knoten assoziiertes Problem, dass herkömmliche MSCs und GMSCs nur zur blockbezogenen Adressierung fähig sind. An sich wird klar sein, dass eine der Hauptaufgaben des flexiblen Routingknotens nach einer Ausführungsform der vorliegenden Erfindung das Liefern eines Verfahrens ist, durch welches ein Netzwerkbetreiber Signalisierungsnachrichten, welche mit einem gegebenen Anruf oder einer angerufenen Partei assoziiert werden, schnell und leicht zu einem bestimmten HLR-Knoten leiten kann. Um solch eine Umleitung der Signalisierungsnachricht zu ermöglichen, setzt der flexible Routingknoten der vorliegenden Erfindung ein Paar an ergänzenden Routingdatenbanken ein, welche eine IMSI- oder MSISDN-Nummer effektiv abbilden, welche mit einer Signalisierungsnachricht zur Netzadresse des angemessenen HLR-Knotens assoziiert wird. Auf diese oben beschriebenen Datenbanken wird als G-FLEX^TM-Datenbank und GTT-Datenbank Bezug genommen.
Die 9a und 9b sind Diagramme einer Datenbankstruktur, welche in erster Linie die Schlüssel- oder Indexstrukturen der G-FLEX^TM-Datenbank und GTT-Datenbank 330 bzw. 332 veranschaulichen sollen. Es sollte klar sein, dass die in den 9a und 9b gezeigten Datensatzstrukturen und Pseudodaten der G-FLEX^TM- und GTT-Datenbank zwar für die in den 6 und 7 gezeigten Beispiele unterstützend sind, aber nur für die Grundinformationen veranschaulichend sind, welche zum Durchführen der erforderten Routingdatensuchläufe notwendig sind. In der Praxis können die Ist-Datensatzstrukturen der Datenbank und die Gesamtdatenbankkonstruktion gemäß bestimmten Implementierungserfordernissen variieren.
Das Zugriffsschema der komplementären Datenbank, welches durch den flexiblen Routingknoten der vorliegenden Erfindung eingesetzt wird, erfordert, dass die GTT-Datenbank 332 einen Satz an bereichs- oder blockbezogenen Routingregeln in Stand hält, während die G-FLEX^TM-Datenbank 330 Ausnahmen zu den blockbezogenen Routingregeln beinhaltet. Dieses Konzept ist wieder einmal allgemein in den 9a und 9b veranschaulicht. Mit bereichsbezogenen oder blockbezogenen Routingregeln ist gemeint, dass ein Block oder Bereich von Mobilfunk-Identifikationsnummern (IMSI, MSISDN, etc.) mit der Netzadresse eines bestimmten HLR, EIR, AuC, Dienststeuerungsstelle (SCP), etc., assoziiert wird. Solch eine Datenbankstruktur der bereichsbezogenen Routingregeln ähnelt den Routingsdatenbankstrukturen, welche häufig in herkömmlichen GMSC-Knoten eingesetzt werden, wie oben beschrieben wurde.
In Bezug auf 9b beinhaltet die GTT- oder bereichsbezogene Datenbank 322 Schlüsselfelder in der linken Spalte und Datenfelder in der rechten Spalte. Die Schlüsselfelder stellen Bereiche von Mobilfunk-Identifikationsnummern dar, welche mit einem bestimmten Knoten assoziiert werden. Beispielsweise spezifiziert das erste Schlüsselfeld eine minimale Mobilfunk-Identifikationsnummer von 9199670000 und eine maximale Mobilfunk-Identifikationsnummer von 9199679999. Die diesem Bereich entsprechenden Datenfelder beinhalten einen Punktcode (PC) von 3-0-2, eine Subsystemnummer (SSN) von 6 und einen Routingindikator (RI) von RT-ON-SSN für das Netzelement, welches dem Bereich in dem Schlüsselfeld entspricht. Die in den Datenfeldern beinhalteten Daten sind nur für Datenfelder veranschaulichend, welche in der bereichsbezogenen oder GTT-Datenbank 332 enthalten sein können. Ähnliche Schüssel- und Datenfelder werden für die anderen Netzelemente gezeigt.
In Bezug auf 9a beinhaltet die G-FLEX^TM- oder ausnahmebezogene Datenbank 330 Einträge bzw. Dateneingaben, welche Ausnahmen zu den Dateneingaben in der bereichsbezogenen Datenbank sind. In 9a beinhaltet die linke Spalte Schlüsselwerte für jede Dateneingabe und die rechte Spalte Datenfelder für jede Dateneingabe. Die erste Dateneingabe beinhaltet einen Schlüsselfeldwert von 9193803833. Die Datenfelder, welche dem ersten Schlüsselfeldwert entsprechen, beinhalten einen Punktcode (PC) von 3-0-3, eine Subsystemnummer (SSN) von 6, einen Routingindikator (RI) von RT-ON-SNN, einen Wert zum Auswechseln der Ziffern des Global Title der angerufenen Partei (RCGT; Replace Called Party Global Title digits) von NO, eine Entitätsadresse 303211234, welche das HLR C darstellt. Diese Datenfelder sind bloß für die Datenfelder veranschaulichend, welche in der ausnahmebezogenen oder G-FLEX^TM-Datenbank 330 enthalten sein können. Die übrigen Dateneingaben in der Datenbank 330 beinhalten ähnliche Daten für andere Netzelemente.
Die doppelte Datenbankarchitektur, welche im flexiblen Routingknoten der vorliegenden Erfindung eingesetzt ist, liefert dem Netzwerkbetreiber eine Anzahl von raffinierten Vorteilen. Beispielsweise verringert das komplementäre Wesen der zwei Datenbanken die Speichervorrichtungsanforderungen der Routingdatenbank auf ein Minimum. Zudem wird die Aufgabe des Wartens und Verwaltens des flexiblen Routingknotens dadurch sehr vereinfacht, dass nur Ausnahmen zu den herkömmlichen blockbezogenen Routingregeln explizit in die G-FLEX^TM-Datenbank eingegeben werden müssen. Wenn dies nicht der Fall ist und beispielsweise ein bestimmter Netzwerkbetreiber Daten, welche mit 500 000 Mobilfunk-Teilnehmern assoziiert werden, in einem oder mehreren HLRs gespeichert hatte, könnte vom Netzwerkbetreiber erfordert werden zumindest einen einmaligen Routingdatensatz für jeden der 500 000 Teilnehmer zu erstellen und zu speichern. Die ausnahmebezogene Struktur des Datenbanksystems des flexiblen Routingknotens erfordert in solch einem Fall einfach, dass der Betreiber einzelne Routingdatensätze in der G-FLEX^TM-Datenbank nur für jene IMSI- oder MSISDN-Nummern erstellt und speichert, welche nicht an den bereichsbezogenen oder blockbezogenen Regeln haften, welche in der GTT-Datenbank spezifiziert wurden. Beispielsweise kann, wenn eine Nummer von einem HLR zu einem anderen HLR portiert wird, die MSISDN-Nummer eine Ausnahme zu den blockbezogenen Regeln im zweiten HLR sein. In diesem speziellen Fall, in welchem alle IMSI- oder MSISDN-Nummern des Betreibers an den blockbezogenen Regeln haften, welche in der GTT-Datenbank spezifiziert wurden, wäre die G-FLEX^TM-Datenbank leer. Beim anderen Extrem, bei welchem alle IMSI- oder MSISDN-Nummern des Betreibers nicht an den allgemeinen blockbezogenen Regeln haften, welche in der GTT-Datenbank spezifiziert wurden, würde die G-FLEX^TM-Datenbank mindestens eine Dateneingabe für jede der zugeordneten Mobilfunk-Identifikationsnummern des Betreibers enthalten.
Der flexible Routingknoten nach der vorliegenden Erfindung ermöglicht eine Lastverteilung unter den HLRs. Wenn beispielsweise ein Dienstanbieter ursprünglich zwei HLRs in Betrieb aufweist und anschließend ein drittes HLR erwirbt, lässt die G-FLEX^TM-Datenbank zu, dass Nummern, welche den ursprünglichen HLRs zugeordnet wurde, dem neuen HLR neu zugeordnet werden.
In Bezug auf die G-FLEX^TM- und GTT-Übersetzungsdienste sind die Parameter, welche entweder direkt oder indirekt zum Bestimmen der Art des durch eine eingehende Signalisierungsnachricht erforderten Übersetzungsdienstes (beispielsweise G-FLEX^TM-Dienst oder GTT-Dienst) verwendet werden, in den 10a - l0c enthalten. Die linke Spalte in jeder der 10a - l0c stellt die Parameter dar, welche zum Bestimmen der Art des erforderten Übersetzungsdienstes verwendet werden. In den veranschaulichten Figuren beinhalten diese Parameter allgemein einen Routingindikator (RI), ein Parameter des Global-Title-Indikators (GTI), ein Parameter der Übersetzungsart (TT), ein Parameter des Nummerierungsplans (NP) und ein Parameter des Wesens des Adressenindikators (NAI). Diese Parameter, ihre Bedeutungen innerhalb des Kontexts eines SS7-Kommunikationsnetzes und ihr Bereich an Werten sind jemandem mit technischen Fähigkeiten sehr bekannt und werden folglich nicht detailliert erörtert werden. Es reicht wohl zu sagen, dass die bevorzugte Ausführungsform des flexiblen Routingknotens der vorliegenden Erfindung auf einige oder alle dieser Parameter angewiesen ist, um den erforderten Übersetzungsdienst zu bestimmen.
Die mittlere Spalte in jeder der 10a - l0c stellt ursprüngliche Werte, d.h. vor der Übersetzung, für die Parameter dar, welche in jeder linken Spalte veranschaulicht werden. Die rechte Spalte in jeder der 10a - l0c veranschaulicht die Werte für jedes der Parameter in der linken Spalte nach der Übersetzung. Genauer stellt die rechte Spalte in 10a Parameterwerte nach einer G-FLEX^TM-Übersetzung dar, welche in Bezug auf 6 beschrieben werden wird. Die rechte Spalte der l0b stellt Parameterwerte nach einer Standard-Übersetzung des Global Title dar, welche detailliert in Bezug auf 7 beschrieben werden wird. Schließlich stellt die rechte Spalte der l0c Parameterwerte nach einer Zwischenübersetzung des Global Title dar, welche in Bezug auf 8 detailliert beschrieben werden wird.
Wenn einmal die allgemeine Art der Übersetzungsdienstanforderung gestellt wurde (d.h. G-FLEX^TM-Übersetzung oder GTT-Übersetzung), wird als nächstes die bestimmte Art des Übersetzungsdienstes bestimmt. Insbesondere in Bezug auf die G-FLEX^TM-Übersetzungsdienste könnten die zur Verfügung stehenden Dienstarten GSM-Dienste enthalten, wie z.B. HLR, EIR, AuC, etc. Die Bestimmung des bestimmten G-FLEX^TM-Übersetzungsdienstes wird durch eine Prüfung eines Parameters der Subsystemnummer (SNN) durchgeführt, welches im Feld der Adresse der angerufenen Partei (CdPA) der Signalisierungsnachricht enthalten ist. Das SSN-Parameter ist jemanden mit technischen Fähigkeiten sehr bekannt und wird folglich hierin wiedereinmal nicht detailliert erörtert werden. Es reicht wohl zu sagen, dass der flexible Routingknoten der vorliegenden Erfindung zum Erkennen bestimmter SSN-Werte konfiguriert ist, die die Notwendigkeit für eine bestimmte Art eines G-FLEX^TM-Übersetzungsdienstes anzeigen.
Von einem operativen Standpunkt werden die Signalisierungsnachrichten, welche eine Routingdatenbankverarbeitung erfordern erst durch die ausnahmebezogene G-FLEX^TM-Datenbank bedient. D.h. ein Suchlauf wird in der G-FLEX^TM-Datenbank basierend auf entweder der IMSI- oder MSISDN-Nummer durchgeführt, welche mit dem eingehenden Signalisierungsnachrichtenpaket assoziiert wird. Falls sich eine IMSIoder MSISDN-Übereinstimmung in der G-FLEX^TM-Datenbank befindet, werden die entsprechenden Routingdaten durch die G-FLEX^TM-Datenbank zurückgesendet und das Signalisierungsnachrichtenpaket entsprechend vor einem weiteren Routing modifiziert. In solch einem Fall wird keine zweite Suche der blockbezogenen GTT-Datenbank erfordert. Falls keine IMSI- oder MSISDN-Übereinstimmung in der G-FLEX^TM-Datenbank lokalisiert wird, wird eine zweite Suche in der bereichsbezogenen GTT-Datenbank durchgeführt.
G-FLEX^TM-Übersetzung
Die 6 und 7 veranschaulichen allgemein die zwei Zugriffsszenarien der Routingdatenbank, welche oben kurz beschrieben wurden. Genauer zeigt 6 den Fall, in welchem der anfängliche G-FLEX^TM-Datenbanksuchlauf eine IMSI- oder MSISDN-Übereinstimmung findet, und daher wird keine zweite GTT-Dantenbanksuche erfordert. Um diesen Fall zu veranschaulichen, wird der Weg einer üblicherweise HLR abhängigen SS7-Signalisierungsnachricht von der GMSC 348 durch den flexiblen Routingknoten 302 und letztlich zum Ziel-HLR C 356 verfolgt, wobei der Weg durch eine gestrichelte Linie in 6 gezeigt wird. Zur Veranschaulichung wurde jeder dieser Netzwerkknoten einer SS7-Netzadresse oder einem Punktcode (PC) zugeordnet. In sowohl 6 als auch 7 wird der GMSC-Knoten 348 durch den PC 1-0-0 identifiziert, der flexible Routingknoten 302 durch PC 2-0-0 identifiziert, während die drei HLR-Knoten 352, 354 und 356 durch die PCs 3-0-1, 3-0-2 bzw. 3-0-3 identifiziert werden.
Beginnend beim GMSC-Knoten 348 wird eine Signalisierungsnachricht formuliert und über die SS7-Kommunikationsverbindung 320 zum flexiblen Routingknoten 302 übertragen. Der relevante Dateninhalt dieser Ursprungssignalisierungsnachricht wird in 10a gezeigt. An sich wird aus der in 10a dargestellten Tabelle hervorgehen, dass die OPC der ursprünglichen Nachricht gleich 1-0-0, dem PC des GMSC-Knotens 348 ist. Der DPC der Nachricht ist 2-0-0, der PC des flexiblen Routingknotens 302. Die Signalisierungsnachricht wird innerhalb des flexiblen Routingknotens 302 durch das LIM 308 empfangen. Die Verarbeitung der SS7-MTP-Protokollschicht 1 und 2 wird beim Eingehen des Signalisierungsnachrichtenpakets durch das Verfahren 310 der MTP-Protokollschicht 1 und 2 durchgeführt. Wenn die Verarbeitung der MTP-Protokollschicht 1 und 2 vollständig ist, wird das Signalisierungsnachrichtenpaket vorübergehend in der Ein-/Ausgabe-Warteschlange 312 gepuffert, bevor sie den Datenstapel zum HMDC-Verfahren 314 der MTP-Protokollschicht 3 hinaufgereicht wird. Das HMDC-Verfahren 314 prüft das Signalisierungsnachrichtenpaket und bestimmt, ob das Paket eine weitere Verarbeitung am flexiblen Routingknoten 302 erfordert. In dem in 6 gezeigten Beispiel, wird vorausgesetzt, dass das HMDC-Verfahren 314 bestimmt, dass eine weitere Verarbeitung des Signalisierungsnachrichtenpakets erfordert wird, und das Paket wird anschließend zum HMDT-Verfahren 316 weitergegeben. Das HDMT-Verfahren 316 prüft das Paket und bestimmt basierend auf der erforderten Art der weiteren Verarbeitung, welches verteilte Verarbeitungsmodul, welches am IMT-Bus 304 angeschlossen ist, als nächstes das Paket empfangen soll. In diesem Fall bestimmt das HMDT-Verfahren 316, dass die Signalisierungsnachricht zum GDM-Modul 322 zum G-FLEX^TM-Übersetzungsdienst weitergeleitet werden soll. Das Signalisierungsnachrichtenpaket wird dann auf dem Hochgeschwindigkeits-IMT-Bus 304 platziert und zum GDM 322 gesendet. Ein detaillierter Ablaufplan der Verfahrensschritte in Bezug auf den GDM/SCCP wird in 11 dargestellt und kann in Verbindung mit dem schematischen Diagramm, welches in 6 gezeigt wird, verwendet werden, um die Methodologie des Suchlaufs der G-FLEX^TM- und GTT-Datenbank besser zu verstehen. Zudem liefert 10a eine Zusammenfassung der Inhalte des Signalisierungsnachrichtenpakets vor und nach der G-FLEX^TM-Übersetzung.
In Bezug auf 11 kommt die Signalisierungsnachricht im Schritt ST1 an der GDM-Karte 322 an und das SCCP-Verfahren 326 empfängt das Paket. Innerhalb des SCCP-Verfahrens 326 wird das Nachrichtenpaket zum Verfahren 328 der SCCP-Steuerung weitergeleitet. In den Schritten ST2 bzw. ST3 decodiert und prüft das SCRC-Verfahren 328 die Informationen des Paketinhalts, welche innerhalb des Anfangsblocks der Signalisierungsnachricht enthalten sind, um zu erstellen, welche Übersetzungsdienstart erfordert wird. Genauer werden die innerhalb des Signalisierungsnachrichtenpakets enthaltenen RI-, GTI-, TT-, NP- und NAI-Parameter analysiert, um zu bestimmen, ob ein G-FLEX^TM- oder GTT-Übersetzungsdienst erfordert wird. Wie in den Schritten ST4 und ST5 gezeigt, wird die Nachricht, wenn bestimmt wird, dass ein GTT-Übersetzungsdienst erfordert wird, direkt zum Verfahren 332 der GTT-Datenbank weitergeleitet. In dem in der 6 dargestellten Szenario werden jedoch ein RI-Wert von „RT-ON-GT", ein GTI-Wert von 4, ein Wert der Übersetzungsart (TT) von 0, ein Wert des „nationalen" NAI und ein Wert des NP „E.164" kollektiv interpretiert die Notwendigkeit für eine G-FLEX^TM-Übersetzung anzuzeigen. Der Inhalt der Signalisierungsnachricht wird dann weiter analysiert, um die bestimmte Art des erforderten G-FLEX^TM-Übersetzungsdienstes zu bestimmen, wie durch den Schritt ST6 gezeigt wird. Genauer wird das SSN-Parameter der CdPA geprüft und der Wert von 6 interpretiert, die Notwendigkeit für eine Übersetzung der G-FLEX^TM-HLR-Art anzuzeigen. In diesem bestimmten Beispiel wird das Paket, wenn die Entitätsart des Zielknotens bestimmt wird, alles andere als ein HLR zu sein (d.h. SSN nicht gleich 6 ist), zum Verfahren 332 der GTT-Datenbank weitergeleitet, wie in den Schritten ST7 bzw. ST5 gezeigt. Im Schritt ST8 wird die Mobilfunk-Identifikationsnummer (MIN), welche innerhalb des Pakets codiert ist, anschließend nach Bedarf geprüft und aufbereitet. Die MIN wird innerhalb des CdPA-Feldes in einer Struktur gespeichert, auf welche häufig als das Teilfeld der Ziffern des Global Title (GTD) Bezug genommen wird. In diesem Beispiel weist die MIN oder GTD einen Wert von 9193803833 auf, wie in 10a gezeigt, und es wird zudem vorausgesetzt, das keine Aufbereitung dieser Nummer erfordert wird.
In Bezug auf die oben erwähnte Nummeraufbereitung kann solch eine Verarbeitung jedoch erforderlich sein, um zu gewährleisten, dass die IMSI oder MSISDN mit dem Format der Schlüsselfelddaten kompatibel sind, welche in der G-FLEX^TM-Datenbank und der GTT-Datenbank 330 bzw. 332 gespeichert sind. Die Operationen der Nummeraufbereitung können das Voranstellen zusätzlicher Ziffern an eine Mobilfunk-Identifikationsnummer beinhalten, welche innerhalb eines Signalisierungsnachrichtenpakets enthalten ist, um die Nummer zu zwingen einem internationalen Format zu entsprechen. Die Umwandlung einer Mobilfunk-Identifikationsnummer von einer Nummerierungsnorm zu einer anderen kann auch durchgeführt werden. Beispielsweise kann die mit einem eingehenden Signalisierungsnachrichtenpaket assoziierte Mobilfunk-Identifikationsnummer von einem Format einer ersten Industrienorm, welche als E.214 bekannt ist, in ein Format einer zweiten Industrienorm, welche als E.212 bekannt ist, vor den Datenbanksuchlaufoperationen umgewandelt werden. Es sollte wieder einmal klar sein, dass solche Mobilfunk-Identifikationsnummeraufbereitungsdienste nur in dem Fall notwendig sind, dass das Format der Mobilfunk-Identifikationsnummer der eingehenden Nachricht nicht mit dem Format der entsprechenden Schlüsselfelddaten in der G-FLEX^TM-Datenbank und der GTT-Datenbank übereinstimmt.
Im Schritt ST9 wird die G-FLEX^TM-Datenbank 330 unter Verwendung der angemessenen Mobilfunk-Identifikationsnummer (IMSI oder MSISDN) als zumindest ein Abschnitt des Kennbegriffs durchsucht. Wenn keine Übereinstimmung in der G-FLEX^TM-Datenbank 330 gefunden wird, wird das Paket zur Verarbeitung zur GTT-Datenbank 332 weitergegeben, wie in den Schritten ST10 bzw. ST11 gezeigt. In dem in der 6 gezeigten Beispiel wird eine Übereinstimmung in der G-FLEX^TM-Datenbank 330 gefunden, wie durch die Tatsache gezeigt, dass es eine Dateneingabe in der G-FLEX^TM-Datenbank 330 gibt ( 9a), welche dem SSN-Wert der Nachricht der CdPA von 9193803833 entspricht. Die durch das Verfahren der G-FLEX^TM-Datenbank 330 zurückgesendeten Routingdaten, ein Punktcodewert von 3-0-3 und eine Subsystemnummer von 6, werden anschließend innerhalb des Signalisierungsnachrichtenpakets codiert, wie durch den Schritt ST12 gezeigt. Es wird klar sein, dass die Routinginformationen, PC:3-0-3 SSN:6, welche durch die G-FLEX^TM-Datenbank zurückgesendet wurden, effektive die Netzadresse des HLR C 356 bilden. Es sollte auch klar sein, dass das Feld des Routingindikators (RI) der übersetzten Signalisierungsnachricht vom ursprünglichen Wert „Route-On-GT" zu einem neuen Wert von „Route-On-SSN" modifiziert wurde, welcher anzeigt, dass keine weiteren Routingadressenübersetzungen erfordert werden, um die Netzadresse des Ziel-HLR-Knotens zu identifizieren. Wieder einmal ist das Parameter des Routingindikators jemandem mit technischen Fähigkeiten im Gebiet der SS7-Telekommunikation sehr bekannt und folglich wird hierin keine detaillierte Erörterung dieses Parameters und der Routingfunktionalität desselben geboten. Es wird jedoch klar sein, dass dieses Parameter verwendet wird, um allgemein anzuzeigen, ob ein Signalisierungsnachrichtenpaket eine Verarbeitung der SCCP-Art erfordert. Es sollte in 9a angemerkt werden, dass zwei der gespeicherten Datenfelder in diesem Fall nicht verwendet werden. Ein Feld der Entitätsadresse wird verwendet, um ein verfälschtes Signal zu speichern, üblicherweise eine formatierte MSISDN- oder IMSI-Nummer, welche für einen bestimmten HLR-Knoten repräsentativ ist. Ein Feld zum Auswechseln der Ziffern des Global Title der angerufenen Partei (RCGT) beinhaltet einen Merker, welcher anzeigt, ob der Wert im CdPA:GTD-Feld der Signalisierungsnachricht geändert werden sollte, um die Entitätsadresse des Ziel-HLR-Knotens widerzuspiegeln. In diesem Fall wird klar sein, dass der RCGT-Merker auf einen Wert von „NO" eingestellt wird, welcher anzeigt, dass das CdPA:GTD-Feld der Signalisierungsnachricht nicht geändert werden muss, um die Entitätsadresse des HLR C wiederzuspiegeln. Dies ist üblicherweise der Fall, wenn der Punktcode und die Subsysteminformation, welche der Netzadresse eines Soll-HLR-Knotens entsprechen, bereits durch den flexiblen Routingknoten bekannt sind. Wenn der flexible Routingknoten nicht mit zumindest dem Punktcode versorgt wurde, welcher dem Ziel-HLR-Knoten entspricht, wird eine Substitution der Entitätsadresse eingesetzt, um anschließende Routingsadressenübersetzungen durch einen externen Routingknoten zu ermöglichen. Ein Beispiel eines solchen Szenarios ist unten geliefert.
Nun zur 6 zurückkehrend wird klar sein, dass nach dem erfolgreichen G-FLEX^TM-Datenbank-Suchlauf, der oben detailliert beschrieben wurde, das modifizierte Signalisierungsnachrichtenpaket als nächstes zum HMRT-Verfahren 334 weitergegeben wird. Wieder einmal bestimmt das HMRT-Verfahren 334 zu welcher LIM- oder DCM-Karte das Paket zur anschließenden Übertragung zum Zielknoten der Nachricht geleitet werden soll. In diesem Fall bestimmt das HMRT-Verfahren 334, dass die den flexiblen Routingknoten 302 und den Zielknoten der modifizierten Nachricht verbindende Verbindung sich auf dem DCM 336 befindet. Folglich wird das modifizierte Signalisierungsnachrichtenpaket intern über den IMT-Bus 304 zum DCM 336 geleitet, wo es durch das HMCG-Verfahren 340 empfangen wird. Das HMCG-Verfahren 340 gibt das modifizierte Nachrichtenpaket in die Ein-/Ausgabe-Warteschlange 341 weiter, während es diese Verteilung des abgehenden Paktes zum Verbindungsverkehrsstau bestätigt. Schließlich wird das modifizierte Nachrichtenpaket von der Ein-/Ausgabe-Warteschlange 341 und weiter zum IP-Verfahren 342 gegeben, wo das SS7-Pakte innerhalb eines IP-Routingumschlags gekapselt wird. Das in das IP gekapselte SS7-Paket wird dann in das assoziierte IP-Netz 350 über die IP-Signalisierungsverbindung 344 übertragen. In diesem Beispiel wird das in das IP gekapselte SS7-Paket adressiert und folglich durch das IP-Netz 350 zum endgültigen Ziel, HLR C 356, geroutet. Die OPC des Pakets wird in die OPC des flexiblen Routingknotens 302 geändert.
Standard-GTT-Übersetzung
Nun in Bezug auf 7 veranschaulicht das Beispielszenario des Nachrichtenflusses, welches in diesem Diagramm dargestellt wird, den Fall, in welchem ein anfänglicher Suchlauf der G-FLEX^TM-Datenbank versagt eine IMSI- oder MSISDN-Übereinstimmung zu finden und daher eine zweite oder Standard-DTT-Datenbanksuche erfordert wird. Der Weg der üblicherweise HLR-abhängigen SS7-Signalisierungsnachricht wird von der GMSC 348 durch den flexiblen Routingknoten 302 und schließlich zum Ziel-HLR B 354 verfolgt. Wieder einmal wird der Weg der Signalisierungsnachricht durch eine gestrichelte Linie gezeigt. Beginnend beim GMSC-Knoten 348 wird eine Signalisierungsnachricht formuliert und über die SS7-Kommunikationsverbindung 320 zum flexiblen Routingknoten 302 übertragen. Der relevante Dateninhalt dieser Ursprungssignalisierungsnachricht wird in 10b gezeigt. An sich wird aus der in 10b dargestellten Tabelle hervorgehen, dass die OPC der ursprünglichen Nachricht gleich 1-0-0 ist, dem PC des GMSC-Knotens 348. Der DPC der Nachricht ist 2-0-0, der PC des flexiblen Routingknotens 302.
Da die Verarbeitung des eingehenden Signalisierungsnachrichtenpakets auf dem LIM 308 in diesem Szenario der gleicht, welche für das in 6 veranschaulichte Szenario beschrieben und oben beschrieben wurde, wird eine detaillierte Erörterung der LIM-Verarbeitung nicht wiederholt werden. Stattdessen wird klar sein, dass die eingehende Signalisierungsnachricht innerhalb des flexiblen Routingknotens 302 durch das LIM 308 empfangen wird und das Nachrichtenpaket anschließend geprüft und über den IMT-Bus 304 zur GDM-Karte 322 zur weiteren Verarbeitung geroutet wird.
Der detaillierte Ablaufplan der in der 11 dargestellten Verarbeitungsschritte in Bezug auf den GDM/SCCP kann in Verbindung mit dem in 7 gezeigten schematischen Diagramm verwendet werden, um die Methodologie des Suchlaufs der G-FLEX^TM- und GTT-Datenbank besser zu verstehen. Zudem liefert l0b eine Zusammenfassung der Inhalte des Signalisierungsnachrichtenpakets vor und nach der G-FLEX^TM-Übersetzung. In Bezug auf 11 kommt die Signalisierungsnachricht im Schritt ST1 bei der GDM-Karte 322 an und das SCCP-Verfahren 326 empfängt das Paket. Innerhalb des SCCP-Verfahrens 326 wird das Nachrichtenpaket zum SCRC-Steuerungsverfahren 328 weitergegeben. In den Schritten ST2 bzw. ST3 decodiert und prüft das SCRC-Verfahren 328 die Informationen des Paketinhalts, welche innerhalb des Anfangsblocks der Signalisierungsnachricht enthalten sind, um zu ermitteln, welche Art von Übersetzungsdienst erfordert wird. Genauer werden die RI-, GTI-, TT-, NP- und NAI-Parameter, welche innerhalb des Signalisierungsnachrichtenpakets enthalten sind, analysiert, um zu bestimmen, ob ein G-FLEX^TM- oder ein GTT-Übersetzungsdienst erfordert wird. Wieder einmal werden, wie im vorangehenden Beispiel ein RI-Wert von „RT-ON-GT", ein GTI-Wert von 4, ein TT-Wert von 0, ein Wert des „nationalen" NAI und ein Wert des NP „E.164" kollektiv interpretiert die Notwendigkeit für eine G-FLEX^TM-Übersetzung anzuzeigen. Der Inhalt der Signalisierungsnachricht wird dann weiter analysiert, um die bestimmte Art des erforderten G-FLEX^TM-Übersetzungsdienstes zu bestimmen, wie durch den Schritt ST6 gezeigt wird. Genauer wird das SSN-Parameter der CdPA geprüft und der Wert von 6 interpretiert die Notwendigkeit für eine Übersetzung der G-FLEX^TM-HLR-Art anzuzeigen. Im Schritt ST8 wird die innerhalb des Pakets codierte Mobilfunk-Identifikationsnummer (MIN) anschließend nach Bedarf geprüft und aufbereitet. In diesem Beispiel weist die MIN oder GTD einen Wert von 7707883438 auf, wie in l0b gezeigt, und es wird weiter vorausgesetzt, dass keine Aufbereitung dieser Nummer erfordert wird.
Im Schritt ST9 wird die G-FLEX^TM-Datenbank 330 unter Verwendung der angemessenen Mobilfunk-Identifikationsnummer (IMSI oder MSISDN) als zumindest ein Abschnitt des Kennbegriffs durchsucht. In diesem Fall wird keine Übereinstimmung in der G-FLEX^TM-Datenbank 330 gefunden und das Paket wird zur weiteren Verarbeitung zur GTT-Datenbank 332 weitergeleitet, wie im Schritt ST10 gezeigt. Es wird klar sein, dass diese GTT-Standardverarbeitung durch die Tatsache gezeigt wird, dass es keine Dateneingabe in der G-FLEX^TM-Datenbank 330 gibt (9a), welche dem SSN-Wert der Nachricht der CdPA von 7707883438 entspricht. Folglich wird im Schritt ST10 die GTT-Datenbank 332 unter Verwendung der Mobilfunk-Identifikationsnummer 7707883438 als zumindest ein Abschnitt des Kennbegriffs durchsucht. Wie in 9b gezeigt, ist ein MIN-Bereich in der GTT-Datenbank 332 definiert, welcher die gesuchte MIN, 7707883438, begrenzt. Die durch das Verfahren 332 der GTT-Datenbank zurückgesendeten Routingdaten, ein Punktcodewert von 3-0-2 und eine Subsystemnummer von 6 werden anschließend innerhalb des Signalisierungsnachrichtenpakets codiert, wie durch den Schritt ST12 gezeigt. Es wird klar sein, dass die durch die GTT-Datenbank 332 zurückgesendeten Routinginformationen, PC:3-0-2 SSN:6, effektiv die Netzadresse des HLR B 354 bilden. Es sollte auch klar sein, das das Feld des Routingindikators (RI) der übersetzten Signalisierungsnachricht vom ursprünglichen Wert „Route-On-GT" zu einem neuen Wert von „Route-On-SSN" modifiziert wurde.
Zur 7 zurückkehrend wird klar sein, dass nach der fehlgeschlagenen G-FLEX^TM- und erfolgreichen GTT-Datenbanksuchlaufsequenz, wie oben detailliert beschrieben wurde, das modifizierte Signalisierungsnachrichtenpaket als nächstes zum HMRT-Verfahren 334 weitergegeben wird. Wieder einmal bestimmt das HMRT-Verfahren 334 zu welcher LIM- oder DCM-Karte das Paket zur anschließenden Übertragung zum Zielknoten der Nachricht geroutet werden soll. In diesem Fall bestimmt das HMRT-Verfahren 334, dass sich die den flexiblen Routingknoten 302 und den Zielknoten der modifizierten Nachricht verbindende Verbindung auf dem DCM 336 befindet. Folglich wird das modifizierte Signalisierungsnachrichtenpaket intern über den IMT-Bus 304 zum DCM 336 geroutet, wo es durch das HMCG-Verfahren 340 empfangen wird. Das HMCG-Verfahren 340 gibt das modifizierte Nachrichtenpaket in die Ein-/Ausgabe-Warteschlange 341 weiter, während es diesen Beitrag des abgehenden Pakets zum Verbindungsverkehrsstau bestätigt. Schließlich wird das modifizierte Nachrichtenpaket von der Ein-/Ausgabe-Warteschlange 341 und weiter zum IP-Verfahren 342 weitergegeben, wo das SS7-Paket innerhalb eines IP-Routingumschlags gekapselt wird. Die Ziel-IP-Adresse im Routingumschlag kann durch einen Datenbanksuchlauf im DCM für die IP-Adresse bestimmt werden, welche dem Punktcode 3-0-2 entspricht. Das im IP gekapselte SS7-Paket wird dann über die IP-Signalisierungsverbindung 344 in das assoziierten IP-Netz 350 übertragen. In diesem Beispiel ist das im IP gekapselte SS7-Paket adressiert und wird folglich durch das IP-Netz 350 zum endgültigen Ziel, HLR B 354, geroutet.
Wie oben erwähnt wurde, kann das in 7 veranschaulichte IP-Netz 350 durch ein SS7-Netz ersetzt werden, ohne vom Bereich der Erfindung abzuweichen. In solch einem Szenario kann das DCM 336 durch ein zweites LIM zum Routen abgehender SS7-Nachrichten über ein SS7-Netz verwendet werden. In einem Verfahren zum Routen einer Signalisierungsnachricht nach solch einer Ausführungsform sind die Schritte zum Routen der Signalisierungsnachricht die gleichen wie jene, welche oben vor der Verteilung der Nachricht zum DCM 336 beschrieben wurden, wie oben beschrieben wurde. Wenn das DCM 336 jedoch eher durch ein LIM ersetzt wird, als die Signalisierungsnachricht in einem IP-Paket zu kapseln, wird die Signalisierungsnachricht einfach gemäß dem Zielpunktcode der Nachricht zum HLR B 354 geroutet. Die abgehende Signalisierungsnachricht weist eine OPC, welche gleich dem Punktcode des flexiblen Routingknotens 302 ist, und einen DPC auf, welcher gleich dem Punktcode des HLR B 354 ist. Da die OPC der Signalisierungsnachricht eher in den Punktcode des flexiblen Routingknotens 302 geändert wird, als die des GMSC 348, wird die Einhaltung der SS7-Netzzuverlässigkeitsverfahren beibehalten.
Zwischenübersetzung
Ein in 8 dargestelltes Beispiel soll eine alternative Netzwerkausführung veranschaulichen, in welcher es für einen flexiblen Routingknoten der vorliegenden Erfindung möglich ist eine Zwischenroutingübersetzung zu liefern. In dieser Ausführung beinhaltet das Signalisierungsnetz 400 einen flexiblen Routingknoten 402, welcher in Form und Funktion im Wesentlichen dem oben beschriebenen und in den 6 und 7 allgemein veranschaulichten flexiblen Routingknoten 302 gleicht. Der flexible Routingknoten 402 ist über mindestens einen Zwischen-STP 404 an die GMSC 348 und die drei HLR-Knoten 352, 354 und 356 gekoppelt. Die Kommunikationsverbindung 406 zwischen dem flexiblen Routingknoten 402 und STP 404 ist eine SS7-Verbindung, obwohl andere Kommunikationsprotokolle, wie z.B. IP, auch eingesetzt werden könnten.
In diesem Szenario wird der Weg einer üblicherweise HLRabhängigen SS7-Signalisierungsnachricht von der GMSC 348 durch den flexiblen Routingknoten 402 und schließlich zum Zielknoten, HLR A 352, verfolgt. Wieder einmal wird der Signalisierungsnachrichtenweg durch eine gestrichelte Linie gezeigt. Der relevante Dateninhalt dieser Signalisierungsnachricht wird, wie er erst empfangen und dann durch den flexiblen Routingknoten 402 übersetzt wird, in l0c gezeigt. Beginnend am GMSC-Knoten 348 wird eine Signalisierungsnachricht mit einem CdPA:GTD-Wert von 2125662322 formuliert und zum Zwischen-STR 404 übertragen. Der STP 404 empfängt und routet die Signalisierungsnachricht über die Kommunikationsverbindung 406 weiter zum flexiblen Routingknoten 402. Obwohl nicht in 10c gezeigt, aber es wird klar sein, dass die OPC der ursprünglichen Nachricht gleich 1-0-0, dem PC des GMSC-Knotens 348 ist, während die DPC der ursprünglichen Nachricht 4-0-0, der PC des STP 404 ist. Im Verfahren des Routens des Nachrichtenpakets modifiziert der STP 404 die OPC in 4-0-0 und die DPC in 2-0-0. Die Nachricht wird dann durch den STP 404 zum flexiblen Routingknoten 402 übertragen, welcher dem Punktcode 2-0-0 zugeordnet ist. Wenn die Signalisierungsnachricht einmal durch den flexiblen Routingknoten 402 empfangen wird, ist die Verarbeitung der Nachricht im Wesentlichen die gleiche, wie die, welche für die vorangehenden Beispiele beschrieben wurde.
Der einzige wesentliche Unterschied in diesem Fall ist, dass die durch den Suchlauf der G-FLEX^TM-Datenbank zurückgesendeten Daten nicht der Punktcode und die SSN des Soll-HLR A-Knotens 352, sondern stattdessen die Entitätsadresse ist, welche mit dem HLR A 352 und dem Punktcode des STP 404 assoziiert wird. Genauer wird der Wert zum Auswechseln der Ziffern des Global Title(RCGT) von „JA" durch die G-FLEX^TM-Datenbank zusammen mit einem Wert der HLR A-Entitätsadresse von 1013211234 zurückgesendet, wie in 9a gezeigt wird. Folglich wird der ursprüngliche Wert des CdPA:GTD-Felds der Signalisierungsnachricht, 2125662322, durch den Wert der HLR A-Entitätsadresse von 1013211234 ersetzt.
Ein zweiter Hauptunterschied von den vorangehenden Szenarien ist, dass der CdPA-Routingindikator der übersetzten Nachricht auf „RT-ON-GT" anstelle von „RT-ON-SSN" eingestellt wird und dadurch anzeigt, dass mindestens eine weitere Routingadressenübersetzung erfordert wird, um die Ist-Netzadresse des Ziel-HLR-Knotens zu bestimmen.
Jemanden mit technischen Fähigkeiten auf dem Gebiet der SS7-Routingsysteme wird klar sein, dass solch eine Übersetzung in Form und Funktion einer Zwischenübersetzung des Global Title sehr ähnlich ist. An sich wird impliziert, dass die innerhalb des flexiblen Routingknotens 402 enthaltenen G-FLEX^TM- und GTT-Datenbanken nicht die Informationen aufweisen, welche zum Identifizieren der Ist-Netzadresse des Soll-Zielknotens notwendig sind. Die G-FLEX^TM-Datenbank ist jedoch mit Informationen bestückt, welche den nächsten Routingknoten des Netzes betreffen, welcher die Ist-Netzadresse des Soll-Zielknotens aufweisen kann. Wie in den 8, 9a und l0c gezeigt, zeigt das Ergebnis des Suchlaufs der G-FLEX^TM-Datenbank an, dass das Signalisierungsnachrichtenpaket als nächstes zum STP 404 am PC: 4-0-0 geroutet werden sollte. Zudem wird der Routingindikator der übersetzten Nachricht auf einen Wert von „RT-ON-GT" eingestellt, welcher anzeigt, dass eine endgültige Routingübersetzung noch erfordert wird, bevor das Nachrichtenpaket sein Soll-Ziel erreichen kann. In diesem Beispiel wird vorausgesetzt, dass der STP 404 konfiguriert ist eine endgültige GTT am Nachrichtenpaket unter Verwendung der Entitätsadresse des HLR A erfolgreich durchzuführen, welche im CdPA:GTD-Feld der Signalisierungsnachricht gespeichert wurde. Nach dieser endgültigen GTT-Übersetzung am STP 404 wird der DCP des Nachrichtenpakets in 3-0-1:6 geändert und die Nachricht anschließend zum Netzelement übertragen, welches diesem PC und der SSN, d.h. dem HLR A 352 entspricht. Die OPC der Nachricht wird in 4-0-0 geändert, d.h. die OPC des STP 404.
Wie zuvor erwähnt wurde, ist ein bedeutender Unterschied, dass der flexible Routingknoten der vorliegenden Erfindung Lösungen über dem Stand der Technik aufweist, welche die Weise einschließen, in welcher das OPC-Feld des SS7-MTP-Routingetiketts während dem G-FLEX^TM- oder GTT-Übersetzungsverfahren geändert wird. Genauer wird als Teil der G-FLEX^TM- und GTT-Verarbeitung die OPC der übersetzten Signalisierungsnachricht modifiziert, um den Punktcode des flexiblen Routingknotens widerzuspiegeln. Dieser Unterschied ist dadurch wichtig, dass er der SS7-Protokollschicht 3 der Industrienorm und den oben erwähnten Netzverwaltungsprotokollen ermöglicht gemäß den anerkannten SS7-Telekommunikationsnormen zu operieren, welche durch ANSI, ITU und Telcordia und andere definiert wurden.
Es wird klar sein, dass verschiedene Details der Erfindung geändert werden können, ohne vom Bereich der Erfindung abzuweichen. Zudem dient die vorangehende Beschreibung nur zur Veranschaulichung und nicht zur Beschränkung, wobei die Erfindung durch die Ansprüche definiert ist.

Claims

Routingelement (302) zum Routen einer Signalisierungsnachricht durch ein Kommunikationsnetzwerk, welches eine Mobilfunk-Vermittlungsstelle enthält, die zum Routen von Signalisierungsnachrichten basierend auf Bereichen von Mobilfunk-Identifikationsnummern und einer Vielzahl von HLR-Registern (352, 354, 356), die Subskriptionsdaten für individuelle Teilnehmern speichern, geeignet ist, wobei das Routingelement (302) aufweist: (a) ein Kommunikationsmodul (308), welches innerhalb des Routingelementes (302) zum Empfangen einer Signalisierungsnachricht von der Mobilfunk-Vermittlungsstelle (348) angeordnet ist; (b) eine bereichsbezogene Datenbank (332), welche Einträge zum Routen der Signalisierungsnachrichten zu den HLR-Registern (352, 354, 356) enthält, wobei die Einträge durch Bereiche oder Blöcke der Mobilfunk-Identifikationsnummern indiziert sind; (c) eine ausnahmebezogene Datenbank (330), welche innerhalb des Routingelementes (302) angeordnet ist und Einträge zum Routen der Signalisierungsnachrichten zu den HLR-Registern (352, 354, 356) enthält, wobei die Einträge durch individuelle Mobilfunk-Identifikationsnummern indiziert sind; und (d) eine Datenbank-Subsystem-Steuereinrichtung (328), welche innerhalb des Routingelementes (302) zum Zugreifen auf wenigstens eine der bereichsbezogenen und ausnahmebezogenen Datenbanken (332 und 330) angeordnet ist, um Routinginformationen zum Routen der Signalisierungsnachricht zu einem der HLR-Register (352, 354, 356) zu extrahieren, und dadurch gekennzeichnet ist, dass: (i) die Datenbank-Subsystem-Steuereinrichtung (328) dazu geeignet ist, um anfangs die Signalisierungsnachricht zu der ausnahmebezogenen Datenbank (330) zu leiten und ein Nachschlagen in der ausnahmebezogenen Datenbank (330) basierend auf einer Mobilfunk-Identifikationsnummer in der Signalisierungsnachricht durchzuführen, um die Routinginformation zu lokalisieren; (ii) die Datenbank-Subsystem-Steuereinrichtung (328) dazu geeignet ist, die Signalisierungsnachricht zu der bereichsbezogenen Datenbank (332) als Antwort auf ein Fehlschlagen des Lokalisierens der Routinginformation in der ausnahmebezogenen Datenbank (330) zu leiten; und (iii) die Datenbank-Subsystem-Steuereinrichtung (328) dazu geeignet ist, die Routinginformation, welche von der bereichsbezogenen oder ausnahmebezogenen Datenbank (332 oder 333) zurückgekommen ist, in die Signalisierungsnachricht einzubauen.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass das Kommunikationsmodul (308) ein Signalisierungssystem-7(SS7)-Linkschnittstellenmodul (LIM) oder ein IP-Datenkommunikationsmodul (DCM) ist.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die Einträge in die ausnahmebezogene Datenbank (330) durch Mobilfunk-Identifikationsnummern indiziert werden, die Ausnahmen zu den Bereichen der Mobilfunk-Identifikationsnummern sind.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass jeder Eintrag in der ausnahmebezogenen Datenbank (330) einen SS7-Punktcode oder eine IP-Adresse enthält.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass jeder Eintrag in der ausnahmebezogenen Datenbank eine Entitätsadresse enthält.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass jeder Eintrag in der bereichsbezogenen Datenbank eine Entitätsadresse enthält.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass jeder Eintrag in der bereichsbezogenen Datenbank einen SS7-Punktcode oder eine IP-Adresse enthält.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die Datenbank-Subsystem-Steuereinrichtung (328) dazu geeignet ist, Nummernaufbereitungsoperationen auf den Inhalten der Signalisierungsnachricht vor dem Zugreifen auf die bereichsbezogene oder ausnahmebezogene Datenbank (332 oder 330) durchzuführen.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die Datenbank-Subsystem-Steuereinrichtung (328) dazu geeignet ist, einen Entitätstyp für ein Ziel der Signalisierungsnachricht vor dem Zugreifen auf die bereichsbezogene oder ausnahmebezogene Datenbank (332 oder 330) zu bestimmen.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die Signalisierungsnachricht eine SS7-Signalisierungsnachricht aufweist.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die Signalisierungsnachricht eine Interim-Standard-41(IS41)-Protokollnachricht oder eine GSM-MAP-Nachricht enthält.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass das Kommunikationsnetzwerk ein Signalisierungssystem-7(SS7)-Netzwerk, ein IP-Netzwerk oder ein ATM-Netzwerk aufweist.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die aus der Signalisierungsnachricht extrahierte Identifikationsnummer eine Mobilfunk-Identifikationsnummer ist.
Routingelement (302) nach Anspruch 13, dadurch gekennzeichnet, dass die aus der Signalisierungsnachricht extrahierte Mobilfunk-Identifikationsnummer eine internationale Mobilfunk-Teilnehmer-Identitätsnummer (IMSI), eine Mobilfunkstations-Dienstintegrierende-Digitale-Netzwerk-Nummer (MSISDN), eine Mobilfunk-Globaler-Titel-Nummer, eine ANSI-41-Mobilfunk-Identifikationsnummer oder eine ANSI-41-Mobilfunkverzeichnisnummer ist.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die in der Signalisierungsnachricht eingebaute Routinginformation einen Punktcode (PC) oder eine IP-Adresse enthält.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass die in der Signalisierungsnachricht eingebaute Routinginformation zumindest eine Entitätsadresse, einen Routingindikator oder eine Subsystem-Nummer (SSN) enthält.
Routingelement (302) nach Anspruch 1, dadurch gekennzeichnet, dass zumindest eine der Mobilfunk-Identifikationsnummern, durch welche die Einträge in der ausnahmebezogenen Datenbank indiziert sind, außerhalb der Blocks oder der Bereiche der Mobilfunk-Identifikationsnummern liegt, durch welche die Einträge in der ausnahmebezogenen Datenbank indiziert sind.
Verfahren zum Routen einer Signalisierungsnachricht in einem Mobilfunk-Kommunikationsnetzwerk, welches eine Mobilfunk-Vermittlungsstelle (348) mit bereichsbezogenen HLR-Routing-Ressourcen und eine Vielzahl von HLR-Registern (352, 354, 356), die eine Subskriptionsinformation für Mobilfunk-Teilnehmer speichern, aufweist, wobei das Verfahren durch folgende Verfahrensschritte gekennzeichnet ist: (a) Empfangen einer Signalisierungsnachricht von der Mobilfunk-Vermittlungsstelle (348); (b) Durchführen einer Anfangssuche einer ausnahmebezogenen Datenbank (330) anwendend eine Identifikationsnummer, welche innerhalb der Signalisierungsnachricht enthalten ist, wobei die ausnahmebezogene Datenbank (330) Einträge enthält, die durch individuelle Mobilfunk-Identifikationsnummern indiziert sind, und eine Routinginformation zum Routen der Signalisierungsnachrichten zu den HLR-Registern (352, 354, 356) speichert; (c) als Antwort auf ein Fehlschlagen des Lokalisierens eines Eintrags entsprechend der Identifikationsnummer in der ausnahmebezogenen Datenbank, Durchführen einer zweiten Suche einer bereichsbezogenen Datenbank (332) anwendend die in der Signalisierungsnachricht enthaltene Identifikationsnummer, wobei die bereichsbezogene Datenbank (332) Einträge enthält, die durch Bereiche der Mobilfunk-Identifikationsnummern indiziert sind und eine Routinginformation für das Routen der Signalisierungsnachrichten zu den HLR-Registern (352, 354, 356) speichert; (d) Modifizieren der Signalisierungsnachricht, um eine Routingadressinformation einzufügen, die von der ausnahmebezogenen oder der bereichsbezogenen Datenbank (332 oder 330) extrahiert ist; und (e) Übertragen der modifizierten Signalisierungsnachricht zu einem der HLR-Register (352, 354, 356).
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die Signalisierungsnachricht eine SS7-Signalisierungsnachricht aufweist.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die Signalisierungsnachricht eine Interim-Standard-41(IS41)-Protokollnachricht oder eine GSM-MAP-Nachricht aufweist.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass das Kommunikationsnetzwerk ein Signalisierungssystem-7(SS7)-Netzwerk, ein IP-Netzwerk oder ein ATM-Netzwerk aufweist.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die aus der Signalisierungsnachricht extrahierte Identifikationsnummer eine Mobilfunk-Identifikationsnummer ist.
Verfahren nach Anspruch 22, dadurch gekennzeichnet, dass die aus der Signalisierungsnachricht extrahierte Mobilfunk-Identifikationsnummer eine internationale Mobilfunk-Teilnehmer-Identitätsnummer (IMSI), eine Mobilfunkstations-Dienstintegrierende- Digitale-Netzwerk-Nummer (MSISDN), eine Mobilfunk-Globaler-Titel-Nummer, eine ANSI-41-Mobilfunk-Identifikationsnummer oder eine ANSI-41-Mobilfunkverzeichnisnummer ist.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die in der Signalisierungsnachricht eingebaute Routinginformation einen Punktcode (PC) oder eine IP-Adresse enthält.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die in der Signalisierungsnachricht eingebaute Routinginformation wenigstens eine Entitätsadresse, einen Routingindikator oder eine Subsystem-Nummer (SSN) enthält.
Verfahren nach Anspruch 18, gekennzeichnet durch ein Bestimmen, ob die empfangenen Signalisierungsnachrichten eine Routing-Adressen-Übersetzung erfordern.
Verfahren nach Anspruch 26, gekennzeichnet durch ein Bestimmen eines Typs einer Routing-Adressen-Übersetzung, die für die Signalisierungsnachrichten erforderlich ist, als Antwort auf das Bestimmen, dass die Signalisierungsnachrichten eine Routing-Adressen-Übersetzung erfordern.
Verfahren nach Anspruch 27, dadurch gekennzeichnet, dass das Bestimmen eines Typs einer Routing-Adressen-Übersetzung ein Bestimmen eines Typs des globalen Systems für ein Mobilfunkkommunikation (GSM) oder ein Amerikanisches-Institut-Für-Nationale-Standards (ANSI)-Netzwerkelement (41), zu welchem die Signalisierungsnachrichten geroutet werden sollen, beinhaltet.
Verfahren nach Anspruch 28, dadurch gekennzeichnet, dass das Bestimmen eines Typs eines GSM- oder ANSI-Netzwerkelementes (41) ein Bestimmen beinhaltet, ob die Signalisierungsnachrichten zu einem HLR-Register (HLR), einem Ausrüstungsidentifikationsregister (EIR), einem Authentifizierungszentrum (AuC) oder zu einem Dienstekontrollpunkt (SCP) zu routen ist.
Verfahren nach Anspruch 26, dadurch gekennzeichnet, dass das Bestimmen, ob die empfangenen Signalisierungsnachrichten eine Routing-Adressen-Übersetzung erfordern, ein Bestimmen der Feldwerte in einem Signalisierungs-Verbindungs-Steuerteil (SCCP), welches Teilnehmeradressenteil (CdPA) der Signalisierungsnachrichten genannt wird, enthält.
Verfahren nach Anspruch 30, dadurch gekennzeichnet, dass das Prüfen der Felder in dem SCCP-CdPA-Teil der Signalisierungsnachrichten ein Prüfen eines Subsystem-Nummernfeldes (SSN), eines Übersetzungstypfeldes (TT), eines Globalen-Titel-Indikator-Feldes (GTI), eines Nummerierungs-Planfeldes (NP) und eines Adressen-Charakter-Indikator-Feldes (NAI) enthält.
Verfahren nach Anspruch 30, dadurch gekennzeichnet, dass das Bestimmen, ob ein Datenpaket eine Routing-Adressen-Übersetzung erfordert, ein Prüfen der Werte in einem Transaktions-Ressourcen-Applikationsteil(TCAP)-Anteil des Datenpakets enthält.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass: (a) das Empfangen einer Signalisierungsnachricht von der Mobilfunk-Vermittlungsstelle (348) ein Empfangen einer Signalisierungsnachricht, die einen Herkunfts-Punktcode (UPC) gleich einem zweiten Punktcode entsprechend der Mobilfunk-Vermittlungsstelle (348), besitzt, an einem Netzwerk-Routing-Knoten (302), der einen ersten Punktcode besitzt, aufweist; und (b) das Übertragen der modifizierten Signalisierungsnachricht zu einem der HLR-Register (352, 354, 356) ein Einfügen des ersten Punktcodes in das OPC-Feld der modifizierten Signalisierungsnachricht aufweist.
Verfahren nach Anspruch 33, dadurch gekennzeichnet, dass das Empfangen einer Signalisierungsnachricht von der Mobilfunk-Vermittlungsstelle (348) ein Empfangen einer Signalisierungs-System-7(SS7)-Signalisierungsnachricht über ein SS7-Netzwerk aufweist.
Verfahren nach Anspruch 33, dadurch gekennzeichnet, dass das Übertragen der modifizierten Signalisierungsnachricht zu einem der HLR-Register (352, 354, 356) ein Übertragen einer Signalisierungssystem-7(SS7)-Signalisierungsnachricht über ein SS7-Netzwerk aufweist.
Verfahren nach Anspruch 33, dadurch gekennzeichnet, dass das Modifizieren der Signalisierungsnachricht, um die Routing-Adressen-Information einzufügen, ein Modifizieren der Signalisierungsnachricht enthält, um einen Ziel-Punktcode(DPC)-Wert entsprechend einem der HLR-Register (352, 354, 356) einzufügen.
Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass wenigstens eine der individuellen Mobilfunk-Identifikationsnummern in der ausnahmebezogenen Datenbank außerhalb des Bereiches der Mobilfunk-Identifikationsnummern der bereichsbezogenen Datenbank ist.