Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR ASSISTING THE FEATURES CALL HOLD , "CONFERENCE CALLING" AND "THREE-PARTY SERVICE" IN FMC NETWORKS
Document Type and Number:
WIPO Patent Application WO/2007/014833
Kind Code:
A1
Abstract:
The prior art can not implement the feature call hold in FMC network (fixed mobile conversion, i.e. mixed mobile fixed networks). This is due to the fact that the feature call hold (as well as the features conference calling and three-party service ) have different definitions in the 2 standards ITU-T Q1912.5 and 3GPP TS 24.228 with which incompatible procedures are defined. Compatibility problems arise since all involved units in the FMC networks with different units such as clients and network transition units necessitate an interworking of all interlinked units. The invention resolves this problem by providing a mapping functionality that converts the protocol elements of both standards into one another.

Inventors:
HOFFMANN KLAUS (DE)
Application Number:
PCT/EP2006/064200
Publication Date:
February 08, 2007
Filing Date:
July 13, 2006
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SIEMENS AG (DE)
HOFFMANN KLAUS (DE)
International Classes:
H04L29/06
Foreign References:
US20040229596A12004-11-18
EP1505842A22005-02-09
EP1388997A12004-02-11
EP1465386A12004-10-06
Other References:
ROSENBERG DYNAMICSOFT J PETERSON NEUSTAR H SCHULZRINNE COLUMBIA UNIVERSITY G CAMARILLO ERICSSON J: "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP); rfc3725.txt;", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, April 2004 (2004-04-01), XP015009505, ISSN: 0000-0003
Attorney, Agent or Firm:
SIEMENS AKTIENGESELLSCHAFT (München, DE)
Download PDF:
Claims:

Patentansprüche

1. Verfahren zum Bereitstellen von SDP Daten in FMC Netzen, die aus einem mobilen Netzanteil und einem Festnetzanteil ge- bildet sind, wobei in ersterem zur Bereitstellen von SDP Daten diese in einem ersten SIP Protokollelement (UPDATE) und in letzterem zur Bereitstellen von SDP Daten diese in einem zweiten SIP Protokollelement (RE-INVITE) geführt werden, dadurch gekennzeichnet, dass das erste SIP Protokollelement (UPDATE) gemäß einem ersten Standard von einer Mapping Funktion (MF) in das zweite SIP Protokollelement (RE-INVITE) gemäß einem zweiten Standard ohne Informationsverlust der SDP Daten umgesetzt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das erste SIP Protokollelement das SIP Protokollelement UPDATE ist.

3. Verfahren nach Anspruch 1, 2, dadurch gekennzeichnet, dass das zweite SIP Protokollelement das SIP Protokollelement RE-INVITE ist.

4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der erste Standard der ITU Standard Q.1912.5 ist.

5. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der zweite Standard der 3GPP Standard TS 24.228 ist.

Description:

Beschreibung

Verfahren zur Unterstützung der Leistungsmerkmale "CaIl Hold", "Conference calling" und "Three-Party Service" in FMC Netzen

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 wer- den.

Mit einer derartigen Trennung sind die gegenwärtig in Schmalbandnetzen geführten Telekommunikationsdienste auch in Breitbandnetzen zu realisieren. Dabei werden die Teilnehmer entwe- der direkt (z.B. über ein DSSl-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 CaIl 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) entstanden. Mit letzterem 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-Teil- nehmern erfolgt unter Zuhilfenahme von SIP-Protokollele- menten. 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. Beispiels- weise 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 Ser- vices, zu denen auch das Leistungsmerkmal "CaIl Hold" zählt, vorgenommen. "CaIl Hold" bedeutet, dass ein Gespräch geparkt oder auf Halten gesetzt wird, um beispielsweise eine Rückfrage an einen anderen Teilnehmer zu richten oder das Gespräch an einen anderen Teilnehmer weiterzuleiten, oder eine Konfe-

renz "Conference calling" (CONF) und "Three-Party Service" (3PTY) einzuleiten und wieder abzubauen.

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. Speziell ist nun in der ITU-T Recommendation Q.1912.5, Kap. B.10, Tabelle B.10-1 spezifiziert, dass das SIP Protokollele- ment RE-INVITE für das Leistungsmerkmal "CaIl Hold" erst dann zwischen den beiden Teilnehmern ausgetauscht wird, wenn beide sich im Gesprächszustand (Talking State) befinden, also der gerufene Teilnehmer abgehoben hat.

Das Standardisierungsgremium 3GPP für mobile Teilnehmer hat nun von der IETF weiter ein SIP Protokollelement UPDATE übernommen, das ursprünglich zwischen zwei Teilnehmern ausgetauscht wird, die noch keinen Gesprächszustand eingenommen haben, also wo der gerufene Teilnehmer noch nicht abgehoben hat. Diese Bedingungen wurden dahingehend erweitert, dass das SIP Protokollelement UPDATE nun auch dann ausgetauscht werden kann, wenn ein Gesprächszustand vorliegt. Speziell in der 3GPP Spezification 3GPP TS 24.228, V5.11.0, Kap. 10.1.3, Seite 403 wird aus Sicht von 3GPP auf das Leistungsmerkmal "CaIl Hold" eingegangen. Hier wird festgelegt, dass ein mobiles Endgerät ein SIP Protokollelement UPDATE in einem aktiven CaIl verwenden muss, um "CaIl Hold" durchzuführen. Für FMC Netze (fixed mobile conversion, d. h. gemischte mobile Festnetze) jedoch kommen auch nicht mobile Teilnehmer zur Anwen- düng oder MGCs und MGCF' s, die standardgemäß zu diesem Zweck das SIP Protokollelement RE-INVITE benutzen (z. B. gemäß der Q.1912.5 von ITU-T) .

