-
Neuere
Kommunikationsarchitekturen sehen die Trennung vermittlungstechnischer
Netzwerke in verbindungsdienstbezogene Einheiten und den Transport
der Nutzinformationen (Bearer Control) vor. Hieraus resultiert eine
Dekomposition/Trennung von Verbindungsaufbau und Medium- bzw. Beareraufbau.
Die Übertragung
der Nutzinformationen (Durchschaltung des Nutzkanals) kann dabei über unterschiedliche
hochbitratige Transporttechnologien wie z.B. ATM, IP oder Frame
Relay vorgenommen werden.
-
Mit
einer derartigen Trennung sind die gegenwärtig in Schmalbandnetzen geführten Telekommunikationsdienste
auch in Breitbandnetzen zu realisieren. Dabei werden die Teilnehmer
entweder direkt (z.B. über ein
DSS1-Protokoll) oder über
als Media Gateway Controller (MGC) ausgebildete Vermittlungsstellen
(z. B. über
das ISUP-Protokoll) angeschlossen. Die Nutzinformationen selbst
werden über
von Media Gateways (MG) in die jeweils benutzte Transporttechnologie
umgewandelt.
-
Die
Steuerung der Media Gateways werden von jeweils zugeordneten Media
Gateway Controllern (MGC) durchgeführt. Zur Steuerung der Media
Gateways verwenden die Media Gateway Controller normierte Protokolle,
wie z. B. das MGCP Protokoll oder das H.248 Protokoll. Zur Kommunikation
untereinander verwenden die Media Gateway Controller ein durch die
ITU standardisiertes BICC (Bearer Independent Call Control) Protokoll,
das aus einer Mehrzahl von standardisierten Protokollen gebildet
ist und somit eine Protokollfamilie umfasst.
-
Ein
dem BICC Protokoll adäquates
Protokoll ist bei dem IETF Standardisierungsgremium mit dem SIP Protokoll
(RFC3261) bzw. dem Zusatz SIP-T (RFC3204)/SIP-I entstanden. Mit
letzteren können
ISUP-Nachrichten – im
Gegensatz zum SIP Protokoll – übertragen
werden. Die Übertragung
der ISUP-Nachrichten erfolgt im allgemeinen durch Tunnel, d.h. durch
transparentes Durchreichen.
-
Der
Verbindungsaufbau zwischen 2 oder mehreren SIP-Teilnehmern erfolgt unter Zuhilfenahme
von SIP-Protokollelementen.
Hierbei werden unter anderem SDP (Session Description Protocol)
Daten ausgetauscht. SDP-Daten sind (Bearer-) endpunktbezogene Daten,
die Informationen über
Codecs, IP-Port, IP-Adresse usw. enthalten. Soll eine Verbindung
zwischen einem SIP-Teilnehmer und einem H.323 oder TDM/ISDN Teilnehmer
erstellt werden, müssen
diese SIP-Protokollelemente
in den beteiligten Media Gateway Controllern entsprechend in H.323-,
TDM- oder ISDN Protokollelemente umgesetzt werden. Beispielsweise bedeutet
dies für
einen aus der SIP Welt gerufenen TDM Teilnehmer, dass die in der
TDM Welt verwendeten ISUP-Nachrichten wie beispielsweise die ISUP-Nachricht
IAM (Initial Address Message), erzeugt und diesem zugeführt werden
muss.
-
Erste
grundsätzliche
Betrachtungen haben innerhalb der ITU-T zur Draft Recommendation
Q.1912.5 „Interworking
SIP and BICC/ISUP" geführt. Hierbei
wurden auch schon erste Überlegungen
bezüglich
der aus der ISDN Welt bekannten Supplementary Services, zu denen
beispielsweise das Leistungsmerkmal „Call Hold" zählt,
vorgenommen. Das Leistungsmerkmal „Fallback" wurde dort bisher nicht betrachtet.
In der Q.1912.5 wurde zusätzlich
auch noch die Verwendung des „CLEAR
MODE" Codec als „for further
study" deklariert.
Der „CLEAR
MODE" Codec ist
insbesondere für
Dienste, die auf TMR „64
kbit/s unrestricted" Eigenschaften
(Transmission Medium Requirements) basieren, zwar unbedingt erforderlich,
aber innerhalb ITU nicht freigegeben und deshalb nicht empfohlen.
-
Das
Leistungsmerkmal „Fallback" ist aus der ISDN
Welt bekannt. Hiermit werden vom sendenden Endgerät dem Netz
insgesamt zwei, für
die gewünschte
Bandbreite charakteristische Übertragungsparameter bekannt
gegeben. Der erste Übertra gungsparameter
definiert dabei die (höhere)
Handbreite, mit der das sendende Endgerät zu übertragen wünscht. Kann dieser Bandbreite
aufgrund der vorhandenen Netzressourcen oder der Eigenschaften des
empfangenen Endgerätes
nicht stattgegeben werden, wird der zweite (geringere) Übertragungsparameter
verwendet.
-
In
der ITU-T Q.1912.5 Empfehlung wird nun lediglich ein Codec zur Festlegung
der ISUP TMR Eigenschaften betrachtet. Damit kann aber das Leistungsmerkmal „Fallback" z. B. im Falle von
Videotelephonie (wie heute schon aus dem Festnetz bekannt) zwischen
zwei Teilnehmern, zwischen denen ein Internetnetz (SIP/SIP-T/SIP-I)
angeordnet ist, nicht realisiert werden, da bei Vorhandensein lediglich
eines Codecs ein Rückfall
auf eine geringere Bandbreite nicht möglich ist.
-
Ohne
diesen aus der ISDN Welt bekannten Fallbackdienst werden aber Verbindungen
nicht sofort mit der erforderlichen Bandbreite aufgebaut, sondern
zuerst einmal abgewiesen, was einen erneuten Verbindungsaufbau mit
geringer Bandbreite erforderlich macht. Dadurch entgehen dem Festnetzbetreiber
unnötigerweise
Gebühren
und gleichzeitig wird sein Netz mit nicht erfolgreichen Verbindungsaufbauversuchen
belastet.
-
Aus
Knight, R. R., u. a., "Bearer-independent
call control", BT
Technology Journal, Bd. 19, Nr. 2, April 2041, Seiten 77–88, ist
eine trägerunabhängige Rufsteuerung
bekannt, die eine einzige Erweiterung des ISUP enthält, nämlich bezüglich einer
besseren Unterstützung
von mobilen Rufen durch eine Verhandlung des besten Codecs. Außerdem Soll
der ISUP Service "Fallback" durch BICC unterstützt werden.
-
Aus
der
EP 1 509 018 A1 ist
ein Verfahren zur Signalisierung der Modifikation von Bearerverbindungen mittels
SIP-Protokoll bekannt.
-
Der
Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, wie
das Leistungsmerkmal „Fallback" in Internet-Netzen realisiert
werden kann.
-
Die
Erfindung wird ausgehend von den im Oberbegriff des Patentanspruchs
1 angegebenen Merkmale durch die in den kennzeichnenden Teilen beanspruchten
Merkmale gelöst.
-
Der
Vorteil der Erfindung ist darin zu sehen, dass eine Mappingfunktionalität vorgesehen
wird, die bei Empfang einer, für
ein transparentes Durchreichen von Informationen bewerkstelligenden
Codec-Funktionalität
im Internetprotokoll (SIP/SDP) und bei Vorhandensein mehrerer Audio-Codecs
das Leistungsmerkmal „Fallback" zwischen den beiden
Endgeräten über das
Internetnetz (SIP) hinweg initiiert. Damit ist das Leistungsmerkmal „Fallback" erst grundsätzlich in
SIP-I/SIP-T/SIP ISUP/BICC Netzen möglich.
-
Die
Erfindung wird im Folgenden anhand eines figürlich dargestellten Ausführungsbeispiels
näher erläutert. Die
Figur zeigt dabei die grundsätzlichen
Verhältnisse
zwischen 2 PSTN-Teilnehmern,
zwischen denen ein Internetnetz angeordnet ist.
-
In
der Figur sind beispielhaft 2 PSTN-Netze offenbart, in denen jeweils
eine Mehrzahl von PSTN-Teilnehmern in bekannter Weise angeordnet
sind. Diese sind an Ortsvermittlungsstellen LE herangeführt, die
ihrerseits mit Transit-Vermittlungsstellen
TX verbunden sind.
-
In
den Transit-Vermittlungsstellen TX wird nun die Trennung zwischen
Signalisierungsinformationen und Nutzinformationen durchgeführt. Die
Signalisierungsinformationen werden von der Transit-Vermittlungsstelle
TX unmittelbar über
ein ISUP-Protokoll einem jeweils zugeordneten Media Gateway Controller
MGC (MGC A oder MGC B) zugeführt.
Die Nutzinformationen werden zu einem (eingangsseitig angeordneten)
Media Gateway MG (MG A oder MG B) übertragen, das als Schnittstelle
zwischen TDM-Netz und einem ATM- bzw. IP-Übertragungsnetz fungiert und
werden über
das betreffende Übertragungsnetz
paketorientiert übertragen.
Das Media Gateway MG A wird von dem Media Gateway Controller MGC
A ebenso gesteuert, wie das Media Gateway MG B vom Media Gateway
Controller MGC B. Im Falle einer Übertragung der Nutzinformationen
vom Media Gateway MG A zum Media Gateway MG B werden die Nutzinformationen
wieder unter Steuerung des dem Media Gateway MG B zugeordneten Media
Gateway Controllers MGC B in einen TDM Datenstrom umgewandelt und
dem in Frage kommenden PSTN-Teilnehmer zugeführt werden. Die zwischen dem Media
Gateway Controller MGC und dem jeweils zugeordneten Media Gateway übertragenen
Daten werden von einem standardisierten Protokoll unterstützt. Dieses
kann beispielsweise das MGCP oder das H.248 Protokoll sein. Zwischen
den beiden Media Gateway Controllern MGC A, MGC B wird vor zugsweise
gemäß vorliegendem
Ausführungsbeispiel
das SIP Protokoll verwendet. In den Signalisierungspfad können noch
weitere Einrichtungen wie SIP-Proxies oder SIP Einheiten SIP E geschaltet
sein.
-
Grundsätzlich wird
bei vorliegender Erfindung von einer Konfiguration ausgegangen,
in der beispielhaft zwei ISDN Teilnehmer über ein SIP/ISUP/BICC Netz
miteinander verbunden sind.
-
Erfindungsgemäß wird nun
vorgeschlagen, eine Mappingfunktionalität vorzusehen, die z. B. bei
Empfang von dem oben genannten CLEAR MODE Codec im SIP/SDP Protokoll
und bei Vorhandensein eines weiteren (Audio) Codec die ISUP TMR
Eigenschaften mit „64
kbit/s preferred" zuweist
und den TMR prime (i. e. TMR')
entsprechend der heutigen Vorgaben der Q.1912.5 für den TMR
zuweist (i.e. „3,1
kHz audio"). Die
Mappingfunktionalität
ist zwischen dem SIP Netz und dem ISUP Netz angeordnet (MGCF/SIP/ISDN
Interworkingpunkt (oder gegebenenfalls in einer neuen physikalischen
logischen Einheit)).
-
In
der entgegengesetzten Richtung soll bei Empfang (auf der ISUP Seite)
von TMR mit „64
kbit/s preferred" und
von TMR prime (i. e. TMR')
mit „3,1
kHz audio" zum einen
der CLEAR MODE Codec im SIP/SDP Protokoll zugewiesen werden und
zum weiteren ein oder mehrere Audio codec(s) entsprechend den Vorgaben der
Q1912.5 Empfehlung für
den TMR zugewiesen werden.
-
Die
entsprechenden Verhältnisse
sind in den Tabellen 1 und 2 aufgezeigt. Hierbei wird in Tabelle
1 zunächst
davon ausgegangen, dass der Teilnehmer der A-Seite (Teilnehmer A)
das Leistungsmerkmal „Fallback" initiieren möchte (Vorwärtsrichtung:
d. h. SIP nach ISUP/BICC). Betrachtet wird nun die Mappingfunktionalität auf der
Schnittstelle zwischen SIP und ISUP (ausgehend von SIP). Die Mappingfunktionalität führt in Abhängigkeit
von den empfangenen Signalisierungsinformationen (Protokollelemente)
auf der SIP-I/SIP-T/SIP und ISUP/ISDN Seite die in Tabelle 1 aufgezeigten
Aktionen durch:
Die SIP Seite der A-Seite übergibt zunächst eine Liste, in der die
SDP Daten der A-Seite enthalten sind. Die SDP Daten sind im SIP
Protokollelement INVITE enthalten. Dieses wird in das ISUP Protokollelement
IAM umgesetzt. Ferner ist im SIP Protokollelement INVITE ein Datencodec
wie z. B. der CLEAR MODE Codec (oder ein VIDEO Codec) enthalten.
Ferner können
auch einer oder mehrere Audiocodecs (z. B. nach G.711) mit 3.1 kHz
enthalten sein. Bei Empfang eines Datencodecs und einem oder mehrerer
Audiocodecs wird nun dem Datencodec das ISUP TMR Protokollelement
mit „64
kbit/s preferred" und
dem ISUP TMR Protokollement 3.1 kHz oder irgendein anderer Wert
zugewiesen (speech). Wesentlich ist, dass dieser Wert kleiner als
64 kbit/s ist.
-
-
In
Tabelle 2 sind die Verhältnisse
(ebenfalls in Vorwärtsrichtung)
aufgezeigt, die sich ergeben, wenn das Leistungsmerkmal "Fallback" vom ISUP/TDM Teilnehmer
initiiert wird. Betrachtet wird also hier die Mappingfunktionalität zwischen
ISUP und SIP (ausgehend von ISUP). Das ISUP/BICC Protokollelement
IAM wird in das SIP Protokollelement INVITE umgesetzt. Ferner wird
aus dem ISUP TMR Protokollelement mit „64 kBit/s preferred" dem SDP in SIP ein
Datencodec wie z. B. CLEAR MODE zugewiesen und aus dem TMR Protokollelement
ein oder mehrere Audiocodecs) entsprechend den Vorgaben der Q.1912.5
Empfehlung.
-
-
Die
Tabellen 3 und 4 zeigen die Verhältnisse,
wie sie sich in Rückwärtsrichtung
ausgehend von dem rufenden Teilnehmer A gemäß Tabelle 1 ergeben. Demgemäß wird davon
ausgegangen, dass der gerufene Teilnehmer (Teilnehmer B) auf die
Aufforderung von Teilnehmer A hin (Tabelle 1) das Leistungsmerkmal „Fallback" initiiert und über Protokollelemente
dem rufenden Teilnehmer A quittiert. Hierbei sind zwei Fälle zu betrachten.
Im ersten Fall (Tabelle 3) ist der Initiierungsversuch insofern
erfolgreich, als dass dem TMR Protokollelement mit „64 kbit/s
preferred" von der
B-Seite nicht stattgegeben wird, jedoch die alternative „3.1 kHz
audio" angenommen
wurde. Hierbei wird das Protokollelement ISUP TMU (d. h. TMR used)
von der ISUP/BICC Seite der SIP Seite zugeführt (SIP to ISUP/BICC (18×/200 --> ACM/CPG/ANM/CON)).
-
Das
rufende Endgerät
der A-Seite erhält
nun eine Liste der SDP Daten, wie in Tabelle 3 aufgezeigt. Wesentlich
jedoch ist, dass das Protokollelement CLEAR MODE abgelehnt wird/fehlt,
entsprechend der Vorgabe durch RFC3264 Kapitel 6.1 durch Setzen
des media Ports auf 0. Dadurch wird der A-Seite signalisiert, dass die Initiierung
des Leistungsmerkmals „Fallback" erfolgreich war.
-
-
Im
zweiten Fall (Tabelle 4) wird davon ausgegangen, dass der Initiierungsversuch
nicht erfolgreich war, d. h. jedoch dass der TMR „64 kbit/s
preferred" angenommen
wurde. Die entsprechenden Verhältnisse sind
in Tabelle 4 aufgezeigt. Auch hier werden das entsprechenden Protokollelement
ISUP TMU (d. h. TMR used) von der ISUP/BICC Seite der SIP Seite
zugeführt
(SIP to ISUP/BICC (18×/200
-> ACM/CPG/ANM/CON)).
Wesentlich hierbei ist, dass in der Liste der SDP Daten das Protokollelement
CLEAR MODE mit einem Port ungleich 0 vorhanden ist. Damit wird der
A-Seite signalisiert, dass die Initiierung des Leistungsmerkmals „Fallback" fehlgeschlagen ist,
jedoch der bevorzugte TMR akzeptiert wurde.
-
-
Die
Tabellen 5 und 6 zeigen die Verhältnisse,
wie sie sich in Rückwärtsrichtung
ausgehend von dem gerufenen Teilnehmer B, welcher ein SIP/SIP-I
Teilnehmer ist, gemäß Tabelle
2 er geben. Tabelle 5 zeigt den Fall, dass das Leistungsmerkmal „Fallback" initiiert wurde,
Tabelle 6 zeigt den Fall, dass kein Fallback durchgeführt wurde.
-
-
-
Die
Mappingfunktionalität
kann in den Einrichtungen CSCF,BGCF des IMS Systems gemäß 3GPP TS 23.002
V6.5.0 (2004-06) Standard oder einem Application Server, oder auch
in der Einrichtung MGCF angeordnet sein.
-
Grundsätzlich wird
bei vorliegender Erfindung von eine Konfiguration ausgegangen, in
der zwei ISDN Teilnehmer über
ein SIP/ISUP/BICC Netz miteinander verbunden sind. Die Erfin dung
ist aber nicht auf ISDN Teilnehmer beschränkt. Sie kann vielmehr auf
Endgeräte übertragen
werden, die von beliebigen Protokollen unterstützt werden. Voraussetzung ist
lediglich, dass diese Protokolle das Leistungsmerkmal „Fallback" unterstützen.
-
Ferner
wurde als Datencodec der CLEAR MODE Codec angesprochen. Das Ausführungsbeispiel
ist aber nicht darauf beschränkt,
ein beliebiger VIDEO Codec (H261, etc.) oder auch weitere Datencodecs
könnte hier
ebenso verwendet werden.
-
Grundsätzlich wurde
bei vorliegender Erfindung von eine Konfiguration ausgegangen, in
der beispielhaft zwei ISDN Teilnehmer über ein SIP/ISUP/BICC Netz
miteinander verbunden sind. Die Erfindung ist hierbei aber nicht
darauf beschränkt.
Ferner wurde insbesondere auf ein Mapping von SIP nach ISUP eingegangen, ein
Mapping nach H.323, ISDN etc. ist aber ebenso möglich. Beispielhaft sei hierzu
angeführt,
dass Informationselemente, die „Fallback" möglichen/erlauben,
die ISDN Protokollelemente BC (bearer capability) mit BC 1 (speech
or 3.1 kHz audio) und BC 2 (unrestricted digital information with
tones and announcements) sind, wobei BC1 und BC2 entsprechend den
Vorgaben der Q.699 Empfehlung zugewiesen werden.
-
Zusätzlich ist
zu beachten, dass neben dieser Mappingfunktion die entsprechende
Einheit (MGC, MGCF, etc) dann das MG entsprechend einstellt und
dazu veranlasst, den verwendeten Codec über MGCP, H.248, MEGACO oder
internes Protokoll zu verwenden.
