DE20212586U1 - Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten - Google Patents

Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten

Info

Publication number
DE20212586U1
DE20212586U1 DE20212586U DE20212586U DE20212586U1 DE 20212586 U1 DE20212586 U1 DE 20212586U1 DE 20212586 U DE20212586 U DE 20212586U DE 20212586 U DE20212586 U DE 20212586U DE 20212586 U1 DE20212586 U1 DE 20212586U1
Authority
DE
Germany
Prior art keywords
network
rsvp
unit
message
cscf
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.)
Expired - Lifetime
Application number
DE20212586U
Other languages
English (en)
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.)
InterDigital Technology Corp
Original Assignee
InterDigital Technology Corp
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 InterDigital Technology Corp filed Critical InterDigital Technology Corp
Publication of DE20212586U1 publication Critical patent/DE20212586U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/748—Negotiation of resources, e.g. modification of a request
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/808—User-type aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/824—Applicable to portable or mobile terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/26—Resource reservation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/182—Network node acting on behalf of an other network entity, e.g. proxy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

InterDigital Technology Corporation I81285GM
[0001] Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
[0002] Hintergrund
[0003] Die vorliegende Erfindung bezieht sich auf mindestens ein Netzwerk, wie zum Beispiel einen GPRS-Gateway-Unterstützungsknoten (GGSN), der mit einem Benutzergerät (UE) kommuniziert und zur Verwendung eines der folgenden Verfahren fähig ist: TDDCDMA; TD-SCDMA; FDDCDMA und CDMA 2000. Insbesondere bezieht sich die vorliegende Erfindung auf die Verwendung eines Sitzungseinleitungsprotokolls (session initiation protocol / SIP) zur Einrichtung der richtigen das Ressourcenreservierungsprotokoll RSVP betreffenden Fähigkeiten und Anforderungen als eine Voraussetzung zur Einrichtung einer Kommunikation unter Verwendung von RSVP und weiter zur Einrichtung von Dienstgütefähigkeiten (quality of service / QoS) des UE und GGSN zur Sicherstellung der erwünschten Dienstgüte (QoS).
[0004] Derzeit erlauben die Standards des Third Generation Partnership Project Protocol (3GPP) die optionale Unterstützung eines Ressourcenreservierungsaufbauprotokolls (RSVP) im Benutzergerät (UE) und im GGSN als ein Signalisierungsprotokoll zum Sicherstellen der Dienstgüte. Aktuelle Standards sehen eine Trennung zwischen Rufeinrichtungsprozeduren und der Einrichtung von QoS vor. Zum Beispiel kann ein UE mit einer RSVP-Fähigkeit einen Anruf (eine Sitzung) an ein RSVP-unfähiges UE, das in einem RSVP-unfähigen Netzwerk betrieben wird, einleiten. Die langwierigen Rufeinrichtungsprozeduren werden erfolgreich stattfinden, jedoch ohne eine Angabe des für QoS beabsichtigten Protokolls. Nach der Einrichtung des Anrufs wird das RSVP-fähige UE damit beginnen, RSVP-Signalisierungsnachrichten auszusenden, um Ressourcen zu reservieren, die zum Tragen des Medienstroms entlang der Route zum Endpunkt nötig sind. Diese RSVP-N ach richten werden über das Internet getragen, nur um am anderen Ende ein unfähiges UE und einen
unfähigen GGSN zur Fertigstellung der Reservierungsprozeduren vorzufinden. Die fehlende Antwort vom Endpunkt an den Aussender der RSVP-Signalisierung wird zum Verfall der diesem bestimmten Medienstrom zugewiesenen Ressourcen auf beiden Seiten während des Rufeinrichtungsschrittes führen, was zu einer Beendigung der Sitzung und einer Rechnungsstellung für einen Dienst führt, der nicht geboten werden konnte. Diese unrationelle Nutzung der Systemressourcen verringert die Gesamtsystemkapazität und den Wirkungsgrad aufgrund der Tatsache, dass ein solches Szenario ständig beim Rufaufbau (Sitzungsaufbau) zwischen RSVP-fähigen und RSVP-unfähigen Netzwerken und UEs auftreten würde. Außerdem sieht die derzeitige Technik die optionale Unterstützung für das Ressourcenreservierungsprotokoll (RSVP) sowohl in Benutzergeräten (UE) als auch im Kernnetzwerk-GGSN der Universal Mobile Telecommunications Services (UMTS) vor. Das Ergebnis ist, dass weder das UE noch der GGSN irgendwelche Annahmen über die Unterstützung eines solchen Protokolls machen können, außer dass es nicht anwendbar ist, d.h. NA ist ein Standard-Betriebsmodus. Es ist daher wichtig, einen Mechanismus vorzusehen, durch den ein RSVP-fähiges UE und ein RSVP-fähiger GGSN sich einander von ihren RSVP-Fähigkeiten in Kenntnis setzen können, bevor Kommunikationen unter der Verwendung von RSVP stattfinden können.
[0005] Zusammenfassung
[0006] Die vorliegende Erfindung offenbart Vorrichtungen, durch welche RSVP-Fähigkeiten eines UE und eines GGSN definiert und ausgetauscht werden. Die Erfindung sieht einen Anzeige- und Antwortmechanismus zum Aushandeln eines bevorzugten RSVP-Betriebsmodus unter Verwendung eines Sitzungs-Einleitungsprotokolls (SIP) vor. Die Kommunikation von Nachrichtenaustauschvorgängen zwischen UE und GGSN können eines der folgenden Verfahren verwenden: Zeitduplex-Codemultiplex-Mehrfachzugriff (TDDCDMA), Zeitmultiplex-Synchron-Codemultiplex-Vielfachzugriff (TD-SCDMA), Frequenzduplex-CDMA (FDDCDMA) und CDMA 2000.
[0007] Das SIP wird verwendet, um Folgendes anzuzeigen: Die RSVP-Fähigkeit des UE; denjenigen Medienfluss (diejenigen Medienflüsse), der auf RSVP basiert (die auf RSVP basieren); den bevorzugten Betriebsmodus, d.h. entweder UE-basierte RSVP-Signalisierung oder GGSN-proxy-basierte RSVP-Signalisierung; und die
• ·
Kommunikation des letztendlichen Aufbaumodus für die RSVP-Signalisierung an das UE von der Policy Control Function (PCF) (Steuerfunktion, die sich nach Betreibervorschriften richtet).
[0008] Erfindungsgemäß sendet das Ursprungs-UE während des Sitzungsaufbaus eine SIP-Nachricht an eine Proxy-Call State Control Function (P-CSCF) eines Heimatnetzwerks, das eine Liste aller Medientypen, Fähigkeiten und bevorzugten Betriebsmodi liefert. Die P-CSCF, welche die Policy Control Function (PCF) enthält, ist letztendlich für die Zuweisung von Ressourcen verantwortlich, die zum Durchführen der gewünschten Sitzung notwendig sind. Die SIP-Information wird zum Treffen einer letztendlichen Entscheidung über den RSVP-Betrieb verwendet. Die P-CSCF (PCF) kann die RSVP-Fähigkeiten des GGSN anfordern, wobei diese Fähigkeiten an einem geeigneten Ort gespeichert werden können, und auf der Grundlage der Fähigkeitsinformation des UE und des GGSN wird eine letztendliche Aufbauentscheidung getroffen. Wenn sowohl das UE als auch der GGSN RSVP-fähig sind, kann die P-CSCF (PCF) die Instanz entscheiden, welche die RSVP-Signalisierung liefern wird. Wenn andererseits der GGSN RSVP-unfähig ist oder einen RSVP-Proxybetrieb nicht unterstützen will, kann die Entscheidung zur Einleitung der RSVP-Signalisierung an das UE weitergeleitet werden. Wenn die P-CSCF bestimmt, dass der GGSN den RSVP-Proxy bereitzustellen hat, weist die P-CSCF das Ursprungs-UE unter Verwendung von SIP an, die RSVP-Signalisierung einzustellen. Eine Entscheidung wird unter Verwendung des Common-Open-Policy-Server-Protokolls (COPS-Protokolls) zum Beginnen des RSVP-Betriebs dann an den GGSN weitergeleitet.
[0009] Das SIP wird auch weiter erfindungsgemäß zur Bereitstellung eines Zulassungsvorgangs unter Verwendung der QoS-Fähigkeiten der Kommunikationsinstanzen zum Bestimmen der Machbarkeit eines erfolgreichen Ergebnisses eines Rufaufbau/Sitzungsaufbauvorgangs verwendet. Das Ursprungs-UE/Netzwerk zeigt das beabsichtigte QoS-Protokoll während eines Rufaufbauvorgangs an. Zusätzlich zeigt dann ein Ziel-UE/Netzwerk bei seiner Antwort über das SIP an, ob es zur Unterstützung eines bestimmten QoS-ProtokolIs fähig ist. Wenn es dazu nicht fähig ist, wird der Anruf mit einer klaren Angabe des Grundes abgewiesen, was dazu beiträgt, die Kosten des Rufaufbaus, die Anzahl von über das Netzwerk geleiteter, zur QoS-Signalisierung verwendeter Nachrichten zu
verringern und eine unrichtige In-Rechnung-Stellung für Dienste auszuschließen, die nicht bereitgestellt werden konnten.
[0010] Eine rationellere Verwendung eines Rufvorgangs (Sitzungsvorgangs) wird durch das Austauschen aller verfügbarer QoS-Fähigkeiten während der Rufaufbauphase erreicht, wodurch ein Szenario ausgeschlossen wird, bei dem ein Anruf (eine Sitzung) erfolgreich zwischen einem RSVP-fähigen UE/Netzwerk und einem unfähigen Netzwerk mit einem UE aufgebaut wird, die dann aufgrund einer fehlenden von der unfähigen Zielseite kommenden, auf die RSVP-Signalisierungsnachrichten erfolgenden Antwort verfällt.
[0011] Eine schnellere Rufaufbauzeit (Sitzungsaufbauzeit) wird durch Freischalten der Policy Control Function (PCF) auf der Zielseite erreicht, wodurch während des Rufaufbaus beim GGSN eine frühe Entscheidung über die RSVP-Sender/Empfänger-Proxyfunktion getroffen wird. Die Entscheidung zur Einsetzung der RSVP-Proxyfunktion beim GGSN wird erst getroffen, nachdem die Rufaufbauphase erfolgreich abgeschlossen wurde und während der RSVP-Signalisierungsphase, insbesondere für die Zielseite der eingeleitet werdenden Sitzung. Außerdem minimiert die Erfindung eine unnötige RSVP-Signalisierung über das Netzwerk sowie über die Luftschnittstelle, wenn sie sie nicht sogar eliminiert, wodurch die Gesamtsystemleistung und -kapazität verbessert wird und solche Fälle auf ein Minimum reduziert werden, bei denen einem Benutzer aufgrund eines erfolgreichen Sitzungsaufbaus Ressourcen in Rechnung gestellt werden, wo jedoch die Sitzung beendet wurde, ohne dass der Dienst ausgeführt wurde.
[0012] Kurzbeschreibung der Zeichnung(en)
[0013] Die vorliegende Erfindung und ihre Aufgaben und Vorteile werden aus einer Betrachtung der folgenden Figuren ersichtlich, bei denen gleiche Elemente durch gleiche Referenznummern bezeichnet wurden. Es zeigt:
[0014] Fig. 1 eine vereinfachte schematische Darstellung, die eine Netzwerkarchitektur und einen grundlegenden Sitzungsaufbauvorgang unter der Verwendung von SIP zeigt;
• ·
[0015] Fig. 2 einen Sitzungsaufbauvorgang zum Nachrichtenaustausch bei der Ursprungs-UMTS-Architektur des in Fig. 1 gezeigten Typs, wobei der Vorgang in größerem Detail gezeigt ist;
[0016] Fig. 3 ein SitzungseinleitungsprotokolKSIPJ-Nachrichteneinladungsformat (INVITE), das derzeit in Verwendung ist;
[0017] Fig. 4 ein erfindungsgemäßes Sltzungsbeschreibungsprotokoll (SDP), das die UE-Fähigkeit integriert, die Proxykonfiguration, die vom UE abgeleitet wurde und die Entscheidung über die Konfigurationseinrichtung durch die P-CSCF (PCF), die vorgesehen werden;
[0018] Fig. 5 ein erfindungsgemäßes Sitzungseinleitungsprotokoll(SIP)-Nachrichteneinladungsformat (INVITE), das von einem UE an eine P-CSCF geschickt wird und Angaben über das Reservierungsprotokoll und die bevorzugte Konfiguration einschließt;
[0019] Fig. 6 ein erfindungsgemäßes Sitzungseinleitungsprotokoll(SIP)-183-Nachrichtenformat von einem Ziel-UE an eine P-CSCF des Zielnetzwerks, das ein Reservierungsprotokoll und eine bevorzugte Konfiguration einschließt;
[0020] Fig. 7 ein erfindungsgemäßes Sitzungseinleitungsprotokoll(SIP)-183-Nachrichtenformat von einer P-CSCF des Ursprungsnetzwerkes an ein Benutzergerät UE des Ursprungsnetzwerkes, das Angaben über das Reservierungsprotokoll und die bevorzugte Konfiguration einschließt;
[0021] Fig. 8 einen Sitzungsaufbauvorgang gemäß derzeitiger Standards, dereinen Medienverhandlungsvorgang veranschaulicht, der während eines anfänglichen Sitzungsaufbaus durchgeführt wird;
[0022] Fig. 9 einen erfindungsgemäßen Sitzungsaufbauvorgang, der dem in Fig. 8 gezeigten ähnlich ist und der Ruf/Sitzungs-Aufbaufähigkeiten unter der Verwendung von SIP einschließt;
• ·
[0023] Fig. 10 ein erfindungsgemäßes Sitzungsbeschreibungsprotokoll (SDP), das eine Reservierungsprotokollfähigkeit und eine bevorzugte Konfigurationsanforderung und Entscheidung einschließt;
[0024] Fig. 11 ein erfindungsgemäßes SIP-Einladungsnachrichtformat (INVITE) von UE (A) an P-CSCF (A), wie in Fig. 8 gezeigt, das eine Reservierungsprotokollfähigkeit und eine bevorzugte Konfiguration einschließt;
[0025] Fig. 12 ein erfindungsgemäßes SIP-Einladungsnachrichtformat von einer P-CSCF (A) an eine S-CSCF (A), das zum Beispiel in Fig. 8 gezeigt ist und ein vorgeschlagenes QoS-Reservierungsprotokoll einschließt;
[0026] Fig. 13 ein erfindungsgemäßes SIP-183-Nachrichtformat von einem Ziel-UE (B) an eine Ziel-P-CSCF (B), wie es in Fig. 8 gezeigt ist, in Reaktion auf die Einladung von der Ursprungs-UE (A), wobei das UE (A) RSVP-fähig ist;
[0027] Fig. 14 ein SlP-183-Nachrichtenformat von einer Ziel-P-CSCF (B) an eine Ziel-S-CSCF (B), das in Fig. 8 gezeigt ist, wobei das UE (B) RSVP-fähig ist;
[0028] Fig. 15 ein SlP-183-Nachrichtenformat von einem Ziel-UE (B) an eine Ziel-P-CSCF (B), das in Fig. 8 gezeigt ist, wobei das UE (B) nicht RSVP-fähig ist und eine RSVP-Proxyfunktion anfordert;
[0029] Fig. 16 ein erfindungsgemäßes SlP-183-Nachrichtenformat von einer Ziel-P-CSCF (B) an eine Ziel-S-CSCF (B) in einer Richtung zur Ursprungs-UE (A) wie es in Fig. 8 gezeigt ist, wobei das UE (B) nicht RSVP-fähig ist und das Netzwerk als ein RSVP-Proxy dient;
[0030] Fig. 17 ein erfindungsgemäßes SIP-823-Nachrichtenformat von einer Ziel-P-CSCF (B) an eine Ziel-S-CSCF (B) zum Ursprungs-UE (A), wie es in Fig. 8 gezeigt ist, wobei weder das UE noch das Netzwerk RSVP-fähig sind;
[0031] Fig. 18 ein erfindungsgemäßes SlP-183-Nachrichtenformat von der Ursprungs-P-CSCF (A) zum Ursprungs-UE (A), wie es in Fig. 8 gezeigt ist, wobei
beide Seiten der angeforderten Sitzung RSVP unterstützen können und der GGSN-Proxy installiert ist; und
[0032] Fig. 19 eine erfindungsgemäße SIP-183-Nachricht von der Ursprungs-P-CSCF (A) an das Ursprungs-UE (A) auch für den Fall, bei dem keine Seite RSVP unterstützt und DiffServ-Protokoll akzeptabel ist.
[0033] Detaillierte Beschreibung der bevorzugten Ausführungsform(en)
[0034] Fig. 1 zeigt eine vereinfachte Übersicht über einen Sitzungsfluss in einer UMTS-Netzwerksarchitektur. Das Netzwerk enthält ein UE (A) und UE (B). UE (A) ist in einem Netzwerk A, das GGSN (A) und P-CSCF (A) enthält, wobei das Netzwerk A entweder das Heimatnetzwerk von UE (A) oder ein Netzwerk sein kann, indem UE
(A) ein Gastteilnehmer ist (Roaming).
[0035] UE (B) ist in einem Netzwerk B mit P-CSCF (B) und GGSN (B). Das Netzwerk B kann entweder ein Heimatnetzwerk von UE (B) oder ein Netzwerk sein, in dem UE
(B) ein Gastteilnehmer ist. Eines oder mehrere andere Netzwerke/CFCSs können zwischen den Netzwerken A und B existieren.
[0036] Der Betrieb eines UMTS-Ruf/Sitzungs-Aufbauvorgangs ist wie folgt:
[0037] Schritt S1: UE (A) beginnt einen Sitzungseinleitungsvorgang an UE (B), der einen SDP-Vorschlag enthält.
[0038] Die Schritte 2-4 sind optional und können von Endgerätimplementierungen und/oder vorkonfigurierten Einstellungen von Endgeräten abhängen. Folglich sind sie gestrichelt dargestellt.
[0039] Schritt S2. Der Benutzer bei UE (B) wird vorher aufmerksam gemacht.
[0040] Schritt S3. Eine Anzeige der vorherigen Aufmerksammachung kann an UE (A) gesendet werden.
[0041] Schritt S4. Der Benutzer bei UE (B) wird dann interagieren und seine/ihre Wünsche bezüglich der aktuellen Sitzung äußern.
• ·
• ·
• ·
[0042] Schritt S5. UE (B) erzeugt auf der Grundlage von Endgeräteinstellungen, vorkonfigurierten Endgerätprofilen und optional den Wünschen des Benutzers ein akzeptiertes SDP.
[0043] Schritt S6. Das akzeptierte SDP wird an das UE (A) in der Nutzlast einer zuverlässigen SIP-Antwort geleitet.
[0044] Schritt S7. Der anfängliche Trägererzeugungsvorgang wird durchgeführt. Während dieses Trägererzeugungsschritts werden die Ressourcen im Zugriffsnetzwerk von UE (A) und UE (B) mit PDP-Kontextprozeduren reserviert. Trägerressourcen in externen Netzwerken können an diesem Punkt ebenfalls reserviert werden.
[0045] Die Schritte 8-10 sind ebenfalls optional und können übersprungen werden und sind daher gestrichelt dargestellt.
[0046] Schritt S8. Das Endgerät bei UE (B) beginnt zu läuten.
[0047] Schritt S9. Die Aufmerksammachungsanzeige wird an UE (A) gesendet.
[0048] Schritt S10. Der Benutzer bei UE (B) kann interagieren und seine/ihre Wünsche bezüglich der aktuellen Sitzung äußern.
[0049] Schritt S11. UE (A) und UE (B) können an diesem Punkt einen Trägermodifikationsvorgang durchführen, wenn die anfänglich in Schritt S7 reservierten Träger und die Wünsche des Benutzers bei UE (B) unterschiedlich sind. Während dieses Trägermodifikationsschritts können die Ressourcen im Zugriffsnetz von UE (A) und UE (B) dadurch modifiziert werden, dass der PDP-Kontext modifiziert wird, und die Ressourcenreservierung im externen Netzwerk kann ebenfalls modifiziert werden.
[0050] Schritt S12. Der Sitzungseinleitungsvorgang wird bestätigt.
[0051] Fig. 2 zeigt den Sitzungsnachrichtenaustauschfluss bei der UMTS-Heimatnetzwerksarchitektur, die aus einem UE, einer P-CSCF und einer S-CSCF besteht und gemäß £xisj;i.e.render Standards aufgebaut ist.
[0052] Bei Schritt S1 sendet das UE eine SIP-Einladung (INVITE) an die P-CSCF des Heimatnetzwerks, wobei diese Einladung dieses Sitzungsbeschreibungsprotokolls (SDP) enthält. Die P-CSCF untersucht die Einladungsbenachrichtigung und leitet sie bei Schritt S2 an die S-CSCF weiter. Die S-CSCF des Heimatnetzwerks untersucht die Einladungsnachricht (INVITE) und übt bei Schritt S3 eine Dienststeuerung aus, erhält den Netzwerkbetreiber, der das angerufene UE bedient und sendet dann die Einladungsnachricht an das Zielnetzwerk des angerufenen UE oder, alternativ dazu, das zwischen dem Heimat- und dem Zielnetzwerk liegende Netzwerk.
[0053] Die Heimatnetzwerk-S-CSCF leitet nach Empfang eines Sitzungsbeschreibungsprotokolls (SDP) vom Zielnetzwerk bei Schritt S5 dieses an das Heimatnetzwerk P-CSCF bei Schritt S6 weiter. Bei Schritt S7 ermächtigt die P-CSCF die QoS-Ressourcen und leitet danach das SDP bei Schritt S8 an das Heimatnetzwerk-UE weiter.
[0054] Bei Schritt S9 erzeugt das Heimatnetzwerk-UE eine letztendliche SDP-Nachricht, in der Sitzungen, ID, Version, Sitzungserzeuger, Zieladresse, Echtzeitprotokoll (RTP), Nutzlasttyp, RTP-Format, Taktrate und Port angibt, gerichtet an die Heimatnetzwerk-P-CSCF, die bei Schritt S10 das letztendliche SDP an S-CSCF des Heimatnetzwerks weiterleitet, die ihrerseits bei Schritt S11 das letztendliche SDP an das Zielnetzwerk oder alternativ dazu das zwischen dem Heimat- und dem Zielnetzwerk liegende Netzwerk weiterleitet.
[0055] Das UE erzeugt bei Schritt S12 eine Ressourcenreservierung, die (hierzu wird mehr Information benötigt) zur Weiterleitung einer Erfolgsnachricht vom UE an die P-CSCF des Heimatnetzwerks bei Schritt S13 führt, von der P-CSCF des Heimatnetzwerks an die S-CSCF des Heimatnetzwerks bei Schritt S14 und von der Heimatnetzwerk-S-CSCF an das Zielnetzwerk oder alternativ dazu ein Zwischennetzwerk bei Schritt S15. Nach der Erstellung der Ressourcenreservierung wird ein Läuten vom Ziel-UE in der Folge an die S-CSCF des Heimatnetzwerks bei Schritt S16 weitergeleitet und bei Schritt S17 von der S-CSCF an die P-CSCF des Heimatnetzwerks weitergeleitet und bei Schritt S18 von der P-CSCF des Heimatnetzwerks an das UE des Heimatnetzwerks weitergeleitet.
• ·
• ·
• ·
[0056] In Beantwortung der Läutanzeige erzeugt das Heimatnetzwerk-UE bei Schritt S19 ein Rückläuten, was dem Ursprungs-UE anzeigt, dass das Ziel läutet.
[0057] Das Zielnetzwerk erzeugt bei Schritt S21 zusätzlich zum Weiterleiten einer Läutanzeige letztendlich an das Heimatnetzwerk-UE bei S20 eine 200-OK-Anzeige an die S-CSCF des Heimatnetzwerks, das eine Dienststeuerung ausübt, die von der Sitzungsaufbauvervollständigung erfordert wird und leitet bei Schritt S22 die 200-OK-Nachricht an die P-CSCF des Heimatnetzwerks weiter, die bei Schritt S23 eine Zustimmung zur Dienstgüteverpflichtung (QoS-commit) liefert und bei Schritt S24 die 200-OK-Nachricht an das Heimatnetzwerk-UE weiterleitet.
[0058] Das Heimatnetzwerk-UE leitet bei Schritt S25 einen Medienfluss ein, der bei Schritt S26 eine Bestätigung (ACK) an die P-CSCF des Heimatnetzwerks sendet, wobei die P-CSCF bei Schritt S27 die Bestätigung an die S-CSCF des Heimatnetzwerks weiterleitet, die ihrerseits bei Schritt S28 die Bestätigung (ACK) an das Zielnetzwerk oder alternativ dazu ein Zwischennetzwerk weiterleitet.
[0059] Fig. 3 zeigt ein SIP-Nachrichtenformat, das gemäß der bestehenden Standards definiert ist und dem, wie noch vollständiger beschrieben wird, Anzeigen eines Reservierungsprotokolls und einer bevorzugten Konfiguration fehlen. Die in Fig. 3 gezeigte SIP-Nachricht enthält eine Anforderung und eine Antwort (erste Zeile), eine Nachrichtenkopfzeile (nächste vierzehn (14) Zeilen) und einen Nachrichtenkörper (verbleibende Zeilen 15-38).
[0060] Fig. 4 zeigt die Zusätze zu bestehenden SIP-Nachrichten, die erfindungsgemäß vorgesehen sind. Die vorgeschlagenen Formate enthalten die Kopfzeile der UE-Fähigkeit und Proxy-Konfiguration bei 10, die UE-Fähigkeit bei 12, die Proxykonfiguration 14, die vom UE erwünscht wird und die Entscheidung über die Konfigurationseinrichtung bei der P-CSCF (PCF) bei 16. Die Verwendung dieser Formate ermöglicht es dem UE, der P-CSCF (PCF) anzuzeigen, ob es RSVP-fähig ist oder nicht, was bei 14 gezeigt ist, sowie den bevorzugten Betriebsmodus, d.h., ob der RSVP-Sender/Empfänger-Proxy bei GGSN bevorzugt wird, was bei 16 gezeigt ist. Das in Fig. 4 gezeigte neuartige Nachrichtenformat ermöglicht es weiter der Heimatnetzwerk-P-CSCF (PCF), dem UE durch direkte Entscheidung die letztendliche Einstellung bekannt zu geben, d.h. dem UE wird eine Nachricht zum
1&Lgr; 1 ~
• t
Beenden der RSVP-Signalisierung gesendet, was anzeigt, dass die RSVP-Proxyfunktion beim GGSN eingesetzt wurde, oder alternativ dazu, mit der RSVP-Signalisierung fortzufahren, was anzeigt, dass kein Proxy verfügbar ist. Das neuartige Nachrichtenformat, das in Fig. 4 gezeigt ist, ermöglicht es weiter dem UE anzuzeigen, welcher Fluss RSVP verwendet, und nicht das Differentiated Services Protocol (DiffServ-Protokoll), was bei 18 gezeigt ist.
[0061] Fig. 5 zeigt eine SIP-Einladungsnachricht (INVITE), die all die zusätzlichen Fähigkeiten der vorliegenden Erfindung einschließt und bei dem UE (A) anzeigt, dass es RSVP-fähig ist, was bei 19 gezeigt ist, und dass ein Proxybetrieb bevorzugt wird, was bei 20 gezeigt ist. Das UE zeigt weiterhin an, dass die Dienstgüte (QoS) für drei unterschiedliche Medienflüsse I, II, III unter Verwendung des RSVP-Protokolls getragen wird, was bei 22, 24, bzw. 26 gezeigt ist, während die QoS im letzten Medienfluss IV von Differentiated Services (DiffServ) getragen wird, wie bei 28 gezeigt ist.
[0062] Fig. 6 zeigt eine SIP-183-Nachricht, welche die SDP-Nachricht vom Ziel-UE ist, die zum Beispiel bei Schritt S5 von Fig. 2 gezeigt ist, bei dem das (nicht gezeigte) Ziel-UE auf die Einladung vom Ursprungs-UE von Fig. 2 antwortet, wobei der P-CSCF mitgeteilt wird, das es RSVP-fähig ist, was bei 30 gezeigt ist, und dass ein RSVP-Proxybetrieb nicht bevorzugt wird, wie bei 32 gezeigt. Das Ziel-UE gibt weiter an, dass ein RSVP-Protokoll auch für die Unterstützung des Medienflusses verwendet wird, wie bei 34 gezeigt. Diese im SIP vorgesehenen Fähigkeiten sind nur zur Konfigurationsverwendung durch das bedienende Netzwerk und haben keinen Einfluss auf andere Instanzen innerhalb der Architektur. Die P-CSCF kann die Proxykonfiguration beim (PC=) Abschnitt der SIP-Nachricht löschen, wie das bei 30 und 32 gezeigt ist, bevor die Nachricht zur nächsten Station weitergeleitet wird, d.h. den nächsten Router, durch den die Nachricht geht.
[0063] Fig. 7 zeigt die SIP 183-Nachricht, die zum Ursprungs-UE durch die Heimatnetzwerk-P-CSCF weitergeleitet wurde und an das UE angibt, dass die Anforderung nach einer RSVP-Proxyfunktion des GGSN gewährt wurde und dass das Ursprungs-UE die RSVP-Signalisierung einstellen sollte, wie bei 36 gezeigt. Diese Nachricht könnte auch auf andere SIP-Nachrichten, wie zum Beispiel SIP-200-OK-Nachrichten unter anderem angewendet werden. Die SIP-183-Nachricht von Fig.
7 bestätigt weiter, dass der Medienfluss unter Verwendung des RSVP-Protokolls getragen wird, wie bei 38 gezeigt.
[0064] Wie oben angegeben, hat die vorliegende Erfindung die weitere Fähigkeit, das Urs &rgr; rung s-U E/Netzwerk dazu zu befähigen, während des Rufaufbauvorgangs ein QoS-Protokoll anzugeben. Dieses Verfahren erfordert weiterhin, dass das Ziel-UE/Netzwerk in einer Antwort angibt, ob es zum Unterstützen des bestimmten QoS-Protokolls fähig ist. In einem Fall, wo das Zielnetzwerk zum Unterstützen des vorgeschlagenen QoS-Protokolls nicht fähig ist, wird der Anruf abgewiesen mit einer klaren Angabe der Ursache, wodurch: die Kosten des Rufaufbaus verringert, die Anzahl von Nachrichten über das Netzwerk zur QoS-Signalisierung verringert und die Möglichkeit einer ungerechtfertigten In-Rechnung-Stellung von Diensten, die nicht geliefert werden können, beseitigt wird.
[0065] Durch Vorsehen eines bestehenden UMTS-Rufaufbaumechanismus, d.h. SIP, ist das Ursprungs-UE fähig, dem Ziel-UE den Typ des für QoS beabsichtigten Protokolls, zum Beispiel RSVP, anzugeben. Der UMTS-Anrufsmechanismus (Sitzungsmechanismus) befähigt das Ziel-UE weiter, dem Ursprungs-UE und dem unterstützenden (bedienenden) Netzwerk anzugeben, ob der vom Ursprungs-UE für QoS vorgeschlagene Protokolltyp, zum Beispiel RSVP, unterstützt wird, und ist außerdem dazu fähig, dem Ursprungsbenutzer und dem bedienenden Netzwerk den Typ des QoS-Protokolls anzugeben, den der Zielbenutzer für den vorgeschlagenen Medientyp unterstützen kann.
[0066] Durch den UMTS-Anrufaufbaumechanismus, d.h. SIP, hat das Zielnetzwerk, d.h. P-CSCF/PCF, aufgrund der vom Zielbenutzer (UE) zurückgegebenen Fähigkeiten und der Netzwerkunterstützung der GGSN-RSVP-Proxyfunktion die Fähigkeit zu entscheiden, ob ein Anrufaufbau fortgesetzt werden kann oder abgebrochen werden soll. Der UMTS-Anruf (die UMTS-Sitzung), d.h. SIP, befähigt die P-CSCF/PCF beim Zielnetzwerk, dem Ursprungsnetzwerk und -benutzer anzugeben, ob das Netzwerk RSVP-basierte QoS unterstützen kann. Der UMTS-Anrufaufbaumechanismus, d.h. SIP, befähigt die P-CSCF/PCF beim Zielnetzwerk, das unterstützte QoS-Protokoll, das durch das Ziel-UE angegeben wurde, zu aktualisieren, d.h. hat die Fähigkeit, das ursprünglich vom Ursprungs-UE vorgeschlagene Protokoll als ein Ergebnis des Einsetzens der RSVP-Funktion
&Igr;&Ogr;" ··* &kgr;*
wiederherzustellen. Der UMTS-Anrufaufbaumechanismus, d.h. SIP, befähigt die GGSN-RSVP-Sender/Empfänger-Proxyfunktion, während eines Rufaufbaus und nicht während der QoS-Reservierungsphase eingesetzt zu werden.
[0067] Der UMTS-Anrufaufbaumechanismus, d.h. SIP, befähigt die P-CSCF/PCF des Ursprungsnetzwerkes, dem Ursprungsbenutzer anzugeben: ob das Zielnetzwerk RSVP-QoS unterstützen kann; ob die RSV-Proxyfunktion bei den GGSN- oder RSVP-basierten Medienflüssen eingesetzt wurde, d.h. ob das UE weiterhin RSVP-Signalisierungsnachrichten senden oder sie beenden sollte. Der UMTS-Anrufaufbaumechanismus, d.h. SIP, befähigt das Ursprungs-UE, den Multimedia-Anruf/Sitzungs-Aufbauvorgang aufgrund der empfangenen Antwort zu beenden, welche über die Fähigkeit des Zielnetzwerks zum Unterstützen des QoS-Protokolls benachrichtigt. Der UMTS-Anrufaufbaumechanismus, d.h. SIP befähigt weiter, das Ursprungs-UE, mit dem Multimedia-Anruf/Sitzungs-Aufbauvorgang fortzufahren, indem das beabsichtigte/vorgeschlagene QoS-Protokoll zum Unterstützen bestimmter Medien auf der Grundlage der empfangenen Antwort über die Fähigkeit des Zielbenutzers eingestellt wird.
[0068] Fig. 8 zeigt ein Kommunikationssystem, bei dem UE #1 in einem Netzwerk angeordnet ist, das P-CSCF #1 und S-CSCF #1 enthält, wobei das Netzwerk das Heimatnetzwerk des UE oder ein Netzwerk sein kann, in welchem das UE #1 Gastteilnehmer ist; und UE #2 in einem Netzwerk, das CSCF #2 und P-CSCF #2 aufweist, wobei das Netzwerk entweder das Heimatnetzwerk von UE #2 oder ein Netzwerk sein kann, in dem UE #2 ein Gastteilnehmer ist. In der in Fig. 2 gezeigten Ausführungsform wird angenommen, dass sowohl das Ursprungs- als auch das Ziel-UE in ihrem Heimatnetzwerk sind, was zum Zweck der Vereinfachung ihrer Beschreibung geschieht, wobei es sich versteht, dass das System im Grunde das gleiche ist, bis auf die Hinzufügung der letztendlichen Übertragung von Nachrichten durch zusätzliche zwischengeschaltete Netzwerke.
[0069] Im hier gegebenen Beispiel bestimmt UE # 1 bei Schritt S1 einen vollständigen Satz von Codecs, die UE #1 für die angeforderte Sitzung unterstützen kann. UE #1 baut ein Sitzungsbeschreibungsprotokoll (SDP) auf, das Bandbreitenanforderungen und Eigenschaften eines jeden Mediums enthält, und teilt lokale Portnummern für jeden möglichen Medienfluss zu. Mehrfache Medienflüsse
können vorgeschlagen werden, und für jeden Medienfluss (M=line und SDP) können mehrere Codecauswahlen angeboten werden. Bei Schritt S2 sendet UE #1 die anfängliche INVITE-Nachricht an P-CSCF #1, die das durch UE #1 aufgebaute SDP enthält. P-CSCF #1 untersucht bei Schritt S3 die Medienparameter und entfernt alle Auswahlen, die der Netzwerkbetreiber auf der Grundlage lokaler Vorschriften nicht auf einem Netzwerk erlaubt, und leitet bei Schritt S4 die INVITE-Nachricht an S-CSCF #1 weiter. S-CSCF #1 untersucht bei Schritt S5 die Medienparameter und entfernt alle Auswahlen, die der Teilnehmer anzufordern keine Berechtigung hat, d.h. Parameter, die der Teilnehmer als Teil der vom Anbieter gebotenen Dienste nicht nachgefragt und bezahlt hat. S-CSCF #1 leitet die INVITE-Nachricht bei Schritt S6 an S-CSCF #2 weiter, die bei Schritt S7 einen Satz unterstützter Codecs auf der Grundlage von Betreibervorschriften in einer im Wesentlichen zum von S-CSCF #1 durchgeführten Schritt S5 ähnlichen Weise verringert, und leitet danach bei Schritt S8 die INVITE-Nachricht an P-CSCF #2 weiter, die in einer von P-CSCF #1 bei Schritt S3 ähnlichen Weise die Medienparameter untersucht und bei Schritt S9 alle Auswahlen entfernt, die der Netzwerkbetreiber aufgrund von lokalen Vorschriften nicht auf dem Netzwerk erlaubt, und sendet bei Schritt S10 die Nachricht an das Ziel-UE #2.
[0070] UE #2 vergleicht die Codecs, die es für die angeforderte Sitzung zu unterstützen fähig ist und bestimmt den im SDP in der INVITE-Nachricht erscheinenden Schnittpunkt. Für jeden Medienfluss, der nicht unterstützt wird, geben UE #2 und SDP Medien (m=line) mit Port=0 ein. Für jeden Medienfluss, der unterstützt wird, fügt UE #2 einen SDP-Eintrag mit einem zugewiesenen Ort und mit den Codecs ein, die mit denjenigen von UE #1 gemeinsam sind, wobei diese Aktivitäten bei Schritt S11 durchgeführt werden. UE #2 gibt die im SDP aufgelisteten gemeinsamen Medienflüsse und Codecs an P-CSCF #2 bei Schritt S12 zurück.
[0071] P-CSCF #2 ermächtigt bei Schritt S13 ein QoS-Ressourcensystem für die verbleibenden Medienflüsse und Codecauswahlen für die gemeinsamen Codecs für die Sitzung und leitet dieses SDP an S-CSCF #2 bei Schritt S14 weiter. S-CSCF #2 leitet bei Schritt S15 die SDP-Nachricht an S-CSCF #1, die bei Schritt S16 die SDP-Nachricht an P-CSCF #1 weiterleitet. P-CSCF #1 ermächtigt bei Schritt S17 die Ressourcen für gemeinsame Codecs für die Sitzung und leitet bei Schritt S18 das
SDP an UE #1. • · · • · · • · ·· ··
··♦··· · 		► &bgr; ·· · ·
• · «
• · &igr;
&bull; · < 		&bull; · &bull; · · · »
&bull; · · · 		&bull; ··· ··
&bull; · · · 		* · · ·
··· · »
» · « ft
&bull; · · I &bull; · · ···· ·· ···· · &bull; · · ·
&bull; ·*·· ■·* as 		O · · ·
[0072] UE #1 bestimmt bei Schritt S19 die anfänglichen Codecs für diese Sitzung und die Medienflüsse, die für diese Sitzung verwendet werden sollten. Wenn es mehr als einen Medienfluss gab oder es mehr als eine Auswahl eines Codecs für einen Medienfluss gab, fügt das UE #1 ein SDP und eine "End-SDP"-Nachricht bei, die an UE #2 durch EU #1 bei Schritt S20 gesendet werden, wobei diese Nachricht weitergeleitet wird, wie bei den Schritten S21 - S24 gezeigt ist.
[0073] UE #2 sendet die "End-SDP"-Nachricht an UE #1 entlang eines durch die INVITE-Nachfrage eingerichteten Signalisierungspfads, wobei der Signalisierungspfad aus Gründen der einfacheren Darstellung weggelassen wurde, wobei es sich versteht, dass der Signalisierungspfad gemäß bestehender Fähigkeiten ist. Die verbleibende Multi-Media-Sitzung wird in Übereinstimmung mit einer Einzel-Codec-Sitzung unter Verwendung herkömmlicher Mittel abgeschlossen.
[0074] Fig. 4 zeigt einen Anrufsfluss (Sitzungsfluss), der die Prinzipien der vorliegenden Erfindung realisiert und bei dem gleiche Schritte der Fig. 8 und 9 mit gleichen Referenznummern bezeichnet sind und bei dem unterschiedliche Schritte durch einen Apostroph gekennzeichnet sind.
[0075] Bei dem in Fig. 9 gezeigten Vorgang bestimmt UE #1 bei Schritt SV zusätzlich zur Bestimmung des vollständigen Satzes von Codecs, die zum Unterstützen der angeforderten Sitzung und zum Aufbauen eines SDP gemäß S1 von Fig. 8 fähig ist, zusätzlich ein unterstützendes QoS-Protokoll, wie zum Beispiel RSVP, DiffServ, ... und so weiter, die UE #1 für diese Sitzung unterstützen kann, wie bei 42 von Fig. 10 gezeigt. Wie beim aktuellen Verfahren von Schritt S1, der in Fig. 8 gezeigt ist, wird das SDP so aufgebaut, dass es Bandbreiteneigenschaften eines jeden Medienflusses sowie die Zuweisung lokaler Portnummern zu jedem möglichen Medienfluss enthält. Mehrere Medienflüsse können angeboten werden, wie in den Zeilen n=SDP zum Beispiel in Fig. 11 gezeigt ist, die zwei Video-Medienflüsse und zwei Audio-Medienflüsse bei 44 und 46 von Fig. 11 zeigt, sowie mehrfache Anrufe. Es sollte jedoch berücksichtigt werden, dass die zwei (2) Audio-Medienflüsse in Fig. 11 jeweils ein anderes QoS-Protokoll haben, von denen eines RSVP und eines DiffServ ist.
&bull; ·· &phgr;··
[0076] UE #1 sendet bei Schritt S2 die oben genannte SDP-INVITE-Nachricht an P-CSCF #1. P-CSCF #1 untersucht bei Schritt S3' die Medienparameter und entfernt alle Auswahlen, die der Netzwerkbetreiber aufgrund lokaler Vorschriften nicht auf dem Netzwerk erlaubt, wie das bei Schritt S3 von Fig. 8 der Fall war. P-CSCF #1 untersucht weiter die RSVP-Fähigkeit von UE #1 sowie seine Bevorzugung des RSVP-Proxybetriebs. P-CSCF #1 leitet diese Information an die Policy Control Function (PCF) weiter, um eine Entscheidung bezüglich einer Netzwerkeinrichtung anzufordern. P-CSCF #1 entfernt den (rc=)-Eintrag, der bei 48 in Fig. 11 gezeigt ist, wobei dieser Eintrag im in Fig. 12 gezeigten SDP weggelassen wurde, und diese SDP-Nachricht (Fig. 12) wird als die INVITE-Nachricht an S-CSCF #1 weitergeleitet, wie in Schritt S4 gezeigt. S-CSCF #1 untersucht bei Schritt S5 die Medienparameter und entfernt alle Auswahlen, die nachzufragen der Teilnehmer keine Berechtigung hat, was dem Schritt S5 in der Ausführungsform von Fig. 8 ähnlich ist, wo nach S-CSCF #1 die INVITE-Nachricht durch die S-S-Sitzungsflussvorgänge durch S-CSCF #2 bei Schritt S6 weiterleitet.
[0077] S-CSCF #2 untersucht ähnlich dem aktuellen Netzwerkverfahren, das in Fig. bei Schritt S7 gezeigt ist, die Medienparameter und entfernt alle Auswahlen, die nachzufragen der Zielteilnehmer keine Berechtigung hat, und leitet bei Schritt S8 die INVITE-Nachricht an P-CSCF #2 weiter.
[0078] P-CSCF #2 führt bei Schritt S91 alle von P-CSCF #2 durchgeführten Funktionen durch, wie in Schritt S9 von Fig. 8 gezeigt ist, indem die Medienparameter untersucht werden und alle entfernt werden, von denen der Netzwerkbetreiber auf der Grundlage lokaler Vorschriften entscheidet, dass sie nicht auf dem Netzwerk erlaubt werden. Zusätzlich hierzu untersucht P-CSCF #2 das in der SDP-Nachricht angebotene QoS-Protokoll vor dem Weiterleiten der Information an PCF zur Entscheidung bezüglich der Unterstützung aller optionaler Funktionalitäten, wie zum Beispiel der GGSN-RSVP-Proxyfunktion. Diese SDP-INVITE-Nachricht wird dann bei Schritt S10 an UE #2 weitergeleitet, wie in Fig. 12 gezeigt.
[0079] UE #2 bestimmt bei Schritt S11' einen vollständigen Satz von Codecs sowie die unterstützenden QoS-Protokolle, wie zum Beispiel RSVP, DiffServ und so weiter, die das UE #2 zum Unterstützen für die Sitzung fähig ist. Ähnlich zu Schritt S11 in
dem in Fig. 8 gezeigten aktuellen Verfahren bestimmt UE #2 den Schnittpunkt mit denjenigen, die im SDP und in der INVITE-Nachricht auftreten. Für jeden Medienfluss, der nicht unterstützt wird, fügt UE #2 einen SDP-Eintrag für Medien ein, d.h. n=line, mit port=0. Für jeden Medienfluss, der unterstützt wird, fügt UE #2 einen SDP-Eintrag mit einem zugewiesenen Port und mit den Codecs ein, die gemeinsam mit denjenigen in der SDP-Nachricht von UE #1 sind. Diese Schritte sind im Wesentlichen identisch zu den Schritten, die als S11 in Fig. 8 gezeigt sind. UE #2 ist weiterhin fähig, P-CSCF #2 anzuzeigen, ob es zum Unterstützen von RSVP fähig ist und ob die RSVP-Sender/Empfänger-Proxyfunktion die bevorzugte Einstellung ist. UE #2 ist ebenfalls fähig, ein anderes QoS-Protokoll in dem Fall vorzuschlagen, dass das Existierende nicht unterstützt wird, wie in den Fig. 13-15 gezeigt. Insbesondere zeigt Fig. 13 ein modifiziertes SIP-183-Nachrichtenformat von UE #2 an P-CSCF in Reaktion zum INVITE von UE #1, wobei die Ausführungsform in Fig. 13 den Fall zeigt, bei dem UE #2 RSVP-fähig ist, wie in Fig. 13 bei 50 gezeigt. Fig. 14 zeigt ein modifiziertes SIP-183-Nachrichtenformat von P-CSCF #2 an S-CSCF in dem Fall, wo UE #2 RSVP-fähig ist. Fig. 15 zeigt ein modifiziertes SIP-183-Nachrichtenformat von UE #2 an P-CSCF #2 in Reaktion auf das INVITE von UE #1 und in dem Fall, wo UE #2 RSVP-fähig ist, wie in Fig. 16 bei 52 gezeigt.
[0080] UE #2 überträgt die SDP-Auflistung, Medienflüsse und Codecs an P-CSCF #2, wie in Fig. 12 bei Schritt S12 gezeigt ist.
[0081] P-CSCF #2 bewilligt bei Schritt S131 die QoS-Ressourcen für die verbleibenden Medienflüsse und Codecauswahlen. P-CSCF #2 untersucht die RSVP-Fähigkeiten von UE #2 und leitet diese Information an PCF für eine Entscheidung sowohl über die RSVP-Proxyfunktion als auch die allgemeine Unterstützung für die vorgeschlagene Sitzung weiter. P-CSCF #2 kann entweder auf der Grundlage einer fehlenden Unterstützung für das vorgeschlagene QoS-Protokoll die Sitzung abweisen oder erlauben, dass die Verhandlungen weitergeführt werden, indem die vorgeschlagenen Änderungen am QoS-Protokoll weitergeleitet werden. Wie bei 52 in Fig. 16 gezeigt, bestimmt in einem Fall, wo UE #2 RSVP-fähig ist, P-CSCF #2 die Netzwerkkonfiguration und leitet eine Anzeige an das Ursprungsnetzwerk weiter, dass RSVP unterstützt wird. In einem Fall, wo UE #2 nicht RSVP-fähig ist und UE #2 angezeigt hat, dass es den vorgeschlagenen Medientyp unter Verwendung eines anderen QoS-Protokolls unterstützen kann, d.h.
HF ■"= HO !O &egr;:; &khgr; &kgr; j \\
DiffServ, während das Netzwerk RSVP-Proxyfunktion unterstützen kann, zeigt Fig. 11 ein SIP-ieS-Nachrichtenformat von UE #2 an P-CSCF #2 in einem Fall, wo UE #2 nicht RSVP-fähig ist und nach einer RSVP-Proxyfunktion verlangt, Fig. 12 ein von P-CSCF #2 an S-CSCF #2 und an UE #1 gerichtetes SIP-183-Nachrichtenformat in einem Fall, wo UE #2 nicht RSVP-fähig ist und das Netzwerk RSVP-fähig ist.
[0082] Weiter ist P-CSCF #2 fähig, die RSVP-Proxyfunktion einzusetzen, die vorgeschlagene QoS, zum Beispiel RSVP, wiederherzustellen und eine Anzeige an das Ursprungsnetzwerk weiterzuleiten, das RSVP unterstützt wird. In einem Beispiel, wo UE #2 und ein bedienendes Netzwerk nicht RSVP-fähig sind, wie bei 54 in Fig. 13 gezeigt, kann P-CSCF #2 sich dafür entscheiden, eine Anzeige an die Ursprungsseite dahingehend weiterzuleiten, dass: RSVP nicht unterstützt wird und der aktuelle von UE #2 gemachte Vorschlag zum Tragen des Medientyps zum Unterstützen eines anderen QoS-Protokolls aufrechterhalten wird; oder die Sitzung einfach auf der Grundlage von Betreibervorschriften abzulehnen. P-CSCF #2 leitet bei Schritt S14 die SDP-Nachricht an S-CSCF #2 weiter. S-CSCF #2 leitet bei Schritt S15 die SDP-Antwort an S-CSCF #1 weiter und S-CSCF #1 leitet bei Schritt S16 die SDP-Antwort an P-CSCF #1 weiter.
[0083] P-CSCF #1 bewilligt bei Schritt S17' die QoS-Ressourcen für die verbleibenden Medienflüsse und Codecauswahlen und untersucht weiterhin RSV-Fähigkeiten des Zielnetzwerkes und leitet diese Information an UE #1 weiter, wie in den Fig. 18 und 19 gezeigt ist. P-CSCF #1 ist außerdem zum Weiterleiten von Entscheidungen überGGSN-RSVP-Proxykonfiguration fähig, d.h., ob die RSVP-Proxyfunktion unterstützt wird. In dem Fall, wo der Proxybetrieb unterstützt wird, wird die "RSVP-Signalisierung beenden" - Nachricht, wie sie in Fig. 18 bei 56 gezeigt, an UE #1 mit der Anzeige gesendet, dass auf der anderen Seite RSVP unterstützt wird, wie in Fig. 18 bei 58 durch die Nachricht "RSVP-fähig" gezeigt. In dem Fall, dass die RSVP-Proxyfunktion nicht unterstützt wird, wird die Nachricht "mit RSVP-Signalisierung fortfahren" als eine Alternative gesendet, wobei diese alternativen Nachrichten in Fig. 18 bei 56 bzw. 58 erscheinen. Wenn die Zielseite nicht RSVP unterstützt, dann wird die Kombination "nicht RSVP-fähig" und "RSVP-Signalisierung beenden" an UE #1 gesendet, damit es für den vorgeschlagenen Medienstrom nicht RSVP verwendet und damit die Proxyfunktion nicht installiert wird. In diesem Fall
&bull; ·
wird die alternative Nachricht "nicht RSVP-fähig" bei 58 in Fig. 18 im gegebenen Beispiel eingefügt.
[0084] Bei Schritt S18 leitet P-CSCF #1 die SDP-Antwort von UE #2 an UE #1 weiter.
[0085] UE #1 bestimmt, welche Medienflüsse für diese Sitzung verwendet werden sollten und welche Codecs für die jeweiligen Medienflüsse verwendet werden sollten. Wenn es mehr als einen Medienfluss gibt oder wenn es mehr als eine Auswahl eines Codecs für den Medienfluss gibt, dann muss UE #1 ein SDP in der "letztendlichen SDP" - Nachricht enthalten, oder alternativ dazu kann UE #1 sich dazu entschließen, die Sitzungseinrichtungsvorgänge abzuschließen, wenn die Medienströme nicht unter Verwendung der vorgeschlagenen QoS-Protokolle geliefert werden können, wobei diese Aktivitäten bei Schritt S191 ausgeführt werden.
[0086] UE #1 sendet die "letztendliche SDP" - Nachricht an UE #2 zusammen mit dem Signalisierungspfad, der durch die INVITE-Anfrage eingerichtet wurde, wie in den Schritten S20 bis S24 gezeigt, wobei diese Schritte den Schritten S20 bis S24 im aktuellen Verfahren ähnlich sind, das im in Fig. 8 gezeigten Anrufsfluss (Sitzungsfluss) verwendet wird. Die restliche Multi-Media-Sitzung wird in einer Weise fertiggestellt, die zur Einzelmedien/Einzelcodec-Sitzung, die oben im Zusammenhang mit dem aktuellen Verfahren bei der Beschreibung von Fig. 8 beschrieben wurde, identisch ist. Das modifizierte Sitzungsbeschreibungsprotokoll für ein in Fig. 10 gezeigtes SDP repräsentiert die von UE #1 an UE #2 gesendete "SDP"-Nachricht.

