DE60014715T2

DE60014715T2 - Verfahren und systeme zur weglenkung von nachrichten in einem telekommunikationsnetzwerk

Info

Publication number: DE60014715T2
Application number: DE60014715T
Authority: DE
Inventors: Matthew Thomas MCCANN; Gopala Raghavendra RAO; Fulton Robert WEST
Original assignee: Tekelec Inc
Current assignee: Tekelec Global Inc
Priority date: 1999-12-23
Filing date: 2000-12-22
Publication date: 2005-02-17
Anticipated expiration: 2020-12-23
Also published as: EP1285545B1; DE60014715D1; WO2001047297A2; AU2449701A; US20010030957A1; US7035239B2; US6836477B1; WO2001047297A3; EP1285545A2; ATE279079T1

Description

Technischer Bereich
Die vorliegende Erfindung bezieht sich auf das Leitweglenken (Routen) von Signalisierungsnachrichten in einem Kommunikationsnetzwerk, und speziell auf Verfahren und Systeme zum Liefern eines Schaltknotens, welcher eine flexible Nachrichten-Leitweglenkfunktionalität beinhaltet.
Stand der Technik
Innerhalb der weltweiten drahtlosen bzw. Funk-Telekommunikationsindustrie wird der gegenwärtige Trend in der Netzwerktechnologie zwischen den Architekturen aufgeteilt, die auf dem Global System for Mobile Communications (GSM) bzw. Globalsystem für Mobile Kommunikation und auf dem American National Standards Institute (ANSI)-41 bzw. Nationalem Amerikanischen Institut für Standards beruhen. In vielen Gesichtspunkten sind die auf GSM und ANSI-41 basierenden Netzwerke ganz ähnlich, wobei sich die primären Unterschiede zwischen den zwei Technologien einfach auf die Protokolle beziehen, welche benutzt werden, um zwischen den verschiedenen Netzwerkentitäten zu kommunizieren, und den Betriebsfrequenzen der Kommunikationshandgeräte selbst. Bei der Diskussion der vorliegenden Erfindung wird im Interesse der Klarheit diese auf Netzwerkimplementierungen vom GSM-Typ beschränkt. Es sollte jedoch gewürdigt werden, dass die vorliegende Erfindung in ähnlicher Weise in einem ANSI-41-, bei Personenkommunikationsdiensten (PCS)oder ähnlichen Arten von Netzwerken genutzt werden kann.
Eine typische GSM-Netzwerkarchitektur wird in 1 dargestellt. Wie in 1 gezeigt wird, beinhaltet das typische GSM-Netzwerk, im Allgemeinen mit der Ziffer 100 bezeichnet, eine Anzahl von Funktionselementen oder Knoten, welche in ge eigneter Weise miteinander verbunden sind, um so den gewünschten gesamten Netzwerkdienst zu erhalten. Diese Netzwerkknoten beinhalten ein Heimatregister (HLR) 116, ein Besucherregister (VLR) 118, ein Geräte-Identifikationsregister (EIR) 120, ein Berechtigungszentrum (AuC) 122, ein Mobil-Schaltzentrum (MSC) 110, ein Netzübergangsmobil-Schaltzentrum (GMSC) 112, ein Netzanpassungs-Mobil-Schaltzentrum (IWMSC) 132 und ein Kurznachricht-Servicezentrum (SMSC) 130. Kurzum, das HLR 116 ist eine Datenbank, welche benutzt wird, um Teilnehmerinformation für alle Kunden innerhalb des Heimatdienstbereiches des GSM-Service Providers bzw. -Dienstanbieters zu speichern. Funktionell ist das HLR 116 über ein Signalisiernetzwerk mit anderen Dienstbereichen verbunden, so dass eine Teilnehmerinformation effizient zwischen geographisch verschiedenen Netzwerken anteilig genutzt werden kann, eine Charakteristik, welche das nahtlose Inter-Netzwerk-Roaming erleichtert. Ähnlich wie das HLR 116 ist auch das VLR 118 eine Datenbank, welche Teilnehmerinformation beinhaltet. Jedoch wird das VLR 118 speziell zum Speichern von Information benutzt, welche sich auf die Teilnehmer bezieht, welche sich nicht in ihrem Heimatdienstbereich befinden. Speziell ist das VLR 118 der Ort, an dem auf das Roaming bezogene Daten für einen Kunden gespeichert werden, wenn der Kunde sein Handgerät außerhalb seines gekennzeichneten Heimatdienstbereiches aktiviert. Der EIR-Knoten 120 hält Information, welche sich auf die Identifikationsseriennummern aller Kundenbandgeräte bezieht, welche innerhalb des Dienstbereiches aktiviert wurden, während der AuC-Knoten 122 Sicherheits- oder Verschlüsselungsdaten beinhaltet, welche mit jedem Handgerät verbunden sind. Das SMSC 130 dient in erster Linie als ein Speichuer- und Weiterleitmechanismus für Teilnehmer, um Kurznachrichtendienst(SMS)-Nachrichten an andere mobile Teilnehmer oder Rechnersysteme zu senden.
Die oben beschriebenen fünf Netzwerkelemente (HLR, VLR, EIR, AuC, SMSC) können als wesentliche Datenbanken oder Datenbank verarbeitungsknoten gedacht bzw. angesehen werden. Im Gegensatz zu diesen Datenbankknoten werden das MSC 110, GMSC 112 und IWMSC 132 im Allgemeinen als Netzwerkschaltelemente betrachtet. Neben ihren vielen Funktionen sind das SMC 110 und GMSC 112 für das Bestimmen verantwortlich, welche Zellenstelle einen Ruf übernehmen wird. Eine derartige Freihandsteuerung wird durch eine Kommunikationsverbindung zwischen dem MSC 110 und einem damit verbundenen bzw. zugehörigen Basisstationssteuergerät (BSC)/Basisübertragungsstation (BTS)-Paar 124 erleichtert. Das GMSC 112 ist zusätzlich dafür bestimmt, ein Netzübergangs-Interface zum öffentlichen Telefonnetzwerk (PSTN) 114 zu liefern; im Übrigen sind die Funktionalität von MSC 110 und GMSC 112 sehr ähnlich. Außerdem, wie dies allgemein in 1 dargestellt wird, ist das GMSC 112 auch über Signalisierverbindungen mit den vier Datenbankknoten, welche oben beschrieben wurden, gekoppelt, und damit wird der gesamte Signalisiernachricht-Zugriff auf diese Datenbankknoten durch das GMSC gesteuert und verwaltet. Obwohl nicht in 1 dargestellt, kann das MSC auch direkt an die Datenbankknoten gekoppelt sein. Das IWMSC 132 ist typischerweise ein MSC 110 oder ein GMSC 112, welches auch die Funktion der Zusammenarbeit zwischen dem SMSC 130 und dem Rest des Mobilnetzwerkes besitzt.
Von spezieller Relevanz für die vorliegende Erfindung sind die Signalisiergesichtspunkte des GSM-Netzwerks, welches oben beschrieben ist, besonders jene Aspekte, welche den Signalisier-Interaktionen zwischen einem HLR- oder SMSC-Datenbankknoten und einem Knoten vom SMC- oder GMSC-Typ zugeordnet sind. Um diese Signalisier-Interaktionen besser zu verstehen, wird nachfolgend eine detaillierte Erklärung der HLR-Operation geliefert.
Innerhalb eines GSM-drahtlosen Kommunikationsnetzwerks wird jedem Mobilstations-Handgerät 128 eine einzigartige Identifi kationsnummer zugeordnet, welche als eine Internationale Mobile Teilnehmeridentität (IMSI)-Identifikationsnummer bekannt ist. Im Falle der Implementierungen des Netzwerkes vom europäischen GSM-Typ ist der IMSI-Code typischerweise mit einem bestimmten Telefonhandgerät verbunden. In derartigen Netzwerken kann jeder Nutzer einer oder mehrerer Nummern des Mobile Station Integrated Services Digital Network (MSISDN) zugeordnet werden. In der drahtlosen bzw. Funktelekommunikationsindustrie sind die MSISDN-Nummern analog zu den 10 Digitaltelefonnummern in einem herkömmlichen nordamerikanischen Drahtnetzwerk. Die Tatsache, dass viele MSISDN-Nummern mit einer einzigen IMSI-Nummer verbunden bzw. zugeordnet sein können, zeigt, dass mehr als eine MSISDN-Nummer angegeben und genutzt werden kann, um ein einzelnes Mobilstations-Handgerät zu erreichen. Es sollte anerkannt werden, dass in dieser Veröffentlichung der Term "Mobile Identification Number" bzw. "Mobile Identifikationsnummer" (MIN) generell benutzt wird, um sich damit auf IMSI-, MSISDN-, Mobile Global Title-, ANSI-41-Mobil-Identifikationsnummern (MIN) und Mobilverzeichnisnummern (MDN) und andere Identifikationsnummern zu beziehen, welche mit Teilnehmern oder Diensten in einem Funknetzwerk verbunden sind.
Auf jeden Fall wird eine MSISDN-Nummer gewählt, wann immer ein Nutzer mit einem speziellen Mobilstations-Handgerät kommunizieren will. Ein MSC oder GMSC bestimmt, indem es einen Teil der gewählten MSISDN-Nummer analysiert, das spezielle HLR, welches die Leitweglenkinformation speichert, welche mit der gerufenen Mobilstation verbunden ist. Durch Wiedergewinnen und Nutzen derartiger Leitweglenkinformation ist das GSM-Netzwerk in der Lage, die gerufene Mobilstation in Antwort auf einen Anrufversuch zu lokalisieren, so dass eine Rufverbindung zwischen der anrufenden Partei und der gerufenen Mobilstation aufgebaut werden kann. Es sollte auch anerkannt werden, dass abhängig von der Art des Rufes oder des Signalisierereignisses ein MSC alternativ den HLR-Suchlauf analysieren und durchfüh ren kann, basierend auf der IMSI- oder MSISDN-Nummer, welche mit der gerufenen oder der anrufenden Partei verbunden ist.
2 stellt eine typische GSM-Netzwerk-Architektur dar, welche im Allgemeinen mit der Nummer 150 bezeichnet wird, welche ein GMSC 154 beinhaltet, welches sowohl an ein MSC 152 als auch an eine einzelne HLR-Einheit 156 angeschlossen ist. Das GMSC 154 beinhaltet eine Leitwegtabelle 160, während das HLR 156 eine Datenbanktabelle 158 beinhaltet. 3 stellt auch eine typische GSM-Netzwerk-Architektur dar, welche im Allgemeinen mit der Nummer 180 bezeichnet wird, welche ein GMSC 182 beinhaltet, welches mit einigen HLR-Einheiten verbunden ist. Speziell ist das GMSC 182 über Signalisierverbindungen jeweils mit dem HLR A 186, HLR B 190 und dem HLR C 194 und notwendigerweise mit den HLR-Datenbanktabellen 188, 192 bzw. 196 verbunden.
In den Beispielen, welche sowohl in 2 und 3 dargestellt werden, ist jedes der HLRs so konfiguriert, dass es einen vorher definierten Block von Teilnehmer-MSISDN-Nummern dient. Im Allgemeinen wird eine spezielle Serie oder ein Block von MSISDN- (oder IMSI-)Nummern jedem HLR in einem Service-Provider-Netzwerk zugewiesen. Es sollte anerkannt werden, dass die HLR-Datenbank und die GMSC-Leitweg-Tabellenstrukturen, welche in den 2-3 gezeigt werden, nur zur Erläuterung des Informationsspeicherkonzeptes auf hohem Niveau dienen und nicht dafür gedacht sind, die aktuellen Datenstrukturen wiederzugeben, 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 einer gegebenen HLR-Einheit zu ändern, wegen der Leitweglenkbeschränkungen des MSC, welches mit der HLR-Einheit verbunden ist. Folglich haben die Service Provider nicht die Gelegenheit, dynamisch ihre MSISDN-Nummernbasis über viele HLRs hinweg neu zu belegen, um effizienter existierende HLR-Ressourcen (d.h. Aufteilen der Belastung) zu nutzen. Es sollte beachtet werden, dass diese Begrenzung das typische Ergebnis der Beschränkungen der Leitwegtabelle in den MSCs ist und im Allgemeinen nicht auf Datenbankspeichereinschränkungen in den HLRs zurückzuführen ist. D. h., obwohl die HLRs im Allgemeinen so belegt sein können, um Teilnehmerdateneinträge für jede IMSI- oder MSISDN-Nummer zu enthalten, sind MSCs typischerweise nur in der Lage, Nachrichten basierend auf einem IMSI- oder MSISDN-Block, in welchen die IMSI- oder MSISDN-Nummer fällt, leitwegzulenken. Diese IMSI- oder MSISDN-Blöcke bestehen aus einem sequenziellen Bereich von IMSI- oder MSISDN-Nummern. Damit es ist die begrenzte Kapazität des Leitweglenkens eines MSC oder eines GMSC, welche das Problem erzeugt, und typischerweise nicht die HLR-Knoten.
Z. B. wird in 2 der gesamte Verkehr, welcher sich auf Anrufe bezieht, welche einer MSISDN-Nummer zwischen 9199670000 und 9199679999 zugeordnet sind, zu dem HLR A 156 durch das verbundene GMSC 154 leitweggelenkt. Da der Service Provider beginnt, mehr und mehr Kunden zu akquirieren (d. h. Angeben von immer mehr MSISDN-Nummern in dem zugeordneten Block oder der Serie 9199670000 bis 9199679999), wird sich der Verkehr oder die Überlast, welche an dem HLR A 156-Knoten erlebt wird bzw. auftritt, entsprechend erhöhen.
Man überlege nun, dass ein Service Provider, welcher die Netzwerkelemente besitzt, welche in 2 dargestellt sind, so viele neuen Kunden akquiriert hat, dass er sich entschließt, in eine zusätzliches Paar von HLRs zu investieren. Dieses Szenario wird im Allgemeinen in 3 dargestellt, wo zwei zusätzliche HLRs als HLR B 190 und HLR C 194 identifiziert werden. Zur Zeit der Implementierung ist HLR B 190 mit dem MSISDN-Nummernblock 919968000-9199689999 belegt, und HLR C 194 ist mit einem MSISDN-Nummernblock 9199690000-9199699999 belegt. Diese beiden HLRs sind mit dem benachbarten GMSC 182 verbunden und werden so aktiviert, dass sie Anrufe, welche ihren vorprogrammierten MSISDN-Blöcken entsprechen, bedienen.
Der Hauptnachteil derartiger Vielfach-HLR-Konfigurationen kann nun besser erkannt werden. Wie allgemein in 3 angezeigt wird, muss trotz des Hinzufügens der neuen HLR-Ressourcenkapazität, welche durch die Einheiten B und C dargestellt wird, der gesamte Verkehr, welcher mit den MSISDN-Nummern 9199670000-9199679999 verbunden ist, noch durch einen einzelnen HLR, HLR A 188 bearbeitet werden. Selbst wenn der Service Provider keine Kunden innerhalb des Bereichs der MSISDN-Nummern 9199680000 – 9199699999 hat, ist es für den Service Provider nicht möglich, dynamisch den "voll zugewiesenen" 9199670000-9199679999-MSISDN-Nummernblock unter den nicht benutzten HLR B 192- und HLR C 196-Einheiten wieder zuzuordnen und rückzuverteilen. Damit ist es leicht möglich, dass der Service Provider in einer Situation arbeiten wird, wo sich der Verkehr auf HLR A 188 sehr stark staut, während die HLR B 192- und HLR C 196-Ressourcen völlig ungenutzt sind. Dies kann zu einer geringeren effizienten Nutzung der installierten Ressourcen führen, wohingegen es für einen Belastungsausgleich effizienter sein würde, den Verkehr gleichmäßig unter den drei HLR-Einheiten aufzuteilen.
Es sollte anerkannt werden, dass zusätzlich zu den Bedenken des Lastaufteilens es ähnliche Äußerungen und ähnliche Notwendigkeiten gibt, welche auftreten, wenn man das Portieren von Teilnehmern von einem Service Provider zu einem anderen Provider in Betracht zieht, welches in anderer Hinsicht als Lokalnummernportabilität (LNP) bekannt ist. Nochmals, das zentrale Problem ist die Fähigkeit, die Teilnehmerinformation unter vielen HLR-Knoten frei zu verteilen. Eine detaillierte Diskussion des speziellen Problems, welches mit LNP verbunden ist, wird in dieser Veröffentlichung nicht geliefert, da die hoch gradigen Aussagen und Bedenken die gleichen sind wie die des hier beschriebenen Lastaufteilungsszenarios.
In dem US-Patent Nr. 5,878,347 von Joensuu, et al. (nachfolgend "das '347-Patent") wird eine Vorgehensweise veröffentlicht, um einige der oben identifizierten und diskutierten Probleme zu lösen. Die im '347-Patent beschriebene Lösung beinhaltet das Implementieren eines neuen Netzwerkelementes, welches als ein virtuelles HLR (vHLR) bezeichnet wird. 4 der vorliegenden Anmeldung und der folgenden Beschreibung erläutert die Funktion des vHLR in dem '347-Patent. Mit Bezug auf 4 ist ein vHLR-Knoten 214 in dem Kommunikationsnetzwerkpfad zwischen einem GMSC 212 und einer Vielzahl von HLR-Knoten, HLR A 218, HLR B 222 und HLR C 226 platziert. Die HLRs 218, 222 und 226 beinhalten jeweils Teilnehmerdatenbanken 220, 224 bzw. 228. Das GMSC 212 sendet Signalisiernachrichten an den vHLR-Knoten 214, wobei Teilnehmerinformation angefordert wird, wobei der einzelne Teilnehmer mit einer IMSI- oder MSISDN-Mobilstations-Identifikationsnummer verbunden ist. Das vHLR 214 enthält keine Teilnehmerinformation; vielmehr beinhaltet das vHLR 214 eine Leitwegtabelle 216, welche IMSI- oder MSISDN-Nummern mit einem speziellen HLR korreliert. Speziell beinhaltet die Leitwegtabelle 216 Information, welche sich auf die IMSI- oder MSISDN-Nummern für eine entsprechende Netzwerkadresse bezieht, welche mit dem HLR verbunden ist, welche dem IMSI- oder MSISDN-Teilnehmer dient.
Die Nachricht-Leitweglenktechnik, welche in dem '347-Patent veröffentlicht wird, ist ein Schlüsselelement der hier beschriebenen Erfindung. Wie allgemein in 4 dargestellt wird, wenn der vHLR-Knoten 214 eine Nachricht 234 von dem angeschlossenen GMSC 212 empfängt, wird die Nachricht zu dem vHLR-Knoten 214 adressiert und ihm direkt geliefert. Der vHLR-Knoten 214 führt einen Tabellensuchlauf durch, wie oben beschrieben, und leitet die Nachricht zu dem geeigneten HLR- Knoten, in diesem Fall dem HLR C 228 zurück. Diese Rückleitfunktion wird durch Ändern des Zielpunktcodes (DPC) der Nachricht 236-Leitweglenkungskennung bzw. -adresse ausgeführt, so dass der Original-DPC (PC=vHLR) durch einen neuen DPC (PC=HLR C) ersetzt wird. Es ist signifikant und sollte beachtet werden, dass der vHLR-Knoten 214 nicht seinen Ursprungspunktcode (OPC) der Nachricht-Leitweglenkkennung ändert. D. h., der OPC der eingehenden Nachricht 234 ist der gleiche wie der OPC der ausgehenden Nachricht 236, welches der Punktcode des GMSC 212 ist. Damit kommt die Nachricht am HLR C 228 mit einem OPC an, welcher gleich dem Punktcode des GMSC-Knotens 212 ist. Das HLR C 228 antwortet mit einer Nachricht 238, welche an das GMSC 212 adressiert ist. Die HLR C-Antwortnachricht 238 wird nicht zu dem vHLR-Knoten 214 zurück gelenkt.
Während eine derartige Leitweglenktechnik einen oder mehrere Leitweglenk-"Sprünge" spart, aus der Sicht einer Netzwerksteuerungsperspektive, präsentiert eine derartige Leitweglenktechnik wenigstens ein signifikantes Problem. D. h. im Falle, dass ein HLR in die Lage kommen könnte, dass er einen Dienst nicht liefern kann, erfordert die SS7-Signalisierkonvention, dass das HLR eine Nachricht zu einem Signalisierpunkt (SP) sendet, welcher versucht, mit ihr zu kommunizieren, wobei der SP vor dem Geschädigten oder außer Funktion befindlichen Status des HLR gewarnt wird. Wenn der Nachrichtenfluss, wie oben beschrieben, gegeben wird, wird anerkannt werden, dass bei einem derartigen Außer-Funktion-Szenario der HLR C 226 eine Netzwerksteuerungsnachricht an den Urheber der eingehenden HLR C-Nachricht 236 senden würde. Der Urheber der eingehenden HLR C-Nachricht 236 wird durch das OPC-Feld der Nachricht 236-Leitweglenkkennung identifiziert. Wie oben beschrieben, ändert der vHLR 214-Knoten nicht das OPC-Feld der Leitweglenkkennung, sondern hinterlässt stattdessen, dass das OPC auf die Adresse des GMSC 212 gesetzt wird. Damit werden die Netzwerksteuerungsnachrichten, welche durch HLR C 226 gesandt werden, an das GMSC 212 adressiert. Das Problem bei einem derartigen Nachrichten-Leitweglenkschema besteht darin, dass das GMSC 212 kein "Wissen" darüber besitzt, dass eine Nachricht an das HLR C 226 gesandt wurde. Wiederum wird anerkannt werden, dass der DPC der Nachricht 234, welche ursprünglich durch das GMSC 212 gesandt wurde, die Netzwerkadresse des vHLR 214 war. D. h., das GMSC 212 hat Kenntnis von einer Nachricht, welche an das vHLR 214 gesandt wurde, aber keine Kenntnis einer speziellen Nachricht, welche für HLR C 226 bestimmt war. Das Implementieren eines derartigen SS7-Nachricht-Leitweglenkschemas würde deshalb ein großes Problem für SS7-Netzwerkbetreiber darstellen, welche eine große Anzahl von Netzwerkelementen gekauft und aufgestellt haben, welche in Erfüllung der Industriestandard-SS7-Kommunikationsprotokolle und der Netzwerksteuerungsverfahren arbeiten.
Was deshalb benötigt wird, ist ein neues System und ein Verfahren zum Rücklenken von Signalisierungsnachrichten unter verschiedenen HLR-, EIR-, AuC- und anderen ähnlichen Signalisierungsdatenbankknoten, bei welchen Nachricht-Leitweglenken in einer derartigen Weise auftritt, um die Erfüllung existierender Industriestandardnetzwerk-Steuerungssignalisierungsprotokolle zu bewahren.
In der WO-A-9856195 wird ein SMS-Leitweglenkverfahren veröffentlicht, wobei die SMS entsprechend dem geforderten Dienst an das relevante SMSC leitweggelenkt wird. Diese Veröffentlichung bezieht sich jedoch nicht auf das Problem der vorliegenden Erfindung.
Veröffentlichung der Erfindung
Entsprechend einem Gesichtspunkt beinhaltet die vorliegende Erfindung einen flexiblen Leitweglenkknoten. Der flexible Leitweglenkknoten beinhaltet ein Kommunikationsmodul, welches in der Lage ist, Datenpakte über ein Netzwerk zu senden und zu empfangen. Eine bereichsbasierte Datenbank beinhaltet bereichsbasierte Regelaufzeichnungen, welche durch Blöcke von Identifikationsnummern indiziert sind. Eine auf Ausnahmen basierende Datenbank beinhaltet auf Ausnahmen basierende Regelaufzeichnungen, welche durch eine einzelne Identifikationsnummer indiziert sind. Ein Datenbank-Teilsystem-Steuergerät greift auf wenigstens eine der Datenbanken zu, um Leitweglenkinformation für das Datenpaket zu extrahieren. Da der flexible Leitweglenkknoten sowohl bereichsbasierte und ausnahmenbasierende Datenbanken beinhaltet, wird die Flexibilität beim Zuordnen von Mobil-Identifikationsnummern unter den HLRs erhöht.
Entsprechend ist es eine Aufgabe der vorliegenden Erfindung, einen flexiblen Leitweglenkknoten zu liefern, welcher in der Lage ist, sowohl bereichsbasierte als auch auf ausnahmenbasierte Datenbank-Suchläufe durchzuführen.
Es ist eine andere Aufgabe der vorliegenden Erfindung, einen flexiblen Leitweglenkknoten zu liefern, welcher die Verfahren entsprechend dem Industriestandard-Netzwerksteuern erfüllt.
Einige der hier aufgeführten Aufgaben der Erfindung sowie andere Aufgaben werden aus der folgenden Beschreibung offensichtlich, welche mit den beigefügten Zeichnungen gegeben wird, welche nachfolgend bestens beschrieben werden.
Kurze Beschreibung der Zeichnungen
1 ist ein Netzwerkdiagramm, welches eine GSM-Funktelekommnikationsnetzwerk-Architektur entsprechend dem Stand der Technik darstellt.
2 ist ein Netzwerkdiagramm, welches eine GSM-Funktelekommunikationsnetzwerks-Implementierung entsprechend dem Stand der Technik darstellt, welche einen einzelnen HLR-Knoten beinhaltet.
3 ist ein Netzwerkdiagramm, welches eine GSM-Funktelekommunikationsnetzwerk-Implementierung entsprechend dem Stand der Technik darstellt, welche viele HLR-Knoten beinhaltet.
4 ist ein Netzwerkdiagramm, welches eine GSM-Funktelekommunikationsnetzwerk-Architektur entsprechend dem Stand der Technik darstellt.
5 ist ein schematisches Diagramm eines Signalübertragungspunkt-Vermittlungsknotens, entsprechend dem Stand der Technik.
6 ist ein schematisches Netzwerkdiagramm, welches ein erstes Leitweglenkdatenbank-Zugriffsszenario entsprechend einer bevorzugten Ausführungsform eines flexiblen Leitweglenkknotens der vorliegenden Erfindung darstellt.
7 ist ein schematisches Netzwerkdiagramm, welches ein zweites Leitweglenkdatenbank-Zugriffsszenario entsprechend einer bevorzugten Ausführungsform für einen flexiblen Leitweglenkknoten der vorliegenden Erfindung darstellt.
8 ist ein schematisches Netzwerkdiagramm, welches eine andere Netzwerkimplementierung eines flexiblen Leitweglenkknotens der vorliegenden Erfindung darstellt.
9a ist eine Tabelle, welche eine beispielhafte G-FLEX^TM-Datenbankstruktur darstellt, welche in einer bevorzugten Ausführungsform eines flexiblen Leitweglenkknotens der vorliegenden Erfindung benutzt wird.
9b ist eine Tabelle, welche eine beispielhafte GTT-Datenbankstruktur darstellt, welche in einer bevorzugten Ausführungsform eines flexiblen Leitweglenkknotens der vorliegenden Erfindung benutzt wird.
10a ist eine Tabelle, welche einen Teilinhalt einer Signalisiernachricht darstellt, welche durch einen flexiblen Leitweglenkknoten der vorliegenden Erfindung in einem ersten Beispielsszenario empfangen und bearbeitet wird.
l0b ist eine Tabelle, welche einen Teilinhalt einer Signalisiernachricht darstellt, welche durch einen flexiblen Leitweglenkknoten der vorliegenden Erfindung in einem zweiten Beispielsszenario empfangen und bearbeitet wird.
l0c ist eine Tabelle, welche einen Teilinhalt einer Signalisiernachricht darstellt, welche durch einen flexiblen Leitweglenkknoten der vorliegenden Erfindung in einem dritten Beispielsszenario empfangen und bearbeitet wird.
11 ist ein Flussdiagramm, welches den Umsetzungsprozess, welcher durch einen flexiblen Leitweglenkknoten der vorliegenden Erfindung implementiert ist, darstellt.
12 ist ein Netzwerkdiagramm, welches das Leitweglenken von Kurznachricht-Dienstnachrichten entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt.
Detaillierte Beschreibung der Erfindung
Entsprechend einer Ausführungsform beinhaltet die vorliegende Erfindung einen flexiblen Leitweglenkknoten für die Kommunikation mit einem GMSC und mit HLRs oder SMSCs in einem Netzwerk. In einer bevorzugten Ausführungsform wird bei einem flexiblen Leitweglenkknoten eine interne Architektur angewandt, welche ähnlich zu der eines Hochleistungs-STP ist, welcher durch die Anmelder der vorliegenden Erfindung als EAGLE^® STP vermarktet wird. 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 von Tekelec, gefunden werden, wobei diese Veröffentlichung hier als Referenz aufgeführt wird. Wie in dieser Publikation beschrieben wird, beinhaltet ein EAGLE^® STP 250 die folgenden Teilsysteme: ein Wartungs- und Verwaltungsteilsystem (MAS) 252, ein Kommunikationsteilsystem 254 und ein Applikationsteilsystem 256. Das MAS 252 liefert Wartungskommunikationen, das Laden des Startprogramm, periphere Dienste, das Alarmverarbeiten und Systemplatten. Das Kommunikationsteilsystem 254 beinhaltet einen Interprozessor-Nachrichtentransport (IMT)-Bus, welcher der Hauptkommunikationsbus innerhalb aller Teilsysteme im EAGLE^® STP 250 ist. Dieses Hochgeschwindigkeits-Kommunikationssystem funktioniert wie zwei mit 125 Mb/s gegenläufig umlaufende serielle Busse.
Das Anwendungsteilsystem 256 beinhaltet Applikationskarten, welche in der Lage sind, mit den anderen Karten über die IMT-Busse zu kommunizieren. Zahlreiche Arten von Applikationskarten können in dem STP 250 enthalten sein, welche beinhalten: ein Verbindungs-Interface-Modul (LIM) 258, welches SS7-Verbindungen und X.25-Verbindungen liefert, ein Applikations-Kommunikationsmodul (ACM) 260, welches ein TCP/IP-Interface an eine externe Anzeigevorrichtung über Ethernet liefert, und ein Applikations-Dienstmodul (ASM) 262, welches eine globale Titelumsetzung, Netzübergangsabschirmen und andere Dienste liefert. Ein Umsetzungsduienstmodul (TSM) 264 kann auch für die lokale Zahlenportabilität vorgesehen werden. Eine detaillierte Beschreibung des EAGLE^® STP wird in dem oben zitierten Feature Guide gegeben und muss hier nicht im Detail beschrieben werden.
6 ist ein schematisches Diagramm eines vereinfachten GSM-Netzwerkes 300, welches einen flexiblen Knoten 203 entsprechend einer Ausführungsform der vorliegenden Erfindung beinhaltet. Zusätzlich zum flexiblen Leitweglenkknoten 302 beinhaltet das GSM-Netzwerk 300 im Allgemeinen: ein SS7-Signalisiernetzwerk 346, ein Netzübergangs-Mobilschaltzentrum (GMSC) 348, ein Internet-Protokoll-(IP-)Netzwerk 350, ein erstes Heimatregister (HLR) 352, ein zweites HLR 354 und ein drittes HLR 356.
In der dargestellten Ausführungsform beinhaltet der flexible Leitweglenkknoten 302 einen Hochgeschwindigkeits-Interprozessor-Nachricht-Transport-(IMT-)Kommunikationsbus 304. Kommunikativ sind mit dem IMT-Bus 304 eine Anzahl von verteilten bzw. dezentralisierten Datenbearbeitungsmodulen oder -karten gekoppelt, welche beinhalten: ein Paar von Wartungs- und Verwaltungs-Teilsystemprozessoren (MASPs) 306, ein SS7-fähiges Verbindungs-Interface-Modul (LIM) 308, ein IP-fähiges Datenkommunikationsmodul (DCM) 336 und ein G-FLEX^TM-Datenbasismodul (GDM) 322. Diese Module sind physikalisch mit dem IMT-Bus 304 durch jeweils die Interfaces 318, 324 bzw. 338 verbunden. Zur Vereinfachung der Darstellung sind nur ein einzelner LIM 308, GDM 322 und DCM 336 in 6 enthalten. Es sollte jedoch anerkannt werden, dass die verteilte Multiprozessor-Architektur des Knotens 302 den Einsatz von vielen LIM-, GDM- und DCM-Karten erleichtert, welche alle simultan an den IMT-Bus 304 angeschlossen werden können.
Das MASP-Paar 306 implementiert die Wartungs- und Verwaltungs-Teilsystemfunktionen, welche oben beschrieben sind. Da das MASP-Paar 306 nicht speziell für eine Diskussion der flexiblen Leitweglenkeigenschaften der vorliegenden Erfindung relevant ist, wird der Leser auf die oben erwähnten Tekelec-EAGLE^®- Veröffentlichungen für eine detailliertere Beschreibung dieser Systemkomponenten hingewiesen.
Wenn man nun die Funktionalität der LIM-Karte betrachtet, so weist die dargestellte Ausführungsform LIM 308 eine Anzahl von Teilkomponenten auf, wobei diese beinhalten, jedoch nicht auf diese beschränkt sind: einen 557-MTP-Pegel-1-und-2-Schichtprozess 310, einen E/A-Puffer oder eine Warteschlange 312, einen SS7-MTP-Pegel-3-Schicht-HMDC-Prozess 314 und einen HMDT-Prozess 316. Der MTP-Pegel-1-und-2-Schichtprozess 310 liefert die Ausstattung, welche notwendig ist, digitale Daten über ein spezielles physikalisches Medium/physikalisches Interface zu senden und zu empfangen als auch eine Fehlerdetektion/korrektur zu liefern und eine sequenzierte bzw. geordnete Lieferung aller SS7-Nachrichtenpakete. Die E/A-Warteschlange 312 dient dem zeitweiligen Puffern eingehender und ausgehender Signalisiernachrichtenpakete. Der MTP-Pegel-3-HMDC-Prozess 314 führt eine Diskriminierfunktion durch, wobei effektiv festgelegt wird, ob ein eingehendes SS7-Nachrichtenpaket eine interne Verarbeitung erfordert oder nur einfach durchzuschalten ist, d. h. zu einem anderen Knotenleitweg zu lenken ist. Der HMDT-Prozess 316 führt das interne Leitweglenken der SS7-Nachrichtenpakete durch, welche eine zusätzliche Bearbeitung vor dem endgültigen Leitweglenken erfordern.
Im Allgemeinen liefert eine GDM-Karte die Datenbanken und die Datenbanksteuerprozesse, welche notwendig sind, um die erforderlichen Netzwerkadressumsetzungen auszuführen, um die flexible Leitweglenkfunktionalität zu erreichen, welche durch die Ausführungsformen der vorliegenden Erfindung implementiert sind. Das GDM 322, welches in 6 gezeigt wird, weist zum Teil auf: ein Signalisierverbindungs-Steuerteil (SCCP)-Teilmodul 326, welches ferner ein Datenbankteilsystem-Steuergerät beinhaltet, welches als ein Signalisierverbindungs-Leitweglenksteuergerät-(SCRC-)Prozess 328 bekannt ist. Der SCRC- Prozess 328 ist für das Nummernkonditionieren, das Leiten von eingehenden SS7-Nachrichtenpaketen zu entweder einem G-FLEX^TM-Datenbankprozess 330 oder zu einem globalen Titelumsetzungs(GTT-)Datenbankprozess 332 und für die Modifikation der Nachrichtenpakete verantwortlich, um Leitweglenkinformation zu beinhalten, welche von den G-FLEX^TM- oder GTT-Datenbankprozessen 330 bzw. 332 zurückkommen. Die SS7-Nachrichtenpakete, welche den SCRC-Prozess 328 verlassen, werden von einem HMRT-Prozess 334 empfangen und weiterbearbeitet. Der HMRT-Prozess 314 ist für das externe Leitweglenken der SS7-Nachrichtenpakete verantwortlich, welche keine zusätzliche Bearbeitung durch den flexiblen Leitweglenkknoten 302 erfordern. D. h., der HMRT-Prozess 334 legt fest, zu welcher LIM- oder DCM-Karte ein SS7-Nachrichtenpaket für die nachfolgende, nach außen gerichtete Übertragung leitweggelenkt werden sollte. Es wird auch aus 6 anerkannt werden, dass das GDM 322 über eine Ethernet-Verbindung 333 an ein OAM-Teilsystem 335 gekoppelt und durch dieses bedient wird. Das OAM-Teilsystem 335 ist für die Verwaltung und die Wartung der G-FLEX^TM- und GTT-Datenbanken 330 bzw. 332 verantwortlich.
Das DCM 336, welches in 6 gezeigt wird, beinhaltet einen HMCG-Prozess 340, welcher für das Anzeigen eines Staus an den verbundenen DCM-Verbindungssätzen verantwortlich ist und kommuniziert das interne diese Verbindungsstauinformation, um die Prozesse an anderen Modulen sich über den IMT-Bus 304 anzusehen. Eine derartige Verbindungsstauinformation wird von dem HMRT-Prozess 334 während nach außen gehender Verbindungsauswahloperationen benutzt. Es sollte anerkannt werden, dass ausgehende SS7-Nachrichtenpakete, welche über das DCM 336 leitweggelenkt werden, aus dem flexiblen Leitweglenkknoten 302 und in ein Internet-Protokoll(IP)-Netzwerk 350 übertragen werden. Da das SS7-Kommunikationsprotokoll und das IP-Kommunikationsprotokoll nicht von Natur aus kompatibel sind, werden alle SS7-Nachrichtenpakete, welche in das IP-Netzwerk 350 zu senden sind, zuerst innerhalb einem IP-Leitweglenk-Envelope bzw. -Bitgruppe vor der Übertragung eingekapselt. Diese IP-Einkapselung wird durch einen IP-Einkapselungsprozess 342 durchgeführt. Der IP-Einkapselungsprozess 342 ist das IP-Protokoll äquivalent zum SS7-MTO-Pegel-1-2-Schichtprozess 310 des LIM-Moduls 308. Bevorzugte Paketformate für das Einkapseln verschiedener Arten von SS7-Nachrichten in IP-Paketen werden in Internet Engineering Task Force (IEFT) INTERNET DRAFT mit dem Titel Transport Adapter Layer Interface, 28. Mai 1999, beschrieben, wobei diese Veröffentlichung hier als Referenz in ihrer Gesamtheit aufgeführt wird.
Nochmals, die Beschreibung der LIM- und DCM-Teilkomponenten, welche hier geliefert werden, ist auf jene Teilkomponenten beschränkt, welche für die Beispiel-Implementierszenarien relevant sind, welche in den 6 und 7 dargestellt werden. Für eine zusammenfassende Diskussion zusätzlicher LIM- und DCM-Operationen und -Funktionalitäten können die oben als Referenz aufgeführten Tekelec-Veröffentlichungen herangezogen werden.
Mit speziellem Bezug auf das Szenario, welches in 6 dargestellt wird, ist das Netzübergangs-Mobilschaltzentrum 348 kommunikativ mit dem flexiblen Leitweglenkknoten 302 über eine SS7-Kommunikationsverbindung 320 verbunden. Spezieller ausgedrückt, der GMSC-Knoten 348 ist mit dem LIM 308 über die SS7-Kommunikationsverbindung 320 verbunden. Der DCM-Modul 336 ist mit dem externen IP-Netzwerk 350 über eine IP-Kommunikationsverbindung 344 verbunden. Innerhalb des IP-Netzwerkes 350 sind die HLR-Knoten 352, 354 und 356 angeordnet und mit ihm verbunden. Ebenso existiert ein IP-Kommunikationspfad zwischen dem DCM-Modul 336 des flexiblen Leitweglenkknotens 302 und jedem der HLR-Knoten 352, 354 und 356. Der IP-Kommunikationspfad kann TCP/IP oder UDP/IP sein. Es sollte anerkannt werden, dass in einer anderen Ausführungsform des flexiblen Leitweglenkkno tens 302 entsprechend einer Ausführungsform der vorliegenden Erfindung das Kommunikationsprotokoll, welches zwischen dem GMSC 348 und dem flexiblen Leitweglenkknoten 302 implementiert ist, ein IP- oder ein anderes Nicht-SS8-Protokoll sein kann, wie z. B. ein Asynchroner Übertragungsmodus (ATM) oder ein Synchrones Optisches Netzwerk (SONET). Z. B. kann eine IP-Kommunikationsverbindung ebenso effektiv zwischen dem GMSC 348 und dem flexiblen Leitweglenkknoten 302 benutzt werden. In einem derartigen Fall würde ein gebräuchliches konfiguriertes DCM-Modul für den LIM 308, welcher in 6 gezeigt wird, substituiert werden. In ähnlicher Weise könnte das Kommunikationsprotokoll, welches zwischen dem flexiblen Leitweglenkknoten 302 und den HLR-Knoten 352, 354 und 356 implementiert ist, ein SS7-, Interim Standard-41(IS-41)-, GSM- oder ein anderes Nicht-IP-Protokoll sein. Z. B. könnte eine SS7-Kommunikationsverbindung zwischen dem flexiblen Leitweglenkknoten 302 und den HLR-Knoten 352, 354 und 356 angewendet werden. In einem derartigen Fall würden viele LIM-Module anstelle des DCM 336, welcher in 6 gezeigt wird, eingesetzt werden.
Wie oben festgestellt wurde, ist es ein Problem, welches mit dem Aufteilen der Last und dem Portieren von Nummern auf viele HLR-Knoten verbunden ist, dass herkömmliche MSCs und GMSCs nur in der Lage sind, blockbasiertes Adressieren durchzuführen. In ähnlicher Weise ist es ein Problem, welchem viele mobile Vermittlungen gegenüberstehen, dass die SMSC-Adressen den Teilnehmern gegeben oder in die Teilnehmer-Handgeräte programmiert werden müssen. Wenn viele SMSCs benutzt werden, kann es sehr schwierig werden, diesen Teilnehmer für die SMSC-Umsetzung zu steuern. Da dem so ist, wird es sehr anerkannt werden, dass es eine der vorrangigsten Aufgaben des flexiblen Leitweglenkknotens entsprechend einer Ausführungsform der vorliegenden Erfindung ist, ein Verfahren zu liefern, bei welchem eine Netzwerkvermittlung schnell und leicht Signalnachrichten, welche mit einem gegebenen Anruf oder einer angerufenen Partei verbunden sind, an einen speziellen HLR- oder SMSC-Knoten zu leiten. Um ein derartiges Rückführen der Signalisiernachricht zu erleichtern, wendet der flexible Leitweglenkknoten der vorliegenden Erfindung ein Paar von komplementierenden Leitweglenkdatenbanken an, welche effektiv eine IMSI- oder MSISDN-Nummer, welche mit einer Signalisiernachricht verbunden ist, auf die Netzwerkadresse des geeigneten HLR- oder SMSC-Knotens umsetzt. Diese Datenbanken, welche oben beschrieben sind, werden als G-FLEX^TM-Datenbank und/oder als GTT-Datenbank bezeichnet.
9a und 9b sind Datenbankstrukturdiagramme, welche in erster Linie die Schlüssel- oder die Indizierstrukturen der G-FLEX^TM- und GTT-Datenbanken 330 bzw. 332 erläutern sollen. Es sollte anerkannt werden, dass die G-FLEX^TM- und GTT-Datenbank-Aufzeichnungsstrukturen und Pseudodaten, welche in 9a und 9b gegeben werden, welche unterstützend für die Beispiele, welche in 6 und 7 gezeigt werden, sind, hier nur erläuternd für die Grundinformation sind, welche notwendig ist, um die erforderlichen Leitweglenkdaten-Suchläufe durchzuführen. In der Praxis können die aktuellen Datenbank-Aufzeichnungsstrukturen und das gesamte Datenbankdesign entsprechend den einzelnen Implementieranforderungen unterschiedlich sein.
Das komplementäre Datenbank-Zugriffsschema, welches durch den flexiblen Leitweglenkknoten der vorliegenden Erfindung angewendet wird, erfordert, dass die GTT-Datenbank 332 einen Satz von bereichs- oder blockbasierten Leitweglenkregeln enthält, während die G-FLEX^TM-Datenbank 330 Ausnahmen für die blockbasierten Leitweglenkregeln hält. Noch einmal, dieses Konzept wird allgemein in den 9a und 9b erläutert. Unter bereichs- oder blockbasierten Leitweglenkregeln wird verstanden, dass ein Block oder ein Bereich von mobilen Identifikationsnummern (IMSI, MSISDN, etc.) mit der Netzwerkadresse eines einzelnen HLR, EIR, AuC, Service-Steuerpunkt (SCP), etc. verbunden ist. Eine derartige bereichsbasierte Leitweglenkregel-Datenbankstruktur ist ähnlich zu den Leitweglenkdatenbankstrukturen, welche gewöhnlich in herkömmlichen GMSC-Knoten, wie oben beschrieben, angewandt wird.
Mit Bezug auf 9b beinhaltet das GTT oder die bereichsbasierte Datenbank 332 Schlüsselfelder auf der linken Seite der Spalte und Datenfelder auf der rechten Seite der Spalte. Die Schlüsselfelder stellen Bereiche von Mobil-Identifikationsnummern dar, welche mit einem speziellen Knoten verbunden sind. Z. B. spezifiziert das erste Schlüsselfeld eine minimale Mobil-Identifikationsnummer von 9199670000 und eine maximale Mobil-Identifikationsnummer von 9199679999. Die Datenfelder, welche diesem Bereich entsprechen, beinhalten einen Punktcode (PC) von 3-0-2, eine Teilsystemnummer (SSN) von 6 und einen Leitweglenk-Indikator (RI) von RT-ON-SSN für das Netzwerkelement, welches dem Bereich in dem Schlüsselfeld entspricht. Die Daten, welche in den Datenfeldern beinhaltet sind, sind nur erläuternd für die Datenfelder, welche in der bereichsbasierten oder GTT-Datenbank 332 enthalten sind. Ähnliche Schlüsselfelder und Datenfelder werden für andere Netzwerkelemente gezeigt.
Mit Bezug auf 9a enthält die G-FLEX^TM- oder Ausnahmenbasierte Datenbank 330 Einträge, welche Ausnahmen zu den Einträgen in der bereichsbasierten Datenbank 332 darstellen. In 9a beinhaltet die Spalte auf der linken Seite Schlüsselwerte für jeden Eintrag, und die Spalte auf der rechten Seite beinhaltet Datenfelder für jeden Eintrag. Der erste Eintrag beinhaltet ein Schlüsselfeld von 9193803833. Die Datenfelder, welche dem ersten Schlüsselfeldwert entsprechen, beinhalten einen Punktcode (PC) von 3-0-3, eine Teilsystemnummer (SSN) von 6, einen Leitweglenk-Indikator (RI) von RT-ON-SSN, einen Replace Called party Global Title digits- bzw. Ersetze-die- Globaltitel-Digits-der-gerufenen-Partei-(RCGT-)Wert von NO und eine Entitätsadresse 303211234, welche HLR C darstellt. Diese Datenfelder dienen nur der Erläuterung des Datenfeldes, welches in der Ausnahme-basierten oder G-FLEX^TM-Datenbank 330 enthalten sein kann. Die verbleibenden Einträge in der Datenbank 330 enthalten ähnliche Daten für andere Netzwerkelemente.
Die duale Datenbankarchitektur, welche in dem flexiblen Leitweglenkknoten der vorliegenden Erfindung angewendet wird, liefert einen Anzahl von feinen Vorzügen für die Netzwerkvermittlung. Z. B. minimiert die Artigkeit der zwei Datenbanken optimal die Speicherquellenanforderungen für die Leitweglenk-Datenbank. Außerdem wird die Aufgabe des Beibehaltens und des Verwaltens des flexiblen Leitweglenkknotens stark vereinfacht, indem nur Ausnahmen für die herkömmlichen blockbasierten Leitweglenkregeln explizit in die G-FLEX^TM-Datenbank eingegeben werden müssen. Wenn dies nicht der Fall ist und z. B. eine spezielle Netzwerkvermittlung Daten hatte, welche mit 500.000 Mobil-Teilnehmern verbunden sind, welche in einen oder mehreren HLRs gespeichert sind, muss die Netzwerkvermittlung wenigstens eine einzigartige Leitweglenkaufzeichnung für jeden der 500.000 Teilnehmer erzeugen und speichern. Die Ausnahmenbasierte Struktur des flexiblen Leitweglenkknoten-Datenbanksystems erfordert einfach in einem derartigen Fall, dass die Vermittlung individuelle Leitweglenkaufzeichnungen in der G-FLEX^TM-Datenbank nur für jene IMSI- oder MSISDN-Nummern erzeugt und speichert, welche nicht zu den bereichs- oder blockbasierten Regeln gehören, welche in der GTT-Datenbank spezifiziert worden sind. Wenn z. B. eine Nummer von einem HLR zu einem anderen HLR portiert wurde, kann die MSISDN-Nummer eine Ausnahme für die blockbasierten Regeln in dem zweiten HLR darstellen. In dem speziellen Fall, wo alle IMSI- oder MSISDN-Nummern zu den blockbasierten Regeln, welche in der GTT-Datenbank spezifiziert sind, gehören, würde die G-FLEX^TM-Datenbank leer sein.
Beim anderen Extrem, wo alle IMSI- oder MSISDN-Nummern der Vermittlung nicht zu den allgemeinen blockbasierten Regeln gehören, welche in der GTT-Datenbank spezifiziert sind, würde die G-FLEX^TM-Datenbank wenigstens einen Eintrag für jede der der Vermittlung zugeordneten mobilen Identifikationsnummern enthalten.
Der flexible Leitweglenkknoten entsprechend der vorliegenden Erfindung erleichtert das Aufteilen der Last unter den HLRs. Wenn z. B. ein Service Provider ursprünglich zwei HLRs im Dienst stehen hat und nachfolgend einen dritten HLR zukauft, gestattet die G-FLEX^TM-Datenbank Nummern, welche den ursprünglichen HLRs zugeordnet sind, welche der neuen HLR zurückzugeordnet werden müssen.
Bezüglich der G-FLEX^TM- und GTT-Umsetzungsdienste sind die Parameter, welche entweder direkt oder indirekt benutzt werden, um die Art des Umsetzungsdienstes (z. B. G-FLEX^TM-Dienst oder GTT-Dienst) zu bestimmen, welche durch eine eingehende Signalisiernachricht gefordert sind, in den 10a–10c beinhaltet. Die Spalte auf der linken Seite in jeder der 10a–10c gibt die Parameter wieder, welche benutzt werden, um die Art des erforderlichen Umsetzdienstes zu bestimmen. In den dargestellten Figuren beinhalten diese Parameter im Allgemeinen einen Leitweglenk-Indikator (RI), einen Global Title Indicator (GTI)- bzw. Globalen-Titelindikator-(GTI-)Parameter, einen Translation Type (TT)- bzw. Umsetzungstyp-(TT-)Parameter, einen Numbering Plan (NP)- bzw. Nummernplan-(NP-)Parameter und einen Nature of Address Indicator (NAI)- bzw. Indikator-fürdie-Herkunft-der-Adresse-(NAI-)-Parameter. Diese Parameter, ihre Bedeutung innerhalb des Kontextes eines S57-Kommunikationsnetzwerkes und der Bereich ihrer Werte sind für Fachleute sehr wohl bekannt, und folglich werden sie hier nicht im Detail diskutiert. Es sollte genügen zu sagen, dass die bevor zugte Ausführungsform für den flexiblen Leitweglenkknoten der vorliegenden Erfindung auf einigen oder allen diesen Parametern beruht, um den erforderlichen Umsetzungsdienst zu bestimmen bzw. festzulegen.
Die mittlere Spalte in jeder der 10a–l0c gibt die ursprünglichen Werte wieder, d. h. vor der Umsetzung, für die Parameter, welche in jeder Spalte auf der linken Seite dargestellt werden. Die Spalte auf der rechten Seite in jeder der 10a–l0c stellt die Werte für jeden der Parameter in der Spalte auf der linken Seite nach der Umsetzung dar. Spezieller ausgedrückt, die Spalte auf der rechten Seite in 10a gibt die Parameterwerte nach einer G-FLEX^TM-Umsetzung wieder, welche mit Bezug auf 6 beschrieben wird. Die Spalte auf der rechten Seite der 10b gibt die Parameterwerte nach einer fehlerhaften Globaltitelumsetzung wieder, welche im Detail mit Bezug auf 7 beschrieben wird. Schließlich gibt die Spalte auf der rechten Seite der 10c die Parameterwerte nach einer dazwischen liegenden globalen Titelumsetzung wieder, welche im Detail mit Bezug auf 8 beschrieben wird.
Nachdem einmal die Anforderung an den allgemeinen Typ des Umsetzungsdienstes gemacht wurde (d. h. G-FLEX^TM-Umsetzung oder GTT-Umsetzung), wird als Nächstes der spezifische Typ des Umsetzungsdienstes festgelegt. Mit speziellem Bezug auf die G-FLEX^TM-Umsetzungsdienste können die Arten der Dienste, welche verfügbar sind, GSM-Dienste beinhalten, wie z. B. HLR, SMSC, EIR, AuC, etc. Die Festlegung des speziellen G-FLEX^TM-Umsetzungsdienstes wird während der Untersuchung eines Subsystem Number (SSN)- bzw. Teilsystemnummer-(SSN-)Parameters durchgeführt, welcher in dem Feld der Called Party Address (CdPA)bzw. Adresse der gerufenen Partei (CdPA) der Signalisiernachricht enthalten ist. Noch einmal, der SSN-Parameter ist Fachleuten wohl bekannt, und folglich wird er hier nicht im Detail diskutiert. Es sollte genügen zu sagen, dass der flexible Leitweglenkknoten der vorliegenden Erfindung so konfiguriert ist, dass er gewisse SSN-Werte als Anzeige für die Notwendigkeit eines speziellen Typs von G-FLEX^TM-Umsetzungsdienst erkennt.
Aus der Sicht des Betreibens werden die Signalisiernachrichten, welche eine Bearbeitung zum Leitweglenken der Datenbank benötigen, zuerst durch ausnahmenbasierte G-FLEX^TM-Datenbank bedient. D. h., ein Suchlauf wird innerhalb der G-FLEX^TM-Datenbank basierend entweder auf der IMSI- oder der MSISDN-Nummer durchgeführt, welche mit dem eingehenden Signalisiernachrichtenpaket verbunden ist. Im Falle, dass eine IMSI- oder MSISDN-Übereinstimmung in der G-FLEX^TM-Datenbank platziert ist, werden die geeigneten Leitweglenkdaten durch die G-FLEX^TM-Datenbank zurückgegeben, und das Signalisiernachrichtenpaket wird entsprechend vor dem weiteren Leitweglenken modifiziert. In einem solchen Fall ist kein zweiter Suchlauf der blockbasierten GTT-Datenbank notwendig. Im dem Fall, dass jedoch keine IMSI- oder MSISDN-Übereinstimmung in der G-FLEX^TM-Datenbank platziert ist, wird ein zweiter Suchlauf in der bereichsbasierten GTT-Datenbank durchgeführt.
G-FLEX^TM-Umsetzung
Die 6 und 7 stellen die zwei Leitweglenk-basierten Datenbanken-Zugriffsszenarien dar, welche oben kurz beschrieben wurden. Spezieller ausgedrückt, 6 gibt den Fall wieder, wo der Anfangssuchlauf der G-FLEX^TM-Datenbank eine IMSI- oder MSISDN-Übereinstimmung findet und deshalb keine zweite GTT-Datenbanksuche erforderlich ist. Um diesen Fall zu erläutern, wird der Pfad einer typischen, auf HLR basierenden SS7-Signalisiernachricht von dem GMSC 348 über den flexiblen Leitweglenkknoten 302 und schließlich zu dem Ziel HLR C 356 ver folgt, wobei der Pfad durch eine gestrichelte Linie in 6 angezeigt wird. Zum Dienste der Erläuterung wurde jedem dieser Netzwerkknoten eine SS7-Netzwerkadresse oder ein Punktcode (PC) zugeordnet. In beiden 6 und 7 wird der GMSC-Knoten 348 durch den PC 1-0-0 identifiziert, der flexible Leitweglenkknoten 302 wird durch PC 2-0-0 identifiziert, während die drei HLR-Knoten 352, 354 und 356 durch jeweils die PCs 3-0-1, 3-0-2 bzw. 3-0-2 identifiziert werden.
Beginnt man am GMSC-Knoten 348, so wird eine Signalisiernachricht formuliert und zu dem flexiblen Leitweglenkknoten 302 über die SS7-Kommunikationsverbindung 320 übertragen. Der relevante Dateninhalt dieser entstehenden Signalisiernachricht wird in 10a gezeigt. Wenn dem so ist, so wird aus der Tabelle, welche in 10a gegeben wird, anerkannt werden, dass das OPC der Originalnachricht gleich 1-0-0 ist, der PC des GMSC-Knotens 348. Der DPC der Nachricht ist 2-0-0, der PC des flexiblen Leitweglenkknotens 302. Die Signalisiernachricht wird innerhalb des flexiblen Leitweglenkknotens 302 durch das LIM 308 empfangen. Das Bearbeiten des SS7-MTP-Pegels 1 und 2 wird an dem eingehenden Signalisiernachrichtenpaket durch den MTP-Pegel-1-und-2-Prozess 310 durchgeführt. Wenn die Verarbeitung mit dem MTP-Pegel 1 und 2 vollendet ist, wird das Signalisiernachrichtenpaket zeitweise in der E/A-Warteschlange 312 gepuffert, bevor es zu dem Stapel des MTP-Pegel-3-HMDC-Prozess 314 durchgelassen wird. Der HMDC-Prozess 314 untersucht das Signalisiernachrichtenpaket und bestimmt, ob das Paket weitere Verarbeitung an dem flexiblen Leitweglenkknoten 302 benötigt. In dem Beispiel, welches in 6 gezeigt wird, wird angenommen, dass der HMDC-Prozess 314 bestimmt, dass weitere Verarbeitung des Signalisiernachrichtenpakets erforderlich ist, und das Paket wird nachfolgend an den HMDT-Prozess 316 durchgelassen. Der HMDT-Prozess 316 untersucht das Paket und legt fest, basierend auf der Art des weiteren Verarbeitens, welches erforderlich ist, welches dezentrale Datenverarbeitungsmodul, welches mit dem IMT-Bus 304 verbunden ist, als Nächstes das Paket empfangen sollte. In diesem Fall bestimmt der HMDT-Prozess 316, dass die Signalisiernachricht an das GDM-Modul 322 für den G-FLEX^TM-Umsetzungsdienst weitergeleitet werden sollte. Das Signalisiernachrichtenpaket wird dann auf dem Hochgeschwindigkeits-IMT-Bus 304 platziert und an den GDM 322 gesendet. Ein detailliertes Flussdiagramm der auf GDM/SCCP bezogenen Verarbeitungsschritte wird in 11 dargestellt und kann in Verbindung mit dem schematischen Diagramm, welches in 6 gezeigt wird, benutzt werden, um besser die Methodik des Suchlaufes in der G-FLEX^TM- und GTT-Datenbank zu verstehen. Außerdem liefert 10a eine Summe des Inhalts des Signalisiernachrichtenpaketes vor und nach der G-FLEX^TM-Umsetzung.
Mit Bezug auf 11 erreicht die Signalisiernachricht im Schritt ST1 die GSM-Karte 322, und der SCCP-Prozess 326 empfängt das Paket. Innerhalb des SCCP-Prozesses 326 wird das Nachrichtenpaket an den SCRC-Kontrollgerät-Prozess 328 durchgelassen. In den Schritten ST2 und ST3 decodiert und untersucht der SCRC-Prozess 328 die Paketinhaltsinformation, welche in der Überschrift der Signalisiernachricht enthalten ist, um aufzustellen, welche Art von Umsetzungsdienst erforderlich ist. Spezieller ausgedrückt, die RI-, GTI-, TT-, NP- und NAI-Parameter, welche in dem Signalisiernachrichtenpaket enthalten sind, werden analysiert, um zu bestimmen, ob ein G-FLEX^TM- oder ein GTT-Umsetzungsdienst erforderlich ist. Wie in den Schritten ST4 und ST5 angezeigt, wird die Nachricht, wenn bestimmt wird, dass ein GTT-Umsetzungsdienst erforderlich ist, direkt an den GTT-Datenbankprozess 332 durchgelassen. In dem Szenario, welches in 6 dargestellt wird, wird jedoch ein RI-Wert von "RT-ON-GT", ein GTI-Wert von 4, ein Umsetzungstyp(TT)-Wert von 0, ein "nationaler" NAI-Wert und ein "E.164"-NP-Wert kollektiv so interpretiert, dass er die Notwendigkeit für eine G-FLEX^TM-Umsetzung anzeigt. Der Inhalt der Signalisier nachricht wird dann weiter analysiert, um die spezielle Art des G-FLEX^TM-Umsetzungsdienstes, welcher erforderlich ist, zu bestimmen, wie dies durch Schritt ST6 angezeigt wird. Spezieller ausgedrückt, der CdPA SSN-Parameter wird untersucht, und der Wert von 6 wird als Anzeichen für die Notwendigkeit einer Umsetzung nach dem G-FLEX^TM-HLR-Typ interpretiert. In diesem speziellen Beispiel, falls der Entitätstyps des Bestimmungsknotens so festgelegt wird, alles andere als HLR oder SMSC zu sein (d. h. SSN ist nicht gleich 6 oder 8), wird das Paket an den GTT-Datenbankprozess 332 durchgelassen, wie dies in den Schritten ST7 und ST5 jeweils gezeigt wird. Im Schritt ST8 wird die Mobil-Identifikationsnummer (MIN), welche innerhalb des Paketes codiert ist, nachfolgend untersucht und konditioniert, wenn dies notwendig ist. Die MIN wird typischerweise innerhalb des CdPA-Feldes in einer Struktur gespeichert, welche allgemein als Global Title Digits (GTD)- bzw. Globale-Titeldigitalwerte-Teilfeld bezeichnet wird. In einigen Fällen kann es notwendig sein, die MIN aus der TCAP/MAP-Information in der Nachricht abzuleiten. In diesem Beispiel hat die MIN oder das GTD einen Wert von 9193803833, wie dies in 10a gezeigt wird, und es wird ferner angenommen, dass keine Konditionierung dieser Nummer erforderlich ist.
Jedoch, mit Bezug auf das oben erwähnte Nummernkonditionieren, kann ein derartiges Verarbeiten notwendig sein, um sicherzustellen, dass die IMSI oder MSISDN mit dem Format der Schlüsselfelddaten kompatibel ist, welche in den G-FLEX^TM- und GTT-Datenbanken 330 bzw. 332 gespeichert sind. Die Arbeitsschritte des Nummernkonditionierens können das Voranhängen von Extra-Digits bzw. -Digitalwerten an eine Mobil-Identifikationsnummer beinhalten, welche innerhalb eines Signalisiernachrichtenpaketes enthalten ist, um so zu erzwingen, dass die Nummer mit einem internationalen Format übereinstimmt. Das Wandeln einer Mobil-Identifikationsnummer von einem Nummernstandard zu einem anderen kann auch durchgeführt werden. Z. B. kann die Mobil-Identifikationsnummer, welche mit einem eingehenden Signalisiernachrichtenpaket verbunden ist, von einem ersten Industriestandardformat, welches als E.214 bekannt ist, in ein zweites Industriestandardformat, welches als E.212 bekannt ist, vor den Datenbank-Suchlaufverarbeitungsschritten gewandelt werden. Noch einmal, es sollte anerkannt werden, dass solche Konditionierdienste der Mobil-Identifikationsnummer nur in dem Fall notwendig sind, in dem das Format der eingehenden Mobil-Identifikationsnummer der Nachricht nicht mit dem entsprechenden Schlüsselfeld-Datenformat in den G-FLEX^TM- und GTT-Datenbanken in Einklang ist.
Im Schritt ST9 wird die G-FLEX^TM-Datenbank 330 durchsucht, wobei die entsprechende Mobil-Identifikationsnummer (IMSI oder MSISDN) als wenigstens ein Teil des Suchschlüssels genutzt wird. Wenn keine Übereinstimmung in der G-FLEX^TM-Datenbank 330 gefunden wird, wird das Paket an die GTT-Datenbank 332 zum Bearbeiten durchgelassen, wie dies in den Schritten ST10 und ST11 jeweils gezeigt wird. In dem Beispiel, welches in 6 gezeigt wird, wird jedoch eine Übereinstimmung in der G-FLEX^TM-Datenbank 330 gefunden, wie dies durch die Tatsache angezeigt wird, dass es einen Eintrag in der G-FLEX^TM-Datenbank 330 gibt (9a), entsprechend dem CdPA SSN-Wert der Nachricht von 9193803833. Die Leitweglenkdaten, welche durch den G-FLEX^TM-Datenbankprozess 330 zurückgegeben werden, werden nachfolgend durch einen Punktcodewert von 3-0-3 und einer Teilsystemnummer von 6 innerhalb des Signalisiernachrichtenpaketes codiert, wie dies durch den Schritt ST12 angezeigt wird. Es wird anerkannt werden, dass die Leitweglenkinformation PC:3-0-3 SSN:6, welche durch die G-FLEX^TM-Datenbank zurückgegeben wird, effektiv die Netzwerkadresse des HLR C 356 darstellt. Es sollte auch anerkannt werden, dass das Feld des Leitweglenk-Indikators (RI) der umgesetzten Signalisiernachricht vom ursprünglichen "Rou te-On-GT"- bzw. "Pfad-auf-GT"-Wert auf einen neuen Wert von "Route-On-SSN" bzw. "Pfad-auf-SSN" modifiziert wurde, wodurch angezeigt wird, dass keine weiteren Leitweglenk-Adressenumsetzungen erforderlich sind, um die Netzwerkadresse des Ziel-HLR-Knotens zu identifizieren. Noch einmal, der Leitweglenk-Indikationsparameter ist für Fachleute der SS7-Telekommunikation wohl bekannt, und folglich wird hier eine detaillierte Diskussion dieses Parameters und seiner Leitweglenkfunktionalität nicht wiedergegeben. Es wird jedoch anerkannt werden, dass dieser Parameter benutzt wird, um allgemein anzuzeigen, ob ein Signalisiernachrichtenpaket eine Verarbeitung nach dem SSCP-Typ erfordert. Es sollte auch beachtet werden, dass in 9a zwei der gespeicherten Datenfelder in diesem Fall nicht benutzt werden. Es wird ein Entitäts-Adressenfeld benutzt, um eine andere, typischerweise eine MSISDN- oder IMSI-formatierte Nummer zu speichern, welche repräsentativ für einen speziellen HLR- oder SMSC-Knoten ist. Ein Feld von Replace Called party Global Title digits (RCGT) bzw. Ersetze-die-Globaltitel-Digits der gerufenen Partei beinhaltet ein Kennzeichen, welches anzeigt, ob der Wert in dem CdPA:GTD-Feld der Signalisiernachricht geändert werden sollte, um die Entitätsadresse des Ziel-HLR-Knotens wiederzugeben. In diesem Fall wird anerkannt werden, dass das RCGT-Kennzeichen auf einen Wert von "NO" gesetzt wird, welcher anzeigt, dass das CdPA:GTD-Feld der Signalisiernachricht nicht geändert werden muss, um die Entitätsadresse des HLR C wiederzugeben. Dies ist typischerweise der Fall, wenn der Punktcode und die Teilsysteminformation, welche mit der Netzwerkadresse eines Zielknotens übereinstimmen, bereits dem flexiblen Leitweglenkknoten bekannt sind. Wenn jedoch der flexible Leitweglenkknoten nicht mit wenigstens dem Punktcode versehen wurde, welcher mit dem Ziel-HLR-Knoten übereinstimmt, dann wird eine Entitäts-Adressensubstitution angewendet, um die nachfolgenden Leitweglenk-Adressenumsetzungen durch einen externen Leitweglenkknoten zu erleichtern. Ein Beispiel eines derartigen Szenarios wird nachfolgend gegeben.
Kehrt man nun zu 6 zurück, so wird anerkannt werden, dass, nachfolgend auf den erfolgreichen G-FLEX^TM-Datenbanksuchlauf, wie er oben im Detail beschrieben wurde, das modifizierte Signalisiernachrichtenpaket als Nächstes an den HMRT-Prozess 334 durchgelassen wird. Noch einmal, der HMRT-Prozess 334 bestimmt, an welche LIM- oder DCM-Karte das Paket für das nachfolgende Übertragen an den Zielknoten der Nachricht geleitet werden sollte. In diesem Fall bestimmt der HMRT-Prozess 334, dass die Verbindung, welche den flexiblen Leitweglenkknoten 302 mit dem modifizierten Zielknoten der Nachricht verbindet, auf dem DCM 336 platziert ist. Folglich wird das modifizierte Signalisiernachrichtenpaket intern über den IMT-Bus 304 an den DCM 336 leitweggelenkt, wo es durch den HMCG-Prozess 340 empfangen wird. Der HMCG-Prozess 340 lässt das modifizierte Nachrichtenpaket in die E/A-Warteschlange 341 durch, wobei dieser nach außen gerichtete Anteil des Paketes für den Stau der Verbindung erkannt wird. Schließlich wird das modifizierte Nachrichtenpaket von der E/A-Warteschlange 341 durchgelassen und zum IP-Prozess 342 gelassen, wo das SS7-Paket in einen IP-Leitweg-Envelope bzw. -Bitgruppe eingekapselt wird. Das IPgekapselte SS7-Paket wird dann zu dem verbundenen IP-Netzwerk 350 über die IP-Signalisierverbindung 344 übertragen. In diesem Beispiel wird das IP-gekapselte SS7-Paket adressiert und folglich durch das IP-Netzwerk 350 zum Endziel HLR C 356 leitweggelenkt. Der OPC des Paketes wird in den OPC des flexiblen Leitweglenkknotens 302 verändert.
Fehler in der GTT-Umsetzung
Wendet man sich der 7 zu, so erläutert das beispielhafte Flussszenario, welches in diesem Diagramm dargestellt wird, den Fall, bei welchem ein erster G-FLEX^TM-Datenbanksuchlauf fehlschlägt, um eine IMSI- oder MSISDN-Übereinstimmung zu finden, und deshalb ist ein zweiter oder Fehler-GTT-Datenbank suchlauf erforderlich. Der Pfad einer typischen HLR-gebundenen SS7-Signalisiernachricht wird vom GMSC 348 über den flexiblen Leitweglenkknoten 302 und schließlich zum Ziel-HLR B 354 verfolgt. Noch einmal, der Signalisiernachrichtenpfad wird durch eine gestrichelte Linie angezeigt. Beginnt man mit dem GMSC-Knoten 348, wird eine Signalisiernachricht formuliert und an den flexiblen Leitweglenkknoten 302 über die SS7-Kommunikationsverbindung 320 übertragen. Der relevante Dateninhalt dieser entstehenden Signalisiernachricht wird in 10b gezeigt. Dementsprechend wird aus der Tabelle, welche in 10b dargestellt wird, erkannt werden, dass der OPC der Originalnachricht gleich 1-0-0 ist, der PC des GMSC-Knotens 348. Der DPC der Nachricht ist 2-0-0, der PC des flexiblen Leitweglenkknotens 302.
Da das Verarbeiten des eingehenden Signalisiernachrichtenpaketes auf dem LIM 308 in diesem Szenario identisch ist mit dem, wie es für das Szenario, welches in 6 dargestellt wird, ist und oben beschrieben wurde, wird eine detaillierte Diskussion der LIM-Verarbeitung nicht wiederholt. Stattdessen wird anerkannt werden, dass die eingehende Signalisiernachricht innerhalb des flexiblen Leitweglenkknotens 302 durch das LIM 308 empfangen wird und dass das Nachrichtenpaket nachfolgend untersucht wird und über den IMT-Bus 304 an die GDM-Karte 322 für das weitere Verarbeiten weitergelenkt wird.
Das detaillierte Flussdiagramm der GDM/SCCP-bezogenen Verarbeitungsschritte, welche in 11 präsentiert werden, kann in Verbindung mit dem schematischen Diagramm, welches in 7 gezeigt wird, benutzt werden, um besser die Methodik des Suchlaufes in der G-FLEX^TM- und GTT-Datenbank zu verstehen. Außerdem liefert 10b eine Zusammenstellung des Inhalts des Signalisiernachrichtenpaketes vor und nach der G-FLEX^TM-Umsetzung. Mit Bezug auf 11 erreicht die Signalisiernachricht im Schritt ST1 die GDM-Karte 322, und der SCCP-Prozess 326 empfängt das Paket. Innerhalb des SCCP-Prozesses 326 wird das Nachrichtenpaket an den SCRC-Steuergerätprozess 328 durchgelassen. In den Schritten ST2 bzw. ST3 decodiert und untersucht der SCRC-Prozess 328 die Information des Paketinhalts, welche in der Signalisiernachrichtüberschrift enthalten ist, um festzulegen, welche Art von Umsetzungsdienst erforderlich ist. Spezieller ausgedrückt, die RI-, GTI-, TT-, NP- und NAI-Parameter, welche in dem Signalisiernachrichtenpaket enthalten sind, werden analysiert, um zu bestimmen, ob ein G-FLEX^TM- oder ein GTT-Umsetzungsdienst erforderlich ist. Wiederum, wie in dem vorausgehenden Beispiel, werden ein RI-Wert von "RT-ON-GT", ein GTI-Wert von 4, ein TT-Wert von 0, ein "National"-NAI-Wert und ein "E.164"-NP-Wert kollektiv interpretiert, dass er die Notwendigkeit für eine G-FLEX^TM-Umsetzung anzeigt. Der Inhalt der Signalisiernachricht wird dann weiter analysiert, um die spezielle Art des G-FLEX^TM-Umsetzungsdienstes, welcher erforderlich ist, zu bestimmen, wie dies durch Schritt ST6 angezeigt wird. Spezieller ausgedrückt, der CdPA-SSN-Parameter wird untersucht, und der Wert von 6 wird so interpretiert, dass er die Notwendigkeit für eine G-FLEX^TM-HLR-Art-Umsetzung anzeigt. Im Schritt ST8 wird die Mobil-Identifikationsnummer (MIN), welche innerhalb des Paketes codiert ist, nachfolgend untersucht und konditioniert, wenn dies notwendig ist. In diesem Beispiel beträgt der Wert des MIN oder GTD 7707883438, wie dies in 10b gezeigt wird, und es wird ferner angenommen, dass kein Konditionieren dieser Nummer erforderlich ist.
Im Schritt ST9 wird die G-FLEX^TM-Datenbank 330 durchsucht, wobei die geeignete Mobil-Identifikationsnummer (IMSI oder MSISDN) als wenigstens ein Teil des Suchschlüssels benutzt wird. In diesem Fall wird eine Übereinstimmung in der G-FLEX^TM-Datenbank 330 nicht gefunden, und das Paket wird an die GTT-Datenbank 332 zur weiteren Verarbeitung durchgelassen, wie dies in Schritt ST10 gezeigt wird. Es wird anerkannt werden, dass dieses GTT-Fehlerverarbeiten durch die Tatsache angezeigt wird, dass kein Eintrag in der G-FLEX^TM-Datenbank 330 (9a) vorhanden ist, welcher mit dem CdPA-SSN-Wert von 7707883438 übereinstimmt. Folglich wird im Schritt ST10 die GTT-Datenbank 332 durchsucht, wobei die Mobil-Identifikationsnummer 7707883438 als wenigstens ein Teil des Suchschlüssels genutzt wird. Wie in 9b angezeigt wird, wird in der GTT-Datenbank 332 ein MIN-Bereich definiert, welcher die gesuchte MIN begrenzt, 7707883438. Die Leitweglenkdaten, welche durch den GTT-Datenbankprozess 332 zurückgegeben werden, ein Punktcodewert von 3-0-2 und eine Teilsystemnummer von 6 werden nachfolgend innerhalb des Signalisiernachrichtenpaketes codiert, wie dies in dem Schritt ST12 angezeigt wird. Es wird anerkannt werden, dass die Leitweglenkinformation, PC:3-0-2 SSn:6, welche von der GTT-Datenbank 332 zurückgegeben wird, effektiv die Netzwerkadresse von HLR B 354 darstellt. Es sollte auch anerkannt werden, dass das Feld des Leitweglenk-Indikators (RI) der Signalisiernachricht von dem Originalwert "Route-On-GT" auf einen neuen Wert von "Route-On-SSN" modifiziert wurde.
Kehrt man nun zu 7 zurück, so wird anerkannt werden, dass im Anschluss an die nicht erfolgreiche G-FLEX^TM- und erfolgreiche GTT-Datenbank-Suchlauffolge, wie sie im Detail oben beschrieben wurden, das modifizierte Signalisiernachrichtenpaket als Nächstes an den HMRT-Prozess 334 durchgelassen wird. Noch einmal, der HMRT-Prozess 334 bestimmt, an welche LIM- oder DCM-Karte das Paket zur nachfolgenden Übersendung an den Zielknoten der Nachricht weitergeleitet werden sollte. In diesem Fall bestimmt der HMRT-Prozess 334, dass die Verbindung, welche den flexiblen Leitweglenkknoten 302 und den modifizierten Zielknoten der Nachricht verbindet, auf dem DCM 336 platziert ist. Folglich wird das modifizierte Signalisiernachrichtenpaket intern über den IMT-Bus 304 an das DCM 336 leitweggelenkt, wo es durch den HMCG-Prozess 340 empfangen wird. Der HMCG-Prozess 340 lässt das modifizierte Nachrichtenpaket zu der E/A-Warteschlange 341 durch, wobei er den Anteil dieses nach außen gerichteten Pakets zum Stau der Verbindung erkennt. Schließlich wird das modifizierte Nachrichtenpaket von der E/A-Warteschlange 341 durchgelassen und weiter zum IP-Prozess 342 geleitet, wo das SS7-Paket innerhalb einer IPfehlergeschützten Leitweglenk-Envelope bzw. -Bitgruppe eingekapselt wird. Die Ziel-IP-Adresse in der fehlergeschützten Leitweglenk-Bitgruppe kann durch den Datensuchlauf in dem DCM für die IP-Adresse, welche dem Punktcode 3-0-2 entspricht, bestimmt werden. Das IP-eingekapselte SS7-Paket wird dann an das angeschlossene IP-Netzwerk 350 über die IP-Signalisierverbindung 344 übertragen. In diesem Beispiel ist das IP-gekapselte SS7-Paket über das IP-Netzwerk 350 adressiert und folglich wird es zum Endzielpunkt HLR B 354 leitweggelenkt.
Wie oben festgestellt, kann das IP-Netzwerk 350, welches in 7 dargestellt wird, durch ein SS7-Netzwerk ersetzt werden, ohne vom Umfang der Erfindung abzuweichen. In einem derartigen Szenario kann das DCM 336 durch ein zweites LIM zum Leitweglenken der ausgehenden SS7-Nachrichten über ein SS7-Netzwerk ersetzt werden. In einem Verfahren zum Leitweglenken einer Signalisiernachricht entsprechend einer derartigen Ausführungsform sind die Schritte zum Leitweglenken der Signalisiernachricht die gleichen, wie sie oben vor der Verteilung der Nachricht an das DCM 336 beschrieben wurden, wie oben beschrieben. Wenn jedoch das DCM 336 durch ein LIN ersetzt wurde, im Gegensatz zum Einkapseln der Signalisiernachricht in ein IP-Paket, wird die Signalisiernachricht einfach zum HLR B 354 leitweggelenkt, entsprechend dem Zielpunktcode der Nachricht. Die ausgehende Signalisiernachricht hat einen OPC gleich dem Punktcode des flexiblen Leitweglenkknotens 302 und einen DPC gleich dem Punktcode des HLR B 354. Da der OPC der Signalisiernachricht auf den Punktcode des flexiblen Leitweglenkknotens 302 geändert wurde, im Gegensatz zu dem des GMSC 348, bleibt eine Erfüllung der Zuverlässigkeitskriterien des SS7-Netzwerks erhalten.
Zwischenumsetzung
Ein anderes Beispiel, welches in 8 präsentiert wird, dient dazu, eine andere Netzwerkimplementierung zu erläutern, in welcher es für einen flexiblen Leitweglenkknoten der vorliegenden Erfindung möglich ist, eine dazwischen liegende Leitweglenkumsetzung bzw. Zwischenumsetzung zu liefern. Bei dieser Implementierung beinhaltet das Signalisiernetzwerk 400 einen flexiblen Leitweglenkknoten 402, welcher im Wesentlichen in seiner Form und Funktion identisch mit dem flexiblen Leitweglenkknoten 302 ist, welcher oben beschrieben wurde und im Allgemeinen in den 6 und 7 dargestellt wird. Der flexible Leitweglenkknoten 402 ist an das GMSC 348 und die drei HLR-Knoten 352, 354 und 356 über wenigstens einen Zwischen-STP 404 gekoppelt. Die Kommunikationsverbindung 406 zwischen dem flexiblen Leitweglenkknoten 402 und STP 404 ist eine SS7-Verbindung, obwohl andere Kommunikationsprotokolle, wie z. B. IP, auch angewendet werden können.
In diesem Szenario wird der Pfad einer typischen HLR-gebundenen SS7-Signalisiernachricht von dem GMSC 348 über den flexiblen Leitweglenkknoten 402 und schließlich zum Zieulknoten HLR A 352 verfolgt. Noch einmal, der Signalisiernachrichtenpfad wird durch eine gestrichelte Linie angezeigt. Der relevante Dateninhalt dieser Signalisiernachricht, wie sie zuerst empfangen wird und dann durch den flexiblen Leitweglenkknoten 402 umgesetzt wird, wird in 10c gezeigt. Beginnt man an dem GMSC-Knoten 348, wird eine Signalisiernachricht mit einem CdPA:GTD-Wert von 2125662322 formuliert und an den dazwischen liegenden STP 404 übertragen. Der STP 404 empfängt und leitweglenkt die Signalisiernachricht an den flexiblen Leitweglenkknoten 402 über die Kommunikationsverbindung 406. Obwohl in 10c nicht gezeigt, wird anerkannt werden, dass der OPC der Originalnachricht gleich 1-0-0 ist, der PC des GMSC-Knotens 348, während der DPC der Originalnachricht gleich 4-0-0 ist, der PC des STP 404. Beim Prozess des Leitweglenkens des Nachrichtenpaketes modifiziert der STP 404 den OPC auf 4-0-0 und den DPC auf 2-0-0. Die Nachricht wird dann durch STP 404 an den flexiblen Leitweglenkknoten 402 übertragen, welchem der Punktcode 2-0-0 zugeordnet ist. Sobald die Signalisiernachricht durch den flexiblen Leitweglenkknoten 402 empfangen wird, ist das Verarbeiten der Nachricht im Wesentlichen das gleiche wie das für die vorher beschriebenen Beispiele.
Der einzige signifikante Unterschied in diesem Fall ist der, dass die Leitweglenkdaten, welche durch den Suchlauf der G-FLEX^TM-Datenbank zurückgegeben werden, nicht der Punktcode und die SSN des Ziel-HLR A-Knotens 352 sind, sondern stattdessen die Entitätsadresse, welche mit dem HLR A 352 und dem Punktcode von STP 404 verbunden ist. Spezieller ausgedrückt, ein Wert Replace Called party Global Title digits (RCGT) bzw. Ersetze die Globaltitel-Digits der gerufenen Partei von "YES" bzw. "JA" wird durch die G-FLEX^TM-Datenbank zurückgegeben, wie dies in 9a angezeigt wird, zusammen mit einer HLR A-Entitätsadresse mit dem Wert 1013211234. Folglich wird der ursprüngliche Wert des CdPA:GTD-Feldes der Signalisiernachricht, 2125662322, durch die HLR A-Entitätsadresse mit dem Wert 1013211234 ersetzt.
Eine zweite Schlüsselunterscheidung von den Szenarien des vorausgehenden Beispiels besteht darin, dass der CdPA-Leitweglenk-Indikator für die umgesetzte Nachricht auf "RT-ON-GT" anstatt auf "RT-ON-SSN" gesetzt wird, wodurch angezeigt wird, dass wenigstens eine weitere Leitweglenk-Adressumsetzung notwendig sein wird, um die aktuelle Netzwerkadresse des Ziel-HLR-Knotens zu bestimmen.
Diejenigen Fachleute, welche mit SS7-Leitweglenksystemen vertraut sind, werden anerkennen, dass eine derartige Umsetzung sehr ähnlich sowohl in Form als auch Funktion zu einer dazwischen liegenden bzw. Zwischen-Global-Titelumsetzung ist. Demzufolge ist beinhaltet, dass die G-FLEX^TM- und die GTT-Datenbanken, welche innerhalb des flexiblen Leitweglenkknotens 402 enthalten sind, nicht die Information besitzen, welche notwendig ist, um die aktuelle Netzwerkadresse des Zielknotens zu besitzen. Jedoch ist die G-FLEX^TM-Datenbank mit Information bestückt, welche sich auf den nächsten Netzwerk-Leitweglenkknoten bezieht, welcher die aktuelle Netzwerkadresse des Zielknotens besitzen könnte. Wie dies in den 8, 9a und 10c angezeigt wird, zeigt das Ergebnis des G-FLEX^TM-Datenbanksuchlaufes an, dass das Signalisiernachrichtenpaket als Nächstes zu STP 404 bei PC:4-0-0 weitergelenkt werden sollte. Außerdem wird der Leitweglenk-Indikator der umgesetzten Nachricht auf den Wert von "RT-ON-GT" gesetzt, wodurch angezeigt wird, dass eine abschließende Leitweglenkumsetzung nach wie vor erforderlich ist, bevor das Nachrichtenpaket sein Ziel erreichen kann. In diesem Beispiel wird angenommen, dass STP 404 so konfiguriert ist, dass es eine erfolgreiche End-GTT an dem Nachrichtenpaket durchführen kann, wobei die Entitätsadresse des HLR A genutzt wird, welche in dem CdPA:GTD-Feld der Signalisiernachricht gespeichert wurde. Auf diese End-GTT-Umsetzung bei STP 404 folgend wird der DPC des Nachrichtenpaketes auf 3-0-1:6 verändert, und die Nachricht wird nachfolgend an das Netzwerkelement, welches diesem PC und der SSN entspricht, nämlich HLR A 352, übertragen. Der OPC der Nachricht wird auf 4-0-0 geändert, d. h. den OPC des STP 404.
Wie bereits vorher beleuchtet, ein wesentlicher Unterschied, welchen der flexible Leitweglenkknoten der vorliegenden Erfindung gegenüber Lösungen entsprechend dem Stand der Technik hat, beinhaltet die Art, in welcher das OPC-Feld des SS7-MTP- Leitweglenk-Labels bzw. der -Adresse während des G-FLEX^TM- oder GTT-Umsetzungsprozesses geändert wird. Spezieller ausgedrückt, als Teil der G-FLEX^TM- und GTT-Verarbeitung wird der OPC der umgesetzten Signalisiernachricht modifiziert, um den Punktcode des flexiblen Leitweglenkknotens zu reflektieren. Dieser Unterschied ist signifikant dadurch, dass er zu dem Industriestandard SS7-Niveau 3 befähigt und darüber hinaus zu Netzwerksteuerprotokollen, um in Erfüllung mit den akzeptierten SS7-Telekommunikationsstandards zu arbeiten, wie sie durch ANSI, ITU, Telcordia u. a. definiert werden.
Leitweglenken einer SMS-Nachricht
Wie oben festgestellt, ist ein Problem bei herkömmlichen Mobilkommunikationsnetzwerken das Zuordnen existierender Mobilteilnehmer zu SMSCs, wenn neue SMSCs dem Netzwerk zugefügt werden. Dieses Problem stammt von der Tatsache, dass die Entitätsadresse für SMSC entweder in die Handgeräte der Teilnehmer fest codiert oder programmiert ist. Wenn neue SMSCs hinzugefügt werden, müssen entweder die Handgeräte der Teilnehmer neu programmiert werden oder ein anderes SS7-Nachricht-Leitweglenkschema implementiert werden. Der flexible Leitweglenkknoten entsprechend einer Ausführungsform der vorliegenden Erfindung beinhaltet die Funktionalität zum Leitweglenken von Nachrichten an ein spezielles SMSC in einem Netzwerk, welches viele SMSCs beinhaltet, ohne dass ein erneutes Programmieren der mobilen Handgeräte notwendig ist.
12 ist ein Netzwerkdiagramm, welches ein Netzwerk darstellt, welches viele SMSCs beinhaltet. Mit Bezug auf 12 beinhaltet das Netzwerk 500 flexible Leitweglenkknoten 403, MSC 502, IWMSC 504, SMSC A 506 und SMSC B 508. Der flexible Leitweglenkknoten 402 beinhaltet Ausnahme- und bereichsbasierte Datenbanken, wie in den 9a bzw. 9b dargestellt. Ungleich jedoch zu den Beispielen, welche oben beschrieben wur den, welche sich in erster Linie auf Leitweglenknachrichten an HLRs beziehen, wird nun ein Beispiel beschrieben, bei welchem der flexible Leitweglenkknoten 402 Nachrichten an die SMSCs 506 und 508 weiterlenkt.
Wenn ein Nutzer wünscht, eine Kurznachricht an einen anderen Nutzer zu senden, sendet das Mobilhandgerät 128 die Daten und die Mobil-Identifikationsnummer des beabsichtigten Empfängers an das MSC 502. Das MSC 502 empfängt die Daten von dem Handgerät und sendet eine Kurznachrichten-Dienstnachricht an den flexiblen Leitweglenkknoten 402. Die Kurznachricht-Dienstnachricht beinhaltet einen Teil eines mobilen Applikationsteils (MAP), welcher die Mobil-Identifikationsnummer des herausgebenden bzw. ursprünglichen Handgerätes 128 beinhaltet. Die Kurznachricht-Dienstnachrichten können auch die Entitätsadresse des SMSC beinhalten, welche ursprünglich im Handgerät 128 programmiert wurde. Anstatt jedoch diese Entitätsadresse zu nutzen, welche im SCCP-Teil der Nachricht gespeichert ist, nutzt der flexible Leitweglenkknoten 402 die MIN in dem Teil der MAP der Nachricht, um zu entscheiden, ob die Nachricht an SMSC A 506 oder SMSC B 508 leitwegzulenken ist. Wenn der flexible Leitweglenkknoten 402 die Kurznachricht-Dienstnachricht von MSC 502 empfängt, wird die Nachricht als eine SCCP-Nachricht identifiziert, welche die G-FLEX-Verarbeitung in der oben beschriebenen Weise notwendig hat, d. h. basierend auf dem Dienstauswähler, dem Umsetzungstyp bzw. der Umsetzungsart, dem Nummernplan und der Natur der Adressindikator-Parameter in der Nachricht. Zusätzlich zu diesen Parametern wird der Teilsystem-Nummernparameter untersucht, um den Entitätstyp des Knotens zu bestimmen, an welchen die Nachricht leitweggelenkt werden sollte. Dieses Umsetzen vom SSN- zum Entitätstyp kann durch den SCRC-Prozess 328 ausgeführt werden, wobei eine Entitäts-Typ-Tabelle benutzt wird, welche auf dem GDM 322, welche in 7 dargestellt wird, vorgesehen ist. Ein Beispiel einer derartigen Entitätstyp-Tabelle sieht wie folgt aus:

Teilsystemnummer Entitätstyp

6 HLR

8 SMSC

Tabelle 1 Umsetzung von SSN in den Entitätstyp
Mit Bezug auf 9a, wenn die Nachricht identifiziert ist, dass sie einen Entitätstyp von SMSC hat, wird ein Suchlauf in der Ausnahme-basierten Datenbank 330 durchgeführt, wobei die MIN von dem MAP-Teil der Nachricht benutzt wird. In 9a ist, wenn die MIN in dem MAP-Teil der Nachricht 4143286672 ist, die Ziel-Entitäts-Adresse der Nachricht 4146773497, welche dem SMSC B 508 entspricht. Der flexible Leitweglenkknoten 402 fügt die Entitätsadresse von SMSC B 508 in das Adressfeld der gerufenen Partei der Nachricht ein, fügt den Punktcode 6-0-1 in das DPC-Feld in den MTP-Teil der Nachricht ein und 1eitweglenkt die Nachricht an IWMSC 504, wie dies in 12 dargestellt wird. IWMSC 504 leitweglenkt die Nachricht an SMSC B 508. SMSC B 508 empfängt die Kurznachrichten-Dienstnachricht und sendet eine Kurznachrichtdienst-Nachricht an das Ziel-Mobilhandgerät.
Wenn der Suchlauf in der Ausnahme-basierten Datenbank 330 durch Nutzen der MIN von dem MAP-Teil der Nachricht fehlschlägt, erscheint ein Suchlauf in der bereichsbasierten Datenbank 332, wobei die Entitätsadresse in dem Adressfeld der gerufenen Partei des SCCP-Teils der Nachricht benutzt wird. In diesem Fall würde die Nachricht an ein SMSC gelenkt werden, welches auf der Entitätsadresse für dieses SMSC in der Datenbank 332 beruht.
Damit gestattet der flexible Leitweglenkknoten 402, welcher in 12 dargestellt wird, dass Kurznachrichtdienst-Nachrichten an ein SMSC in einem Netzwerk leitweggelenkt werden, welches viele SMSCs beinhaltet. Dieses Leitweglenken kann ausgeführt werden, ohne dass es erforderlich ist, die Mobilhandgeräte eines Mobiltelekommunikations-Service Providers zu verändern, wenn ein neuer SMSC dem Netzwerk hinzugefügt wird. Demzufolge reduziert der flexible Leitweglenkknoten entsprechend der vorliegenden Erfindung in großem Maße die Belastung bzw. Mühe der Mobiltelekommunikations-Netz-Provider, wenn neue SMSCs an ein Netzwerk hinzugefügt werden.
Es ist davon auszugehen, dass verschiedene Details der Erfindung verändert werden können, ohne vom Umfang der Erfindung abzuweichen. Außerdem dient die vorausgegangene Beschreibung nur dem Zweck der Erläuterung und ist nicht als Einschränkung zur Erfindung gedacht, wie sie durch die nachfolgenden Patentansprüche definiert sind.

