DE60033283T2

DE60033283T2 - Verfahren und systeme zur mitteilung von ss7-nachrichten über ein paketbasiertes netz unter verwendung einer transportanpassungsschichtschnittstelle

Info

Publication number: DE60033283T2
Application number: DE60033283T
Authority: DE
Inventors: Darren Robby Raleigh BENEDYK; Michael David Raleigh SPRAGUE; Alan Dan Raleigh BRENDES
Original assignee: Tekelec Inc
Current assignee: Tekelec Global Inc
Priority date: 1999-06-07
Filing date: 2000-06-06
Publication date: 2007-08-30
Anticipated expiration: 2020-06-07
Also published as: EP1192758B1; EP1192758A4; ATE353507T1; WO2000076134A1; AU5466800A; ES2282118T3; DE60033283D1; EP1192758A1

Description

Technischer Bereich
Die vorliegende Erfindung bezieht sich auf Verfahren und Systeme für das Kommunizieren bzw. Mitteilen von SS7-Nachrichten über ein paketbasiertes Netzwerk. Spezieller ausgedrückt, die vorliegende Erfindung bezieht sich auf Verfahren und Systeme zum Kommunizieren von SS7-Nachrichten über ein paketbasiertes Netzwerk, wobei ein Transportadapterschicht-Interface bzw. -Schnittstelle benutzt wird.
Hintergrund des Standes der Technik
Das traditionelle öffentliche Telefonnetzwerk (PSTN) besteht aus Signalisierungsknoten, welche über dedizierte bzw. festgeschaltete Signalisierungssystem-7-(SS7-)Signalisierungsverbindungen verbunden sind. Die drei primären Typen von Signalisierungsknoten in dem herkömmlichen PSTN-Netzwerk sind Dienstvermittlungsstellen (SSPs), Signalübertragungspunkte bzw. Zeichengabe-Transferstellen (STPs) und Dienststeuerstellen (SCPs). Dienstvermittlungsstellen sind Teilnehmervermittlungsstellen, welche sowohl Sprach- als auch Datenverkehr handhaben. Signalübertragungspunkte sind Schalt- bzw. Vermittlungsknoten, welche SS7-Nachrichten zwischen SS7-Signalisierungspunkten routen bzw. leitweglenken. Dienststeuerstellen sind Datenbanken und zugehörige Computer, welche Daten in Antwort auf SS7-Anfragen liefern. Beispiele für derartige Daten beinhalten Abrechnungsinformationen, 800er-Nummer-Umsetzungsinformationen und Nummernübertragbarkeitsinformationen.
Diese herkömmlichen SS7-Knoten haben typischerweise kommuniziert, indem sie über SS7-Nachrichten zueinander über festgeschaltete SS7-Signalisierungsverbindungen gesendet haben. Während derartige Signalisierungsverbindungen eine hohe zuverlässige Einrichtung für das Kommunizieren von SS7-Verkehr liefern, liefern SS7-Signalisierungsverbindungen für einen Benutzer nur feste Bandbreite ohne Rücksicht auf die Notwendigkeiten für den Benutzer. Eine Folge davon ist, dass die Benutzer eine ausreichende Anrufsignalisierungsbandbreite installieren oder mieten müssen, um Spitzen- oder Schlimmster-Fall-Verkehrszustände der schlimmsten Art handzuhaben. Das Installieren oder das Mieten bzw. Leasen von ausreichender Anrufsignalisierungsbandbreite für Spitzenbelastungszustände ist ineffizient, da Spitzenbelastungszustände sehr selten auftreten. Außerdem, da die SS7-Anrufsignalisierungsbandbreite teuer ist, besteht eine Notwendigkeit für eine Alternative zu den dedizierten SS7-Signalisierungsverbindungen.
1 ist ein Blockschaltbild eines herkömmlichen PSTN-Netzwerks. In 1 kommunizieren SSPs 100 und 102 mit SSPs 104 und 106 über die STPs 108, 110, 112 und 114. Die SCP-Datenbankknoten 116 und 120 liefern Daten in Antwort auf Anfragen von den SSPs 100, 102, 104 und 106 und/oder von den STPs 108, 110, 112 und 114. Alle Leitungen, welche die Knoten in 1 verbinden, stellen herkömmliche SS7-Signalisierungsverbindungen dar. Wie oben festgestellt wurde, werden derartige Verbindungen oft unterbenutzt und sind teuer zu installieren oder zu leasen.
In paketbasierten Netzwerken, wie z.B. Übertragungssteuerprotokoll/Internetprotokoll-(TCP/IP-)Netzwerken, kann die Bandbreite von vielen Benutzern gemeinsam genutzt werden. Zusätzlich hat das Wachsen und die Popularität des globalen Internets Komponenten für derartige Netzwerke schließlich verfügbar und die Kosten effizient gemacht. Jedoch schafft das Integrieren des herkömmlichen PSTN-Netzwerks mit einem paketbasierten Netzwerk, wie z.B. einem TCP/IP-Netzwerk, eine Anzahl von Problemen.
Zum Beispiel besteht ein Problem beim Senden von herkömmlichem Anrufsignalisierungsverkehr über ein TCP/IP-Netzwerk darin, dass in einem TCP/IP-Netzwerk Übertragungen zwischen einem Sender und einem Empfänger stromorientiert sind. D.h., die TCP-Software auf einer Sendemaschine garantiert nicht, die Daten in den gleichen Grenzen zu senden, welche durch eine Sendeapplikation definiert sind. Der Betrag an Daten, welcher über eine TCP-Verbindung gesendet wird, hängt von der Fenstergröße, welche durch den Empfänger angeboten wird, von der Anzahl von Bytes an Daten, welche von dem Empfänger bestätigt wurden, und von der maximalen Segmentgröße des physikalischen Netzwerks ab, welches den Sender und den Empfänger verbindet. Entsprechend kann die empfangende Anwendung die Daten nicht in den gleichen Grenzen empfangen, welche durch die Sendeanwendung geschaf fen ist. Demnach können mehrere Nachrichten, wenn Anrufsignalisierungsnachrichten über ein TCP/IP-Netzwerk gesandt werden, in einem TCP-Segment kombiniert werden. Alternativ kann eine einzelne Anrufsignalisierungsnachricht unter vielen TCP-Segmenten aufgeteilt werden. In herkömmlichen Netzwerken ist es die Aufgabe der empfangenden Applikation bzw. Anwendung, den eingehenden Datenstrom lexalisch zu zerlegen und die individuellen Pakete auszukoppeln. Derartiges lexalisches Zerlegen ist schwierig und erhöht die Komplexität von Anwendungsprogrammen, welche TCP benutzen.
Ein anderes Problem beim Senden herkömmlicher Anrufsignalisierungsnachrichten über eine TCP/IP-Verbindung besteht darin, dass die Dauer der Auszeit für das Abschalten der Verbindung in dem TCP für Anrufsignalisierungsanwendungen zu lang ist. Beispielsweise beinhalten einige Implementierungen des TCP ein Haltezeitglied. Das Haltezeitglied wird jedes Mal, wenn ein TCP-Segment empfangen wird, zurückgesetzt. Solange das Zeitglied andauert, veranlasst es eine Seite der Verbindung zu bestimmen, ob die andere Seite noch in Betrieb ist. Es wird kein Mechanismus in den TCP-Protokoll-Spezifikationen spezifiziert, um zu bestimmen, ob die andere Seite in Betrieb ist. Zusätzlich beträgt die Auszeitdauer für das Haltezeitglied größenordnungsmäßig Minuten. Demnach könnte eine Seite einer Verbindung ausgehen, und die andere Seite könnte minutenlang warten, bevor die Verbindung zurückgesetzt wird. Eine derart lange Auszeitdauer verbraucht Ressourcen auf der Maschine, welche auf Daten von der anderen Seite wartet, und ist für Telefonapplikationen ungeeignet.
Noch ein weiteres Problem beim Integrieren von herkömmlicher Telefonie und paketbasierten Netzwerken, wie z.B. TCP/IP-Netzwerken, besteht darin, dass der TCP/IP langatmige Übergabeprozeduren für das Aufbauen und das Beenden der Verbindung benötigt. Beispielsweise sendet eine Client- bzw. Vorfeldrechner-Anwendung, um eine TCP-Verbindung aufzubauen, ein Synchronisations-(SYN-)Paket an eine Server- bzw. dienstleistender Rechner-Anwendung. Die Server-Anwendung sendet dann eine Bestätigung (ACK) und eine XYN zurück an den Client. Der Client sendet dann eine Bestätigung an das SYN + ACK vom Server. Während dem Anfangsaustausch von SYN- und ACK-Nachrichten tauschen der Client und der Server Frequenz- bzw. Reihenfolgenummern aus. Sobald der Client die Bestätigung an den SYN + ACK zum Server sendet, befindet sich die TCP-Software auf der Client- Maschine in einem offenen Zustand, in welchem Daten von dem Server empfangen werden können, und Daten von der sendenden Anwendung an den Server gesandt werden können.
Um eine TCP-Verbindung zu beenden, wenn eine Anwendung eine Verbindung schließt, sendet die TCP-Software, welche zu der Anwendung gehört, ein FIN-Paket bzw. Beendigungspaket an die TCP-Software auf der anderen Seite der Verbindung. Die TCP-Software der Maschine, welche das FIN empfängt, sendet ein ACK an das FIN und informiert die Anwendung, dass ein FIN empfangen wurde. Falls die Anwendung das Senden von Daten beendet, schließt die Anwendung. In Antwort auf das Schließen der Anwendung sendet die TCP-Software ein FIN an die TCP-Software, welche das Original-FIN gesandt hat. In Antwort auf das Empfangen des FIN sendet die Software ein ACK. Sobald dieses ACK gesendet ist, wird die Verbindung für beide Seiten der Verbindung als geschlossen bzw. beendet betrachtet.
Während sich die Erstellungs- und Beendigungsprozeduren der TCP-Verbindung als zuverlässig herausgestellt haben und für eine Vielzahl von Fehlerzuständen verantwortlich sind, sind derartige Prozeduren mühsam und erfordern vielmalige Umläufe, um vollendet zu werden. Beispielsweise ist für das Erstellen einer TCP-Verbindung minimal ein 1,5-facher Umlauf erforderlich. In dem oben beschriebenen TCP-Verbindungsbeendigungs-Szenario werden wenigstens zweimalige Umläufe erforderlich. Zusätzlich ist auf beiden Seiten der Verbindung TCP-Software erforderlich, um den Zustand aufrechtzuerhalten und um zusätzliche Verarbeitung während der Verbindungserstellung und -beendigung durchzuführen.
Wegen all dieser Gründe sollte die Anzahl des Auftretens von TCP-Prozeduren zur Verbindungserstellung und -beendigung minimiert werden. Beispielsweise, falls gewünscht wird, Software in einer Telefoneinrichtung, welche aktuell mit einer entfernten Einrichtung über eine TCP-Verbindung kommuniziert, hochzurüsten, muss die Verbindung beendet werden. Das Beenden der Verbindung erfordert das oben beschriebene Übergabeverfahren. Sobald die Software hochgerüstet ist, muss die Verbindung wieder erstellt werden. Das Wiedererstellen der Verbindung erfordert das oben beschriebene Drei-Wege-Übergabeverfahren. Demnach erfordert das Durchführen des Hochrüstens der Software eine Anfangs-TCP-Verbindungserstellung, eine TCP-Verbindungsbeendigung, auf welche eine andere TCP- Verbindungserstellung folgt. Diese Verfahren verbrauchen Ressourcen und sollten minimiert werden, speziell in Telekommunikationsvermittlungen mit hohem Verkehr.
Im Hinblick auf all diese Schwierigkeiten, welche zum Integrieren herkömmlicher Telefonnetzwerke gehören, wie z.B. von SS7-Netzwerken und stromorientierten paketbasierten Netzwerken, wie z.B. TCP-Netzwerken, besteht eine Notwendigkeit für neue Verfahren und Systeme zum Integrieren dieser Netzwerke, welche wenigstens einige der Schwierigkeiten, welche mit dem Stand der Technik verbunden sind, vermeiden.
Offenlegung der Erfindung
Die vorliegende Erfindung beinhaltet Verfahren und Systeme zum Kommunizieren von SS7-Nachrichten zwischen Signalisierungsknoten über ein paketbasiertes Netzwerk, wobei ein Transportadapterschicht-Interface benutzt wird. Der Ausdruck Transportadapterschicht-Interface, wie er hier benutzt wird, bezieht sich auf ein Interface, welches oberhalb der Transportschicht in dem TCP-Protokollstapel angeordnet ist, welcher die Integration zwischen dem SS7-Protokollstapel und dem TCP/IP-Protokollstapel erleichtert. Ein derartiges Interface beinhaltet die Funktionalität für das Verhindern und das Zulassen von Kommunikationen über einen Socket bzw. logischen Verbindungspunkt, ohne herkömmliche TCP-Verbindungserstellungs- und -beendi-gungs-Übergabeverfahren aufzurufen. Zusätzlich liefert das Interface Überwachungs- und Testnachrichten, welche jeweils benutzt werden, um die Leistungsfähigkeit und den Teststatus einer Verbindung zu messen. Das Interface liefert auch einen Mechanismus zum Verkapseln von SS7-Nachrichten, welche eine individuelle Nachrichtenidentifikation über eine stromorientierte Verbindung gestatten.
Ausführungsformen der Erfindung werden nachfolgend als Module, Schichten oder Verfahren zum Implementieren von SS7- und IP-Kommunikationsfunktionen beschrieben. Es ist davon auszugehen, dass diese Module, Schichten oder Verfahren als Hardware, Software oder als eine Kombination von Hardware und Software implementiert werden können. Beispielsweise wird die Funktionalität des Transportadapterschicht-Interface nachfolgend als ein Verfahren beschrieben, welches auf einem Datenkommunikationsmodul implementiert ist. Der Daten kommunikationsmodul kann Hardware beinhalten, wie z.B. einen Mikroprozessor und einen zugehörigen Speicher für das Ausführen und Speichern von Programmen. Das TALI-Verfahren kann durch den Mikroprozessor ausgeführt werden, um die nachfolgend beschriebenen TALI-Funktionen durchzuführen.
Entsprechend ist es eine Aufgabe der Erfindung, neue Verfahren und Systeme für das Kommunizieren von SS7-Nachrichten über ein stromorientiertes, paketbasiertes Netzwerk zu liefern, welche die Probleme mit herkömmlichen stromorientierten, paketbasierten Netzwerken vermeiden.
Es ist eine weitere Aufgabe der Erfindung, Verfahren und Systeme zu liefern, um Dienstdatenkommunikation über eine stromorientierte Verbindung ohne das Aufrufen eines TCP-Übergabeverfahrens zu gestatten und zu verhindern.
Es ist noch eine weitere Aufgabe der Erfindung, Verfahren und Systeme zu liefern, um empfangene Nachrichtenpakete über eine stromorientierte Verbindung zu identifizieren.
Einige der Aufgabe der Erfindung wurden hier oben aufgeführt, andere Aufgaben werden im Laufe der Beschreibung offensichtlich, wenn diese zusammen mit den Zeichnungen, welche nachfolgend bestens beschrieben werden, in Verbindung gebracht werden.
Kurze Beschreibung der Zeichnungen
Bevorzugte Ausführungsformen der Erfindung werden nun in Bezug auf die beigefügten Zeichnungen beschrieben, in welchen:
1 ein Blockschaltbild ist, welches das herkömmliche PSTN-Netzwerk darstellt;
2 ein Blockschaltbild einer beispielhaften Betriebsumgebung für Ausführungsformen der vorliegenden Erfindung ist;
3 ein Blockschaltbild eines Signalisierungs-Gateway ist, welches in der Lage ist, SS7-Nachrichten über ein paketbasiertes Netzwerk zu senden, wobei ein Transportadapterschicht-Interface entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt wird;
4(a) und 4(b) Blockschaltbilder sind, welche die Beziehungen zwischen den SS7- und IP-Protokollstapeln und Verfahren zum Integrieren der Protokollstapel darstellen, wobei ein Transportadapterschicht-Interface entsprechend Ausführungsformen der vorliegenden Erfindung benutzt wird;
5 ein Blockschaltbild ist, welches eine beispielhafte Paketstruktur darstellt, um SCCP-Nachrichten zu verkapseln, wobei ein Transportadapterschicht-Interface entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt wird;
6 ein Flussdiagramm ist, welches beispielhaft Schritte darstellt, welche von einem Signalisierungs-Gateway beim Verkapseln von SCCP-Nachrichten ausgeführt werden, wobei ein Transportadapterschicht-Interface entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt wird;
7 ein Blockschaltbild ist, welches eine beispielhafte Paketstruktur darstellt, um MTP3-Nachrichten zu verkapseln, wobei ein Transportadapterschicht-Interface entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt wird;
8 ein Blockschaltbild ist, welches eine beispielhafte Paketstruktur darstellt, um SS7-Nachrichten zu verkapseln, wobei eine ATM-Adaptionsschicht- und ein Transportadapterschicht-Interface entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt werden;
9 ein Flussdiagramm ist, welches exemplarisch die Schritte darstellt, um individuelle Nachrichtenpakete zu identifizieren, welche über eine stromorientierte Verbindung entsprechend einer Ausführungsform der vorliegenden Erfindung erhalten werden;
10 ein Flussdiagramm ist, welches beispielhaft die Schritte darstellt, um den Verbindungsstatus zu überwachen, wobei Transportadapterschicht-Interface-Nachrichten entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt werden;
11 ein Flussdiagramm ist, welches beispielhaft die Schritte darstellt, um Kommunikation zu gestatten und zu verbieten, wobei ein Transportadapterschicht-Interface entsprechend Ausführungsformen der vorliegenden Erfindung benutzt wird; und
12 ein Flussdiagramm ist, welches beispielhaft die Schritte darstellt, um die Umlaufzeit zu messen, wobei Transportadapterschicht-Interface-Nachrichten entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt werden.
Detaillierte Beschreibung der Erfindung
2 stellt eine beispielhafte Betriebsumgebung für Ausführungsformen der vorliegenden Erfindung dar. In 2 kommunizieren herkömmliche SS7-Netzwerkelemente, wie z.B. SSPs 200, 202 und 204 und SCP 206, über ein SS7-Netzwerk 208 miteinander. IP-Knoten, wie z.B. Media Gateways (MGs) 210, 212 und 214, Media-Gateway-Steuergeräte (MGCs) 216 und 218 und Internet-Dienstanbieter (ISP) 220 kommunizieren miteinander über ein erstes paketbasiertes Netzwerk 222. In ähnlicher Weise kommunizieren Signalisierungs-Gateways 224 und 226 mit MGCs 216 und 218 und mit SCP 228 über ein zweites paketbasiertes Netzwerk 230. Erste und zweite paketbasierte Netzwerke 222 und 230 können jeweils IP-Netzwerke aufweisen. Ferner können das erste und zweite paketbasierte Netzwerk 222 und 230 das gleiche logische Netzwerk sein. Der Grund, warum die Netzwerke 222 und 230 in 2 getrennt dargestellt sind, besteht darin, dass das erste paketbasierte Netzwerk 222 paketaufgeteilte Medienstromkommunikation zwischen MGs und Mediensteuerinformation zwischen den MGCs und den MGs trägt und das zweite paketbasierte Netzwerk 230 Anrufsignalisierungsverkehr zu und von den SGs 224 und 226 trägt.
Die herkömmlichen SS7-Neztwerkelemente, wie z.B. SSPs und SCPs, werden oben im Detail beschrieben. Deshalb wird hier keine Beschreibung derselben wiederholt. Die zusätzlichen Netzwerkelemente, welche in 2 dargestellt werden, beinhalten Medien-Gateways 210, 212 und 214, Medien-Gateway-Steuergeräte 216 und 218, Signalisierungs-Gateways 224 und 226 und Internet-Dienstanbieter (ISP) 220. Die Medien-Gateways 210, 212 und 214 verkapseln die Medienstromkommunikationen, wie z.B. Audio, Video und Daten, in IP-Paketen, welche über das erste paketbasierte Netzwerk 222 zu übertragen sind. Ein Beispiel eines benutzten Protokolls, um Medienstromkommunikation über ein paketbasiertes Netzwerk zu senden, ist das Echtzeit-Protokoll (RTP), wie es in RFC 1889, RTP: A Transport Protocol for Real Time Applications, Jacobson et al., Januar 1996.
Die MGCs 216 und 218 steuern die MGs 210, 212 und 214, indem ein Steuerprotokoll benutzt wird. Ein Beispiel eines Steuerprotokolls, welches durch die MGCs 216 und 218 implementiert werden darf, ist das Media-Gateway-Steuerprotokoll, wie es in Media Gateway Control Protocol (MGCP), http:/search.ietf.org/internet-drafts/draft-huitema-mejaco-mgcpv0r1-05.txt, 21. Februar 1999, beschrieben wird. Der ISP 220 liefert Internet-Dienste an Teilnehmer. Entsprechend kann der ISP 220 einen Netzwerkzugriffs-Server beinhalten, um dem Benutzer Zugriff zum Internet zu liefern.
Die Signalisierungs-Gateways 224 und 226 implementieren ein Interface zwischen dem SS7-Netzwerk 208 und dem zweiten paketbasierten Netzwerk 230. In einer bevorzugten Ausführungsform der Erfindung liefern die Signalisierungs-Gateways 224 und 226 ein Transportadapterschicht-Interface, um zu gestatten, dass herkömmliche Netzwerkwerkelemente, wie z.B. SSPs 200, 202 und 204, mit IP-Netzwerkelementen, wie z.B. MGCs 216 und 218, kommunizieren. Jedoch ist das Transportadapterschicht-Interface nicht auf Kommunikationen zwischen SSPs und MGCs beschränkt. Beispielsweise kann das Transportadapterschicht-Interface entsprechend Ausführungsformen der vorliegenden Erfindung auch benutzt werden, um Anrufsignalisierungsnachrichten an IP-basierte SCPs zu kommunizieren, z.B. an den SCP 228 und andere Einrichtungen, welche mit einem IP-Interface ausgestattet sind.
3 ist ein Blockschaltbild, welches ein Signalisierungs-Gateway für das Implementieren der Transportadapterschicht-Interface-Funktionalität entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt. In 3 beinhaltet das Signalisierungs-Gateway 224 ein SS7-Verbindungs-Interface-Modul (LIM) 300, um SS7-Nachrichten über ein SS7-Netzwerk zu senden und zu empfangen, und ein Datenkommunikationsmodul (DCM) 302, um SS7-Nachrichten über eine oder mehrere stromorientierte Verbindungen zu senden und zu empfangen. Das Signalisierungs-Gateway 224 kann auch zusätzliche Module beinhalten, wie z.B. ein Datenbank-Dienstmodul (DSM) 304, um SCCP- und Datenbankdienste zu liefern. Die Module 300, 302 und 304 sind über einen Interprozessor-Nachrichtentransport-(IMT-)Bus 306 angeschlossen. Der IMT-Bus 306 ist vorzugsweise ein gegenläufig rotierender Zwei-Ring-Bus für erhöhte Zuverlässigkeit.
Das Verbindungs-Interface-Modul 300 beinhaltet eine Anzahl von Verfahren für das Senden und Empfangen von SS7-Nachrichten über SS7-Anschlüsse. In der dargestellten Ausführungsform beinhaltet das Verbindungs-Interface-Modul 300 das MTP-Ebene-1-und-2-Verfahren 307, um SS7-Schicht-1-und-2-Verarbeitung von eingehenden Nachrichten durchzuführen. Die E/A-Warteschlange 308 reiht eingehende und ausgehende SS7-Nachrichten auf. Das Nachrichtendiskriminierungsverfahren 309 bestimmt, ob eingehende Nachrichten an das Signalisierungs-Gateway 224 oder an einen anderen Knoten adressiert sind. Beispielsweise kann das Nachrichtendiskriminierungsverfahren 309 den SS7-Zielpunktcode in einer eingehenden Nachricht analysieren, um zu bestimmen, ob die Nachricht an ein Signalisierungs-Gateway 224 oder an einen anderen Knoten adressiert ist. Falls das Nachrichtendiskriminierungsverfahren 309 bestimmt, dass die Nachricht an ein Signalisierungs-Gateway 224 adressiert ist, leitet das Nachrichtendiskriminierungsverfahren 309 die Nachricht an das Nachrichtenverteilungsverfahren 310. Das Nachrichtenverteilungsverfahren 310 routet die Nachricht an ein anderes internes Modul zur weiteren Verarbeitung.
Das DSM 304 liefert Datenbank- und SCCP-Dienst für SS7-Nachrichten. Entsprechend darf das DSM 304 Signalisierungsverbindungs-Routing-Steuer-(SCRC-) und SCCP-Verfahren 312 und 314 beinhalten, um SCCP-Schichtinformation von eingehenden Nachrichten zu interpretieren und um die Nachrichten an das Datenbankverfahren 316 zu routen. Das Datenbankverfahren 316 kann einen Suchlauf in der Datenbank 318 durchführen, um Routing- oder andere Information für eine eingehende Nachricht zu erhalten. Beispielsweise kann die Datenbank 318 eine Nummernübertragbarkeits-Datenbank, eine Schaltungsidentifiziercode-Routing- Datenbank, eine Abrechnungscode-Datenbank oder eine andere Datenbank sein, um Routen oder eine andere Funktionalität durchzuführen. Das Routen-Verfahren 320 routet die Nachricht an das geeignete Modul für hinausgehende Verarbeitung, basierend auf MTP-Schicht-3-Information in der Nachricht.
Das DCM 302 beinhaltet das Transportadapterschicht-Interface-Verfahren 322, um Transportadapterschicht-Interface-Funktionalität durchzuführen. Eine derartige Funktionalität beinhaltet das Verkapseln von SS7-Nachrichten in einem Transportadapterschicht-Interface-Paket, welches über eine stromorientierte Verbindung zu senden ist, wobei Kommunikation über eine stromorientierte Verbindung zugelassen und verboten wird, wobei das andere Ende der stromorientierten Verbindung überwacht wird, etc.. Das DCM 203 beinhaltet vorzugsweise auch ein stromorientiertes Kommunikationsverfahren, wie z.B. ein TCP/IP-Verfahren 324. Das TCP/IP-Verfahren 324 führt herkömmliche TCP/IP-Protokollstapelfunktionen durch. Derartige Funktionen beinhalten das zuverlässige Liefern von TCP/IP-Paketen, Flusssteuerung, Paket-in-Reihenfolge-Ordnen und andere stromorientierte Transportfunktionalität.
4(a) ist ein Blockschaltbild, welches die Beziehungen zwischen dem SS7-Protokollstapel und dem Transportadapterschicht-Interface-Protokollstapel entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt. In 4 beinhaltet der SS7-Protokollstapel 400 die MTP-Schicht 1 402, die MTP-Schicht 2 404 und die MTP-Schicht 3 406. Die MTP-Schicht 1 402, welche auch als die physikalische Schicht bezeichnet wird, kommuniziert mit Hardware, um Daten über ein physikalisches Medium zu senden und zu empfangen. Die MTP-Schicht 2 404, welche als die Datenverbindungsschicht bezeichnet wird, liefert Fehlerkorrektur/Nachweis und die geeignete In-Reihenfolge-Lieferung der SS7-Nachrichtenpakete. Die MTP-Schicht 3 406, welche auch als die Netzwerkschicht bezeichnet wird, ist für das SS7-Nachrichtenrouten, die Nachrichtenunterscheidung und die Nachrichtenverteilung verantwortlich.
Oberhalb der MTP-Schichten 1 bis 3 sind die Benutzerteile- und Anwendungsteileschicht 408 angebracht. Die Benutzerteile- und Anwendungsteileschicht 408 ist in die ISDN-Nutzerteil-(ISUP-)Schicht 410, die Signalisierungsverbindungs-Steuerteil-(SCCP-)Schicht 412 und die Umsetzungsfähigkeiten-Applikationsteil-(TCAP-)Schicht 414 aufgeteilt. Die ISDN-Nutzerteilschicht 410 führt die SS7-Anruferstellungs- und -Anrufbeendigungsfunktionen durch. Die SCCP-Schicht 412 führt die Signalisierungsverbindungs-Steuerteilfunktionen, wie z.B. das Datenbankuntersystem-Adressieren durch. Die TCAP-Schicht 414 wird für Datenbanktransaktionen benutzt, wie z.B. die 800er-Nummer-Umsetzungen, die Nummerübertragbarkeitstransaktionen und die Abrechungstransaktionen. Schließlich kann die SS7-Anwendungsschicht 416 jegliche Funktion ausführen, welche die darunter liegenden Dienste nutzt, welche durch SS7 geliefert werden. Beispiele derartiger Anwendungen beinhalten Abrechnungsanwendungen, Netzwerküberwachungsanwendungen, etc..
Der TALI-Protokollstapel 418 beinhaltet ein IP-Protokollstapelteil 420, ein TALI-Teil 422 und ein SS7-Teil 424. Das IP-Protokollstapelteil 420 beinhaltet eine physikalische und eine MAC-Schicht 426, eine Netzwerkschicht 428 und eine Transportschicht 430. Die physikalische und MAC-Schicht 426 ist über ein Interface mit der Netzwerk-Hardware zur Kommunikation zwischen angeschlossenen Maschinen verbunden und transportiert Netzwerkrahmen zwischen Maschinen, welche an das gleiche Netzwerk angeschlossen sind. Die Netzwerkschicht 428 handhabt Routing- und Adressieren von Datagrammen zwischen unterschiedlichen physikalischen Netzwerken. In einer bevorzugten Ausführungsform der Erfindung führt die Netzwerkschicht 428 das Adressieren und Routen von Funktionen entsprechend dem Internet-Protokoll, wie z.B. der Internet-Protokollversion 4 oder der Internet-Protokollversion 6 durch. Die Transportschicht 430 liefert Kommunikation zwischen Anwendungsprogrammen. In einer bevorzugten Ausführungsform der vorliegenden Erfindung beinhaltet die Transportschicht 430 stromorientierte Transport-Software, wie z.B. TCP-Software, zum Implementieren eines zuverlässigen stromorientierten Transports zwischen Anwendungen.
Es sollte beachtet werden, dass, obwohl der TALI-Protokollstapel 418, welcher in 4(a) dargestellt wird, eine MTP3-Schicht 406 beinhaltet, die MTP-Schicht-3-Funktionalität im Gegensatz zu anderen Verarbeitungspunktcodes optional ist und von dem TALI-Protokollstapel 418 weggelassen werden kann.
Entsprechend einem wichtigen Gesichtspunkt der vorliegenden Erfindung beinhaltet das Transportadapterschicht-Interface-Teil 422 Funktionen und Paketstrukturen, welche die gegenseitige Betriebsfähigkeit zwischen den SS7- und TCP-Protokollen erleichtern. Beispielsweise beinhaltet das Transportadapterschicht-Interface-Teil 422 Paketstrukturen, welche das Herausziehen von SS7-Paketen aus einem TCP-Datenstrom erleichtern, Befehle, um Verbindungen ohne das Aufrufen von TCP-Verbindungserstellungs- und -beendigungsverfahren zu gestatten und zu verbieten, Überwachungsnachrichten, um die Umlaufzeit zu messen, und Testnachrichten, um zu bestimmen, ob eine TCP-Verbindung freigegeben oder abgeschaltet ist. Jede dieser Funktionen wird nachfolgend detaillierter diskutiert.
Herkömmliche SS7-Einrichtungen 436, wie z.B. SSPs, STPs und SCPs, kommunizieren mit dem Signalisierungs-Gateway 224, wobei der SS7-Protokollstapel 400 benutzt wird. TCP/IP-Einrichtungen 438, wie z.B. MGCs und IP-basierte SCPs, kommunizieren mit dem Signalisierungs-Gateway 224, wobei der TALI-Protokollstapel 418 benutzt wird. Entsprechend beinhaltet das Signalisierungs-Gateway 224 vorzugsweise Software für das Implementieren sowohl des SS7-Protokollstapels 400 als auch des TALI-Protokollstapels 418.
Wie in 3 dargestellt wird, kann der SS7-Protokollstapel 400 durch oder auf einem LIM 300 implementiert werden, und der TALI-Protokollstapel 418 kann durch oder auf einem DCM 102 implementiert werden. Jedoch ist die vorliegende Erfindung nicht auf eine derartige Implementierung begrenzt. Beispielsweise können in einer alternativen Ausführungsform der Erfindung der SS7-Protokollstapel 400 und der TALI-Protokollstapel 418 auf einer einzelnen Karte oder einem Modul innerhalb des Signalisierungs-Gateways 224 oder in einem anderen Knoten implementiert sein, in welchem SS7- und IP-Kommunikationsfähigkeit wünschenswert ist.
4(b) ist ein Blockschaltbild, welches eine alternative Implementierung des TALI-Protokollstapels entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt. In 4(b) beinhaltet der Protokollstapel 400a MTP3-, SCCP-, TCAP-, ISUP- und Anwendungsschichten 406, 412, 414 und 416, welche identisch zu den entsprechend nummerierten Schichten sind, welche mit Bezug auf 4(a) beschrieben wurden. Jedoch sind in 4(b) die MTP-Schichten 1 und 2 durch eine asynchrone Transportmodus-(ATM-)Schicht 450, eine ATM-Adaptionsschicht 5 452 und eine Signalisierungs-ATM-Adaptionsschicht 454 ersetzt. Die Schichten 450, 452 und 454 führen Funktionen aus, um den SS7-Verkehr über ein Breitbandnetzwerk, wie z.B. ein ATM-Netzwerk, zu übertragen.
Der TALI-Protokollstapel 418a beinhaltet MAC-, Netzwerk-, Transport-, TALI- und SS7-Schichten 426, 428, 430, 422 und 424, welche identisch zu den entsprechend nummerierten Schichten mit Bezug auf 4(a) sind. Jedoch beinhaltet der TALI-Protokollstapel 418a eine Signalisierungs-ATM-Adaptionsschicht (SAAL) 454, um das In-Reihenfolge-Bringen von SS7-Daten zu liefern, welche über eine TCP/IP-Verbindung übertragen wurden. Wenn der TALI-Protokollstapel 418a ohne eine SAAL-Schicht 454 implementiert ist, wie dies in 4(a) dargestellt wird, wird die SS7-Reihenfolgenummer, welche in dem SS7-MTP2-Nachrichtenkopf beinhaltet ist, nicht über eine TCP/IP-Verbindung übertragen. Diese Reihenfolgenummer wird benutzt, um das Nachrichten-in-Reihenfolge-Bringen zu bewahren und um komplexe SS7-Vorgehensweisen zu unterstützen, wobei MSU-Wiederherstellung während des Verbindungsüberwechselns und Rückwechseln eingeschlossen sind. Das Überwechseln ist ein SS7-Verfahren, mit welchem eine Verbindungsanforderung über eine SS7-Verbindung gesendet wird, um SS7-Verkehr von dieser Verbindung zu einer anderen SS7-Verbindung zu verschieben. Das Rückübertragen ist ein SS7-Verfahren, um SS7-Verkehr zurück zur Originalverbindung zu bewegen. Der TALI-Protokollstapel 418, welcher in 4(a) ohne SAAL-Schicht 454 dargestellt ist, garantiert noch das korrekte In-Reihenfolge-Bringen von SS7-Daten, da die TCP-Schicht 430 das In-Reihenfolge-Bringen von TCP-Segmenten liefert, welche den SS7-Verkehr tragen.
Wenn der TALI-Protokollstapel 481a mit der SAAL-Schicht 454 implementiert wird, ist die Reihenfolgenummer des SS7 MSU ein Teil der Daten, welche über die TCP/IP-Verbindung übertragen werden. Diese Reihenfolgenummer kann als ein Nachrichtenkopf, ein Dateiende-Etikett oder in einem anderen Teil eines Transportadapterschicht-Interface-Paketes beinhaltet sein. In dem dargestellten Beispiel ist die Reihenfolgenummer ein 24-Bit-Wert, welcher in einem dienstspezifischen, verbindungsorientierten Protokoll-(SSCOP-)Dateiende-Etikett beinhaltet ist, welches durch die SAAL-Schicht 454 geliefert wird. Diese 24-Bit- Reihenfolgenummer dient dem gleichen Zweck wie die 8-Bit-SS7-Reihenfolgenummer. Entsprechend kann der TALI-Protokollstapel 418a, welcher in 4(b) dargestellt wird, für das SS7-Überwechseln und -Zurückwechseln mit Datenwiedergewinnung benutzt werden und kann den MSU-Verlust minimieren, wenn SS7-Verbindungen deaktiviert werden.
SCCP-Verkapselung unter Benutzung des TALI
5 stellt eine Paketstruktur zum Verkapseln von SCCP MSUs in IP-Paketen dar, wobei das Transportadapterschicht-Interface entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt wird. In 5 beinhaltet die SS7 MSU 500 die SCCP-Schichtinformation 502 und die TCAP-Schichtinformation 504, welche im Service-Teil 506 des TALI-Pakets 508 verkapselt sind. Die SS7 MSU 500 beinhaltet auch ein Dienstanzeigeoktett 510 und ein Routing-Etikett 512. In einer Ausführungsform der Erfindung kann das Dienstanzeigeoktett 510 und das Routing-Etikett 512 direkt im Dienstteil 506 des TALI-Pakets 508 verkapselt sein. Jedoch sind in der dargestellten Ausführungsform das Dienstanzeigeoktett 510 und das Routing-Etikett 512 bei dem TALI-Paket 508 weggelassen. Das Weglassen der Dienstanzeigeoktett- und Routing-Etikett-Information von dem TALI-Paket erleichtert das Verarbeiten durch das empfangende TALI-Verfahren.
Besser als das Verkapseln des Dienstindikationsoktetts 510 und des Routing-Etiketts 512 direkt in dem Dienstfeld 506 des TALI-Pakets 508 kann die TALI-Protokoll-Software entsprechend den Ausführungsformen der vorliegenden Erfindung Information von dem SIO 510 und Routing-Etikett 512 in andere Informationsfelder speichern. Beispielsweise kann der Zielpunktcode von dem Routing-Etikett 512 in dem SCCP-angerufenen Punktcodefeld der SCCP-Schicht 502 gespeichert werden. In ähnlicher Weise kann der Ursprungspunktcode von dem Routing-Etikett 512 in dem SCCP-Anrufer-Punktcodefeld der Routing-Kennung 512 gespeichert werden. Die Identifikationsinformation über den Nachrichtentyp vom SIO 510 kann mit dem OPCODE-Feld 514 des TALI-Pakets 508 verschmolzen werden. Beispielsweise kann das OPCODE-Feld 514 Information zum Identifizieren des Nachrichtentyps speichern. In der dargestellten Ausführungsform kann das OPCODE-Feld 514 auf einen vorher festgelegten Wert eingestellt werden, um die Nachricht als eine SCCP-Nachricht zu identifi zieren. Die verbleibenden Felder des SS7 MSU 500 werden vorzugsweise vom TALI-Paket 508 weggelassen. D.h., die SS7-Schicht-2-Information, Öffnungskennungen, Schließungskennungen und Rahmenüberprüfungsreihenfolgen werden vorzugsweise von dem TALI-Paket 508 weggelassen. Diese Information kann weggelassen werden, da der TCP/IP-Protokollstapel analoge Funktionen zu SS7-Schichten 1 und 2 liefert. Das Weglassen der SS7-Schichten 1 und 2 vom TALI-Paket 508 erniedrigt den Overhead zum Senden der Pakete über ein Netzwerk.
Zusätzlich zum Service-Feld 506 und zum OPCODE-Feld 514 beinhaltet das TALI-Paket 508 auch ein LENGTH- bzw. Längenfeld 516 und ein SYNC- bzw. Synchronisations-Feld 518. Das LENGTH-Feld 516 spezifiziert die Länge des Service-Teils des Datenpaketes. DAS SYNC-Feld 518 enthält eine vorher festgelegte Bit-Reihenfolge für das Identifizieren des Starts des TALI-Pakets 508. Das LENGTH-Feld 516 und das SYNC-Feld 518 können durch das Empfangen der TALI-Protokoll-Software benutzt werden, um individuelle TALI-Pakete aus einer stromorientierten Verbindung herauszuziehen. Demnach löst die TALI-Paketstruktur in 5 das Problem des Empfangens von Daten über eine stromorientierte Kommunikation und liefert individuelle TALI-Pakete an eine Anwendung. Dies erleichtert das Gestalten der Anwendung, wie dies nachfolgend detaillierter diskutiert wird.
Das TALI-Paket 508 ist in dem Datenteil 520 des Netzwerkrahmens 522 verkapselt. Der Netzwerkrahmen 522 kann irgendein gebräuchlicher Rahmen für das Liefern von Paketen an Maschinen sein, welche an das gleiche Netzwerk angeschlossen sind. Beispielsweise darf der Netzwerkrahmen 522 ein Ethernet-Rahmen sein. Entsprechend enthält der Netzwerkrahmen 522 einen indirekten Zugriffssteuer-(MAC-)Nachrichtenkopf 524. Der IP-Nachrichtenkopf 526 folgt auf den MAC-Nachrichtenkopf 524. Schließlich folgt der TCP-Nachrichtenkopf 528 auf den IP-Nachrichtenkopf 526. Die Struktur der Nachrichtenköpfe 524, 526 und 528 ist den Fachleuten bekannt und muss hier nicht beschrieben werden.
6 ist ein Flussdiagramm, welches beispielhaft die Schritte darstellt, welche durch das TALI-Verfahren 322 ausgeführt werden können, welches in 3 für das Ausführen des TALI-Verkapseln einer SCCP MSU dargestellt ist. In 6 empfängt im Schritt ST1 das TALI-Verfahren 322 eine SS7 MSU. Die SS7 MSU kann von einem SS7-Knoten stammen, wie z.B. einem SSP. Im Schritt ST2 wirft das TALI-Verfahren 322 die MTP-Schicht-2-Information, den SRC und die Kennzeichnungen von der SCCP MSU ab. Im Schritt ST3 platziert das TALI-Verfahren 322 den Zielpunktcode von der Routing-Schicht in das Angerufener-Adressfeld der SCCP-Schicht. Im Schritt ST4 platziert das TALI-Verfahren 322 den Ursprungspunktcode von dem Routing-Etikett in das Anrufenden-Adressfeld der SCCP-Schicht. Es ist davon auszugehen, dass die Schritte ST3 und ST4 optional sind und weggelassen werden können, wenn das gesamte MTP3-Teil der SCCP MSU in dem Dienstteil des TALI-Pakets verkapselt ist.
Im Schritt ST5 setzt das TALI-Verfahren 322 das SYNC-Feld in den Nachrichtenkopf des TALI-Pakets, um den Beginn des TALI-Pakets anzuzeigen. Im ST6 setzt das TALI-Verfahren 322 das OPCODE-Feld des TALI-Pakets auf SCCP. Im Schritt ST7 setzt das TALI-Verfahren 322 das LENGTH-Feld auf die Anzahl von Oktetten im Dienstfeld des TALI-Pakets. Schließlich sendet im Schritt ST8 der TALI-Prozess 322 das Paket an das TCP/IP-Verfahren 324 zur TCP/IP-Verkapselung und Übertragung zu einem externen Knoten.
Die Schritte zum Verarbeiten eines eingehenden TALI-Pakets sind im Wesentlichen die umgekehrten zu den Schritten, welche in 5 dargestellt sind. Neue Schritte zur Verarbeitung eingehender TALI-Pakete werden detaillierter nachfolgend in dem Abschnitt mit dem Titel "Identifizieren individueller Nachrichtenpakete, welche über eine stromorientierte Verbindung empfangen werden" diskutiert.
MTP3-Verkapselung bei Benutzung der TALI
7 ist ein Blockschaltbild, welches eine beispielhafte Paketstruktur darstellt, um MTP3-Nachrichten in IP-Paketen entsprechend einer bevorzugten Ausführungsform der vorliegenden Erfindung zu verkapseln. Wie es hier verwendet wird, ist eine MTP3-Nachricht eine SS7-Nachricht, welche nicht eine SCCP- oder eine ISUP-Nachricht ist. Diese Nachrichten entsprechen Dienstindikationswerten von 0-2, 4 und 6-15. In 7 beinhaltet die SS7 MSU 700 eine Schicht 2 702, eine Schicht 3 703 und Öffnungs- und Schließungsinformation 704 und 706. Nicht wie im Beispiel, welches in 5 dargestellt ist, wird in diesem Beispiel alle Schicht-3-Information im Dienstteil 506 des TALI-Pakets 508 verkapselt. Wie in dem Beispiel, welches in 5 dargestellt wird, werden die Schicht-2-Information 702 und die Öffnungs- und Schließinformation 704 und 706 vorzugsweise abgelegt.
Im TALI-Paket 508 wird das LENGTH-Feld 516 auf die Länge des Dienstteils 506 eingestellt. Das OPCODE-Feld 514 wird auf einen vorher festgelegten Wert eingestellt, um ein MTP3-Paket zu identifizieren. Das SYNC-Feld 518 wird auf einen vorher festgelegten Wert eingestellt, um den Start des TALI-Pakets 508 zu identifizieren. Das TALI-Paket 508 wird im Netzwerkrahmen 522 in der gleichen Weise verkapselt, wie oben mit Bezug auf 5 beschrieben. Demnach liefert die vorliegende Erfindung ein Verfahren zum Verkapseln von MTP3-Nachrichten anders als ISUP- und SCCP-Nachrichten in Netzwerkrahmen, wobei ein Transportadapterschicht-Interface benutzt wird.
SAAL-Verkapselung unter Benutzung der TALI
Wie oben mit Bezug auf 4(b) beschrieben, beinhaltet eine Ausführungsform des Transportadapterschicht-Interface-Protokollstapels eine SAAL-Schicht. Die TALI liefert auch einen entsprechenden SAAL OPCODE bzw. SAAL Operationscode, welcher anzeigt, dass eine SAAL-Nachricht transportiert wird. Dieser OPCODE kann benutzt werden, um jegliche Art von SS7-Nachricht zu transportieren, wobei ISUP-Nachrichten, SCCP-Nachrichten und MTP3-Nachrichten, welche SAAL-Information beinhalten, beinhaltet sind. Zusätzlich darf der SAAL OPCODE benutzt werden, um Nicht-SS7-Nachrichten zu transportieren, wie z.B. gleichberechtigte SAAL-Nachrichten.
8 stellt eine Verkapselung der SAAL-Nachrichten dar, wobei ein Transportadapterschicht-Interface entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt wird. In 8 beinhaltet die SS7 MSU 800 Schicht-2- und Schicht-3-Teile 802 und 803 und Öffnungs- und Schließteile 804 und 805, wie vorher beschrieben. Das Schicht-3-Teil 802 beinhaltet einen SIO-Wert 806, ein Routing-Etikett 807 und andere Schicht-3-Information 808. Andere Schicht-3-Information 808 kann ISUP-Information, Anwendungsteilinformation oder MTP3-Information beinhalten, wie vorher beschrieben. In der dargestellten Ausführungsform wird jegliche Schicht-3-Information 803 im Dienstteil 810 des TALI-Pakets 812 verkapselt.
Das TALI-Paket 812 beinhaltet ein LENGTH-Feld 814, ein OPCODE-Feld 816 und ein SYNC-Feld 818. Zusätzlich beinhaltet das TALI-Paket 812 ein SSCOP-Dateiende-Etikett 820. Das LENGTH-Feld 814 spezifiziert die Anzahl von Oktetten im Dienstteil 810, das OPCODE-Feld 816 wird auf einen vorher festgelegten Wert eingestellt, um das TALI-Paket 812 als ein SAAL-Paket zu identifizieren, und das SYNC-Feld 818 wird auf einen vorher festgelegten Wert eingestellt, um den Beginn des TALI-Pakets 812 zu anzuzeigen. Das SSCOP-Dateiende-Etikett 820 enthält eine Reihenfolgenummer für das In-Reihenfolge-Bringen der TALI-Dienstdatenpakete, wenn eine TCP/IP-Verbindung nicht funktioniert. Das TALI-Paket 812 wird in dem Netzwerkrahmen 522 in der oben beschriebenen Weise verkapselt. Die SAAL-Entkapselung kann in einer Weise auftreten, welche ähnlich zu der ist, welche oben mit Bezug auf 6 beschrieben ist, wenn das Dienstteil 810 des TALI-Pakets 812 eine SS7 MSU enthält. Wenn das Dienstteil 810 des TALI-Pakets 812 eine gleichberechtigte SAAL-Nachricht enthält, kann durch die SAAL-Schicht eine Entkapselung durchgeführt werden, besser als durch die TALI-Schicht.
TALI-Zustandsmaschine
Tabelle 1, welche nachfolgend gezeigt wird, ist eine Zustandsmaschine des TALI-Protokolls. In Tabelle 1 geben die Spalten Protokollzustände wieder, und die Zeilen geben Ereignisse wieder, welche Übergänge zwischen Protokollzuständen auslösen können oder nicht. Leere Zellen in der Tabelle zeigen an, dass keine Aktion für einen gegebenen Zustand in Antwort auf ein gegebenes Ereignis auftritt. Zellen mit Text zeigen Funktionen an, welche durch die TALI-Protokollimplementierungen und Zustandsübergänge ausgeführt werden, welche in Antwort auf die Ereignisse auftreten.
Die Zustände im TALI-Protokoll sind: außer Dienst (OOS), Verbindung, nahes Ende verboten – fernes Ende verboten (NEP-FEP), nahes Ende verboten – entferntes Ende gestattet (NEP-FEA), nahes Ende gestattet – entferntes Ende verboten (NEA-FEP) und nahes Ende gestattet – entferntes Ende gestattet (NEA-FEA). Im Außer-Dienst-Zustand wurde eine TCP-Verbindung entweder nicht erstellt oder wurde abgeschaltet. Im Verbindungszustand wird eine TCP-Verbindung zwischen TCP-Software, welche zu TALI-Endpunkten gehört, erstellt. "Verboten" bezieht sich auf einen Zustand, bei welchem eine TCP-Verbindung erstellt wird, aber es TALI-Dienstnachrichten nicht gestattet wird, zu der Seite gesandt zu werden, für die Nachrichtenfluss verboten ist. Schließlich bezieht sich "gestattet" auf die Bereitschaft einer Seite für eine Verbindung, um TALI-Dienstnachrichten anzunehmen. Wie es hier benutzt wird, sind TALI-Service-Nachrichten Nachrichten, welche Anwendungsdaten tragen. TALI-Nachrichten sind Nachrichten, wie z.B. gestatten, verbieten, überwachen und testen, welche TALI-Steuerinformation tragen. SAAL-Nachrichten, welche nicht benutzt werden, um Anwendungsdaten zu tragen, fallen auch in die TALI-Nachrichtengruppe. Demnach sind, falls im verbotenen Zustand, TALI-Nachrichten gestattet, während TALI-Dienstnachrichten nicht gestattet sind.
Die Ereignisse, welche in Spalte 1 der Tabelle aufgeführt sind, beinhalten Zeitablauf-Ende, Empfang von Nachrichten, Protokollübertretungen, etc.. Das TALI-Protokoll beinhaltet vier Hauptzeitabläufe: T1, T2, T3 und T4. Der Zeitablauf T1 repräsentiert das Zeitintervall zwischen dem Ursprung einer Testnachricht bei jeder TALI-Implementierung. Jedes Mal, wenn T1 andauert, sollte eine TALI-Implementierung eine Testnachricht senden. Die Testnachricht wird nachfolgend detaillierter mit Bezug auf das Überwachen des Zustands einer TALI-Verbindung diskutiert.
Der Zeitablauf T2 repräsentiert den Zeitbetrag, bei welchem eine TALI-Implementierung eine Gestattungs- oder eine Verbotsnachricht in Antwort auf eine Testnachricht zurückzusenden hat. Wenn das entfernte Ende einer TALI-Verbindung nicht mit einer Gestattungs- oder Verbotsnachricht antworten kann, bevor T2 abläuft, behandelt der Sender der Testnachricht die T2-Nachricht als eine Protokollverletzung (PV).
Der Zeitablauf T3 steuert die Länge der Zeit, dass das nahe Ende der TALI-Verbindung Dienstdaten verarbeiten sollte, welche von dem entfernten Ende einer TALI-Verbindung empfangen werden, nachdem ein Management-Verbotsverkehrsereignis am nahen Ende aufgetre ten ist. Wie hier benutzt wird, ist ein "Management-Ereignis" eine Aktion, welche durch eine Anwendung durchgeführt wird, welche oberhalb angesiedelt ist und welche die TALI-Schicht benutzt. Der Zeitablauf T3 wird benutzt, wenn ein Übergang von NEA-FEA (beiden Enden ist es gestattet, Dienstdaten zu senden) zu NEP-FEA (nur das entfernte Ende ist bereit, Service-Daten zu senden) auftritt. Wenn ein Endpunkt zu dem verbotenen Zustand übergeht, zeigt der Endpunkt an, dass der Endpunkt das Empfangen von Dienstnachrichtverkehr zu stoppen wünscht. D.h., wenn A und B die Endpunkte sind und der Endpunkt B keinen Dienstnachrichtverkehr zu empfangen wünscht, dann sendet der Endpunkt B eine Verbotsnachricht an den Endpunkt A. Nach dem Senden der Verbotsnachricht empfängt der Endpunkt B Verkehr für T3 Sekunden und verarbeitet diesen. Nachdem T3 geendet hat, werden keine Dienstnachrichten am Endpunkt B verarbeitet. Der Endpunkt A startet mit dem Aufteilen des Verkehrs zu einem Knoten, anders als dem Endpunkt B, sobald er die Verbotsnachricht vom Endpunkt B erhält.
Einige der Daten durften an die TCP-Schicht am Endpunkt A zur Übertragung gegeben werden, nachdem der Endpunkt B die Verbotsnachricht gesendet hat, aber bevor die Verbotsnachricht durch den Endpunkt A empfangen wurde. Die Anwendung am Endpunkt A besitzt keine Steuerung über Nachrichten, welche bereits an den TCP gegeben wurden. Wenn der Endpunkt B nicht für eine gewisse Zeit gewartet hat, dann würde der Endpunkt B gültige Nachrichten abwerfen. Der Endpunkt A würde anhalten, Daten zu der TCP-Schicht laufen zu lassen, wenn er einmal die Verbotsnachricht erhalten hat.
Der T4-Zeitablauf stellt das Zeitintervall zwischen dem Ursprung der Überwachungsnachricht dar. Jedes Mal, wenn die Zeit T3 abläuft, sollte die TALI-Implementierung eine Überwachungsnachricht senden. Das Benutzen der Überwachungsnachrichten, um die Umlaufzeit einer Verbindung zu messen, wird nachfolgend detaillierter diskutiert.
Andere Nachrichten, welche bei den Ereignissen der Spalte der Tabelle 1 dargestellt sind, sind spezielle (spcl-)Nachrichten und ausgedehnte Dienst-(xsrv-)Nachrichten. Ausgedehnte Dienstnachrichten werden benutzt, um andere Transportarten an Dienstverkehr als die oben beschriebenen zu transportieren. Spezielle Nachrichten sind verkaufsspezifische Nachrichten, welche benutzt werden, um Dienste anders als jene, welche durch die TALI geliefert werden, zu liefern.
Ein anderes Merkmal der Erfindung, welches in Tabelle 1 dargestellt wird, ist das Verwenden der Überwachungsnachrichten, um die TALI-Software-Version des entfernten Endes einer TALI-Verbindung zu identifizieren. Wenn beispielsweise entsprechend Tabelle 1 eine Implementierung eine Überwachungsnachricht in irgendeinem Zustand außer dem Außer-Dienst-Zustand oder dem Zustand des Verbindens empfängt, aktualisiert die Implementierung die TALI-Version des entfernten Endes der Verbindung. Beispielhafte Felder in der Überwachungsnachricht, welche benutzt werden, um die TALI-Version zu identifizieren, werden detaillierter nachfolgend diskutiert.
Die folgende Beschreibung stellt einen beispielhaften Pfad durch die Zustandsmaschine dar, welche in Tabelle 1 dargestellt wird. Zuerst kann die TCP-Software, welche zu einem nahen Ende der TALI-Implementierung gehört, eine TCP-Verbindung mit der TCP-Software erstellen, welche zu einem entfernten Ende der TALI-Implementierung gehört. Während der Erstellungsphase der TCP-Verbindung befinden sich beide TALI-Implementierungen im Verbindungszustand. Sobald eine TCP-Verbindung erstellt ist, befinden sich beide TALI-Implementierungen in dem NEP-FEP-Zustand, wobei angezeigt wird, dass TALI-Dienstnachrichten nicht gesendet werden können. Wenn das nahe Ende der TALI-Implementierung eine Erlaubnisnachricht empfängt, schaltet die Zustandsmaschine zu dem NEP-FEA-Zustand um. In dem NEP-FEA-Zustand wird das nahe Ende der TALI-Implementierung eine Erlaubnisnachricht senden, wenn ein Management-Erlaubnis-Verkehrsereignis auftritt. Der Ausdruck "Management-Erlaubnis-Verkehrsereignis", wie er hier benutzt wird, bezieht sich auf ein Ereignis, welches die TALI-Implementierung in Kenntnis setzt, dass Dienstnachrichten auf dem fraglichen Socket gesendet werden. Sobald das nahe Ende der TALI-Implementierung eine Erlaubnisnachricht sendet, geht die Zustandsmaschine in den NEA-FEA-Zustand über. In dem NEA-FEA-Zustand können beide TALI-Implementierungen TALI-Dienstnachrichten senden und empfangen.
Tabelle 1: TALI-Zustands-Maschine
Identifizieren individueller Nachrichtenpakete, welche über stromorientierte Verbindung empfangen werden
Wie oben diskutiert, steht eines der Probleme, welche mit dem Empfangen von Daten über eine stromorientierte Verbindung verbunden sind, wie z.B. einer TCP-Verbindung, darin, dass die Paketgrenzen, welche durch eine Sendeanwendung geschaffen sind, nicht durch die zugrundeliegende TCP-Software gewartet werden könnten. Als Ergebnis könnte die empfangende Anwendung Daten in den vorgesehenen Einheiten nicht empfangen. Die vorliegende Ausführungsform löst dieses Problem mit Bezug auf TALI-Pakete, wobei die SYNC- und LENGTH-Felder benutzt werden. 9 ist ein Flussdiagramm, welches beispielhaft die Schritte darstellt, welche durch das TALI-Verfahren 322 durchgeführt werden, welches in 3 zum Identifizieren von TALI-Paketen dargestellt wird, welche über eine stromorientierte Verbindung empfangen werden. Im Schritt ST1 wird eine stromorientierte Verbindung, wie z.B. eine TCP-Verbindung, zwischen Endpunkten erstellt. Die Endpunkte können ein Signalisierungs-Gateway und ein Medien-Gateway-Steuergerät sein. Im Schritt ST2 empfängt das TALI-Verfahren 322 Daten über die Verbindung. Im Schritt ST3 liest das TALI-Verfahren 322 eine vorher festgelegte Anzahl von Bytes, um den Nachrichtenkopf aus dem Strom an Daten herauszuziehen, welche über die Verbindung empfangen werden. Die vorher festgelegte Anzahl von Bytes ist gleich der Größe des Nachrichtenkopfes, wie er durch die TALI-Version eingestellt ist. Beispielsweise kann der Nachrichtenkopf zwanzig Bytes in der Länge besitzen.
Im Schritt ST4 teilt das TALI-Verfahren 322 den Nachrichtenkopf in die SYNC-, OPCODE- und LENGTH-Felder auf. Im Schritt ST5 bestimmt das TALI-Verfahren 322, ob der Wert in dem SYNC-Feld gültig ist. Falls der Wert in dem SYNC-Feld nicht gültig ist, behandelt das TALI-Verfahren 322 die Nachricht als eine Protokollverletzung. Falls das TALI-Verfahren 322 bestimmt, dass das SYNC-Feld gültig ist, kann das TALI-Verfahren 322 dann bestimmen, ob die LENGTH- und OPCODE-Felder gültig sind (Schritt ST7). Im Schritt ST8 liest das TALI-Verfahren 322 die nächsten LENGTH-Bytes in dem Datenstrom nach dem Nachrichtenkopf. Im Schritt ST9 lässt das TALI-Verfahren 322 das Paket hinauf zum Protokollstapel laufen, so dass es durch die TALI-Zustandsmaschine verarbeitet wird. Sobald das TALI-Paket hinauf zum Protokollstapel durchgelassen wurde, kehrt das TALI-Verfahren 322 zum Schritt ST3 zurück, um den nächsten Datennachrichtenkopf zu lesen. Da das TALI-Verfahren 322 die SYNC- und LENGTH-Felder benutzt, um die Paketgrenzen zu bestimmen, ist das Design der SS7-Anwendung im großen Maße vereinfacht. Es besteht keine Notwendigkeit, dass sich eine SS7-Anwendung mit Paketgrenzen befasst.
Gleichberechtigte TALI-Nachrichten
Gleichberechtigte TALI-Nachrichten sind Nachrichten, welche über die TALI-Schicht einer Seite einer stromorientierten Verbindung übertragen werden und welche durch die TALI-Schicht auf der anderen Seite einer stromorientierten Verbindung beendet werden. Die gleichberechtigten TALI-Nachrichten, welche hier beschrieben werden, beinhalten Testnachrichten zum Prüfen des Zustands einer Verbindung, Erlaubnis- und Verbotsnachrichten zum Erlauben und Verbieten von Kommunikation über eine Verbindung ohne das Aufrufen von TCP-Verbindungserstellungs- oder -beendigungsprozeduren und Überwachungsnachrichten zum Messen der Umlaufzeit einer Verbindung. Jede dieser Nachrichten wird nun detaillierter diskutiert.
Testnachrichten werden von einer TALI-Implementierung benutzt, um das entfernte Ende einer TALI-Verbindung zu fragen, in Bezug auf die Bereitschaft des entfernten Endes, SS7-Dienstdaten zu tragen. Testnachrichten werden vorzugsweise periodisch von jeder TALI-Implementierung basierend auf einem vorher festgelegten Auszeitwert gesendet. Beim Empfangen einer Testnachricht muss eine TALI-Implementierung entweder über eine Verbots- oder eine Erlaubnisnachricht erwidern, um anzuzeigen, ob die TALI-Implementierung SS7-Dienstdaten über eine TALI-Verbindung tragen wird. Wenn keine Antwort innerhalb einer vorher festgelegten Zeitperiode empfangen wird, kann die Verbindung zurückgesetzt und/oder wieder erstellt werden.
Tabelle 1 unten stellt die Paketstruktur einer Testnachricht dar. In der Tabelle 1 beinhaltet die Testnachricht ein SYNC-Feld, ein OPCODE-Feld und ein LENGTH-Feld. Das SYNC-Feld ist auf TALI eingestellt, das OPCODE-Feld ist auf Test eingestellt, und das LENGTH-FELD ist auf 0 eingestellt.
Tabelle 1: Testnachricht
10 ist ein Flussdiagramm, welches beispielhaft die Schritte darstellt, welche durch ein TALI-Verfahren beim Überwachen des Zustands der Verbindung durchgeführt werden, wobei Testnachrichten benutzt werden. Im Schritt ST1 sendet das TALI-Verfahren 322 eine Testnachricht zu einem gleichrangigen auf der anderen Seite einer Verbindung. Im Schritt ST2 startet das TALI-Verfahren 322 die Zeitabläufe T1 und T2. Der Zeitablauf T1 kann benutzt werden, um zu bestimmen, wenn die nächste Testnachricht zu senden ist, und der Zeitablauf T2 kann benutzt werden, um die Zeit für das Empfangen einer gültigen Antwort auf die Testnachricht zu bestimmen. Im Schritt ST3 werden die Zeitabläufe T1 und T2 mit vorher festgelegten Werten verglichen. Beispielsweise kann der vorher festgelegte Wert für den Zeitablauf T1 auf eine Zeitdauer für das Senden der nächsten Testnachricht eingestellt werden. Der Zeitwert T2 kann auf eine vorher festgelegte Zeitdauer eingestellt werden, welche vorzugsweise kleiner als der Aufrechterhaltungszeitablauf für TCP ist. Beispielsweise kann die Auszeitdauer für zweimalige Umläufe für die gegebene Verbindung eingestellt werden. Ein Verfahren zum Messen der Umlaufzeit einer Verbindung wird nachfolgend detaillierter diskutiert.
Im Schritt ST4 bestimmt das TALI-Verfahren 322, ob der Zeitablauf T2 abgelaufen ist und gestoppt wurde. Der Zeitablauf T2 läuft ab, wenn er die Auszeitperiode erreicht, welche für T2 eingestellt ist. Der Zeitablauf T2 stoppt, wenn eine Erlaubnis- oder eine Verbotsnachricht empfangen wird. Falls der Zeitablauf T2 nicht abgelaufen ist oder gestoppt wurde, fährt das TALI-Verfahren 322 fort, den Zeitablauf zu prüfen. Falls das TALI-Verfahren 322 bestimmt, dass der Zeitablauf T2 abgelaufen ist, bestimmt das TALI-Verfahren 322 im Schritt ST5, ob eine gültige Antwort auf die Testnachricht empfangen wurde. Wie oben diskutiert wurde, kann eine gültige Antwort auf die Testnachricht eine Erlaubnisnachricht oder eine Verbotsnachricht sein. Falls eine gültige Antwort empfangen wurde, bestimmt das TALI-Verfahren 322, ob der Zeitablauf T1 abgelaufen ist oder gestoppt wurde, und wenn dem so ist, sendet es eine andere Testnachricht an die andere Seite (Schritte ST6 und ST1). Falls eine gültige Antwort nicht erhalten wurde, kann im Schritt ST7 das TALI-Verfahren 322 zurückgesetzt werden und versuchen, die Verbindung wieder zu erstellen. Da die Auszeitperiode vorzugsweise kleiner als die einer TCP-Verbindung ist, liefert das Überwachen des Verbindungsstatus, wobei die Testnachrichten benutzt werden, ein effizienteres Verbindungsmanagement als der TCP. Außerdem, da die Testnachrichten periodisch gesendet werden und an ihnen gearbeitet wird, können die TALI-Verbindungen zuverlässig gewartet werden.
Erlaubnis- und Verbotsnachrichten
Wie oben diskutiert, liefert das TALI-Protokoll Erlaubnis- und Verbotsnachricht zum Gestatten und Verbieten von Kommunikationen über eine TCP-Verbindung ohne das Aufrufen von TCP-Verbindungs- und -Erstellungs- und -Beendigungsverfahrensweisen. Die Erlaubnisnachricht wird in Antwort auf eine Testanfrage oder in Antwort auf ein internes Implementierungsereignis gesandt, um anzuzeigen, dass eine TALI-Implementierung SS7-Dienstdaten über eine TALI-Sitzung tragen will. Wie es hier benutzt wird, bezieht sich eine TALI-Sitzung auf eine Verbindung auf der TALI-Ebene zwischen Endpunkten. Eine TALI-Sitzung kann durch das Erstellen einer TCP-Verbindung geschaffen werden, auf welche das Austauschen von Erlaubnisnachrichten folgt, wie es nachstehend detaillierter diskutiert wird. Die Erlaubnisnachricht informiert das entfernte Ende, dass SS7-Verkehr auf der Verbindung übertragen werden kann. Erlaubnis ist eine der zwei möglichen gültigen Antworten auf eine Testnachricht. Bevor der SS7-Verkehr über eine Verbindung getragen werden kann, ist es für beide Enden der Verbindung notwendig, Erlaubnisnachrichten zueinander zu senden. Die unten gezeigte Tabelle 2 stellt eine beispielhafte Paketstruktur für eine Erlaubnisnachricht dar. In Tabelle 2 beinhaltet die Erlaubnisnachricht ein SYNC-Feld, ein OPCODE-Feld und ein LENGTH-Feld. Das SYNC-Feld ist auf TALI eingestellt, um anzuzeigen, dass das Paket ein TALI-Paket ist. Das OPCODE-Feld ist auf "allo" (für gestattet) eingestellt, um eine Erlaubnisnachricht zu identifizieren. Das LENGTH-Feld ist auf 0 eingestellt, da das Dienstteil des TALI-Pakets keinerlei Daten trägt.
Tabelle 2: Erlaubnisnachricht
Ähnlich zur Erlaubnisnachricht wird die Verbotsnachricht in Antwort auf eine Testanfrage oder in Antwort auf ein internes Implementierungsereignis gesendet. Jedoch ist im Gegensatz zur Erlaubnisnachricht der Zweck der Verbotsnachricht anzuzeigen, dass eine TALI-Implementierung nicht willens ist, SS7-Dienst über die TALI-Sitzung zu tragen. Die Verbotsnachricht informiert das entfernte Ende, dass SS7-Verkehr nicht über die Verbindung übertragen werden kann. Solange ein Ende der Verbindung verboten bleibt, kann der SS7-Verkehr nicht über die Verbindung getragen werden. Tabelle 3 stellt eine beispielhafte Paketstruktur für eine Verbotsnachricht dar. In der Tabelle 3 beinhaltet die Verbotsnachricht ein SYNC-Feld, ein OPCODE-Feld und ein LENGTH-Feld. Das SYNC-Feld ist auf die TALI eingestellt, um die Nachricht als ein TALI-Paket zu identifizieren. Das OPCODE-Feld ist auf "proh" für verboten eingestellt. Das LENGTH-Feld ist auf 0 eingestellt, da die Nachricht keinerlei Daten in dem Dienstteil der Nachricht trägt.
Tabelle 3: Verbotsnachricht
Eine Verbotsbestätigungsnachricht ist eine Nachricht, welche durch eine TALI-Implementierung in Antwort auf das Empfangen einer Verbotsnachricht von dem entfernten Ende einer Verbindung gesendet wird. Das Empfangen einer Verbotsbestätigungsnachricht zeigt an, dass die Verbotsnachricht korrekt empfangen wurde und dass an ihr entsprechend agiert wird. Die Seite einer Verbindung, welche eine Verbotsbestätigungsnachricht empfängt, kann demnach annehmen, dass keine weiteren Daten über die Verbindung übertragen werden und dass es in Ordnung ist, einiges an gewünschter Aktion, welche zu der Verbindung gehört, durchzuführen. Die nachfolgend gezeigte Tabelle 4 zeigt eine Verhinderungsbetätigungsnachricht entsprechend einer Ausführungsform der vorliegenden Erfindung. In Tabelle 4 beinhaltet die Verbotsbestätigungsnachricht ein SYNC-Feld, ein OPCODE-Feld und ein LENGTH-Feld. Das SYNC-Feld kann den TALI-Wert beinhalten, um anzuzeigen, dass die Nachricht eine TALI-Nachricht ist. Das OPCODE-Feld kann den Wert "proa" speichern, um anzuzeigen, dass die Nachricht eine Verbotsbestätigungsnachricht ist. Das LENGTH-Feld kann einen Wert von 0 beinhalten, da das Dienstteil der Nachricht keinerlei Daten enthält.
Tabelle 4: Verbotsbestätigungsnachricht
11 ist ein Flussdiagramm, welches die Vorteile des Benutzens der Verbots- und Bestätigungsnachrichten darstellt, um Verbindungen freizugeben und zu sperren. Im Schritt ST1 wird eine TALI-Sitzung zwischen zwei Knoten erstellt, dem Knoten A und dem Knoten B. Die Knoten A und B können jeweils irgendeine Art von Knoten sein, welche zuvor beschrieben wurden, in die es wünschenswert ist, einen TALI-Protokollstapel zu implementieren. Beispielsweise kann entweder der Knoten ein Signalisierungs-Gateway, ein Medien-Gateway-Steuergerät oder ein IP-fähiger SCP sein. Das Erstellen einer TALI-Sitzung kann das Erstellen einer TCP-Verbindung zwischen den Knoten A und B beinhalten, gefolgt von einem Austausch von Erlaubnisnachrichten zwischen den Knoten A und B. Sobald die Verbindung erstellt ist und Kommunikationen erlaubt sind, kommunizieren im Schritt ST2 die Knoten A und B, wobei die TALI-Sitzung benutzt wird. Eine derartige Kommunikation kann das Austauschen von SS7-Anrufsignalisierungsnachrichten beinhalten, wie z.B. SCCP-Nachrichten, TCAP-Nachrichten, ISUP-Nachrichten und MTP3-Nachrichten. Im Schritt ST3 sendet der Knoten A eine Verbotsnachricht an den Knoten B. Der Grund für das Senden der Verbotsnachricht kann sein, dass es der Knoten A wünscht, ein Software-Hochrüsten bzw. -Aktualisieren durchzuführen. Im Schritt ST4 bestimmt der Knoten A, ob eine Verbotsbestätigungsnachrichten empfangen wurde. Falls eine Verbotsbestätigungsnachricht nicht empfangen wurde, kann der Knoten A die Verbotsnachricht rückübertragen.
Sobald der Knoten A die Verbotsbestätigungsnachricht erhält, kann der Knoten A im Schritt ST5 annehmen, dass Daten nicht vom Knoten B über die verbotene Verbindung empfangen werden. Entsprechend kann der Manager des Knotens B eine gewünschte Aktion durchführen, wie z.B. ein Software-Hochrüsten bzw. -Aktualisieren. Wenn die gewünschte Aktion vollendet ist, kann der Knoten A im Schritt ST6 eine Erlaubnisnachricht an den Knoten B über die Verbindung senden. Sobald der Knoten B die Erlaubnisnachricht erhält, kann der Knoten B die Kommunikationen über die abgeschaltete Verbindung wieder aufnehmen. Da ein Transportadapterschicht-Interface erlaubt und verboten werden kann, ohne TCP-Verbindungserstellungs- und -beendigungsvorgehensweisen aufzurufen, sind die Zeit- und Verarbeitungsressourcen, welche für diese Operationen erforderlich sind, reduziert gegenüber herkömmlichen TCP-Prozeduren bzw. Vorgehensweisen.
Leistungsfähigkeitsmessung und Versionsidentifikation
Entsprechend einem anderen Gesichtspunkt der Erfindung können Nachrichten zwischen der TALI-Implementierung gesendet werden, um die Leistungsfähigkeit einer spezifischen Verbindung zu messen und die TALI-Versionsnummer zwischen Kommunikationsendpunkten zu kommunizieren. Eine Leistungsfähigkeitsmessung, welche von Interesse sein kann, ist die Umlaufzeit. Die Umlaufzeit ist die Zeit, welche eine Nachricht braucht, um von einer Seite einer Verbindung zu der anderen und zurück zu laufen. Die Grundlage für das Messen der Umlaufzeit entsprechend der vorliegenden Ausführungsform beinhaltet eine Überwachungsnachricht und eine Überwachungsbestätigungsnachricht. Eine Überwachungsnachricht liefert eine generische Echo-Fähigkeit, welche von einer TALI-Implementierung genutzt werden kann, um die Umlaufzeit zu messen. Die unten gezeigte Tabelle 5 ist ein Beispiel für eine Paketstruktur für die Überwachungsnachricht. In Tabelle 5 beinhaltet die Überwachungsnachricht ein SYNC-Feld, ein OPCODE-Feld, ein LENGTH-Feld, ein Versionsetikettfeld und ein Datenfeld. Das SYNC-Feld identifiziert die Überwachungsnachricht als eine TALI-Nachricht. Das OPCODE-Feld beinhaltet den Wert "moni", um die Nachricht als eine Überwachungsnachricht zu identifizieren. Das LENGTH-Feld beinhaltet die Länge des Datenteils der Überwachungsnachricht, welche lieferantenabhängige Daten enthält. Das Versionsetikettfeld in der Überwachungsnachricht kann benutzt werden, um die TALI-Versionsnummer an das entfernte Ende einer Verbindung zu kommunizieren. Die möglichen Versionsetikettfeldwerte xxx.yyy spezifizieren die größeren und kleineren TALI-Versionsnummern. Beispielsweise spezifiziert ein Versionsetikettfeldwert von 001.000 die TALI-Version 1.0.
Tabelle 5: Versionssteuerung-"moni"-Nachricht
In Antwort auf das Empfangen einer Überwachungsnachricht sendet eine TALI-Sitzung vorzugsweise eine Überwachungsbestätigungsnachricht. Tabelle 6, welche nachfolgend gezeigt wird, stellt eine Beispielpaketstruktur für eine Überwachungsbestätigungsnachricht dar. In dem dargestellten Beispiel beinhaltet die Überwachungsbestätigungsnachricht ein SYNC-Feld, ein OPCODE-Feld, ein LENGTH-Feld und ein Datenfeld. Das SYNC-Feld speichert den TALI-Wert, um den Start eines TALI-Pakets anzuzeigen. Das OPCODE-Feld speichert den Wert "mona", um das Paket als eine Überwachungsbestätigungsnachricht zu identifizieren. Das LENGTH-FELD speichert die Länge des Datenteils der Überwachungsbestätigungsnachricht. Das Datenteil der Überwachungsbestätigungsnachricht beinhaltet bevorzugt die gleichen Daten, welche in der Überwachungsnachricht gesendet wurden. Das Übereinstimmen der Daten gestattet, dass die Überwachungsnachricht mit der Überwachungsbestätigungsnachricht gepaart wird.
Tabelle 6: Überwachungsbestätigungsnachricht
12 ist ein Flussdiagramm, welches das Gebrauchen der Überwachungsnachricht und der Überwachungsbestätigungsnachricht darstellt, um die Umlaufzeit einer Verbindung zu messen und um die TALI-Versionsnummer an das entfernte Ende einer Verbindung zu kommunizieren. Im Schritt ST1 liest eine TALI-Implementierung einen Zeitablaufwert, welcher zu der lokalen Maschine gehört, und schließt den Zeitablaufwert in einer Überwachungsnachricht ein. Im Schritt ST2 platziert die TALI-Implementierung ihre TALI-Versionsnummer in die Überwachungsnachricht. Die Versionsnummer wird von der anderen Seite einer TALI-Verbindung benutzt, um die Versionsnummer zu verfolgen. Beispielsweise kann beim Empfangen einer Überwachungsnachricht ein Endpunkt bestimmen, ob die Überwachungsnachricht einen gültigen Versionsetikettwert in dem Versionsetikettfeld besitzt. Dies kann das Vergleichen der Bytes beinhalten, welche dort platziert sind, wo das Versionsetikettfeld in der Überwachungsnachricht für eine vorher festgelegte Liste von Versionswerten sein sollte. Falls der Wert mit einem der Werte in der Liste übereinstimmt, speichert der Endpunkt dann diesen Wert als die TALI-Version für die andere Seite. Falls keine Übereinstimmung gefunden wird, kann der Endpunkt eine Fehlerversion für die andere Seite speichern, z.B. 1.0. Da beide Seiten einer Verbindung vorzugsweise Überwachungsnachrichten zueinander senden und die Überwachungsnachrichten die Sendeseiten-TALI-Versionsnummer beinhalten können, kann jede Seite der Verbindung die aktuelle Version der anderen Seite bestimmen.
In dem Schritt ST3 sendet die TALI-Implementierung die Überwachungsnachricht an die andere Seite einer Verbindung. Wie oben diskutiert, kann die andere Seite der Verbindung das Versionsetikett nutzen, um die TALI-Version der sendenden Seite zu aktualisieren. Die andere Seite der Verbindung ändert den OPCODE der Nachricht von Überwachung auf Überwachungsbestätigung und sendet die Nachricht an die sendende TALI-Implementierung zurück. Im Schritt ST5 empfängt die TALI-Implementierung die Überwachungsbestätigungsnachricht von der anderen Seite der Verbindung und extrahiert einen Zeitablaufwert von der Überwachungsbestätigungsnachricht. Im Schritt ST5 liest die TALI-Implementierung den lokalen Zeitablaufwert, wenn die Überwachungsbestätigungsnachricht empfangen wurde. Im Schritt ST6 berechnet die TALI-Implementierung die Umlaufzeit für die Verbindung basierend auf dem Unterschied zwischen dem lokalen Zeitablaufwert, wenn die Überwachungsnachricht empfangen wurde, und dem Zeitablaufwert, welcher von der Überwachungsbestätigungsnachricht gelesen wird. Das Berechnen der Umlaufzeit auf diese Weise gestattet das Optimieren der anderen Zeitabläufe, wie z.B. der Zeitabläufe für Rückübertragung.
Beglaubigung der kritischen Nachrichten
Wie oben aufgezeigt, können viele der Nachrichten, welche zwischen den TALI-Implementierungen gesendet werden, Kommunikationen über eine Verbindung zulassen und/oder verbieten. Da derartige Nachrichten in einer Telekommunikationsumgebung verhängnisvoll sein können, ist es vorzuziehen, dass Sicherheitsnachrichten implementiert werden, um sicherzustellen, dass nur autorisierte Benutzer diese Nachrichten senden können. Ein Verfahren, um diesen Schutz zu liefern, besteht darin, kritische Nachrichten zu beglaubigen.
Hier beschriebene Beispiele kritischer Nachrichten sind Verbotsnachrichten und Testnachrichten. Um sicherzustellen, dass diese Nachrichten durch autorisierte bzw. beglaubigte Benutzer übertragen werden, können Verschlüsselungs- und/oder Beglaubigungsverfahren benutzt werden. In einem Beispiel kann ein öffentlicher Verschlüsselungsschlüsselalgorithmus, wie z.B. Rivest, Shamir, Adleman (RSA), benutzt werden, um zu verifizieren, dass die Nachricht von einem autorisierten Benutzer ihren Ursprung hat. Um eine Nachricht zu beglaubigen, wobei ein öffentlicher Verschlüsselungsschlüsselalgorithmus benutzt wird, sendet der sendende Knoten seinen öffentlichen Schlüssel an den Empfangsknoten. Der sendende Knoten unterzeichnet dann die Nachricht, wobei sein privater Schlüssel benutzt wird. Der empfangende Knoten beglaubigt die Nachricht, wobei der öffentliche Schlüssel des sendenden Knotens benutzt wird. Falls die Nachricht korrekt beglaubigt wird, d.h. falls eine gültige TALI-Nachricht empfangen wird, weiß dann der empfangende Knoten, dass die Nachricht von einem autorisierten Benutzer kam. Auf diese Weise kann die Sicherheit von TALI-Verbindungen erhöht werden.
Entsprechend einem anderen Gesichtspunkt der Erfindung können kritische Nachrichten in einer unterschiedliche Weise beglaubigt werden, wobei ein öffentliches Schlüssel-Verschlüsselungssystem benutzt wird. Beispielsweise können ein Sender und ein Empfänger öffentliche Schlüssel austauschen. D.h., der Sender S kann den öffentlichen Schlüssel von S an den Empfänger R senden, und R kann den öffentlichen Schlüssel von R an S senden. S kann dann eine kritische Nachricht verschlüsseln, wie z.B. eine Verbotsnachricht, wobei der öffentliche Schlüssel von R benutzt wird. Wenn R die Nachricht empfängt, kann R die Nachricht unter Benutzung des privaten Schlüssels von R entschlüsseln. Wenn die Nachricht korrekt entschlüsselt wird, weiß R, dass die Nachricht von irgendjemandem kommt, welcher Zugriff auf den öffentlichen Schlüssel von R hat. R kann dann eine Antwortnachricht verschlüsseln, z.B. eine Verbots-Bestätigungsnachricht, wobei der öffentliche Schlüssel von S benutzt wird. S kann die Nachricht unter Benutzung des privaten Schlüssels von S entschlüsseln. Falls die Nachricht korrekt entschlüsselt wird, weiß S, dass die Nachricht von irgendjemand stammt, welcher Zugriff auf den öffentlichen Schlüssel von S hat. Auf diese Weise kann eine Zwei-Wege-Beglaubigung erreicht werden.
Es wird verstanden werden, dass verschiedene Details der Erfindung geändert werden können, ohne vom Umfang der Erfindung abzuweichen. Außerdem dient die vorausgegangene Beschreibung nur dem Zweck der Erläuterung und nicht dem Zweck der Eingrenzung, wobei die Erfindung durch die Ansprüche definiert wird.

