DE602004009940T2 - Bereitstellung von multimediadiensten mittels eines leitungsvermittelnden trägers - Google Patents

Bereitstellung von multimediadiensten mittels eines leitungsvermittelnden trägers Download PDF

Info

Publication number
DE602004009940T2
DE602004009940T2 DE602004009940T DE602004009940T DE602004009940T2 DE 602004009940 T2 DE602004009940 T2 DE 602004009940T2 DE 602004009940 T DE602004009940 T DE 602004009940T DE 602004009940 T DE602004009940 T DE 602004009940T DE 602004009940 T2 DE602004009940 T2 DE 602004009940T2
Authority
DE
Germany
Prior art keywords
cscf
endpoint
gateway
network
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602004009940T
Other languages
English (en)
Other versions
DE602004009940D1 (de
Inventor
Richard Bodin
Michael Stittsville LEEDER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nortel Networks Ltd
Original Assignee
Nortel Networks Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nortel Networks Ltd filed Critical Nortel Networks Ltd
Publication of DE602004009940D1 publication Critical patent/DE602004009940D1/de
Application granted granted Critical
Publication of DE602004009940T2 publication Critical patent/DE602004009940T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1043Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/12Setup of transport tunnels

Description

  • HINTERGRUND
  • Die vorliegende Offenbarung bezieht sich allgemein auf drahtlose Kommunikationssysteme und spezieller auf die Unterstützung von auf dem Internetprotokoll (IP) basierenden Multimediadiensten, die einen Leitungsträger einsetzen.
  • Telekommunikationssysteme wie beispielsweise das Funknetzwerk nach dem universellen mobilen Telekommunikationssystem (UMTS) entwickeln sich zu Systemen, die sowohl Sprach- als auch Datenverkehr über feststehende, drahtlose und Satellitennetzwerke übertragen können. Ein Teil dieser Evolution schließt die Entwicklung und Bereitstellung von Paketrahmenwerken zur Auslieferung von IP-basierenden, Echtzeit-, Konversations-, Multimediadiensten ein. Es wurde zum Beispiel ein IP-Multimedia-Subsystemstandard (IMS) als Teil des Partnerschaftsprojektes der 3. Generation (3GPP) definiert, um derartige Dienste bereitzustellen.
  • Die technische Spezifikation nach 3GPP 23.228 Version 5.9.0 Release 5 „3rd Generation Partnership Project; Technical Spezification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2" gibt die Dienstebeschreibung der Stufe 2 für das Subsystem des IP-Multimediakernnetzwerks vor, welches die erforderlichen Bestandteile enthält, um die IP-Multimedia (IM) Dienste in UMTS zu unterstützen. Das Dokument stellt ferner die Mechanismen heraus, um die Unterstützung von IP-Multimedia-Anwendungen zu ertüchtigen. Um die IP-Multimedia-Anwendungen wo immer möglich an Nicht-3GPP-IP-Anwendungen anzugleichen, ist der allgemeine Ansatz, Nicht-3GPP-spezifische IP-basierende Lösungen zu übernehmen.
  • Standards (wie beispielsweise IMS), welche die Bereitstellung von Multimediadiensten über ein paketbasierendes Netzwerk behandeln, benötigen allgemein Mechanismen für die Dienstequalität (QoS), die dazu bestimmt sind, ein bestimmtes Qualitätsniveau sicherzustellen. Die meisten drahtlosen Paketnetzwerke benötigen jedoch relativ wesentliche Erweiterungen, bevor derartige QoS Mechanismen bereitgestellt werden können, was die Implementierung der zugeordneten Standards verlangsamt. Während zum Beispiel IMS ein Rahmenwerk bereitstellt, um die Bereitstellung von Multimediadiensten in einem drahtlosen Netzwerk zu unterstützen, benötigen die meisten drahtlosen Netzwerke Aktualisierungen bezüglich ihrer Zugriffs-/Funkschichten, ebenso wie bei ihren Paketkern-/allgemeinen Paketfunkdienst-(GPRS) Subsystemen, bevor IMS auf geeignete Weise unterstützt werden kann. Die Einführung dieser Hochrüstungen kann mit einem beträchtlichen Zeit- und Kostenaufwand einhergehen, weil die Hochrüstungen entwickelt, ins Feld gebracht und getestet werden müssen.
  • Die internationale Veröffentlichung WO 02/28014 offenbart ein Verfahren, bei dem die Sprachübertragung über das Internetprotokoll in UMTS erreicht wird, indem ein Hybridmode des Anlagerns verwendet wird, wobei der Sprachträgerpfad von einem Mobiltelefon zur Netzwerksteuerung im Leitungsverbindungsmodus transportiert wird und von da weiter im Paketmodus. Die Steuerungssignalisierung vom Mobiltelefon wird über das Internetprotokoll an das Kernnetzwerk gesendet.
  • Entsprechend besteht ein Bedarf an einem verbesserten System und einem Verfahren, um für die Bereitstellung von IP-basierenden, Echtzeit-, Konversations-, Multimediadiensten zu sorgen. Es ist wünschenswert, diese Dienste für Mobilgeräte über Netzwerke bereitzustellen, die gegebenenfalls QoS Mechanismen nicht unterstützen, die für die Bereitstellung derartiger Dienste spezifiziert sind. Es ist ebenso wünschenswert, diese Dienste in Übereinstimmung mit den vorgegebenen Telekommunikationsstandards bereitzustellen und für das System und das Verfahren sich in Anlehnung an die Standards zu verhalten, die gegenwärtig implementiert sind oder die in Zukunft implementiert werden.
  • ZUSAMMENFASSUNG
  • In einer Ausführungsform wird ein Verfahren zur Bereitstellung eines paketbasierenden Multimediadienstes für einen Endpunkt in einem drahtlosen Netzwerk bereitgestellt, wobei der Dienst durch einen Telekommunikationsstandard vorgegeben ist, wobei das Verfahren aufweist: die Einrichtung eines paketbasierenden Signalisierungskontextes zwischen dem Endpunkt und einem Gateway; die Einrichtung eines Leitungsträgerleitungsabschnitt s zwischen dem Endpunkt und dem Gateway unter Verwendung des Signalisierungskontextes; und die Steuerung der Übertragung von Daten über den Leitungsträgerleitungsabschnitt unter Verwendung des Signalisierungskontextes, dadurch gekennzeichnet, dass das Netzwerk einen Mechanismus für die Dienstequalität von Paketen nicht unterstützt, der durch den Standard spezifiziert ist und worin der Signalisierungskontext verwendet wird, die Bereitstellung des paketbasierenden Multimediadienstes über den Leitungsträgerleitungsabschnitt in Angleichung an den Standard bereitzustellen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Ablaufdiagramm eines beispielhaften Verfahrens zur Bereitstellung von Multimediadiensten für ein Mobilgerät unter Verwendung eines Leitungsträgers.
  • 2 stellt ein beispielhaftes UMTS Drahtlosnetzwerk dar, bei dem das Verfahren von 1 implementiert werden kann.
  • 3 veranschaulicht eine Ausführungsform einer Architektur, die verwendet werden kann, um das Verfahren aus 1 im System von 2 zu implementieren.
  • 4 stellt einen beispielhaften Rufablauf dar, der eine Rufeinrichtung veranschaulicht, bei der ein Leitungsträger durch ein Netz über ein Medien-Gateway innerhalb der Architektur von 3 angefordert wird.
  • 5 ist ein beispielhafter Rufablauf, der eine Rufeinrichtung veranschaulicht, bei der ein Leitungsträger über ein Mobilgerät innerhalb der Architektur von 3 angefordert wird.
  • 6 veranschaulicht eine weitere Ausführungsform einer Architektur, die verwendet werden kann, um das Verfahren der 1 innerhalb des Systems von 2 zu implementieren.
  • 7 ist ein beispielhafter Rufablauf, der eine Rufeinrichtung veranschaulicht, bei der ein Leitungsträger durch ein Netzwerk über ein intelligentes Gateway innerhalb der Architektur von 6 angefordert wird.
  • 8 veranschaulicht noch eine weitere Ausführungsform einer Architektur, die verwendet werden kann, um das Verfahren aus 1 innerhalb des Systems aus 2 zu implementieren.
  • 9 ist ein beispielhafter Rufablauf, der eine Rufeinrichtung veranschaulicht, bei der ein Mobilgerät einen Ruf an ein Netzwerk innerhalb der Architektur von 8 auslöst.
  • 10 ist ein beispielhafter Rufablauf, der eine Rufeinrichtung veranschaulicht, bei der ein Netzwerk einen Ruf an ein Mobilgerät innerhalb der Architektur von 8 auslöst.
  • DETAILLIERTE BESCHREIBUNG
  • Die vorliegende Offenbarung bezieht sich allgemein auf drahtlose Kommunikationssysteme und spezieller auf die Unterstützung von auf dem Internetprotokoll (IP) basierenden Multimediadiensten, die einen Leitungsträger verwenden. Es wird jedoch verstanden, dass die nachfolgende Offenbarung viele Ausführungsformen oder Beispiele bereitstellt. Spezielle Beispiele oder Bestandteile und Anordnungen werden nachfolgend beschrieben, um die vorliegende Offenbarung zu vereinfachen. Diese stellen natürlich lediglich Beispiele dar und sind nicht dazu bestimmt, beschränkend zu wirken. Zusätzlich kann die vorliegende Offenbarung Bezugszeichen und/oder Buchstaben in verschiedenen Beispielen wiederholen. Die Wiederholung dient dem Zweck der Einfachheit und der Klarheit und gibt an sich keine Beziehung zwischen den verschiedenen Ausführungsformen und/oder Aufbauten, die besprochen werden, vor.
  • Mit Bezug auf 1 kann in einer Ausführungsform ein Verfahren 100 verwendet werden, um einen paketbasierenden Multimediadienst für ein Mobilgerät in einem Netzwerk bereitzustellen. Wie später noch im einzelnen beschrieben werden wird, ist der Dienst durch einen Telekommunikationsstandard definiert, der eine Dienstequalität (QoS) Funktionalität für paketbasierende Datenübertragungen spezifiziert. Das Netzwerk unterstützt jedoch keine derartige QoS Funktionalität. Entsprechend kann das Verfahren 100 verwendet werden, um die Multimediadienste in Übereinstimmung mit dem Standard auf dem nicht-konformen Netzwerk bereitzustellen.
  • In Schritt 102 kann eine Paketsignalisierungsverbindung zwischen dem Mobilgerät und dem Netzwerk eingerichtet werden. Diese Signalisierungsverbindung kann zum Beispiel ein Signalisierungsprotokoll verwenden, das die Rufeinrichtung, das Routing, die Authentifizierung und andere Nachrichten an Endpunkte innerhalb des IP-Netzwerks bereitstellt. In Schritt 104 wird eine Leitungsträgerverbindung zwischen dem Mobilgerät und dem Netzwerk eingerichtet. Da die Leitungsträger- und Paketsignalisierungsverbindungen simultan existieren, sollte das Mobilgerät eine Funktionalität aufweisen, welche diesen Doppelverbindungsbetrieb unterstützt.
  • In Schritt 106 können Signalisierungsinformationen und Daten, die mit dem Multimediadienst in Verbindung stehen, zwischen dem Netzwerk und dem Mobil gerät übertragen werden. Zum Beispiel kann in Schritt 108 Signalisierungsinformation für den Multimediadienst über die Paketsignalisierungsverbindung in Anlehnung an den Standard übertragen werden. In Schritt 110 können Daten für den Multimediadienst über die Leitungsträgerverbindung in Anlehnung an den Standard übertragen werden. Es wird verstanden, dass die Schritte 108 und 110 simultan stattfinden können, weil eine Signalisierungs- und Datenübertragung während der ganzen Kommunikationssitzung stattfinden kann. Entsprechend erlaubt es das Verfahren 100, den Multimediadienst für das Mobilgerät über das Netz wie nach dem Standard spezifiziert bereitzustellen, sogar, wenn das Netzwerk die spezifizierte QoS Funktionalität nicht unterstützt.
  • Sich nunmehr 2 zuwendend, veranschaulicht ein Telekommunikationsnetz 200 ein System, in dem das Verfahren 100, welches in Bezug mit 1 beschrieben wurde, ausgeführt werden kann. Im gegenwärtigen Beispiel stellt das Netzwerk 200 ein Funknetzwerk dar, welches sowohl Sprach- als auch Paketkommunikation unter Verwendung der allgemeinen Paketfunkdienst-(GPRS) und/oder der universellen mobilen Telekommunikationssystem-(UMTS) Technologien unterstützt.
  • Das Netzwerk 200 weist ein Funkzugriffsnetzwerk (RAN) 202 und ein Kernnetzwerk 204 auf. Das Kernnetzwerk 204 weist ferner eine Leitungsdomäne 206 auf und eine Paketdomäne 208. Andere Netzwerke können für das Netzwerk 200 zugänglich sein, wie beispielsweise ein öffentlich vermitteltes Telefonnetz (PSTN) 210 (das mit der Leitungsdomäne 206 verbunden ist), ein Internet 212, und ein X.25-Netzwerk 214 (die beide mit der Paketdomäne 208 verbunden sind).
  • Das RAN 202 enthält eine Vielzahl von Zellen (nicht gezeigt), die über Basistransceiverstationen (BTS) 216, 218 und 220 bedient werden. Die BTS 216 ist mit einer Basisstationssteuerung (BSC) 222 verbunden, um ein Drahtlosnetzwerk der 2. Generation bereitzustellen. Die BTSs 218, 220 sind durch die Netzwerksteuerungen (RNCs) 224, 226 jeweils zugänglich, um ein Drahtlosnetzwerk der 3. Generation bereitzustellen. Ein Mobilvermittlungszentrum/Besucheraufenthaltsregister (MSC/VLR) 228 kann verwendet werden, um das Kernnetzwerk 204 mit anderen Netzwerken, wie beispielsweise dem PSTN 210 zu verbinden. Ein Heimaufenthaltsregister (HLR) 230 kann für das MSC/VLR 228 zugänglich sein und ebenso ein Dienste bereitstellender GPRS Unterstützungsknoten (SGSN) 232 und ein Gateway GPRS Unterstützungsknoten (GGSN) 234 in der Paketdomäne 208.
  • Das Netzwerk 200 ermöglicht es wenigstens einem Mobilgerät 236, eine Kommunikationssitzung mit einer weiteren Vorrichtung über die BTS 216 einzurichten. Eine Anforderung einer Kommunikationssitzung mit dem Mobilgerät 236 kann zum Beispiel über das MSC/VLR 228 an (1) ein erstes Mobilgerät 238, (2) ein Sprachendgerät (nicht gezeigt), das mit dem PSTN 210 gekoppelt ist, oder (3) ein Datenendgerät (nicht gezeigt), das sonst wo an das Telekommunikationsnetz 200 gekoppelt ist, gerichtet werden. Falls es sich bei der Kommunikationssitzung zum Beispiel um eine Sitzung zur Datenübertragung auf einem Leitungsträger handelt, kann es sich bei der Anforderung darum handeln, das Mobilgerät 236 mit einem Rechner oder einer anderen Datenvorrichtung über das Netzwerk 200 zu verbinden. Falls es sich bei der Kommunikation um eine Sitzung zur Übertragung von Paketdaten handelt, kann die Anforderung durch den SGSN 232, den GGSN 234 und an das Internet 212 geroutet werden. Es ist festzustellen, dass während die Mobilgeräte 236 und 238 als Mobiltelefone dargestellt sind, sie ein beliebiges Mobilgerät darstellen können, das in der Lage ist, über das Netzwerk 200 zu kommunizieren. Ferner können die Mobilgeräte 236, 238 in der Lage sein, simultane Leitungs-/Daten-(zum Beispiel Paket) Verbindungen aufrechtzuerhalten. Es ist zu verstehen, dass das Netzwerk 200 lediglich der Veranschaulichung dient und die vorliegende Offenbarung gleichfalls auf andere Netze anwendbar ist.
  • Nunmehr Bezug nehmend auf 3 kann eine Architektur 300 verwendet werden, um eine Rufsitzung zu implementieren, die das Verfahren 100 der 1 repräsentiert. Im gegenwärtigen Beispiel kann die Rufsitzung durch das Netzwerk über ein Medien-Gateway oder einen Endanwender wie beispielsweise eine Mobilstation angefordert werden. Die Sitzung dient der Bereitstellung IP-basierender Echtzeit-, Konversations-, Multimediadienste. Zum Beispiel können die Dienste unter Verwendung eines IP-Multimedia-Subsystems (IMS) bereitgestellt werden, das als Teil des Partnerschaftsprojekts der 3. Generation (3GPP) definiert ist. Die Bereitstellung dieser Dienste in Konformität mit dem 3GPP kann jedoch bestimmte QoS Mechanismen erfordern, die in einigen Netzen nicht existieren können, wie beispielsweise QoS für Paket- und Zugangsschichten, die dem Telekommunikati onsnetz 200 aus 2 zugeordnet sind. Entsprechend ertüchtigt die Architektur 300 die Verwendung von 3GPP IMS Diensten vor der Einführung der IP QoS Mechanismen wie folgt, obwohl es verstanden wird, dass die vorliegende Offenbarung auch in einem Netzwerk implementiert werden kann, in dem derartige QoS Mechanismen existieren.
  • Die Architektur 300 weist einen Signalisierungspfad 302 auf und einen Trägerpfad 304 zwischen einer Mobilstation (MS) 306 (zum Beispiel ein Dual Mode Mobiltelefon, das in der Lage ist, simultan Leitungs-/Datenverbindungen zu unterhalten) und einer anderen Partei 308. Die MS 306 ist mit einem GGSN 310 über eine Verbindung in der Paketdomäne 312 verbunden (zum Beispiel unter Verwendung eines dynamischen Host-Konfigurationsprotokolls (DHCP), eines Domain-Namendienstes (DNS), etc.). Der GGSN 310 ist mit einer Proxy-Rufsitzungssteuerungsfunktion (P-CSCF) 314 verbunden, welche wiederum mit einer Dienste bereitstellenden Rufsitzungssteuerungsfunktion (S-CSCF) 316 kommunizieren kann. Es wird verstanden, dass andere Netzwerkeinheiten verwendet werden können, wie beispielsweise eine abfragende Rufsitzungssteuerungsfunktion (I-CSCF) (die mit dem S-CSCF 316 gezeigt ist).
  • Die P-CSCF 314 kann einen Kontaktpunkt in einem besuchten Netzwerk zur Verfügung stellen, nachdem die MS 306 im Netzwerk registriert ist. Die S-CSCF 316 kann verwendet werden, um Privilegien zu identifizieren, die der MS 306 zugeordnet sind, ebenso wie für die Auswahl und Bereitstellung des Zugangs zu einem Heimnetzanwendungsserver (nicht gezeigt). Die I-CSCF (ebenso 316) kann verwendet werden, um den Ort der S-CSCF festzustellen, und die Architektur des Netzwerks des S-CSCF zu verbergen. Die P-CSCF 314 und I/S-CSCF 316 können als funktionale Blöcke angesehen werden, die auf irgendeinem der vielen der Netzwerkknoten angeordnet sein können einschließlich innerhalb des GGSN 310. Der I/S-CSCF 316 kommuniziert mit der anderen Partei 308 über einen Austausch von SIP Nachrichten.
  • Die MS 306 ist mit dem Medien-Gateway (MGW) 318 über eine Verbindung in der Leitungsdomäne 320 verbunden. Das MGW 318 befindet sich in Kommunikation mit der anderen Partei 308 über einen IP-Trägerpfad 322. Im vorliegenden Beispiel vermittelt das MGW 318 den leitungsvermittelten Trägerverkehr, der von der MS 306 empfangen wird, über die Verbindung in der Leitungsdomäne 320 in IP-Paket basierenden Trägerverkehr. Der Trägerpfad 304 kann durch die MS 306 oder über einen intelligenten Knoten im Netzwerk wie beispielsweise das MGW 318 ausgelöst werden. Wie später in mehr Detail gezeigt werden wird, ertüchtigt der Nachrichtenverkehr, der verwendet wird, um die Rufsitzung innerhalb der Architektur 300 einzurichten, die Sitzung dazu, sich an spätere Netzwerkänderungen anzupassen, wie beispielsweise die Implementierung von QoS Mechanismen. Es wird festgestellt, dass die Verbindung in der Leitungsdomäne 320 allein für den Trägerverkehr von und zu der MS 306 verwendet wird, während die Signalisierungsinformationen über die P-CSCF 314 geroutet werden.
  • Im Betrieb, wie mit weiteren Einzelheiten in Bezug auf 4 beschrieben werden wird, wird ein erster Leitungsabschnitt der Sitzung über die Verbindung in der Leitungsdomäne 320 eingerichtet. Dies kann erreicht werden, indem ein Signalisierungs-PDP Kontext zwischen der MS 306 und der P-CSCF 314 (über den GGSN 310) eingerichtet wird. Dann findet die SIP Signalisierung zwischen der MS 306 und dem P-CSCF 314 statt, um die Rufsitzung einzurichten. Netzwerkdienste können unter Verwendung der S-CSCF 316 ausgeführt werden, und ein Leitungsträger wird angefordert, um die Verbindung in der Leitungsdomäne 320 einzurichten. Ein zweiter Leitungsabschnitt der Verbindung wird zur anderen Partei 308 über das MGW 318 unter Verwendung von entweder einer Paket- oder Leitungsverbindung eingerichtet. Das MGW 318 überbrückt dann sowohl den ersten und den zweiten Leitungsabschnitt, um die MS 306 und die andere Partei 308 zu verbinden.
  • Mit zusätzlichem Bezug auf 4 veranschaulicht ein Rufablauf eine Folge von Nachrichten, die innerhalb der Architektur 300 aus 3 verwendet werden kann. Im Rufablauf 400 wird das MGW 318 verwendet, um die Verbindung in der Leitungsdomäne 320 einzurichten. Wie in 4 gezeigt, enthält der Rufablauf 400 die MS 306, die P-CSCF 314, die I/S-CSCF 316 und das MGW 318.
  • Der Rufablauf 400 beruht stark auf dem SIP Nachrichtenaustausch. Wie bekannt ist, ist SIP auf dem Paradigma von Anforderung und Antwort basierend und kann aufgeteilt werden in SIP Anforderungsnachrichten und SIP Antwortnachrichten. SIP Anforderungsnachrichten schließen EINLADUNG ein (welche einen Ruf auslöst oder Rufparameter verändert), ACK (welche eine endgültige Antwort für EINLADUNG bestätigt), BYE (die den Ruf beendet), CANCEL (welches eine stattfindendes Einladen abbricht), OPTIONS (das einen Server über seine Fähigkeiten abfragt), REGISTER (das mit dem Ortsdienst registriert), und INFO (das Fortschreitungsinformationen sendet). Die SIP Antwortnachrichten können Antwortcodes wie 100 (fahre fort), 180 (läuten), 200 (OK), 302 (temporär bewegt), 401 (nicht autorisiert), und 600 (belegt) enthalten. Die Verwendung von SIP verleiht der Rufsitzung Flexibilität und kann ebenso dazu dienen, die Rufsitzung nach bekannten Standards wie 3GPP IMS auszurichten.
  • Der Rufablauf 400 beginnt mit Schritt 402, in dem die MS 306 eine SIP Einladungsnachricht an die P-CSCF 314 sendet. Die EINLADEN Nachricht enthält ein Paket zur Beschreibung des Protokolls einer Ausgangssitzung (SDP) im Körper der Nachrichten SIP EINLADEN. SDP stellt ein Protokoll dar, das verwendet werden kann, um eine Multimediasitzung anzuzeigen und kann derartige Informationen wie einen Sitzungsnamen und Zweck enthalten. Die SIP Nachricht EINLADEN wird von der P-CSCF 314 an das MGW 318 über die I/S-CSCF 316 weitergeleitet.
  • Die MS 306, die P-CSCF 314, die I/S-CSCF 316, und das MGW 318 führen SDP Verhandlungen über SIP Nachrichten in Schritt 404 durch. Die Verhandlungen können eine SDP Antwort, ein SDP Angebot, einen SDP Erfolg, und SDP Antwortaustausch enthalten. Im gegenwärtigen Beispiel kann eines der SDP Pakete einen Codec-Wert enthalten, um anzuzeigen, dass ein Leitungsträger verwendet wird. Die SDP Verhandlungen enthalten eine Reservierung von Leitungsressourcen durch das MGW 318, wie in Schritt 406 angezeigt.
  • In Schritt 408 verwendet die P-CSCF 314 einen Mechanismus der Paketsteuerungsfunktion (PCF), um QoS Ressourcen zu autorisieren, welche während der SDP Verhandlungen in Schritt 404 angefordert wurden, was mehrfach während der SDP Verhandlungen auftreten kann. Im gegenwärtigen Beispiel handelt es sich dabei um einen NULL Ablauf, weil kein QoS angefordert wird (das heißt, dass die Leitungsträgerverbindung 20 inhärent ein QoS vom Konversationsgrad aufweist und dieser nicht angefordert werden muss). In Schritt 410 richtet das MGW 318 jeweils erste und zweite Leitungsabschnitte zur Mobilstation 306 und der anderen Partei 308 ein. Es wird bemerkt, dass der zweite Leitungsabschnitt entweder paketvermittelt oder leitungsvermittelt sein kann.
  • Das MGW 318 empfängt eine LÄUTEN Anzeige in Schritt 412 und ordnet die LÄUTEN Anzeige der SIP Antwortnachricht LÄUTEN zu, welche dann an die MS 306 über die I/S-CSCF 316 und die P-CSCF 314 gesendet wird. Sobald das MGW 318 eine Antwortanzeige in Schritt 414 empfängt, leitet es diese Information als SIP Nachricht OK an die P-CSCF 314 über die I/S-CSCF 316 in Schritt 416 weiter. Die P-CSCF 314 verwendet die PCF, um die angeforderte QoS in Schritt 418 zu bestätigen, bei der es sich um einen NULL Ablauf handelt, weil kein QoS angefordert wurde. Die P-CSCF 314 leitet dann die SIP Nachricht OK an die MS 306 in Schritt 420 weiter. Die MS 306 kann dann damit beginnen, die Medienressourcen, die autorisiert und bestätigt wurden, in der Rufeinrichtung Schritt 422 zu verwenden. In Schritt 424 sendet die MS 306 eine SIP Nachricht ACK an die I/S-CSCF 316 über die P-CSCF 314. Nun wieder mit speziellem Bezug auf 3 kann in einer weiteren Ausführungsform die Architektur 300 durch das Mobilgerät 306 angefordert werden (anstatt durch das Netzwerk über das MGW 318 wie oben beschrieben). Wie zuvor festgestellt, kann die Architektur 300 für eine Rufsitzung verwendet werden, welche paketbasierende, Echtzeit-, Konversations-, Multimediadienste unter Verwendung von 3GPP IMS vor der Einrichtung von IP QoS Mechanismen im Netzwerk bereitstellt.
  • Im Betrieb, wie in weiteren Einzelheiten in 5 beschrieben werden wird, kann ein PDF Signalisierungskontext zwischen der MS 306 und dem GGSN 310 eingerichtet werden. Die SIP Signalisierung findet dann zwischen der MS 306 und der P-CSCF 314 statt, um eine Rufsitzung einzurichten. Netzwerkdienste können ausgeführt werden, indem die S-CSCF 316 verwendet wird. Ein erster Leitungsabschnitt der Sitzung kann über entweder eine Paket- oder eine Leitungsverbindung eingerichtet werden, und kann eine SIP VoIP oder eine SIP Leitungsträger-Rufeinrichtung verwenden.
  • Der zweite Leitungsabschnitt der Verbindung (die Verbindung in der Leitungsdomäne 320) wird durch die MS 306 eingerichtet. Während der SIP/SDP Signalisierung, die zwischen der MS 306 und der P-CSCF 314 stattfindet, wird ein Leitungsträger-Codec einbezogen, der anzeigt, dass eine Leitungsverbindung einzurichten ist. MS 306 erkennt den Leitungsträger-Codec und fordert eine Leitungsverbindung über das MGW 318 an. Das MGW 318 überbrückt dann sowohl den ersten als auch den zweiten Leitungsabschnitt, um die MS 306 und die andere Partei 308 zu verbinden und kann in der Sitzung verbleiben zur Dienstesteuerung während der Verbindung.
  • Mit zusätzlichem Bezug auf 5 veranschaulicht ein Rufablauf 500 eine Folge von Nachrichten, die innerhalb der Architektur 300 aus 3 verwendet werden kann. Im Rufablauf 500 wird die MS 306 verwendet, um die Verbindung in der Leitungsdomäne 320 einzurichten. Wie in 5 gezeigt, enthält der Rufablauf 500 die MS 306, die P-CSCF 314, die I/S-CSCF 316, und das MGW 318. Wie der Rufablauf 400 aus 4, beruht der Rufablauf 500 stark auf dem SIP Nachrichtenaustausch.
  • Der Rufablauf 500 beginnt mit Schritt 502, in dem die MS 306 eine SIP Nachricht EINLADEN an die P-CSCF 314 sendet. Wie zuvor beschrieben, enthält die EINLADEN Nachricht ein Ausgangs SDP Paket im Körper der Nachricht SIP EINLADEN. Die SIP Nachricht EINLADEN 302 wird von der P-CSCF 314 an das MGW 318 über die I/S-CSCF 316 weitergeleitet, und kann ebenso eine andere Netzwerkeinheit wie eine Abschluss CFCS weitergeleitet werden.
  • Die MS 306, die P-CSCF 314, die I/S-CSCF 316, und das MGW 318 führen SDP Verhandlungen über SIP Nachrichten in Schritt 404 durch. Diese Nachrichten können eine SDP Antwort, ein SDP Angebot, einen SDP Erfolg, und SDP Antwortaustausche enthalten. Im gegenwärtigen Beispiel kann eines der SPD Pakete einen Codec-Wert enthalten, um anzuzeigen, dass ein Leitungsträger verwendet wird. In Schritt 506 verwendet die P-CSCF 314 einen PCF Mechanismus, um QoS Ressourcen zu autorisieren, die während der SDP Verhandlungen 304 angefordert wurden, was mehrfach während der SDP Verhandlungen auftreten kann. Im gegenwärtigen Beispiel ist dies ein NULL Ablauf, weil keine QoS angefordert werden (das heißt, der Verbindung in der Leitungsdomäne 320 wohnt ein QoS vom Konversationsgrad inne, und muss deswegen nicht angefordert werden). In Schritt 508 richtet das MGW 318 einen ersten Rufleitungsabschnitt mit der anderen Partei 308 ein, und die MS 306 richtet einen Leitungsruf (einen zweiten Rufleitungsabschnitt) mit dem MGW 318 über die Verbindung in der Leitungsdomäne 320 ein. Das MGW 318 überbrückt dann die ersten und zweiten Rufleitungsabschnitte.
  • In Schritt 510 sendet das MGW 318 eine LÄUTEN Anzeige an die MS 306 über die I/S-CSCF 316 und P-CSCF 314. Sobald das MGW 318 eine Antwortanzeige in Schritt 512 empfängt, leitet es diese Information als SIP Nachricht OK an die P-CSCF 314 über die I/S-CSCF 316 weiter. Die P-CSCF 314 verwendet die PCF, um die angeforderte QoS in Schritt 514 zu bestätigen, welche einen NULL Ablauf darstellt, weil kein QoS angefordert wurde. Die P-CSCF 314 leitet dann die SIP Nachricht OK an die MS 306 in Schritt 516 weiter. Die MS 306 kann dann die Medienressourcen, die autorisiert und bestätigt wurden, in der Rufeinrichtung in Schritt 518 verwenden. In Schritt 520 sendet die MS 316 eine SIP Nachricht ACK an die I/S-CSCF 316 über die P-CSCF 314.
  • Nunmehr mit Bezug auf 6 veranschaulicht eine Architektur 600 eine weitere mögliche Implementierung einer Rufsitzung, welche das Verfahren 100 aus 1 repräsentiert. Im gegenwärtigen Beispiel kann eine Kommunikationssitzung innerhalb der Architektur 600 durch ein Netzwerk über ein intelligentes Gateway angefordert werden (anstatt durch die MS 306 oder über das Netzwerk via das MGW 318, wie oben beschrieben). Die Architektur 600 kann verwendet werden, um IP-basierende, Echtzeit-, Konversations-, Multimediadienste bereitzustellen, die 3GPP IMS vor der Einführung von IP QoS Mechanismen im Netzwerk verwenden.
  • Die Architektur 600 ist ähnlich zur Architektur 300 der 3, enthält aber ein intelligentes Netzwerk-Gateway (IN Gateway) 602 und ein MSC 604. Das IN Gateway 602 ist zwischen der P-CSCF 314 und dem MSC 604 positioniert. Das MSC 604 ist zwischen der Verbindung in der Leitungsdomäne 320 und dem MGW 318 positioniert. Es wird verstanden, dass die Positionen des IN Gateways 602 und des MSC 604 lediglich der Veranschaulichung dienen, und dass sie irgendwo in der Architektur 600 positioniert sein können. Darüber hinaus kann das IN Gateway 602 durch eine Gateway-Funktion repräsentiert werden, die in einer anderen Netzwerkeinheit angeordnet ist, wie dem MSC 604, demnach kann das IN Gateway 602 nicht als unabhängige physikalische Netzwerkeinheit implementiert sein. Das IN Gateway 602 stellt eine Funktionalität zur Zuordnung zwischen IP/SIP Nachrichten und SS7/IN Nachrichten bereit.
  • Im Betrieb, wie das in weiteren Einzelheiten in 7 beschrieben wird, kann ein PDP Signalisierungskontext zwischen der MS 306 und der P-CSCF 314 (über den GGSN 310) eingerichtet werden. Die SIP Signalisierung findet dann zwischen der MS 306 und der P-CSCF 314 statt, um eine Rufsitzung einzurichten. Netzwerkdienste können ausgeführt werden, indem die S-CSCF 316 verwendet wird. Ein erster Leitungsabschnitt der Sitzung kann eingerichtet werden, indem entweder eine Paket- oder Leitungsverbindung über eine IN Protokollnachricht an das MSC 604 verwendet wird. Im vorliegenden Beispiel wird der erste Leitungsabschnitt unter Verwendung einer Standard SIP VoIP oder SIP Leitungsträger-Rufeinrichtung eingerichtet.
  • Der zweite Leitungsabschnitt der Verbindung (die Verbindung in der Leitungsdomäne) wird durch die MS 306 über eine IN Nachricht an das MSC 604 angefordert. Die ersten und zweiten Leitungsabschnitte werden dann überbrückt, um die MS 306 und die andere Partei 308 zu verbinden. Falls beide Leitungsabschnitte leitungsbasierend sind, kann die Überbrückung durch das MSC 604 ausgeführt werden, ohne dass das MGW 318 benötigt wird. Falls jedoch der erste Leitungsabschnitt paketbasierend ist, dann kann das MGW 318 erforderlich sein, um die Überbrückung in Verbindung mit dem MSC 604 zu vervollständigen.
  • Mit zusätzlichem Bezug auf 7 veranschaulicht ein Rufablauf 700 eine Folge von Nachrichten, die verwendet werden können, um die Kommunikationssitzung, die zuvor beschrieben wurde, einzurichten, bei der das Netzwerk die Verbindung in der Leitungsdomäne 320 über das IN Gateway 602 anfordert. Wie in 7 gezeigt, enthält der Rufablauf 700 die MS 306, die P-CSCF 314, die I/S-CSCF 316, und das IN Gateway 602 und MSC 604 (welche bei dieser Darstellung kombiniert sind und durch das Bezugszeichen 604 bezeichnet werden).
  • Der Rufablauf 700 beginnt in Schritt 702, in dem die MS 306 eine SIP Nachricht EINLADEN an die P-CSCF 314 sendet. Wie zuvor beschrieben enthält die EINLADEN Nachricht ein Ausgangs SDP Paket im Körper der SIP Nachrichten EINLADEN. Die SIP Nachricht EINLADEN wird an die I/S-CSCF 316 weitergeleitet, welche eine entsprechende IN Nachricht an das MSC 604 (über das IN Gateway 602) sendet, um eine Leitungsverbindung in Schritt 704 anzufordern.
  • In Schritt 706 führen die MS 306, die P-CSCF 314, und die I/S-CSCF 316 SDP Verhandlungen über SIP Nachrichten durch. Diese Verhandlungen können eine SDP Antwort, ein SDP Angebot, einen SDP Erfolg, und SDP Antwortaustausche enthalten. Im vorliegenden Beispiel kann eines der SDP Pakete einen Codec-Wert enthalten, um anzuzeigen, dass ein Leitungsträger verwendet wird. In Schritt 708, der simultan zu Schritt 706 stattfinden kann, findet eine Interaktion mit dem IN Gateway/MSC 604 statt, um Antwortbenachrichtigungen anzufordern. In Schritt 710 verwendet die P-CSCF 314 einen PCF Mechanismus, um QoS Ressourcen zu autorisieren, die während der SDP Verhandlungen angefordert werden, was mehrfach während der SDP Verhandlungen geschehen kann. Im vorliegenden Beispiel handelt es sich dabei um einen NULL Ablauf, weil keine QoS angefordert wird (das heißt, der Verbindung in der Leitungsdomäne 320 wohnt ein QoS vom Konversationsgrad inne, und muss nicht angefordert werden). In Schritt 712 richtet das MSC 604 einen ersten Rufleitungsabschnitt (der in diesem Beispiel leitungsbasiert ist) mit der anderen Partei 308 ein, und richtet einen zweiten Rufleitungsabschnitt mit dem MS 306 über die Verbindung in der Leitungsdomäne 320 ein.
  • In Schritt 714 sendet die I/S-CSCF 316 eine LÄUTEN Anzeige an das MS 306 über die P-CSCF 314. Sobald das MSC 604 eine Antwort empfängt, berichtet sie diese an die I/S-CSCF 316 in Schritt 716. In Schritt 718 leitet die I/S-CSCF 316 diese Informationen als eine SIP Nachricht OK an die P-CSCF 314 weiter. Die P-CSCF 314 verwendet die PCF, um die angeforderte QoS in Schritt 720 zu bestätigen, bei der es sich um einen NULL Ablauf handelt, weil keine QoS angefordert wurde. Die P-CSCF 314 leitet dann die SIP Nachricht OK an die MS 306 in Schritt 722 weiter. Die MS 306 kann dann die Medienressourcen verwenden, die in der Rufeinrichtung in Schritt 724 autorisiert und bestätigt wurden. In Schritt 726 sendet die MS 306 eine SIP Nachricht ACK an die I/S-CSCF 316 via die P-CSCF 314.
  • Nunmehr mit Bezug auf 8 veranschaulicht in einer anderen Ausführungsform eine Architektur 800 eine weitere mögliche Architektur innerhalb der eine Rufsitzung, welche das Verfahren 100 aus 1 repräsentiert, ausgeführt werden kann. Wie bei den vorangehenden Beispielen kann die Architektur 800 verwendet werden, um IP-basierende, Echtzeit-, Konversations-, Multimediadienste bereitzustellen. Zum Beispiel können die Dienste bereitgestellt werden, indem IMS verwendet vor der Einführung von IP QoS Mechanismen wird, die allgemein für die Bereitstellung derartiger Dienste erforderlich sind. Verbindungen innerhalb der Architektur 800 können leitungsvermittelt (CS) oder paketvermittelt (PS) sein.
  • Die Architektur 800 enthält eine MS 802 und eine MS 804. Angeordnet zwischen den beiden Mobilstationen ist ein Hybriddienst-Gateway (HSG) 806. Ein Netzwerk 808, das einen SGSN, einen GGSN, und/oder andere Einheiten, wie in 2 beschrieben, enthalten kann, und ein MSC 810 sind zwischen der MS 802 und dem HSG 806 positioniert. Eine S-CSCF oder ein SIP Proxy/AS 812 ist zwischen der MS 804 und dem HSG 806 positioniert, obwohl nicht alle Verbindungen zwischen der MS 804 und dem HSG 806 durch den SIP AS 812 gehen müssen.
  • Das HSG 806 enthält eine Vielzahl von verschiedenen Funktionen, welche als tatsächliche unabhängige physikalische Bauteile repräsentiert sein können oder lediglich als funktionale Module des HSG 806. Zum Zwecke der verständlichen Darstellung werden diese Funktionen als unabhängige Bauteile bezeichnet, die innerhalb des HSG 806 kombiniert sind. Im gegenwärtigen Beispiel arbeitet das HSG 806 als eine P-CSCF 816 (zum Beispiel stellt sie keine Dienste bereit und steuert die Medien im Lokalnetzwerk). Das HSG 806 umfasst ebenso ein SIP Hauptratenschnittstellen (PRI) Gateway 818, ein Echtzeitprotokoll (RTP) Portal 820, einen IMS Medienserver 822 und verschiedene andere Medienserver 824.
  • Das PRI Gateway 818 kann Zugang zu und von einem Netzwerk gewähren (wie beispielsweise einem IP Netzwerk), indem es als Signalisierungs- und Medien-Gateway zwischen einem VoIP Netzwerk und einem leitungsbasierenden Netzwerk unter Verwendung einer ISDN Primärratenschnittstelle fungiert. Um Zugang zu gewähren, konvertiert das PRI Gateway 818 allgemein paketbasierende Sprachströme in leitungsbasierende Sprachströme und umgekehrt. Das RTP Portal 820 kann Elemente in einem privaten SIP Netzwerk ertüchtigen, um auf sichere Weise mit Elementen in einem öffentlichen Netzwerk in beide Richtungen zu kommunizieren. Das RTP Portal 820 kann ebenso als Ankerpunkt für einen RTP Medienstrom dienen. Dies sorgt für zusätzliche Flexibilität, indem zum Beispiel es der Architektur 800 ermöglicht wird, mit Sprachrundruftypen von Diensten zu arbeiten.
  • Im Betrieb, wie in weiteren Einzelheiten mit Bezug auf die 9 und 10 beschrieben werden wird, können die Dienste in der S-CSCF (oder dem SIP Proxy /AS) 812 bereitgestellt werden. Aufgrund dessen kann es sein, dass die MS 804 nichts darüber weiß, das ein leitungsvermittelter Leitungsabschnitt verwendet wird (zum Beispiel werden SIP Dienste, wie beispielsweise Rufweiterleitung und webbasierende Bereitstellung insgesamt vom IMS wiederverwendet). Darüber hinaus kann das PRI Gateway 818 nicht die MS 804 „rufen". Stattdessen kann SIP Signalisierung verwendet werden, um der MS 804 eine Portnummer am RTP Portal 802 zur Verfügung zu stellen, welche für eine „tatsächliche" Einrichtung einer VoIP SIP Sitzung sorgt. Zusätzlich kann es, während die Architektur 800 beide Leitungsabschnitt ertüchtigen kann, leitungsvermittelt zu sein, wünschenswert sein, ein zusätzliches PRI Gateway hinzuzufügen. Zugangsverfahren können gemischt werden, indem bei verschiedenen P-CSCF registriert wird (zum Beispiel unter Verwendung des R6 VoIP Verfahrens, WLAN, LAN, etc.).
  • Mit zusätzlichem Bezug auf 9 veranschaulicht ein Rufablauf 900 eine Folge von Nachrichten, die verwendet werden kann, um eine Kommunikationssitzung bereitzustellen, welche durch die MS 802 in der Architektur 800 von 8 initiiert wird, bei der ein Leitungsabschnitt leitungsbasierend ist und ein Leitungsabschnitt paketbasierend (zum Beispiel VoIP). Wie in 9 gezeigt, enthält der Rufablauf 900 die MS 802, die P-CSCF 816, das IISG PRI Gateway 818, das HSG RTP Portal 820 und die MS 804.
  • Der Rufablauf 900 beginnt mit Schritt 902, in dem die MS 802 eine STP EINLADEN Nachricht an die P-CSCF 816 sendet. Es wird verstanden, dass der SIP Nachrichtenaustausch über den SIP AS 812 transferiert werden kann. Die SIP Nachricht EINLADEN enthält ein SDP Paket, welches einen Null-Codec festlegt, so dass keine Sprachpakete über ein paketvermitteltes Netz gesendet werden. In Schritt 904 führen die P-CSCF 816 und das RTP Portal 802 einen Handshake durch, um Rufressourcen zu reservieren. Die P-CSCF 816 sendet dann eine SIP Nachricht EINLADEN, welche ein SDP Paket enthält, das eine RTP Portal-Anschlussnummer kennzeichnet, an die MS 804 in Schritt 906. In Schritt 908 antwortet die MS 804, indem sie eine SIP Nachricht OK, welche ein SDP Paket enthält, das die MS 804 identifiziert, an die P-CSCF 816 sendet. Die P-CSCF 816 leitet die SIP Nachricht OK, welche ein SDP-Paket mit einem Dummy-Domainnamen enthält, an die MS 802 in Schritt 910 weiter. Ein VoIP Trägerleitungsabschnitt 912 wird zwischen der MS 804 und dem RTP Portal 820 eingerichtet. Im vorliegenden Beispiel wird der VoIP Träger unter Verwendung einer Standard VoIP Rufeinrichtung eingerichtet.
  • Die MS 802 kann native Rufeinrichtungsabläufe verwenden, um den leitungsvermittelten Ruf in Schritt 914 über das PRI Gateway 818 zu initiieren. Das PRI Gateway 818 sendet eine SIP Nachricht EINLADEN, welche ein SDP Paket enthält, das das PRI Gateway 818 identifiziert, an die P-CSCF 816 in Schritt 916. In Schritt 918 sendet die P-CSCF 816 eine SIP Nachricht OK, die das RTP Portal 820 identifiziert, an das PRI Gateway 818. Ein VoIP Träger Leitungsabschnitt 920 wird dann zwischen dem RTP Portal 820 und dem PRI Gateway 818 eingerichtet. Wie zuvor kann der VoIP Träger Leitungsabschnitt 920 unter Verwendung einer Standard VoIP Rufeinrichtung etabliert werden. Das PRI Gateway 818 sendet eine ACK Nachricht in Bezug auf die Rufeinrichtung an die MS 802 in Schritt 922. Ein Leitungsabschnitt eines leitungsvermittelten Trägers 924 kann dann zwischen der MS 802 und dem PRI Gateway 818 eingerichtet werden. In Schritt 926 sendet die MS 802 eine SIP Nachricht ACK an die P-CSCF 816, welche die Nachricht an die MS 804 weiterleitet.
  • Nunmehr mit Bezug auf 10 und mit fortwährendem Bezug auf 8 veranschaulicht ein Rufablauf 1000 eine Folge von Nachrichten, die verwendet werden können, um eine Kommunikationssitzung bereitzustellen, welche durch das Netzwerk mit der MS 802 innerhalb der Architektur 800 von 8 initiiert wird, wobei ein Leitungsabschnitt leitungsbasiert ist und ein Leitungsabschnitt paketbasiert ist (zum Beispiel VoIP). Wie in 10 gezeigt, enthält der Rufablauf 1000 die MS 802, die P-CSCF 816, das HSG PRI Gateway 818, das HSG RTP Portal 820 und die MS 804.
  • Der Rufablauf 1000 fängt mit Schritt 1002 an, in dem die MS 802 eine SIP Nachricht EINLADEN an die P-CSCF 816 sendet. Es wird verstanden, dass der SIP Nachrichtenaustausch über den SIP AS 812 transferiert werden kann. Die SIP Nachricht EINLADEN enthält ein SDP Paket, das einen Null-Codec festlegt, so dass keine Sprachpakete über ein paketvermitteltes Netzwerk gesendet werden. In Schritt 1004 führen die P-CSCF 816 und das RTP Portal 820 einen Handshake durch, um Rufressourcen zu reservieren. Die P-CSCF 816 sendet eine SIP Nachricht EINLADEN, welche ein SDP Paket enthält, welches den Domainnamen der MS 802 identifiziert und das RTP Portal an das PRI Gateway 818 in Schritt 1006. In Schritt 1008 sendet das PRI Gateway 818 eine Nachricht zur Einrichtung eines leitungsvermittelten Rufs an die MS 802, welche dann eine ACK Nachricht in Bezug auf die Rufeinrichtung an das PRI Gateway 818 in Schritt 1010 sendet. Das PRI Gateway 818 sendet eine SIP Nachricht OK, welche ein SDP Paket enthält, das das PRI Gateway 818 kennzeichnet, an die P-CSCF 816 in Schritt 1012. Eine VoIP Träger Leitung 1014 wird dann zwischen dem RTP Portal 820 und dem PRI Gateway 818 eingerichtet. Im vorliegenden Beispiel kann der VoIP Träger Leitungsabschnitt unter Verwendung einer Standard VoIP Rufeinrichtung etabliert werden. Ein Leitungsabschnitt eines leitungsvermittelten Trägers 1016 wird zwischen dem PRI Gateway 818 und der MS 802 eingerichtet. Im vorliegenden Beispiel kann es wünschenswert sein, dass die MS 802 eingehendes Läuten unterdrückt.
  • Im Schritt 1018 sendet die P-CSCF 816 die SIP Nachricht EINLADEN, welche ein SDP Paket enthält, das das RTP Portal 820 identifiziert, an die MS 804. Als Reaktion sendet die MS 804 in Schritt 1020 eine SIP Nachricht OK, die ein SDP Paket enthält, das die MS 804 identifiziert, an die P-CSCF 816. Die P-CSCF 816 fügt einen Dummy-Domänennamen in das Paket ein und leitet die SIP Nachricht OK an die MS 802 in Schritt 1022 weiter. Ein VoIP Trägerpfad 1024 wird zwischen der MS 804 und dem RTP Portal 820 eingerichtet. Die MS 802 sendet eine SIP Nachricht ACK an die P-CSCF 816 in Schritt 1026, welche die SIP Nachricht ACK an die MS 804 weiterleitet.
  • Es wird verstanden, dass die vorliegende Offenbarung die Rufeinrichtung unter Verwendung eines SIP oder eines ähnlichen Protokolls bereitstellt, und dann leitungsvermittelte Netzwerkelemente verwendet, um einen Teil des Trägerpfades bereitzustellen. Dies erlaubt es, Multimediadienste, so wie jene, die durch IMS definiert sind, auf eine derartige Weise zu betreiben, dass ein Kunde, der das Netzwerk betrachtet, kein Wissen darüber besitzt, dass ein leitungsvermittelter Träger einen Teil des Trägerpfades bildet. Dies ermöglicht es, Dienste über ein Netzwerk zu betreiben, in dem nicht alle QoS Mechanismen implementiert sind, und gleicht die Bereitstellung der Dienste an vorgegebene Standards an, wie beispielsweise eine 3GPP IMS Architektur. Ferner sorgt dieser Ansatz für eine einfache Migration zu einem vollständigen VoIP Trägerpfad, wenn QoS Mechanismen im Netzwerk eingeführt werden. Zusätzlich sorgt dies für die Bereitstellung einer Dienstesteuerung, Rechnungsstellung, und Authentifizierungsarchitektur, die identisch ist zu jener, die in 3GPP IMS oder anderen Standards vorgeschlagen wird. Bei der vorliegenden Offenbarung kann der Träger ein beliebiger aus Echtzeit, Konversationssprache (zum Beispiel Sprache, Video, Spielsitzungen, Anwendungsteilnutzung, etc.) sein.
  • Während die vorliegende Offenbarung 3GPP GPRS und UMTS Technologien zum Zwecke der Veranschaulichung verwendet, wird es verstanden, dass sie gleichfalls anwendbar ist auf andere Technologien einschließlich denn leitungsgebundenen Zugang, drahtlosen lokalen Netzwerk-(LAN) Zugang wie beispielsweise 802.11, CDMA (Code Division Multiple Access)/1×RTT (Radio Transmission Technology)/1×EV-DO (Evolution Data Only) Zugang und/oder anderen Technologien.
  • Entsprechend wird es durch Fachleute verstanden werden, dass, während die vorangehende Beschreibung eines oder mehrere Ausführungsbeispiele zeigt, verschiedene Veränderungen in der Form und in Einzelheiten hierin durchgeführt werden können. Zum Beispiel kann die Art des Protokolls, das in der vorangehenden Beschreibung verwendet wird, variieren und es wird verstanden, dass Ersetzungen durchgeführt werden können. Ähnlich können verschiedene Netzwerkaufbauten für verschiedene Arten von digitalen Diensten verwendet werden. Darüber hinaus werden Begriffe wie „erster Leitungsabschnitt" und „zweiter Leitungsabschnitt" zum Zwecke der Angabe von Beispielen verwendet und bezeichnen nicht notwendigerweise eine sequentielle oder chronologische Reihenfolge. Zusätzlich wird es verstanden, dass Nachrichten zu oder von anderen Netzwerkeinheiten als den gezeigten gesendet werden können. Zum Beispiel, obwohl die SIP Nachrichten EINLADEN so dargestellt werden, dass sie von der MS gesendet werden, kann in einigen Ausführungsformen SIP EINLADEN an die MS gesendet werden. Deswegen sollten die Ansprüche in Übereinstimmung mit der vorliegenden Offenbarung auf breite Weise interpretiert werden.

Claims (17)

  1. Verfahren zur Bereitstellung eines Paket-basierenden Multimediadienstes an eifern Endpunkt (306, 802) in einem drahtlosen Netzwerk (200), worin der Dienst durch einen Telekommunikationsstandard vorgegeben ist, wobei das Verfahren aufweist: die Einrichtung (102) eines Paket-basierenden Signalisierungskontextes zwischen dem Endpunkt (306, 802) und einem Gateway (318); die Einrichtung eines Leitungsträgerauslegers zwischen dem Endpunkt (306, 802) und dem Gateway (318) unter Verwendung des Signalisierungskontextes; und Steuerung der Übertragung von Daten über den Leitungsträgerausleger unter Verwendung des Signalisierungskontextes, dadurch gekennzeichnet, dass das Netzwerk nicht einen Mechanismus für die Dienstequalität (QoS) von Paketen unterstützt, der durch den Standard spezifiziert ist und der Signalisierungskontext verwendet wird, die Bereitstellung des Paket-basierenden Multimediadienstes über den Leitungsträgerausleger in Angleichung an den Standard bereitzustellen.
  2. Verfahren nach Anspruch 1, ferner aufweisend das Anfordern der Leitungsträgerverbindung, worin die Anforderung durch das Netzwerk (200) ausgelöst wird.
  3. Verfahren nach Anspruch 1, ferner aufweisend das Anfordern einer Leitungsträgerverbindung, worin die Anforderung durch den Endpunkt (306, 802) ausgelöst wird.
  4. Verfahren nach Anspruch 1, ferner aufweisend die simultane Aufrechterhaltung der Verbindungen für den Leitungsträger und die Packetsignalisierung.
  5. Verfahren nach Anspruch 1, ferner aufweisend das Überbrücken der Leitungsträgerverbindung mit einer Endpunktträgerverbindung, worin die Überbrückung eine Verbindung zwischen dem Endpunkt (306, 802) und der Endpunktträgerverbindung einrichtet.
  6. Verfahren nach Anspruch 1, ferner aufweisend das Auslösen der Einrichtung des Leitungsträgerauslegers durch entweder den Endpunkt (306, 802) oder das Gateway (318).
  7. Verfahren nach Anspruch 1, ferner aufweisend die Autorisierung einer zuvor angeforderten QoS Ressource, worin die Autorisierung Null ist, weil keine QoS aufgrund der Leitungsträgerverbindung angefordert wurde.
  8. Verfahren nach Anspruch 1, worin die Autorisierung eine Paketsteuerungsfunktion verwendet.
  9. Verfahren nach Anspruch 1, worin die Einrichtung des Signalisierungskontextes die Bereitstellung eines Codec enthält, der anzeigt, dass ein Leitungsträger verwendet wird.
  10. Verfahren nach Anspruch 1, worin die Einrichtung des Signalisierungskontextes die Bereitstellung des Endpunktes (306, 802) mit einem Null-Codec einschließt, um zu verhindern, dass Sprachpakete über eine verfügbare Paketsignalisierungsverbindung gesendet werden.
  11. Verfahren nach Anspruch 1, worin die Verwendung des Signalisierungskontextes die Verwendung eines Paket-basierenden Initialisierungsprotokolls für eine Sitzung einschließt.
  12. Telekommunikationssystem zur Bereitstellung eines Paket-basierenden Multimediadienstes an einem Endpunkt (306, 802) in einem drahtlosen Netzwerk (200), worin der Dienst durch einen Telekommunikationsstandard vorgegeben wird, wobei das System aufweist: eine Proxy-Rufsitzungssteuerungsfunktion P-CSCF (314); ein Gateway (318), das mit der P-CSCF (314) verbunden ist; und eine Vielzahl von Befehlen zur Ausführung innerhalb des Netzwerks, die Befehle für: Einrichtung eines Paketsignalisierungskontextes zwischen dem Endpunkt (306, 802) und dem Gateway (318); Einrichtung einer Leitungsträgerverbindung zwischen dem Endpunkt (306, 802) und dem Gateway; wobei das Telekommunikationssystem dadurch gekennzeichnet ist, dass das Netzwerk nicht einen Mechanismus für die Dienstequalität (QoS) von Paketen unterstützt, der durch den Standard spezifiziert ist und das Netzwerk (200) ferner Befehle zur Übertragung von Signalisierungsinformationen für den Multimediadienst zwischen dem P-CSCF (314) und dem Gateway (318) aufweist, und zwischen dem Gateway (318) und dem Endpunkt (306, 802), über die Paketsignalisierungsverbindung in Angleichung an den Standard; und durch Übertragung der Daten für den Multimediadienst zwischen dem Gateway (318) und dem Endpunkt (306, 802) über die Leitungsträgerverbindung in Antwort auf die Signalisierungsinformationen.
  13. System nach Anspruch 12, ferner aufweisend eine Sitzungssteuerungsfunktion für einen Diensteaufruf S-CSCF (316), die mit der P-CSCF (314) und dem Endpunkt (306, 802) verbunden ist, worin ein Kommunikationsausleger zwischen der S-CSCF (316) und dem Endpunkt (306, 802) mit einer Leitungsträgerverbindung in Form einer Rufsitzung überbrückt werden kann.
  14. System nach Anspruch 12, worin Funktionalitäten, die durch das Medien-Gateway (318) und die P-CSCF (314) bereitgestellt werden, in einem Hybriddienste-Gateway HSG (806) kombiniert werden.
  15. System nach Anspruch 14, ferner aufweisend eine Vielzahl von Medienservern, die mit dem HSG (806) über die P-CSCF (314) verbunden sind.
  16. System nach Anspruch 12, ferner aufweisend: ein mobiles Vermittlungszentrum MSC (604, 810), das zwischen dem Endpunkt (306, 802) und dem Gateway (318) positioniert ist, worin die Leitungsträgerverbindung zwischen dem Endpunkt (306, 802) und dem MSC (604, 810) eingerichtet wird; und ein intelligentes Gateway (602), das zwischen dem MSC (604, 810) und der P-CSCF (314) positioniert ist, worin das intelligente Gateway (602) daran angepasst ist, die Signalisierungsnachrichten zwischen der P-CSCF (314) und dem MSC (604, 810) aufeinander abzubilden.
  17. System nach Anspruch 12, worin das Netzwerk (200) ein universelles mobiles Telekommunikationssystem UMTS drahtloses Netzwerk ist, und worin der Telekommunikationsstandard ein Internetprotokoll-Multimedia-Subsystem IMS Standard ist, der im Partnerschaftsprojekt der dritten Generation 3GPP definiert ist.
DE602004009940T 2003-07-30 2004-07-27 Bereitstellung von multimediadiensten mittels eines leitungsvermittelnden trägers Active DE602004009940T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US630999 2003-07-30
US10/630,999 US7746849B2 (en) 2003-07-30 2003-07-30 Providing packet-based multimedia services via a circuit bearer
PCT/IB2004/002413 WO2005011207A1 (en) 2003-07-30 2004-07-27 Providing packet-based multimedia services via a circuit bearer

Publications (2)

Publication Number Publication Date
DE602004009940D1 DE602004009940D1 (de) 2007-12-20
DE602004009940T2 true DE602004009940T2 (de) 2008-09-04

Family

ID=34103958

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004009940T Active DE602004009940T2 (de) 2003-07-30 2004-07-27 Bereitstellung von multimediadiensten mittels eines leitungsvermittelnden trägers

Country Status (4)

Country Link
US (2) US7746849B2 (de)
EP (1) EP1656773B1 (de)
DE (1) DE602004009940T2 (de)
WO (1) WO2005011207A1 (de)

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2398458B (en) * 2003-02-15 2005-05-25 Ericsson Telefon Ab L M Conversational bearer negotiation
US7746849B2 (en) * 2003-07-30 2010-06-29 Nortel Networds Limited Providing packet-based multimedia services via a circuit bearer
US7961714B1 (en) * 2004-05-11 2011-06-14 Nortel Networks Limited Providing packet-based multimedia services via a circuit bearer
US7359373B2 (en) * 2003-10-17 2008-04-15 Nokia Corporation System, apparatus, and method for establishing circuit-switched communications via packet-switched network signaling
US6994245B2 (en) * 2003-10-17 2006-02-07 James M. Pinchot Micro-reactor fabrication
US8374284B2 (en) * 2004-02-12 2013-02-12 Apple, Inc. Universal decoder
US8862570B1 (en) 2004-03-02 2014-10-14 Rockstar Consortium Us Lp Method and apparatus for open management of multi-media services
US8036211B1 (en) * 2004-03-09 2011-10-11 Genband Us Llc Legacy user proxy call session control function
CN100531194C (zh) * 2004-09-07 2009-08-19 华为技术有限公司 分组域业务信号处理系统及其方法
DE602005013281D1 (de) * 2004-12-17 2009-04-23 Huawei Tech Co Ltd Verfahren und system zum halten einer sitzungskontinuität
KR100871237B1 (ko) * 2005-01-31 2008-11-28 삼성전자주식회사 무선통신 시스템에서 이동 단말의 얼라팅 정보 송수신 시스템 및 방법
WO2007029056A2 (en) 2005-03-08 2007-03-15 Nortel Networks Limited Multiple access service convergence
EP1705859A1 (de) * 2005-03-24 2006-09-27 Orange SA Verfahren und System zur Aktivierung eines Kontextes für ein Packetdatenprotokoll
EP1705858A1 (de) * 2005-03-24 2006-09-27 Orange SA Verfahren und System zur Aktivierung eines Kontextes für ein Paketdatenprotokoll
CN100454914C (zh) * 2005-03-25 2009-01-21 华为技术有限公司 一种电路交换网络到ims网络呼叫路由的建立方法
WO2006109964A1 (en) * 2005-04-11 2006-10-19 Lg Electronics Inc. User equipment, method and system for simultaneous session control
CN101167381B (zh) * 2005-04-27 2012-07-18 艾利森电话股份有限公司 服务路由判决实体
KR100910801B1 (ko) * 2005-05-02 2009-08-04 엘지전자 주식회사 Sip 기반의 세션 셋업 방법 및 장치
KR100770861B1 (ko) * 2005-05-13 2007-10-26 삼성전자주식회사 아이피 멀티미디어 서브시스템망에서 회선교환 서비스정보를 획득하기 위한 방법 및 장치
CA2609942C (en) * 2005-05-27 2020-07-07 Nortel Networks Limited Circuit-switched and multimedia subsystem voice continuity with bearer path interruption
US20060291412A1 (en) 2005-06-24 2006-12-28 Naqvi Shamim A Associated device discovery in IMS networks
US7864936B2 (en) 2005-06-24 2011-01-04 Aylus Networks, Inc. Method of avoiding or minimizing cost of stateful connections between application servers and S-CSCF nodes in an IMS network with multiple domains
US20060291487A1 (en) * 2005-06-24 2006-12-28 Aylus Networks, Inc. IMS networks with AVS sessions with multiple access networks
US7792528B2 (en) * 2005-06-24 2010-09-07 Aylus Networks, Inc. Method and system for provisioning IMS networks with virtual service organizations having distinct service logic
CN100463574C (zh) * 2005-07-29 2009-02-18 中兴通讯股份有限公司 宽带码分多址系统主叫侧语音呼叫的快速建立方法
KR100909542B1 (ko) * 2005-08-01 2009-07-27 삼성전자주식회사 Csi 단말과 ims 단말 사이의 음성 및 멀티미디어 서비스 연동을 위한 방법 및 장치
WO2007038273A1 (en) * 2005-09-23 2007-04-05 Nokia Siemens Networks Gmbh & Co. Kg Centralized management of a multi-mode wireless call
US20070076696A1 (en) * 2005-09-30 2007-04-05 Yafan An Use of SIP messages for location services
US20070076664A1 (en) * 2005-09-30 2007-04-05 Yafan An Handoff decision making for heterogeneous network environments
WO2007073708A1 (de) * 2005-12-27 2007-07-05 Nokia Siemens Networks Gmbh & Co. Kg Verfahren zur steuerung des aufbaus einer sprachkommunikationsverbindung
CN100474854C (zh) * 2006-01-10 2009-04-01 华为技术有限公司 一种选择被叫接续网络的方法及网络系统
KR100933121B1 (ko) 2006-01-23 2009-12-21 삼성전자주식회사 Ims 도메인을 통한 실시간 서비스를 포함하는 ims 단말의 호 요청을 csi 단말이 처리하는 방법 및 장치
US9491305B2 (en) * 2006-01-30 2016-11-08 Nokia Technologies Oy Call management adjustment in call continuity architecture
MY154891A (en) 2006-01-31 2015-08-14 Interdigital Tech Corp Method and apparatus for supporting circuit switched interworking
WO2007090235A1 (en) * 2006-02-06 2007-08-16 Uiactive Ip Pty Ltd A system for conducting multi-media communication sessions
US20070197227A1 (en) * 2006-02-23 2007-08-23 Aylus Networks, Inc. System and method for enabling combinational services in wireless networks by using a service delivery platform
KR100775349B1 (ko) * 2006-03-31 2007-11-12 엘지전자 주식회사 서비스 도메인 선택 방법 및 장치
WO2007113636A2 (en) * 2006-04-03 2007-10-11 Nokia Corporation Multimedia session domain selection
CN100502359C (zh) * 2006-04-26 2009-06-17 华为技术有限公司 具有会话叠加功能的分组网络系统及其实现方法和装置
US8730945B2 (en) * 2006-05-16 2014-05-20 Aylus Networks, Inc. Systems and methods for using a recipient handset as a remote screen
US9026117B2 (en) * 2006-05-16 2015-05-05 Aylus Networks, Inc. Systems and methods for real-time cellular-to-internet video transfer
US8432899B2 (en) * 2007-02-22 2013-04-30 Aylus Networks, Inc. Systems and methods for enabling IP signaling in wireless networks
US8611334B2 (en) * 2006-05-16 2013-12-17 Aylus Networks, Inc. Systems and methods for presenting multimedia objects in conjunction with voice calls from a circuit-switched network
US20070286370A1 (en) * 2006-05-24 2007-12-13 Kauppinen Risto A Apparatuses and methods for presenting caller identities for communications originating and terminating in different communication domains
EP2033477A4 (de) * 2006-06-14 2014-01-08 Apple Inc Übergangshilfeverfahren von kommunikationssitzungen für ein benutzerelement zwischen verschiedenen subsystemtypen verschiedener generationen
US8687587B2 (en) * 2006-06-14 2014-04-01 Apple Inc. Inter-subsystem transfers
US9749296B1 (en) * 2006-06-30 2017-08-29 Avaya Inc. Method and apparatus for modifying address information in signaling messages to ensure in-path devices remain in signaling path between endpoints
CN101502076B (zh) * 2006-08-10 2012-09-05 诺基亚公司 与媒体后退进行交互工作
ATE518352T1 (de) 2006-10-03 2011-08-15 Research In Motion Ltd Verfahren und vorrichtungen zum steuern von call continuity in einer ims-netzwerkumgebung unter verwendung von sip-nachrichten
US20090323656A1 (en) * 2006-10-04 2009-12-31 Nortel Networks Limited Circuit-switched and multimedia subsystem voice continuity
US7856226B2 (en) * 2007-04-17 2010-12-21 Aylus Networks, Inc. Systems and methods for IMS user sessions with dynamic service selection
WO2008141675A1 (en) * 2007-05-22 2008-11-27 Telefonaktiebolaget Lm Ericsson (Publ) Method, apparatuses and computer program for dynamically configuring a proxy call session control function of the ip multimedia subsystem from a policy control rules server
US20080317010A1 (en) * 2007-06-22 2008-12-25 Aylus Networks, Inc. System and method for signaling optimization in ims services by using a service delivery platform
EP2139179A1 (de) * 2008-06-26 2009-12-30 THOMSON Licensing Verfahren und Vorrichtung für den Bericht von Statusinformationen
US8085810B2 (en) * 2008-08-06 2011-12-27 Movik Networks Cross-layer pipelining optimizations for reduced roundtrips and improving quality of experience
US8625582B2 (en) * 2008-08-14 2014-01-07 Motorola Solutions, Inc. Method and apparatus for routing a bearer path in an internet protocol multimedia subsystem based communication system
US8107932B1 (en) 2008-09-10 2012-01-31 Rockstar Bidco Lp Enabling mid-call services to be added to a communication session by a wireless device
US9032016B2 (en) * 2010-01-20 2015-05-12 Xyratex Technology Limited—A Seagate Company Communication method and apparatus
US9450989B2 (en) * 2010-05-19 2016-09-20 Avaya Inc. SIP anchor points to populate common communication logs
US20120005351A1 (en) * 2010-07-02 2012-01-05 Cisco Technology, Inc. Method and apparatus for transmitting an application identifier across application elements
KR101266692B1 (ko) * 2010-12-28 2013-05-22 주식회사 팬택 VoIP 서비스 제어 시스템 및 방법
CN102891830B (zh) * 2011-07-18 2017-04-05 中兴通讯股份有限公司 保障流媒体业务服务质量的方法及系统
CN103096180B (zh) * 2011-11-03 2017-12-12 重庆工程职业技术学院 流媒体QoS保障方法及系统
US10630507B2 (en) * 2016-11-29 2020-04-21 Ale International System for and method of establishing a connection between a first electronic device and a second electronic device

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
FI108599B (fi) * 1999-04-14 2002-02-15 Ericsson Telefon Ab L M Toipuminen matkaviestinjärjestelmissä
EP1094675A1 (de) * 1999-10-21 2001-04-25 Hyundai Electronics Industries Co., Ltd. Verfahren zur Übertragung einer Kontrolmitteilung zur Ressourcensteuerung in einem asynchronen mobilen Kommunikationssystem
US6633635B2 (en) * 1999-12-30 2003-10-14 At&T Corp. Multiple call waiting in a packetized communication system
US6768722B1 (en) * 2000-06-23 2004-07-27 At&T Corp. Systems and methods for managing multiple communications
US6721565B1 (en) * 2000-08-07 2004-04-13 Lucent Technologies Inc. Handover of wireless calls between systems supporting circuit and packet call models
US6424657B1 (en) * 2000-08-10 2002-07-23 Verizon Communications Inc. Traffic queueing for remote terminal DSLAMs
GB2367206B (en) 2000-09-26 2004-01-21 Motorola Inc Transmission of voice over packet-switched systems
ES2296733T3 (es) * 2001-02-06 2008-05-01 Nokia Corporation Sistema de acceso para una red celular.
US20020110104A1 (en) * 2001-02-13 2002-08-15 Telefonaktiebolaget Lm Ericsson (Publ). Hybrid media gateway control function providing circuit-switched access to a packet-switched radio telecommunications network
US7746849B2 (en) * 2003-07-30 2010-06-29 Nortel Networds Limited Providing packet-based multimedia services via a circuit bearer
US7961714B1 (en) * 2004-05-11 2011-06-14 Nortel Networks Limited Providing packet-based multimedia services via a circuit bearer

Also Published As

Publication number Publication date
DE602004009940D1 (de) 2007-12-20
WO2005011207A1 (en) 2005-02-03
US7746849B2 (en) 2010-06-29
EP1656773A1 (de) 2006-05-17
US20100260172A1 (en) 2010-10-14
US20050025047A1 (en) 2005-02-03
EP1656773B1 (de) 2007-11-07

Similar Documents

Publication Publication Date Title
DE602004009940T2 (de) Bereitstellung von multimediadiensten mittels eines leitungsvermittelnden trägers
DE602004010516T2 (de) Konversationsträgerverhandlung
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE602006000816T2 (de) Verfahren zur Bereitstellung von nahtlose mobile Sitzung
DE602004009669T2 (de) Routing-optimierung bei der sip-verbindungsherstellung
DE60225278T2 (de) Technik zur verbesserung von ansagen in anrufen mit mobilursprung
DE602004000139T2 (de) Schnelles SIP/SDP-Netzverfahren für Konferenzbetrieb mit Optimierung der Netzressourcen
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
EP2014047B1 (de) Vereinfachtes verfahren zur ims registrierung bei notrufen
DE69933286T2 (de) Telekommunikationssystem
DE60225577T2 (de) Setzen des kommunikationsmodus
EP1676414B1 (de) Sitzungen in einem kommunikationssystem
DE602004008293T2 (de) Transparente Zugangsauthentifikation in GPRS-Kern-Netzwerken
DE102004063298B4 (de) Verfahren zum rechnergestützten Verwalten von Kommunikationsrechten zum Kommunizieren mittels mehrerer unterschiedlicher Kommunikationsmedien in einer Telekommunikations-Konferenz mit mehreren Telekommunikations-Einrichtungen
WO2006000545A1 (de) Aufbau einer verbindung für den austausch von daten eines ip-basierten dienstes
DE602004007552T2 (de) Verfahren und einrichtung für push-to-talk-dienst
KR20080016610A (ko) 단말, 비상센터, 네트워크, 그리고 단말 신원을 이용하여비상 세션을 확립하기 위한 네트워크 요소, 시스템 및 방법
DE102006002434B3 (de) Verfahren und Server zum Herstellen einer Kommunikationsverbindung zwischen Kommunikationsendgeräten
DE102006010507B4 (de) Kommunikationsverbindungs-Aufbau-Steuerungs-Einheit, Verfahren zum Aufbauen einer Kommunikationsverbindung, Kommunikationsendgerät und Verfahren zum Anfordern einer Kommunikationsverbindung
DE102006012966B4 (de) Verfahren zum Signalisieren einer Anforderung zum Aufbauen einer Kommunikationsverbindung, Verfahren zum Aufbauen einer Kommunikationsverbindung, Kommunikationsverbindungsaufbau-Steuereinheit, Kommunikationsgeräte und Computerprogrammelemente
DE102007025052B4 (de) Verfahren und System zum Aufbau einer Datenverbindung in einem Kommunikationssystem
WO2006034948A1 (de) Nutzung von presence-informationen (statusinformationen) zur erweiterung einer bestehenden kommunikationsverbindung
DE102006008055B4 (de) Verfahren zum Wechsel von einem paketorientierten Kommunikationsdienst auf einen leitungsorientierten Kommunikationsdienst und vice versa
DE102004032923B4 (de) Verfahren zum Registrieren eines Kommunikationsendgeräts, Kommunikationssystem, Verfahren zum Steuern eines Kommunikationsendgeräts und Kommunikationsendgerät
DE102006054282B4 (de) Steuerung einer Mehrfachverbindung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition