-
HINTERGRUND
DER ERFINDUNG
-
Technisches
Gebiet der Erfindung
-
Die Erfindung bezieht sich auf Entwicklungstestsysteme,
und genauer auf eine Vorrichtung und ein Verfahren zum Verbinden
eines Telekommunikation-Systememulators mit einem Netzwerk.
-
Beschreibung
zum Stand der Technik
-
In der Telekommunikationsindustrie
werden standardisierte Telekommunikationsnetzwerke miteinander verbunden,
indem Protokolle verwendet werden, welche auf dem Open Systems Interconnection
(OSI) Modell basieren. Das OSI-Modell ist ein international anerkanntes
Fachwerk an Standards zur Kommunikation zwischen unterschiedlichen
Systemen, welche von unterschiedlichen Lieferanten hergestellt werden.
Das OSI-Modell erzeugt
eine offene Systemnetzwerkumgebung, bei welcher jegliches Lieferantencomputersystem,
welches mit jeglichem Netzwerk verbunden ist, frei Daten mit jeglichem
anderen Computersystem auf diesem Netzwerk oder einem verbundenen
Netzwerk teilt.
-
Das OSI-Modell organisiert die Kommunikationsverarbeitung
in sieben unterschiedlichen Schichten von untereinander zusammenhängenden Protokollen
in einer geschichteten Sequenz, basierend auf ihrer Beziehung zum
Benutzer. 1 ist ein veranschaulichendes
Blockdiagramm eines OSI-Stapels 10, welcher die sieben
Schichten des OSI-Modells darstellt.
-
Schichten 1–3 befassen
sich mit einem Netzwerkzugriff und Schichten 4–7 beschäftigen sich
mit End-zu-End Kommunikationen zwischen der Nachrichtenquelle und
dem Nachrichtenziel. Jede Schicht enthält mindestens eine Funktion,
welche zwischen einer oberen und einer unteren logischen Grenze enthalten
ist. Die Dienste jeder Schicht werden mit den Diensten von unteren
Schichten verbunden, um neue Dienste zu erzeugen, welche für die höheren Schichten
erhältlich
sind. Die Schichten sind wie folgt:
Schicht 1 ist
eine physikalische Schicht, welche eine Übertragung von Signalen und
die Aktivierung und Deaktivierung von physikalischen Verbindungen
bereitstellt;
Schicht 2 ist eine Datenverbindungsschicht,
welche Signalsynchronisation, Fehlerkorrektur, Einordnung und Flusssteuerung
enthält.
Diese Schicht stellt ebenfalls eine Datenübertragungsverbindung über eine
oder mehrere physikalische Verbindungen hinweg bereit;
Schicht 3 ist
eine Netzwerkschicht, welche Routing- und Schaltfunktionen bereitstellt;
Schicht 4 ist
eine Transportschicht, welche Schichten 1–3 verwendet,
um einen End-zu-End Dienst bereitzustellen, welcher erforderte Eigenschaften
für die höherschichtigen
Funktionen hat;
Schicht 5 ist eine Session-Schicht,
welche das Mittel zum Errichten einer Session-Verbindung und zum Unterstützen eines
geordneten Austausches von Daten und damit in Verbindung stehenden
Steuerfunktionen für
einen bestimmten Kommunikationsdienst bereitstellt;
Schicht 6 ist
eine Darstellungsschicht, welche Mittel zur Datenformatierung und
Code-Umwandlung bereitstellt; und
Schicht 7 ist eine
Anwendungsschicht, dessen Protokolle den von einem Endbenutzer gesuchten
tatsächlichen
Dienst bereitstellt.
-
Während
der Entwicklung und des Testens von Telekommunikationssystemen und
neuen Dienstanwendungen, ist es üblich,
einen Satz von untereinander zusammenhängenden Softwareprogrammen
zu entwickeln, welche, wenn sie verbunden werden, die Systemhardware
modulieren oder simulieren. Die Wirkungen eines Hinzufügens neuer Dienstanwendungen
oder die Wirkungen von vorgeschlagener Hardware oder Software, welche
sich in dem System ändert,
können
schnell moduliert und analysiert werden, ohne den teuren und zeitraubenden
Prozess des tatsächlichen
Modifizierens der Systemhardware oder eines Ladens einer neuen Dienstanwendung
in einem aktuellen System zu unterlaufen. Es treten jedoch Probleme
auf und die Testkosten steigen wesentlich an, wenn die zu testenden
Funktionen Kommunikationen zwischen zwei oder mehreren Telekommunikationssystemen
erfordern.
-
Bestehende Kommunikationsverbindungen, welche
zur Verbindung standardisierter Telekommunikationssysteme verwendet
werden, enthalten im allgemeinen Berechnungssoftware, welche OSI-Schichten 3–7 ausführt und
zusammensetzt, und Übertragungshardware,
welche OSI-Schichten 1–2 ausführt. Wenn
eine Verbindung zwischen zwei Telekommunikationssystemen oder zwischen
einem Telekommunikationssystem und einem Systemsimulator zu Testzwecken
erforderlich ist, werden die Systeme normalerweise direkt miteinander
mit derselben Übertragungshardware
verbunden, welche zur physikalischen Verbindung installierter Telekommunikationssysteme
im Feld verwendet wird. Testeinrichtungen und Testtools werden dann
mit den Systemen und den physikalischen Verbindungen zwischen ihnen
zum Zwecke des Überwachens
der Verbindungen und zum Durchführen
von Protokollanalysen oder anderen Evaluierungstests verbunden.
-
Jedoch gibt es mehrere Nachteile
bei diesen bestehenden Testverfahren. Zunächst sind die Testeinrichtungen
und die Testtools, welche zur Testentwicklung von Telekommunikationssystemen
verwendet werden, sehr teuer. Zweitens erfordern diese bestehenden
Testverfahren die Verwendung von physikalischer Übertragungshardware zwischen
den unter Test stehenden Systemen, welches die Setup-Zeit und die
Kosten des Testprozesses erhöht.
Drittens erfordern diese Verfahren eine wesentliche Zugriffszeit
für ein
nützliches
Telekommunikationssystem, welches bei einer Anzahl unterschiedlicher
Entwicklungsgruppen von hoher Anforderung sein kann. Schließlich bindet
die Verwendung eines physikalischen Telekommunikationssystems und
einer physikalischen Übertragungshardware
den Tester an eine physikalische Umgebung in Nähe zu dem unter Test stehenden
System.
-
Obwohl es keine bekannten Lehren
aus dem Stand der Technik zu einer Lösung des zuvor genannten Nachteils
und der Unzulänglichkeit
gibt, offenbart US-Patent Nr. 5,027,343 von Chan et al. (Chan) einen
Gegenstand, welcher eine gewisse Beziehung zur hier diskutierten
Angelegenheit hervorbringt. Chan offenbart ein Testzugriffssystem
zum Ferntesten (remote testing) von Produkten in einem Integrated
Services Digital Network (ISDN) System. Die getesteten Protokolle
beziehen sich auf OSI-Schichten 1–3, welche sich hauptsächlich mit der Errichtung,
dem Halten und Freisetzen von einem physikalischen Telekommunikationspfad
beschäftigen.
Chan paketiert oder verkapselt Netzwerkmeldungen, welche Schichten 1–3 enthalten,
und verwendet ein Paketschaltnetzwerk, um Testprozeduren vom Tester
zum unter Test stehenden System zu übertragen. Das unter Test stehende
System entkapselt die Pakete, entfernt die Netzwerkmeldungen, und
sendet sie zur Verarbeitung.
-
Chan überwindet einige der Nachteile
bei der Verwendung derselben physikalischen Übertragungshardware zum Testen,
welche zu Übertragungen
zwischen Telekommunikationssystemen im Feld verwendet werden. Jedoch
ist Chan spezifisch daraufhin gerichtet, um ein Ferntesten von tatsächlicher physikalischer
Hardware zu unterstützen.
Eine lokale Seite, welche einen Tester enthält, ist mit einem unter Test
stehenden System fernverbunden. Chan bringt jedoch besonders hervor,
dass das Patent nur auf OSI-Schichten 1–3 gerichtet ist,
welche sich mit der physikalischen Übertragung, dem Routing und Schalten
von Signalen beschäftigen.
Chan ist daher eine Hardware-abhängige
Lösung,
welche sehr empfindlich auf Hardware-Zeiterfordernisse ist. Chan lehrt
kein Verfahren zum Verbinden mehrerer Telekommunikationssysteme
oder Systememulatoren ohne physikalischer Übertragungshardware, für das Testen
von OSI-Schichten 3–7,
oder schlägt
eines vor.
-
Die europäische Patentanmeldung 0,589,576
der American Telephone and Telegraph Company, veröffentlicht
am 3. März
1994, diskutiert eine Kommunikationsnetzwerk-Testumgebung, welche
einen Signalsimulator verwendet. Jedoch diskutiert sie nicht die
Integration eines Telefonnetzwerkemulators mit einem Datennetzwerk.
-
Simulation Software for Communications Networks:
The State of the Art, von Averill M. Law und Michael McComas stellt
eine Zusammenfassung von erhältlichen
Datensystemsimulatoren bereit. Jedoch diskutiert dieser Artikel
keine Telefonnetzwerksimulation über
ein Datennetzwerk, noch wird sie ermöglicht.
-
Es wäre ein deutlicher Vorteil,
ein System und ein Verfahren zum Verbinden mehrerer Telekommunikationssysteme
und/oder Telekommunikationssysteme und Systememulatoren mit einem
Protokollsimulator zur Testentwicklung von Software zu haben, welche
OSI-Schichten 3–7 in
einem Telekommunikationsknoten implementiert, welcher nicht die Verwendung
derselben Übertragungshardware
benötigt,
welche zur physikalischen Verbindung von installierten Telekommunikationssystemen
im Feld verwendet wird. Ein solches System und Verfahren würde den
Bedarf von teuren Testeinrichtungen und Testtools zum Überwachen
der Kommunikationsverbindungen und zum Durchführen von Protokollanalysen
oder weiteren Evaluierungstests ausschließen. Das System wäre unabhängig von
der Übertragungshardware,
welche für
normale Telekommunikationsübertragungen
verwendet wird, und wäre
nicht empfindlich auf Hardware-Zeiterfordernisse. Eine Vorrichtung
und ein Verfahren zum Verbinden von Emulatoren an unterschiedlichen
Netzwerken wären
für ein solches
System erforderlich, um am wirksamsten betrieben zu werden. Die
vorliegende Erfindung stellt eine solche Vorrichtung und ein solches
Verfahren bereit.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
In einem Aspekt ist die vorliegende
Erfindung ein Protokoll Schnittstellen-Gateway zum Verbinden eines
Emulators mit einem Netzwerk. Das Gateway umfasst: ein Mittel zum
Empfangen von Signalen aus dem Netzwerk und Senden von Signalen
an das Netzwerk, welche in einem Netzwerk-Protokoll formatiert sind.
Das Gateway enthält
ebenfalls ein Mittel zum Umwandeln der empfangenen Signale in Befehle
im Emulatorcode, und Umwandeln der verarbeiteten Befehle im Emulatorcode
in Signale in dem Netzwerkprotokoll. Zusätzlich enthält das Gateway ein Mittel zum
Senden der Befehle im Emulatorcode an den Emulator und Empfangen
der verarbeiteten Befehle im Emulatorcode vom Emulator. Das Protokoll Schnittstellen-Gateway
kann ebenfalls einen UNIX-Socket verwenden, welcher Open Systems
Interconnection (OSI) Schichten 1 und 2 des Netzwerkprotokolls
ersetzt, um die Signale an und von dem Netzwerk zu senden und zu
empfangen.
-
In einem anderen Aspekt ist die vorliegende Erfindung
ein Verfahren zum Verbinden eines Emulators an ein Netzwerk. Das
Verfahren umfasst die Schritte: Empfangen von Signalen, welche in
einem Netzwerkprotokoll formatiert sind, aus dem Netzwerk mit einem
Protokoll Schnittstellen-Gateway; Umwandeln der empfangenden Signale
in dem Protokoll Schnittstellen-Gateway in Befehle im Emulatorcode; und
Senden der Befehle im Emulatorcode vom Protokoll Schnittstellen-Gateway an den Emulator
zur Verarbeitung. Das Verfahren enthält ebenfalls ein Empfangen
der verarbeiteten Befehle im Emulatorcode vom Emulator mit dem Protokoll
Schnittstellen-Gateway;
Umwandeln in dem Protokoll Schnittstellen-Gateway von verarbeiteten
Befehlen im Emulatorcode in Signale in dem Netzwerkprotokoll; und Senden
der Signale in dem Netzwerkprotokoll von dem Protokoll Schnittstellen-Gateway
an das Netzwerk. Das Verfahren kann ebenfalls ein Ersetzen von Open
System Interconnection (OSI) Schichten 1 und 2 des
Netzwerkprotokolls mit einem Unix-Socket enthalten.
-
KURZE BESCHREIBUNG
DER ZEICHNUNG
-
Die Erfindung wird besser verstanden,
und deren zahlreiche Aufgaben und Vorteile werden dem Fachmann deutlicher
durch Bezug auf die folgende Zeichnung in Verbindung mit der begleitenden
Beschreibung, in der:
-
1 (Stand
ein veranschaulichendes Blockdiagramm eines der Technik) OSI-Stapels
ist, welcher die sieben Schichten des OSI-Modells darstellt;
-
2 ein
vereinfachtes Blockdiagramm einer Kommunikationsverbindung ist,
welche einen Internet-Socket zwischen zwei OSI-Stapeln verwendet, welche
gemäß den Lehren
der vorliegenden Erfindung an dem Schicht 3 Pegel verbunden
sind;
-
2A ein
vereinfachtes Blockdiagram ist, welches die Beziehung zwischen den
unterschiedlichen Protokollen darstellt, welche in der vorliegenden
Erfindung verwendet werden;
-
3 ein
vereinfachtes Blockdiagramm einer Kommunikationsverbindung ist,
welche einen Internet-Socket zwischen zwei Telekommunikationssystem-Emulatoren
verwendet, welcher Protokolle des OSI-Modells verwendet;
-
4 ein
vereinfachtes Blockdiagramm ist, welches eine Ausführungsform
der vorliegenden Erfindung darstellt, bei welcher ein Protokoll-Simulationstool
modifiziert wurde, um einen Internet-Socket und eine LAN-Verbindung
zu verwenden, um eine Rufaufbausimulation mit einer Rufabschlusssimulation
zu verbinden;
-
5 ein
Blockdiagramm ist, welches die Protokoll-Stapel und Kommunikationsverbindung von 3 detaillierter darstellt;
-
6 ein
Blockdiagramm von einer Ausführungsform
der vorliegenden Erfindung ist, bei welcher eine Protokollsimulation-Testvorrichtung über einen
Internet-Socket eine Schnittstelle mit einem Telekommunikationsschaltemulator
bildet;
-
7 ein
vereinfachtes Blockdiagramm eines automatisierten Diagnosesystems
ist, in dem sowohl ein Ziel-Telekommunikationsschalter und ein Ziel-Emulator
gemäß den Lehren
der vorliegenden Erfindung mit einem Protokollsimulator verbunden sind;
-
8 ein
detaillierteres Blockdiagramm des Emulators und PIG-Tools von 7 ist;
-
9 ein
vereinfachtes Blockdiagramm ist, welches die Simulation von einer
Vielzahl von Leitungsschnittstellenkarten (LICs) durch den Protokollsimulator,
und ihre Verbindung über
einen Internet-Socket und LAN mit einem Emulator und einer Vielzahl
von simulierten Signalisierungspunkten darstellt;
-
10 eine
Darstellung einer auf einem Computer dargestellten Icon-Tool-Box
ist, welche durch einen Bediener verwendet werden kann, um ein Testen
mit dem Entwicklungstestsystem der vorliegenden Erfindung einzuleiten;
-
11 eine
Darstellung eines auf einem Computer dargestellten Shelf-Auswahlmenüs ist, welches
es einem Bediener ermöglicht,
ein richtiges Hardware-System oder ein emuliertes System zu Testzwecken
auszuwählen;
-
12 eine
Darstellung eines auf einem Computer dargestellten Netzwerkabbildungseditors ist,
welcher verwendet wird, um die Testumgebung an das Entwicklungstestsystem
zu bestimmen;
-
13 eine
Darstellung einer auf einem Computer dargestellten Netzwerkabbildung
ist, welche eine Simulation in dem Protokollsimulator von einer
einfachen Orts-Update-Sequenz darstellt, welche in einem Basisstationsteuerer
(BSC) in einem Privatkommunikationssystem (PCS) eines mobilen Telekommunikationssystems
durchgeführt
wird;
-
14 eine
Darstellung eines auf einem Computer dargestellten Menüs von emulierten
Systemen (virtuelle Shelves) ist, auf welche das PIG-Tool zugreifen
kann;
-
15 eine
Darstellung eines Computerdisplays ist, welche drei Statusfenster
zeigt, welche dem Protokollsimulator, dem PIG-Tool und dem Emulator entsprechen;
und
-
16 eine
detailliertere Auflistung des Meldungsbeobachtungsabschnittes des
PIG-Tool Statusfensters
von 15 ist.
-
DETAILLIERTE
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
-
Während
der Entwicklung von neuen Funktionen und Diensten, welche zwischen
Telekommunikationssystemen übertragen
werden, bleiben OSI-Schichten 1 und 2 (die physikalische
Hardware und die Verbindung zum Netzwerk) häufig unbeeinflusst. Im Gegensatz
dazu werden Schichten 3–7 fast immer auf
eine bestimmte Weise geändert.
Mit anderen Worten wird die Entwicklung von neuen Funktionen und
Diensten nicht immer das Mittel zur Informationsübertragung ändern, sondern die übertragene Information
wird fast immer geändert.
Daher benötigt ein
Testen, welches nur OSI-Schichten 3–7 einbezieht, nicht
teure und spezielle Übertragungstesteinrichtungen,
welche zwischen Netzwerkmodellen verbunden ist, da die physikalische
Schicht im allgemeinen nicht beeinflusst wird. Anstelle dessen können Entwickler
einen Vorteil aus der Tatsache ziehen, dass die meisten Telekommunikationssysteme
einige Typen eines lokalen Netzwerkes (LAN) Protokolls unterstützen.
-
2 ist
ein vereinfachtes Blockdiagramm einer Kommunikationsverbindung 20,
welche einen Internet-Socket 21 zwischen OSI-Stapeln 22, 23 verwendet,
welche an dem Schicht 3 Pegel verbunden sind. Gemäß den Lehren
der vorliegenden Erfindung werden die bestehenden Pegel 1 und 2 Telekommunikationsprotokolle,
der physikalische Pegel und der Datenverbindungspegel durch ein
LAN-Protokoll, wie zum Beispiel Ethernet, ersetzt. Das Telekommunikationsprotokoll
wird durch das Transmission Control Protocol/Internet Protocol (TCP/IP)
verkapselt und dann unter Verwendung einer Internet-Socket-Schnittstelle 21 über ein
LAN-Netzwerk übertragen.
Die Internet-Socket-Schnittstelle 21 kann vom Typ einer
UNIX-Datei sein,
welche Netzwerkkommunikationen zwischen Applikationen bereitstellt,
welche auf unterschiedlichen Host-Prozessoren betrieben werden.
Die Socket-Schnittstelle erlaubt es Applikationsprogrammen miteinander
zu kommunizieren. Im allgemeinen erzeugt ein Applikationsprogramm
einen TCP Client Socket, verbindet an einen TCP Server Socket, und
sendet oder empfängt
dann Daten über
diese Schnittstelle.
-
Die Internet-Socket-Schnittstelle 21 kann
als eine Verallgemeinerung des UNIX-Dateizugriffsmechanismus gedacht
werden, welcher einen Endpunkt zur Kommunikation bereitstellt. Applikationsprogramme
fordern von dem Betriebssystem an, einen Socket zu erzeugen, wenn
einer gebraucht wird. Sockets werden erzeugt, ohne dass sie an spezifische Zieladressen
gebunden sind. Die Applikation kann dann jedes Mal eine Zieladresse
dann zuführen, wenn
sie den Socket verwendet (beispielsweise beim Senden von Datagrammen)
oder sie kann wählen
die Zieladresse an den Socket zu binden, und vermeidet das Ziel
wiederholend zu spezifizieren (beispielsweise beim Erstellen einer
TCP-Verbindung). Ein Client Socket verbindet an einen Server Socket,
um eine Kommunikation zwischen Applikationsprogrammen zu erlauben.
-
Ein standardisiertes Internet Protokoll
ist das User Datagram Protocol (UDP). Das UDP Protokoll enthält eine
Protokollanschlussnummer, welche es einem Sender erlaubt, unter
mehreren Zielen (Applikationsprogrammen) auf einem Remote-Prozessor zu unterscheiden.
UDP/IP-Sockets werden zum Aufbauen, Aufrechterhalten und Abbauen
von Kommunikationen zwischen Applikationsprogrammen verwendet, während TCP/IP-Sockets zur zuverlässigen Übertragung
von Daten verwendet werden.
-
2A ist
ein vereinfachtes Blockdiagramm, welches die Beziehung zwischen
den unterschiedlichen Protokollen darstellt, welche in der vorliegenden
Erfindung verwendet werden. Benutzerprozesse 24 und 25 umfassen
OSI-Schichten 5–7.
Es werden Daten zwischen den Benutzerprozessen 24 und 25 unter
Verwendung des TCP-Protokolls 26 (OSI-Schicht 4) übertragen.
Andere Kommunikationen zwischen den Benutzerprozessen verwenden das
UDP-Protokoll 27 (OSI-Schicht 4). Sowohl Daten als
auch Kommunikationen verwenden dann das IP-Protokoll 28 (OSI-Schicht 3)
und Ethernet 29 (OSI-Schichten 1–2),
um die Verbindung zwischen den Benutzerprozessen zu vollenden.
-
Internet-Sockets können mit
herkömmlichen Betrieben,
wie zum Beispiel „Lesen" und „Schreiben" verwendet werden.
Sobald beispielsweise ein Applikationsprogramm einen Socket erzeugt und
eine TCP-Verbindung vom Socket an eine Zieladresse erzeugt, kann
das Applikationsprogramm den „Schreiben"-Betrieb verwenden, um einen Datenstrom über die
Verbindung zu senden. Ein Empfangsapplikationsprogramm an dem anderen
Ende kann den „Lesen"-Betrieb verwenden,
um die Daten zu empfangen.
-
3 ist
ein vereinfachtes Blockdiagramm einer Kommunikationsverbindung 30,
welche einen Internet-Socket 31 zwischen zwei Telekommunikationssystememulatoren 32 und 33 verwendet,
welche Protokolle vom OSI-Modell verwenden. Der Ausdruck „Emulator", wie hier verwendet,
bezieht sich auf ein Softwareprogramm, welches die Hardware eines
Verarbeitungsknotens emuliert und die Applikationssoftware interpretiert,
als wenn die Applikationssoftware auf einer Zielmaschine läuft. Der
Ausdruck „Simulator" bezieht sich auf
einen Prozessor, welcher in Ansprechen auf vorweggenommene Meldungen vorprogrammiert
ist. In der bevorzugten Ausführungsform
laufen ein Protokollsimulator und ein Telekommunikationssystememulator
auf Prozessoren, welche auf UNIX basieren. Daher kommunizieren diese
Systeme miteinander, indem sie einen Internet-Socket und ein LAN-basiertes
Netzwerk, wie zum Beispiel Ethernet, verwenden. Protokollbasierte
Information wird von einem Übertragungssystem
an ein Empfangssystem übertragen,
indem LAN-Protokolle verwendet werden, welche von den Telekommunikationssystemen
unterstützt
werden. Kommunikationen zwischen dem Protokollsimulator und dem Telekommunikation-Systememulator
verwenden den Internet-Socket,
um gepackte Daten von OSI-Schichten 3–7 in TCP/IP-Format auf dem LAN-basierten Netzwerk
zu übertragen.
Der Empfangsemulator empfängt
unter Verwendung von Sockets die Information vom Protokollsimulator über einen
Protokoll Schnittstellen-Gateway, entpackt Schichten 3–7 und verarbeitet
die Information. Eine festgesetzte OSI-Schicht 2 in dem
Telekommunikationsprotokoll, welches unter Test steht (beispielsweise
Message Transfer Part (MTP)), kann auch verwendet werden, da die
Kommunikationsverbindung zwischen dem Protokollsimulator und dem
Telekommunikationssystememulator von einem völlig unterschiedlichen Protokoll-Stapel
gesteuert wird, welcher mit dem Internet-Socket verknüpft ist.
-
Wenn die Kommunikationsverbindung
zwischen Telekommunikationsknoten ist, können OSI-Schichten 3–7 jeglichem
ANSI Signalling System 7 (SS7), CCITT oder einem anderen
kompatiblen Protokoll-Stapel entsprechen. 3 stellt den Transport von einem Transaction
Capabilities Application Part (TCAP) Protokoll-Stapel 33 an
Stapel 32 dar, oder umgekehrt. Ebenfalls sind ein Mobile
Application Part (MAP) Protokoll-Stapel 33a und ein Integrated
Services User Part (ISUP) Protokoll-Stapel 33b dargestellt.
TCAP 34 und MAP 35 sind Level 7 Applikationen,
während
ISUP 36 eine Level 4–7 Applikation ist.
Der SS7-Stapel kann durch den Internet-Socket 31 unter Verwendung
von Ethernet über
ein LAN transportiert werden, um die MTP-Schichten 1 und 2 zu
ersetzen. Der physikalische Ziel-Telekommunikationsknoten oder Telekommunikationssystememulator
akzeptiert die Information auf einer TCP/IP-Verbindung auf dem LAN
und decodiert die Schicht 3–7 Information. Einige
Telekommunikationknoten können
eine Modifikation zur Kommunikation über TCP/IP mit einer LAN-Verbindung
erfordern, um ihre normalen MTP-Schichten 1 und 2 zu
ersetzen. Solche Modifikationen sind im Stand der Technik bekannt
und werden hier im folgenden nicht ausgeweitet.
-
Dieser Kommunikationsprozess kann
ebenfalls zur Kommunikation zwischen einem UNIX-Prozessor, welcher
eine Telekommunikationssignalisierung ausgibt, und einem physikalischen
Ziel-Telekommunikationsknoten verwendet werden, welcher so ausgestattet
ist, um die LAN-Information zu empfangen und die eingehende Signalisierungsinformation
extrahiert.
-
4 ist
ein vereinfachtes Blockdiagramm, welches eine Ausführungsform
der vorliegenden Erfindung darstellt, in der ein Protokoll-Simulationstool 41 modifiziert
wurde, um Internet-Sockets 42 und 43 zu verwenden,
und eine LAN-Verbindung 44,
um eine Rufaufbau-Simulation 45 mit einer Rufabbau-Simulation 46 zu
verbinden. In dieser Ausführungsform
wird Telekommunikationsprotokoll-Simulationssoftware für Schichten 3–7 des
OSI-Modells von der Rufaufbausimulation 45 an der Rufabbausimulation 46 übertragen,
oder umgekehrt, ohne dass jegliches externes Netzwerk oder eine
Hardware benötigt
wird. Die Rufaufbausimulation 45 umfasst eine Testscript-Software,
welche die Rufaufbaufunktionen durchführt. Diese Scripte werden dann
in Schichten 3–7 bei
Block 47 eingebaut und an einen UNIX-Adapter 48 gesendet.
Der UNIX-Adapter 48 verpackt die Schichten in TCP/IP-Format
bei Block 49 zur Übertragung über den
Internet-Socket 42, die LAN-Verbindung 44 und
den Internet-Socket 43 an eine Empfangsseite 50 des
UNIX-Adapters 48, bei welchem die Schichten entpackt werden.
Die Schichten werden dann bei Block 51 abgebaut und an
die Rufabbau-Simulation 46 in
dem Simulationstool 41 gesendet. Auf diese Weise werden
Signale von der Software-Paketierung des Simulationstools in das
Simulationstool selber zurückgeschleift,
um eine Testscriptverifikation von OSI-Schichten 3–7 zu
ermöglichen. Es
wird eine Prozessierung in einem Dialog fortgeführt, wie durch das vorprogrammierte
Testscript bestimmt, wobei jedes Script so entworfen wird, dass
es Protokollmeldungen, welche mit Schichten 3–7 des unter
Test stehenden Kommunikationsprotokolls aufgebaut werden, gesendet
und empfangen werden.
-
5 ist
ein Blockdiagramm, welches die Protokoll-Stapel 22 und 23 und
die Kommunikationsverbindung 20 von 2 detaillierter darstellt. Der Protokoll-Stapel 22 kann
eine UNIX-basierte Testapplikation sein, welche mit einer unter
Test stehenden Einheit 52 über den Internet-Socket 21 kommuniziert.
Die Testapplikation enthält
ein MTP, welches den OSI-Modell Protokoll-Stapel umfasst. Am MTP-Benutzerpegel
(Schicht 7) gibt es eine UNIX-basierte Applikation 53,
welche ein MTP-Protokoll für
Kommunikationen mit dem MTP-Benutzer verwendet. Den Protokoll-Stapel
heruntergehend, gibt es eine Signalling Connection Control Part(SCCP)-Schicht 54 und
eine MTP-Schicht 3 55, welche Signallisierungsnetzwerkfunktionen
durchführt.
Unter MTP-Schicht 3 gibt es MTP-Schichten 1 und 2, wobei
bei der vorliegenden Erfindung die normalen MTP-Schichten 1 und 2 Hardwarebezüglichen
Komponenten durch eine UNIX-Applikation 56 ersetzt wurden.
-
Der Internet-Socket 21 transportiert
paketierte Daten von der UNIX-Applikation 56 in der UNIX-basierten
Testapplikation an eine zweite UNIX-Applikation 57, welche
die Hardware-Komponenten
von normalen MTP-Schichten 1 und 2 in der unter
Test stehenden Einheit simuliert. Spezifikationen, welche unter
den UNIX-Applikationen 56 und 57 gemacht wurden,
erlauben ihnen die OSI-Schicht 3–7 Information zwischen
den Applikationen ohne dynamische Zuweisung von Schicht 2 Information durch
Verwendung von UNIX-Eigenschaften, mit oder ohne Verwendung von
LAN-Kommunikation und Protokollen, zu übertragen.
-
Wenn das ANSI SS7-Protokoll in der
spezifischen Kommunikationsapplikation verwendet wird, werden SS7-Meldungen von der
OSI-Schicht 7 auf dem Schicht 3 Pegel paketiert
und von der Testapplikation 22 an die unter Test stehende
Einheit 52 unter Verwendung der UNIX-Plattform und Betriebsmittel durchlaufen.
Die unter Test stehende Einheit empfängt die Daten zur Verarbeitung,
führt Funktionen
in der unter Test stehenden Einheit aus und kann eine Antwortinformation
für OSI-Schichten 3–7 zur
Handhabung in der Testapplikation paketieren.
-
6 ist
ein Blockdiagramm einer Ausführungsform
der vorliegenden Erfindung, in welcher eine Protokollsimulation-Testvorrichtung (Protokollsimulator) 60 über Internetsockets 61 und 62 eine Schnittstelle
mit einem UNIX-Prozess 63, welcher eine Zielsystem-Emulation
durchläuft,
ausbildet. Der Protokollsimulator 60 umfasst einen UNIX-Prozess, welcher
standardisierte Simulationstools ablaufen lässt. Die standardisierten Tools
enthalten eine Testscript-Software 64, welche die Rufaufbaufunktionen durchführt. Diese
Scripte werden dann in OSI-Schichten 3–7 in Block 65 eingebaut
und an einen UNIX-Adapter 66 gesendet. Der UNIX-Adapter paketiert
die Schichten in TCP/IP-Format zur Übertragung über Internet-Sockets 61 und 62 und
einer LAN-Verbindung 67 an den UNIX-Prozess, welcher die Zielsystememulation 63 ablaufen
lässt.
Der Emulationsprozess 63 enthält einen Protokoll Schnittstellen-Gateway
(PIG-Tool) 68 und einen Zielsystememulator 69.
Das PIG-Tool 68 entpackt die OSI-Schichten, welche von dem Socket in TCP/IP-Format
empfangen wurden, und konvertiert sie auf Prozessorbefehle. Die
Befehle werden dann an den Zielsystememulator 69 passiert.
-
Der Zielsystememulator 69 emuliert
die Hardware eines Ziel-Telekommunikationsknotens, welcher
in der UNIX-Umgebung betrieben wird, und ist in der Lage, Signalisierungsinformation
an dem OSI-Schicht 3 Pegel oder höher zu senden und zu empfangen.
Der Emulator 69 kann mit einer Schnittstellenapplikation
kommunizieren, welche Internet-Sockets oder andere UNIX-Betriebsmittel,
wie zum Beispiel Pipes oder Schnittstelle 67, verwendet, um
die OSI-Schicht 3–7 Information
zu senden und zu empfangen. Nach einem Durchführen erforderlicher Funktionen
auf der empfangenen Information kann der Emulator mit Rückkommunikationen
zum Protokollsimulator 60 antworten, indem dasselbe Verfahren
eines Paketierens in TCP/IP-Format und eine Übertragung über Internet-Sockets verwendet werden,
um die Daten an den Protokollsimulator zur Verifizierung durch das
Testscript zu übertragen.
-
7 ist
ein vereinfachtes Blockdiagramm eines automatisierten Diagnosesystems 70,
in dem sowohl ein Ziel-Telekommunikationsvermittler 71 und ein
Vermittleremulator 72 mit einem Protokollsimulator 73 gemäß den Lehren
der vorliegenden Erfindung verbunden sind. Der Protokollsimulator 73 kann
in unterschiedlichen Computererzeugten Figuren alternativ als Protocol
Adaptable State Machine (PASM) oder als Message Generator Traffic
Simulator (MGTS) bezeichnet werden. Der Protokollsimulator 73 ermöglicht es
einem Benutzer entweder einen tatsächlichen Ziel-Hardwareknoten
oder einen durch Software emulierten Knoten für das Testen von OSI-Schichten 3–7 auszuwählen. Wenn
ein Hardwareknoten ausgewählt
wird (beispielsweise der Ziel- Telekommunikationsvermittler 71),
identifiziert ein Kommunikationsmanager 74 diese Auswahl
an ein Protokoll-Simulationssocket-Adaptionsmodul (Protokollsimulationsadapter) 75,
welcher dann die korrekte Protokollsimulationssoftware 76 und
den Protokoll-Stapel 77 für den Hardware-Knoten auswählt. Meldungen
in einem UNIX-basierten TCP-IP-Protokoll werden über einen von einer Vielzahl
von Internet-Sockets 78 an ein LAN 79 gesendet.
Diese Meldungen treten an dem LAN über einen Internet-Socket 81 aus,
und werden an einen UNIX-Adapter 82 gerichtet. Der UNIX-Adapter 82 übersetzt
das TCP/IP-Protokoll in SS7-Meldungen, welche von dem Ziel-Telekommunikationsvermittler 71 verstanden
werden.
-
Wenn ein Emulator ausgewählt wird
(beispielsweise der Vermittleremulator 72), identifiziert der
Kommunikationsmanager 74 diese Auswahl an einen Protokollsimulationsadapter 75,
welcher dann die korrekte Protokollsimulationssoftware 76 und
den Protokoll-Stapel 77 für das emulierte System auswählt. Meldungen
im UNIX-basierten TCP/IP-Protokoll werden über einen von der Vielzahl
an Internet-Sockets 78 an das LAN 79 gesendet.
Die Meldungen treten an dem LAN über
ein Gateway-Internet-Socket 83 aus, und werden in der bevorzugten Ausführungsform
an einen Protokoll Schnittstellen-Gateway (PIG-Tool) 84 gerichtet.
-
Der Protokollsimulationsadapter 75 ist
eine Simulation eines Message Generation Traffic Simulator (MGTS)
Hardwaregehäuses,
welches als ein Prozess oder eine Gruppe an Prozessen auf einer
Arbeitsstation läuft.
Der Protokollsimulationsadapter 75 enthält Protokollsimulationssoftware 76 und
damit in Verbindung stehende Protokoll-Stapel 77. Dies
bietet die Möglichkeit
an, eine Testsequenzverifikation durchzuführen, ohne auf ein Hardwaregehäuse zuzugreifen.
Benutzer können
vor einem Verbinden mit dem Zielhardwareknoten 71 oder 72 Testsequenzen auf
Fehler beseitigen (debug) und auf Fehler untersuchen (trouble shoot).
-
Zur Kommunikation mit einem Emulator
verwendet der Protokollsimulationsadapter 75 das SS7 TCP/IP-Protokoll.
Testmeldungen können
ebenfalls Header-8 Bitzeichen enthalten, welche zwischen dem Protokollsimulator
und Ziel- oder emulierten Telekommunikationsknoten proprietär sind,
um die Quelle der Meldungen, die Meldungslänge, Protokolländerung,
etc. zu identifizieren. Die Testmeldungen werden über einen
der Internet-Sockets 78 über das LAN 79, wie
z. B. Ethernet, über
den Gateway-Internet-Socket 83 an PIG-Tool 84 übertragen.
Das PIG-Tool 84 streift das TCP/IP-Protokoll und die Header
ab und wandelt die Testmeldungen in CPU-Befehle um. Die CPU-Befehle
werden dann zur Verarbeitung und Ausübung der zu testenden Software
an den Emulator 72 gesendet. Der Emulator 72 enthält die Applikationssoftwareblöcke 85 von
dem simulierten Telekommunikationsknoten, als auch Softwaremodule,
welche die Hardware des Zielknotens emulieren. Der Emulator übt die zu
testende Software aus, verifiziert die Verwendung des simulierten
Kommunikationsprotokolls mit dem Ziel-Telekommunikationsknoten und erwidert
in Richtung des Protokollsimulators 73. Daher kann der
Protokollsimulator 73 zum Testen der Applikation auf der
Zielhardware 71 verwendet werden, indem dieselben Testsequenzen verwendet
werden, nachdem ein Benutzer Testsequenzen für eine Applikation auf dem
Emulator 72 entwickelt.
-
Der Protokollsimulator 73 kann
ebenfalls gleichzeitig Testapplikationen über den Internet-Socket 78 und über eine physikalische
Schnittstelle 86 mit der Ziel-Host-Hardware 71 testen.
Zusätzlich kann
der Protokollsimulator 73 weitere Testvorrichtungen (nicht
gezeigt) über
den Internet-Socket 78 und das LAN 79 steuern.
-
8 ist
ein detaillierteres Blockdiagramm des UNIX-basierten Emulators 72 und
PIG-Tools 84 von 7.
Der Protokollsimulator 72, welcher Hooks in dem Protokollsimulationsadapter 75 enthält, lässt die
Protokollsimulationssoftware 76 ablaufen. In der bevorzugten
Ausführungsform
ist der Protokollsimulator 73 so konfiguriert, dass er
zwölf Benutzern
dient und einen Sparc 20 Server von SUN Microsystems verwendet,
welcher 32 MB RAM und 1000 MB Wechselplatz (swap space) auf der
Festplatte des Servers hat. Der UNIX-basierte Emulator 72 und
das PIG-Tool 84 können
auf einer SUN Sparc 5 Workstation betrieben werden, welche 32 MB
RAM und 200 MB Wechselplatz auf der Festplatte der Workstation hat.
Bei einer Ausführungsform,
welche einem einzigen Benutzer dient, kann der Protokollsimulator 73 ebenfalls
auf einer Sun Sparc 5 Workstation betrieben werden. Diese Hardwarekonfigurationen
werden nur aus veranschaulichenden Gründen beschrieben und dienen
nicht dazu, den Umfang der vorliegenden Erfindung zu begrenzen,
welche mit anderen Hardware-Konfigurationen implementiert werden
kann.
-
Das PIG-Tool 84 empfängt unbearbeitete SS7
8 Bitzeichen (OSI-Schichten 3–7) 87,
mit oder ohne proprietären
Header 8-Bitzeichen,
vom Gateway Internet Socket 83, welcher mit dem Ethernet LAN 79 verbunden
ist. Die SS7 8 Bitzeichen laufen über ein Virtual Patch Panel
(VPP) 88 in das PIG-Tool 84 ein. Innerhalb des
PIG-Tools werden die SS7 8-Bitzeichen gesammelt, bis eine komplette
SS7 Message Signal Unit (MSU) empfangen wird.
-
Das PIG-Tool 84 empfängt die
Quelle der MSU über
den Internet-Socket, auf welchem die MSU empfangen wurde. Wenn die
MSU vom Protokollsimulator 73 empfangen wurde, werden die
proprietären
Header 8-Bitzeichen, sofern sie vorliegen, abgestreift und verarbeitet.
Wenn die MSU vom Emulator 72 in der Form von einem oder
mehreren Emulatorbefehlen empfangen wurde, werden diese Befehle
durch das PIG-Tool in einem MSU-Puffer
(nicht gezeigt) verarbeitet.
-
Wenn die MSU vollständig empfangen
wurde, zieht das PIG-Tool 84 Routing-Tabellen zu Rate, welche
durch den Benutzer spezifiziert wurden, und in dem VPP 88 intern
gespeichert und aufrechterhalten werden. Die Routing-Tabellen bringen
Quelleneinträge
mit Zieleinträgen
in Verbindung. Sobald das Ziel der MSU von den Routing-Tabellen
bestimmt wird, verarbeitet das PIG-Tool die Meldungen in das geeignete
Form für
das Ziel. Wenn der Protokollsimulator 73 das Ziel ist,
zieht diese Verarbeitung die optionale Verkapselung der MSU mit
dem proprietären Header
ein, sofern einer verwendet wurde. Wenn das Ziel der MSU der Emulator 72 ist,
wird die MSU in der geeigneten Anzahl an Emulatorbefehlen abgebrochen
und zur Verarbeitung durch den zu testenden Softwarebefehl in den
Emulator gesendet.
-
9 ist
ein vereinfachtes Blockdiagramm, welches die Simulation von einer
Vielzahl von Leitungsschnittstellenkarten (LICs) 91 durch
den Protokollsimulator 73 und ihre Verbindungen über Internet-Sockets 78 und 83 und
LAN 79 an einen Emulator 92 und an eine Vielzahl
von simulierten Signalisierungspunkten 93 darstellt.
-
In einer Ausführungsform der vorliegenden Erfindung
kann der Protokollsimulator 73 bis zu 16 LICs 91 simulieren
und der Emulator 92 kann mit bis zu 16 Signalisierungspunkten 93 an
das LAN verbinden, wobei alle davon über Internet-Sockets 78 und 83 und
ein Ethernet LAN 79 verbunden sind. Diese Anzahl an LICs
und Signalisierungspunkten ist keine Begrenzung auf die vorliegende
Erfindung, sondern wird nur als eine beispielhafte Ausführungsform
dargelegt. In anderen Ausführungsformen
kann eine höhere
oder geringere Anzahl an LICs und Signalisierungspunkten verwendet
werden.
-
Detailliertes
Beispiel
-
10 ist
eine Darstellung einer Computerangezeigten Piktogramm-Toolbox 100,
welche von einem Bediener verwendet werden kann, um ein Testen mit
dem Entwicklungstestsystem der vorliegenden Erfindung einzuleiten.
Der Bediener kann das System entweder von der Emulator-Arbeitsstation oder
der Protokollsimulator-Arbeitsstation aus steuern. Ein erstes PIG-Tool-Piktogramm 101 wird
mit „Socket" bezeichnet und ein
zweites PIG-Tool-Piktogramm 102 wird mit „normal" bezeichnet. Das PIG-Tool 84 ist
in der Lage, eine Schnittstelle mit zwei unterschiedlichen Emulatoren
zu bilden, wobei einer Socketbasiert ist und einer ein „normaler" Emulator ist, welcher
nicht Socket-basiert ist, und diese Piktogramme werden verwendet,
um den Typ an Emulator zur Bildung einer Schnittstelle mit dem PIG-Tool
auszuwählen.
Ein „MGTS"-Piktogramm 103 wird zur Einleitung
der Protokollsimulationssoftware 76 in dem Protokollsimulator 73 verwendet.
-
11 ist
eine Darstellung eines Computerangezeigten Shelf-Auswahlmenüs 110,
welches es einem Bedieneer ermöglicht, ein
tatsächliches
Hardware-System oder ein emuliertes System zu Testzwecken auszuwählen. Eine
Auswahl eines Menüelements,
welches mit „real" bezeichnet wird,
verbindet den Protokollsimulator 73 mit einem realen Ziel-Hardwaresystem.
Eine Auswahl eines Menüelements,
welches mit „exu..." beginnt, verbindent
den Protokollsimulator 73 mit einem emulierten System. Die
emulierten Systeme werden in drei Kategorien – klein, mittel und hoch – eingeteilt,
und zwar in Abhängigkeit
von der Anzahl an Leitungsschnittstellenkarten (LICs) 91,
welche mit dem ausgewählten
Menüelement
in Verbindung stehen.
-
12 ist
eine Darstellung eines Computerangezeigten Netzwerk-Abbildungseditors 120,
welcher zur Bestimmung der Testumgebung mit dem Entwicklungstestsystem
der vorliegenden Erfindung verwendet wird. Ein Satz an simulierten
Knoten 121 bis 130 umrundet einen unter Test stehenden
Knoten (Testknoten) 131, welcher sich im Zentrum des Displays
befindet. Der Testknoten 131 kann ein reales Ziel-Hardwaresystem oder
ein emuliertes System sein, und zwar in Abhängigkeit von der Systemart, welche
durch den Bediener ausgewählt
wird, indem er das Shelf-Auswahlmenü 110 von 11 verwendet. Wenn der Bediener
ein reales Ziel-Hardwaresystem
auswählt,
dann sind die Verbindungen 132 zwischen dem Testknoten 131 und
den umrundenden Knoten 121 bis 130 physikalische
Verbindungen. Wenn der Bediener ein emuliertes System auswählt, dann
sind die Verbindungen 132 zwischen dem Testknoten 131 und
den umrundenden Knoten 121 bis 130 simulierte
SS7-Verbindungen. Jeder Knoten wird mit einem Signalisierungspunktcode
(beispielsweise 7-9-60) und einem kurzen Namen für den simulierten Knoten (beispielsweise
MSC 4) bezeichnet.
-
13 ist
eine Darstellung einer Computerangezeigten Netzwerk-Abbildung (Simulationsscript),
welche eine Simulation in dem Protokollsimulator einer einfachen
Ort-Aktualisierungssequenz darstellt,
welche in einem Basisstation-Steuerer (BSC) in einem Personal Communication
System (PCS) mobilen Telekommunikationssystem ausgeführt wird.
Wenn ein mobiler Teilnehmer ein mobiles Telefon einschaltet, wird
die Ortsaktualisierungssequenz eingeleitet, wie bei Schritt 136 der
Protokollsimulation des BSC gezeigt. Der BSC sendet dann eine Ortsaktualisierungsanforderungsmeldung 137 an
sein Mobilvermittlungscenter (MSC), welches wiederum den Ort des
mobilen Teilnehmers in dem Heimatortsregister (Home Location Register
HLR) aktualisiert. Eine Bestätigungsmeldung
wird dann von dem MSC an den BSC bei 138 zurückgegeben.
-
In 13 sind
simulierte Knoten, welche Meldungen empfangen, mit von einer zentralen
vertikalen Linie aus nach links gerichteten Pfeilen dargestellt.
Simulierte Knoten, welche Meldungen übertragen, sind mit von der
zentralen vertikalen Linie aus nach rechts gerichteten Pfeilen dargestellt.
Simulierte Knoten, welche zugleich Meldungen empfangen und übertragen,
sind mit von der zentralen vertikalen Linie aus nach beiden Richtungen
gerichteten Pfeilen dargestellt. Ein simulierter Knoten 139,
welcher mit „Loop" bezeichnet ist,
befindet sich im Zentrum des Displays, und ist ein Haltepunkt, bei
welchem die Simulation auf eine andere zu empfangene Meldung wartet.
Ein Zeitnehmer 141 überwacht
die Schleife nach Aktivität,
und wenn es während
einer vorliegenden Zeitperiode (beispielsweise 10 sec) keine Aktivität gibt,
wird die Testsequenz gestoppt.
-
Die Verarbeitung startet bei Knoten 136 und bewegt
sich zum Knoten 137, wo das BSC die Ortsaktualisierungsanforderungsmeldung
an dem MSC überträgt. Bei
dem Entwicklungstestsystem der vorliegenden Erfindung kann diese
Anforderungsmeldung an ein reales Ziel MSC und HLR gehen oder durch
das PIG-Tool 84 an einen Emulator mit Verkehrshandhabungssoftware
und einen eingebauten HLR gehen. Die Ortsaktualisierungsanforderungsmeldung
ist im SS7-Format, und das PIG-Tool wandelt sie in Emulatorbefehle
um. Wenn der Emulator die Anforderung verarbeitet und erwidert,
wandelt das PIG-Tool die Erwiderung in das SS7-Format zur Übertragung
an die BSC-Simulation zurück.
Wenn der MSC-Emulator mit einer Anforderungsmeldung erwidert, empfängt die
BSC-Simulation eine Verbindungsbestätigung (CC) Meldung an Knoten 138.
Die Verarbeitung bewegt sich dann an den Schleifenknoten 139 weiter
und wartet auf den MSC-Emulator, um auf die Anforderungsmeldung
zu erwidern. Wenn die Ortsaktualisierungsanforderungsmeldung akzeptiert wird,
empfängt
die BSC-Simulation eine Ortsaktualisierungsakzeptanzmeldung an Knoten 142.
Die Verbindung zum MSC/Emulator wird dann an Knoten 143 gelöscht, und
eine Freisetzungsvollendungsmeldung wird an Knoten 144 gesendet.
Die Verarbeitung endet dann bei 145.
-
14 ist
eine Darstellung eines Computer-dargestellten Menüs 146 von
Protokollsimulationssystemen (virtual shelves) 148, auf
welches das PIG-Tool 184 zugreifen kann. Diese Liste ist
identisch mit den Protokollsimulationssystemen, welche in dem Shelf-Auswahlmenü 110 in
dem in 11 dargestellten
Protokollsimulator aufgelistet sind. Wenn ein Protokollsimulationssystem
ausgewählt
wird (beispielsweise exuboge large 149), wird eine Liste
an erhältlichen
Knoten oder Leitungsschnittstellenkarten (LICs) 151, welche
mit dem ausgewählten
System in Verbindung stehen, dargestellt. Die Liste an LICs 151 enthält ebenfalls
eine Referenz an Signalisierungspunkten (STs), welche mit Daten
in dem emulierten Telekommunikationssystem in Verbindung stehen. Sobald
der Bediener das Protokollsimulationssystem und die LICs auswählt, welche
beim Testen zu verwenden sind, baut ein Klicken auf den Knopf 152, welcher
mit „MGTS
Virtual Shelf" gekennzeichnet
ist, eine Verbindung mit dem Gateway-Schnittstellen-Socket 83 (7) auf. Wenn diese Verbindung
hergestellt wird, baut ein Klicken auf den „Emulator"-Knopf 153 eine Verbindung
zum Emulator auf. Somit erstellt das PIG-Tool 84 eine Verbindung zwischen
einem simulierten LIC, welcher durch den Protokollsimulator erzeugt
wird, und einem Signalisierungspunkt in dem emulierten System auf.
-
15 ist
eine Darstellung eines Computerdisplays 155, welches drei
Statusfenster zeigt, welche dem Protokollsimulator (gekennzeichnet
mit PASM Simulation) 156, dem PIG-Tool 157 und dem emulierten
System (gekennzeichnet mit EmuTool) 158 entsprechen. Ein
oberer Abschnitt 159 des Protokoll-adaptierbaren Zustandsmaschine
(PASM) Simulationsfensters 156 zeigt an, dass die Ortsaktualisierungssequenz
in dem mobilen Vermittlungscenter/Heimatortsregister (MSC/HLR) durchgeführt wurde,
und dass die BSC-Protokollsimulation durch den Protokollsimulator
verifiziert wurde. Ein mittlerer Abschnitt 161 ist eine
Anmeldung (log), welche anzeigt, wie oft bestimmte Meldungen übertragen
und empfangen wurden. Ein unterer Abschnitt 162 stellt
das Simulationsscript 135 von 13 dar, wobei der Pfad der Simulation
durch Pfeile angezeigt wird.
-
Das PIG-Tool Fenster 157 enthält einen
oberen Abschnitt 163, welcher das Menü von Protokollsimulationssystemen
(virtual shelves) 148 zeigt, auf welches das PIG-Tool 84 zugreifen
kann. Ein unterer Abschnitt 164 ist ein Meldungsbeobachter,
welcher Daten über
die Meldungen, welche zwischen dem Protokollsimulator 73 und
dem PIG-Tool 84 übertragen
und empfangen wurden, bereitstellt, wenn die Daten durch den Gateway-Socket 83 (7) durchlaufen.
-
Das Emulatorfenster 158 stellt
Information auf Befehle und Daten, welche vom PIG-Tool 84 an den
Emulator 72 gehen, bereit. Wie in 9 gezeigt, wandelt ein Umwandler 94 in
dem PIG-Tool 84 die SS7 hex in Emulatorcode um und sendet
ihn an eine Applikation-Programmierschnittstelle (API) 95.
Ein oberer Emulatoranmeldeabschnitt 165 (15) zeigt die in Emulatorcode 166 empfangenen
Befehle und den Signalverbindungspunkt 167 für jeden
empfangenen Befehl. Ein unterer Befehlsabschnitt 168 (teilweise
verborgen) stellt eine gekürzte
Version der vom PIG-Tool 84 an den Emulator 72 gesendeten
Befehle bereit.
-
16 ist
eine detailliertere Auflistung des Meldungsüberwachungsabschnittes 164 des PIG-Tool
Statusfensters 157 von 15.
Es werden Daten auf allen LICs bereitgestellt, welche zum Testen
ausgewählt
wurden. Das Fenster 164 stellt eine Quelle für jede Meldung
(beispielsweise „Empfangen von
MGTS Plattform") 171,
proprietäre
Header-Information 172 und die in der Meldung beförderten
Daten 173 dar. Die Header-Information 172 zeigt die Änderung,
Protokollrichtung und die Länge
der SS7-Meldung an. Die Meldungsdaten 173 werden in 8-Bitzeichen (8 Bits)
von SS7-Daten in hexadezimaler Darstellung dargestellt. Das PIG-Tool 84 kann
Meldungen an den Emulator 72 senden, und zwar zur selben Zeit,
wenn es Meldungen vom Protokollsimulator 73 (7) empfängt.