Claims (14)

1. Netzwerk zum Einrichten einer Kommunikation mit einer mobilen Einheit (UE), wobei die Kommunikation ein Ressourcenreservierungsprotokoll (RSVP) verwendet, das unter Einsatz von Codemultiplex-Vielfachzugriff 2000 (CDMA 2000) an die UE gesendet wurde, wobei:
- das Netzwerk eine Einheit zum Empfangen einer Sitzungseinleitungsprotokollnachricht (SIP-Nachricht) aufweist, um Folgendes anzuzeigen: die RSVP-Fähigkeit der UE; zu übertragende Medientypen, Fähigkeiten und einen bevorzugten Betriebsmodus;
- das Netzwerk weiter eine Proxy-Anrufsstatus-Steuerfunktionseinheit aufweist, die in Reaktion auf das SIP eine Entscheidung darüber trifft, ob das Netzwerk oder das UE eine RSVP-Signalisierung einleiten soll, und
- das Netzwerk eine Einheit zum Senden der Entscheidung des Netzwerks an das UE aufweist.
2. Netzwerk nach Anspruch 1, weiter mit einer Einheit zum Bestimmen, dass die UE keine RSVP-Signalisierung einleiten soll, wenn die UE nicht RSVP-fähig und das Netzwerk RSVP-fähig ist; und
- einer Einheit zum Senden einer Nachricht an die UE, dass sie keine RSVP- Signalisierung einleiten soll.
3. Netzwerk nach Anspruch 1, weiter mit einer Einheit zum Bestimmen, dass die UE eine RSVP-Signalisierung einleiten soll, wenn die UE RSVP-fähig und das Netzwerk RSVP-fähig ist; und
- einer Einheit zum Senden einer Nachricht an die UE, dass sie eine RSVP- Signalisierung einleiten soll.
4. Netzwerk nach Anspruch 1, weiter mit einer Einheit zum Bestimmen, dass die UE keine RSVP-Signalisierung einleiten soll, wenn sowohl die UE als auch das Netzwerk RSVP-fähig sind; und
- einer Einheit zum Senden einer Nachricht an die UE, dass sie keine RSVP- Signalisierung einleiten soll.
5. Netzwerk nach Anspruch 1, weiter mit einer Einheit zum Bestimmen, dass die UE eine RSVP-Signalisierung einleiten soll, wenn sowohl die UE als auch das Netzwerk RSVP-fähig sind; und
- wobei das Netzwerk weiter eine Einheit zum Senden einer Nachricht an die UE aufweist, dass sie eine RSVP-Signalisierung einleiten soll.
6. Netzwerk nach Anspruch 1, weiter mit einer Einheit zum Erhalten einer RSVP- Fähigkeit des Netzwerks aus einem Speicher.
7. Netzwerk nach Anspruch 1, weiter mit einem General Packet Radio Service (GPRS) Gateway Support Node (GGSN),
- wobei die Proxy-Anrufzustandssteuerfunktionseinheit die Fähigkeit des GGSN zum Zuweisen einer Einleitung einer RSVP-Signalisierung erhält.
8. Netzwerk nach Anspruch 1, bei dem die Einheit zum Senden eine Einheit zum Anfordern von der UE zum Einleiten einer RSVP-Signalisierung aufweist, wenn das Netzwerk keine RSVP-Signalisierung einleiten möchte.
9. Netzwerk nach Anspruch 8, bei dem die Einheit zum Senden eine Einheit zum Weiterleiten einer Entscheidung zum Beginnen eines RSVP-Betriebs an den GGSN unter Verwendung eines Common Open Policy Server (COPS)- Protokolls aufweist.
10. System mit einem Ursprungsnetzwerk zur Kommunikation mit einem Ursprungsbenutzergerät (UE) und einem Zielnetzwerk zur Kommunikation mit einem Ziel-UE, wobei die Kommunikationen Codemultiplex-Vielfachzugriff 2000 (CDMA 2000) einsetzen und Dienstgütefähigkeiten (QoS-Fähigkeiten) kommunizierender Instanzen verwenden, um die Machbarkeit eines erfolgreichen Anruf/Sitzungs-Aufbaus zu bestimmen, wobei:
- das Ursprungsnetzwerk eine Einheit zum Einsetzen eines Sitzungseinleitungsprotokolls (SIP) aufweist, um in Reaktion auf einen Anrufaufbauvorgang ein beabsichtigtes QoS-Protokoll anzuzeigen;
- das Zielnetzwerk eine Einheit zum Reagieren auf das SIP hat, wenn es zum Unterstützen der beabsichtigten QoS fähig ist; und
- eine Einheit zum Abweisen des Anrufs, wenn das Ziel-UE/Netzwerk nicht fähig ist.
11. System nach Anspruch 10, bei dem die Einheit zum Abweisen ferner aufweist:
- eine Einheit zum Liefern einer Nachricht, die eine klare Anzeige des Grundes zur Abweisung des Anrufs ist.
12. Netzwerke zur Erleichterung einer Anrufs-/Sitzungs-Einleitungs-Aufbauzeit zwischen einer einleitenden mobilen Einheit (einleitenden UE) und einer mobilen Zieleinheit (Ziel-UE), wobei jede entsprechend einem Einleitungs- und einem Ziel-Heimatnetzwerk zugeordnet ist, welche das gleiche Netzwerk oder unterschiedliche Netzwerke sein können, wobei Kommunikationen zwischen den Netzwerken und den UEs Codemultiplex-Vielfachzugriff 2000 (CDMA 2000) einsetzen, wobei:
- das einleitende Netzwerk eine Einheit zum Empfangen von der einleitenden UE einer Sitzungseinleitungsprotokollnachricht (SIP-Nachricht) hat, die an die Ziel-UE gerichtet ist und Folgendes aufführt: eine Liste zu übertragender Medien, einen bevorzugten Betriebsmodus, eine RSVP-Fähigkeit und die Fähigkeit zum Unterstützen vorgegebener Dienstgütefähigkeiten und zum Senden der SIP-Nachricht an das Zielnetzwerk und
- das Zielnetzwerk eine Einheit zum Treffen einer Entscheidung über eine RSVP-Proxyfunktion in Reaktion auf die empfangene SIP-Nachricht aufweist.
13. System nach Anspruch 12, bei dem das Zielnetzwerk eine Einheit zum Senden an das einleitende Netzwerk eines von der Ziel-UE empfangenen SIP und zum Anfordern einer Alternative zu einer RSVP-Fähigkeit aufweist.
14. System nach Anspruch 13, bei dem das Zielnetzwerk weiter eine Einheit zum Senden an das einleitende Netzwerk eines DiffServ als eine Alternative zu einer RSVP-Fähigkeit aufweist.
DE20212586U 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten Expired - Lifetime DE20212586U1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US31291801P 2001-08-16 2001-08-16
US31292001P 2001-08-16 2001-08-16
US10/217,692 US7227865B2 (en) 2001-08-16 2002-08-13 Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities

Publications (1)

Publication Number Publication Date
DE20212586U1 true DE20212586U1 (de) 2003-02-13

Family

ID=34067772

Family Applications (4)

Application Number Title Priority Date Filing Date
DE20212586U Expired - Lifetime DE20212586U1 (de) 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
DE20212587U Expired - Lifetime DE20212587U1 (de) 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotkolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
DE20212588U Expired - Lifetime DE20212588U1 (de) 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
DE20212589U Expired - Lifetime DE20212589U1 (de) 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten

Family Applications After (3)

Application Number Title Priority Date Filing Date
DE20212587U Expired - Lifetime DE20212587U1 (de) 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotkolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
DE20212588U Expired - Lifetime DE20212588U1 (de) 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
DE20212589U Expired - Lifetime DE20212589U1 (de) 2001-08-16 2002-08-16 Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten

Country Status (8)

Country Link
US (2) US7227865B2 (de)
EP (1) EP1425675A4 (de)
KR (19) KR200309638Y1 (de)
CN (4) CN2566543Y (de)
AU (1) AU2002323232A1 (de)
DE (4) DE20212586U1 (de)
TW (7) TW588892U (de)
WO (1) WO2003017554A2 (de)

Families Citing this family (93)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7227865B2 (en) * 2001-08-16 2007-06-05 Interdigital Technology Corporation Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities
DE50115680D1 (de) * 2001-12-04 2010-12-09 Nokia Siemens Networks Gmbh Verfahren und netzvorrichtung zum bereitstellen von insbesondere personalisierten kommunikationsdiensten in einem kommunikationssystem
WO2003088579A1 (en) * 2002-04-16 2003-10-23 Nokia Corporation Handling a request to establish a packet switched session
US7277455B2 (en) 2002-06-10 2007-10-02 Qualcomm Incorporated Packet flow processing in a communication system
EP1532792B1 (de) * 2002-06-10 2011-10-05 Qualcomm, Incorporated Paketflussverarbeitung in einem kommunikationssystem
US8161158B2 (en) * 2002-09-25 2012-04-17 Nokia Corporation Method in a communication system, a communication system and a communication device
US7391724B2 (en) * 2002-10-09 2008-06-24 Spyder Navigations, L.L.C. System and method with policy control function for multimedia broadcast/multicast system services
US7525994B2 (en) * 2003-01-30 2009-04-28 Avaya Inc. Packet data flow identification for multiplexing
KR101001755B1 (ko) 2003-02-14 2010-12-15 주식회사 케이티 차별화서비스를 위한 정책 생성방법
US7826353B2 (en) * 2003-05-05 2010-11-02 Nokia Corporation Method, system and network element for authorizing a data transmission
DE10322539A1 (de) * 2003-05-19 2004-12-09 Siemens Ag Verfahren zum Aufbau einer Kommunikationsverbindung und Kommunikationssystem
US8223637B2 (en) * 2003-06-17 2012-07-17 Avaya Inc. Quality-of-service and call admission control
US7701915B2 (en) * 2003-06-27 2010-04-20 Nokia Corporation Method in a communication system, a communication system and a communication device
US8139585B1 (en) * 2003-07-10 2012-03-20 Sprint Spectrum L.P. Method and system for controlling sessions from a subscriber terminal
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
GB0324596D0 (en) * 2003-10-21 2003-11-26 Nokia Corp Sessions in a communication system
US8325688B2 (en) * 2003-11-04 2012-12-04 Qualcomm Incorporated Method and apparatus for policy control enhancement in a wireless communication system
CN1934828B (zh) * 2003-11-04 2012-06-20 高通股份有限公司 在无线通信***中用于策略控制增强的方法和装置
CN100433890C (zh) * 2003-12-22 2008-11-12 华为技术有限公司 应用动态业务质量控制的移动数据业务实现方法
US7447211B1 (en) * 2004-03-23 2008-11-04 Avaya Inc. Method and apparatus of establishing a communication channel using protected network resources
US7483385B2 (en) * 2004-03-26 2009-01-27 Hewlett-Packard Development Company, L.P. Process for monitoring the quality of service in a telecommunication network and apparatus for the same
US7542461B2 (en) * 2004-04-19 2009-06-02 Cisco Technology, Inc. Method and apparatus for dynamically determining when to use quality of service reservation in internet media applications
US7574595B2 (en) * 2004-06-22 2009-08-11 Interdigital Technology Corporation Transparent session initiated protocol
US7916700B2 (en) * 2004-06-30 2011-03-29 Nokia Corporation Dynamic service information for the access network
US7680100B1 (en) 2004-09-30 2010-03-16 Avaya Inc. Internet protocol appliance manager
WO2006065025A1 (en) * 2004-12-13 2006-06-22 Electronics And Telecommunications Research Institute Mobile communication system based on ip and session initiation method thereof
US7881294B1 (en) * 2004-12-21 2011-02-01 At&T Intellectual Property Ii, L.P. Method and apparatus for enabling network based media manipulation
KR100789630B1 (ko) 2004-12-23 2007-12-27 주식회사 케이티 호스트 종단 간 서비스 품질을 보장하는 자원관리방법과이를 이용한 세션 설정 방법과 그 시스템
US8194640B2 (en) 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US7796603B1 (en) * 2005-01-14 2010-09-14 Acme Packet, Inc. Method and system for controlling media sessions in networks that use communication protocols with distinct signaling and media channels
US7463634B1 (en) * 2005-02-24 2008-12-09 Sprint Communications Company L.P. Quality correlation testing
CN101159740B (zh) * 2005-03-08 2011-05-04 华为技术有限公司 下一代网络中实现代理请求模式资源预留的方法和装置
KR100910801B1 (ko) * 2005-05-02 2009-08-04 엘지전자 주식회사 Ｓｉｐ 기반의 세션 셋업 방법 및 장치
EP1880556B1 (de) * 2005-05-13 2018-08-01 Nokia Technologies Oy Verfahren und element zur dienststeuerung
FI20055226A0 (fi) * 2005-05-13 2005-05-13 Nokia Corp Menetelmä ja elementti palvelunohjaukseen
US20060285497A1 (en) * 2005-06-20 2006-12-21 Nokia Corporation Method, apparatus and computer program product providing interoperable QoS parameters and signaling thereof in a 3GPP2-3GPP and 3GPP2-3GPP2 conversational multimedia exchange
CN100388714C (zh) * 2005-06-22 2008-05-14 中兴通讯股份有限公司 采用混合路径的端到端服务质量的域间协商方法及***
US7502320B2 (en) * 2005-07-06 2009-03-10 Cisco Technology, Inc. Method and apparatus for network-based admission control using path-coupled quality of service signaling
US8577283B2 (en) 2005-07-15 2013-11-05 Qualcomm Incorporated TDD repeater
US8204064B2 (en) * 2005-09-16 2012-06-19 Acme Packet, Inc. Method and system of session media negotiation
WO2007043180A1 (ja) * 2005-10-14 2007-04-19 Fujitsu Limited アクセスネットワーク選択方法
EP1780973A1 (de) * 2005-10-28 2007-05-02 NTT DoCoMo, Inc. Verfahren und Vorrichtung zum Aufbau von Sitzungen in dynamischen Netzen
US20070133516A1 (en) * 2005-12-14 2007-06-14 General Instrument Corporation Method and apparatus for selecting a codec in a packet-switched communication network
CN1996999B (zh) * 2005-12-31 2010-09-15 华为技术有限公司 一种媒体资源预留方法和设备
CN101682557A (zh) 2006-01-05 2010-03-24 Lg电子株式会社 在移动通信***中发送数据
KR100912784B1 (ko) 2006-01-05 2009-08-18 엘지전자 주식회사 데이터 송신 방법 및 데이터 재전송 방법
BRPI0706353B1 (pt) 2006-01-05 2023-01-24 Interdigital Patent Holdings, Inc Método para alocar recursos de rádio em um sistema de comunicação móvel
KR101265628B1 (ko) 2006-01-05 2013-05-22 엘지전자 주식회사 이동 통신 시스템에서의 무선 자원 스케줄링 방법
KR101187076B1 (ko) 2006-01-05 2012-09-27 엘지전자 주식회사 이동 통신 시스템에 있어서 신호 전송 방법
KR101333918B1 (ko) 2006-01-05 2013-11-27 엘지전자 주식회사 이동 통신 시스템의 점-대-다 서비스 통신
KR101203841B1 (ko) 2006-01-05 2012-11-21 엘지전자 주식회사 무선 통신 시스템에서의 페이징 메시지 전송 및 수신 방법
BRPI0706841A8 (pt) 2006-01-05 2018-04-17 Lg Electronics Inc transmissão de dados em um sistema e comunicação móvel
WO2007078171A2 (en) 2006-01-05 2007-07-12 Lg Electronics Inc. Method of transmitting feedback information in a wireless communication system
KR101211807B1 (ko) 2006-01-05 2012-12-12 엘지전자 주식회사 이동통신 시스템에서 무선단말의 동기상태 관리방법
KR101268200B1 (ko) 2006-01-05 2013-05-27 엘지전자 주식회사 이동통신 시스템에서의 무선자원 할당방법
KR101319870B1 (ko) 2006-01-05 2013-10-18 엘지전자 주식회사 이동 통신 시스템에서의 핸드오버 방법
KR100748514B1 (ko) * 2006-01-13 2007-08-14 엘지전자 주식회사 Ｓｉｐ 기반 세션 서비스의 데이터 처리 방법 및 단말
KR101358469B1 (ko) 2006-02-07 2014-02-06 엘지전자 주식회사 무선 네트워크(ｎｅｔｗｏｒｋ) 안에서 상향(ｕｐｌｉｎｋ)및 하향(ｄｏｗｎｌｉｎｋ) 대역폭(ｂａｎｄｗｉｄｔｈ)의선택 및 신호 방법
KR101216751B1 (ko) 2006-02-07 2012-12-28 엘지전자 주식회사 이동 통신 시스템에서 식별자를 이용한 충돌 회피 방법
US8493854B2 (en) 2006-02-07 2013-07-23 Lg Electronics Inc. Method for avoiding collision using identifier in mobile network
CN101026871A (zh) 2006-02-21 2007-08-29 华为技术有限公司 在会话初始化协议多媒体通信***中处理媒体类型的方法
KR101387475B1 (ko) 2006-03-22 2014-04-22 엘지전자 주식회사 복수의 네트워크 엔터티를 포함하는 이동 통신시스템에서의 데이터 처리 방법
EP1845693B1 (de) * 2006-04-13 2015-09-16 Alcatel Lucent Vorrichtung zur Steuerung des Sitzungsaufbaus
EP1850551B8 (de) * 2006-04-28 2016-11-23 Unify GmbH & Co. KG Verfahren und Vorrichtungen zum Etablieren einer Kommunikation in einem paketorientierten Netzwerk
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
KR20070121513A (ko) 2006-06-21 2007-12-27 엘지전자 주식회사 이동통신 시스템의 상향 접속 방법
KR101369135B1 (ko) 2006-06-21 2014-03-05 엘지전자 주식회사 이동통신 시스템에서의 멀티미디어 및 방송서비스의 품질보장 방법 및 그 단말
WO2007148881A2 (en) 2006-06-21 2007-12-27 Lg Electronics Inc. Method of supporting data retransmission in a mobile communication system
KR20070121505A (ko) 2006-06-21 2007-12-27 엘지전자 주식회사 무선링크 재설정 방법
CN101473565B (zh) 2006-06-21 2012-11-07 Lg电子株式会社 在无线移动通信***中使用消息分离发送和接收无线电接入信息的方法
WO2008001018A2 (fr) * 2006-06-30 2008-01-03 France Telecom Passarelle residentielle
US9137844B2 (en) * 2007-10-04 2015-09-15 Qualcomm Incorporated Method and apparatus for handling user equipment capability information
KR20080037950A (ko) * 2006-10-27 2008-05-02 삼성전자주식회사 데이터를 송수신하는 방법 및 장치
US7953867B1 (en) * 2006-11-08 2011-05-31 Cisco Technology, Inc. Session description protocol (SDP) capability negotiation
CN101198143B (zh) * 2006-12-07 2010-05-12 上海贝尔阿尔卡特股份有限公司 Gsm网络中用于确定交换设备间通信方式的方法和装置
KR101430442B1 (ko) * 2007-01-08 2014-08-14 엘지전자 주식회사 네트워크 기반의 능력 관리를 통한 세션 업데이트 방법 및단말
CN101237389B (zh) * 2007-02-02 2011-11-09 华为技术有限公司 一种实现远程媒体流控制的方法、通信***和设备
US20080298354A1 (en) * 2007-05-31 2008-12-04 Sonus Networks, Inc. Packet Signaling Content Control on a Network
US7962089B1 (en) 2007-07-02 2011-06-14 Rockwell Collins, Inc. Method and system of supporting policy based operations for narrowband tactical radios
US7788383B2 (en) * 2007-10-30 2010-08-31 Cisco Technology, Inc. Communicating a selection of a potential configuration
KR100952707B1 (ko) * 2008-06-05 2010-04-13 주식회사 케이티 종단 간 서비스 품질을 보장하기 위한 리소스 관리 장치, 시스템, 및 방법
US8204505B2 (en) * 2008-06-17 2012-06-19 Qualcomm Incorporated Managing network-initiated quality of service setup in mobile device and network
US9094943B2 (en) * 2008-09-19 2015-07-28 Qualcomm Incorporated Network and mobile device initiated quality of service
KR101022165B1 (ko) * 2008-11-10 2011-03-17 엘지전자 주식회사 능력 정보에 기반한 세션 관리 방법
US20100150144A1 (en) * 2008-12-12 2010-06-17 Bernard Ku Method and apparatus for completing a circuit switched service call in an internet protocol network
US20110310737A1 (en) * 2010-06-21 2011-12-22 Qualcomm Incorporated Method and apparatus for qos context transfer during inter radio access technology handover in a wireless communication system
US8908636B2 (en) 2010-06-21 2014-12-09 Qualcomm Incorporated Method and apparatus for QoS context transfer during inter radio access technology handover in a wireless communication system
US8787172B2 (en) 2010-06-21 2014-07-22 Qualcomm Incorporated Method and apparatus for QoS context transfer during inter radio access technology handover in a wireless communication system
US8984148B2 (en) * 2012-07-23 2015-03-17 Cisco Technology, Inc. Method and apparatus for signaling post-ring reservations
US10469668B1 (en) * 2017-08-30 2019-11-05 Sprint Spectrum L.P. Determining access parameters based on likelihood of HD voice service
CN111985772B (zh) * 2020-07-15 2024-02-20 惠州市德赛西威智能交通技术研究院有限公司 一种评价标准协议的鲁棒性与完整度实现方法
US20230117615A1 (en) * 2021-10-19 2023-04-20 At&T Intellectual Property I, L.P. Api driven subscriber ims registration status changes and ims routing steering

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6021263A (en) 1996-02-16 2000-02-01 Lucent Technologies, Inc. Management of ATM virtual circuits with resources reservation protocol
US6101549A (en) 1996-09-27 2000-08-08 Intel Corporation Proxy-based reservation of network resources
JPH11103303A (ja) * 1997-09-26 1999-04-13 Sony Corp ネットワーク資源予約制御方法および装置、受信端末、送信端末、並びに中継装置
US6058113A (en) 1997-09-30 2000-05-02 Lucent Technologies, Inc. Method for enhancing resource reservation communication
FI974558A (fi) 1997-12-18 1999-06-19 Nokia Mobile Phones Ltd Resurssin varaus liikkuvassa Internet-protokollassa
US6252857B1 (en) 1998-03-04 2001-06-26 At&T Corp. Method and apparatus for provisioned and dynamic quality of service in a communications network
WO2001028160A2 (en) 1999-10-14 2001-04-19 Nortel Networks Limited Establishing a communications session having a quality of service in a communications system
US6366577B1 (en) 1999-11-05 2002-04-02 Mci Worldcom, Inc. Method for providing IP telephony with QoS using end-to-end RSVP signaling
US6434143B1 (en) 1999-11-08 2002-08-13 Mci Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
DE60041240D1 (de) 2000-01-26 2009-02-12 Ericsson Telefon Ab L M Verfahren, Server und Anordnung in einem Kommunikationsnetz
US6257857B1 (en) * 2000-01-31 2001-07-10 Advanced Semiconductor Engineering, Inc. Molding apparatus for flexible substrate based package
US20020119821A1 (en) * 2000-05-12 2002-08-29 Sanjoy Sen System and method for joining a broadband multi-user communication session
US6438114B1 (en) 2001-02-05 2002-08-20 Motorola, Inc. Method and apparatus for enabling multimedia calls using session initiation protocol
US7227865B2 (en) * 2001-08-16 2007-06-05 Interdigital Technology Corporation Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities

Also Published As

Publication number Publication date
TWI260174B (en) 2006-08-11
US20070242677A1 (en) 2007-10-18
KR200309638Y1 (ko) 2003-04-03
KR20040008103A (ko) 2004-01-28
WO2003017554A2 (en) 2003-02-27
KR20070122423A (ko) 2007-12-31
TW588910U (en) 2004-05-21
KR200330746Y1 (ko) 2003-10-22
DE20212587U1 (de) 2003-02-13
KR20040093641A (ko) 2004-11-06
KR200309637Y1 (ko) 2003-04-03
KR20050091643A (ko) 2005-09-15
TW592412U (en) 2004-06-11
EP1425675A4 (de) 2006-06-28
KR20040010459A (ko) 2004-01-31
TWI240583B (en) 2005-09-21
KR200330748Y1 (ko) 2003-10-22
KR100632229B1 (ko) 2006-10-11
KR100613177B1 (ko) 2006-08-18
KR100617339B1 (ko) 2006-08-31
TW200631366A (en) 2006-09-01
AU2002323232A1 (en) 2003-03-03
CN2571078Y (zh) 2003-09-03
CN2565214Y (zh) 2003-08-06
DE20212588U1 (de) 2003-02-06
KR200309639Y1 (ko) 2003-04-03
KR200299674Y1 (ko) 2003-01-06
DE20212589U1 (de) 2003-02-13
KR20040015701A (ko) 2004-02-19
KR200330747Y1 (ko) 2003-10-22
TW588891U (en) 2004-05-21
CN2571079Y (zh) 2003-09-03
EP1425675A2 (de) 2004-06-09
KR20040015700A (ko) 2004-02-19
KR20040093645A (ko) 2004-11-06
US20030035401A1 (en) 2003-02-20
KR20040093646A (ko) 2004-11-06
US7227865B2 (en) 2007-06-05
KR20070098769A (ko) 2007-10-05
TW200421891A (en) 2004-10-16
KR100637774B1 (ko) 2006-10-25
WO2003017554A3 (en) 2003-05-15
KR20080030983A (ko) 2008-04-07
KR20080045091A (ko) 2008-05-22
KR100809515B1 (ko) 2008-03-04
KR100597568B1 (ko) 2006-07-07
CN2566543Y (zh) 2003-08-13
KR100632227B1 (ko) 2006-10-11
TW588892U (en) 2004-05-21

