DE69825624T2

DE69825624T2 - Verfahren zum weiterleiten und datenerfassung einer digitaler nachricht aus einer telekommunikationseinrichtung

Info

Publication number: DE69825624T2
Application number: DE1998625624
Authority: DE
Inventors: David Macdaniel; R. Jinx SMITH; L. Minh PHAN; Yao-Pao Chien (Frank)
Original assignee: Alcatel USA Inc
Current assignee: Alcatel Lucent Holdings Inc
Priority date: 1997-12-15
Filing date: 1998-12-15
Publication date: 2005-01-13
Anticipated expiration: 2018-12-16
Also published as: WO1999031892A3; US6175732B1; DE69825624D1; JP2003523099A; WO1999031892A9; WO1999031892A2; EP1040687B1; EP1040687A2; EP1040687A4

Description

Feld der Erfindung
Die vorliegende Erfindung bezieht sich auf ein System zur Weiterleitung und zur Datenerfassung einer digitalen Nachricht, speziell in der Anwendung auf eine digitale Nachricht, die von einem Zellular-Mobiltelefon oder einer anderen Telekommunikationseinrichtung stammt.
Hintergrundinformationen
Die vorliegende Erfindung bezieht sich auf Zellularfunk- und Fernsprechnetze. Diese Netze bestehen im Allgemeinen aus mobilen Kommunikationseinheiten (z. B. Mobiltelefonen), welche die Teilnehmer nutzen, um Funksignale zu senden, die Sprachdaten über Funk zu anderen Teilnehmern übertragen. Eine Mobileinheit sendet ein Signal, das von einer Basisstation für den Bereich oder die "Zelle" empfangen wird, in dem sich die Mobileinheit befindet. Die Basisstation leitet das Signal zu einem Mobilfunk-Vermittlungszentrum weiter, welches das Signal zu seinem Ziel weiterleitet. Dieses Ziel kann ein drahtgebundenes Fernsprechnetz oder eine andere Basisstation sein, die das Signal zu einer anderen Mobileinheit sendet. In jedem Fall wird das Signal durch ein Zellularfunk-Telekommunikationsnetz geleitet, bevor es entweder wieder an eine andere Mobileinheit gesendet oder an das drahtgebundene Fernsprechnetz weitergeleitet wird.
Das oben erwähnte Zellularfunk-Telekommunikationsnetz enthält Basisstationen, die in einem geografischen Dienstbereich (wobei jeder eine Antenne, eine Basisstations-Steuerung und einen Sender/Empfänger enthält) strategisch angeordnet sind. Jede Basisstation ist an ein Mobilfunk-Vermittlungszentrum angeschlossen, wobei jedes Mobilfunk-Vermittlungszentrum mehrere Basisstationen bedient. Das Mobilfunk-Vermittlungszentrum ist im Allgemeinen eine kleine Anlage, die sich zwischen den Basisstationen befindet, die es bedient, und eine zentralisierte Einrichtung für das Netz. Eine Heimatdatei (Home Location Register, HLR) befindet sich in der zentralisierten Netzwerkeinrichtung und bedient alle Mobilfunk-Vermittlungszentren des Netzes. Die HLR speichert Daten der Teilnehmer am Netz und bietet Zugriff auf sie. Die HLR speichert zum Beispiel Daten, welche das Heimat-Netz eines Teilnehmers, Art oder Ebene des Dienstes und andere Teilnehmerinformationen beschreiben. Jedes Mobilfunk-Vermittlungszentrum enthält eine Besucherdatei ("VLR"), in der Teilnehmer registriert werden, die auf das Netz zugreifen, die aber nicht in der HLR des Netzes aufgelistet sind, weil sie sich geografisch außerhalb ihres Heimatnetzes befinden, wenn sie auf das Mobilkommunikationssystem zugreifen. Die VLR kommuniziert mit den HLRs im ganzen System, um Teilnehmerdaten über die Teilnehmer zu erhalten, die auf das Netz zugreifen.
Zusätzlich zu Sprachsignalen, die Sprachdaten übertragen senden Mobileinheiten digitale Nachrichten an ein Telekommunikationsnetz. Diese Nachrichten können dazu verwendet werden, um zum Beispiel die Dienstebene eines Teilnehmers zu ändern, die Dienstoptionen eines Teilnehmers zu ändern oder die von einem Teilnehmer registrierte Nummer zu ändern, an die eintreffende Anrufe für den Teilnehmer weiterzuleiten sind. Wie Sprach-Datensignale werden Nachrichten auch von Basisstationen empfangen und zu Mobilfunk-Vermittlungszentren weitergeleitet. Nachrichten werden dann jedoch vom Netz verarbeitet und nicht zu anderen Teilnehmern weitergeleitet oder mit ihnen verbunden. Die Nachrichten können von der HLR oder einer anderen Komponente des Netzes verarbeitet und implementiert werden, die so konstruiert ist, auf die in der Nachricht angegebene Information zu wirken. Die Nachrichten können als Befehle bezüglich dieser Komponenten wirken. Diese Komponenten von Kommunikationsnetzen enthalten im Allgemeinen Standard- Mikrocomputer, die programmiert sind, digitale Nachrichten von Mobileinheiten zu empfangen, die über eine Basisstation weitergeleitet werden. Auf der Grundlage der Nachrichten führen die Computer Operationen aus, wie z. B. Ändern der Dienstoptionen des Teilnehmers oder Ändern einer Nummer, zu der die Anrufe eines Teilnehmers weitergeleitet werden müssen.
Moderne Telekommunikationssysteme haben die Fähigkeit, die Eigenschaften fernzusteuern, so dass ein Teilnehmer zum Beispiel ein Konto eröffnen, ein Passwort ändern, eine Dienstebene ändern oder andere Diensteigenschaften, wie z. B. Rufweiterleitungs-Optionen ändern kann. Die derzeitigen Systeme zur Fernsteuerung von Eigenschaften empfangen Nachrichten durch eine HLR. Alle diese Funktionen werden im Telekommunikationsnetz ausgeführt, ohne dass Nachrichten an oft inkompatible, von anderen Herstellern betriebene Systeme nach außen weitergeleitet werden müssen.
In den derzeitigen Systemen werden Nachrichten von einer HLR empfangen und entweder innerhalb der HLR verarbeitet oder von einer anderen Komponente des Netzes verarbeitet, die entwickelt wurde, um die durch die Nachricht spezifizierte Funktion auszuführen. Die Komponente verarbeitet die Nachricht entsprechend dem Inhalt der Nachricht und löst die von der Nachricht angeforderte Funktion aus. Zum Beispiel enthält eine Nachricht, die eine Aktualisierung einer Rufweiterleitungs-Nummer anfordert, einen bestimmten Code, der dem Netz signalisiert, dass es sich um eine Anforderung nach der Aktualisierung einer Rufweiterleitungs-Nummer handelt. Eine Netzkomponente liest diesen Code und stellt fest, dass die Nachricht nicht in der Komponente abzuschließen ist, sondern an eine Komponente im Netz weitergeleitet werden muss, die speziell für die Behandlung der Rufweiterleitung konstruiert wurde. Die Komponente, in der die Nachricht abzuschließen ist, löst dann die Sequenz zur Aktualisierung der Rufweiterleitungs-Nummer aus.
Derzeitige Systeme bieten nur die Weiterleitung von Nachrichten innerhalb eines Netzes. Neue Anwendungen zur Benutzung von über Funk übertragenen digitalen Nachrichten erfordern die Weiterleitung von Nachrichten nach außerhalb des Netzes. Neben der Änderung von Teilnehmer- und Dienst-Optionen können von Mobileinheiten übertragene digitale Nachrichten dazu verwendet werden, zum Beispiel Informationen von entfernten Orten an zentrale Datenbanken zu liefern (z. B. die direkte Übermittlung von Zählerständen von Gas-, Wasser- oder Stromzählern an die Datenbank einer Firma), oder einen speziellen geografischen Ort eines Teilnehmers zu senden, oder Befehle an entfernt angeordnete Einrichtungen zu senden (z. B. einen Befehl zum Ein-/Ausschalten).
In US-Patent Nr. 5,577,102 wird ein System zur Verarbeitung von Kurznachrichten in einem zellularen Mobiltelefonnetz beschrieben. Das System ist als einfaches Verfahren zur Übertragung von Kurznachrichten von einem Teilnehmer auf einem zellularen Mobiltelefonnetz zu einem anderen Teilnehmer konstruiert. Eine Nachricht wird von einem Mobilfunk-Vermittlungszentrum empfangen, welches dann die Adresse der Nachricht prüft, die Nachricht speichert, mit einer HLR kommuniziert, um Wegesuch-Information zu erhalten, und die Nachricht an den gewünschten Teilnehmer sendet. Dieses System empfängt, verarbeitet und leitet digitale Nachrichten in einem zellularen Telekommunikationsnetz weiter. Es leitet keine Nachrichten nach außerhalb des Netzes.
In US-Patent Nr. 5,428,665 wird ein Verfahren zur Verwaltung von Prozeduren für ergänzende Dienstmerkmale in einem globalen System zur Mobilkommunikation beschrieben. Mobilstationen senden Nachrichten, die entweder in einem Mobilfunk- Vermittlungszentrum/einer Besucherdatei (MSC/VLR) oder in einer Heimatdatei (HLR) zu verarbeiten sind. Das MSC/VLR leitet die für die HLR bestimmten Nachrichten an die HLR weiter, ohne den Inhalt anzusehen oder sie auf irgendeine Weise zu verarbeiten. Nachrichten, die im MSC/VLR abzuschließen sind, werden vom MSC/VLR behalten und intern verarbeitet.
In US-Patent Nr. 5,594,740 wird ein Verfahren und eine Vorrichtung zur Verwendung der Steuerkanäle eines vorhandenen zellularen Fernsprechnetzes zum Senden und Empfangen von bidirektionalen drahtlosen Datennachrichten beschrieben. Das System umfasst die Manipulation, Umsetzung und Verschlüsselung von Steuerkanal-Datenbits und bietet eine anwendungsspezifische Nachrichtenübertragung auf den Steuerkanälen eines vorhandenen Telekommunikationsnetzes. Dieses System bietet keine Weiterleitung anwendungsspezifischer Nachrichten nach außerhalb eines Telekommunikationsnetzes.
In US-Patent Nr. 5,546,444 wird ein anderes Verfahren und eine Vorrichtung zur Verwendung der Steuerkanäle eines vorhandenen zellularen Fernsprechnetzes zum Senden von Datennachrichten über eine spezielle Kommunikationsverbindung an ein Datensammlungs-System beschrieben. Dieses System bietet keine Weiterleitung anwendungsspezifischer Nachrichten nach außerhalb eines Telekommunikationsnetzes in Richtung verschiedener entfernter Einheiten.
In der internationalen Patentanmeldung WO 97/20442 wird ein Verfahren und eine Vorrichtung zur Vereinfachung der Nachrichtenkommunikation zwischen Netzwerken innerhalb eines zellularen Telekommunikationsnetzes beschrieben. Bei diesem Verfahren ist es erforderlich, dass die weiterzuleitenden Nachrichten eine Ziel-Kennung im Textfeld der Nachrichten enthalten.
Zusammenfassung der Erfindung
Die Erfindung betrifft ein Verfahren zur Weiterleitung einer Nachricht, das folgende Schritte umfasst:

– In einem zellularen Funk-Telekommunikationsnetz von einer Basisstation Empfangen einer Nachricht, die eine Mobil-Kennnummer enthält;
– Feststellung, ob die Nachricht an eine entfernte Einheit außerhalb des Telekommunikationsnetzes weiterzuleiten ist;
– Wenn die Nachricht nicht weiterzuleiten ist, Verarbeitung der Nachricht im Telekommunikationsnetz; und
– Wenn die Nachricht weiterzuleiten ist, Weiterleitung der Nachricht zur entfernten Einheit, welche die Nachricht verarbeitet.

Gemäß der Erfindung enthält der Feststellungsschritt die Schritte der Abfrage einer Datenbank nach der Mobil-Kennnummer, die in der Nachricht enthalten ist, wobei die Datenbank eine Vielzahl von Mobileinheit-Kennnummern enthält, wobei mindestens einige aus der Vielzahl der Mobileinheit-Kennnummern einer entsprechenden entfernten Einheit außerhalb des Telekommunikationsnetzes zugeordnet ist, und die Nachricht wird nach außerhalb des Telekommunikationsnetzes zur entfernten Einheit weitergeleitet, wenn die in der Nachricht enthaltene Mobileinheit-Kennnummer in der Datenbank der entfernten Einheit zugeordnet ist.
In einer beispielhaften Ausführung der vorliegenden Erfindung wird ein System, das Multi-Thread-Prozesse enthält, zur Weiterleitung digitaler Nachrichten nach außerhalb eines Telekommunikationsnetzes und zur Datenerfassung dieser Nachrichten, zum Beispiel zum Zweck der Rechnungsstellung, bereitgestellt. Das System empfängt eine Nachricht und stellt fest, ob die Nachricht im Netz verarbeitet werden muss oder nach außerhalb des Netzes weitergeleitet werden muss, zum Beispiel an ein Anwenderprogramm eines Herstellers. Das System verwendet eine Heimatdatei (HLR), auf der ein Dienstlogik-Programm (SLP) läuft, eine Vielzahl von Relais (implementiert als Haut-Relais und ein oder mehrere Unter-Relais), einen Diskriminator und Nachrichten-Datenerfassungs-Dateien und entspricht dem Telekommunikations-Standard IS41.
In einer beispielhaften Ausführung empfängt das SLP eine digitale Nachricht von einer Telekommunikationseinrichtung und stellt fest, ob die Nachricht nach außerhalb des Netzes weitergeleitet werden muss. Wenn die Nachricht weitergeleitet werden muss, formatiert das SLP die Nachricht und sendet sie zum Haupt-Relais. Wenn das Haupt-Relais eine Nachricht vom SLP empfängt, schreibt das Haupt-Relais die Nachricht in eine Protokolldatei. Das Haupt-Relais leitet die Nachricht dann an den Diskriminator weiter, der auf der Grundlage der in der Nachricht enthaltenen Information die Nachricht an eines der Unter-Relais weiterleitet. Jedes Haupt-Relais und Unter-Relais steht schreibend und lesend in Kommunikation mit einer Protokolldatei. Das Unter-Relais, welches die Nachricht empfängt, sendet die Nachricht über ein Hersteller-Relais an eine spezielle Hersteller-Anwendung, die sich außerhalb des Telekommunikationsnetzes befindet.
Das Relais-/Diskriminator-/Unter-Relais-System arbeitet als Schnittstelle zwischen dem Telekommunikationsnetz und einem außerhalb liegenden System, die Nachrichten vom Telekommunikationsnetz an das außerhalb liegende System weiterleitet, wo sie verarbeitet und für die spezielle Geschäfts-Applikation des anderen Herstellers verwendet werden.
Kurzbeschreibung der Zeichnungen
1 ist ein Blockdiagramm der Gesamt-Systemarchitektur einer beispielhaften Ausführung der vorliegenden Erfindung.
2 zeigt die Struktur einer beispielhaften digitalen Nachricht.
3 ist ein Flussdiagramm eines Teils des Dienstlogik-Programms (SLP).
4 ist ein Flussdiagramm eines beispielhaften Haupt-Relais-Prozesses.
5 ist ein Flussdiagramm eines beispielhaften Diskriminator-Prozesses.
6 ist ein Flussdiagramm eines beispielhaften Unter-Relais-Prozesses.
7 zeigt die von einem Relais gemäß der beispielhaften Ausführung der vorliegenden Erfindung erzeugten Threads.
8 zeigt die Funktion eines Threads gemäß der beispielhaften Ausführung der vorliegenden Erfindung.
9 zeigt die Funktion eines beispielhaften Relais-Prozesses.
10 zeigt die "Handshake"-Operationen der Relais-Client-Verbindungen gemäß der beispielhaften Ausführung der vorliegenden Erfindung.
Detaillierte Beschreibung
Überblick über die Architektur: In 1 ist ein Blockdiagramm der Gesamt-Systemarchitektur einer beispielhaften Ausführung der vorliegenden Erfindung gezeigt. Es wird eine HLR 101 bereitgestellt, die einen digitalen Computer umfasst, wie z. B. eine Workstation Sun Microsystems^TM SPARC^® oder UltraSPARC^®. Auf der HLR 101 läuft ein Software-Programm. Die HLR 101 enthält eine Datenbank mit Daten der Netzwerkteilnehmer (wie z. B. Teilnehmer-Kennnummern) und Daten über Nachrichtenziele (wie Host-Namen, Netzwerkdienst-Namen und Hersteller-Kennnummern). Zusätzlich dazu läuft auf der HLR 101 ein SLP 102.
Der SLP 102 ist ein Prozess, der feststellt, ob Nachrichten vom HLR 101 verarbeitet werden müssen oder an eine Einrichtung eines anderen Herstellers nach außen weitergeleitet werden müssen. In der beispielhaften Ausführung der vorliegenden Erfindung wird der SLP 102 mit einer Umgebung zur Erzeugung von Diensten (Service Creation Environment, SCE) erzeugt, einem Software-Werkzeug, das für die Erzeugung und Überwachung komplexer Software-Programme für Telekommunikationsnetze verwendet wird. Die SCE erlaubt es den Entwicklern, schon geschriebene unabhängige Code-Bausteine zusammenzustellen, wozu Flussdiagramme und ein interaktiver Grafik-Editor verwendet werden.
Die SCE ermöglicht es einem SLP-Entwickler, einen neuen SLP in einer über Fenster zu bedienenden interaktiven Umgebung zu entwickeln. Der Entwickler beginnt mit der Konstruktion eines neuen speziellen SLP, indem er einen allgemeinen SLP (von der SCE bereitgestellt) installiert. Der Entwickler führt dann nach Wunsch Kundenanpassungen des allgemeinen SLP durch, um ihn in einen speziellen SLP umzusetzen, der den speziellen Anforderungen des Entwicklers entspricht. Abschließend testet der Entwickler den SLP mit der Animationsfunktion der SCE.
Der Entwickler installiert einen allgemeinen SLP, indem er mit einer Maustaste auf ein allgemeines SLP-Symbol klickt und dann die Funktion zum Erzeugen wählt. Der Entwickler kann dann den allgemeinen SLP konstruieren, indem er dienstunabhängige Bausteine (SIBs) einfügt und verbindet. SIBs sind Codeblöcke die von den Dienstanwendungen unabhängig sind. Gemäß der beispielhaften Ausführung werden die SIBs als Flussdiagramm-Objekte dargestellt. Ein SIB kann ein Eintritts-SIB, ein Eingabe-SIB oder ein Entscheidungs-SIB sein. Klickt man auf einen SIB, erscheint ein Parameter-Fenster, das der Entwickler verwenden kann, um die Parameter des SIB zu ändern. Wenn der allgemeine SLP erzeugt wurde, wird er durch Klicken auf das Symbol "Save (Speichern)" abgespeichert, bevor der SLP in einen speziellen SLP geändert wird.
Um den allgemeinen SLP in einen speziellen SLP zu ändern, richtet der Entwickler zunächst Teilnehmer ein. Der Entwickler ordnet dem SLP eine Dienstnummer und einen Dienstnamen zu. Der Entwickler klickt auf eine Schaltfläche "create (Erzeugen)" und gibt dann eine Dienstnummer ein. Durch Klicken auf eine Schaltfläche "selct service (Dienst auswählen)" ordnet der Entwickler den Dienst einem vorhandenen Teilnehmer zu. Um einen neuen Teilnehmer anzulegen, klickt der Entwickler auf eine Schaltfläche "create subscriber (Teilnehmer anlegen)" und gibt die Teilnehmernummer, den Teilnehmernamen und die Auslöser für den SLP ein. Wenn dies beendet ist, schaltet der Entwickler die SCE in den Teilnehmermodus, in dem der Teilnehmer den allgemeinen SLP ändern kann.
Um den allgemeinen SLP zu editieren, kann der Entwickler auf jeden SIB klicken, um ein Parameter-Fenster aufzurufen und zu editieren. Die Änderungen werden in diesem Fenster durchgeführt und dann auf den SIB angewendet, wenn das Fenster geschlossen wird. Wenn die SLP-Änderungen beendet sind, wird der SLP als spezieller SLP abgespeichert, indem auf eine Schaltfläche zum Speichern der Änderungen geklickt wird.
Der neue spezielle SLP wird dann getestet, wozu die Funktionen der SCE verwendet werden. Diese Funktionen umfassen intelligente Netzwerk-Applikations- und Animations-, sowie Überwachungs-Steuerungsfenster und ein Dienstumschaltpunkt-Fenster zur Simulation von Anrufen. Die SCE bietet eine Animation zur Überprüfung des Betriebs des SLP.
Der spezielle SLP 102 der vorliegenden Erfindung ist über eine Standard-TCP/IP-(Transmission Control Protocol/Internet Protocol)-Verbindung 123 mit einem Haupt-Relais 103 gekoppelt. Das Haupt-Relais 103 ist ein Prozess, der in Software implementiert ist und auf der HLR 101 oder einem gesonderten Computer laufen kann (z. B. ein Sun Microsystems^TM SPARC^® oder UltraSPARC^®, oder ein Standard-Personal-Computer).
Das Haupt-Relais 103 (z. B. in der Programmiersprache C++ implementiert) leitet vom SLP 102 empfangene Nachrichten an einen Diskriminator 104 weiter.
Zusätzlich dazu protokolliert das Haupt-Relais 103 über einen Datei-E/A-Systemaufruf jede Nachricht in einer Protokolldatei 109. In der beispielhaften Ausführung wird die Protokolldatei 109 auf einer lokalen Festplatte des Computers gespeichert, auf dem das Haupt-Relais 103 läuft.
Das Haupt-Relais 103 ist mit dem Diskriminator 104 über eine TCP/IP-Verbindung 134 gekoppelt. Der Diskriminator 104 ist ein Prozess, der in Software implementiert ist (z. B. in der Programmiersprache C++) und auf demselben Computer laufen kann wie das Haupt-Relais 103, oder auf einem gesonderten Computer, der mit dem Haupt-Relais 103 verbunden ist. Der Diskriminator 104 empfängt Nachrichten vom Haupt-Relais 103 und leitet jede empfangene Nachricht an ein geeignetes Unter-Relais 105, 106 weiter.
Der Diskriminator 104 ist mit zwei Unter-Relais 105, 106 gekoppelt. Obwohl zwei Unter-Relais 105, 106 gezeigt werden, kann das System der vorliegenden Erfindung jede beliebige Zahl von Unter-Relais enthalten.
Jedes Unter-Relais 105, 106 ist ein Prozess, der in Software implementiert ist (z. B. in der Programmiersprache C++) und auf demselben Computer laufen kann wie der Diskriminator 104 oder auf einem gesonderten Computer, der mit dem Diskriminator 104 über TCP/IP-Verbindungen 145, 146 verbunden ist. Dieser Computer kann zum Beispiel ein Sun Microsystems^TM SPARC^® oder Ultra SPARC^® oder ein Standard-Personal-Computer sein. Es können mehrere Unter-Relais auf demselben Computer laufen oder jedes Unter-Relais auf einem gesonderten Computer.
Jedes Unter-Relais 105, 106 ist über eine TCP/IP-Verbindung 157, 168 mit einem entsprechenden Hersteller-Relais 107, 108 verbunden. Jedes Unter-Relais empfängt Nachrichten vom Diskriminator 104 und leitet die empfangenen Nachrichten an das entsprechende Hersteller-Relais 107, 108 weiter, das sich außerhalb des Telekommunikationsnetzes befindet.
Zusätzlich dazu protokolliert jedes Unter-Relais 105, 106 über einen Datei-E/A-Systemaufruf jede Nachricht, die es empfängt, in einer entsprechenden Protokolldatei 110, 111. In der beispielhaften Ausführung wird jede der Protokolldateien 110, 111 auf einer lokalen Festplatte des Computers gespeichert, auf dem das entsprechende Unter-Relais 105, 106 läuft.
Die Hersteller-Relais 107, 108 werden auf Computern ausgeführt, die von den Unter-Relais 105, 106 getrennt sind und sich außerhalb des Telekommunikationsnetzes befinden. Weiterhin wird in der beispielhaften Ausführung jedes der Hersteller-Relais 107, 108 auf einem gesonderten einzelnen Computer ausgeführt. Die Hersteller-Relais 107, 108 sind Teile von Hersteller-Anwenderprogrammen, welche die Nachrichten empfangen, die von den Hersteller-Anwenderprogrammen verarbeitet werden.
Überblick über die Funktion: Im Betrieb empfängt in der beispielhaften Ausführung der vorliegenden Erfindung die HLR 101 eine digitale Nachricht, die von einer Basisstation über ein Mobilfunk-Dienst-Vermittlungszentrum weitergeleitet wurde. Das Format der digitalen Nachricht ist das einer Nachricht zur Fernsteuerung von Funktionen gemäß dem Telekommunikationsstandard IS41 und umfasst ein Feld, welches eine Mobileinheit-Kennnummer (MIN) enthält, ein Feld, das eine Mobileinheit-Seriennummer (MSN) enthält, sowie ein Feld, das die vom Teilnehmer gewählten Ziffern enthält. Die Nachricht wird vom SLP 102 verarbeitet und formatiert. Der SLP 102 stellt fest, ob die digitale Nachricht an eine Hersteller-Einrichtung nach außerhalb weiterzuleiten ist, indem er die MIN in eine Datenbank abbildet. Insbesondere fragt der SLP 102 die Datenbank ab, um festzustellen, ob die MIN der Nachricht sich in den MIN-Bereichen befindet, die in der Datenbank aufgelistet sind. Wenn gefunden wird, dass die MIN sich in einem dieser Bereiche befindet, ruft der SLP die zu dem Bereich gehörende Information aus der Datenbank ab und konstruiert eine Nachricht in dem Format, das später in Zusammenhang mit 2 noch beschrieben wird. Der SLP 102 leitet die Nachricht dann über die TCP/IP-Verbindung 123 an das Haupt-Relais 103 weiter. Wenn die MIN der Nachricht nicht in den in der Datenbank enthaltenen Bereichen gefunden wird, muss die Nachricht nicht weitergeleitet werden, und der SLP 102 verarbeitet die Nachricht intern.
Das Haupt-Relais 103 schreibt eine Datensatz-Kennung (ID) in festgelegte Felder der Nachricht. Die Datensatz-Kennung kennzeichnet das Haupt-Relais und dient zur eindeutigen Kennzeichnung der Nachricht. Das Haupt-Relais 103 schreibt (d. h. "protokolliert") dann die Nachricht in die Protokolldatei 109 und leitet die Nachricht über die TCP/IP-Verbindung 134 zum Diskriminator 104 weiter.
In der beispielhaften Ausführung enthält das Haupt-Relais 103 Objekte, wie z. B. ein Protokoll-Manager-Objekt ("LogMgr") und ein Relais-Manager-Objekt ("Mgr") und ist als Multi-Thread-Prozess implementiert. Ein Multi-Thread-Prozess arbeitet, indem er mehrere "Threads" oder "Einfach"-Prozesse erzeugt, die gleichzeitig arbeiten können. Diese Threads sind Mitglieder-Funktionen des Objektes Mgr. Einfach-Prozesse sind Mini-Prozesse, die untereinander über einfache Speicher-Schreib-/Lese-Befehle kommunizieren können, im Gegensatz zu "Komplett"-Prozessen, die über TCP/IP-Schnittstellen miteinander kommunizieren müssen. Ein Multi-Thread-Prozess arbeitet wie ein Multitasking-System mit dem Unterschied, dass die Kommunikation zwischen den Threads weniger Ressourcen benötigt als die Kommunikation der Prozesse eines Multitasking-Systems. Die Threads können über einfache Speicher-Schreib-/Lese-Funktionen kommunizieren, so dass es nicht erforderlich ist, über das Betriebssystem zu gehen.
Das Haupt-Relais 103 erzeugt getrennte Threads zur Kommunikation mit einzelnen Clients und kann daher mit mehreren Clients gleichzeitig kommunizieren.
Vom Standpunkt der TCP/IP-Netzwerkverbindung arbeitet das Haupt-Relais 103 als Server. Die Client/Server-Architektur beschreibt eine allgemeine Form von verteiltem System, in dem die Software zwischen Server-Tasks und Client-Tasks aufgeteilt wird. Ein Client sendet gemäß einem bestimmten Protokoll Anforderungen an einen Server und fragt nach Informationen oder fordert Aktionen an, und der Server reagiert, indem er die Informationen liefert oder die Aktion ausführt und eine Bestätigungsnachricht zurück zum Client sendet.
Als Server erlaubt das Haupt-Relais 103 Verbindungen durch externe Clients (in 1 nicht gezeigt). Diese externen Clients sind Softwareprozesse, die auf demselben Computer wie das Haupt-Relais 103 oder auf einem anderen Computer laufen können. Wenn Clients mit dem Haupt-Relais 103 eine Verbindung aufnehmen, erzeugt das Haupt-Relais 103 Threads für jeden (verwaltet durch den Mgr), um mit den Clients zu kommunizieren. Diese Clients können Informationen von der Protokolldatei 109 benötigen, um ihre Funktionen auszuführen, wie z. B. die Feststellung, ob in der Protokolldatei 109 noch nicht weitergeleitete Nachrichten gespeichert sind oder nicht, oder die Archivierung der in der Protokolldatei 109 gespeicherten gesendeten Nachrichten, so dass Speicherplatz in der Protokolldatei 109 für neue Nachrichten freigegeben werden kann.
Ein Client, zum Beispiel ein Archivierungsprozess, kann das "Unspooling" von Nachrichten aus der Protokolldatei 109 anfordern. Diese Anforderung wird von dem Thread über LogMgr gesendet. Der LogMgr verwaltet die Interaktion zwischen dem Haupt-Relais 103 und der Protokolldatei 109, führt die Schreib/Lese-Funktionen aus, die zur Ausführung der Funktionen des Haupt-Relais 103 und der Anforderungen der Clients erforderlich sind. Das Haupt-Relais 103 enthält auch eine Datensatz-Tabelle, wobei es sich um eine Datenstruktur handelt, die als "Verzeichnis" oder "Tabelle" des Inhaltes der Protokolldatei 109 dient.
Ein Archivierungsprozess kann zum Beispiel anfordern, dass die Zwischenspeicherung aller "gesendeten" Nachrichten rückgängig gemacht wird (Unspooling). Der LogMgr ruft die in der Datensatz-Tabelle als "gesendet" markierten Nachrichten auf, um ihre Lage in der Protokolldatei 109 zu bestimmen. Der LogMgr liest dann jede gesendete Nachricht aus der Protokolldatei 109, markiert die Nachricht als kopiert oder archiviert und schreibt die Nachricht in eine temporäre Datei. Das Haupt-Relais 103 sendet dann eine Quittungsnachricht an den Archivierungsprozess. Der Archivierungsprozess sendet eine Quittungsnachricht zurück an das Haupt-Relais 103. Der LogMgr markiert dann die kopierten oder archivierten Nachrichten als zu überschreiben und entfernt ihre Einträge aus der Datensatz-Tabelle. Schließlich ruft der Archivierungsprozess die temporäre Datei ab. Die Nachrichten in der Protokolldatei 109, deren Zwischenspeicherung rückgängig gemacht wurde, können dann überschrieben werden. Hierdurch werden die Nachrichten, deren Zwischenspeicherung rückgängig gemacht wurde, effektiv gelöscht und der in der Protokolldatei 109 verfügbare Speicherplatz vergrößert.
Der Diskriminator 104 empfängt eine Nachricht vom Haupt-Relais 103 und leitet die Nachrichten auf der Grundlage der in der Nachricht enthaltenen Leitweglenkungs-Information an das richtige Ziel-Unter-Relais 105, 106 weiter.
Das Unter-Relais 105, 106 protokolliert die empfangene Nachricht in seiner Protokolldatei 110, 111 und leitet die Nachricht an sein entsprechendes Hersteller-Relais 107, 108 weiter, um die weitere Verarbeitung gemäß der Funktion der herstellerspezifischen Anwendung durchzuführen, welche dem Hersteller-Relais 107, 108 entspricht.
In einer beispielhaften Ausführung des Systems enthalten die Unter-Relais 105, 106 im Wesentlichen die selbe Software wie das Haupt-Relais 103 und arbeiten somit im Wesentlichen auf die gleiche Weise wie das Haupt-Relais 103. Demgemäß ist die allgemeine Funktion der Unter-Relais 105, 106 im Wesentlichen gleich der oben in Zusammenhang mit dem Haupt-Relais 103 beschriebenen Funktion mit der Ausnahme, dass die Unter-Relais 105, 106 vom Diskriminator 104 (und nicht vom SLP 102) empfangene Nachrichten verarbeiten und die verarbeiteten Nachrichten zu Hersteller-Relais 107, 108 weiterleiten (und die Nachrichten nicht zum Diskriminator 104 weiterleiten).
Die Software von HLR 101, SLP 102, Haupt-Relais 103, Diskriminator 104 und der Sub-Relais 105, 106 kann auf demselben Computer laufen. Lässt man jedoch den Diskriminator 104 und die Unter-Relais 105, 106 auf getrennten Computern laufen, spart man Speicherplatz in der HLR 101 und verringert die allgemeine Belastung der HLR 101, wodurch das System effizienter wird.
Nachrichtenstruktur: In einer beispielhaften Ausführung der vorliegenden Erfindung sind die Nachrichten, die an Hersteller-Anwendungen nach außerhalb weitergeleitet werden, so aufgebaut wie in 2 gezeigt. Eine digitale Nachricht 200 kann zum Beispiel 156 Bytes digitale Information enthalten, die auf verschiedene Felder aufgeteilt ist.
In dieser beispielhaften Ausführung wird in den Bytes 0–3 der Nachricht ein Host-ID-Feld 201 bereitgestellt. Das Host-ID-Feld 201 kennzeichnet das Haupt-Relais 103, welches die Nachricht weitergeleitet hat, und den Computer, auf dem es ausgeführt wird. Ein Sequenz-ID-Feld 202 befindet sich in den Bytes 4–11 der Nachricht. Das Sequenz-ID-Feld 202 ist eine Reihenfolgenummer, die vom Haupt-Relais 103 zugewiesen wird. Das Haupt-Relais 103 inkrementiert diese Reihenfolgenummer für jede weitergeleitete Nachricht. Das Host-ID-Feld 201 und das Sequenz-ID-Feld 202 bilden zusammen eine Datensatz-ID, welche die Nachricht eindeutig kennzeichnet.
Ein Zeitmarken-Feld 203, 204 liefert eine Zeitmarke für die Nachricht. Das Zeitmarken-Feld 203, 204 belegt die Bytes 12–15 und 16–17 der Nachricht.
In den Bytes 18–27 wird ein Mobileinheit-Kennnummern-Feld (MIN) 205 bereitgestellt. Das MIN-Feld 205 kennzeichnet den Mobilteilnehmer, der die Nachricht gesendet hat.
In den Bytes 28–31 der Nachricht wird ein Mobileinheit-Seriennummern-Feld (MSN) 206 bereitgestellt. Das MSN-Feld 206 liefert die Seriennummer, die in der Mobileinheit, welche die Nachricht gesendet hat, fest verdrahtet ist.
Ein Feld für die gewählten Ziffern 207 in den Bytes 32–63 der Nachricht liefert die Sequenz der an der Mobileinheit gewählten Ziffern.
In den Bytes 64–67 der Nachricht wird ein Nachrichten-Raten-Feld 208 bereitgestellt.
In den Bytes 68–71 der Nachricht wird ein Hersteller-Nummern-Feld 209 bereitgestellt.
In den Bytes 72–77, bzw. 78–91 werden ein Host-Namen-Feld 210 und ein Dienst-Namen-Feld 211 bereitgestellt. Die Information im Host-Namen-Feld 210 und das Dienst-Namen-Feld 211 werden vom SLP 102 aus einer Datenbank gelesen und vom Diskriminator 104 benutzt, um festzustellen, zu welchem Unter-Relais die Nachricht weitergeleitet werden muss.
In den Bytes 92–155 der Nachricht werden andere Daten 212 gespeichert.
SLP-Prozess: Der in 3 gezeigte Prozess zeigt den Teil des SLP 102, der für die vorliegende Erfindung relevant ist, und der feststellt, ob die Nachricht an eine Hersteller-Anwendung adressiert ist oder zurückgehalten und von der HLR 101 verarbeitet werden muss. Wie gezeigt, empfängt der SLP 102 eine Nachricht (Schritt 301). Diese Nachricht wird zum Beispiel von einer Basisstation über ein Mobilfunk-Vermittlungszentrum weitergeleitet.
Als nächstes wird die Mobileinheit-Kennnummer (MIN) in der Nachricht erhalten (Schritt 302) und dazu verwendet, eine Datenbank abzufragen (Schritt 303). Die Datenbank enthält eine Liste von MIN-Bereichen, die mit einer Liste von Nachrichtenraten korreliert sind, eine Liste von Host-Namen, eine Liste von Dienst-Namen, eine Liste von Hersteller-Nummern und eine Liste von Zeichenketten variabler Länge. Wenn sich herausstellt, dass die MIN in einen der MIN-Bereiche fällt, die in der Datenbank verzeichnet sind, formatiert der SLP 102 die Nachricht, wie in 2 gezeigt, indem er die zugeordneten Felder mit den entsprechenden Informationen aus der Datenbank füllt (Schritt 304). Als Teil der Formatierungsprozedur schreibt der SLP auch eine Zeitmarkierung in die zugeordneten Felder in der Nachricht. Der SLP 102 leitet die Nachricht dann über die TCP/IP-Schnittstelle 123 an das Haupt-Relais 103 weiter (Schritt 305). Wenn die MIN nicht in den in der Datenbank enthaltenen Bereichen gefunden wird, wird eine Meldung "No Match (keine Übereinstimmung)" zurückgegeben, und die Nachricht wird intern vom SLP 102 weiter verarbeitet (Schritt 306).
Haupt-Relais-Prozess: Wenn das Haupt-Relais 103 eine Nachricht vom SLP 102 empfängt, protokolliert das Haupt-Relais 103 die Nachricht in der Protokolldatei 109 und leitet die Nachricht zum Diskriminator 104 weiter. Zusätzlich dazu macht das Haupt-Relais 103 auf Anforderung von einem Client, z. B. von einem Archivierungsprozess, die Zwischenspeicherung von Datensätzen aus der Protokolldatei rückgängig.
Da das Haupt-Relais ein Multi-Thread-Prozess ist, ist die Protokolldatei 109 sorgfältig synchronisiert, so dass auf die Protokolldatei 109 nicht von mehr als einem Thread zu einem Zeitpunkt zugegriffen wird. Gemäß der beispielhaften Ausführung der vorliegenden Erfindung wird die Synchronisation der Protokolldatei-Verbindungen durch Verwendung eines Semaphors durchgeführt. Ein Semaphor ist ein Zugriffsbit, das nur Lese-Funktionen eines einzelnen Benutzers und Schreib-Funktionen eines einzelnen Benutzers erlaubt und in der Technik bekannt ist und für Synchronisationsaufgaben verwendet wird. Wenn ein Thread auf die Protokolldatei 109 zugreift, wird das Semaphor-Bit gesetzt. Wenn das Semaphor-Bit gesetzt ist, können keine anderen Threads auf die Protokolldatei 109 zugreifen. Jeder Thread, der auf die Protokolldatei 109 zugreift, versucht so viel Daten wie möglich zu bekommen und versucht auch, das Semaphor so bald wie möglich freizugeben. Die Schreib-/Lese-Funktionen, die auf die Protokolldatei 109 angewendet werden, werden vom LogMgr durchgeführt und gesteuert.
4 ist ein Flussdiagramm des Haupt-Relais-Prozesses 103. Das Haupt-Relais 103 ist ein Multi-Thread-Programm, das vom Standpunkt der TCP/IP-Netzwerk-Verbindung als Server implementiert ist. In der beispielhaften Ausführung der vorliegenden Erfindung ist der SLP 102 der Linke-Hand-Client des Haupt-Relais 103, und der Diskriminator ist der Rechte-Hand-Client des Haupt-Relais 103.
Betrachtet man nun das Flussdiagramm von 4, empfängt das Haupt-Relais 103 eine Nachricht vom SLP 102 (Schritt 401). Das Haupt-Relais 103 schreibt eine Datensatz-ID, die eine Host-ID 201 und eine Sequenz-ID 202 umfasst, in die zugeordneten Felder der Nachricht (Schritt 402). Die Host-ID kennzeichnet eindeutig das Haupt-Relais 103. Die Sequenz-ID 202 ist eine Reihenfolgenummer, die vom Haupt-Relais 103 für jede Nachricht, die vom Haupt-Relais 103 empfangen wird, inkrementiert wird.
Das Haupt-Relais 103 testet dann das Semaphor, um festzustellen, ob die Protokolldatei 109 zum Empfang einer Nachricht zur Verfügung steht (Schritt 403). Wenn das Haupt-Relais 103 feststellt, dass die Protokolldatei 109 in Betrieb ist (d. h. das Semaphor ist gesetzt), wartet das Haupt-Relais 103, bis die Protokolldatei verfügbar wird.
Wenn das Haupt-Relais 103 feststellt, dass die Protokolldatei nicht verfügbar ist, weil die Protokolldatei voll ist (Schritt 404), verwirft das Haupt-Relais 103 die Nachricht (Schritt 409). Verworfene Nachrichten werden aus dem temporären Speicher gelöscht und sind für das System komplett verloren. Das Haupt-Relais 103 sendet dann einen Problembericht als Information an den System-Manager (Schritt 410).
Wenn die Protokolldatei 109 nicht mehr in Betrieb und nicht voll ist schreibt das Haupt-Relais 103 die Nachricht in die Protokolldatei 109 (Schritt 405). Das Haupt-Relais 103 schreibt dann den Datensatz-Zustand in die Protokolldatei 109 und stellt ihn auf "sent (gesendet)" (Schritt 406). Das Haupt-Relais 103 schreibt dann die Datensatz-Index-Information in die Datensatz-Tabelle (Schritt 407). Das Haupt-Relais 103 leitet die Nachricht dann über die TCP/IP-Verbindung 134 an den Diskriminator 104 weiter (Schritt 408).
Diskriminator-Prozess: 5 ist ein Flussdiagramm des Diskriminator-Prozesses 104. Vom Standpunkt der TCP/IP-Verbindung arbeitet der Diskriminator 104 als Client für das Haupt-Relais 103 und für die Unter-Relais 105, 106. Wenn der Diskriminator 104 erstmals startet, liest er eine Konfigurationsdatei, die sich auf demselben Computer befindet wie der Diskriminator. Die Konfigurationsdatei enthält den Host-Namen, den Dienst-Namen und den Server-Typ jedes Servers, mit dem der Diskriminator eine Verbindung versuchen sollte. Der Server-Typ definiert, ob bezüglich des Diskriminators der Server "links" liegt (Haupt-Relais) oder ob er bezüglich des Diskriminators "rechts" liegt (Unter-Relais). Der Diskriminator versucht dann, Verbindungen zwischen dem Haupt-Relais 103 und den Unter-Relais 105, 106 aufzubauen, die in der Konfigurationsdatei spezifiziert sind. Nachdem die in der Konfigurationsdatei spezifizierten Verbindungen hergestellt wurden, wartet der Diskriminator 104 auf eine Nachricht, die vom Haupt-Relais 103 weitergeleitet werden soll.
Gemäß der beispielhaften Ausführung empfängt der Diskriminator 104 eine Nachricht vom Haupt-Relais 103 (Schritt 501). Als nächstes erhält der Diskriminator 104 Adressinformationen aus der empfangenen Nachricht, die den Host-Namen 210 und den Dienst-Namen 211 umfassen (Schritt 502). Der Diskriminator 104 vergleicht dann den Host-Namen 210 und den Netzwerk-Dienst-Namen 211 mit den Einträgen in der Konfigurationsdatei (Schritt 503).
Wenn der Diskriminator 104 keine Übereinstimmung findet, oder der Diskriminator 104 findet, dass das Ziel-Unter-Relais 105, 106 nicht läuft (z. B. abgeschaltet ist) (Schritt 504), verwirft der Diskriminator 104 die Nachricht (Schritt 506). Die verworfene Nachricht ist im Diskriminator verloren, aber anders als in dem Fall, wenn das Haupt-Relais eine Nachricht verwirft, ist die Nachricht im System nicht verloren, da sie in die Protokolldatei 109 des Haupt-Relais 103 geschrieben wurde.
Wenn eine Übereinstimmung gefunden wurde, leitet der Diskriminator 104 die Nachricht über eine TCP/IP-Schnittstelle 145, 146 zum Unter-Relais 105, 106 weiter (gekennzeichnet durch den Host-Namen und den Dienst-Namen) (Schritt 505).
Wenn ein Unter-Relais 105, 106 abgeschaltet wird (als Folge einer normalen Abschaltung oder eines Unter-Relais-Ausfalls), akzeptiert es keine TCP/IP-Verbindungen, bis es wieder initialisiert werden kann. Wenn das Unter-Relais 105, 106 neu initialisiert wird, wird der Diskriminator 104 neu initialisiert, um die Unter-Relais-Verbindung wieder aufzubauen. Wenn der Diskriminator 104 neu initialisiert wird, sendet er eine Nachricht an das Haupt-Relais 103 und fordert es auf, alle Nachrichten, die in der Protokolldatei als "gesendet" markiert sind, für die aber keine Quittungsnachricht empfangen wurde, erneut zum Diskriminator 104 zu senden.
Unter-Relais-Prozess: Betrachtet man nun das Flussdiagramm in 6, wird ein Beispiel für einen Unter-Relais-Prozess 105 gezeigt (derselbe Prozess wird auch von jedem der anderen Unter-Relais des Systems ausgeführt). Wie oben beschrieben, führt jedes der Unter-Relais 105, 106 ähnliche Funktionen aus, wie das Haupt-Relais 103. Demgemäß enthält in der beispielhaften Ausführung der vorliegenden Erfindung jedes der Unter-Relais 105, 106 im wesentlichen die selbe Software wie das Haupt-Relais 103. Wie das Haupt-Relais 103 ist jedes der Unter-Relais 105, 106 ein Multi-Thread-Prozess. Demgemäß hat jedes Unter-Relais 105, 106 einen LogMgr, einen Mgr, eine Datensatz-Tabelle, und nutzt ein Semaphor zur Synchronisation der Benutzung der entsprechenden Protokolldatei 110, 111 jedes Threads.
Betrachtet man nun das Flussdiagramm in 6, empfängt Unter-Relais 105 eine Nachricht vom Diskriminator 104 (Schritt 601). Das Unter-Relais 105 testet das mit der Protokolldatei 110 verbundenen Semaphor, um festzustellen, ob die Protokolldatei 110 verfügbar ist (Schritt 602). Wenn die Protokolldatei 110 in Betrieb ist, wartet das Unter-Relais, bis die Protokolldatei 110 verfügbar wird. Das Unter-Relais 105 testet, ob die Protokolldatei 110 voll ist (Schritt 603). Wenn die Protokolldatei 110 voll ist, verwirft das Unter-Relais 105 die Nachricht (609) und sendet einen Problembericht als Information an den System-Manager (610).
Wenn die Protokolldatei 110 verfügbar ist, schreibt das Unter-Relais 105 die Nachricht in die Protokolldatei 110 (Schritt 604). Das Unter-Relais 105 schreibt dann den Datensatz-Zustand in die Protokolldatei 110 und stellt ihn auf "sent (gesendet)" (Schritt 605). Das Unter-Relais 105 schreibt dann die Datensatz-Index-Information in die Datensatz-Tabelle (Schritt 606). Das Unter-Relais 105 sendet dann über den Diskriminator 104 eine Quittungsnachricht an das Haupt-Relais 103 (Schritt 607). Das Unter-Relais 105 leitet die Nachricht dann an das dem Unter-Relais 105 zugeordnete Hersteller-Relais 106 weiter (Schritt 608).
Wenn das Hersteller-Relais 106 die Nachricht empfängt, verarbeitet die Hersteller-Anwendung, die dem Hersteller-Relais 106 zugeordnet ist, die Nachricht auf die vom Hersteller gewählte Weise.
Relais-Threads: In 7 sind die Threads dargestellt, die von einem Relais 700 erzeugt werden. Dieses Relais könnte ein Haupt-Relais oder ein Unter-Relais sein, da beide im Wesentlichen denselben Code enthalten und auf dieselbe Weise arbeiten. Das Relais 700 erzeugt einen Thread 701 für die linke Seite ("LHS"), einen Thread 702 für die rechte Seite ("RHS"), einen Archivierungs-Thread 703, einen Thread 704 zur Überprüfung, ob die Datei voll ist und einen Thread 705 zur Signalbehandlung. Da mehrere Threads verwendet werden, kann ein Relais mehrere Funktionen gleichzeitig durchführen.
Das Relais 700 erzeugt die Threads LHS und RHS 701 und 702, um mit den Prozessen zu kommunizieren, die an der linken, bzw. rechten Seite des Relais angeschlossen sind. Zum Beispiel kommuniziert der Thread LHS 701 des Haupt-Relais 103 mit dem SLP 102, während der Thread RHS 702 des Haupt-Relais 103 mit dem Diskriminator 104 kommuniziert. Entsprechend kommuniziert der Thread LHS 701 des Unter-Relais 105, 106 mit dem Diskriminator 104, während der Thread RHS 702 des Unter-Relais 105, 106 mit einem Hersteller-Relais 107, 108 kommuniziert.
Das Relais 700 erzeugt den Archivierungs-Thread 703, um mit einem Client zu kommunizieren, der die Archivierung von Datensätzen in einer Protokolldatei 109, 110 oder 111 anfordert. Dieser Thread wird erzeugt, wenn der Client eine Verbindungsanforderung an das Relais 700 sendet, wie unten beschrieben.
Das Relais 700 erzeugt auch den Thread 704 zur Überprüfung, ob die Datei voll ist, um festzustellen, ob die Protokolldatei über einen Schwellwert gefüllt ist und um eine Alarmnachricht zu senden, falls dies der Fall ist.
Zusätzlich dazu erzeugt das Relais 700 einen Thread 705 zur Signalbehandlung, der es ermöglicht, dass Multi-Thread-Prozesse mit mehreren Clients arbeiten, indem ein UNIX^®-Signal gesperrt wird, das andernfalls diese Funktion verhindern würde.
8 zeigt die Interaktion eines Relais 700 mit einem Client 803. Das Relais kann ein Haupt-Relais 103 oder ein Unter-Relais 105, 106 sein. Der Client kann zum Beispiel ein Archivierungsprozess sein. Als Antwort auf eine Verbindungsanforderung 809 von einem Client 803 erzeugt das Relais 700 (wenn der Client erkannt und die Verbindung akzeptiert wird) einen Thread 800 zur Kommunikation mit dem Client 803. Diese Thread-Client-Kommunikation 807 erfolgt über eine TCP/IP-Verbindung. Der Thread ist auch in der Lage, einen Verbindungsfehler 808 zu erkennen.
Der Client kann über den LogMgr 801 Informationsanforderungen an die Protokolldatei (in 8 nicht gezeigt) stellen. Der Client 803 kann über die Thread-Client-Kommunikation 807 eine Informationsanfrage-Nachricht an den Thread senden. Der Thread 800 sendet die Nachricht 805 dann an den LogMgr 801. Der LogMgr 801 bearbeitet dann die in der Nachricht enthaltene Anfrage und führt die angeforderte Protokolldatei-Funktion aus.
Das Objekt Mgr 802 überwacht 806 den Betrieb des Thread für das Relais 700.
9 zeigt den Betrieb eines Relais 700 in Kommunikation mit Clients im System. Weil das Relais 700 ein Multi-Thread-Prozess ist, können die in 9 gezeigten Funktionen unabhängig und gleichzeitig ausgeführt werden. Das Relais 700 dient als Server, der mit mehreren Clients verbunden ist, einschließlich eines Left Hand Side (LHS) 901 und eines Right Hand Side (RHS) 902.
Wenn der LHS 901 eine Nachricht 910 zum Relais 700 weiterleitet, sendet das Relais 700 eine Nachricht 911 "record acknowledgement (Datensatz-Quittung)" zurück zum LHS 901, wenn die Nachricht erfolgreich empfangen wurde.
Wenn das Relais 700 die Nachricht 913 zum RHS 902 weiterleitet, sendet der RHS 902 eine Nachricht 914 "record acknowledgement (Datensatz-Quittung)" zurück zum Relais 700, wenn die Nachricht erfolgreich empfangen wurde.
Der Takt 903 wird dazu benutzt, den Thread 704 "Check File Full (Überprüfung, ob die Datei voll)" zu benachrichtigen 906, einen Thread, der sich normalerweise in einem "Sleep"-Zustand befindet, aber regelmäßig "aufwacht", wenn dies vom Takt 903 signalisiert 916 wird, um die Verfügbarkeit der Protokolldatei 905 zu überprüfen.
Das Relais 700 verfügt über eine Protokolldatei 905, deren Verfügbarkeit dadurch bestimmt wird, wie voll die Protokolldatei 905 ist (d. h. welcher Prozentsatz gefüllt ist). Wenn die Protokolldatei 905 über eine Schwellwert-Kapazität gefüllt ist, sendet das Relais eine Nachricht "log file full (Protokolldatei voll)" 917 an den Informations-Problembericht-Prozess ("IPR") 904. Der IPR "löst einen Alarm aus", indem er die Nachricht "log file full (Protokolldatei voll)" über die HLR 101 an einen Wartungs-Bediener sendet.
Der Speicher der Protokolldatei 905 wird über eine Datenstruktur des Relais 700, die Datensatz-Tabelle genannt wird, für das Relais abgebildet (indiziert) 918. Dies ermöglicht es dem Relais 700, in der Protokolldatei 905 nach Nachrichten zu suchen und sie abzurufen.
Wenn der Archivierungsprozess-Client 907 eine Anforderung zur Archivierung von Datensätzen 927 oder eine Anforderung zum Kopieren von Datensätzen 922 sendet, liest der LogMgr des Relais 700 die angeforderten Datensätze (z. B. alle als "quittiert" oder "gesendet" markierten Datensätze) aus der Protokolldatei 905 und schreibt 919 sie in eine temporäre Datei 906. Der LogMgr sendet dann eine Archivierungs-Quittungs-Nachricht 926 oder eine Kopier-Quittungs-Nachricht 921 an den Archivierungs-Prozess 907. Der Archivierungsprozess 907 ruft dann die Daten aus der temporären Datei ab und sendet dann eine Nachricht "Archivierung beendet" 925 oder "Kopieren beendet" 920 an das Relais 700. Das Relais 700 löscht 919 dann die temporäre Datei 906.
Der Archivierungsprozess-Client 907 kann auch eine Anforderung zur Initialisierung von Datensätzen 923 senden. Der LogMgr löscht dann die gesamte Protokolldatei und sendet eine Initialisierungs-Quittungs-Nachricht 924 zurück.
10 zeigt die "Handshake"-Operationen der Relais-Client-Verbindungen. Jeder Client (zum Beispiel der LHS 901, der RHS 902 oder ein Archivierungsprozess 907) sendet eine Verbindungsanforderungs-Nachricht 1005, 1009, 1013 zum Relais 700. Die Verbindungsanforderungs-Nachricht 1005, 1009, 1013 enthält Informationen über den Typ des Client, der die Nachricht sendet. Das Relais 700 bestimmt den Typ des Client, der die Verbindung versucht, und akzeptiert die Verbindung, wenn er den Client erkennt, und es weist die Verbindung zurück, wenn es den Client-Typ nicht erkennt. Wenn das Relais 700 die Verbindung zurückweist, sendet es eine Nachricht "connection reject (Verbindung zurückgewiesen)" 1007, 1011, 1015 zum Client. Wenn das Relais 700 die Verbindung akzeptiert, senden LHS 901, RHS 902 oder der Archivierungsprozess 907 eine Nachricht "start up" 1006, 1010, 1014 zum Relais 700.
Wenn der LHS 901, der RHS 902 oder der Archivierungsprozess 907 mit dem Relais 700 verbunden sind, ist der Client in der Lage, Nachrichten vom Relais 700 zu senden oder von ihm zu empfangen und kann das Relais 700 auffordern, Dateien aus der Protokolldatei abzurufen, wie in den oben angegebenen Prozeduren beschrieben.

