-
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 Tunneln, 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 die
Endgeräte
oder 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.
-
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 vorgenommen.
Gleiches gilt für
das Standardisierungsgremium 3GPP für mobile Teilnehmer, wo SIP
basierte Dienste spezifiziert sind (TS 24.229). Insbesondere ist
hier in der IMS (IP multimedia subsystem) eine Architektur vorgegeben
und standardisiert, wie sie in 2 aufgezeigt
ist.
-
Grundsätzlich werden
in der ITU-T Q.1912.5 Empfehlung die Verhältnisse spezifiziert, wie sie
sich zwischen SIP- und PSTN-Teilnehmern ergeben. Dabei wird kein
Unterschied zwischen leitungsgebundenen und mobilen Teilnehmern
gemacht. Für
FMC Netze (fixed mobile conversion, d. h. gemischte mobile Festnetze) jedoch
kommen auch nicht mobile Teilnehmer zur Anwendung. Damit wird es
in derartigen FMC Netzen mit unterschiedlichen Einheiten wie Clients
und Netzübergangseinheiten
(MGCF, MGC etc.) zu einem Interworking aller miteinander vernetzter
Einheiten kommen.
-
Die
ITU-T Empfehlung Q1912.5 unterstützt
FAX T.38 Anwendungen. Mit zunehmender Verbreitung von SIP Clients,
die auch auf PDA's/Handy's laufen können, die
im Rahmen von 3GPP anwendbar sind, entsteht auch der Bedarf den
FAX Dienst über
T.38 (ITU-T recommendation T.38) durchzuführen.
-
Dieser
Dienst ist jedoch im 3GPP nicht möglich, da die IMS Architektur
FAX T.38 Anwendungen nicht unterstützt. Entsprechend der 3GPP
Empfehlung TS29.209 V6.2.0 (2005-03) „3rd Generation Partnership
Project; Technical Specification Group Core Network; Policy control
over Gq interface (Release 6)" sind
im Kapitel 6.5.21 lediglich für
die SDP Daten "AUDIO
(0)", "VIDEO (1)", "DATA (2)", "APPLICATION (3)", und "CONTROL (4)" erlaubt. Für T.38 Anwendungen
wird jedoch das SDP Datum „IMAGE" im Media-line (m-line)
Feld des SDP Protokolls benutzt. Die hierzu erforderliche Festlegung
erfolgt aus der IETF Empfehlung RFC 3362, „G. Parsons, "Real-time Facsimile (T.38) – image_t38
MIME Sub-type Registration",
August 2002." und
Detaillierung in Rec. T.38/V152. Nachfolgend ist ein entsprechendes
Media-Line Feld beispielhaft im SDP Protokoll aufgezeigt:
-
In
der Einrichtung P-CSCF der IMS Architektur (2) werden die SDP Daten abgegriffen,
und über das
Gq Interface der PDF Funktion (Policy Decision Function) zugeführt. Von
dieser wird dann entschieden, ob der Bearer nach Massgabe der vorhandenen
SDP Daten zwischen den beiden Endgeräten freigegeben werden kann.
Da die Einrichtung P-CSCF das für
ein T.38 Endgerät
repräsentative
SDP Datum „IMAGE" nicht erhält oder
kennt, wird diese Einrichtung über
das zugeordnete Gq Interface demzufolge auch den Baerer nicht entsprechend
einstellen.
-
Da
die SDP Daten derzeit lediglich beim Austausch zwischen den beiden
Endgeräten
abgegriffen werden, werden diese unverändert zwischen den Endgeräten über SIP
Signalisierung ausgetauscht, die SIP Signalierung bemerkt somit
keine Probleme und beginnt gegebenenfalls die Vergebührung. Da
die PDF Funktion den Bearer jedoch nicht freigeschaltet hat, kann
der Anwender keine FAX T.38 Übertragung
vornehmen, wird aber vergebührt.
-
Der
Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, wie
FAX T.38 Anwendungen in FMC-Netzen kontrolliert abgewiesen werden
können.
-
Die
Erfindung wird ausgehend von den in den Oberbegriffen der Patentanspruchs
1 und 5 angegebenen Merkmale durch die in den kennzeichnenden Teilen
beanspruchten Merkmale gelöst.
-
Der
Vorteil der Erfindung ist darin zu sehen, dass in FMC Netzen der
Anwender von T.38 Anwendungen der keine FAX T.38 Übertragung
vornehmen kann, darüber
informiert und damit auch nicht unnötig vergebührt wird. Aus der erhaltenen
Information kann er entsprechende Schlüsse ziehen und gegebenenfalls
eine FAX Verbindung über
G.711 aufbauen.
-
Die
Erfindung wird im folgenden anhand eines figürlich dargestellten Ausführungsbeispiels
näher erläutert.
-
Es
zeigen:
-
1 die
grundsätzlichen
Verhältnisse
zwischen PSTN- und/oder
mobilen Teilnehmern, zwischen denen ein Internetnetz angeordnet
ist,
-
2 die
konkrete Ausgestaltung eines FMC Netzes,
-
3 das
IM Subsystem gemäss
Standard TS24.229,
-
1 zeigt
die grundsätzlichen
Verhältnisse
zwischen PSTN- und/oder
mobilen Teilnehmern, zwischen denen ein Internetnetz angeordnet
ist. Hier sind beispielhaft 2 PSTN-Netze offenbart, in denen jeweils eine
Mehrzahl von PSTN-Teilnehmern in bekannter Weise angeschlossen 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 vorzugsweise
gemäss
vorliegendem Ausführungsbeispiel
das SIP Protokoll verwendet. Schliesslich ist am Media Gateway Controller MGC
B ein Subsystem IMS mit Einrichtungen P-CSCF, PDF herangeführt, über das
mobile Teilnehmer (z. B. IMS Tln) mit z. B. den PSTN Teilnehmern
verbindbar sind. Im Grunde handelt es sich bei der in 1 aufgezeigten
Konfiguration bereits um ein FMC Netz in seiner einfachsten Ausprägung.
-
2 zeigt
ein FMC Netz mit einer Mehrzahl von Strukturen. Demgemäss ist eine
Mehrzahl von vermaschten Netzen entnehmbar. Hierzu zählen mobile
(GRPS, UMTS) und feste (xDSL, LAN) Teilnehmerzugangsnetze ebenso,
wie drahtlose Teilnehmerzugangsnetze (WLAN). Als Übergangspunkt
sind jeweils Netze IM Subsysteme IMS oder Domänen angeordnet.
-
3 zeigt
die Definition und Aufgaben des IMS Systems gemäss 3GPP TS 23.002 V6.5.0 (2004-06) Standard.
Hierbei ist eine BGCF (Breakout gateway control function) Funktionalität, beschrieben.
Ferner sind Einrichtungen CSCF, P-CSCF sowie weitere Einrichtungen
aufgezeigt, deren Zusammenwirken ebenfalls in obigem Standard erläutert ist.
Beispielsweise wird von der BGCF Funktion (Breakout Gateway Control
Funktion) das Netz (Domäne,
z. B. PSTN) ausgewählt,
in das der von einem SIP Endgerät
UE ausgehende Ruf geleitet werden soll. Wenn die BGCF Funktion festlegt,
dass das Ziel im eigenen Netz liegt, d. h. in dem Netz, in dem die
BGCF Funktion angeordnet ist, wählt
die BGCF Funktion eine MGCF Funktionalität aus, die für das Interworking
mit dem PSTN Netz verantwortlich ist. Wenn das Ziel in einem anderen
Netz liegt, reicht die BGCF Funktion die Signalisierung in das andere
Netz weiter.
-
Schliesslich
kann 3 die Einrichtung P-CSCF entommen werden, die
als Steuerung der Schnittstelle Gq fungiert. Hier ist eine Funktion
PDF (Policy Description Function) abgelegt, die die Regeln im Netz
vorgibt. Tauschen beispielsweise 2 Endgeräte SDP Daten aus, so werden
diese von der Einrichtung P-CSCF abgegriffen und der Funktion PDF
zugeführt.
Wird von letzterer ermittelt, dass die vorgegebenen Regeln verletzt sind,
wird der Bearer nicht freigegeben und beide Teilnehmer können nicht
wie geplant miteinander kommunizieren.
-
Es
wird nun vorgesehen, dass die Einrichtung P-CSCF den Verbindungswunsch
für T.38
Anwendungen wenigstens kontrolliert abweist, falls das SDP Datum „IMAGE" auf dem Gq Interface
oder einem Gq äquivalenten
Interface nicht bekannt ist. Hierzu wird in der Einrichtung P-CSCF
erkannt, dass das SDP Datum „IMAGE" nicht zum Wertebereich
des Interfaces Gq (oder einem äquivalenten
Interface) gehört.
Ist dies der Fall, blockiert das Interface Gq das SDP Datum „IMAGE" und sendet nur die
verbleibenden SDP Daten an die PDF Funktion weiter. Diese hat somit
keinerlei Kentnisse darüber,
dass ein SDP Datum „IMAGE" in der Einrichtung
P-CSCF eingetroffen ist, d. h. dass der Bearer für eine T.38 Fax Anwendung geschaltet
werden soll.
-
Die
Einrichtung P-CSCF hat die SDP Daten des sendenden Teilnehmers aus
dem SIP Protokoll abgegriffen (SDP Offer). Ihre Aufgabe besteht
nun darin, den Teil des Media-Line Feldes mit „IMAGE" zu entfernen und den SDP Offer in der
SIP Nachricht an das empfangende Endgerät weiterzusenden. Die Antwort
des empfangenden Teilnehmers (response) wird von der Einrichtung
P-CSCF ebenfalls abgegriffen und der Port des Media-Line Feldes „IMAGE" mit dem Hinweis
T.38 innerhalb der SDP Daten auf „0" in der SDP Answer gesetzt, falls weiteren
SDP Daten in den Media-Lines stehen. Damit wird dem anfordernden/sendenden
Teilnehmer signalisiert, dass das SDP Datum „IMAGE" nicht benutzt wird. Der anfordernde/sendende
Teilnehmer erhält
somit eine Zurückweisung
(Reject) dieses Mediums, obwohl der Verbindungswunsch an sich erfolgreich
war. Gemäß RFC3264
kann das SDP mehrere m-lines (media lines) enthalten:
-
Falls
in diesem Fall keine weiteren SDP Daten mehr im Media-Line Feld stehen,
wird mit einem SIP negativen Response 415 „unsupported media type" (oder ähnliches)
ausgelöst.
Die Einheit die den Reject empfängt,
kann dann standardgemäss
mit einem anderen Media Type einen weiteren Verbindungswunsch durchführen.