Claims

Verfahren zum Verkapseln einer Signalisierungsverbindungssteuerteil-(SCCP-)Nachricht in einem Internet-Protokoll-(IP-)Datagramm, wobei ein Transportadapterschicht-Interface (TALI) benutzt wird, wobei das Verfahren oder das Computerprogrammprodukt die folgenden Schritte beinhaltet oder ausführt: (a) Empfangen einer SS7-Nachrichtsignaleinheit (MSU), wobei die SS7-MSU Nachrichtübertragungsteil-(MTP-)Schichten 1, 2 und 3 und eine SCCP-Schicht aufweist, (b) Verwerfen von MTP-Schicht-1-und-2-Informationen von der SS7-MSU; (c) Platzieren der SCCP-Schicht in einem Dienstteil eines TALI-Pakets; (d) Hinzufügen eines TALI-Nachrichtenkopfes an dem TALI-Paket; und (e) Hinzufügen von stromorientierten Verbindungsprotokoll- und IP-Nachrichtenköpfen an das TALI-Paket.
Verfahren nach Anspruch 1, welches das Platzieren der MTP-Schicht-3-Information ohne Modifikation in das Dienstteil des TALI-Pakets aufweist.
Verfahren nach Anspruch 1, welches das Extrahieren der MTP-Schicht-3-Information von der SS7-MSU und das Platzieren der MTP-Schicht-3-Information in der SCCP-Schicht aufweist.
Verfahren nach Anspruch 3, in welchem das Extrahieren der MTP-Schicht-3-Information das Extrahieren eines Ursprungspunktcode-(OPC-)Wertes von der SS7-MSU beinhaltet und das Platzieren der MTP-Schicht-3-Infornation in der SCCP-Schicht das Platzieren des OPC-Wertes in einem Anrufer-Adressfeld in der SCCP-Schicht beinhaltet.
Verfahren nach Anspruch 3, in welchem das Extrahieren der MTP-Schicht-3-Information das Extrahieren eines Zielpunktcode-(DPC-)Wertes von der SS7-MSU beinhaltet und das Platzieren der MTP-Schicht-3-Information in der SCCP-Schicht das Platzieren des DPC-Wertes in einem Anrufer-Adressfeld in der SCCP-Schicht beinhaltet.
Verfahren nach Anspruch 1, welches das Setzen eines SYNC-Feldes in dem TALI-Paket auf einen vorbestimmten Wert beinhaltet, welcher den Beginn des TALI-Pakets für stromorientierte bzw. verbindungsorientierte Kommunikation anzeigt.
Verfahren nach Anspruch 1, welches das Setzen eines LENGTH- bzw. LÄNGE-Feldes in dem TALI-Paket auf einen Wert aufweist, welcher die LENGTH bzw. LÄNGE des Serviceteils des TALI-Pakets anzeigt.
Verfahren nach Anspruch 1, welches das Setzen eines OPCODE-Feldes in dem TALI-Paket auf einen vorbestimmten Wert aufweist, um das TALI-Paket als ein SCCP-Paket zu identifizieren.
Verfahren zum Verkapseln eines Nachrichtenübertragungsteil-Schicht-3-(MTP3-)Paketes in ein Internet-Protokoll-(IP-)Datagramm, wobei ein Transportadapterschicht-Interface (TALI) benutzt wird, wobei das Verfahren oder das Computerprogrammprodukt die folgenden Schritte beinhaltet oder ausführt: (a) Empfangen einer MTP3-Nachrichtensignaleinheit (MSU), wobei die MTP3-MSU MTP-Schichten 1, 2 und 3 beinhaltet; (b) Verwerfen der MTP-Schichten 1 und 2 von der MTP3-MSU; (c) Platzieren einer MTP-Schicht-3-Information von der MTP3-MSU in einem Dienstteil eines TALI-Pakets; (d) Hinzufügen eines TALI-Nachrichtenkopfes an das TALI-Paket; und (e) Hinzufügen von stromorientierten Transportprotokoll- und IP-Nachrichtenköpfen an das TALI-Paket.
Verfahren nach Anspruch 9, in welchem das Platzieren der MTP-Schicht-3-Information in dem Serviceteil das Platzieren eines Routing-Etiketts bzw. -Kennzei- Kennzeichens und eines Dienstindikationsoktetts (SIO) in dem Dienstteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 10, in welchem das Platzieren der MTP-Schicht-3-Information in dem Dienstteil das Platzieren der Schicht-3-Information zusätzlich zu dem Routing-Etikett und dem SIO in dem Dienstteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 11, in welchem das Platzieren von Information zusätzlich zu dem Routing-Etikett und dem SIO das Platzieren von Netzwerksteuerungsinformation in dem Serviceteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 12, in welchem das Platzieren von Netzwerksteuerinformation in dem Dienstteil des TALI-Pakets das Platzieren von Umschaltinformation in dem Dienstteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 12, in welchem das Platzieren von Netzwerksteuerinformation in dem Serviceteil des TALI-Pakets das Platzieren von Rückschaltinformation in dem Serviceteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 12, in welchem das Platzieren von Netzwerksteuerinformation in dem Dienstteil des TALI-Pakets das Platzieren von Flusssteuerinformation in dem Dienstteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 11, in welchem das Platzieren von Information zusätzlich zu dem Routing-Etikett und der SIO das Platzieren von Netzwerktestinformation in dem Dienstteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 16, in welchem das Platzieren von Netzwerktestinformation in dem Dienstteil eines TALI-Pakets das Platzieren von Signalisierungs-Route-Einstellungstestinformation in dem Dienstteil des TALI-Pakets beinhaltet.
Verfahren nach Anspruch 9, welches das Setzen eines SYNC-Feldes in dem TALI-Paket auf einen vorbestimmten Wert aufweist, welcher den Beginn des TALI-Pakets für stromorientierte Kommunikation anzeigt.
Verfahren nach Anspruch 9, welches das Setzen eines LENGTH-Feldes in dem TALI-Paket auf einen Wert aufweist, welcher die LENGTH bzw. LÄNGE des Dienstteils des TALI-Paketes anzeigt.
Verfahren nach Anspruch 9, welches das Setzen des OPCODE-Feldes auf einen vorbestimmten Wert aufweist, um das TALI-Paket als ein MTP3-Paket zu identifizieren.
Verfahren nach Anspruch 9, welches das Hinzufügen einer Anwendungsschicht-Reihenfolgenummer an das TALI-Paket aufweist.
Verfahren nach Anspruch 21, welches das Hinzufügen einer Anwendungsschicht-Reihenfolgenummer aufweist, wobei das Hinzufügen eines dienstspezifischen, verbindungsorientierten Protokoll-(SSCOP-)Dateiende-Etiketts an dem TALI-Paket beinhaltet.
Verfahren zum Überwachen des Zustands einer stromorientierten Transportprotokollverbindung, welche zum Kommunizieren von SS7-Nachrichten zwischen SS7- und Internet-Protokoll-(IP-)Knoten benutzt wird, wobei das Verfahren oder das Computerprogrammprodukt die folgenden Schritte beinhaltet oder ausführt: (a) Erstellen einer ersten stromorientierten Transportprotokollverbindung für Kommunikations-SS7-Nachrichten zwischen einem ersten Signalisierungsknoten und einem zweiten Signalisierungsknoten; (b) Übertragen einer ersten Transportadapterschicht-Interface-(TALI-)Protokollnachricht, welche in einem stromorientierten Transportprotokollsegment verkapselt ist, über die erste stromorientierte Transportprotokollverbindung; (c) Horchen nach einer Rückantwort auf die erste Nachricht über die erste stromorientierte Transportprotokollverbindung; und (d) in Antwort darauf, dass das Empfangen der Erwiderungsnachricht innerhalb einer vorbestimmten Zeitperiode misslingt, Behandeln der ersten stromorientierten Transportprotokollverbindung als ausgeschaltete Transportprotokollverbindung.
Verfahren nach Anspruch 23, welches in Antwort auf das Fehlschlagen des Empfangs der Rückantwort innerhalb einer vorbestimmten Zeitperiode das Versuchen aufweist, die Kommunikation über die erste stromorientierte Transportprotokollverbindung wieder zu erstellen.
Verfahren nach Anspruch 23, in welchem die vorbestimmten Zeitperiode kleiner als ein stromorientierter Transportprotokoll-Abschaltungstotzeitwert ist.
Verfahren nach Anspruch 23, in welchem das Übertragen einer ersten TALI-Protokollnachricht das Übertragen einer TALI-Testnachricht beinhaltet und das Horchen nach einer Rückantwort das Horchen nach einer TALI-Erlaubnis- oder -Verbotsnachricht beinhaltet.
Verfahren nach Anspruch 23, welches in Antwort auf das Empfangen der Rückantwort das Bestimmen einer Umlaufzeit (RTT) zwischen dem ersten und dem zweiten Signalisierungsknoten aufweist.
Verfahren nach Anspruch 27, in welchem das Bestimmen einer Umlaufzeit beinhaltet: (a) Lesen eines lokalen Zeittaktwertes und Einfügen des lokalen Zeittaktwertes in die erste Nachricht; (b) Lesen des lokalen Zeittaktwertes, wenn die Rückantwort empfangen wird; (c) Lesen eines Zeittaktwertes aus der Rückantwort; und (d) Berechnen des RTT, basierend auf dem Unterschied zwischen dem Zeittaktwert in der Rückantwort und dem lokalen Zeittaktwert, wenn die Rückantwort empfangen wurde.
Verfahren nach Anspruch 23, welches das Einfügen einer lokalen TALI-Versionsnummer in der ersten TALI-Protokollnachricht aufweist.
Verfahren zum Anhalten und Zurückweisen von SS7-Nachrichtenkommunikation über eine stromorientierte Transportprotokollverbindung, wobei das Verfahren oder Computerprogramm die folgenden Schritte beinhaltet oder ausführt: (a) Erstellen einer ersten stromorientierten Transportprotokollverbindung zwischen einem ersten Signalisierungsknoten und einem zweiten Signalisierungsknoten; (b) Senden und Empfangen von stromorientierten, Transportprotokoll-verkapselten SS7-Nachrichten über die erste stromorientierte Transportprotokollverbindung und (c) Empfangen einer ersten Steuernachricht über die erste stromorientierte Transportprotokollverbindung und in Antwort darauf Anhalten des Sendens der SS7-Nachrichten über die erste stromorientierte Transportprotokollverbindung.
Verfahren nach Anspruch 30, welches nach dem Empfangen der ersten Steuernachricht aufweist: Zurückweisen des Sendens der SS7-Nachrichten über die erste stromorientierte Transportprotokollverbindung in Antwort auf das Empfangen einer zweiten Steuernachricht über die erste stromorientierte Transportprotokollverbindung.
Verfahren nach Anspruch 30, welches in Antwort auf das Empfangen der ersten Steuernachricht aufweist: Schalten von SS7-Kommunikation zwischen dem ersten und zweiten Signalisierungsknoten zu einer zweiten stromorientierten Transportprotokollverbindung, welche zwischen dem ersten und dem zweiten Signalisierungsknoten erstellt ist.
Verfahren nach Anspruch 30, in welchem das Empfangen einer ersten Steuernachricht beinhaltet: Empfangen der ersten Steuernachricht, welche unter Benutzung eines vorbestimmten Verschlüsselungsalgorithmus unterzeichnet ist, und Verifizieren, dass die erste Steuernachricht, welche von einem autorisierten Knoten herrührt, den ersten Verschlüsselungsalgorithmus benutzt.
Verfahren nach Anspruch 30, in welchem das Erstellen einer stromorientierten Transportprotokollverbindung zwischen dem ersten und dem zweiten Signalisierungsknoten das Erstellen der ersten stromorientierten Transportprotokollverbindung zwischen einem Signalisierungs-Gateway und einem Medien-Gateway-Steuergerät beinhaltet.
Verfahren nach Anspruch 30, in welchem das Erstellen einer Verbindung zwischen dem ersten und dem zweiten Signalisierungsknoten das Erstellen einer Verbindung zwischen einem ersten SS7-Signalisierungsknoten und einem IP-Knoten beinhaltet.
Verfahren nach Anspruch 30, in welchem das Erstellen einer Verbindung zwischen dem ersten und zweiten Signalisierungsknoten das Erstellen einer Verbindung zwischen einem ersten IP-fähigen SS7-Signalisierungsknoten und einem zweiten IP-fähigen SS7-Knoten beinhaltet.
Verfahren zum Verarbeiten von Transportadapterschicht-Interface-(TALI-)Nachrichten, welche über eine stromorientierte Transportprotokollverbindung empfangen wird, wobei das Verfahren oder das Computerprogrammprodukt die folgenden Schritte beinhaltet oder ausführt: (a) Empfangen einer Mehrzahl von TALI-Nachrichten über eine stromorientierte Transportprotokollverbindung; (b) Identifizieren des Beginns jeder der TALI-Nachrichten, wobei ein erstes Feld in jeder der TALI-Nachrichten benutzt wird; (c) Identifizieren des Endes jeder der TALI-Nachrichten, wobei ein zweites Feld in jeder der TALI-Nachrichten benutzt wird; und (d) Extrahieren individueller TALI-Nachrichtenpakete, wobei die ersten und zweiten Felder benutzt werden.
Verfahren nach Anspruch 37, welches das Identifizieren des Inhalts jeder der TALI-Nachrichten aufweist, wobei ein drittes Feld in jeder der TALI-Nachrichten benutzt wird.
Verfahren nach Anspruch 37, in welchem das Empfangen einer Mehrzahl von TALI-Nachrichten über eine stromorientierte Verbindung das Empfangen einer Mehrzahl von TALI-Nachrichten über eine stromorientierte Transportprotokollverbindung aufweist.
Verfahren nach Anspruch 37, in welchem das Identifizieren des Beginns jeder der TALI-Nachrichten das Identifizieren jeder der TALI-Nachrichten unter Benutzung eines SYNC-Feldes in jeder der TALI-Nachrichten beinhaltet.
Verfahren nach Anspruch 37, in welchem das Identifizieren des Endes jeder der TALI-Nachrichten unter Benutzung eines zweiten Datenfeldes das Identifizieren des Endes jeder der TALI-Nachrichten unter Benutzung eines LENGTH-Feldes zum Spezifizieren der Länge eines Datenteils jeder der TALI-Nachrichten beinhaltet.
Verfahren nach Anspruch 38, in welchem das Identifizieren des Inhalts jeder der TALI-Nachrichten unter Benutzung eines dritten Datenfeldes das Identifizieren des Inhalts jeder der TALI-Nachrichten unter Benutzung eines OPCODE-Feldes zum Spezifizieren des Inhalts jeder der TALI-Nachrichten beinhaltet.
Verfahren nach Anspruch 37, in welchem ein Datenteil jeder der TALI-Nachrichten SS7-Information trägt.
Kommunikationsnetzwerkelement zum Implementieren eines Transportadapterschicht-Interface-(TALI-)Protokollstapels, wobei das Kommunikationsnetzwerkelement aufweist: (a) ein TALI-Verfahren, welches zum Empfangen von SS7-Nachrichten geeignet ist, wobei SS7-Schicht-1-und-2-Information von den SS7-Nachrichten verwor fen wird, und geeignet ist, einen TALI-Nachrichtenkopf an jede der SS7-Nachrichten hinzuzufügen, um TALI-Nachrichten zu bilden; und (b) ein stromorientiertes Transportprotokollverfahren, welches geeignet ist, die TALI-Nachrichten von dem TALI-Prozess zu empfangen, stromorientierte Transportprotokoll- und IP-Nachrichtenköpfe an die TALI-Nachrichten hinzuzufügen und die TALI-Nachrichten an eine Empfangsapplikation über ein IP-Netzwerk basierend auf den stromorientierten Transportprotokoll- und IP-Nachrichtenköpfen weiterzuleiten.
Kommunikationsnetzwerkelement nach Anspruch 44, welches ein Datenkommunikationsmodul (DCM) aufweist, welches Hardware beinhaltet, welche geeignet ist, Nachrichten über das IP-Netzwerk zu senden und zu empfangen, wobei das TALI-Verfahren auf dem DCM implementiert ist.
Kommunikationsnetzwerkelement nach Anspruch 45, in welchem das stromorientierte Transportprotokollverfahren auf dem DCM implementiert ist.
Kommunikationsnetzwerkelement nach Anspruch 44, in welchem das stromorientierte Transportprotokollverfahren adaptiert ist, um einen Strom von TCP-Daten von dem IP-Netzwerk zu empfangen.
Kommunikationsnetzwerkelement nach Anspruch 44, in welchem der TALI-Prozess geeignet ist, den Strom von TCP-Daten von dem stromorientierten Transportprotokollverfahren zu empfangen und die individuelle TALI-Nachrichtengrenzen in dem Strom zu identifizieren.
Computerprogrammprodukt, welches ein Programm aufweist, welches auf einem von einer Maschine lesbaren Medium gespeichert ist, welches, wenn es in einem gewöhnlichen Computer geladen wird, diesen veranlasst, die Verfahrensschritte nach Anspruch 1 bis 43 auszuführen.