-
Technisches
Gebiet
-
Die
vorliegende Erfindung bezieht sich auf intelligente Netzwerk-/weiterentwickelte
intelligente Netzwerk-(IN/AIN-)Dienste und insbesondere auf ein
Verfahren zur Ermöglichung
einer IN/AIN-Funktionalität
für Telefonie-Dienste,
die in einem Breitband-Paketnetzwerk eingesetzt werden.
-
Hintergrund
der Erfindung
-
Moderne
Telefonie-Dienste, die in dem öffentlichen
Femsprechwählnetz
(PSTN) eingesetzt werden, beruhen üblicherweise auf einer verteilten
Transaktions-orientierten
Telefonie-Funktionalität,
wie z. B. der intelligenten Netzwerk- und/oder weiterentwickelten
intelligenten Netzwerk-(IN-/AIN-)Funktionalität, um höher entwickelte Anrufsteuerdienste
für Teilnehmer
bereitzustellen. Typischerweise beinhaltet diese verteilte Funktionalität verschiedene
Netzwerk-Elemente (beispielsweise Dienstesteuerungsstellen (SCP's), intelligente
Peripheriegeräte
(IPe'sO) und interaktive
Sprachausgabe-(IVR-)Server) und Transaktions-basierte Protokolle, wie
z. B. den intelligente Netzwerk-Anwendungsteil (INAP) und den Transaktionsfähigkeiten-Anwendungsteil (TCAP)),
die in dem zentralen Signalisierungs-(CCS-)Netzwerk eingesetzt werden.
INAP und TCAP arbeiten über
eine übliche
Signalisierung-System 7-(SS7-)Infrastruktur und ergänzen die
diensteintegrierte digitale Netzwerk-Benutzerteil-(ISUP-)Signalisierung
durch Bereitstellen eines Abfrage-/Antwortprotokolls für den Zugriff
auf Routing-Information und Telefonie-Dienste, die von IN-/AIN-fähigen Netzwerk-Elementen
innerhalb des CCS-Netzwerkes bereitgestellt werden.
-
Ein
Mangel des derzeitigen PSTN-/TCS-Netzwerkes besteht darin, dass
ihre monolithische Architektur und ihre langsame (64 kbs) Signalisierungsgeschwindigkeit
die Netzwerk-Skalierbarkeit verringert. Wenn der Umfang des Telefonie-Verkehrs
zunimmt, haben Netzwerk-Diensteanbieter zunehmende Schwierigkeiten, ausreichende
CCS-Netzwerkressourcen bereitzustellen, um die zugehörige ISUP- und INAP-/TCAP-Signalisierung
abzuwickeln. In dieser Hinsicht besteht eine besondere Schwierigkeit
in der Notwendigkeit, jedes Netzwerkelement (beispielsweise eine
SCP) mit ausreichenden SS7-Signalisierungsports zu versehen. Typischerweise
ist die Anzahl der SS7-Signalisierungsports sowohl durch die Hardware
als auch die Software der gerätemäßigen Ausgestaltung
des Netzwerk-Elementes
beschränkt.
Im Fall von herkömmlichen
CCS-Netzwerk-Elementen neigt die monolithische Konstruktion sowohl
der Hardware als auch der Software dazu, die Hinzufügung von
neuen SS7-Signalisierungsports schwierig und daher aufwändig zu
machen. Wenn jedoch nicht genügend
SS7-Signalisierungsports bereitgestellt werden, so kann dies zu
einer Port-Erschöpfung
und zu einer daraus folgenden Verringerung der Dienste führen, weil
das betroffene Netzwerkelement nicht in der Lage ist, irgendwelche
neuen ISUP oder TCAP-Mitteilungen anzunehmen, bevor nicht ein Port
verfügbar
wird.
-
Eine
weitere Beschränkung
des herkömmlichen
CCS-Netzwerkes besteht darin, dass seine monolithische Konstruktion
und die hohen Kosten von CCS-Netzwerk-Elementen erhebliche Hindernisse für den Eintritt von
Netzwerk-Diensteanbietern schaffen, denen eine CCS-Netzwerk-Infrastruktur
fehlt.
-
Um
Fragen der Skalierbarkeit innerhalb des PSTN zu behandeln, wurden
verschiedene Anstrengungen gemacht, Telefonie-Dienste in einem Breitband-Paketnetzwerk zu
installieren, wie z. B. einem Internetprotokoll-(IP-)Netzwerk. Es
wurden verschiedene Protokolle vorgeschlagen, um diese Funktionalität zu ermöglichen,
unter Einschluss verschiedener Sprache-Über-IP-(VoIP-)Protokolle zur Übertragung
von Trägerverkehr sowie
Sitzungsaufbau- und Routing-Protokolle (wie z. B. der Etikett vermittelte
Mehrprotokoll-Pfad (MPLS) und das Sitzungseinleitungs-Protokoll (SIP))
zur Herstellung von Kommunikationssitzungen und zum Routen oder Lenken
des Trägerverkehrs
durch das Netzwerk. Im allgemeinen ist es auch möglich, Ressourcen in einem Breitband-Paketnetzwerk
einzusetzen, die Dienste ähnlich
zu denen ermöglichen,
die von dem herkömmlichen CCS-Netzwerk
bereitgestellt werden. Um Telefonverbindungen zwischen Punkten in
dem PSTN und einem Paketnetzwerk herzustellen, ist eine Wechselwirkung
zwischen Ressourcen der Breitband-Paket- und CCS-Netzwerke von wesentlicher
Bedeutung. Ein Verfahren, mit dem dies erreichbar ist, wurde von
V. Gurbani in einem Internet Engineering Task Force-(IETF-)Entwurf
mit dem Titel „Accessing
IN services from SIP networks" vorgeschlagen. 1 ist
ein Blockschaltbild, das das System von Gurbani zur Ermöglichung
einer IN/AIN-Funktionalität
für Telefonie-Dienste
zeigt, die in einem SIP-Netzwerk 2 eingesetzt werden. Wie
dies in 1 gezeigt ist, lehrt Gurbani
eine IN-Zustandsmaschine 4, die der üblichen SIP-Zustandsmaschine 6 innerhalb
eines SIP-Servers 8 des SIP-Netzwerkes 2 überlagert
ist. Die IN-Zustandsmaschine 4 arbeitet zur Erzeugung üblicher
TCAP-Mitteilungen, die den Zustand der SIP-Zustandsmaschine 6 wiedergeben,
und leitet diese Mitteilungen über
das herkömmliche
CCS-Netzwerk 10 an ein IN/AIN-fähiges Gerät 12 (beispielsweise
eine SCP und/oder ein IPe) weiter. TCAP-Mitteilungen (beispielsweise
Antwort-Mitteilungen)
werden über
das CCS-Netzwerk 10 von der IN-Zustandsmaschine 4 empfangen
und an die SIP-Zustandsmaschine 6 weitergeleitet, um den
Anrufaufbau über
das SIP-Netzwerk 2 zu steuern.
-
Somit
arbeitet bei dem System von Gurbani die IN-Zustandsmaschine 4 als
eine Schnittstelle zwischen dem SIP-Netzwerk 2 und dem üblichen
CCS-Netzwerk 10, was es ermöglicht, dass ein SIP-Server 8 eine
Dienstevermittlungsstelle (SSP) des PSTN für die Zwecke eines Zugriffs
auf IN/AIN-Funktionalität
emuliert. Dieses System leidet jedoch an der Beschränkung, dass
es die Menge an TCAP-Verkehr in dem CCS-Netzwerk 10 vergrößert und
damit die Gefahr einer Signalisierungsport-Erschöpfung in dem CCS-Netzwerk-Element 12 vergrößert. Die
Gefahr vergrößert sich,
wenn der Umfang des Telefonie-Verkehrs in dem SIP-Netzwerk 2 ansteigt.
-
Entsprechend
ist ein Verfahren und eine Vorrichtung, das bzw. die den Zugriff
auf eine verteilte transaktionsorientierte Telefonie-Funktionalität für Telefonie-Dienste,
die in einem Breitband-Paketnetzwerk eingesetzt werden, bei gleichzeitiger
Milderung der Gefahr einer Signalisierungsport-Erschöpfung in
CCS-Netzwerk-Elementen ermöglicht, äußerst wünschenswert.
-
Zusammenfassung
der Erfindung
-
Ein
Hauptziel der vorliegenden Erfindung besteht in der Überwindung
zumindest einiger der Beschränkungen
des vorstehend genannten Standes der Technik.
-
Dieses
Ziel wird durch die Elemente erreicht, die in den beigefügten unabhängigen Ansprüchen definiert
sind. Wahlweise Merkmale und alternative Ausführungsformen sind in den Unteransprüchen definiert.
-
Somit
ergibt ein Gesichtspunkt der vorliegenden Erfindung ein Verfahren
zur Ermöglichung
einer verteilten transaktionsorientierten Telefonie-Funktionalität für Telefonie-Dienste
in einem Breitband-Paketnetzwerk. Ein Funktionsinhalt einer Transaktionsmitteilung
wird in eine Protokolldateneinheit (PDU) des Breitband-Paketnetzwerkes eingekapselt.
Die PDU wird über
das Breitband-Paketnetzwerk zu einem zweiten Netzwerk-Element weitergeleitet.
Die Funktionalität
wird dann unter Verwendung des eingekapselten Transaktions-Funktionsgehaltes
aufgerufen.
-
Ein
weiterer Gesichtspunkt der vorliegenden Erfindung ergibt ein System,
das zur Ermöglichung
einer verteilten transaktionsorientierten Telefonie-Funktionalität für Telefonie-Dienste
in einem Breitband-Paketnetzwerk ausgebildet ist. Das System umfasst:
ein erstes Netzwerk-Element, das zur Einkapselung von zumindest einem
Funktionsinhalt einer Transaktionsmitteilung in eine Protokolldateneinheit
(PDU) des Breitband-Paketnetzwerkes ausgebildet ist, und ein zweites
Netzwerk-Element, das zum Aufruf der Funktionalität unter
Verwendung des eingekapselten Transaktions-Funktionsinhaltes ausgebildet ist.
-
Ein
weiterer Gesichtspunkt der vorliegenden Erfindung ergibt einen Netzwerk-Knoten,
der zur Ermöglichung
einer verteilten Transaktions-orientierten Telefonie-Funktionalität für Telefonie-Dienste
in einem Breitband-Paketnetzwerk ausgebildet ist. Der Knoten umfasst:
Einrichtungen zum Einkapseln zumindest eines Funktionsinhaltes einer
Transaktionsmitteilung in eine Protokolldateneinheit (PDU) des Breitband-Paketnetzwerkes;
und Einrichtungen zur Weiterleitung der PDU über das Breitband-Paketnetzwerk
zu einem Netzwerk-Element, das zur Bereitstellung der Funktionalität ausgebildet
ist.
-
Das
Breitband-Paketnetzwerk umfasst irgendeines oder mehrere von: einem
asynchronen Übertragungsbetriebsart-(ATM-)Netzwerk;
einem Internetprotokoll-(IP-)Netzwerk,
einem Frame Relay-(FR-)Netzwerk; und einem Dienste integrierenden
digitalen Netzwerk (ISDN). In bevorzugten Ausführungsformen der Erfindung
umfasst das Breitband-Paketnetzwerk ein IP-Netzwerk, und die PDU
umfasst einen Sitzungseinleitungsprotokoll-(SIP-)Mitteilungsumschlag.
In einem derartigen Fall kann der Funktionsinhalt einer IN/AIN-Mitteilung in
einen Mehrzweck-Internet-Post-Erweiterungs-(MIME-)Teil
des SIP-Umschlages eingesetzt werden.
-
Jedes
Netzwerk-Element kann eine Medien-Überleiteinrichtungs-Steuerung,
die zur Ermöglichung
eines Telefonie-Signal-Verkehrs über
das Breitband-Paketnetzwerk ausgebildet ist, oder einen Anwendungsserver
umfassen, der zum Aufruf einer IN/AIN-Funktionalität unter
Verwendung des IN/AIN-Funktionsinhaltes ausgebildet ist. Der Anwendungsserver
kann entweder ein CCS-Netzwerk-Element, das zum Senden und Empfangen
von PDU's des Breitband-Paketnetzwerkes
ausgebildet ist, oder ein Netzwerk-Element des Breitband-Paketnetzwerkes
sein.
-
Die
Einkapselung des Funktionsinhaltes der der Transaktionsmitteilung
kann die folgenden Schritte umfassen: Formulieren einer üblichen
Transaktionsmitteilung; und Einfügen
der formulierten Transaktionsmitteilung in einen Nutzinformations-Teil
der PDU.
-
Alternativ
kann die Einkapselung des Funktionsinhaltes der Transaktionsmitteilung
die Umsetzung einer Transaktionsmitteilung auf die PDU umfassen.
Bei manchen Ausführungsformen
ist die Transaktionsmitteilung eine Transaktionsfähigkeiten-Anwendungsteil-(TCAP-)Mitteilung.
In einem derartigen Fall wird ein TCAP-Mitteilungstyp auf einen jeweiligen
Mitteilungstyp der PDU umgesetzt. Der TCAP-Mitteilungstyp kann einen von folgenden
Typen umfassen: Abfrage; Antwort; Konversation; einseitig gerichtet
und Abbruch. In anderen Ausführungsformen
ist die Transaktionsmitteilung eine intelligente Netzwerk-Anwendungsteil-(INAP-)Mitteilung.
-
In
einem derartigen Fall wird ein INAP-Mitteilungstyp auf einen jeweiligen
Mitteilungstyp der PDU umgesetzt. Der INAP-Mitteilungstyp kann irgendeinen
der folgenden Typen umfassen: Beginne; Ende; Fortsetzen; einseitig
gerichtet und Abbrechen.
-
Ein
Transaktionsmitteilungs-Parameter kann ebenfalls auf einen jeweiligen
PDU-Mitteilungsparameter umgesetzt
werden. Der Mitteilungsparameter kann einen oder mehreren von Folgendem
umfassen: eine Ursprungsadresse und eine Zieladresse, und er kann
auf ein jeweiliges Zusatzinformations-Feld der PDU umgesetzt werden.
Schließlich
kann eine codierte Transaktionsmitteilungs-Nutzinformation in eine
Nutzinformation der PDU umgesetzt werden. Die codierte Mitteilungs-Nutzinformation
kann in einen Nutzinformations-Teil eines MIME-Teils der PDU umgesetzt
werden.
-
In
Ausführungsbeispielen
der Erfindung umfasst die Transaktionsmitteilung zwei oder mehrere
codierte Nutzinformations-Teile. Jeder codierte Nutzinformations-Teil
kann auf eine jeweilige einzelne MIME-Nutzinformation umgesetzt
werden. Alternativ können
die codierten Nutzinformations-Teile auf eine gemeinsame MIME-Nutzinformation umgesetzt
werden.
-
Somit
ergibt die vorliegende Erfindung ein Verfahren und ein System, das
eine verteilte Transaktions-orientierte Telefonie-Funktionalität für Telefonie-Dienste
in einem Breitband-Paketnetzwerk ermöglicht. Beispiele von verteilten
Transaktions-orientierten
Telefonie-Funktionalitäten
schließen
eine Funktionalität
eines intelligenten Netzwerkes (IN) und eines weiterentwickelten
intelligenten Netzwerkes (AIN) ein, auf die ein Zugriff über das
herkömmliche
Netzwerk mit zentraler Kanal-Signalisierung unter Verwendung von
Transaktions-basierten Mitteilungsprotokollen erfolgt, wie z. B.
die intelligenten Netzwerk-Anwendungsteil-(INAP-) und/oder Transaktionsfähigkeiten-Anwendungsteil-(TCAP-)Protokolle.
Ein Funktionsinhalt einer Transaktionsmitteilung, wie z. B. einer
TCAP-Mitteilung, wird in eine Protokolldateneinheit (PDU) des Breitband-Paketnetzwerkes
eingekapselt. Die PDU wird über
das Breitband-Paketnetzwerk
zu einem zweiten Netzwerk-Element weitergeleitet. Die Funktionalität wird dann
unter Verwendung des Funktionsinhaltes der eingekapselten Transaktionsmitteilung
aufgerufen. Bei bevorzugten Ausführungsformen
ist die PDU ein Sitzungseinleitungsprotokoll-(SIP-)Umschlag, in
den der Funktionsinhalt der TCAP-Mitteilung umgesetzt werden kann.
-
Ein
Vorteil der vorliegenden Erfindung besteht darin, dass sie ein Verfahren
und eine Vorrichtung ergibt, das bzw. die einen Zugriff auf eine
verteilte Transaktions-orientierte
Telefonie-Funktionalität
für Telefonie-Dienste
ermöglicht,
die in einem Breitband-Paketnetzwerk eingesetzt sind, während eine
Signalisierungsport-Erschöpfung in
CCS-Netzwerk-Elementen vermieden wird.
-
Ein
weiterer Vorteil der vorliegenden Erfindung besteht darin, dass
der übliche
Funktionsinhalt einer TCAP-Mitteilung über das Breitband-Paketnetzwerk
zu einem Anwendungsserver transportiert werden kann, um die IN/AIN-Funktionalität aufzurufen,
ohne dass eine herkömmliche
CCS-Netzwerk-Infrastruktur verwendet wird. Entsprechend kann die
IN/AIN-Funktionalität
bezüglich
von Telefonie-Diensten aufgerufen/werden, die in dem Breitband-Paketnetzwerk
eingesetzt sind, ohne dass zur Signalisierungsport-Erschöpfung in
dem CCS-Netzwerk beigetragen wird.
-
Kurze Beschreibung
der Zeichnungen
-
Weitere
Merkmale und Vorteile der vorliegenden Erfindung werden aus der
folgenden ausführlichen Beschreibung
in Kombination mit den beigefügten
Zeichnungen ersichtlich, in denen:
-
1 ein
Blockschaltbild ist, das schematisch Operationen eines bekannten
Systems für
den Zugriff auf die IN/AIN-Funktionalität für Telefonie-Dienste in einem
Breitband-Paketnetzwerk erläutert;
-
3 ein Blockschaltbild, das schematisch
Operationen eines Systems für
den Zugriff auf eine IN/AIN-Funktionalität für Telefonie-Dienste in einem
Breitband-Paketnetzwerk
gemäß einer
Ausführungsform der
vorliegenden Erfindung erläutert;
-
3a ein
Mitteilungs-Ablaufdiagramm ist, das Prinzip-Mitteilungen zeigt,
die in einer TCAP-Abfrage/Antwort-Transaktion gemäß dem Stand
der Technik ausgetauscht werden
-
3b ein
Mitteilungs-Ablaufdiagramm ist, das Prinzip-Mitteilungen zeigt,
die in der Abfrage/Antwort-Transaktion nach 3a unter
Verwendung von in SIP eingekapselten TCAP gemäß einer Ausführungsform
der vorliegenden Erfindung ausgetauscht werden;
-
4a ein
Mitteilungs-Ablaufdiagramm ist, das Prinzip-Mitteilungen zeigt,
die in einer AIN-Sende-an-Ressource-Transaktion gemäß dem Stand
der Technik ausgetauscht werden;
-
4b ein
Mitteilungs-Ablaufdiagramm ist, das Prinzip-Mitteilungen zeigt,
die in der AIN-Sende-an-Ressource-Transaktion nach 4a unter
Verwendung von in SIP eingekapselten TCAP gemäß einer Ausführungsform
der vorliegenden Erfindung ausgetauscht werden;
-
5a ein
Mitteilungs-Ablaufdiagramm ist, das Prinzip-Mitteilungen zeigt,
die in einer TCAP-Rufwiederholungs-(RAG-)Transaktion gemäß dem Stand
der Technik ausgetauscht werden;
-
5b ein
Mitteilungs-Ablaufdiagramm ist, das Prinzip-Mitteilungen zeigt,
die in der RAG-Transaktion nach 5a unter
Verwendung von in SIP eingekapselten TCAP gemäß einer Ausführungsform
der vorliegenden Erfindung ausgetauscht werden; und
-
6 ein
Blockschaltbild ist, das schematisch ein Beispiel eines Modells
für einen
SIP-Umschlag zeigt, der den TCAP-Funktionsinhalt gemäß einer
Ausführungsform
der vorliegenden Erfindung erläutert.
-
Es
ist festzustellen, dass in den beigefügten Zeichnungen gleiche Merkmale
durch gleiche Bezugsziffern identifiziert sind.
-
Ausführliche
Beschreibung des bevorzugten Ausführungbeispiels
-
Die
vorliegende Erfindung ergibt ein Verfahren und eine Vorrichtung
zur Ermöglichung
einer intelligenten Netzwerk-/weiterentwickelten intelligenten Netzwerk-(IN/AIN-)Funktionalität für Telefonie-Dienste,
die in einem Breitband-Paketnetzwerk
eingesetzt sind. 2 ist ein Blockschaltbild, das
Beispiele von Elementen eines Netzwerkes 14 erläutert, bei
dem die vorliegende Erfindung eingesetzt werden kann.
-
Wie
dies in 2 gezeigt ist, können Telefonie-Dienste
in einem Breitband-Paketnetzwerk 14 in
einer allgemein üblichen
Weise eingesetzt werden. Das Breitband-Paketnetzwerk 14 kann
durch ein oder mehrere verbundene Paketnetzwerke (beispielsweise
Internet-Protokoll-(IP-), asynchrone Übertragungsbetriebsart(ATM-),
Frame Relay-(FR-) und Dienste integrierende digitale Netzwerke (ISDN))
mit einer passenden Formatanpassung an Netzwerkgrenzen gebildet
werden. Kommunikationssitzungen können über das Breitband-Paketnetzwerk 14,
beispielsweise zwischen den Medien-Überleiteinrichtungs-Steuerungen
(MGC's) 16a, 16b unter
Verwendung irgendeines bekannten Sitzungsprotokolls aufgebaut werden,
wie z. B. des Sitzungseinleitungsprotokolls (SIP), das herkömmliche
Dienste-integrierte
digitale Netzwerk-Benutzerteil-(ISUP-)Mitteilungen einkapseln kann,
um den Aufbau von Verbindungen über
das öffentliche
Femsprechwählnetz
(PSTN) (nicht gezeigt) aufzubauen. Die IN/AIN-Funktionalität wird durch
einen Anwendungsserver (AS) 18 bereitgestellt, der als
eines oder mehrere herkömmliche
Elemente des CCS-Netzwerkes bereitgestellt werden kann, wie z. B.
Dienstesteuerungsstellen (SCP's),
intelligente Peripheriegeräte
(IPe's) und interaktive Sprachausgabe-(IVR-)Server,
die in geeigneter Weise angepasst sind, um eine Signalisierung über das
Breitband-Paketnetzwerk zu ermöglichen.
Alternativ können
der AS 18 als ein Server bereitgestellt werden, der in dem
Breitband-Paketnetzwerk 14 eingesetzt ist. Bei der in 2 dargestellten
Ausführungsform
ist ein einziger AS 18 zum Aufruf der IN/AIN-Funktionalität vorgesehen.
Es ist verständlich,
dass die IN/AIN-Funktionalität normalerweise
von zwei oder mehr Geräten
bereitgestellt wird, die allein oder in Kombination arbeiten. Zur
Vereinfachung der Beschreibung der vorliegenden Erfindung wird eine
vereinfachte Netzwerk-Topologie dargestellt, bei der die IN/AIN-Funktionalität durch
eine Wechselwirkung zwischen einer einzigen MGC 16a des Breitband-Paketnetzwerkes
und einem einzigen AS 18 ermöglicht wird. Es ist jedoch
zu erkennen, dass die vorliegende Erfindung nicht auf diese vereinfachte
Ausführungsform
beschränkt
ist.
-
Die
vorliegende Erfindung arbeitet zur Ermöglichung von intelligenten
Netzwerk-Anwendungsteil-(INAP-)
und/oder Transaktionsfähigkeiten-Anwendungsteil-(TCAP-)Abfrage/Antwort-Transaktionen
zwischen MGC's 16 und
Anwendungsserver 18, wobei die CCS-Netzwerk-Infrastruktur
für den
Mitteilungstransport umgangen wird.
-
Diese
Operation ermöglicht
die IN/AIN-Funktionalität
für Telefonie-Dienste,
die in dem Breitband-Paketnetzwerk 14 eingesetzt sind,
ohne dass die Gefahr eine Port-Erschöpfung in
CCS-Netzwerk-Elementen vergrößert wird.
Somit wird gemäß der Erfindung
zumindest der Funktionsinhalt jeder INAP- und/oder TCAP-Mitteilung
in eine PDU des Breitband-Paketnetzwerkes eingekapselt, das dann
zum Mitteilungstransport verwendet wird. Bei Ausführungsbeispielen,
bei denen der AS 18 durch herkömmliche CCS-Netzwerk-Elemente
(beispielsweise SCP's
und IPe's) bereitgestellt
wird, kann eine logische Verbindung zwischen dem Breitband-Paketnetzwerk 14 und
dem AS 18 zur Erleichterung des Transports von TCAP einkapselnden PDU's unter Verwendung
von vorhandenen IP-, FR- oder ISDN-Ports des AS 18 hergestellt
werden, die üblicherweise
für den
Netzwerk-Verwaltungsverkehr
verwendet werden. Alternativ kann der AS 18 mit neuen IP-Ports
zusätzlich
zu und/oder anstelle von vorhandenen SS7-Ports bereitgestellt werden.
Aufgrund der Flexibilität
und Skalierbarkeit, die sich durch das IP ergibt, ist es typischerweise
einfacher und weniger aufwändig, IP-Ports
zu einer vorhandenen SCP, einem IVR oder einem IPe hinzuzufügen, als
dies bei der Hinzufügung äquivalenter
SS7-Ports der Fall ist.
-
Die
Einkapselung des Funktionsinhaltes von INAP und/oder TCAP in PDU's des Breitband-Paketnetzwerk 14 wird
nunmehr ausführlich
in Form eines Ausführungsbeispiels
beschrieben, bei dem das Breitband-Paketnetzwerk 14 ein
IP-Netzwerk (wie
das öffentliche
Internet) ist, und der Funktionsinhalt von TCAP in einen SIP-Umschlag
eingekapselt wird. Es ist verständlich,
dass ein sehr eng verwandtes Verfahren der Einkapselung verwendet
werden kann, um den Funktionsinhalt der INAP-Mitteilungen in PDU's des Breitband-Paketnetzwerkes 14 einzukapseln.
Entsprechend konzentriert sich die folgende Beschreibung auf die
Einkapselung des Funktionsinhaltes von TCAP, wobei es verstanden
werden soll, dass die Erfindung nicht auf TCAP beschränkt sein
soll, sondern vielmehr auch die Einkapselung des INAP-Funktionsinhaltes
einschließt.
-
Die
Einkapselung des TCAP-Funktionsinhaltes in einen SIP-Umschlag kann
dadurch erreicht werden, dass entweder eine übliche TCAP-Mitteilung in einen
Nutzinformations-Teil des SIP-Umschlages eingefügt wird, oder dass die TCAP- Mitteilungen auf
entsprechende SIP-Mitteilungen umgesetzt werden. Ein Beispiel einer
Umsetzung zwischen TCAP- und SIP-Mitteilungen wird nachfolgend beschrieben.
-
Im
Allgemeinen beinhaltet die Umsetzung zwischen TCAP- und SIP-Mitteilungen
drei Umsetzungen, nämlich:
Umsetzung von TCAP-Mitteilungs-Typen auf SIP-Mitteilungs-Typen; Umsetzung
von TCAP-Parametern auf SIP-Parameter; und Umsetzung des TCAP-Mitteilungsinhaltes
auf die SIP-Umschlag-Nutzinformation. Jede dieser Umsetzungen wird
aufeinanderfolgend in der folgenden Beschreibung behandelt.
-
Umsetzung
von TCAP-Mitteilungs-Typen auf SIP-Mitteilungs-Typen
-
Der
erste Gesichtspunkt der Umsetzung von TCAP auf SIP beinhaltet die
Umsetzung von TCAP-Mitteilungs-Typen auf SIP-Mitteilungs-Typen und
Status-Codes. Wie dies in der Technik bekannt ist, sind SIP-Mitteilungen
entweder Anfragen oder Antworten. Die nachfolgenden Tabellen 1 und
2 zeigen Beispiele von Umsetzungen zwischen TCAP-Mitteilungs-Typen
(sowohl für
ANSI- als auch ITU-T-Versionen von TCAP) und SIP-Anforderungs- bzw.
Antwort-Mitteilungs-Typen.
-
-
-
Unter
Verwendung der vorstehenden Umsetzungen können SIP-Anfrage-/Antwort-Transaktionen, die das
funktionelle Äquivalent
von herkömmlichen
TCAP-Abfrage/Antwort-Transaktionen
ausführen,
erreicht werden. Die 3a–5b zeigen
Mitteilungsflüsse
für drei
beispielhafte Transaktionen unter TCAP und SIP.
-
3a zeigt
grundsätzliche
Schritte einer TCAP-Abfrage/Antwort-Transaktion nach dem Stand der Technik.
Wie dies in 3a gezeigt ist, leitet ein SSP
eine TCAP-Abfrage
mit Zulassung (QwP) an eine SCP (im Schritt S2) weiter, die durch
Zurückliefern
einer TCAP-Antwort an den SSP (im Schritt S4) antwortet. Das funktionelle Äquivalent
dieser Transaktion unter Verwendung von SIP gemäß der vorliegenden Erfindung
ist in 3b gezeigt. So wird eine SIP-Einladungs-Mitteilung, die den
Inhalt (beispielsweise gewählte
Ziffern) der TCAP-QwP-Mitteilung einkapselt, von einer MGC 16 an
den AS 18 (im Schritt S6) weitergeleitet, der zunächst mit
einer SIP-Bestätigungs-Mitteilung
(Schritt S8) und dann nachfolgend mit einer SIP-200-OK-Mitteilung (Schritt
S10) antwortet, die den Inhalt der TCAP-Antwort-Mitteilung (beispielsweise analysierte
Routeninformation) einkapselt.
-
4 zeigt die grundsätzlichen Schritte einer „Sende
an Ressource"-Konversation
nach dem Stand der Technik. Wie dies in 4a gezeigt
ist, leitet eine SSP eine TCAP-Anfrage mit Zulassung (QwP) an eine SCP
(im Schritt S12), die durch Zurückliefern
einer TCAP-Antwort (sende an Ressource) an die SSP (Schritt S14)
antwortet. Auf der Grundlage des Inhaltes der TCAP-Antwort-Mitteilung
baut die SSP eine Verbindung zu einem intelligenten Peripheriegerät (IPe)
(Schritt S16) auf, das dann verschiedene Funktionen ausführen kann, wie
z. B. das Abspielen einer Ankündigung
(Schritt S18) und/oder das Sammeln von gewählten Ziffern (Schritt S20).
Das IPe leitet dann eine Leistungsmerkmal-Mitteilung (Schritt S22)
weiter, die die Ergebnisse seiner Verarbeitung (beispielsweise gewählte Ziffern)
an die SSP enthält,
die ihrerseits diese Daten an die SCP in einer TCAP-CwP-(Anrufinformation
von der Ressource (CIFR))Mitteilung an die SCP (Schritt S24) weiterleitet.
Die SCP liefert eine TCAP-CwP-(Rufinformation an Ressource (CITR))Mitteilung
an die SSP (Schritt S26), die ihrerseits eine Leistungsmerkmal-Mitteilung,
die die CITR-Information
enthält,
an das intelligente Peripheriegerät (Schritt S28) weiterleitet.
Das intelligente Peripheriegerät
sendet dann eine Freigabe-Mitteilung an die SSP (Schritt S30), um
die Verbindung zwischen der SSP und dem IPe abzubauen. Bei Empfang
der Freigabe-Mitteilung sendet die SSP eine TCAP-CwP-Mitteilung,
die anzeigt, dass die Ressource frei ist, an die SCP (Schritt S32),
die eine TCAP-Antwort-Mitteilung an die SSP (Schritt S34) zurückliefert.
Wie dies weiter oben beschrieben wurde, sind die zwischen der SCP
und der SSP ausgetauschten Mitteilungen TCAP-Mitteilungen. Umgekehrt
würden
zwischen der SSP und dem intelligenten Peripheriegerät ausgetauschte
Mitteilungen normalerweise private Raten-Schnittstellen-(PRI-)Protokoll-Mitteilungen
sein, die über
ein Dienste integrierendes digitales Netzwerk (ISDN) oder eine Ethernet-Verbindungsstrecke übertragen
wurden.
-
4b zeigt
die äquivalente „sende
an Ressource" Transaktion
unter Verwendung des TCAP einkapselnden SIP gemäß der vorliegenden Erfindung.
Wie dies in 4b gezeigt ist, leitet eine
MGC 16 eine SIP-Einladungs-Mitteilung, die den Inhalt der
TCAP-QwP-Mitteilung einkapselt, an den AS 18 (im Schritt
S36), der durch Zurückliefern
von zunächst
einer SIP-Bestätigungs-Mitteilung
(Schritt S38) und dann einer SIP-182-in Warteschlange-Mitteilung
antwortet, die den Inhalt einer TCAP- „sende
an Ressource"-Mitteilung
an die MGC 16 (Schritt S40) einkapselt. Auf der Grundlage
des Inhaltes der SIP-182-in Warteschlange-Mitteilung baut die MGC 16 eine
Verbindung mit einem intelligenten Peripheriegerät (IPe) (Schritt S42) auf,
das dann verschiedene Funktionen ausführt, wie z. B. das Abspielen
einer Ankündigung
(Schritt S44) und/oder das Sammeln von gewählten Ziffern (Schritt S46).
Das intelligente Peripheriegerät
liefert dann eine Leistungsmerkmal-Mitteilung, die die Ergebnisse
ihrer Verarbeitung enthält
(beispielsweise gewählte
Ziffern) an die MGC 16 (Schritt S48) weiter, die ihrerseits
diese Daten an den AS 18 in einer SIP-182-in Warteschlange-Mitteilung
weiterleitet (Schritt S50). Die AS 18 liefert eine SIP-182-in
Warteschlange-Mitteilung, die eine Leitungsinformation an Ressource-(CITR-)Information
enthält,
an die MGC 16 (Schritt S52), die ihrerseits die Leistungsmerkmal-Mitteilung, die die
CITR-Information enthält,
an das intelligente Peripheriegerät (Schritt S54) weiterleitet. Das
intelligente Peripheriegerät
sendet dann eine Freigabe-Mitteilung
an die MGC 16 (Schritt S56), um die Verbindung zwischen
der MGC 16 und dem IPe aufzulösen. Bei Empfang der Freigabe-Mitteilung
sendet die MGC 16 eine SIP-182-in Warteschlange-Mitteilung,
die anzeigt, dass die Ressource frei ist, an den AS 18 (Schritt S58),
der eine SIP-200-OK-Mitteilung an die MGC 16 zurückliefert
(Schritt S60). Wie dies vorstehend bezüglich der 4a beschrieben
wurde, würden
die Signale zwischen der MGC 16 und dem intelligenten Peripheriegerät normalerweise
in privaten Raten-Schnittstellen-(PRI-)Mitteilungen sein, und sie
können über ein
Dienste integrierendes digitales Netzwerk (ISDN) oder eine Ethernet-Verbindungsstrecke übertragen
werden.
-
5a zeigt
TCAP-Prinzip-Mitteilungen, die in einer bekannten Rufwiederholungs-(RAG-)Transaktion ausgetauscht
werden. Wie dies in 5a gezeigt ist, führt ein
Versuch eines anrufenden Teilnehmers zur Herstellung einer Telefonverbindung
zwischen dem Telefon A und einem angerufenen Teilnehmer an einem
Telefon B zu einem üblichen
ISUP-IAM-Mitteilungsaustausch zwischen SSP-A und SSP-B (Schritt
S62) der feststellt, dass das Telefon B in Gebrauch ist (Gabelschalter
ausgehängt)
und daher eine übliche
ISUP-ReI-Mitteilung an die SSP-A liefert (Schritt S64). Bei Empfang
des „Belegt"-Signals aktiviert
der anrufende Teilnehmer das RAG-Merkmal und legt den Hörer am Telefon
A auf (Schritt S66). Als Ergebnis liefert die SSP-A eine TCAP-QwP-(NRAG-)Mitteilung
an die SSP-B (Schritt S68), die mit einer TCAP-CwP- Mitteilung antwortet,
die die TCAP-QwP-(NRAG-)Mitteilung bestätigt (Schritt S70). Wenn der
angerufene Teilnehmer den Hörer
am Telefon B auflegt (Schritt S72) liefert die SSP-B eine TCAP-CwP-Mitteilung
an die SSP-A (Schritt S74), die mit einer TCAP-(NRAG-abgeschlossen-)Mitteilung
(Schritt S76) antwortet. Die SSP-A kann dann den anrufenden Teilnehmer
informieren, dass der angerufene Teilnehmer nunmehr frei ist (Mitteilungsaustausch
nicht gezeigt).
-
5b erläutert die äquivalente
Rufwiederholungs-(RAG-)Transaktion unter Verwendung des TCAP einkapselnden
SIP gemäß der vorliegenden
Erfindung. Wie dies in 5b gezeigt ist, führt ein
Versuch eines anrufenden Teilnehmers zur Herstellung einer Telefonverbindung
zwischen dem Telefon A und einem angerufenen Teilnehmer am Telefon
B zu einem üblichen
SIP- und/oder ISUP einkapselnden SIP-Mitteilungsaustausch zwischen
MGC-A 16a und MGC-B 16b (Schritt S78), die feststellt,
dass das Telefon B in Gebrauch ist (Hörer ausgehängt) und daher eine übliche SIP-(Freigabe-)Mitteilung
an die MGC-A 16a liefert (Schritt S80). Bei Empfang des „Belegt"-Signals aktiviert
der anrufende Teilnehmer das RAG-Merkmal
(Schritt S82) und legt den Hörer
am Telefon A auf. Als Ergebnis leitet die MGC-A 16a eine
SIP-Einladungs-Mitteilung, die den Inhalt der TCAP-QwP-(NRAG-)Mitteilung
einkapselt, an MGC-B 16b weiter (Schritt S84), und dann
mit einer SIP-182-in-Warteschlange-Mitteilung
(Schritt S88) antwortet, wodurch die SIP-Einladungs-Mitteilung bestätigt wird.
Wenn der angerufene Teilnehmer den Hörer am Telefon B auflegt (Schritt
S90), leitet die MGC-B 16b eine SIP-182-in-Warteschlange-Mitteilung
an die MGC-A 16a (Schritt S92) weiter, die mit einer SIP-200-OK-Mitteilung
antwortet (Schritt S94). Die MGC-A 16a informiert dann
den anrufenden Teilnehmer, dass der angerufene Teilnehmer nun frei
ist (Mitteilungsaustausch nicht gezeigt).
-
6 ist
ein Blockschaltbild, das schematisch ein Beispiel eines Modells
für einen
SIP-Umschlag 20 zeigt, der den TCAP-Funktionsinhalt gemäß einer
Ausführungsform
der vorliegenden Erfindung einkapselt. Bei der Ausführungsform
nach 6 enthält
der SIP-Umschlag 20 Identifikations-Information in einem
SIP-Kopffeld 22 zusammen mit einem Mehrzweck-Internet-Post-Erweiterungs-(MIME-)Teil 24,
der eine Sitzungs-Beschreibungsprotokoll-(SDP-)Beschreibungs-information 26 und
einen binären
TCAP-Mitteilungsteil 28 einschließt, die durch eindeutige Grenzen
voneinander getrennt sind. Der SIP-Umschlag kann über das
Breitband-Paketnetzwerk 14 unter Verwendung von beispielsweise
dem Benutzer-Datagramm-Paket-(UDP-)Protokoll über IP transportiert werden.
-
Das
SIP-Kopffeld 22 und der SDP-Teil 26 stellen die
Sitzungssteuerung bereit, während
die MIME-Teile 24 eine Beschreibungssprache bereitstellen,
die unterschiedliche Dateitypen zu dem SIP-Umschlag 20 hinzufügt. Alle
diese Teile nutzen gemeinsam die folgenden Attribute:
- • sie
sind textbasiert (ASCII oder ISO 10646);
- • sie
werden jeweils für
einen bestimmten eindeutigen Zweck verwendet;
- • sie
können
Information für
diesen Zweck übertragen
und/oder codieren; und
- • jeder
Teil wird unter Befolgung eines deutlich verschiedenen Satzes von
Regeln realisiert.
-
Wie
dies in der Technik bekannt ist, ist das SIP ein Anwendungsschicht-Steuerprotokoll zur
Schaffung, Modifikation und Beendigung von Sitzungen zwischen zwei
oder mehr Geräten.
Für die
Zwecke der Einkapselung des TCAP-Funktionsinhaltes
gemäß der vorliegenden
Erfindung werden SIP-Klienten zur Kommunikation von Transaktionsinformation
verwendet, die zu einem Benutzer-Agenten-Verhalten
führen
kann. Die folgende Tabelle 3 zeigt Beispiele von SIP-Kopffeld-22-Felddefinitionen
und Beispiele von Werten, die im Zusammenhang mit der vorliegenden
Erfindung verwendet werden können.
Für eine
grundlegende Ebene der Sitzungssteuerung kann das SIP-Kopffeld 22 die „VOM", „AN", „ANRUFIDENTIFIKATION", „INHALTSTYP" und „INHALTSLÄNGE"-Felder einschließen. Andere
bekannte SIP-Kopffelder können
in einer bekannten Weise verwendet werden, um eine höherer Ebene
der Sitzungssteuerung bereitzustellen.
-
-
Unter
Verwendung der vorstehenden Felddefinitionen ist ein Beispiel eines
SIP-Kopffeldes 22 zur
Verwendung bei der vorliegenden Erfindung wie folgt:
INVITE
sip: callserverA@sipserver.nortelnetworks.com SIP/2.0
From:
sip:callserver@sipserver.nortelnetworks.com
To: sip:appserver123@sipserver.nortelnetworks.com
Call-ID:
1998122516401234@callseverA.nortelnetworks.com
Content-Type:
Application/Multipart
Content-Length: 273
-
Wie
sein Name andeutet, wird der SDP-Teil 26 zur Handhabung
von Beschreibungsinformation für eine
Kommunikationssitzung verwendet (beispielsweise zwischen der MGC 16 und
dem AS 18). Der SDP-Teil 26 liefert Endpunkt-
und Verbindungsinformation, und er wird innerhalb des SIP-Kopffeldes 22 durch
eine Inhaltstyp-(Content-Type-)Feldaussage mit der folgenden Form
identifiziert:
Content-Type: application/SDP; charset: ISO-10646.
-
Beispiele
von Felddefinitionen und Inhalten des SDP-Teils 26 sind
in der nachfolgenden Tabelle 4 angegeben.
-
-
Unter
Verwendung der vorstehenden Felddefinitionen ist ein Beispiel eines
STP-Port 26 zur Verwendung bei der vorliegenden Erfindung
wie folgt:
-
-
Wie
dies in der Technik gut bekannt ist, wurde MIME ursprünglich dafür ausgelegt,
Dateien an Email-Mitteilungen anzuhängen, dies kann jedoch ohne
weiteres zur Verwendung in anderen Transportsystemen angepasst werden.
Für die
Zwecke der vorliegenden Erfindung wird der MIME-Teil 24 dazu
verwendet, im binären
TCAP-Mitteilungsteil 28 an
das Ende der SIP/SDP-Kombination anzuhängen. Mehrteilige MIME-Nutzinformationen
ermöglichen
es einem SIP-Umschlag 20, irgendwelche PSTN/CCS-Signalisierungs-Information
zu übertragen,
die zum Aufruf der IN/AIN-Funktionalität erforderlich
ist. Der mehrteilige Hauptteil kann aus irgendeiner Kombination
des Folgenden bestehen: SDP-Nutzinformation; TCAP-Nutzinformation; und/oder
irgendeine Anzahl von MIME-Typen.
-
TCAP
kann mehrfache Komponenten enthalten. Gemäß der vorliegenden Erfindung
ist es möglich, eine
mehrteilige TCAP-Mitteilung in eine MIME-Nutzinformation einzukapseln
oder alternativ jede TCAP-Komponente in eine jeweilige getrennte
MIME-Nutzinformation einzukapseln. Im Allgemeinen folgt das MIME-Kopffeld 30 auf
das SIP-Kopffeld 22 und hat die Form des folgenden beispielhaften
MIME-Kopffeldes:
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=unique-boundary-1
-
Ein
Beispiel einer MIME-Nutzinformation 28, die eine binäre TCAP-Mitteilungs-Nutzinformation gemäß der vorliegenden
Erfindung überträgt, ist
wie folgt:
-
-
Die
vorstehend beschriebenen Umsetzungen ermöglichen es, dass der Funktionsinhalt
von TCAP-Mitteilungen in SIP-Umschlägen 20 für den Transport über ein
Breitband-Paketnetzwerk 14 eingekapselt wird. Die Einkapselung
des TCAP-Funktionsinhaltes
wird nunmehr weiter in Form von drei Beispielen von SIP-Mitteilungen wie
folgt beschrieben: eine SIP-EINLADUNGS-(SIP-SINVIT-)Mitteilung,
die eine TCAP-Anfage einkapselt; eine SIP-182-in-Warteschlange-(Queued-)Mitteilung,
die eine TCAP-Konversation mit einer Zulassungsmitteilung einkapselt;
und ein SIP-200-OK-Mitteilung, die eine TCAP-Antwort-Mitteilung
einkapselt.
-
Das
SIP-Mitteilungsformat erfordert, dass die erste Zeile eine „Anforderungs"-Zeile ist, gefolgt
von einer Serie von „Kopffeld"-Zeilen, einer <CRLF>-(Wagenrücklauf-Zeilenvorschub-)Trennung
und schließlich
den Mitteilungs-Hauptteil. In dem vorliegenden Beispiel werden der
SDP-Teil 26 und die MIME-Nutzinformation 28 durch
einen Begrenzungsparameter getrennt, der für dieses Beispiel den Wert „unique-boundary-1" hat.
INVITE:
sip:callserverA@sipserver.nortelnetworks.com SIP/2.0
From:
sip:callserver@sipserver.nortelnetworks.com
To: sip:appserver123@sipserver.nortelnetworks.com
Call-ID:
1998122516401234@callseverA.nortelnetworks.com
Content-Type:
Application/Multipart
Content-Length: 273
MIME-Version:
1.0 Content-Type: multipart/mixed; boundary=unique-boundary-1
<CRLF>
-
-
-
Die 3b, 4b und 5b zeigen
die Verwendung von in Warteschlangen angeordneten (queued) SIP-182-Mitteilungen
zum Einkapseln des Funktionsinhaltes der TCAP-Unterhaltung-mit-Zulassung-Mitteilungen.
Ein Beispiel einer in einer Warteschlange angeordneten SIP-182-Mitteilung,
die für
diesen Zweck geeignet ist, ist wie folgt:
SIP[TCAP]/0.0 182
Queued
From: callseverB <sip:callserverB.nortelnetworks.com>
To: callserverA <sip:callserverA.nortelnetworks.com>
Call-ID: 1998122516401234@callseverB.nortelnetworks.com
Content-Length:
122
Cseq: 1
MIME-Version: 1.0
Content-Type: application/tcap;base=ansi92
Content-Transfer-Encoding:
binary
<TCAP
Binary message part encoded here>
-
Die 3b, 4b und 5b zeigen
weiterhin die Verwendung von SIP-200-OK-Mitteilungen zum Einkapseln des Funktionsinhaltes
der TCAP-Antwort-Mitteilungen.
-
Ein
Beispiel einer SIP-200-OK-Mitteilung, die für diesen Zweck brauchbar ist,
ist wie folgt:
SIP[TCAP]/0.0 200 Queued
From: callseverA <sip:me.nortelnetworks.com>
To: callserverB <sip:callserverB.nortelnetworks.com>
Call-ID: 1998122516401234@callseverB.nortelnetworks.com
Cseq:
2 BYE
MIME-Version: 1.0
Content-Type: application/tcap;base=ansi92
Content-Transfer-Encoding:
binary
<TCAP
Binary message part encoded here>
