DE69937471T2

DE69937471T2 - Verfahren und Systeme zur Übermittlung von SS7-Nachrichten

Info

Publication number: DE69937471T2
Application number: DE69937471T
Authority: DE
Inventors: David M. Raleigh Sprague; Dan Alan Brendes; Venkatarmaiah Ravishankar; Paul Andrew Morrisville Miller
Original assignee: Tekelec Inc
Current assignee: Tekelec Global Inc
Priority date: 1998-12-04
Filing date: 1999-11-19
Publication date: 2008-08-21
Anticipated expiration: 2019-11-20
Also published as: EP1715658A1; EP1161819A1; CA2352246A1; EP1161819B1; EP1715658B1; WO2000035156A1; ATE541394T1; EP1161819A4; DE69932855T2; ATE377323T1; DE69932855D1; EP1879354B1; AU2153200A; ATE336846T1; DE69937471D1; EP1879354A1; CA2352246C

Description

Informationen zu Prioritätsanmeldungen
Diese Anmeldung beansprucht die Priorität von: US-Patentanmeldung 09/205,809 , eingereicht am 4. Dezember 1998 (anhängig); vorläufige US-Patentanmeldung Nr. 60/127,889 , eingereicht am 5. April 1999, und vorläufige US-Patentanmeldung Nr. 60/137,988 , eingereicht am 7. Juni 1999.
Bereich der Erfindung
Die vorliegende Erfindung bezieht sich im Allgemeinen auf Verfahren und Systeme für Kommunikations-Signalisiersystem-7-(SS7-)Nutzerteilnachrichten zwischen SS7-Knoten und Internet-Protokoll-(IP-)Knoten. Genauer gesagt bezieht sich die vorliegende Erfindung auf Verfahren und Systeme zum Kommunizieren von SS7-Nutzerteil-Nachrichten zwischen SS7-Signalisierungspunkten und IP-Knoten, wobei Signalübergabepunkte bzw. Zeichengabe-Transferpunkte (STPs) benutzt werden.
Hintergrund der Erfindung
Moderne Telekommunikationsnetzwerke beinhalten im Allgemeinen zwei getrennte Kommunikationspfade oder Unter- bzw. Teilnetzwerke. Das erste ist ein Sprachnetzwerk, welches die Übertragung von Sprache oder anderer Information zwischen den Benutzern handhabt. Das zweite ist ein Signalisierungsnetzwerk, welches das dynamische Verbinden einer Vielzahl von Sprachnetzwerkschaltungen erleichtert, so dass eine Verbindung vom Sprachtyp zwischen einem Anrufer und einem Angerufenen erstellt wird. Diese Funktionen werden im Allgemeinen als das Aufbauen und Abbauen eines Anrufs bezeichnet. Zusätzlich liefert das Signalisierungsnetzwerk ein Gerüst, über welches Informationen, die sich nicht auf Sprache beziehen, in einer Weise übertragen werden können, welche für den Benutzer transparent ist. Diese Signalisierungstechnik wird häufig als "Out of Band"- bzw. "Außerband"-Signalisieren bezeichnet, wobei der Term "Band" das Sprachband einbezieht. Gebräuchliche Beispiele eines derartigen Außerband-Datentransportes sind der Zugriff auf Datenbankdienste mit der 800-Nummer, Anrufkarten-Verifizierdienste, Dienste der Nummernportabilität und Anrufer-ID- bzw. -Identifizierdienste.
Um eine dauerhafte und zuverlässige Kommunikation über die Signalisiernetzwerk-Infrastruktur zu liefern, wurde ein allgemeines oder Standard-Digital-Signalisierprotokoll, welches als SS7 bekannt ist, entwickelt. SS7 ist ein allgemeines Kanalsignalisiersystem außerhalb des Bandes, welches gekennzeichnete Nachrichten benutzt, um schaltungsbezogene Signalisierinformationen, im Netzwerk befindliche Datenbankdienstinformationen und andere Informationen zu transportieren, welche für das Aufbauen von Kommunikationsdiensten benutzt werden können.
Aus der Sicht der Hardware beinhaltet ein SS7-Netzwerk eine Vielzahl von SS7-Knoten, welche im Allgemeinen als Signalisierpunkte (SPs) bezeichnet werden, welche miteinander unter Benutzen von Signalisierverbindungen verbunden sind, welche auch als SS7-Verbindungen bezeichnet werden. Wenigstens drei Typen von SPs werden in einem SS7-Netzwerk geliefert:
Dienstvermittlungspunkte (SSPs), Signalübertragungspunkte (STPs) und Dienststeuerpunkte (SCPs).
Ein SSP ist normalerweise in einem Tandem oder in Ämtern der Klasse-5 installiert. Der SSP ist in der Lage, sowohl Inband-Signalisieren als auch SS7-Signalisieren handzuhaben. Ein SSP kann eine Kundenvermittlung, ein Endamt, ein Zugriffstandem und/oder ein Tandem sein. Ein STP überträgt die Signalisiernachrichten von einer Signalisierungsverbindung zu einer anderen. Die STPs sind Paketvermittlungen und sind im Allgemeinen in passenden Paaren installiert. Schließlich steuern STPs den Zugriff zu Datenbanken, z. B. zu 800-Nummer-Umsetzungsdatenbanken, 800-Nummer-Trägeridentifikationsdatenbanken, Kreditkarten-Verifizierdatenbanken, etc.
Signalisierdatenverbindungen sind Übertragungseinrichtungen, welche benutzt werden, um SPs miteinander zu verbinden. Sie sind für die bidirektionalen Einrichtungen bestimmt, welche bei 56 kbps in den Vereinigten Staaten und in Kanada und bei 64 kbps arbeiten, wenn eine klare Kanaltauglichkeit eingesetzt ist. Normalerweise besitzt jede Verbindung ein zweites Glied für die Redundanz und eine erhöhte Netzwerkintegrität.
Signalisierdatenverbindungen beinhalten Zugriffsverbindungen oder "A"-Verbindungen, welche SSPs mit STPs verbinden und welche SCPs mit STPs verbinden, wie dies in 1 gezeigt wird. Brückenverbindungen oder "B"-Verbindungen werden benutzt, um paarweise STPs mit anderen paarweisen STPs zu verbinden, welche sich auf der gleichen hierarchischen Ebene befinden, wie dies in 2 gezeigt wird. Überkreuzverbindungen oder "C"-Verbindungen verbinden gepaarte STPs miteinander, wie dies in 3 gezeigt wird. C-Verbindungen werden für durchlaufende Nachrichten zwischen STPs benutzt, wenn Signalisiernetzwerkfehler auftreten.
Diagonalverbindungen oder "D"-Verbindungen verbinden STPs verschiedener hierarchischer Ebenen, wie dies in 4 gezeigt wird. Erweiterte Verbindungen oder "E"-Verbindungen verbinden SSPs mit STPs, welche nicht innerhalb ihres verbundenen lokalen STP-Bereichs sind, wie dies in 5 gezeigt wird. Schließlich völlig miteinander verknüpfte Verbindungen oder "F"-Verbindungen verbinden SSPs direkt miteinander, ohne STPs, wie dies in 6 gezeigt wird. 7 ist ein Blockdiagramm eines Zwei-Ebenen-SS7-Netzwerkes, welches eine Zusammenfassung des möglichen Verbindungseinsatzes beinhaltet.
SS7 beinhaltet auch ein Netzwerkprotokoll. Als Protokoll definiert SS7 eine Hierarchie oder eine Struktur der Information, welche in einer Nachricht oder in einem Datenpaket enthalten ist, welches zwischen SPs eines SS7-Netzwerkes über Signalisierverbindungen übertragen wird. Diese interne Datenstruktur wird oft als ein SS7-Protokollstapel bezeichnet, welcher die folgenden vier SS7-Ebenen beinhaltet:

Ebene 1: die physikalische Ebene
Ebene 2: die Datenverbindungs-(oder Verbindungs-)Ebene
Ebene 3: die Netzwerkebene
Ebene 4: Benutzerteile- und Anwendungsteile-Ebene

Die physikalische Ebene, welche auch als Nachrichtenübertragungsteil-(MTP-)Ebene 1 bezeichnet wird, ist die niedrigste oder die fundamentalste Ebene und ist die erste Ebene, welche benutzt wird, um eine eingehende Nachricht zu interpretieren und zu verarbeiten. Diese Ebene bestimmt und/oder liefert die elektrischen Charakteristika, um die digitalen Daten über die benutzte Schnittstelle zu übertragen. Auf die Interpretation/das Verarbeiten auf der physikalischen Ebene folgend wird die eingehende Nachricht zu dem Stapel oder der Datenverbindungsebene geführt.
Die Datenverbindungsebene, welche auch als MTP-Ebene 2 bezeichnet wird, sitzt benachbart und oberhalb der physikalischen Ebene und ist für das Liefern der Fehlerdetektierung/Korrektur und für das geeignet sequenzierte Liefern der SS7-Nachrichtenpakete verantwortlich. Auf die Interpretation/das Verarbeiten auf der Datenverbindungsebene folgend wird die eingehende Nachricht zu dem Stapel zur Netzwerkebene geführt.
Die Netzwerkebene, welche auch als MTP-Ebene 3 bezeichnet wird, liegt benachbart und oberhalb der Datenverbindungsebene und liefert die Information, welche für das Routen des Nachrichtenpaketes, die Unterscheidung des Nachrichtenpaketes und die Verteilung des Nachrichtenpaketes verantwortlich ist. Funktionell bestimmt die Nachrichtenunterscheidung, ob das Nachrichtenpaket zu dem empfangenden SP oder zu einem anderen SP adressiert ist. Falls die Nachricht die lokale Adresse des empfangenden SP enthält, wird die Nachricht weiter zur Nachrichtenverteilung geführt. Die Nachrichtenverteilung routet die Nachricht zu dem geeigneten Applikationsteil oder Benutzerteil innerhalb des empfangenden SP. Falls die Nachricht nicht zu dem empfangenden SP adressiert ist, wird sie dann weiter zu dem Nachrichten-Router geführt, welcher die physikalische Adresse des SP bestimmt, zu welchem die Nachricht zu senden ist. Auf die Interpretation/Verarbeitung auf der Netzwerkebene folgend wird die eingehende Nachricht hinauf zum Stapel zu der Benutzerteile- und Anwendungsteile-Ebene geführt.
Die Benutzerteile- und Anwendungsteile-Ebene liegt benachbart und oberhalb der Netzwerkebene. Die Nutzerteilprotokolle führen das Aufbauen und das Abbauen des Anrufs durch. Beispielhafte Nutzerteilprotokolle, welche in der SS7-Ebene 4 beinhaltet sein können, sind ISDN-Nutzerteil (ISUP), Telefonnutzerteil (TUP) und Breitband-ISDN-Nutzerteil (BISUP).
Die Anwendungsteilprotokolle liefern den Zugriff zu Netzwerkdatenbanken für Dienste, wie z. B. den 800-Nummer-Dienst, Kreditkartenverifizierung und Nummernportabilität. Das Transaction Capabilities Application Part bzw. Transaktionsfähigkeits-Anwendungsteil-(TCAP-)Protokoll ist ein Beispiel eines SS7-Ebene-4-Protokolls, welches benutzt werden kann, den Zugriff auf diese und andere Dienste zu liefern.
In der obigen Beschreibung wurde angenommen, dass eine eingehende Nachricht verarbeitet wird. Eine ausgehende Nachricht wird über den Protokollstapel in umgekehrter Richtung geführt, wobei er an der Benutzerteilebene eintritt und aus der physikalischen Ebene austritt. 8 zeigt eine SS7-Protokoll-Architektur relativ zu den SS7-Ebenen und relativ zu Standard-Offenen-System-Integrations-(OSI-)Schichten.
Die oben erwähnten SS7-Protokollebenen sind mit Hilfe von Hardware und Software implementiert, welche in den SS7-Signalisierungspunkten angesiedelt sind, wie z. B. den Signalisierübertragungspunkten (STPs). Ein STP mit hoher Leistungsfähigkeit wird durch den Aussteller der vorliegenden Anmeldung als die Eagle^® STP vermarktet. Ein Blockdiagramm eines herkömmlichen Eagle^® STP wird in 9 gezeigt. Eine detaillierte Beschreibung des Eagle^® STP kann in Eagle^® Feature Guide PN/9110-1225-01, Rev. B., Januar 1998, veröffentlicht durch Tekelec, gefunden werden, wobei diese Veröffentlichung hier als Referenz eingearbeitet ist. Wie in dieser Publikation beschrieben wird, beinhaltet Eagle^® STP, allgemein als 900 bezeichnet, die folgenden Untersysteme: Das Wartungs- und Verwaltungsteilsystem (MAS) 910, das Kommunikationsteilsystem 920 und das Anwendungsteilsystem 930. Das MAS 910 liefert Wartungskommunikationen, anfängliches Programmladen, periphere Dienste, Alarmverarbeiten und System-Disks bzw. -Scheiben. Das Kommunikationsteilsystem 920 beinhaltet einen Interprozessor-Nachrichtentransport-(IMT-)Bus, welcher der Hauptkommunikationsbus innerhalb aller Teilsystem im Eagle^® STP 900 ist. Dieses Hochgeschwindigkeitskommunikationssystem funktioniert als zwei mit 125 Mbps egenläufig umlaufende serielle Busse.
Das Anwendungsteilsystem 930 beinhaltet Anwendungskarten, welche in der Lage sind, mit anderen Karten über die IMT-Busse zu kommunizieren. Das dargestellte Anwendungsteilsystem 930 beinhaltet drei Typen von Anwendungskarten: ein Verbindungsschnittstellenmodul (LIM) 940, welches SS7-Verbindungen und X.25-Verbindungen liefert, ein Anwendungskommunikationsmodul (ACM) 950, welches eine TCP/IP-Schnittstelle für das Senden von Kopien der SS7-Nachricht-Signaleinheiten (MSUs) über Ethernet liefert, und ein Anwendungsdienstmodul (ASM) 960, welches eine Globaltitelübersetzung, Gateway-Screening und andere Dienste liefert. Ein Übersetzungsdienstmodul (TSM) kann auch für die lokale Nummernportabilität geliefert werden.
Das LIM 940 liefert Ebene-1- und einige Ebene-2-Funktionen auf den SS7-Signalisierverbindungen. Das ACM 950 liefert den Zugriff auf einen entfernten Host-Rechner für eine STP LAN-Fähigkeit. Die STP LAN-Fähigkeit liefert den Zugriff in einer Richtung auf Kopien der SS7 MSUs von dem STP zu einem entfernten Host-Rechner. Die Verbindung in einer Richtung von dem STP zu einem Host-Rechner wird über ein Ethernet-LAN geliefert, wobei das TCP/IP-Protokoll benutzt wird. Schließlich liefert das ASM 960 einen zusätzlichen Speicher, welcher benutzt wird, um die Übersetzungstabellen und Screening- bzw. Sortierdaten zu speichern. Eine detaillierte Beschreibung des Eagle^® STP wird in dem oben aufgeführten Feature Guide geliefert und muss nicht weiter beschrieben werden.
Ein kurzer konzeptioneller Überblick des Eagle^® STP wird in der Broschüre mit dem Titel Eagle^© STP Platform, Veröffentlichung 908-0126-01, Rev. A, Tekelec, 1997, beschrieben. Wie darin beschrieben wird, ist das Eagle^® STP ein völlig fehlertolerantes Paketvermittlungs- und geschlossenes lokales Netzwerk mit hoher Kapazität für das Austauschen von Datennachrichten zwischen einem halben Dutzend bis zu mehreren Hundert oder mehr Nachrichtenverarbeitungsmodulen. In der Eagle^® STP-Systemarchitektur greifen drei funktionell spezifische Anwendungsteilsysteme über ein Kommunikationsteilsystem aufeinander zu, welches zwei gegenläufig umlaufende, 125-Mbps-IMT-Busse beinhaltet. Die Anwendungsteilsysteme beinhalten LIMs, welche SS7- und X.25-Zugriff auf Telekommunikations-Signalisiernetzwerke liefern, ACMs, welche TCP/IP-Zugriff auf lokale Netzwerke liefern, und ein MAS, welches Wartungskommunikation, periphere Dienste-Alarmverarbeitung und Systemdisks liefert. Wie in dieser Broschüre festgestellt wird, "kommunizieren ACMs direkt mit externen, miteinander angeordneten Dienstanwendungssystemen über eine TCP/IP, eine 10-Mbit/s-LAN-Schnittstelle, welche auf dem Ethernet-Interface-Appliqué (EIA) befestigt ist. Beispiele von externen Anwendungssystemen beinhalten: einen SCP, welcher nicht mit SS7-Signalisierverbindungen ausgestattet ist, ein Routing- oder Lade-Datenbanksystem, zelluläre/PCS-Heimat- oder -Besucher-Ortsregister (HLR, VLR), ein Nachrichtenberechnungssystem, ein Verarbeitungssystem für Sprache/Aufzeichnung/Bild und andere intelligente Netzwerk(IN-) Dienstknoten und Peripherausstattungen, welche eine direkte Schnittstelle über SS7-Signalisierverbindungen erfordern". Demnach beschreibt die Eagle^® STP-Plattform-Veröffentlichung nicht die Kommunikation zwischen einem STP und einem SS7-Knoten. Die hier beschriebene ACM-Karte wird primär für Diagnosezwecke benutzt.
Eine detaillierte Beschreibung der Funktion der Eagle^® STP-LAN-Schnittstellenfähigkeit wird in der Broschüre mit dem Titel Eagle^® STP STP LAN Interface Feature, Veröffentlichung 908-0134-01, Rev. B, Tekelec 1997, gegeben. Darin wird beschrieben, "Das STP-LAN-Schnittstellenmerkmal gestattet das Sammeln von Kopien von SS7-Nachrichten, welche an den Eagle^® STP übergehen. Dieses Merkmal zusammen mit dem vom Nutzer gelieferten Datenverarbeitungsgerät gestattet dem Eagle^® STP, Funktionen unterhalb der normalen Signalübergabepunkt-(STP-)Funktionalität durchzuführen, z. B. Auditier- und Berechnungsfunktionen, Nachrichtenausscheiden und -verfolgen und Protokollübereinstimmungsanalyse. Das Eagle^® STP-LAN-Schnittstellenmerkmal versetzt den Benutzer in die Lage, eine externe Datensammlung oder Verarbeitungssysteme direkt an den Eagle^® STP über TCP/IP mit 10 Mbits/s Ethernet LAN anzuschließen. Es versetzt den Benutzer in die Lage, entweder ISUP-Nachrichten, SCCP/TCAP-Nachrichten oder beide auszuwählen, um sie zu dem externen Überwachungssystem zu übertragen. Es fügt auch einen Zeitstempel hinzu, um die ausgewählten Nachrichten und ihre Reihenfolge für die nachfolgende Verarbeitung zu identifizieren." Wie in dieser Broschüre auch gezeigt wird, ist die Ethernet LAN-Verbindung eine Verbindung in einer Richtung von dem ACM zu einem externen Prozessor (Host-Rechner) für Zwecke der Diagnose. Außerdem ist das Eagle^® STP LAN-Merkmal nicht für das Kommunizieren von SS7-Nachrichten zwischen SS7-Signalisierungspunkten geeignet, geschweige denn für das Kommunizieren von Nachrichten zu SS7-Signalisierungspunkten für das Aufbauen eines Anrufs oder für andere Signalisierfunktionen, welche sich auf einen Anruf beziehen.
Während das Kommunizieren von SS7-Nachrichten über SS7-Verbindungen in einigen Fällen wünschenswert sein kann, kann es auch wünschenswert sein, SS7-Nachrichten über andere Arten von Netzwerken zu kommunizieren. SS7-Verbindungen liefern ein zuverlässiges Kommunikationsmedium mit hoher Bandbreite mit SS7-Nachrichten. Jedoch ist eine dedizierte SS7-Verbindung teuer, und sie liefert häufig für eine Anwendung eine zu große Bandbreite. Zusätzlich macht die Ausweitung der Netzwerke, welche anders als SS7-Netzwerke sind, diese zu möglichen Kandidaten für den SS7-Nachrichtenverkehr. Ein Typ von Netzwerk, welches gewöhnlich benutzt wird, um SS7-Nachrichten zu transportieren, ist ein X.25-Netzwerk. Beispielsweise ist es dafür bekannt, ein Datenbanktransport-Zugriffsmerkmal zu liefern, welches SS7-Nachricht-Signalisiereinheiten abfängt, welche von einem X.25-Netzwerk aus ihren Ursprung haben. Dieses Merkmal wird in einer Broschüre mit dem Titel Eagle^® STP Database Transport Access Feature, Veröffentlichung 908-0136-01, Rev. B, Tekelec, 1997, beschrieben.
Es ist auch bekannt, Protokollwandler für einige Protokolle in Verbindung mit STPs zu benutzen. Beispielsweise liefert das Eagle^® STP X.25-Protokoll-Wandlungsmerkmal das Schnittstellenverbinden und die Verbindungsmöglichkeit zwischen Knoten eines SS7-Netzwerks und Knoten auf einem X.25-Netzwerk. Dieses Merkmal wird in einer Broschüre mit dem Titel Eagle° STP X.25 to SS7-IS.41 Protocol Conversion Feature, Veröffentlichung 908-0135-01, Rev. B, Tekelec, 1997, beschrieben. In ähnlicher Weise ist bekannt, ein ANSI-ITU-Gateway zu liefern, um einen Eagle^® STP in die Lage zu versetzen, mit anderen Arten von Signalisierungsnetzwerken verbunden zu werden. Dieses Merkmal wird in einer Broschüre mit dem Titel Eagle^® STP ANSI-ITU Gateway Feature, Veröffentlichung 908-0133-01, Rev. B, Tekelec, 1997, beschrieben.
Protokollwandler sind auch für das Übersetzen von Protokollen zwischen SS7- und Nicht-SS7-Netzwerken bekannt. Beispielsweise übersetzt das Tekelec-SS7-Frame Relay Access Device bzw. -FR-Zugangsgerät (FRAD) die SS7-Protokollinformation zwischen einem SS7-Netzwerk und einem Frame-Relay-Netzwerk. Dieses Merkmal wird in einer Broschüre mit dem Titel SS7-Frame Relay Access Device SS7 Protocol Information Translator beschrieben.
Die Protokollwandlung für SS7-Netzwerke wird auch im US-Patent 5,793,771 für Darland et al. mit dem Titel "Communication Gateway" (nachfolgend das "771-Patent") beschrieben. Das '771-Patent beschreibt ein System und ein Verfahren für das Protokollübersetzen zwischen einem fremden Posttelefon- und Telegraphennetzwerk und einem Kommunikationsdienst-Anbieter vor Ort zum Verifizieren internationaler Kreditkartennummern. Das System beinhaltet ein Kommunikations-Gateway, welches aus einem Rechner besteht, welcher zwischen dem fremden Netzwerk und dem Ortsnetzwerk platziert ist, ausschließlich um die Protokollumwandlung durchzuführen. Das Kommunikations-Gateway ist nicht ein Signalisierungsübergangspunkt. Das Kommunikations-Gateway ist nur ein Protokollwandler, und das Kommunikations-Gateway beinhaltet ein SS7-Modul zum Senden und Empfangen einer Vielzahl von eingehenden und ausgehenden SS7-Anfragen und Antworten. Das Kommunikations-Gateway beinhaltet auch ein eingebundenes Teilsystemmodul, welches an dem SS7-Modul angekoppelt ist, um die eingehenden SS7-Anfragen von einem SS7-Protokoll in ein Nicht-SS7-Protokoll zu übersetzen.
In dem '771-Patent wird veröffentlicht, dass das eingebundene Teilsystemmodul eingehende SS7-Nachrichten in ein Network Information Distributed Service bzw. Netzwerk-Informationverteiltes-Dienst-(NIDS-)Format und ein TCP-Format wandelt.
Jedoch ist die einzige Art der SS7-Nachrichten, welche diskutiert werden, die TCAP-Nachrichten, wobei MTP- und SCCP-Schichten von den Nachrichten entfernt sind und ein TCP-Nachrichtenkopf an die Nachrichten hinzugefügt wird. Die übersetzten eingehenden Anfragen werden an einen Endbenutzer weitergeleitet, wobei das Nicht-SS7-Protokoll benutzt wird. Das eingebundene Teilsystemmodul übersetzt auch jegliche Antworten, welche den eingehenden SS7-Anfragen entsprechen, von dem Nicht-SS7-Protokoll zu dem SS7-Protokoll.
Das Kommunikations-Gateway des '771-Patents beinhaltet ferner ein nach außen gerichtetes Teilsystemmodul, welches an das SS7-Modul gekoppelt ist, um ausgehende SS7-Anfragen von dem Nicht-SS7-Protokoll in das SS7-Protokoll zu übersetzen. Wiederum werden diese Anfragen als TCAP-Anfragen für internationale Kreditkartenverifizierung veröffentlicht. Die übersetzten ausgehenden Anfragen werden über das SS7-Modul über ein SS7-Netzwerk gesendet. Das nach außen gerichtete Teilsystemmodul übersetzt auch die SS7-Antworten, welche den nach außen gehenden SS7-Anfragen entsprechen, von dem SS7-Protokoll in das Nicht-SS7-Protokoll. Die übersetzten Antworten, welche den ausgehenden SS7-Anfragen entsprechen, werden zu einem Endbenutzer weitergeleitet, während sie in dem Nicht-SS7-Protokoll sind.
In dem US-Patent 5,706,286 für Reiman et al. mit dem Titel "SS7 Gateway" wird ein Protokollwandler getrennt von einem STP veröffentlicht, welcher TCAP-Anfragen in ein KIDS-Format wandelt und umgekehrt für die Kreditkartenvalidierung.
In dem US-Patent 5,640,446 für Everett et al. mit dem Titel "System and Method of Validating Special Service Calls Having Different Signaling Protocols" wird ein Protokollwandler veröffentlicht, welcher extern zu einem STP ist, welcher die TCAP-Anfragen in NIDS-Format für Anrufkartentransaktionen wandelt.
Ein Problem bei herkömmlichen Protokollwandlern besteht darin, dass diese Einrichtungen ein spezielles Verarbeiten durch Hardware und durch Software erfordern, welche an einem getrennten Ort von dem STP angesiedelt ist. Diese Protokollwandler besitzen auch nicht die Verarbeitungsgeschwindigkeit und Funktionalität eines Signalübertragungspunktes, wie das oben erwähnte Eagle^® STP.
Noch ein weiteres Problem bei herkömmlichen Protokollwandlern besteht darin, dass die Protokollwandler nicht in der Lage sind, SS7-Nachrichten in andere Protokolle zu verwandeln, ohne die Schicht, welche transportiert wird, abzuschließen. Als Ergebnis können Wandler erforderlich sein, um den gesamten Protokollstapel zu implementieren. Noch ein weiteres Problem bei den oben erwähnten Protokollwandlern besteht darin, dass sie nur die Übersetzung zwischen SS7 TCAP-Nachrichten und TCP-Paketen angehen. Beim Verkapseln von TCAP-Nachrichten wird die MTP-Schicht-3-Information von der Nachricht abgestreift. Es gibt zahlreiche andere SS7-Nachrichten-Nutzlast-Typen (ISUP, TUP, BISUP, etc.), welche nicht TCP/IP-verkapselt werden können und nicht durch ein IP-Netzwerk geroutet werden können, ohne wenigstens einiges an Routing-Kennungs-Information zu beinhalten, welche in der MTP-Ebene 3 enthalten ist. Die Funktionalität von derartigen SS7-Nachrichten wird beeinträchtigt, wenn nicht sogar in vielen Fällen ohne diese MTP-Niedrigebenen- oder -Routing-Kennungs-Information zerstört. In der Praxis stellt eine derartige Protokollwandlungsaufgabe ein schwierigeres und herausforderndes Problem dar, als der verhältnismäßig einfache Fall der TCP/IP-verkapselten TCAP/SCCP-Information.
Entsprechend gibt es eine seit langem gefühlte Notwendigkeit für Verfahren und Systeme zum Übertragen von SS7-Nutzerteil-Nachrichten, welche MTP-Protokoll-Information von niedrigerer Ebene beinhalten, über ein IP-Netzwerk, welches Signalübertragungspunkte benutzt.
Veröffentlichung der Erfindung
Die vorliegende Erfindung beinhaltet ein Verfahren zum zuverlässigen Wiederherstellen von SS7-Nutzerteil-Nachrichtenpaketen, wenn ein TCP-Socket versagt. Das Verfahren beinhaltet das Erstellen erster und zweiter TCP-Verbindungen über erste und zweite Sockets zwischen ersten und zweiten SS7-Knoten. Die Datenpakete werden von dem ersten SS7-Knoten zu dem zweiten SS7-Knoten über eine der TCP-Verbindungen gesendet. Die Datenpakete beinhalten jeweils ein Anwendungsebene-Folgenummer-Anzeigeglied zum In-Reihenfolge-Bringen von Datenpaketen, welche durch die ersten und zweiten SS7-Knoten erhalten werden. In Antwort auf das Bestimmen, dass einer der TCP-Sockets fehlgeschlagen hat, wird ein Wiederherstellungspaket von jedem Knoten zu dem anderen Knoten gesendet, wobei die Anwendungsebene-Reihenfolgenummer, welche das letzte von jedem Knoten empfangene Datenpaket anzeigt, beinhaltet ist. Die Datenkommunikationen können dann über den Socket auftreten, welcher nicht fehlgeschlagen hat.
Diese und andere Aufgaben werden insgesamt oder zum Teil durch die vorliegende Erfindung erreicht. Einige der Aufgaben der Erfindung, welche hier oben aufgestellt wurden, und andere Aufgaben werden im Laufe der Beschreibung offensichtlich, wenn diese in Verbindung mit den beigefügten Zeichnungen hergenommen wird, welche nachfolgend bestens beschrieben werden.
Kurze Beschreibung der Zeichnungen
Die vorliegende Erfindung wird nun mit Bezug auf die beigefügten Zeichnungen beschrieben, von welchen:
1–7 Blockdiagramme sind, welche die Signalisierdatenverbindungen und SPs der herkömmlichen SS7-Netzwerke darstellen;
8 ist ein Blockdiagramm, welches die SS7-Protokollarchitektur in Relation zu den SS7-Ebenen und in Relation zu den Standard-Offenen-System-Integrations-(OSI-)Schichten darstellt;
9 ist ein Blockdiagramm eines herkömmlichen Eagle^® STP;
10–14 sind Blockdiagramme, welche beispielhaft Netzwerkkonfigurationen für die Kommunikation in zwei Richtungen von SS7-Nutzerteilnachrichten zwischen einem STP und wenigstens einem der anderen SPs in einem SS7-Netzwerk darstellen, wobei TCP/IP entsprechend den Ausführungsformen der vorliegenden Erfindung benutzt wird;
15 ist ein Blockdiagramm eines SP entsprechend einer Ausführungsform der vorliegenden Erfindung;
16 ist ein Blockdiagramm, welches den Transport der Nutzerteilnachrichten in zwei Richtungen innerhalb der SS7- und IP-Netzwerkelemente darstellt, wobei ein STP entsprechend einer Ausführungsform der vorliegenden Erfindung benutzt wird;
17 ist ein Blockdiagramm, welches eine Netzwerkkonfiguration beispielhaft für einen Nut zerteilnachrichtenfluss entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt;
18 ist ein Anrufablaufdiagramm, welches beispielhaft den Nut zerteilnachrichtenfluss in der Netzwerkkonfiguration darstellt, welche in 17 dargestellt wird;
19 und 20 sind Ablaufdiagramme, welche die Kommunikation in zwei Richtungen der SS7-Nachrichten zwischen einem STP und wenigstens einem anderen SP entsprechend zu Ausführungsformen der vorliegenden Erfindung zeigen;
21 ist ein Blockdiagramm von beispielhafter Hardware eines STP, welcher in der Lage ist, Nutzerteilnachrichten über IP-Netzwerke entsprechend einer Ausführungsform der vorliegenden Erfindung zu kommunizieren;
22 ist ein detailliertes Blockdiagramm, welches beispielhaft Software in einem STP für die SS7-Nutzerteilnachrichtenkommunikation in zweifacher Richtung über SS7- und IP-Netzwerke entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt;
23 ist ein Blockschaltbild, welches beispielhaft die Hardware für SS7-zu-IP-Nachrichtenfluss entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt;
24 ist ein Blockdiagramm einer beispielhaften Datenstruktur für das Senden von SS7-Nutzerteilnachrichten über IP-Netzwerke entsprechend einer Ausführungsform der vorliegenden Erfindung;
25 ist ein Blockdiagramm einer beispielhaften Datenstruktur für das Senden von SS7-Nutzerteilnachrichten über IP-Netzwerke entsprechend einer Ausführungsform der vorliegenden Erfindung; und
26 ist ein Flussschaltbild, welches eine beispielhafte SS7-Nachrichtenwiederherstellungs-Routine entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt.
Detaillierte Beschreibung von bevorzugten Ausführungsformen
Die vorliegende Erfindung wird nun nachfolgend vollständiger mit Bezug auf die beigefügten Zeichnungen beschrieben, in welchen bevorzugte Ausführungsformen der Erfindung gezeigt werden. Diese Erfindung kann jedoch in vielen unterschiedlichen Formen ausgeführt sein und diese sollten nicht so ausgelegt werden, dass sie auf die hier vorgestellten Ausführungsformen beschränkt sind; vielmehr werden diese Ausführungsformen geliefert, so dass diese Veröffentlichung sorgfältig und vollständig ist und somit vollständig den Umfang der Erfindung Fachleuten übermittelt. Ähnliche Zahlen beziehen sich auf ähnliche Elemente in derselben.
Beispielhafte Netzwerkkonfigurationen für bidirektionale Kommunikation von Nutzerteilnachrichten
10–14 sind Blockdiagramme, welche beispielhafte Netzwerkkonfigurationen für bidirektionale Kommunikation von SS7-Nutzerteilnachrichten zwischen einem STP und wenigstens einem der anderen SPs in einem SS7-Netzwerk darstellen, wobei TCP/IP entsprechend Ausführungsformen der vorliegenden Erfindung benutzt wird. Spezieller ausgedrückt, 10 stellt eine beispielhafte Netzwerkkonfiguration für die bidirektionale Kommunikation von SS7-Nutzerteilnachrichten zwischen einem STP und wenigstens einem SSP dar, wobei TCP/IP benutzt wird, um dadurch SS7-A-Verbindungen durch TCP/IP-Verbindungen zu ersetzen. Beispielsweise können STPs 1000 und 1002 SS7-Nutzerteilnachrichten zu SS7-Nutzerteilnachrichten von SSPs 1004 und 1006 über TCP/IP-Netzwerk 1008 senden und empfangen.
11 stellt eine beispielhafte Netzwerkkonfiguration für bidirektionale Kommunikation von SS7-Nutzerteilnachrichten zwischen STPs der gleichen hierarchischen Ebene dar, wobei SS7-B-Verbindungen mit TCP/IP-Verbindungen ersetzt werden. Beispielsweise könnten gepaarte STPs 1100 und 1102 SS7-Nutzerteilchnachrichten zu SS7-Nutzerteilnachrichten von gepaarten STPs 1104 und 1106 über das TCP/IP-Netzwerk 1108 senden und diese empfangen.
12 stellt eine beispielhafte Netzwerkkonfiguration für bidirektionale Kommunikation von Nutzerteilchnachrichten zwischen gepaarten STPs dar, wobei TCP/IP benutzt wird, wobei SS7-C-Verbindungen mit TCP/IP-Verbindungen ersetzt werden. Beispielsweise kann der STP 1200 SS7-Nutzerteilnachrichten zu SS7-Nutzerteilnachrichten vom STP 1202 über das TCP/IP-Netzwerk 1204 senden und diese empfangen. In ähnlicher Weise kann der STP 1206 SS7-Nutzerteilnachrichten zum STP 1208 senden und SS7-Nutzerteilnachrichten vom STP 1208 über das TCP/IP-Netzwerk 1204 empfangen.
13 stellt eine beispielhafte Netzwerkkonfiguration für bidirektionale Kommunikation von Nutzerteilnachrichten zwischen STPs von unterschiedlichen hierarchischen Ebenen dar, wobei TCP/IP-Verbindungen benutzt werden, wobei D-Verbindungen mit TCP/IP-Verbindungen ersetzt werden. Beispielsweise können lokale STPs 1300–1306 SS7-Nutzerteilnachrichten an regionale STPs 1308 und 1310 senden und SS7-Nutzerteilnachrichten von regionalen STPs 1308 und 1310 über das TCP/IP-Netzwerk 1312 empfangen.
14 stellt eine beispielhafte Netzwerkkonfiguration für bidirektionale Kommunikation von SS7-Nutzerteilnachrichten zwischen STPs und SSPs dar, welche nicht innerhalb des gleichen lokalen STP-Bereiches sind, wobei TCP/IP benutzt wird, wobei E-Verbindungen mit TCP/IP-Verbindungen ersetzt werden. Beispielsweise können STPs 1400 und 1402 in einem unterschiedlichen lokalen Bereich von STPs 1404 und 1406 und SSP 1408 platziert sein. Die Kommunikation von Nutzerteilnachrichten zwischen STPs 1400 und 1402 und SSP 1408 würden damit herkömmlicherweise über E-Verbindungen auftreten. Jedoch sind entsprechend der vorliegenden Erfindung die E-Verbindungen durch das TCP/IP-Netzwerk 1410 ersetzt. Demnach sind die STPs 1400 und 1402 in der Lage, SS7-Nutzerteilnachrichten zu SS7-Nutzerteilnachrichten von STPs 1404 und 1406 und SSP 1408 durch das TCP/IP-Netzwerk 1410 zu senden und diese zu empfangen. TCP/IP kann auch benutzt werden, um Kombinationen von A- bis E-Verbindungen durch das Kombinieren von einer oder von mehreren der 10–14 zu ersetzen.
STP, welcher ein SS7/IP-Nutzerteil-Kommunikationsglied beinhaltet
15 ist ein Blockdiagramm eines SP, welcher allgemein mit 1500 bezeichnet ist, entsprechend der Erfindung. Der SP 1500 kann auch als ein "Knoten" eines SS7-Netzwerks bezeichnet werden. Der SP 1500 kann irgendeine geeignete Kombination von Hard- und Software aufweisen, um die SS7- und IP-Vermittlungsfunktionen durchzuführen. Wie in 15 gezeigt wird, beinhaltet der SP 1500 einen STP 1510, welcher Nachrichten zwischen anderen SPs des SS7-Netzwerkes überträgt, wobei das SS7-Protokoll benutzt wird. Der SP 1500 beinhaltet auch ein SS7/IP-Nutzerteilnachrichten-Kommunikationsglied 1520, welches vorzugsweise innerhalb des STP 1510 integriert ist, um wenigstens einige der übertragenen SS7-Nutzerteilnachrichten zwischen dem STP 1510 und wenigstens einem der anderen SPs bidirektional zu kommunizieren, wie z. B. dem SP 1540 des SS7-Netzwerks, wobei ein IP-Netzwerk und vorzugsweise das TCP/IP-Netzwerk 1530 benutzt wird. In einer alternativen Ausführungsform kann das SS7-IP-Nutzerteil-Kommunikationsglied 1520 extern zum STP 1510 platziert sein.
Der STP 1510, welcher das SS7/IP-Nutzerteilnachrichten-Kommunikationsglied 1520 beinhaltet, kann benutzt werden, um einen nahtlosen Transport zwischen den SS7-Nutzerteil-Netzwerkelementen und zwischen den IP-Netzwerkelementen zu liefern. Beispielsweise, wie in 16 gezeigt wird, kann der STP 1510 benutzt werden, um bidirektional SS7-Nachrichten und andere Nachrichten zwischen einem ersten Signalisierungspunkt SP1 und einem zweiten Signalisierungspunkte SP2 zweier getrennter SS7-Netzwerke zu kommunizieren, wie dies durch den bidirektionalen Pfeil A1 gezeigt wird. Außerdem kann der STP 1510 auch benutzt werden, um bidirektional SS7-Nutzerteilnachrichten oder andere Nachrichten zwischen einem ersten IP-Knoten N1 und einem zweiten IP-Knoten N2 über eines oder über mehrere IP-Netzwerke zu kommunizieren, wie dies durch den bidirektionalen Pfeil A2 gezeigt wird.
Schließlich, wie durch die bidirektionalen Pfeile A3 und A4 gezeigt wird, kann der STP 1510 benutzt werden, SS7-Nutzerteilnachrichten oder andere Nachrichten zwischen Signalisierungspunkten SP1 und SP2 und IP-Knoten N1 und N2 zu kommunizieren. Daher kann ein STP, welcher ein SS7/IP-Nutzerteilnachricht-Kommunikationsglied aufweist, ein Router für das Kommunizieren von Nutzerteilnachrichten innerhalb von SPs in einem SS7-Netzwerk werden, zwischen SPs in einem SS7-Netzwerk und Knoten in einem IP-Netzwerk und zwischen Knoten in einem IP-Netzwerk. Ein nahtloser Transport von Nutzerteilnachrichten zwischen SS7- und IP-Netzwerkelementen kann dadurch geliefert werden, wobei ein STP mit einem SS7/IP-Nutzerteilnachricht-Kommunikationsglied benutzt wird.
Wie oben dargestellt wurde, werden die Nutzerteilnachrichten, wie z. B. die ISUP-Nachrichten, benutzt, um die Anrufaufbau- und Anrufabbaufunktionen durchzuführen. 17 stellt eine beispielhafte Netzwerkkonfiguration dar, um Nutzerteilnachrichten zwischen Endämtern beim Durchführen des Anrufaufbaus zu kommunizieren. In 17 ist der SSP 1700 mit dem STP 1510 über eine SS7-Verbindung 1720 verbunden. Beispielsweise kann die SS7-Verbindung 1720 eine A-Verbindung umfassen. Der STP 1510 ist mit einem anderen SSP 1730 über ein TCP/IP-Netzwerk 1740 verbunden. Das TCP/IP-Netzwerk 1740 ersetzt eine SS7-A-Verbindung zwischen dem STP 1710 und dem SSP 1730. Der STP 1510 beinhaltet ein SS7/IP-Nutzerteilnachricht-Kommunikationsglied 1520, um bidirektional Nutzerteilnachrichten zwischen SSP 1700 und SSP 1730 zu kommunizieren. In dem dargestellten Netzwerk ist der SSP 1730 vorzugsweise in der Lage zu kommunizieren, wobei der TCP/IP benutzt wird. In einer alternativen Netzwerkkonfiguration könnte der SSP 1730 nicht für den TCP/IP freigegeben sein, und ein zusätzlicher STP, welcher ein SS7/IP-Nutzerteilnachricht-Kommunikationsglied oder einen Protokollwandler beinhaltet, kann zwischen dem TCP/IP-Netzwerk 1740 und dem SSP 1730 angeschlossen sein. Eine derartige Konfiguration ist innerhalb des Umfangs der vorliegenden Erfindung.
Jeder der Knoten in der Netzwerkkonfiguration, welcher in 17 dargestellt wird, besitzt eine MTP-Ebene-3-Routing-Information, welche einen Punktcode beinhaltet. In dem dargestellten Netzwerk besitzt der SSP 1700 einen Punktcode von 100.100.101. Der SSP 1730 besitzt einen Punktcode von 200.200.201. Der STP 1510 besitzt einen Punktcode von 300.300.301. Da der STP 1510 und der 1730 über ein IP-Netzwerk angeschlossen sind, besitzen der STP 1510 und der SSP 1730 auch IP-Adressen. In der dargestellten Ausführungsform besitzt der STP 1710 eine IP-Adresse von 128.10.2.30, und der SSP 1730 besitzt eine IP-Adresse von 128.10.2.31.
18 stellt ein beispielhaftes Anrufablaufdiagramm dar, welches den Fluss von ISUP-Nachrichten zwischen dem SSP 1700 und dem SSP 1730 beim Durchführen eines Anrufaufbaus darstellt. In der Zeile 1 des Anrufablaufdiagramms sendet der SSP 1700 eine Anfangsadressnachricht (IAM), welche eine Nachricht, adressiert an SSP 1730, ist, an den STP 1510. Die IAM-Nachricht besitzt einen Ausgangspunktcode von 100.100.101 und einen Zielpunktcode von 200.200.201. Wenn der STP 1510 die IAM-Nachricht empfängt, ändert der STP 1510 den SS7-Ursprungspunktcode oder den Zielpunktcode nicht. Außerdem verkapselt der STP 1510 die IAM-Nachricht in einem TCP/IP-Paket mit einer Zielpunkt-IP-Adresse von 128.10.2.31, d. h. der IP-Adresse von SSP 1730. Das TCP/IP-Paket beinhaltet auch die Quell-IP-Adresse von 128.10.2.30, d. h. die IP-Adresse des STP 1510.
In Zeile 2 des Anrufablaufdiagramms sendet der SSP 1730 eine vollständige Adressennachricht (ACM) an den SSP 1510. Die vollständige Adressnachricht beinhaltet einen Ursprungscode von 200.200.201, d. h. den Punktcode des SSP 1730, und einen Zielpunktcode von 100.100.101, d. h. den Punktcode des SSP 1700. Die Ziel-IP-Adresse ist jedoch die des STP 1510, d. h. 128.10.2.30. Der STP 1510 empfängt die ACM-Nachricht, entfernt den TCP/IP-Nachrichtenkopf, fügt irgendwelche benötigte SS7-Information hinzu und leitet die ACM-Nachricht an den SSP 1700.
In Zeile 3 des Anrufablaufdiagramms, wenn die anrufende Partei auf den Anruf antwortet, sendet der SSP 1730 eine Antwortnachricht (ANM) an den SSP 1700. Die Antwortnachricht kann in einer Weise ähnlich zu der ACM-Nachricht gesendet werden, und deshalb muss die Übertragung nicht weiter beschrieben werden.
Sobald die Antwortnachricht von dem SSP 1700 empfangen wurde, ist ein Anruf zwischen den Endnutzern 1750 und 1760 im Werden. Der Anruf dauert an, bis eine der Parteien aufhängt. In dem dargestellten Anrufablaufdiagramm, wenn der Endnutzer 1760, welcher mit dem SSP 1730 verbunden ist, aufhängt, wird eine Freigabenachricht (REL) von dem SSP 1730 an den SSP 1700 gesendet. Die Freigabenachricht wird in einer Weise ähnlich zu der ACM-Nachricht, welche oben beschrieben wurde, adressiert und geroutet. Der SSP 1700 antwortet auf die Freigabenachricht durch Senden einer Freigabe-vollständig-Nachricht (RLC) an den SSP 1730. Die Freigabe-vollständig-Nachricht wird in einer ähnlichen Weise an die IAM-Nachricht, welche oben beschrieben ist, adressiert und geroutet.
Da der STP 1510 eine bidirektionale Kommunikation der Nutzerteilnachrichten zwischen Endämtern ausführt, sind die für das Ausführen der Operationen für den Anrufaufbau erforderlichen Ressourcen reduziert. Beispielsweise ist es nicht länger notwendig, dass dedizierte SS7-Verbindungen zwischen Endämtern vorhanden sind, um Anrufsignalisier-Operationen auszuführen. Eine oder mehrere der Verbindungen können durch ein IP-Netzwerk, wie z. B. ein TCP/IP-Netzwerk oder ein UDP/IP-Netzwerk, ersetzt werden.
Bidirektionale Kommunikationsverfahren und Computerprogramme
Ein STP für ein SS7-Netzwerk entsprechend der vorliegenden Erfindung beinhaltet eine Einrichtung für und liefert die Schritte zum bidirektionalem Übertragen von SS7-Nutzerteilnachrichten zwischen SPs des SS7-Netzwerks. Der STP beinhaltet auch eine Einrichtung für und liefert die Schritte zum bidirektionalem Übertragen von Nutzerteilnachrichten zwischen SPs des SS7-Netzwerks und IP-Knoten eines IP-Netzwerks. Der STP beinhaltet auch eine Einrichtung zum und liefert die Schritte zum bidirektionalem Übertragen von Nachrichten zwischen IP-Knoten des IP-Netzwerks. Das bidirektionale Übertragen findet vorzugsweise unter Benutzung von TCP/IP statt.
19 und 20 sind Ablaufdiagramme, und 21–24 sind Blockdiagramme, welche beispielhafte Hardware und Software für die bidirektionale Kommunikation von SS7-Nutzerteilnachrichten zwischen einem STP und wenigstens einem der anderen SPs eines SS7-Netzwerks entsprechend den Ausführungsformen der vorliegenden Erfindung darstellen. Die vorliegende Erfindung kann als Verfahren ausgeführt sein, Systeme (Geräte) und/oder als Computerprogrammprodukt. Entsprechend kann die vorliegende Erfindung die Form einer gesamten Hardware-Ausführung annehmen, einer gesamten Software-Ausführung oder einer Ausführung, welche Software- und Hardware-Gesichtspunkte kombiniert.
Es wird auch verstanden werden, dass eine oder mehrere der Blöcke in 19–24 und die Kombinationen dieser Blöcke über Computerprogramm-Instruktionen implementiert sein können. Diese Computerprogramm-Instruktionen können an einen Prozessor oder an andere programmierbare Datenverarbeitungsgeräte geliefert werden, um eine Maschine herzustellen, so dass die Instruktionen, welche auf dem Prozessor oder auf anderen programmierbaren Datenverarbeitungsgeräten ausgeführt werden, eine Einrichtung schaffen, um die Funktionen, welche in dem Ablaufdiagrammblock oder -blöcken spezifiziert sind, zu implementieren. Diese Computerprogramm-Instruktionen können auch in einem von einem Computer lesbaren Medium gespeichert werden, welches einen Prozessor oder andere Programmdaten-Verarbei-tungsgeräte leiten kann, in einer speziellen Weise zu funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Instruktionen einen Artikel der Herstellung produzieren, wobei eine Instruktionseinrichtung beinhaltet ist, welche die in dem Ablaufdiagrammblock oder den Ablaufdiagrammblöcken spezifizierten Funktionen implementiert.
Entsprechend unterstützen die Blöcke in 19–24 Kombinationen der Einrichtungen zum Ausführen der spezifizierten Funktionen, Kombinationen von Schritten zum Ausführen der spezifizierten Funktionen und eine Programminstruktionseinrichtung zum Ausführen der spezifizierten Funktionen. Es wird auch verstanden werden, dass jeder Block und die Kombinationen von Blöcken durch Hardware-basierte Computersysteme für einen speziellen Zweck implementiert werden können, welche die spezifizierten Funktionen oder Schritte ausführen, oder durch Kombinationen von Hardware und Computerinstruktionen für einen speziellen Zweck.
19 stellt beispielhafte Schritte dar, welche durch ein SS7/IP-Nutzerteilnachricht-Kommunikationsglied ausgeführt werden können, welches in einem STP beim Verarbeiten einer SS7-Nutzerteilnachricht für die Übertragung über ein IP-Netzwerk entsprechend einer Ausführungsform der vorliegenden Erfindung eingebettet ist. Im Schritt ST1 empfängt das SS6/IP-Nutzerteilnachricht-Kommunikationsglied eine SS7-Nutzerteilnachricht von einem SS7-Knoten. Die SS7-Nutzerteilnachricht beinhaltet eine SS7 MTP-Ebene und eine SS7-Nutzerteilebene, wie z. B. eine ISUP-Ebene. Ein Teil der MTP-Ebene-Information kann von der SS7-Nachricht abgestreift oder entfernt sein, wie dies im Schritt ST2 gezeigt wird. Jedoch ist entsprechend einer bevorzugten Ausführungsform der Erfindung die MTP-Ebene-3-Routing-Information vorzugsweise in der Nachricht enthalten.
Im Schritt ST3 sind die verbleibende MTP-Ebene-Information und die Nutzerteilebene in der SS7-Nachricht in einer TCP-Transportschicht platziert, um eine TCP-Nachricht zu schaffen. Die TCP-Transportschicht beinhaltet bevorzugt den TCP-Anschluss, auf welchem eine Verbindung mit dem Ziel SS7- oder IP-Knoten erstellt wurde. Es sollte an diesem Punkt beachtet werden, dass die gesamte Information, welche in der Ursprungs-SS7 MTP-Ebene enthalten war, in der TCP-Transportschicht platziert werden kann, falls dies gewünscht ist. Außerdem kann die MTP-Ebene-Information, welche schließlich in der TCP-Transportschicht beinhaltet ist, modifiziert oder gegenüber ihrer ursprünglichen Form vor der TCP-Verkapselung geändert werden. D. h., der Bitstrom, welcher die MTP-Ebene-Information in dem ursprünglichen SS7 MSU darstellt und der Bitstrom, welcher die MTP-Ebene-Information in der TCP-verkapselten Nachricht darstellt, müssen nicht identisch sein. Zusätzlich können zusätzliche Daten, wie z. B. Anwendungs-Ebene-Reihenfolge-Anzahl-Daten und Operationscode-Daten zu der Nachricht hinzugefügt werden, bevor oder nachdem die Nachricht TCP- oder IP-verkapselt ist.
Im Schritt ST4 ist eine IP-Netzwerkschicht an die TCP-Nachricht hinzugefügt, um eine TCP/IP-Nachricht zu schaffen. Die IP-Netzwerkschicht beinhaltet die Ziel-IP-Adresse des Knotens, an welchen die Ursprungs-SS7-Nachrichten adressiert wurden. Die Ziel-IP-Adresse kann bestimmt werden, indem eine Look-up bzw. Nachschlagtabelle oder andere Routing-Mechanismen, welche auf dem Zielpunktcode in der Ursprungs-SS7-Nachricht basieren, benutzt werden. In einer alternativen Ausführungsform der Erfindung können die Schritte ST3 und ST4 so kombiniert werden, dass die TCP- und IP-Information in einem einzelnen Schritt addiert wird. Schließlich wird im Schritt ST5 die TCP/IP-Nachricht an die IP-Adresse über ein IP-Netzwerk 1530 (15) unter Benutzung des TCP-Transports gesendet. Die IP-Adresse kann einen SS7-Knoten darstellen, welcher so aufgebaut ist, dass er unter Benutzung des TCP/IP oder eines TCP/IP-Knotens ohne die SS7-Fähigkeiten kommuniziert. Deshalb kann die Nutzerteilnachricht von einem STP, einem anderen SS7-Knoten oder einem IP-Knoten unter Benutzung eines TCP/IP-Netzwerkes gesendet werden.
20 stellt das Verarbeiten dar, welches durch das SS7/IP-Nutzerteilnachricht-Kommunikationsglied 1520 des STP 1510 (15) beim Verarbeiten einer IP-verkapselten SS7-Nachricht entsprechend einer Ausführungsform der vorliegenden Erfindung ausgeführt werden kann. Wie im Schritt ST1 gezeigt wird, wird eine TCP/IP-Nachricht, welche eine verkapselte SS7-Nutzerteilnachricht enthält, von einem IP-Netzwerk empfangen. Die TCP/IP-Nachricht beinhaltet SS7 MTP-Ebene-Information und Nutzerteil-Nutzlastdaten, welche in dem TCP-Transport und in den IP-Netzwerkschichten verkapselt sind. Im Schritt ST2 ist die IP-Netzwerkschicht von der IP-Nachricht entfernt, um eine TCP-Nachricht zu schaffen, welche SS7 MTP-Ebene-Information und SS7-Nutzerteil-Nutzlastdaten in einer TCP-Transportschicht beinhaltet. Im Schritt ST3 ist die TCP-Transportschicht von der TCP-Nachricht entfernt, um eine SS7-Nachricht zu schaffen, wobei SS7 MTP-Ebene-3-Information und eine SS7-Nutzerteil-Nutzlastebene beinhaltet sind. In einer alternativen Ausführungsform der Erfindung können die Schritte ST2 und ST3 so kombiniert werden, dass die TCP/IP-Information in einem Schritt entfernt ist. Zusätzliche Information, wie z. B. eine Anwendungsebene-Reihenfolgenummer und ein Operationscode können auch von der Nachricht entfernt und verarbeitet werden. Im Schritt ST4 ist die MTP-Ebenen-1-und-2-Information an die Nachricht angefügt, um, wenn erforderlich, eine funktionelle SS7-Nachricht zu bilden. Falls keine MTP-Ebene-Information von der TCP/IP-Nachricht durch den SP 1540 entfernt wurde, dann müssen keine zusätzlichen MTP-Ebene-1-und-2-Informationen angefügt werden. Schließlich wird im Schritt ST5 die SS7-Nachricht geroutet. Deshalb kann die Nachricht von dem SP 1540 an den STP 1510 gesendet werden, wobei das TCP/IP-Netzwerk 1530, eher als eine SS7-Verbindung, benutzt wird.
Obwohl die Ablaufdiagramme in 19 und 20 jeweils das Hinzufügen und das Entfernen von TCP-Transportschicht-Information von einer SS7-Nutzerteilnachricht zeigen, ist die vorliegende Erfindung nicht auf eine derartige Ausführungsform begrenzt. Beispielsweise kann in einer alternativen Ausführungsform eine SS7-Nutzerteilnachricht in einer UDP/IP-Nachricht für die Übertragung über ein UDP/IP-Netzwerk verkapselt sein. In ähnlicher Weise können UDP/IP-verkapselte SS7-Nutzerteilnachrichten über ein UDP/IP-Netzwerk empfangen werden, und der UDP/IP-Teil der Nachrichten kann entfernt werden, um die SS7-Nutzerteilnachrichten herzustellen.
Hardware zum Ausführen bidirektionaler SS7/IP-Nutzerteilnachricht-Kommunikationen
21 ist ein Blockdiagramm einer Hardware-Konfiguration für einen STP 1510, welcher ein integriertes SS7/IP-Nutzerteilnachricht-Kommunikationsglied entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt. Wie in 21 gezeigt wird, beinhaltet der STP 1510 drei zusammenarbeitende Teilsysteme: das Wartungs- und Verwaltungsteilsystem (MAS) 2102, ein Kommunikationsteilsystem, welches ein Paar von entgegengesetzt umlaufenden Interprozessor-Nachrichtentransport-(IMT-)Bussen 2104 besitzt, und schließlich ein Anwendungsteilsystem 2106. Das Anwendungsteilsystem 2106 kann eine Vielzahl von Modulen beinhalten. Beispielsweise wird wenigstens ein Anwendungsdienstmodul (ASM) 2108 benutzt, um Umsetzungstabellen und Screening- bzw. Abtastdaten für das Gateway-Screening zu speichern. Wenigstens ein Umsetzungsdienstmodul (TSM) 2110 kann beinhaltet sein, welches für globale Titelumsetzung benutzt wird. Wenigstens ein Anwendungskommunikationsmodul (ACM) 2112 liefert einen eindirektionalen Zugriff auf einen entfernten Host-Rechner für die STP-LAN-Funktionalität. Wenigstens ein Verbindungsschnittstellenmodul (LIM) 2113 liefert einen physikalischen Eingangs-/Ausgangsanschluss für zwei SS7-Verbindungen. Jedes der Elemente 2108–2113 in dem Anwendungsteilsystem 2106 kann eine oder mehrere gedruckte Schaltkarten beinhalten, wobei Verarbeitungsschaltung und Speichereinrichtungen beinhaltet sind, welche konfiguriert sind, um die beschriebenen Funktionen auszuführen.
Entsprechend einer Ausführungsform der vorliegenden Erfindung liefert wenigstens ein Datenkommunikationsmodul (DCM) 2114 die notwendige Hardware für bidirektionale Kommunikation von SS7-Nachrichten über ein IP-Netzwerk. Das DCM 2114 kann einen Mikroprozessor für allgemeine Zwecke, Netzwerkkommunikations-Hardware, Programmspeicher und Datenspeicher für das bidirektionale Kommunizieren von SS7-Nutzerteilnachrichten über ein IP-Netzwerk beinhalten. Das SS7/IP-Nutzerteilnachricht-Kommunikationsglied 1520 (in 21 nicht gezeigt) kann in dem Programmspeicher des DCM 2114 angesiedelt sein und den Prozessor veranlassen, bidirektionale SS7/IP-Nutzerteil-Kommunikationsfunktionen auszuführen, wie dies nachfolgend detaillierter beschrieben wird. Das DCM 2114 führt ein bidirektionales SS7 zu TCP/IP oder UDP/IP-Protokollstapel-Digitalhierarchieumsetzen durch, wie zuvor beschrieben. Wie in 21 gezeigt wird, ist jedes DCM 2114 über Schnittstellen mit sowohl dem IMT-Bus 2104 als auch einem zugehörigen TCP/IP-Netzwerk 2116 verbunden. Durch das Verbinden über Schnittstellen mit dem IMT-Bus 2104 können Hochgeschwindigkeitskommunikationen mit anderen Modulen in dem STP 1510 erhalten werden.
SS7/IP-Nutzerteilnachricht-Kommunikationsglied
22 ist ein detailliertes Blockdiagramm, welches die Software darstellt, welche auf dem STP 1510 ausgeführt wird, um bidirektionale SS7/IP-Nutzerteilnachricht-Kommunikationen entsprechend der vorliegenden Erfindung auszuführen. In der dargestellten Ausführungsform beinhaltet der STP 1510 ein SS7/IP-Nutzerteilnachricht-Kommunikationsglied 1520. Das SS7/IP-Nutzerteilnachricht-Kommunikationsglied 1520 beinhaltet eine Anwendungsschicht 2200 und einen SS7/IP-Wandler 2201. Die Funktionen der Anwendungsschicht 2200 und des SS7/IP-Wandlers 2201 werden nachfolgend im Detail diskutiert. Die Software, welche auf den LIMs 2113a und 2113b und DCM 2114 läuft, führt Kombinationen von SS7-Funktionen durch, wobei Diskriminier(HMDC-) Funktionen des Nachrichtenhandhabens, Verteilungs-(HMDT-)Funktionen des Nachrichtenhandhabens, Überlast-(HMGC-)Funktionen des Nachrichtenhandhabens und Routing-(HMRT-)Funktionen des Nachrichtenhandhabens beinhaltet sind. Wie oben aufgeführt, bestimmen die HMDC-Funktionen 2202a und 2202c, ob die empfangenen MSUs für den STP selbst bestimmt sind und ob sie an dem STP verarbeitet werden sollten oder ob die MSUs über den STP zu einem anderen SS7-Knoten geroutet werden sollten. Die HMRT-Funktionen 2204a und 2204c bestimmen die Signalisierverbindung, über welche die ausgehende Nachricht gesendet wird. Die HMGC-Funktion 2205 überwacht den Signalisierungspunkt, welcher die Last verarbeitet. Die Überlastungsprozeduren existieren, um zu detektieren, wenn die Verarbeitungslast zu hoch ist, und führen ein Abwerfen der Last durch, um die Verarbeitungslast zu reduzieren.
Noch weiter mit Bezug auf 22, wenn eine SS7-Nutzerteilnachricht 2203 am LIM 2113a ankommt, kann die SS7-Ebenen-1-und-2-Information entfernt werden, und die Nachricht wird in die Reihe 2200a eingereiht. Die HMDC-Funktion 2202a bestimmt, ob ein Routen erforderlich ist. Das Bestimmen, ob ein Routen erforderlich ist, kann das Untersuchen des DPC in der Nachricht beinhalten. Falls die HMDC-Funktion 2202a bestimmt, dass ein Routen erforderlich ist, routet die HMRT 2204a die Nachricht an das DCM 2114, wobei der IMT-Bus 2104 benutzt wird. Die Anwendungsschicht 2200 bestimmt die Datenkomponenten, welche zu dem SS7/IP-Wandler 2201 geführt werden. In einer Ausführungsform kann die Anwendungsschicht 2200 bestimmen, dass der gesamte MTP und die Nutzerteil-Nutzlastdaten weiter zu dem SS7/IP-Wandler 2201 zu führen sind. Es sollte gewürdigt werden, dass in alternativen Konfigurationen die Anwendungsschicht 2200 bestimmen kann, dass nur bestimmte Komponenten der MTP-Schichtdaten benötigt werden und folglich nur ein Teil der MTP-Ebene-Daten zusammen mit der Nutzerteil-Nutzlast zu dem SS7/IP-Wandler 2201 weitergeführt wird. Jedoch, wie dies nachfolgend detaillierter diskutiert wird, hält die Anwendungsschicht 2200 vorzugsweise die Routing-Information in der SS7-Nutzerteilnachricht fest. In jedem Fall platziert der SS7/IP-Wandler 2201 die MTP-Ebene-Information und die Nutzerteilebene-Nutzlast in einer TCP- oder UDP-Transportschicht und fügt eine IP-Netzwerkschicht hinzu, welche eine IP-Adresse beinhaltet. Zusätzliche Information, wie z. B. Anwendungsebene-Reihenfolgenummern und Operationscodes können auch an die Nachricht hinzugefügt werden. Die TCP/IP- oder UDP/IP-verkapselte Nachricht 2210 wird dann an den Ziel-SSP über das IP-Netzwerk geroutet.
Fährt man mit der Beschreibung der 22 fort, so wird eine eingehende TCP/IP- oder UDP/IP-verkapselte Nutzerteilnachricht 2212 von einem SP über ein IP-Netzwerk empfangen. Der SS7/IP-Wandler 2201 entfernt die IP-Netzwerkschicht und die TCP- oder UDP-Transportschicht, während irgendeine fehlende MTP-Schichtinformation hinzugefügt wird, um so eine vollständige SS7-Nachricht zu schaffen, wobei eine MTP-Ebene und eine Nutzerteilebene beinhaltet sind. Die Nachricht wird in eine Reihenfolge 2200c eingereiht und durch die HMDC-Funktion 2202c verarbeitet, um zu bestimmen, ob ein Routen erforderlich ist. Falls ein Routen erforderlich ist, leitet die HMRT-Funktion 2204c die Nachricht an die HMGC-Funktion 2205 auf dem LIM 2113b weiter. Die HMCG-Funktion 2205 speichert die Nachricht in einer Reihe 2200b. Sobald die Nachricht den Kopf der Reihe erreicht, wird die nicht verkapselte SS7-Nutzerteilnachricht 2213 an den vorgesehene SP über eine SS7-Verbindung gesendet.
23 ist ein Blockdiagramm, welches den Nachrichtenfluss über den STP 1510 darstellt, wenn dieser die Nutzerteilnachrichten, welche zu und von dem SSP 1730 über das TCP/IP-Netzwerk 1740 entsprechend einer Ausführungsform der vorliegenden Erfindung empfangen wurden, verarbeitet werden. In 23 wird eine SS7-formatierte Nutzerteilnachricht (M1) durch den STP 1510 über ein herkömmliches SS7 LIM 2113 empfangen. Zum Zwecke der Darstellung ist angenommen, dass die Nutzerteilnachricht M1 eine Anfangsadressnachricht (IAM) ist. Basierend auf Information, welche in der Routing-Kennung der Nutzerteilnachricht M1 enthalten ist, bestimmt das LIM 2113, dass die IAM-Nachricht für einen SSP 1730 bestimmt ist, mit welchem der STP 1510 über das TCP/IP-Netzwerk 1740 angeschlossen ist. Das LIM 2113 routet dann die Nachricht M1 intern über den IMT-Bus 2104 an das TCM-Modul 2114. Das TCM-Modul 2114 führt eine Übersetzung durch und wandelt die SS7-Nutzerteilnachricht M1 in ein TCP/IP-Paket 2300, wobei einige oder die gesamte MTP-Ebene-2-3-Information und die Nutzerteil-Nutzlastschicht übertragen werden, wie oben beschrieben. Das TCP/IP-Paket 2300 wird dann über das TCP/IP-Netzwerk zu dem SSP 1730 gesendet.
In einem zweiten Szenario erzeugt der SSP 1730 ein TCP/IP-Paket 2302, welches eine SS7-Nutzerteilnachricht enthält, welche zurück zu dem STP 1510 geroutet wird. In diesem Fall, zum Zwecke der Erläuterung, wird angenommen, dass die zweite Nutzerteilnachricht eine vollständige Adressnachricht (ACM) ist. In diesem Beispiel wird auch angenommen, dass der SSP 1730 die Nachricht in dem TCP/IP-Paket 2302 erzeugt und sendet, welches in seiner Struktur ähnlich zu dem TCP/IP-Paket 2300 ist, welches oben beschrieben ist. Das TCP/IP-Paket 2302 wird über das TCP/IP-Netzwerk 1740 geführt und wird eventuell durch den STP 1510 über das TCM-Modul 2114 empfangen. Das TCP/IP-Paket 2302 wird dann in ein SS7-Format durch das TCM 2114 übersetzt und intern über den IMT-Bus 2104 an das geeignete LIM-Modul 2113 und hinaus zu dem SS7-Netzwerk als eine Nutzerteilnachricht M2 geroutet.