Similar Documents

Publication Publication Date Title
DE20212586U1 (de) Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotokolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
DE60225278T2 (de) Technik zur verbesserung von ansagen in anrufen mit mobilursprung
DE60112480T2 (de) Dienstqualität (QoS) für ein Universales Mobiltelekommunikationssystem (UMTS) mit Unterstützung einer Verhandlung einer einstellbaren Dienstqualität
DE60030858T2 (de) Verfahren und anordnung zur anzeige der speziellen verwendung eines pdp kontexts
DE602004009913T2 (de) Verfahren, system und netzwerkelement zur autorisierung einer datenübertragung
DE69935397T3 (de) Verfahren und Vorrichtung zur Echtzeitdatenübertragung in einem Paketfunknetz
DE60117476T2 (de) Bidirektionales Reservierungsprotokoll
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE60210240T2 (de) Weiterreichen zwischen Mobilfunknetzwerken unterschiedlicher Technologien
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE19847679B4 (de) Verfahren, Mobilfunkgerät und bedienender GPRS-Unterstützungsknoten in Zusammenhang mit einem teilnetzabhängigen Konvergenzprotokoll für ein Mobilfunknetz
DE60127869T2 (de) Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente
DE60035782T2 (de) Verfahren und anordnung zur auswahl einer kanalkodierung und eines interleaving-verfahrens für bestimmte arten von paketdatenverbindungen
DE60037830T2 (de) Dynamische aktualisierung der dienstqualität in einem paketvermittlungsnetz
DE60319602T2 (de) Verfahren zum Senden/Empfangen von Steuerinformationen in einem Mobilkommunikationssystem mit Broadcast/Multicast Diensten
DE602005006095T2 (de) Bereitstellen von Informationen über die Beziehungen individueller Träger für mobile Endgeräte, die einen Multicast- oder Broadcastdienst empfangen
DE69617445T2 (de) Nachrichtenübertragungssystem
DE60130911T2 (de) Verfahren und gerät für die koordinierte verrechnung von diensten in einer multimedia-sitzung
DE69733420T2 (de) Zwischen-vermittlung-signalisierung für dienst-änderungsanfragen während einer verbindung
EP1226692B1 (de) Verfahren zum betreiben eines mobilfunknetzes
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
DE202004019527U1 (de) Unabhängige und effiziente Lieferung von Diensten an drahtlose Vorrichtungen, die fähig sind, mehrere Funkschnittstellen und Netzinfrastrukturen zu unterstützen
DE60225934T2 (de) Verfahren und Vorrichtung für Funkverbindunganpassung
EP1887740A1 (de) Festlegung des Veranlassers für eine Konfiguration oder einen Aufbau einer Zugangsnetzverbindung
DE60225577T2 (de) Setzen des kommunikationsmodus

Legal Events

Date Code Title Description
R207 Utility model specification

Effective date: 20030320

R150 Utility model maintained after payment of first maintenance fee after three years

Effective date: 20050921

R151 Utility model maintained after payment of second maintenance fee after six years

Effective date: 20080911

R152 Utility model maintained after payment of third maintenance fee after eight years

Effective date: 20100927

R071 Expiry of right
R071 Expiry of right