Claims

Verfahren zum Leitweglenken bzw. Weiterleiten von Nachrichten an ein Short Message Service Center (SMSC) (508) bzw. Kurzmitteilungsdienstzentrum in einem Netzwerk, welches eine Vielzahl von SMSCs (506 und 508) beinhaltet und in welchem eine globale Titelumsetzung bzw. Titelübersetzung auf der Basis von globalen Titeladressen durchgeführt wird, welche in Signalisier-Verbindungssteueranteilen der Nachrichten gespeichert sind, wobei das Verfahren charakterisiert ist durch: a) Empfangen einer Nachricht (ST1), welche einen Signalisier-Verbindungssteueranteil und einen Mobil-Applikationsanteil besitzt, wobei der Mobil-Applikationsanteil eine mobile Identifikationszahl aufweist; b) Festlegen bzw. Bestimmen (ST2) eines Entitätstyps für die Nachricht basierend auf dem Signalisierverbindungssteueranteil; c) in Antwort auf das Bestimmen, dass der Entitätstyp anzeigt, dass die Nachricht für ein SMSC bestimmt ist, Ausführen (ST10) eines Suchlaufs in einer Adressen-Umsetzungsdatenbank (330 oder 332), wobei die mobile Identifikationszahl aus dem Mobil-Applikationsanteil der Nachricht benutzt wird, um eine Adresse für einen der SMSCs (506 und 508) in dem Netzwerk zu lokalisieren bzw. zu orten; und d) in Antwort auf das Orten der Adresse, Leitweglenken bzw. Weiterlenken der Nachricht basierend auf der Adresse.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Ausführen eines Suchlaufs in einer Adressumsetzungsdatenbank das Ausführen eines Suchlaufs in einer Datenbank (330) beinhaltet, welche durch einzelne Mobil-Identifikationszahlen indiziert ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Ausführen eines Suchlaufs in einer Adressumsetzungsdatenbank das Ausführen eines Suchlaufs in einer Datenbank (332) beinhaltet, welche durch die Bereiche der Mobil-Identifikationszahlen indiziert ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Ausführen eines Suchlaufs in einer Adressumsetzungsdatenbank das Ausführen eines Suchlaufs in einer ersten Datenbank (330) beinhaltet, welche durch einzelne Mobil-Identifikationszahlen indiziert ist, wobei der MIN, welcher aus dem MAP-Teil der Nachricht herausgezogen ist, benutzt wird, und in Antwort auf das Fehlschlagen des Lokalisierens der Adresse in der ersten Datenbank, das Ausführen eines Suchlaufs in einer zweiten Datenbank (332) ausgeführt wird, wobei eine Entitätsadresse, welche aus dem Signalisierverbindungssteueranteil der Nachricht extrahiert ist, benutzt wird.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Entitätsadresse, welche aus dem Signalisier-Verbindungssteueranteil der Nachricht extrahiert ist, einer Entitätsadresse entspricht, welche in einen Mobil-Handapparat programmiert ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Empfangen einer Nachricht das Empfangen einer Kurznachricht-Dienstnachricht von einem Mobil-Schaltzentrum beinhaltet.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das Empfangen einer Kurznachricht-Dienstnachricht das Emp fangen einer Kurznachricht-Dienstnachricht an einem Signalübertragungspunkt oder Signalisiernetzübergang beinhaltet.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Leitweglenken bzw. Weiterleiten der Nachricht, basierend auf der Adresse, das Leitweglenken der Nachricht zu einem Netzanpassungs-Mobil-Schaltzentrum (IWMSC) (504) beinhaltet, welches mit einem SMSC (508) angeordnet ist.
Flexibler Leitweglenkungsknoten bzw. Weiterleitknoten (404) zur Verwendung in einem Netzwerk, in welchem eine globale Titelumsetzung bzw. -übersetzung ausgeführt wird, basierend auf globalen Titeladressen beim Signalisieren von Verbindungssteueranteilen der Nachrichten, wobei der Leitweglenkknoten charakterisiert ist durch: (a) eine erstes Kommunikationsmodul (308) zum Empfangen von Signalisiernachrichten, wobei bestimmt wird, ob die Nachrichten einen Signalisier-Verbindungssteueranteil (SCCP) zum Verarbeiten benötigen, und in Antwort auf das Bestimmen, dass die Nachrichten SCCP-Verarbeitung erfordern, ein internes Leitweglenken der Nachrichten; und (b) ein Verarbeitungsmodul (322) zum Empfangen der Signalisiernachrichten, welche eine SCCP-Verarbeitung erfordern, welcher bestimmt, ob die Signalisiernachrichten einen SMSC-Entitätstyp besitzen, und, in Antwort auf das Bestimmen, dass die Nachrichten SMSC-Entitätstypen besitzen, Extrahieren Mobil-Identifikationszahlen aus den Mobil-Applikationsanteilbereichen der Nachrichten und Ausführen von Adressumsetzungen für die Nachrichten, basierend auf den Mobil-Identifikationszahlen.
Flexibler Leitweglenkknoten bzw. Weiterleitknoten (504) nach Anspruch 9, dadurch gekennzeichnet, dass das Verarbeitungsmodul eine Entitätstyp-Tabelle beinhaltet, zum Bestimmen eines Entitätstyps für das Signalisieren der Nachrichten, welche SCCP-Verarbeitung erfordern.
Flexibler Leitweglenkknoten (504) nach Anspruch 10, dadurch gekennzeichnet, dass die Entitätstyp-Tabelle Einträge zum Umsetzen von Untersystemzahlwerten für die Entitätstyp-Identifiziereinrichtungen beinhaltet.
Flexibler Leitweglenkknoten (504) nach Anspruch 11, dadurch gekennzeichnet, dass die Entitätstyp-Tabelle einen ersten Eintrag zum Umsetzen eines Untersystem-Zahlwertes in einen SMSC-Entitätstyp beinhaltet.
Flexibler Leitweglenkknoten (504) nach Anspruch 12, dadurch gekennzeichnet, dass der erste Eintrag den Untersystemzahlenwert 8 in einen SMSC-Entitätstyp umsetzt.
Flexibler Leitweglenkknoten (504) nach Anspruch 12, dadurch gekennzeichnet, dass das Verarbeitungsmodul angepasst ist, die Adressumsetzungen basierend auf den Mobil-Identifikationszahlen auszuführen, welche aus den MAP-Teilen der Nachrichten für Nachrichten, welche einen Entitätstyp von SMSC besitzen, extrahiert werden.