Das OAM 2304 liefert die Funktionalität des Betreibens, Verwaltens und der Wartung. Diese Funktionalität beinhaltet den Nutzer-Ein-/Ausgang, Disk-Dienste, Datenbank-Aktualisierungen an aktiven Karten und die allgemeine Fähigkeit, die vorliegende Software auf den LIMs, ASMs, etc. zu laden. Die HSL 2306 ist eine Hochgeschwindigkeits-Signalisierverbindung, welche entsprechend der Bellcore GR-2878-Kernspezifikation implementiert ist. Diese Hochgeschwindigkeitsverbindung ist eine SS7-Verbindung, welche auf ATM über Ti arbeitet, im Gegensatz zu MTP über ein DS0-physikalische Netzwerk. Die folgende Tabelle stellt die OSI-Standardschichten dar und vergleicht die MTP-Verbindungen mit niedriger Geschwindigkeit, die MTP-Verbindungen mit hoher Geschwindigkeit, den herkömmlichen IP und dem Betrieb eines DCM entsprechend einer Ausführungsform der vorliegenden Erfindung. Vergleichen der OSI-Schichten, der MTP-Verbindungen mit niedriger und hoher Geschwindigkeit, der IP-Schichten und der DCM-Funktionalität TABELLE 1:

OSI (Standard)	MTP-Niedriggeschwi ndigkeitsverbi ndungen	MTP-Hochgeschwi ndigkeitsve rbindungen	IP (Herkömmlich)	DCM
Anwendung	ISUP	ISUP	-	ISUP
Präsentation				-
Sitzung				-
Transport		-	TCP	-
Netzwerk	MTP 3	MTP 3	IP	MTP 3
Datenverbindung	MTP-2	SAAL AAL-5	MAC	Gateway-Adaptionsschicht TOP IP MAC
physikalisch	DSO	T1	10/100 Basis-t	10/100 Basis-t