Problematisch ist nun, dass es bei FMC Netzen mit unterschiedlichen Einheiten wie Clients und Netzübergangseinheiten (MGCF, MGC etc.) zu einem Interworking aller miteinander vernetzten Einheiten kommen wird. Da das Leistungsmerkmal "CaIl Hold" auf den unterschiedlichen Definitionen der 3GPP und der ITU-T Recommendation Q1912.5 basiert, sind damit inkompatible Prozeduren für "CaIl Hold" definiert. Folgerichtig können diese Einheiten nicht ohne weiteres das Leistungsmerkmal "CaIl Hold" gemeinsam bearbeiten, da unterschiedliche Meldun- gen benutzt werden. Gleiches gilt für die Leistungsmerkmale

"Conference calling" (CONF) und "Three-Party Service" (3PTY) .

Des Weiteren würde eine IMS Einheit, welche für das Event charging verantwortlich ist (e.g. CSCF) bei einem FMC Inter- working zwischen zwei Festnetzteilnehmern derzeit nicht in der Lage sein überhaupt zu erkennen, z. B. dass das Feature Hold von einem Festnetzteilnehmer (mit der RE-INVITE) durchgeführt wird. Damit entginge dem Netzwerkbetreiber im IMS zum einen eine Chargingmöglichkeit oder der Dienst kommt wegen der Inkompatibilität gar nicht zustande.

Der Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, wie in FMC Netzen die Leistungsmerkmale "CaIl Hold", "Conference calling" und "Three-Party Service" realisiert werden können.

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 Map- ping Funktionalität vorgesehen ist, die in einfacher Weise die SIP Protokollelemte UPDATE und RE-INVITE ineinander überführt. Damit ist es mit der vorgeschlagenen Lösung überhaupt

erst möglich, Leistungsmerkmale wie z. B. "CaIl Hold", "Conference Calling" und "Three-Party Service" in FMC Netzen zu realisieren .

Die Erfindung wird im Folgenden anhand eines figürlich dargestellten Ausführungsbeispiels näher erläutert.

Es zeigen:

Figur 1 die grundsätzlichen Verhältnisse zwischen 2 PSTN- Teilnehmern, zwischen denen ein Internetnetz angeordnet ist,

Figur 2 das IM Subsystem gemäß Standard TS24.229,

Figur 3 die Verhältnisse in FMC Netzen am Beispiel des

Leistungsmerkmals "CaIl Hold" von Teilnehmer A nach

B,

Figur 4 die Verhältnisse in FMC Netzen am Beispiel des

Leistungsmerkmals "CaIl Hold" von Teilnehemr B nach

A.

In Fig. 1 sind beispielhaft 2 PSTN-Netze offenbart, in denen jeweils eine Mehrzahl von PSTN-Teilnehmern in bekannter Weise angeordnet ist. 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- Pro-

tokoll 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.

Fig. 2 zeigt die Definition und Aufgaben des IMS Systems gemäß 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 eben- falls 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 Funkti- on die Signalisierung in das andere Netz weiter.

In Fig. 3 ist das erfindungsgemäße Verfahren am Beispiel des Leistungsmerkmals "CaIl Hold" aufgezeigt. Den 3 Leistungsmerkmalen "CaIl Hold", "Conference Calling" und "Three-Party Service" liegt die Problematik zugrunde, dass die SDP Daten der Endgeräte zu modifizieren sind. Demgemäß ist eine Mapping Funktionalität MF vorgesehen, die das SIP Protokollelement/ Nachricht UPDATE in das SIP Protokollelement RE-INVITE überführt. Hierbei wird davon ausgegangen, dass Teilnehmer A ein 3GPP Teilnehmer und Teilnehmer B ein PSTN Teilnehmer ist.

Ferner wird davon ausgegangen, dass Teilnehmer A der rufende Teilnehmer ist. Entsprechend der Definition des Dienstes "CaIl Hold" ist für den Dienst nicht erheblich, wer der rufende und wer der gerufene Telnehmer ist. Teilnehmer A sendet nun gemäß ITU-T Standard das SIP Protokollelement UPDATE zu dem gerufenen Teilnehmer B. Die Mapping Funktionalität MF nimmt nun das SIP Protokollelement UPDATE entgegen und setzt dieses in das SIP Protokollelement RE-INVITE um. Dabei werden auch die SDP Daten der Endgeräte gemäß RFC3264 "An Of- fer/Answer Model Session Description Protocol" und damit Informationen über das Leistungsmerkmal "CaIl Hold" ohne Informationsverlust gemappt . Der gerufene Teilnehmer B nimmt nun das SIP Protokollelement RE-INVITE entgegen und quittiert dies mit einer SIP Protokollmeldung 200 OK für das SIP Proto- kollelement RE-INVITE. Die Mapping Funktionalität MF nimmt diese Quittung entgegen und setzt sie in die SIP Quittungsmeldung 200 OK für SIP Protokollelement UPDATE um. Schließlich quittiert die Mapping Funktionalität MF den Vorgang dem Teilnehmer B mit einer Meldung ACK.

Fig. 4 zeigt den umgekehrten Vorgang, d. h. Teilnehmer A ist ein PSTN Teilnehmer und Teilnehmer B ein 3GPP Teilnehmer. In diesem Fall soll der rufende Teilnehmer der PSTN Teilnehmer A sein. Das Umsetzen der Protokollinformation durch die Mapping Funktionalität MF erfolgt in ähnlicher Weise, wie in Fig, 3 beschrieben.

Die Mapping Funktionalität MF kann in der Einrichtung CSCF, BGCF oder einem Application Server, oder auch in der Einrichtung MGCF angeordnet sein.