Claims

Ein Verfahren zum Weiterleiten einer Nachricht, das folgende Schritte umfasst: In einem zellularen Funk-Telekommunikationsnetz Empfangen (301) einer Nachricht, die eine Mobileinheit-Kennnummer (205) enthält; Feststellung, ob die Nachricht an eine entfernte Einheit (107, 108) außerhalb des zellularen Funk-Telekommunikationsnetzes weiterzuleiten ist; Wenn die Nachricht nicht weiterzuleiten ist, Verarbeiten (306) der Nachricht innerhalb des zellularen Funk-Telekommunikationsnetzes; und Wenn die Nachricht weiterzuleiten ist, Weiterleiten (305) der Nachricht an die entfernte Einheit, welche die Nachricht verarbeitet, dadurch gekennzeichnet, dass der Feststellungs-Schritt die Schritte des Absuchens (303) einer Datenbank (101) nach der in der Nachricht enthaltenen Mobileinheit-Kennnummer umfasst, wobei die Datenbank eine Vielzahl von Mobileinheit-Kennnummern enthält, und wobei mindestens eine aus der Vielzahl der Mobileinheit-Kennnummern einer entsprechenden entfernten Einheit (107, 108) außerhalb des zellularen Funk-Telekommunikationsnetzes zugeordnet ist, und wobei die Nachricht nach außerhalb des zellularen Funk-Telekommunikationsnetzes weitergeleitet wird, wenn die in der Nachricht enthaltene Mobileinheit-Kennnummer in der Datenbank der entfernten Einheit zugeordnet ist.
Das Verfahren aus Anspruch 1, worin der Feststellungs-Schritt weiterhin einen Schritt der Neuformulierung (304) der Nachricht in eine Nachricht für eine entfernte Anwendung (200) umfasst, wobei die in der Nachricht enthaltene Information und die in der Datenbank gespeicherte Information benutzt wird und die spezifisch für die entfernte Einheit ist.
Das Verfahren aus Anspruch 1 oder 2, worin der Weiterleitungs-Schritt folgende Schritte umfasst: Weiterleiten (305) der Nachricht für die entfernte Anwendung an einen ersten Prozess (103); Weiterleiten (408) der Nachricht für die entfernte Anwendung von dem ersten Prozess an einen zweiten Prozess (104), wobei der zweite Prozess einen aus einer Vielzahl von dritten Prozessen (105) auswählt (502), und wobei der zweite Prozess die Nachricht für die entfernte Anwendung an den gewählten dritten Prozess weiterleitet (505); und Im gewählten dritten Prozess (105) Weiterleiten (608) der Nachricht für die entfernte Anwendung an die entfernte Einheit (106).
Das Verfahren aus Anspruch 3, worin der erste Prozess (103) die Nachricht für die entfernte Anwendung (200) in einer ersten Protokolldatei (109) protokolliert (405).
Das Verfahren aus Anspruch 3 oder 4, worin der gewählte dritte Prozess (105, 106) die Nachricht für die entfernte Anwendung (200) in einer entsprechenden zweiten Protokolldatei (110, 111) protokolliert (604).
Das Verfahren aus einem beliebigen der Ansprüche 3 bis 5, worin die Vielzahl dritter Prozesse (105, 106) mindestens einen Unter-Relais-Prozess enthält.
Das Verfahren aus einem beliebigen der Ansprüche 3 bis 6, worin die Auswahl eines aus der Vielzahl dritter Prozesse (105, 106) als Funktion der entfernten Einheit (107, 108) ausgeführt wird.
Das Verfahren aus einem beliebigen der Ansprüche 3 bis 7, das weiterhin den Schritt der Archivierung (907) der protokollierten Nachricht für die entfernte Anwendung (200) umfasst.
Das Verfahren aus einem beliebigen der Ansprüche 3 bis 8, worin die Nachricht für die entfernte Anwendung (200) ein Host-Namen-Feld (210) und ein Dienst-Namen-Feld (211) enthält, die aus der Datenbank (101) gelesen und zur Bestimmung verwendet werden, an welchen dritten Prozess die Nachricht für die entfernte Anwendung weitergeleitet werden muss.
Das Verfahren aus einem beliebigen der Ansprüche 3 bis 9, worin jeder dritte Prozess (105, 106) einer entfernten Einheit (107, 108) zugeordnet ist.
Das Verfahren aus einem beliebigen der Ansprüche 1 bis 10, worin die Nachricht eine Nachricht zur Fernsteuerung von Funktionen ist.
Ein System zum Weiterleiten einer Nachricht, die eine entsprechende Mobileinheit-Kennnummer enthält, das folgendes umfasst: Eine Heimatdatei (101), die sich in einem zellularen Funk-Telekommunikationsnetz befindet und Mittel enthält, um eine Nachricht zu empfangen, sowie eine Datenbank umfasst, die eine Vielzahl von Mobileinheit-Kennnummern enthält; dadurch gekennzeichnet, dass die Datenbank mindestens eine aus der Vielzahl von Mobileinheit-Kennnummern einer entsprechenden entfernten Einheit zuordnet, die sich außerhalb des zellularen Funk-Telekommunikationsnetz befindet, und das System weiterhin folgendes umfasst: Ein Haupt-Relais (103), das mit der Heimatdatei (101) gekoppelt ist, wobei die Heimatdatei Mittel zum Senden der Nachricht an das Haupt-Relais umfasst, wenn eine entsprechende Mobileinheit-Kennnummer zu mindestens einer aus der Vielzahl der Mobileinheit-Kennnummern in der Datenbank passt und wenn die Mobileinheit-Kennnummer einer entfernten Einheit (107, 108) in der Datenbank zugeordnet ist; Einen Diskriminator (104), der mit dem Haupt-Relais gekoppelt ist, wobei das Haupt-Relais Mittel zum Senden der Nachricht an den Diskriminator umfasst; und Eine Vielzahl von Unter-Relais (105, 106), die an den Diskriminator gekoppelt sind, wobei der Diskriminator Mittel zum Senden der Nachricht an ein ausgewähltes der Vielzahl von Unter-Relais umfasst, wobei das gewählte Unter-Relais einer entfernten Einheit (107, 108) zugeordnet ist und wobei das ausgewählte Unter-Relais Mittel zum Senden der Nachricht an die entfernte Einheit umfasst.
Das System aus Anspruch 12, worin das Haupt-Relais (103) eine erste Protokolldatei (109) und Mittel zur Protokollierung der Nachricht in der ersten Protokolldatei enthält.
Das System aus Anspruch 12 oder 13, worin das gewählte Unter-Relais (105, 106) eine entsprechende zweite Protokolldatei (110, 111) und Mittel zur Protokollierung der Nachricht in der zweiten Protokolldatei enthält.
Das System aus einem beliebigen der Ansprüche 12 bis 14, worin die Heimatdatei (101) weiterhin ein Dienstlogik-Programm (102) enthält, um zu bestimmen, ob die in der Nachricht enthaltene Mobileinheit-Kennnummer zu mindestens einer aus der Vielzahl der Mobileinheit-Kennnummern in der Datenbank passt und ob die in der Nachricht enthaltene Mobileinheit-Kennnummer einer entfernten Einheit in der Datenbank zugeordnet ist.
Das System aus Anspruch 15, worin das Dienstlogik-Programm (102) eine Vielzahl von dienstunabhängigen Bausteinen enthält.
Das System aus Anspruch 15 oder 16, worin das Dienstlogik-Programm (102) weiterhin Mittel zur Neuformulierung der Nachricht in eine Nachricht für eine entfernte Anwendung (200) umfasst, wobei die in der Nachricht enthaltene Information und die in der Datenbank gespeicherte Information benutzt wird und die spezifisch für die entfernte Einheit ist, wobei das Dienstlogik-Programm die Nachricht in die Nachricht für eine entfernte Anwendung umformuliert, bevor die Nachricht für die entfernte Anwendung an das Haupt-Relais weitergeleitet wird.
Das System aus einem beliebigen der Ansprüche 12 bis 17, worin die Nachricht eine Nachricht zur Fernsteuerung von Funktionen ist.