Datenstrukturen
24 stellt eine Datenstruktur für bidirektionales Kommunizieren von SS7-Nutzerteilnachrichten in Internet-Protokollpaketen entsprechend einer Ausführungsform der vorliegenden Erfindung dar. In 24 ist ein SS7 MSU, welcher im Allgemeinen mit 2400 bezeichnet ist, in dem Transportadapter-Schicht-Schnittstellen-(TALI-)Paket, welches allgemein mit 2402 bezeichnet ist, verkapselt, welches umgekehrt in dem IP-Paket 2404 verkapselt ist. Spezieller ausgedrückt, die Schicht-3-Information in dem SS7 MSU 2400, welche das Nachrichtentypfeld, das Schaltinformations-Codefeld, die Routing-Kennung und das Dienstinformations-Oktett beinhaltet, ist in dem Dienstfeld 2406 des TALI-Pakets 2402 verkapselt. Das Nutzerteilfeld ist auch in dem Dienstfeld 2406 verkapselt. Die verbleibenden Teile des SS7 MSU werden vorzugsweise ausgeschieden. Das TALI-Paket 2402, zusätzlich zu der SS7-Schicht-3-Information, beinhaltet das Längenfeld 2408, das Opcode-Feld 2410 und das Synchronisationsfeld 2412. Das Längenfeld 2408 spezifiziert die Länge der Daten in dem Dienstfeld 2406 des TALI-Pakets 2402. Das Opcode-Feld 2410 spezifiziert einen SS7-Nachrichtentyp. In diesem Beispiel würde das Opcode-Feld einen SS7-Nutzerteilnachrichtentyp spezifizieren, wie z. B. ISUP, TUP oder BISUP. Das Synchronisationsfeld 2412 zeigt den Start eines Paketes an. Das Synchronisationsfeld 2412 ist für das Bestimmen der Paketgrenzen in den TCP-Strömen nützlich, falls der Wert in dem Längenfeld 2408 nicht korrekt ist.
Das TALI-Paket 2402 ist in dem Datenfeld 2414 des IP-Paketes 2404 verkapselt. Das TCP-Nachrichtenkopffeld 2416 beinhaltet die TCP-Nachrichtenkopfinformation, z. B. die TCP-Portiernummern, für die bidirektionale Nutzerteil-Nachrichtenkommunikation. Das IP-Nachrichtenkopffeld 2418 beinhaltet die IP-Nachrichtenkopfinformation, wie z. B. die Quelle und das Ziel der IP-Adressen, für das IP-Paket 2404. Schließlich beinhaltet das MAC-Nachrichtenkopffeld 2420 physikalische und Netzwerkinformation für das Liefern des IP-Pakets 2404 über ein physikalisches Netzwerk.
25 stellt eine alternative Datenstruktur für das Verkapseln einer SS7-Nutzerteilnachricht in einem IP-Paket entsprechend einer Ausführungsform der vorliegenden Erfindung dar. Die in 25 dargestellte Datenstruktur liefert erhöhte Zuverlässigkeit, wobei das Nachrichten-in-Reihe-Bringen und – Wiedergewinnen benutzt wird. In 25 ist das SS7 MSU 2400 das gleiche wie das SS7 MSU, welches in 24 dargestellt wird. Das TALI-Paket, welches allgemein mit 2402a bezeichnet wird, ist unterschiedlich von dem TALI-Paket 2402, welches in 24 dargestellt wird. Im Einzelnen beinhaltet das TALI-Paket 2402a ein Anwendungsebene-Reihenfolge-Anzahlfeld bzw. Laufzahlfeld 2500 für das In-Reihenfolge-Bringen von IP-Paketen zwischen den SS7 MSUs. In der dargestellten Ausführungsform ist das Anwendungsebene-Laufzahlfeld 2500 als ein Trailer bzw. Dateiendetikett für das TALI-Paket 2402a beinhaltet. In einer alternativen Ausführungsform kann das Anwendungsebene-Laufzahlfeld 2500 als ein Nachrichtenkopf für das TALI-Paket 2402a beinhaltet sein oder an irgendeinem anderen Platz in dem TALI-Paket 2402a. Das Anwendungsebene- Laufzahlfeld 2500 liefert eine Laufzahl eines TALI-Pakets in einer Kommunikation zwischen den SS7 MSUs. Das Verarbeiten des Laufzahlwertes, um erhöhte Zuverlässigkeit zu liefern, wird nachfolgend detaillierter diskutiert.
Das IP-Paket 2404a beinhaltet ein Datenfeld 2414a, welches das TALI-Paket 2402a beinhaltet. Das Datenfeld 2414a beinhaltet demnach ein Anwendungsebene-Laufzahlfeld 2500. Die verbleibenden Felder in dem IP-Paket 2404a sind die gleichen wie jene, welche in 24 dargestellt sind, und müssen nicht weiter beschrieben werden.
26 stellt eine beispielhafte SS7-Nachrichten-Wiederherstellungsroutine für die zuverlässige Kommunikation von IP-verkapselten SS7-Nachrichten zwischen SS7-Knoten dar. Die SS7-Nachrichten-Wiederherstellungsroutine kann softwaremäßig über SS7-Kommunikations-Hardware in den SS7-Knoten ausgeführt werden. Beispielsweise kann die SS7-Nachrichten-Wiederherstellungsroutine durch ein DCM oder dessen Äquivalent in einem STP ausgeführt werden. Alternativ kann die SS7-Nachrichten-Wiederherstellungsroutine durch andere Knoten, wie z. B. SSPs, SCPs oder Nicht-SS7-IP-Knoten für zuverlässige IP-Kommunikationen ausgeführt werden. In 26 wird die SS7-Paket-Wiederherstellungsroutine im Allgemeinen in Form von Schritten erklärt, welche durch zwei SS7-Knoten ausgeführt werden. Die Knoten werden als Knoten A und Knoten B jeweils bezeichnet. Es wird von Fachleuten verstanden werden, dass jeder Knoten ein STP, ein SSP, ein SCP oder ein anderer Knoten sein kann.
Im Schritt ST1 erstellt der Knoten A erste und zweite TCP-Verbindungen auf den ersten und zweiten TCP-Socket mit dem Knoten B. Im Schritt ST2 sendet der Knoten A TCP/IP-verkapselte SS7-Nachrichten, welche Applikationsebene-Laufzahlen enthalten, welche die Reihenfolge der Pakete an dem ersten Socket des Knotens B anzeigen. Im Schritt ST3 bestimmt der Knoten A, ob ein Socketfehler aufgetreten ist. Falls kein Socketfehler aufgetreten ist, fährt der Knoten A fort, die TCP-Pakete zu dem Knoten B auf dem Socket Nummer 1 zu senden. Da die TCP-Kommunikationen bidirektional sind, kann der Knoten B auch TCP-Pakete zum Knoten A auf dem Socket Nummer 1 senden. Die vom Knoten B an den Knoten A übertragenen Pakete beinhalten vorzugsweise auch Anwendungsebene-Laufzahlen, welche die Ordnung bzw. Reihenfolge der Pakete anzeigen, welche vom Knoten B zum Knoten A gesendet wurden.
Im Schritt ST4, falls ein Socketfehler aufgetreten ist, z. B. an dem Socket Nummer 1, tauschen die Knoten A und B Anwendungsebene-Laufzahlen über den guten Socket für die letzten übertragenen und empfangenen Pakete aus. Beispielsweise sendet der Knoten A die Anwendungsebene-Laufzahl des letzten vom Knoten B empfangenen Paketes an den Knoten B. Der Knoten B sendet die Anwendungsebene-Laufzahl des letzten an den Knoten A gesendeten Paketes. In ähnlicher Weise sendet der Knoten B die Anwendungsebene-Laufzahl, welche das letzte Paket anzeigt, welches vom Knoten A empfangen wurde, an den Knoten A. Der Knoten B sendet die Anwendungsebene-Laufzahl, welche das letzte Paket anzeigt, welches an den Knoten A gesendet wurde. Im Schritt ST5 nehmen der Knoten A und der Knoten B die Datenkommunikationen auf dem guten Socket wieder auf, d. h. dem Socket 2 basierend auf den Anwendungsebene-Laufzahlen. Beispielsweise kann der Knoten B verlorene Pakete an den Knoten A senden, und der Knoten A kann die verlorenen Pakete an den Knoten B auf dem zweiten Socket senden. Auf diese Weise werden zuverlässige Kommunikationen zwischen den SS7-Knoten sogar dann erstellt, wenn ein Socket fehlerhaft ist. Das herkömmliche TCP-Laufzahl-Aufstellen geht nicht auf diesen Sachverhalt ein, da der TCP keinen Mechanismus für das Wiederherstellen des Paketes liefert, wenn ein Socket fehlerhaft ist. Das Anwendungsebene-Laufzahl-Aufstellen der vorliegenden Erfindung gestattet, dass Kommunikationen an dem Punkt wiederaufgenommen werden, wo Kommunikationen verloren wurden, anstatt dass eine Rücksendung einer gesamten Folge von Paketen erforderlich ist.
Obwohl die Erfindung bisher im Detail mit Bezug auf das Ersetzen von SS7-Verbindungen zwischen einem STP und anderen SS7-Typ-SP-Netzwerkelementen mit TCP/IP-Verbindungen beschrieben wurde, kann die vorliegende Erfindung auch angewendet werden, um die Kommunikation zwischen SS7-Netzwerkelementen und IP-basierten Netzwerkelementen über TCP/IP-Verbindungen zu erleichtern. Außerdem beziehen sich die Diskussion und die Beispiele, welche oben geliefert werden, speziell auf das Anwenden der vorliegenden Erfindung auf SS7-Nutzerteilnachrichten. Jedoch wird von Fachleuten geschätzt werden, dass jeglicher SS7-Nachrichtentyp, welcher eine MTP-Routing-Kennungsinformation erfordert, um effektiv seine richtige Funktion durchzuführen oder ihr zu dienen, bidirektional zwischen SS7 und IP-Netzwerken kommuniziert werden kann, wobei der STP der vorliegenden Erfindung benutzt wird.
Es wird verstanden werden, dass verschiedene Details der Erfindung verändert werden können, ohne vom Umfang der Erfindung abzuweichen. Außerdem dient die vorausgegangene Beschreibung nur dem Zwecke der Erläuterung und nicht dem Zweck der Eingrenzung, wobei die Erfindung durch die Ansprüche definiert ist.

