-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft allgemein das Überwachen von Datennachrichten
in einem Kommunikationsnetzwerk. Ein bevorzugtes Anwendungsgebiet
für die
Erfindung ist ein Netzwerkelement in einem intelligenten Netzwerk
wie einem SCP-Netzwerkelement, aber die erfindungsgemäße Lösung kann
in allen Netzwerkelementen angewendet werden, bei denen Nachrichten
einer gegebenen Protokollebene zu überwachen sind, um beispielsweise
ihre Gültigkeit
zu verifizieren. Nachfolgend wird die Erfindung anhand eines als
Beispiel dienenden intelligenten Netzwerks beschrieben, weil die
Erfindung im Großen
und Ganzen im Hinblick auf die mit intelligenten Netzwerken zusammenhängenden Probleme
geschaffen wurde.
-
Hintergrund der Erfindung
-
Aufgrund
der rapiden Fortschritte auf dem Gebiet der Telekommunikation sind
Betreiber jetzt in der Lage, den Nutzern einen großen Dienstleistungsbereich
anzubieten. Eine Netzwerkarchitektur, die fortschrittliche Dienstleistungen
bereitstellt, wird als Intelligentes Netzwerk, kurz IN, bezeichnet.
-
Die
funktionale Architektur des intelligenten Netzwerks ist in 1 dargestellt,
wobei die Funktionsentitäten
des Netzwerks als Ovale angegeben sind. Nachfolgend wird diese Architektur
kurz beschrieben, weil die Erfindung später unter Hinweis auf die intelligente
Netzwerkumgebung erläutert
wird.
-
Der
Zugriff des Endnutzers (Teilnehmers) auf das Netzwerk wird durch
die Anrufsteuerungsagentenfunktion CCAF gesteuert (Call Control
Agent Function). Der Zugriff zu IN-Dienstleistungen wird ermöglicht,
indem den existierenden digitalen Vermittlungsstellen Zusätze hinzugefügt werden.
Das wird erreicht durch die Anwendung des Basisanrufzustandsmodells
BCSM (Basic Call State Model), das die vorhandene Funktionalität beschreibt,
die für
die Verarbeitung eines Anrufs zwischen Nutzern angewendet wird.
BCSM ist ein Automationsmodell auf hoher Ebene für die CCF-Anrufsteuerungsfunktionen,
die zum Aufbauen und Aufrechterhalten des Verbindungspfades zwischen
den Nutzern erforderlich ist. Diesem Zustandsmodell wird Funktionalität dadurch
hinzugefügt,
dass die Dienstleistungsschaltfunktion SSF (Service Switching Function)
angewendet wird (siehe die teilweise Überlappung der Funktionsentitäten CCF
und SSF in 1), um entscheiden zu können, wann
intelligente Netzwerksdienstleistungen (IN-Dienstleistungen) aufgerufen werden sollten.
Sind diese IN-Dienstleistungen einmal aufgerufen, führt die
Dienstleistungssteuerungsfunktion SCF (Service Control Function),
die die Dienstleistungslogik für
das intelligente Netzwerk enthält,
die dienstleistungsabhängige
Verarbeitung (des Anrufversuchs) durch. Die Dienstleistungsschaltungsfunktion
SSF (Service Switching Function) verbindet also die Rufsteuerungsfunktion
CCF (Call Control Function) mit der Dienstleistungssteuerungsfunktion SCF
(Service Control Function) und ermöglicht es der SCF, die Rufsteuerungsfunktion
CCF zu steuern. Beispielsweise kann SCF SSF/CCF auffordern, bestimmte
Ruf- oder Aufbaufunktionen durchzuführen wie Abrechnungs- oder
Routingvorgänge.
SCF kann ebenfalls Anforderungen an die Dienstleistungsdatenfunktion
SDF (Service Data Function) senden, die den Zugriff auf die dienstleistungsabhängigen Informationen
des intelligenten Netzwerks und die Netzwerkdaten steuert. Zum Beispiel
kann die SCF die SDF bitten, Daten bereitzustellen, die mit einer
bestimmten Dienstleistung in Beziehung stehen, oder solche Daten
zu aktualisieren.
-
Die
oben beschriebenen Funktionen werden weiter durch die Funktion der
spezialisierten Ressourcen SRF (specialized resources function)
ergänzt,
welche die speziellen Funktionen bereitstellt, die zur Implementierung
einiger der vom intelligenten Netzwerk gebotenen Dienstleistungen
erforderlich sind. Beispiele solche Dienstleistungen sind Protokollkonversionen,
Spracherkennung, stimmhafte Nachrichten usw. Beispielsweise kann
die SCF die SSF/CCF-Funktionen anfordern, um zuerst eine Verbindung
zwischen den Endnutzern und SRF herzustellen, und dann SRF beauftragen,
den Endnutzern Ankündigungen
vorzuspielen.
-
Andere
Funktionsentitäten
eines intelligenten Netzwerks sind die verschiedenen, mit der Steuerung
zusammenhängenden
Funktionen wie die Dienstleistungserzeugungs-Umgebungsfunktion SCEF
(Service Creation Environment Function), die Dienstleistungsverwaltungsfunktion
SMF (Service Management Function) und die Dienstleistungsverwaltungs-Zugangsfunktion
SMAF (Service Management Access Function). Die SMF enthält unter
anderem Dienstleistungssteuerung, während die SMAF für SMF eine
Schnittstelle bietet, und die SCEF ermöglicht die Definition, Entwicklung, Überprüfung und
Zuführung
der IN-Dienstleistungen
an der SCF über
die SMF. Da diese Funktionen sich allein auf die Funktionen des
Netzwerkbetreibers beziehen, sind sie in 1 nicht
gezeigt.
-
Die
Rolle der in 1 gezeigten Funktionsentitäten für die IN-Dienstleistungen
wird nachfolgend kurz erläutert.
Die CCAF empfängt
die Dienstleistungsanforderung von der anrufenden Partei, die üblicherweise
aus dem Abheben des Hörers und/oder
einer spezifischen Reihe von Zahlen besteht, die von der anrufenden
Partei gewählt
wird. Die CCAF gibt die Dienstleistungsanforderung an die CCF/SSF
zur weiteren Verarbeitung weiter. Die Anrufsteuerungsfunktion CCF
(Call Control Function) besitzt keine Dienstleistungsdaten, ist
aber so programmiert, dass sie die Notwendigkeit einer Dienstleistungsanforderung
erkennt. Die CCF unterbricht für
einen Moment den Aufbauvorgang für
den Anruf, um der Dienstleistungsschaltfunktion SSF (Service Switching
Function) den Zustand des Anrufs anzuzeigen. Es ist dann die Aufgabe
der SSF, unter Verwendung eines Satzes vordefinierter Kriterien,
die Dienstleistungsanforderung zu interpretieren und damit zu bestimmen,
ob sie sich auf Dienstleistungen bezieht, die von dem intelligenten
Netzwerk bereitgestellt werden. Ist das der Fall, dann generiert
SSF eine standardisierte IN-Dienstleistungsanforderung und sendet
sie zusammen mit den Informationen über den Zustand der Dienstleistungsanforderung
an die SCF. Die SCF empfängt
die Anforderung und decodiert sie. Danach kooperiert die SCF mit
der SSF/CCF, der SRF und der SDF, um dem Endnutzer die angeforderte
Dienstleistung zur Verfügung
zu stellen.
-
Die
Architektur der physikalischen Ebene eines intelligenten Netzwerks
zeigt, wie die oben beschriebenen Funktionsentitäten auf die physikalischen
Entitäten
des Netzwerks verteilt sind. Die physikalische Architektur eines
intelligenten Netzwerks ist in 2 dargestellt,
wo die physikalischen Entitäten
als Rechtecke oder Kreise und die Funktionsentitäten als Ovale dargestellt sind.
Signalisierungsverbindungen sind durch gestrichelte Linien und der
tatsächliche
Transport, beispielsweise Sprache, ist durch durchgezogene Linien
dargestellt. Optionale Funktionsentitäten sind durch gestrichelte
Linien angezeigt. Bei dem in der Fig. dargestellten Signalisierungsnetzwerk
handelt es sich um ein SS7-Netzwerk (SS7, Signaling System Number
7, ist ein bekanntes Signalisierungssystem, das im CCITT (derzeit
ITU-T) Blaubuch „Specifications
of Signaling System No 7, Melbourne 1988, beschrieben ist).
-
Teilnehmereinrichtungen
SE, die beispielsweise ein Telefon, einen Computer oder eine Fax-Maschine
enthalten können,
sind entweder direkt mit dem Dienstleistungsschaltungspunkt SSP (Service
Switching Point) oder dem Netzwerkzugriffspunkt NAP (Network Access
Pont) verbunden.
-
Der
Dienstleistungsschaltungspunkt SSP bietet dem Nutzer Zugriff zum
Netzwerk und führt
alle notwendigen Auswahlfunktionen durch. SSP ist ebenfalls in der
Lage, Anforderungen für
intelligente Netzwerkdienstleistungen zu erkennen. Von der Funktion
her umfasst der SSP die Rufsteuerungs- und Dienstleistungsauswahlfunktionen.
-
Bei
dem Netzwerkzugriffpunkt NAP handelt es sich um eine konventionelle
Telefonvermittlungseinrichtung wie der DX 220 Vermittlungseinrichtung des
Anmelders, die die Rufsteuerungsfunktion CCF umfasst und die in
der Lage ist, zwischen konventionellen Anrufen und solchen Anrufen
zu unterscheiden, die IN-Dienstleistungen
erfordern, und die IN-Dienstleistungsrufe an den geeigneten SSP
zu routen.
-
Zu
dem Dienstleistungssteuerungspunkt SCP gehören die Dienstleistungslogikprogramme SLP,
die zum Generieren der intelligenten Netzwerkdienstleistungen benutzt
werden. Der Kürze
halber können
die SLPs nachfolgend auch als Dienstleistungsprogramme bezeichnet
werden.
-
Der
Dienstleistungsdatenpunkt (Service Data Point) ist eine Datenbank,
die Informationen über
Kunden und das Netzwerk enthält,
das die Dienstleistungsprogramme des SCPs für das Generieren personalisierter
Dienstleistungen nutzen. SCP kann die Dienstleistungen des SDP über das
Signalisier- oder Datennetzwerk direkt nutzen.
-
Eine
Intelligente Peripherievorrichtung bietet Spezialfunktionen wie
Ansagen und Sprach- und Mehrfachauswahlerkennung.
-
Der
Dienstleistungsschalt- und Dienstleistungssteuerpunkt SSCP (Service
Switching and Control Point) besteht aus dem SCP und dem SSP, die
in einem einzigen Netzwerkelement angeordnet sind (was bedeutet,
dass, wenn das in der Figur gezeigte SSP-Netzwerkelement sowohl
die SCF- als auch die SSF-Entitäten enthält, es sich
um eine SSCP-Einheit handelt).
-
Die
Aufgabe des Dienstleistungsverwaltungssystems SMP (Service Management
System) ist die Verwaltung des Dienstleistungsdatenpunktes SDP,
das Steuern und Testen des Netzwerks und das Sammeln von Netzwerkdaten.
SMP kann eine Verbindung mit jeder anderen physikalischen Entität eingehen.
-
Der
Dienstleistungserzeugungs-Umgebungspunkt SCEP (Service Creation
Environment Point) wird zur Definition, Entwicklung und Überprüfung der
Dienstleistungen des intelligenten Netzwerks und zum Einführen der
Dienstleistungen in SMP benutzt.
-
Der
beigeordnete Zusatz AD entspricht dem Dienstleistungssteuerungspunkt
SCP hinsichtlich seiner Funktion, ist jedoch direkt mit dem SSP über eine
schnelle Datenverbindung (wie die ISDN 30B+D-Verbindung) anstelle
einer Verbindung über das
allgemeine Kanalsignalisierungsnetzwerk SS Nr. 7 verbunden.
-
Der
Dienstleistungsknoten SN (Service Node) ist dazu ausgestaltet, IN-Dienstleistungen
zu steuern und Datenübermittlungen
mit Nutzern durchzuführen.
Er kommuniziert direkt mit einem oder mehreren SSPs.
-
Der
Dienstleistungsverwaltungszugriffpunkt SMAP (Service Management
Access Point) ist eine physikalische Entität, die für bestimmte Nutzer Zugriff zum
SMP bietet.
-
Das
SCP-Netzwerkelement kann auch von einem getrennten Assistenz-SCP
begleitet sein. Diese Art von Assistenz-SCP-Netzwerkelement kann vom
Dienstleistungsanbieter in der Weise betrieben werden, dass es teilnehmerspezifische Nummernübersetzungen
oder eine Routing-Logik unterstützt, die
dem SCP-Netzwerkelement
des Netzwerkbetreibers angeboten werden, um die dort vorhandenen Steuerdaten
zu ergänzen.
-
Das
oben Beschriebene liefert eine kurze Beschreibung eines intelligenten
Netzwerks als Hintergrund für
das Verfahren gemäß der vorliegenden Erfindung.
Ein interessierter Leser findet weitere Informationen über intelligente
Netzwerke in ITU-T Q.121X-Spezifikationen oder in Bellcores AIN-Spezifikationen.
-
Beispielsweise
benutzt das System den Intelligent Network Application Part INAP
Nachrichtensatz zwischen dem SSP und dem SCP. (Dieser Nachrichtensatz
wird beispielsweise in dem Standard ETSI IN 051 INAP Teil 1: Protokollspezifikation, Entwurf
prETS 300 374-1, November 1993, beschrieben, wo ein interessierter
Leser weitere Hintergrundinformationen finden kann). Im SS7-Protokollstapel, wie
er in 3 dargestellt ist, ist INAP die höchste Schicht,
gefolgt von dem Transaction-Capabilities-Application-Teil TCAP,
dem Signalisierungsverbindungssteuerungspunkt SCCP und dem Nachrichtenübermittlungsteil
MTP. Auf die Weise ist die Struktur so geschichtet, dass eine höhere Schicht
die Dienstleistungen, die von der direkt unter ihr angeordneten
Schicht bereitgestellt werden, nutzt. Die INAP-Schicht stellt die
Schnittstelle für
IN-Dienstleistungen bereit.
-
Die
Standards spezifizieren nicht die zwischen SSP und SCP zu verwendenden
tatsächlichen Protokolle,
sondern nur die INAP-Nachrichten, von denen einige für eine Übertragung
in eine Richtung und andere für
die Übertragung
in die andere Richtung benutzt werden. Feststehende und wahlweise anzuwendende
Parameter sowie „Ausweitungsparameter" sind für die Nachrichten
definiert. So können individuelle
Dienstleistungslogikprogramme die in demselben INAP-Nachrichtensatz
enthaltenen Nachrichten verwenden, jedoch in unterschiedlicher Reihenfolge
und mit unterschiedlichen Parameterwerten. Daraus folgt, dass es
die individuellen Dienstleistungslogikprogramme sind, die als die
tatsächlichen Protokollschichten
in den Kommunikationen zwischen dem SSP und dem SCP dienen. Jedes
Dienstleistungslogikprogramm sendet INAP-Nachrichten an das Netzwerk
und empfängt
INAP-Nachrichten vom Netzwerk.
-
Für die Definition
all dieser INAP-Nachrichten wurde die ASN.1-Definitionssprache benutzt. ASN.1
(Abstract Syntax Notation 1) ist eine Beschreibungssprache, die
auf dem Gebiet der Telekommunikation allgemein zur Definition und
Codierung von Datenstrukturen verwendet wird.
-
Um
einen korrekten Betrieb des Systems sicherzustellen, muss sowohl
der ankommende als auch der abgehende Nachrichtenverkehr überwacht werden,
wenn das Netzwerkelement in Betrieb genommen wird, oder sogar noch
früher.
Außerdem
ist der Betreiber möglicherweise
daran interessiert, Nachrichten zu überwachen, während das
Netzwerkelement in Betrieb ist. Besonders wichtig ist die Überwachung
von INAP-Nachrichten für
das SCP-Netzwerkelement, weil INAP das Protokoll ist, das Zugriff auf
intelligente Netzwerkdienstleistungen bietet.
-
Um
es der für
die Überwachung
verantwortlichen Person zu ermöglichen,
die Nachrichtenstruktur tatsächlich
zu überprüfen, müssen die
Nachrichten in ihrem Standardformat dargestellt werden können, das
tatsächlich
das ASN.1-Format ist. Üblicherweise wird
diese Überwachung
ausgeführt,
wenn die Nachricht der betreffenden Protokollschicht sowieso für andere
Zwecke bearbeitet wird. Beispielsweise sind INAP-Nachrichten üblicherweise
in Verbindung mit Dienstleistungslogikprogrammen überwacht
worden, weil diese Programme im SCP-Netzwerkelement die „Orte" erzeugen, wo die
INAP-Nachrichten sowieso bearbeitet werden, und wo es möglich ist,
auf die INAP-Nachrichten an sich (im ASN.1-Format) zuzugreifen. Um es anders auszudrücken, das Überwachen von
Nachrichten wird traditionell in Verbindung mit Programmblöcken durchgeführt, die
die genannten Nachrichten sowieso bearbeitet hätten.
-
Der
Nachteil dieser Art von Lösung
ist jedoch, dass die Überwachung
die „nützlichen
Prozesse" wie Dienstleistungsprogramme
immer komplizierter werden lassen. Außerdem müssen dann, wenn für Überwachungszwecke
Modifikationen vorgenommen werden müssen, die Veränderungen
an allen Dienstleistungsprogrammen durchgeführt werden. Das ist eine Beeinträchtigung
der Zuverlässigkeit
von Dienstleistungsprogrammen, weil die Dienstleistungsprogramme
in Verbindung mit jeder dieser Modifikationen bearbeitet werden
müssen.
-
Es
ist denkbar, dass alternativ die Nachrichten der ausgewählten Protokollschichten
unter Benutzung von Nachrichten mit einer niedrigeren Protokollschicht überwacht
werden; beispielsweise könnten
INAP-Nachrichten bereits auf einer niedrigeren Schicht (TCAP) überwacht
werden. Das ist jedoch häufig
kompliziert. Beispielsweise sind die TCAP-Nachrichten vom Netzwerk
BER-codiert (BER: Basic Encoding Rules), so dass eine Prüfung einer
solchen Bit-Folge nach der korrekten INAP-Nachrichtenstruktur äußerst kompliziert
ist.
-
EP 782311 A2 beschreibt
ein Verfahren zum Überwachen
des Signalisierungsnetzwerks in einem Telekommunikationssystem durch
Ausweiten einer Kopie jeder Signalisierungsnachricht, die von einem besonderen
Signaltransferpunkt einer Schnittstelleneinheit verarbeitet wird.
Die Schnittstelleneinheit leitet Nachrichten, die „von Interesse" sind, an ein Signalüberwachungssystem
entsprechend einem vorbestimmten Filterprotokoll weiter. Im Signalüberwachungssystem
werden Nachrichten entsprechend einem vordefinierten Korrelationsprotokoll
zugeordnet. Die korrelierten Signalisierungsnachrichten werden in
der Folge durch einen OSS-Techniker zur Analyse und Aktualisierung
zurückgeholt.
-
US 5802146 A beschreibt
eine Anordnung zum Überwachen
von Betriebsvorgängen
fortschrittlicher intelligenter Netzwerkelemente eines öffentlichen
Telefonschaltnetzwerks durch den Transport standardisierter Netzwerkverwaltungsnachrichten über ein
Datennetzwerk.
-
Zusammenfassung der Erfindung
-
Zweck
der vorliegenden Erfindung ist die Beseitigung der genannten Nachteile
und das Bereitstellen einer Lösung,
die das effiziente Überwachen der
Gültigkeit
von Nachrichten ermöglicht,
und zwar auf eine Weise, die die Durchführung vereinfacht.
-
Dieses
Ziel wird mit der Anwendung einer Lösung erreicht, die der Erfindung
entspricht, wie sie in den unabhängigen
Patentansprüchen
definiert ist.
-
Die
Idee der Erfindung ist die vollständige Trennung der sich auf
die Nachrichtenüberwachung beziehenden
Funktionalität
von den die Nachricht bearbeiten den verwendbaren Programmen, indem
parallel zu diesen verwendbaren Programmblöcken ein zentralisierter Programmblock
zum Überwachen
der Nachrichten geschaffen wird. Dieser Programmblock empfängt eine
Kopie der zu überwachenden
Nachricht, die von dem Netzwerk empfangen oder gesendet wurde.
-
Bei
Anwendung der Lösung
gemäß der Erfindung
ist es nicht mehr notwendig, Dienstleistungslogikprogramme zu ändern, wenn
einem Netzwerkelement (oder einer ähnlichen Entität) die Überwachungsfunktion
hinzugefügt
oder die bestehende Überwachungsfunktion
verändert
werden soll. Daraus folgt, dass es für einen Lieferanten von Netzwerkelementen
ohne Weiteres möglich
ist, die Überwachungsfunktionen
sogar in bestehende Netzwerkelemente zu integrieren. Da auf diese
Weise verwendbare Programme (wie Dienstleistungsprogramme) an der
tatsächlichen
Ausführung
der Überwachung
nicht teilnehmen, sind sie einfacher und in dieser Hinsicht präziser definiert,
was für
die Dienstleistungsanbieter von Bedeutung ist. Gleichzeitig verbessert
sich die Zuverlässigkeit
der Dienstleistung.
-
Kurzbeschreibung der Zeichnungen
-
Die
Erfindung und ihre bevorzugten Ausführungsformen werden unter Hinweis
auf die in den 4 bis 10 der
beigefügten
Zeichnungen gezeigten Beispiele detailliert beschrieben.
-
1 stellt
die funktionale Architektur eines intelligenten Netzwerks dar;
-
2 stellt
die physikalische Architektur eines intelligenten Netzwerks dar;
-
3 stellt
eine Signalisierungsverbindung zwischen dem SSP- und dem SCP-Netzwerkselement
dar;
-
4 stellt
die funktionale Architektur eines SCP-Netzwerkselements gemäß der Erfindung
hinsichtlich der für
die Software der Dienstleistungslogik wesentlichen Teile dar;
-
5 stellt
den Inhalt einer objektspezifischen Datenzeile dar;
-
6 zeigt
die Struktur der Dienstleistungs-Anforderungsnachricht, die an eine
Dienstleistungslogikinstanz gesendet wird;
-
7 zeigt
die Struktur der Bestätigungsnachricht,
die von einer Dienstleistungslogik-Programminstanz gesendet wird;
-
8 stellt
die Verarbeitung einer von dem Netzwerk empfangenen Nachricht durch
das Nachrichtenverteilungsprogramm das SCP-Netzwerkelement dar;
-
9 stellt
den Betrieb des Überwachungsprogramms
für eine
Nachricht dar; und
-
10 zeigt
ein Beispiel der Ausgabe des Überwachungsprogramms.
-
Detaillierte Beschreibung
der Erfindung
-
Wenn
ein Netzwerkteilnehmer einen Ruf initiiert, empfängt die Endvermittlungsstelle
des Teilnehmers zuerst die Information, dass der anrufende Teilnehmer
einen Ruf abgeben möchte.
Diese Information kann beispielsweise an der Vermittlungsstelle als
Aufbaunachricht entsprechend dem Standard Q.931 ankommen. Handelt
es sich bei der Endvermittlungsstelle nicht um eine SSP-Vermittlungsstelle, kann
sie die Rufanforderung an eine SSP-Vermittlungsstelle weiterleiten.
-
Wenn
die Rufkontrolle der SSP-Vermittlungsstelle feststellt, dass es
sich um einen Teilnehmer handelt, der IN-Dienstleistungen benötigt, wird die Übertragung
der Steuerung zum IN ausgelöst
und die Bearbeitung des versuchten Rufes wird „eingefroren". Die SSP-Vermittlungsstelle
sendet dann an den SCP eine Initial_DP-Nachricht, bei der es sich
um eine Standardnachricht zwischen der SSF und dem SCP handelt,
die von der SSF erzeugt wird, wenn an irgendeinem Erkennungspunkt
des Rufzustandsmodells festgestellt wird, dass eine Dienstleistungsanforderung
notwendig ist (ein Erkennungspunkt ist ein Punkt im Rufzustandsmodell,
bei dem die Steuerung an das IN übertragen
werden kann). Initial_DP ist damit die Nachricht, die den Dialog
zwischen dem SSP und dem SCP bezüglich
des Bereitstellens jeder Dienstleistung beginnt. Die in der Nachricht
von der SSP-Vermittlungsstelle enthaltenen Informationselemente
umfassen zumindest die rufende und die angerufene Nummer und einen
Dienstleistungsschlüssel.
-
4 stellt
die funktionale Architektur eines SCP-Netzwerkelements gemäß der Erfindung
dar, und zwar aus der Sicht der Dienstleistungsprogramme. Die am
Netzwerkelement ankommenden Dienstleistungsanforderungen kommen
durch einen gemeinsamen Kanalsignalisierungsstapel CCSS (s. 3)
zum empfangenden Programmblock SRP (SS7 Empfängerprogramm). Ein solcher
empfangender Programmblock steht für jeden gemeinsamen Kanalsignalisierungsstapel
des SCP-Netzwerkelements zur Verfügung. Der Einfachheit halber
zeigt das Beispiel der Fig. nur einen Stapel und einen empfangenden
Programmblock.
-
Wenn
ein SCP-Netzwerkelement mit mehr als einem SSP-Netzwerkelement verbunden
ist, in denen unterschiedliche Versionen des INAP-Nachrichtensatzes
verwendet werden, ist die Definition des Dateninhalts der von dem
SCP empfangenen Datennachrichten unterschiedlich, und zwar abhängig davon,
mit welchem SSP der SCP kommuniziert. Aus diesem Grund muss in der
Praxis die weitere Verarbeitung der Nachrichten vom empfangenden Programmblock
an entsprechend dem betreffenden INAP-Nachrichtensatz differenziert
werden. Andererseits ist der Empfangsprogrammblock SRP unabhängig von
dem verwendeten INAP-Nachrichtensatz.
-
Der
Empfangsprogrammblock SRP empfängt
vom Netzwerk (von SSF-Entitäten)
Standard-TC_BEGIN-Nachrichten. Es ist die Aufgabe des Programmblocks,
die relevante INAP-Nachrichtensatzversion auf der Basis der TC_BEGIN-Nachricht zu
identifizieren und die in den Komponentengrundelementen (primitives)
enthaltenen INAP-Nachrichten an den Nachrichtenverteiler-Programmblock
MDPi weiterzuleiten, der dem genannten Nachrichtensatz entspricht,
wobei i = 1, 2, ... j ist und j die Anzahl der verwendeten verschiedenen
INAP-Nachrichtensätze ist.
-
In
der dem Empfangsprogrammblock am nächsten liegenden Schicht enthält die Netzwerkarchitektur
also Programmblöcke
MDPi (i = 1, ... j), einen für
jeden verwendeten INAP-Nachrichtensatz. Jedes Verteilerprogramm
MDPi empfängt TCAP-Nachrichten
von dem Netzwerk und leitet INAP-Nachrichten weiter, empfängt INAP-Nachrichten von
den Dienstleistungslogikprogrammen und sendet TCAP-Nachrichten an
das Netzwerk. (Eine TCAP-Nachricht umfasst einen Header und ein
oder mehr Komponentengrundelemente. Jedes Komponentengrundelement
kann höchstens
eine INAP-Nachricht enthalten. Jedes Komponentengrundelement hat
ebenfalls einen eigenen Subheader. Alle diese Header-Teile werden
erzeugt, wenn Nachrichten an das Netzwerk gesendet werden, und sie
werden entfernt, wenn Nachrichten von dem Netzwerk empfangen werden.)
Wenn eine Initiationsanforderung für einen Dienstleistungsdialog – der als
ein TC_BEGIN-Grundelement ankommt (und eine Initial_DP-Nachricht
enthält) – von einem
Netzwerkelement empfangen wird, wird eine neue Instanz des Empfangsprogramms
SRP erzeugt, die den korrekten Verteilerprogrammblock durchsucht,
die eine Instanz daraus für
die Verwendung für
die genannte Dienstleistungsanforderung erzeugt und eine TCAP-Nachricht
an die genannte Instanz übermittelt. Danach
wird die Instanz des Empfangsprogrammblocks gelöscht. Die Verteilerprogramminstanz
empfängt
alle TCAP-Nachrichten, die danach vom SSP ankommen. Die Suche nach
dem richtigen Verteilerprogramm läuft so ab, dass der Empfangsprogrammblock
SRP aus dem Header der TC_BEGIN-Nachricht entweder den Identifizierer
des sendenden SSP-Netzwerkelements (SPC, Signalisierungspunktcode,
oder GT, Globaler Titel) ausliest und zusätzlich den Identifizierer des
Subsystems (SSN, SubSystem Nummer) oder alternativ den relevanten
Anwendungskontextidentifizierer AC und, auf der Basis dieser Information,
aus der Datentabelle SRP_DT der SRP-Schicht den Namen des Verteilerprogramms, MDP_NAME,
entsprechend des in Frage stehenden INAP-Nachrichtensatzes sucht.
-
Die
Architektur der SCP-Vermittlungsstelle enthält also für jeden INAP-Nachrichtensatz
einen zugeordneten Programmblock MDPi, dessen Aufgabe es ist, die
empfangenen Nachrichten zu decodieren (zumindest die Initial_DP-Nachricht,
die den Dienstleistungsschlüsselparameter
enthält)
und die Nachrichten in ihre korrekten Empfänger zu verteilen.
-
Zusätzlich enthält das Netzwerkelement
für jeden
Verteilerprogrammblock MDPi gemäß der Erfindung
einen Überwachungsprogrammblock
MPPi (i = 1, ... j) zur Überwachung
der Nachricht. Dieses Programm gibt den Inhalt der empfangenen INAP-Nachrichten
als Eingabe an die ausgewählten
Ausgabevorrichtungen wie Drucker oder Bildschirmanzeige.
-
Zur
Durchführung
der Überwachung
enthält das
SCP-Netzwerkelement auch die Datentabelle SU_DT, die die Anfangsparameter
enthält,
beispielsweise eine Zeile für
jedes Nachrichtenverteilerprogramm. Die Zeile kann zumindest Informationen
darüber
enthalten, ob eine Überwachung
durchzuführen ist
(TRACE-Feld), und den Namen des Überwachungsprogramms
(MPP_NAME), an das eine Kopie einer INAP-Nachricht zu senden ist,
wenn eine Überwachung
durchzuführen
ist. Diese Art von Datentabelle wird in der Phase der Inbetriebnahme
oder früher
erzeugt. Wird eine TCAP-Nachricht empfangen, weiß das die Nachricht empfangende
Nachrichtenverteilerprogramm bereits, ob eine Überwachung durchzuführen ist
oder nicht, und, wenn sie durchzuführen ist, kennt es bereit den
Namen des Überwachungsprogramms,
an das die Nachrichtenkopie zu senden ist. Der Betrieb der Verteiler-
und Überwachungsprogramme
wird später
in dieser Beschreibung detaillierter beschrieben.
-
In
der funktionalen Hierarchie des Netzwerkelements sind die Hauptprogrammblocke
nach den Verteilerprogrammen in der nächsten Hierarchieschicht angeordnet.
Diese Hauptprogrammblöcke
sind durch FMPi (Feature Manager Program: Funktionsverwaltungsprogramm)
bezeichnet. Die Hauptprogrammblöcke
stellen die Prozesse zur Steuerung der tatsächlichen Dienstleistungslogikprogramme
SLP zur Verfügung,
indem sie ihnen die benötigten
Daten zuführen.
Auf die Weise sind die Hauptprogrammblöcke für die Verwaltung der Dienstleistungen
und Funktionen verantwortlich. (Eine Sub-Dienstleistung, für die der
obige Ausdruck „Service
Feature" („Dienstleistungsfunktion") in den internationalen
Standards verwendet wird, wird auch in diesem Zusammenhang als „Funktion" bezeichnet. Eine
Dienstleistungsfunktion ist die (kleinste) Komponente, die für den Kunden
oder Teilnehmer erkennen lässt,
dass die von ihm/ihr erlangte Dienstleistung eingeschlossen ist).
-
Die
Nachrichtenverteilerprogramme leiten jede Dienstleistungsanforderung
an den richtigen Hauptprogrammblock. Um das zu ermöglichen,
ist eine zugeordnete Datentabelle MDP_DT für die Verteilerprogramme vorhanden,
in der der Dienstleistungsschlüsselwert
SK als Suchschlüssel
am Anfang jeder Datenzeile angegeben ist. Auf der Basis dieses Dienstleistungsschlüsselwerts,
der in der Initial_DP-Nachricht angekommen ist, sucht der Verteilerprogrammblock
aus der Datentabelle die richtige Zeile, in der er den Identifizierer
des Hauptprogrammblocks (FMP_NAME) findet, der im Fall des genannten
Dienstleistungsschlüsselwerts
als Empfänger
dient. Die Datentabelle ist vorzugsweise allen Verteilerprogrammblöcken MDPi
gemeinsam. Nachdem der richtige Hauptprogrammblock gefunden wurde,
erzeugt die Verteilerblockinstanz darauf eine Instanz, die für die genannte
Dienstleistungsanforderung zu benutzen ist, und übermittelt eine INAP-Nachricht an die
genannte Instanz.
-
Da
die Anforderungen an die Dienstleistungslogik für unterschiedliche Objektarten
unterschiedlich sind, ist es von Vorteil, das SCP-Netzwerkelement
auf eine Weise auszuführen,
dass es getrennte Hauptprogrammblöcke für in den SSP-Vermittlungen vorhandene,
logisch getrennte Hauptobjektklassen aufweist. Zu den genannten
Klassen können
die Klasse des rufenden Teilnehmers, die Klasse des angerufenen
Teilnehmers, Ziele (Anfang der gewählten Nummer), Unterziele (die
ganze gewählte Nummer),
Routen, Schaltkreisgruppen usw. gehören. Außerdem können die Teilnehmer entsprechend der
Zugehörigkeit
zu einem Netzwerk (zum Beispiel zu einem Festnetz oder einem Mobilnetzwerk)
in Klassen unterteilt sein. Objekte in diesem Zusammenhang bezeichnen
solche netzwerkrelevanten Entitäten,
denen Informationen in dem Netzwerkelement zugeordnet werden können – beispielsweise
im Falle eines intelligenten Netzwerks in einem SSP-Netzwerkelement – die für einen
individuellen Rufversuch angeben, ob eine Dienstleistungsanforderung
an das Dienstleistungen anbietende Netzwerkelement (was im Falle
eines intelligenten Netzwerk ein SCP-Netzwerkelement ist) gesendet
werden soll.
-
Wie
bereits angegeben wurde, nutzt jeder Verteilerprogrammblock den
Parameter des Dienstleistungsschlüssels, der in der Dienstleistungsanforderungsnachricht
ankam, um den empfangenden Hauptprogrammblock zu definieren. Das
bedeutet, dass für
Dienstleistungsanforderungen, die sich auf eine gegebene Hauptobjektklasse
beziehen (beispielsweise anrufende Teilnehmer), die SSP-Vermittlung einen
Dienstleistungsschlüsselwert
einzustellen hat, der sich von dem Dienstleistungsschlüsselwert von
Objekten unterscheidet, die zu einer anderen Klasse gehören (beispielsweise
angerufene Teilnehmer) (obwohl eine Dienstleistung derselben Art
betroffen ist). Es können
sehr unterschiedliche Dienstleistungsschlüsselwerte einem gegebenen Hauptprogrammblock
entsprechen, aber die Dienstleistungsschlüsselwertsätze, die sich auf zwei unterschiedliche
Hauptprogramme beziehen, dürfen
sich nicht überlappen.
-
Jede
Hauptobjektklasse hat eine zugeordnete Datentabelle FMPi_DT (i =
1, 2, ... n). Nachfolgend werden diese Datentabellen als Haupttabellen
bezeichnet. Das SCP-Netzwerkelement hat also eine zugeordnete Haupttabelle
für jeden
Hauptprogrammblock. Jede Haupttabelle hat eine Datenzeile für jedes
Objekt, das zu der genannten Klasse gehört. So hat zum Beispiel die
Datentabelle (FMP1_DT), die von dem Hauptprogrammblock FMP1 bezüglich anrufender
Teilnehmer benutzt wird, eine Datenzeile für jeden anrufenden Teilnehmer
Ai (i = 1, 2 ...), die Datentabelle (FMP2_DT), die vom Hauptprogramm FMP2
bezüglich
angerufener Teilnehmer benutzt wird, eine Datenzeile für jeden
angerufenen Teilnehmer Bi (i = 1, 2 ...), die Datentabelle, die
vom Hauptprogramm im Zusammenhang mit untergeordneten Zielobjekten
benutzt wird, eine Datenzeile für
jedes verwendete untergeordnete Ziel, die Datentabelle, die vom
Hauptprogramm hinsichtlich der Zielobjekte benutzt wird, eine Datenzeile
für jedes
zu benutzende Ziel, usw.
-
In
jeder Zeile der Haupttabellen sind Informationen auf die in 5 dargestellte
Weise gespeichert, die definieren, welche Art von Funktionssatz das
genannte Objekt aktiviert hat. Ein Objektidentifizierer Ol ist am
Anfang jeder Zeile R als Suchschlüssel gespeichert. Der Hauptprogrammblock
sucht die korrekte Zeile aus seiner Datentabelle anhand des Wertes
des in der INAP-Nachricht enthaltenen Objektidentifizierers aus.
Die Zeile enthält
aufeinanderfolgende untergeordnete Aufzeichnungen (subrecords) SR,
eine für
jede Funktion. Am Anfang jeder untergeordneten Aufzeichnung ist
ein Feld FK, das einen Funktionsschlüssel Fki enthält (i =
1, 2 ...), der angibt, um welche Funktion es sich handelt. Danach kann
die untergeordnete Aufzeichnung beispielsweise ein Statusfeld ST
enthalten, das Informationen darüber
enthält,
ob die genannte Funktion aktiv oder passiv ist, und ein Prioritätsfeld PR,
das eine Prioritätszahl
enthält.
Diese Prioritätszahlen
von untergeordneten Aufzeichnungen geben die relative Ordnung der
Ausführung
der Funktionen an. Jede untergeordnete Aufzeichnung enthält mindestens
das Feld SLP, das den Identifizierer des Dienstleistungslogikprogramms enthält, das
die genannte Funktion ausführt.
Die Dienstleistungslogikprogramme bilden die unterste Hierarchieschicht
des Netzwerkelements.
-
Es
sind vorzugsweise für
jede Hauptobjektklasse zugeordnete Dienstleistungsprogramme vorhanden.
Außerdem
ist ein Klon jedes Programms jedem INAP-Nachrichtensatz zugeordnet (d. h. jedem Verteilerprogramm).
In der Zeichnung sind die Dienstleistungsprogramme mit Bezugszeichen
SLPxy – z
bezeichnet, wobei x die Hauptobjektklasse bezeichnet, zu der das
Programm gehört,
y den INAP-Nachrichtensatz bezeichnet, zu dem das Programm gehört, und
z die laufende Nummer des Programms innerhalb der Hauptobjektklasse
angibt.
-
In Übereinstimmung
mit der Hierarchie des Netzwerkelements wird die Instanz (SLPi)
der untersten Schicht eines Dienstleistungsanforderungsdialogs als
Kind bezeichnet, die Instanz der nächsten Schicht (FMPi) als Vater
(parent) und die Instanz (MDPi) der dazu nächsten Schicht als Großvater (grandparent).
Eine ältere
Instanz erzeugt immer die jüngere
Instanz.
-
In
der Praxis kann zum Beispiel eine von einem Dienstleistungslogikprogramm
ausgeführte Funktion
das Abspielen einer Meldung an den Teilnehmer sein („spiele
eine Meldung ab")
oder ein Vorgang, mit dem der anrufende Teilnehmer aufgefordert
wird, zusätzliche
Zahlen zu wählen
(„veranlasse und
sammle Nutzerinformationen"),
oder ein Verbindungsvorgang (eine CONNECT-Nachricht wird an die
SSP-Vermittlungsstelle gesendet, mit dem die SSP-Vermittlungsstelle
aufgefordert wird, den Ruf mit einer gegebenen Adresse zu verbinden).
-
Die
Reihenfolge für
die Ausführung
der Funktionen kann beispielsweise auf die oben angegebene Weise
angezeigt sein, indem ein Prioritätsnummernfeld PR an die untergeordneten
Aufzeichnungen angefügt
wird, in welchem Fall die genannten Nummern die relative Reihenfolge
für die
Durchführung
der Funktionen angeben. Es sind auch andere Möglichkeiten zum Erreichen der
korrekten Reihenfolge bei der Ausführung möglich. Diese Weise ist jedoch
einfach und ermöglicht
es, dass derselbe Dienstleistungsschlüsselwert eine unterschiedliche Reihenfolge
für die
Ausführung
anzeigt, beispielsweise für
zwei unterschiedliche anrufende Teilnehmer.
-
Zusätzlich sind
eine oder mehre getrennte Datentabellen für die Hauptprogrammblöcke vorhanden,
die eine Datenzeile für
jeden Dienstleistungsschlüsselwert
enthalten, der in der Domäne
mehrerer unterschiedlicher Hauptprogrammblöcke verwendet wird. Das in
den Fig. gezeigte Beispiel hat eine Datentabelle FMP_DT1, die allen
Programmblöcken
gemeinsam ist (alle Hauptprogrammblöcke lesen die genannte Datentabelle).
Am Anfang jeder Datenzeile in der Datentabelle wird der Dienstleistungsschlüsselwert
SK als der Schlüssel
angegeben. Jede Zeile enthält
Daten der Funktion Fki (i = 1, 2 ...), die sich auf den genannten
Dienstleistungsschlüsselwert
beziehen, d. h. auf Dienstleistungen, die zu erlaubende Funktionen
des genannten Dienstleistungsschlüsselwerts sind. Weiter kann
die Zeile Informationen darüber
enthalten, in welcher Reihenfolge diese Funktionen ausgeführt werden,
oder die Reihenfolge der Funktionsschlüssel kann direkt die relative
Reihenfolge der Funktionen anzeigen. Der Hauptprogrammblock liest
aus dieser Datentabelle die Zeile aus, die dem empfangenen Dienstleistungsschlüsselwert
entspricht, wodurch er den Funktionssatz findet, der die für den genannten
Wert zu ermöglichenden
Funktionen enthält.
Danach liest der Hauptprogrammblock aus seiner zugeordneten Datentabelle
FMPi_DT (i = 1, 2 ...) die Zeile, die dem Identifizierer des genannten
Objekts (z. B. dem anrufenden Teilnehmer) entspricht. Aus dieser
Zeile findet der Hauptprogrammblock den Identifizierer des Dienstleistungslogikprogramms
SLPi (i = 1, 2 ...), das zu starten ist. Aus der Zeile der klassenspezifischen
Tabelle FMPi_DT (zum Beispiel der Tabelle anrufender Teilnehmer)
berücksichtigt
der Hauptprogrammblock nur solche Funktionen, die sich auf den genannten
Dienstleistungsschlüsselwert
beziehen (d. h., solche, die zu dem oben genannten erlaubten, zu
durchsuchenden Satz gehören),
und von diesen schließlich
nur jene, die bei dem genannten Objekt als aktiv bezeichnet werden.
-
Auf
dieser Stufe der Ausführung
der Dienstleistungsanforderung sind die Funktionen bezüglich des
Objekts und die relative Reihenfolge ihrer Ausführung bekannt. Danach erzeugt
der Hauptprogrammblock eine Instanz des Dienstleistungslogikprogramms,
das der Funktion entspricht, die als erste an der Reihe ist, und
fordert sie auf, die Ausführung der
Dienstleistung zu beginnen.
-
Die
FMP-Instanz sendet also eine Initial_DP-Nachricht an das Dienstleistungsprogramm
mit der höchsten
Priorität,
und der Hauptprogrammblock liest dessen Identifizierer aus der diesbezüglichen
untergeordneten Aufzeichnung der objektbezogenen Zeile. Zuerst wird
jedoch eine getrennte Anforderungsnachricht REQREC an die genannte
SLP-Instanz gesendet, da die Initial_DP-Nachricht in ihrem Standardformat (ASN.1-Format)
gesendet werden muss, in dem ihr Informationsgehalt nicht ausreichend
ist. Das Dienstleistungslogikprogramm benötigt also zusätzlich zu den
in der INAP-Nachricht enthaltenen Daten noch weitere Daten, beispielsweise
den Wert des Funktionsschlüssels,
den es in der Anforderungsnachricht empfängt.
-
6 zeigt
ein Beispiel der Datenstruktur der gesendeten Anforderungsnachricht.
Die Anforderungsnachricht hat zuerst ein Feld FMP_ID1, das den Identifizierer
der sendenden FMP-Instanz enthält. Danach
folgt ein Feld RP_ID, das den Identifizierer des Programmblocks
enthält,
an den der SLP seine diesen Dialog betreffenden Nachrichten senden
sollte. Diese Bestätigungsnachrichten
können
sowohl an die FMP-Instanz (Vater) als auch die MDP-Instanz (Großvater)
gesendet werden. Durch das Versenden von Bestätigungsnachrichten an die Verteilerprogramminstanz
kann die Last an den Hauptprogrammblöcken verringert werden, da
die MDP-Instanz sowieso für
das Absenden von ausgehenden Nachrichten an das Netzwerk sorgt.
Das nächste Feld
LAST_REQ enthält
eine Boole'sche
Variable, die angibt, ob noch eine weitere Anforderungsnachricht
an die SLP-Instanz gerichtet ist, nachdem die in der Anforderungsnachricht
angeforderten Funktionen ausgeführt
wurden. Das Feld SK enthält
den aus dem SSP-Netzwerkelement
erfahrenen Dienstleistungsschlüsselwert.
Das nächste
Feld, NoOfSFs, zeigt die Anzahl von Funktionen an, die in der Anforderungsnachricht
enthalten sind, und die Felder Fki (i = 1, 2 ...), die dem genannten
Feld folgen, enthalten die Schlüssel
der genannten Funktionen. Das letzte Feld AT enthält eine
Beschreibung dafür,
wie der Dienstleistungsdialog zu beenden ist, wenn die Ausführung der
Funktionen fehlschlägt.
-
In
der für
dieses Beispiel verwendeten Umgebung sind die Dienstleistungsprogramme
so strukturiert, dass sie aus Teilen zusammengesetzt sind, von denen
jedes eine gegebene Funktion ausführt. So führt jeder SLP nur jene Funktionen
aus, deren Funktionsschlüssel
in der Anforderungsnachricht ankommen. Wenn mehr als eine Funktion
aus der Gruppe der zu erlaubenden Funktionen in der objektbezogenen
Zeile aktiv ist und derselbe SLP-Identifizierer sich auf alle genannten
Funktionen bezieht, kann FMP alle diese Funktionsschlüssel in
einer Anforderungsnachricht senden (vorausgesetzt, dass es sonst
zu erlauben ist, alle genannten Funktionen nacheinander auszuführen). Wenn
die Funktionen den Identifizierer von mehreren unterschiedlichen SLP-Programmen
enthalten, sendet die FMP-Instanz Anforderungsnachrichten an die
genannten SLP-Programme in der durch die untergeordneten Aufzeichnungen
in der objektbezogenen Zeile angegebenen Reihenfolge. Die Vorgehensweise
kann auch so gestaltet sein, dass nur ein Funktionsschlüssel in
einer Anforderungsnachricht gesendet wird.
-
Nach
der Ausführung
der Funktion sendet der SLP eine Bestätigungsnachricht INFOREC an jene
Elemente (Vater und/oder Großvater),
die in der Anforderungsnachricht REQREC angegeben sind. In der Bestätigungsnachricht
gibt die SLP-Instanz auch an, auf welche Weise die Funktion beendet
wurde. Wenn beispielsweise die Durchführung der Funktion fehlschlägt, kann
die als nächste
durchzuführende Funktion
anders sein als im Normalfall, bei dem die Durchführung der
Funktion erfolgreich verlaufen ist.
-
7 stellt
eine mögliche
Struktur einer Bestätigungsnachricht
INFOREC dar, die von einer SLP-Instanz gesendet wurde. Das erste
Feld SLP_ID2 gibt den Identifizierer der Absender-SLP-Instanz an.
Das nächste
Feld WATT enthält
beispielsweise Informationen darüber,
ob eine Erwiderung vom Netzwerk erwartet wird, bevor die Dienstleistung fortgeführt werden
kann. Das Feld FLAG_D enthält eine
Boole'sche Variable,
die angibt, ob die SLP-Instanz nach dem Absenden einer Bestätigungsnachricht
selbst abschaltet oder nicht. Das Feld LAST_REQ wiederum enthält dieselben
Informationen, die das Kind zuletzt vom Vater in dem genannten Feld
erhalten hat (der Großvater
empfängt
also auch die genannten Informationen). Das nächste Feld LAST_INFO enthält wieder
eine Boole'sche
Variable, die angibt, ob die SLP-Instanz die Ausführung der
letzten Funktion der von ihr empfangenen Anforderungsnachricht beendet
hat. Das nächste
Feld Fk enthält
den Schlüssel
der Funktion, in dem die genannte Nachricht als Bestätigung ankommt.
Das Feld CC enthält
den Beendigungscode der gerade ausgeführten Funktion. Das Feld ECC
kann geringe Fehler anzeigen, für
die das Senden einer getrennten Fehlernachricht nicht erforderlich
ist. Das Feld EndDlg enthält
Informationen darüber,
auf welche Weise die genannte SLP-Instanz eine Beendigung des genannten
Dialogs durch den Großvater
wünscht.
Der Dialog kann auf unterschiedliche Weise beendet werden, beispielsweise
abhängig
davon, ob eine Nachricht an das Netzwerk gesendet werden soll oder,
wenn eine Nachricht gesendet wird, welche Informationselemente in
dem zu sendenden TC_END-Grundelement enthalten sein sollen.
-
Die
Bestätigungsnachricht
kann weiter ein Feld NFk enthalten, in dem der Schlüssel der
Funktion angegeben ist, die als nächste ausgeführt werden sollte.
-
Da
der Sendeverkehr von internen Nachrichten in dem Netzwerkelement
die tatsächliche
Erfindung nicht berührt,
wird er in diesem Zusammenhang nicht im Detail beschrieben. Allgemein
gesprochen kann gesagt werden, dass die Dienstleistungsprogramminstanzen
sowohl interne Nachrichten als auch Nachrichten empfangen, die vom
Netzwerk ankommen (INAP-Nachrichten), dass die (internen) Anforderungs-
und Bestätigungsnachrichten
für die Ausführung und
Verkettung von Funktionen genutzt werden und dass die Bestätigungsnachricht
ebenfalls für
die Angabe genutzt werden kann, wie die Ausführung der Funktion fortschreitet
und, möglicherweise
auch, welche Funktion als nächste
auszuführen
ist.
-
Struktur
und Betrieb der Dienstleistungslogikprogramme werden hier nicht
detaillierter beschrieben, weil die vorliegende Erfindung sich nicht auf
die Implementation dieser Themen bezieht. Wie oben erwähnt wurde,
sind die Dienstleistungslogikprogramme in der Umgebung, die als
Beispiel angeführt
wird, von der Art, dass sie aus Komponenten bestehen, von denen
jede eine spezifische untergeordnete Dienstleistung ausführt. Wenn
sich ein Leser weitere Hintergrundinformationen für dieses
Gebiet wünscht,
wird auf die Internationalen Offenlegungsschriften
WO9940732A3 ,
WO9940733A3 ,
WO9940734A3 ,
WO9940735A3 und
WO9940736A3 verwiesen, in denen die
Implementation solcher Dienstleistungslogikprogramme beschrieben
ist. Die erfindungsgemäße Lösung ist
jedoch unabhängig von
der Art und Weise, wie die Dienstleistungen implementiert werden.
Anders ausgedrückt,
die Lösung gemäß der Erfindung
kann auch dann genutzt werden, wenn die Dienstleistungen auf andere
bekannte Weise realisiert werden. Soweit es die Implementierung
der Dienstleistungen betrifft, kann also die funktionale Architektur
des Netzwerkelements variieren.
-
Es
folgt eine detailliertere Beschreibung der Durchführung des Überwachens
in der oben beschriebenen Umgebung.
-
8 stellt
den Betrieb des Nachrichtenverteilerprogrammblocks hinsichtlich
einer vom Netzwerk kommenden TCAP-Nachricht dar. Wurde die Nachricht
empfangen, wird sie zuerst auf der TCAP-Schicht (Phase 81)
bearbeitet, als Ergebnis dieser Bearbeitung kann die INCAP-Nachricht
aus der TCAP-Nachricht extrahiert werden. In Phase 81 kann
jedoch die Nachrichtenüberwachung
nur auf der TCAP-Schicht durchgeführt werden, auf der die tatsächliche
Nachrichtenbearbeitung stattfindet. Danach (Phase 82) wird
eine Überprüfung durchgeführt, um
zu bestimmen, ob eine Überwachung
durchzuführen
ist oder nicht. Ist keine Überwachung
durchzuführen,
springt der Bearbeitungsvorgang direkt zur Phase 86, wo
das Funktionsverwaltungsprogramm, an das die INAP-Nachricht zu senden
ist, aus der MDP_DT-Datentabelle entsprechend dem in der Nachricht
enthaltenen Dienstleistungsschlüsselwert ausgelesen
wird. Soll eine Überwachung
stattfinden, wird eine Kopie des INAP-Programms für INAP erzeugt
(Phase 83). Als Nächstes
wird eine Instanz des Überwachungsprogramms
für die
betreffende INAP-Nachricht erzeugt (Phase 84), und die
Kopie der INAP-Nachricht wird an die genannte Instanz gesendet (Phase 85).
Nach Ausführung
dieser Phasen kehrt das System zum Normalbetrieb zurück, wo das Funktionsverwaltungsprogramm,
das die Nachricht empfangen soll, identifiziert wird (Phase 86),
und die Originalnachricht wird an das genannte Funktionsverwaltungsprogramm
gesendet (Phase 87).
-
In
der entgegengesetzten Übertragungsrichtung
empfängt
das Nachrichtenverteilerprogramm INAP-Nachrichten von Dienstleistungslogikprogrammen.
Selbstverständlich
ist der Prozess in dem Sinn umgekehrt, dass die an das Netzwerk
zu sendende TCAP-Nachricht nicht generiert wird, bevor die INAP-Nachricht
bearbeitet ist und eine Kopie der INAP-Nachricht an das Überwachungsprogramm
gesendet wurde. Normalerweise ist es nicht erforderlich, weil sie
zu diesem Zeitpunkt bereits existiert.
-
Es
gibt jedoch Dienstleistungen, für
die eine Überwachungsprogramminstanz
generiert werden muss; eine solche Dienstleistung ist der Weckruf
als Dienstleistung, für
die es keine vorangegangene Nachricht vom Netzwerk gibt.
-
9 stellt
den Ablauf des Überwachungsprogramms
MPPi hinsichtlich einer solchen Nachrichtenkopie dar, der sich aus
einer vom Netzwerk empfangenen Nachricht ergibt. Wurde einmal die
Kopie der INAP-Nachricht vom Nachrichtenverteilerprogramm in Phase
91 empfangen,
wird die Nachricht mit einem bekannten Verfahren decodiert (Phase
92),
wenn sie im BER-Format ist (was für die an diesem Punkt vom Netzwerk
kommenden Nachrichten im Allgemeinen der Fall ist). Nach dem Decodieren ist
die Nachricht im ASN.1-Format. Anders ausgedrückt, nach dem Decodieren wird
die Nachricht im Speicher auf eine Weise gespeichert, dass die Datenstrukturen,
die mit der ASN.1-Nachrichtendefinition übereinstimmen, in den verschiedenen
Speicherbereichen in der Weise unterschieden werden können, dass
aufgezeigt wird, welche Zeilen der Nachrichtendefinition in der
Nachricht enthalten sind. Für die
Durchführung
der Decodierung wird vorzugsweise derselbe dienstleistungsunabhängige Aufbaublock
(SIB) aufgerufen, der zum Decodieren der Originalnachricht im Dienstleistungslogikprogramm
benutzt wird. Für
jede INAP-Nachrichtenart gibt es eine zugehörige Decodierfunktion. Danach
wird die ASN.1-Formatnachricht aus dem Speicher Zeile für Zeile
ausgelesen (Phase
93) und (Phase
94) als Datei
oder zur optischen Anzeige ausgegeben, wo sie angesehen werden kann.
Das Auslesen kann auf die gleiche Weise durchgeführt werden wie in den Dienstleistungslogikprogrammen.
Ein mögliches
Verfahren zur Realisierung ist in der Internationalen Offenlegungsschrift
WO 9956451 A1 beschrieben.
-
Werden
Nachrichten zum Netzwerk übermittelt,
kann das Überwachungsprogramm
auf identische Weise durchgeführt
werden. Es ist jedoch keine Decodierfunktion erforderlich, wenn
die INAP-Nachricht erst kurz vor der TCAP-Bearbeitung in das BER-Format konvertiert
wird.
-
10 zeigt
als Beispiel, wie eine Ausgabe aus dem Überwachungsprogramm aussehen
kann. Bei der Nachricht handelt es sich um eine INAP-Nachricht mit
dem Namen CalllnformationReportArg, die SSP an SCP sendet. Die Art
der Nachricht oder die Übermittlungsrichtung
sind jedoch für die
Erfindung nicht von wesentlicher Bedeutung, da alle Nachrichten
auf die gleiche Weise bearbeitet werden. Wie in der Fig. gezeigt
ist, bestehen die ASN.1-Definitionen der INAP-Nachrichten aus Textzeilen. Diese Zeilen
können
in Typen unterteilt werden; beispielsweise kann die Unterteilung
dahingehend erfolgen, ob die Zeilen eine Be ziehung zu tatsächlichen
Nachrichtenparametern haben oder ob sie eingebettete ASN.1-Datenstrukturen
darstellen, die in der Nachricht enthalten sind.
-
Der Überwachungsprogrammblock
gibt die empfangene Nachricht in ihrem Standardformat (ASN.1) aus,
so dass die Ausgabe jene Textzeilen der ASN.1-Definition für die entsprechende
Nachrichtenart zeigt, für
die entsprechende Parameter oder Datenstrukturen in der Nachricht
enthalten sind, und die Werte, die den genannten Textzeilen entsprechen.
Der Programmblock ist auch in der Lage, die Nachricht im BER-Format
auszugeben.
-
Wie
aus dem Beschriebenen hervorgeht, wird gemäß der Erfindung im Netzwerkelement
ein Zweig zu Überwachungszwecken
geschaffen, und eine Kopie der zu überwachenden Nachricht wird über den
Zweig an den Überwachungsprozess übermittelt.
Daraus ergibt sich, dass das Überwachen
unabhängig
von dem tatsächlichen „Nutzungsprozess" durchgeführt wird
und die Verarbeitung der Originalnachricht nicht beeinträchtigt.
Die Überwachung
an sich wird mit einem bekannten Verfahren durchgeführt.
-
Obwohl
die Erfindung im voraufgehenden Text unter Hinweis auf die in den
beigefügten
Zeichnungen gegebenen Beispiele beschrieben wurde, ist die Erfindung
selbstverständlich
nicht auf die genannten Beispiele beschränkt, sondern kann im Bereich
der Idee der oben dargelegten Erfindung und der beigefügten Patentansprüche variiert
werden. Wie bereits früher
erwähnt
wurde, kann die erfindungsgemäße Lösung in
einer Anzahl ähnlicher
Umgebungen angewendet werden, wo es notwendig ist, Nachrichten einer
bestimmten Protokollschicht zu überwachen,
und wo eine Interpretation der Nachricht nur schwer anders auszuführen ist
als in Verbindung mit der Nachrichtenbearbeitung in der genannten
Protokollschicht. Eine solche Umgebung ist das Lokalbereichsnetzwerk.
Ein alternatives Protokoll ist SNMP (Simple Network Management Protocol),
das in TCP/IP-Netzwerken verwendet wird, wo SNMP-Nachrichten im
BER-Format übertragen
werden wie INAP-Nachrichten im SS7-Netzwerk.