Claims

Verfahren zum zuverlässigen Wiederherstellen von Signalisiersystem-sieben-(SS7-)Nutzerteil-Nachrichtenpaketen in Antwort auf einen Socket-Fehler, wobei das Verfahren aufweist: (a) Senden von IP-verkapselten SS7-Nachrichten von einem ersten Knoten zu einem zweiten Knoten über den ersten Socket, wobei jede der Nachrichten eine Anwendungsebenen-Laufzahl für die Sequenzialisierung von Nachrichten enthält, welche von dem ersten und zweiten Knoten empfangen werden; und (b) in Antwort auf den Fehler des ersten Socket, Senden eines ersten Wiederherstellungspakets von dem ersten Knoten zu dem zweiten Knoten über den zweiten Socket, wobei das erste Wiederherstellungspaket eine Anwendungsebenen-Laufzahl beinhaltet, welche die letzte durch den ersten Knoten empfangene Nachricht anzeigt.
Verfahren nach Anspruch 1, wobei das Senden der Nachrichten über den ersten und den zweiten Socket das Senden der Nachrichten über erste und zweite Übertragungssteuerprotokoll-(TCP-)Sockets beinhaltet.
Verfahren nach Anspruch 1, in welchem das Senden der Nachrichten über die ersten und zweiten Sockets das Senden von Nachrichten über erste und zweite Nutzer-Datagramm-Protokoll-(UDP-)Sockets beinhaltet.
Verfahren nach Anspruch 1, welches nach dem Empfangen des ersten Wiederherstellungspaketes an dem zweiten Knoten das Wiederaufnehmen der Datenkommunikation mit dem ersten Knoten über den zweiten Socket basierend auf der Anwendungsebenen-Laufzahl aufweist.
Verfahren nach Anspruch 1, in welchem der erste und der zweite Knoten SS7-Knoten aufweisen.
Verfahren nach Anspruch 1, in welchem der erste und der zweite Knoten IP-Knoten aufweisen.
Verfahren nach Anspruch 1, in welchem der erste Knoten ein SS7-Knoten und der zweite Knoten ein IP-Knoten ist.
Signalisiersystem-sieben-(SS7-)Nachrichtenwiederherstellungs-Computerprodukt, welches von einem Computer ausführbare Instruktionen beinhaltet, welche in einem vom Computer lesbaren Medium zum Durchführen der Schritte eingebettet sind, um die Schritte durchzuführen, welche aufweisen: (a) Senden von Internet-Protokoll-(IP-)verkapselten SS7-Nachrichten von einem ersten Knoten zu einem zweiten Knoten über den ersten Socket, wobei die Nachrichten jeweils eine Anwendungsebenen-Laufzahl zum Sequenzieren von Nachrichten beinhalten, welche durch den ersten und den zweiten Knoten empfangen werden; und (b) in Antwort auf einen Fehler des ersten Sockets Senden eines ersten Wiederherstellungspakets von dem ersten Knoten zu dem zweiten Knoten über den zweiten Socket, wobei das erste Wiederherstellungspaket eine Anwendungsebenen-Laufzahl beinhaltet, welche die letzte von dem ersten Knoten empfangene Nachricht anzeigt.
SS7-Nachrichtenwiederherstellungs-Computerprodukt nach Anspruch 8, in welchem das Senden der Datenpakete über erste und zweite Sockets das Senden der Datenpakete über erste und zweite Sendesteuerprotokoll-(TCP-)Sockets beinhaltet.
SS7-Nachrichtenwiederherstellungs-Computerprodukt nach Anspruch 8, in welchem das Senden von Nachrichten über erste und zweite Sockets das Senden der Nachrichten über erste und zweite Benutzer-Datagramm-Protokoll-(UDP)Sockets beinhaltet.
SS7-Nachrichtenwiederherstellungs-Computerprodukt nach Anspruch 8, welches nach dem Empfangen des ersten Wiederherstellungspaketes an dem zweiten Knoten das Wiederaufnehmen der Datenkommunikation mit dem ersten Knoten über den zweiten Socket basierend auf der Anwendungsebenen-Laufzahl aufweist.
SS7-Nachrichtenwiederherstellungs-Computerprodukt nach Anspruch 8, in welchem das Senden von Nachrichten von einem ersten Knoten zu einem zweiten Knoten das Senden der Nachrichten von einem ersten SS7-Knoten zu einem zweiten SS7-Knoten aufweist.
SS7-Nachrichtenwiederherstellungs-Computerprodukt nach Anspruch 8, in welchem das Senden der Nachrichten von einem ersten Knoten zu einem zweiten Knoten das Senden der Nachrichten von einem ersten SS7-Knoten zu einem ersten IP-Knoten aufweist.
SS7-Nachrichtenwiederherstellungs-Computerprodukt nach Anspruch 8, in welchem das Senden der Nachrichten von einem ersten Knoten zu einem zweiten Knoten das Senden der Nachrichten von einem ersten IP-Knoten zu einem zweiten IP-Knoten aufweist.