DE60117476T2

DE60117476T2 - Bidirektionales Reservierungsprotokoll

Info

Publication number: DE60117476T2
Application number: DE60117476T
Authority: DE
Inventors: Xiaobao X. Swindon Chen; Mooi Choo Marlboro Chuah
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 2000-05-05
Filing date: 2001-04-23
Publication date: 2006-08-31
Anticipated expiration: 2021-04-24
Also published as: JP2002010364A; CA2340487A1; US6654610B1; CA2340487C; EP1152571B1; DE60117476D1; EP1152571A2; EP1152571A3

Description

Erfindungsgebiet
Die vorliegende Erfindung betrifft allgemein Telekommunikationssysteme und insbesondere Paketdatenprotokolle zur Verwendung in diesen Systemen.
Stand der Technik
In Telekommunikationssystemen der dritten Generation, wie beispielsweise dem UMTS-System (Universal Mobile Telecommunication System), wird eine breite Bandbreite für Dienste wie beispielsweise Daten und Multimedien zusätzlich zur Sprache bereitgestellt. In solchen Systemen ist es wünschenswert, Benutzern eine Fähigkeit zur Herstellung einer erforderlichen Dienstgüte (QoS – Quality of Service) zu bieten. QoS kann jedoch in gewissen Arten von Netzen wie beispielsweise IP-Netzen (Internet Protocol) oder allgemeiner gesagt dem Internet nur dann garantiert werden, wenn Ressourcen reserviert werden.
Gegenwärtig wird ein als Ressourcereservierungsprotokoll (RSVP – Resource Reservation Protocol) bekanntes Ende-Ende-Protokoll benutzt, damit diese und andere Arten von Netzen die erforderlichen Ressourcen zur Bereitstellung einer gewünschten QoS reservieren können. RSVP ist in IETF (Internet Engineering Task Force) RFC2205 Resource Reservation Protocol (RSVP), R. Braden et al., September 1997 beschrieben. 1 zeigt die Funktionsweise von RSVP. Ein sendender Benutzer 10 sendet einem empfangenden Benutzer 12 eine PATH-Nachricht. Die PATH-Nachricht führt Verkehrseigenschaftsinformationen wie beispielsweise gewöhnlich als "TSpecs" bezeichnete Informationen zur Anzeige von Eigenschaften des Verkehrs, der vom sendenden Benutzer 10 zu senden ist. Wenn der empfangende Benutzer 12 die PATH-Nachricht empfängt, sendet er eine RESV-Nachricht, die eine QoS-Anforderung, wie die gewöhnlich als "FlowSpecs" bezeichnete, enthält. In der Praxis können die sendenden und empfangenden Benutzer 10 und 12 entfernt angeordnet sein, so daß die PATH- und RESV-Nachrichten mehrere Knoten eines Netzes durchlaufen. Bei Empfang der beiden Nachrichten durch jeden Knoten trifft er die Entscheidung, ob ausreichende Ressourcen in diesem Knoten reserviert werden können. Wenn dies möglich ist, dann werden die Nachrichten für die PATH-Nachricht zum nächsten Abschnitt und für die RESV-Nachricht zum vorhergehenden Abschnitt weitergegeben. Wenn die RESV-Nachricht den sendenden Benutzer 10 erreicht, beginnt er mit der Übertragung von Daten. Danach werden periodische Auffrischungsnachrichten gesendet, um an jedem Knoten den hergestellten QoS-Zustand aufrechtzuerhalten.
In der am 3. März 2000 im Namen der Erfinder X. Chen et al. eingereichten europäischen Patentanmeldung Nr. EP1130931 mit dem Titel "Resource Reservation in 3G or Future Generation Telecommunication Network" (Ressourcereservierung im Telekommunikationsnetz der dritten Generation oder zukünftigen Generation) sind Verfahren zum Reservieren von Ressourcen in dritten oder zukünftigen Generationen von drahtlosen mobilen Netzen wie beispielsweise dem UMTS beschrieben. Vorteilhafterweise haben die dort beschriebenen Verfahren keinen oder nur minimalen Einfluß auf bestehende Architektur oder QoS-Verfahren und minimieren jeglichen zusätzlichen Zeichengabeverkehr, der mit der Unterstützung von RSVP im UMTS verbunden ist.
Wie in der 1 angezeigt, ist das herkömmliche RSVP ein einseitig gerichtetes QoS-Zeichengabeprotokoll, das eine QoS-Anforderung von einem Verkehrsempfänger zu einem Verkehrssender abgibt. Die über RSVP eingerichtete ausgehandelte QoS gilt nur für den in der Richtung vom Verkehrssender zum Empfänger fließenden Verkehr. Zur Aushandlung des QoS-Erfordernisses für den Verkehr in der entgegengesetzten Richtung muß eine getrennte RSVP-Sitzung eingeleitet werden.
Ein Problem, das bei der Implementierung von RSVP in UMTS und anderen Arten von Systemen entsteht, ist daß diese Systeme im allgemeinen deutlich zwischen QoS für in einer Aufwärtsrichtung von einem mobilen Endgerät (MT – Mobile Terminal) zum Netz fließenden Verkehr und in einer Abwärtsrichtung vom Netz zum MT fließenden Verkehr unterscheiden. Beispielsweise wird eine solche Unterscheidung im Kontext des QoS-Informationselements (IE) des Paketdatenprotokolls (PDP) des UMTS-Standards getroffen.
Eine direkte Erweiterung des bestehenden einseitig gerichteten PDP-Kontexts, um sowohl Aufwärts- als auch Abwärtsverkehr abzudecken, kann zu einem Problem unterschiedlichen Durchlaufs ("Racing") führen. Insbesondere können Benutzer RSVP-Nachrichten zur QoS-Steuerung in der Aufwärtsrichtung unabhängig von entsprechenden, in der Abwärtsrichtung gesendeten RSVP-Nachrichten zur QoS-Steuerung senden. Wenn daher ein gegebenes MT und ein entsprechender GGSN (Gateway GPRS (General Packet Radio Service) Support Node) RSVP-Nachrichten empfangen, müssen unterschiedliche PDP-Kontext-Steuerverfahren für die mit jeder Richtung verbundene RSVP-Sitzung eingeleitet werden. Dies kann einen erfolgreich hergestellten PDP-Kontext in einer Richtung, aber einen fehlgeschlagenen PDP-Kontext in der entgegengesetzten Richtung für eine Sitzung, die reservierte Ressourcen in beiden Richtungen wünscht, zur Folge haben.
Es ist daher offenbar, daß im UMTS oder einer sonstigen Art von Telekommunikationssystem ein Bedarf an einem bidirektionalen PDP-Kontext-Verfahren besteht, das für sowohl Aufwärts- als auch Abwärtsverkehr gilt und das das oben beschriebene Racing-Problem löst.
In Eriksson A: "Real-Time Services over the Internet" (Echtzeitdienste über das Internet) ISS '97 World Telecommunications Congress (International Switching Symposium), Global Network Evolution: Convergence or Collision? (Globale Netzentwicklung: Konvergenz oder Zusammenstoß?), Toronto, 21.–26. September 1997, ISS World Telecommunications Congress (International Switching Symposium), TORONTO, P., Band 2, 21. September 1997 (1997-09-21), Seiten 173–179, XP000704466 ist offenbart, daß ein spezifisch vor der Reservierung von Ressourcen ausgeführtes Protokoll auf Sitzungsebene dazu benutzt wird, Konferenzteilnehmern zu ermöglichen, Übereinstimmung über eine gemeinsame Menge von Fähigkeiten zu erreichen. Auch ist offenbart, ein herkömmliches Ressourcereservierungsprotokoll (RSVP) zum Reservieren von Netzressourcen auf der Vermittlungsschicht zu benutzen, aber nur nachdem das Protokoll auf Sitzungsebene vollständig ist und Parameter wie Bandbreite und Trägerdienstklasse auf der Sitzungsebene vereinbart worden sind.
In WO-A-00 10357 ist ein Verfahren zum Übertragen von Datenpaketen in mehreren Datenflüssen zu/von einer Mobilstation in einem mobilen Kommunikationssystem offenbart. Zum Leiten der Datenpakete wird ein Datenübertragungsweg gebildet. Mehrfache Profile sind dem Datenübertragungsweg zugeordnet, wobei jedes Profil mindestens einen QoS-Parameter (Dienstgüteparameter) umfaßt. Für jeden Fluß oder jedes Datenpaket wird ein Profiletikett bereitgestellt, das eines der mehrfachen Profile anzeigt. Planung und Überwachung der Übertragung von einzelnen Datenpaketen basiert auf mindestens einem QoS-Parameter des durch das dem in Frage stehenden Datenfluß zugeordnete Profiletikett angezeigten Profils.
Kurze Beschreibung der Erfindung
Ein Verfahren, eine Vorrichtung und ein maschinenlesbares Mittel gemäß der Erfindung entsprechen den unabhängigen Ansprüchen. Bevorzugte Ausführungsformen entsprechen den abhängigen Ansprüchen.
Die vorliegende Erfindung bietet bidirektionale PDP-Verfahren (packet data protocol) zur Verwendung in UMTS- und sonstigen Telekommunikationssystemen.
Gemäß der Erfindung wird eine Bestimmung getroffen, ob ein Benutzer Ressourcereservierungen in sowohl einer Aufwärtsrichtung als auch einer Abwärtsrichtung im System erfordert. Wenn der Benutzer die bidirektionale Ressourcereservierung erfordert, wird ein bidirektionales Protokoll zur Herstellung der erforderlichen Ressourcereservierungen implementiert. Das bidirektionale Protokoll integriert Ressourceaushandlungsverfahren für sowohl die Aufwärtsrichtung als auch die Abwärtsrichtung, um sicherzustellen, daß die erforderlichen Ressourcereservierungen für beide Richtungen bereitgestellt werden. Das bidirektionale Protokoll kann ein auf einem RSVP-Ressourceaushandlungsverfahren (Resource Reservation Protocol) basierendes Paketdatenprotokoll (PDP) sein.
Die oben erwähnte Bestimmung, ob der Benutzer bidirektionale Ressourcereservierungen erfordert, können auf einem oder mehreren Markierungsbit basieren, die kennzeichnen, ob der Benutzer Ressourcereservierungen für sowohl die Aufwärts- als auch die Abwärtsrichtung erfordert. Die Markierungsbit können einem QoS-Informationselement (IE) des Systems zugeordnet sein und können dazu benutzt werden, dem Benutzer die Auswahl zwischen Anwendung des bidirektionalen Protokolls und Anwendung eines Einweg-Protokolls zu erlauben.
Beispielsweise kann ein Paar von Markierungsbit benutzt werden, wobei die Werte der Bit anzeigen, ob der Benutzer keine Ressourcereservierungen entweder in der Aufwärtsrichtung oder der Abwärtsrichtung, Ressourcereservierungen nur in der Aufwärtsrichtung, Ressourcereservierungen nur in der Abwärtsrichtung oder Ressourcereservierungen sowohl in der Aufwärts- als auch in der Abwärtsrichtung erfordert. Als weiteres Beispiel kann ein einziges Markierungsbit dazu benutzt werden, für eine gegebene Richtung von Ressourcereservierungserfordernis anzuzeigen, ob das Ressourcereservierungserfordernis mit einem entsprechenden Ressourcereservierungserfordernis in der entgegengesetzten Richtung verkoppelt ist.
Vorteilhafterweise werden durch die bidirektionalen Protokollverfahren der vorliegenden Erfindung Ressourcereservierungen wirkungsvoll für sowohl Aufwärts- als auch Abwärtsverkehr gehandhabt und das der Implementierung von QoS im gegenwärtigen Einweg-PDP-Kontext von UMTS innewohnende Racing-Problem überwunden.
Kurze Beschreibung der Zeichnungen
1 zeigt die Funktionsweise eines Ressourcereservierungsprotokolls (RSVP), das in Verbindung mit der Erfindung benutzt werden kann.
2 ist ein Blockschaltbild eines Telekommunikationssystems, in dem die Erfindung implementiert sein kann.
3A, 3B und 3C zeigen bidirektionale PDP-Kontextverfahren (packet data protocol) gemäß einem ersten Betriebsszenario der Erfindung mit nur am MT (mobile terminal) terminiertem RSVP.
4A, 4B, 5A, 5B, 6A, 6B und 7 zeigen bidirektionale PDP-Kontextverfahren gemäß einem zweiten Betriebsszenario der Erfindung mit am MT und am GGSN (Gateway GPRS (General Packet Radio Service) Support Node) terminiertem RSVP.
Ausführliche Beschreibung der Erfindung
Die Erfindung wird unten in Verbindung mit einem beispielhaften Telekommunikationssystem einer als UMTS-System (Universal Mobile Telecommunication System) bekannten Art dargestellt. Obwohl die Erfindung besonders gut zur Implementierung in einem solchen System geeignet ist, versteht es sich, daß die Verfahren der Erfindung allgemeiner auf andere Arten von Telekommunikationssystemen anwendbar sind.
2 zeigt einen Teil eines UMTS 20, in dem die vorliegende Erfindung implementiert werden könnte. Das UMTS 20 umfaßt ein Kernnetz (CN – Core Network) 22, das durch einen Gateway 24 und einen CN EDGE 26 gebildet wird, und ein UTRAN (UMTS Terrestrial Radio Access Network) 28. Ein mobiles Endgerät (MT – Mobile Terminal) 30 kommuniziert mit dem UTRAN 28 über eine Funkschnittstelle. Es wird angenommen, daß das MT 30 in diesem Beispiel UMTS-spezifisch ist und mit einer Endgeräteeinrichtung (TE – Terminal Equipment) 32 verbunden ist, die nicht-UMTS-spezifische Anwendungen fahren kann. Das Gateway 24 kann mit dem externen Netz 40 kommunizieren.
Es ist zu bemerken, daß jede dargestellte Komponente des UMTS 20 Subkomponenten aufweist, die in der 2 dargestellt, aber hier nicht weiter beschrieben sind. Zusätzliche Einzelheiten hinsichtlich der Funktionsweise des UMTS 20 und seiner Komponenten und Subkomponenten, so wie sie in der 2 dargestellt sind, sind in den vom UMTS-Standard-Ausschuß ausgegebenen UMTS-Standard-Schriften einzusehen: 3GPP: 3G TS 23.060 V3.2.1 (2000-01), Technical Specification Group Services and System Aspects: General Packet Radio Service (GPRS): Service Description (3G TS23.060 Version 3.2.1), und 3G TS23.107 V3.1.1 (2000-02)3GPP – 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects: QoS Concept and Architecture (QoS – Konzept und Architektur). Diese Standards-Schriften werden hier durch Bezugnahme aufgenommen.
Wieder auf das UMTS 20 der 2 Bezugnehmend, umfassen die oben angeführten Subkomponenten Umsetzungselemente, Zulassungs-/Kapazitätssteuerungselemente, UMTS, Lokale, Funk-, UTRA-, CN- und externe Trägerdienst-(BS – Bearer Service)Manager, Netzdienst-(NS – Network Service)Manager und einen Echtzeitträger-(RAB – Real Time Bearer)Manager. Die Bezeichnung "ph" bezieht sich auf physikalisch und die Bezeichnung "Iu" bezeichnet eine in der oben angeführten Schrift 23.060 angegebene Schnittstelle. Wie schon bemerkt, sind diese und andere Elemente des Systems 20 ausführlicher in den UMTS-Standards-Schriften beschrieben.
Die vorliegende Erfindung bietet eine Anzahl unterschiedlicher Verfahren zur Implementierung eines bidirektionalen PDP-Kontexts (Packet Data Protocol) für bidirektionale QoS-Aushandlung und -Steuerung im UMTS 20. Diese Verfahren werden ausführlich unten unter Bezugnahme auf 3A bis 7 beschrieben. In diesen Figuren wird der CN EDGE 26 als SGSN (Serving GPRS Support Node) bezeichnet und das Gateway 24 wird als GGSN (Gateway GPRS Support Node) bezeichnet.
Der Deutlichkeit und Einfachheit der Darstellung in den 3A bis 7 halber werden einige Grundannahmen getroffen:

1. Es ist ein primärer bzw. Vorgabe-PDP-Kontext für MT hergestellt.
2. Es ist kein aktiver sekundärer PDP-Kontext für die bestehende RSVP-Sitzung hergestellt.

Auch ist zu bemerken, daß die nachfolgende Beschreibung auch Fälle darstellt, in denen ein aktiver sekundärer PDP-Kontext für einen bidirektionalen PDP-Kontext hergestellt worden ist, der noch nicht vollständige QoS-Informationen für beide Richtungen enthält.
Der Begriff "ausstehende PDP-Kontext-Transaktion" wird hier zur Bezeichnung eines unfertigen Verfahrens Create PDP Request (PDP-Anforderung erstellen), Activate PDP Request (PDP-Anforderung aktivieren) oder Update PDP Request (PDP-Anforderung aktualisieren) benutzt. Ein bidirektionaler PDP-Kontext ohne ein vollständiges QoS-Erfordernis wird als unvollständiger bidirektionaler PDP-Kontext bezeichnet.
Die bidirektionalen PDP-Kontextverfahren der vorliegenden Erfindung werden unter Verwendung von zwei Szenarios dargestellt, wobei ein erstes Szenario nur am MT terminiertes RSVP umfaßt und ein zweites Szenario ein am MT und GGSN terminiertes RSVP umfaßt.
Szenario 1: nur am MT terminiertes RSVP
Für dieses Szenario wird davon ausgegangen, daß nur TE 32 und MT 30 RSVP-Zeichengabenachrichten erzeugen. Der Host im externen Netz 40 benutzt andere Zeichengabemechanismen, um den GGSN über sein Abwärts-QoS-Erfordernis zu informieren und daß dieses Abwärts-QoS-Erfordernis zum MT weiterzuleiten ist.
3A zeigt dieses Szenario für Aufwärts-QoS. Von MT wird die erstmalige PATH-Nachricht terminiert und eine Nachricht Activate Secondary PDP Context Request (Sekundäre PDP-Kontextanforderung aktivieren) mit entsprechender Aufwärts-QoS ("abc") zum SGSN erzeugt, der wiederum eine Nachricht Create Secondary PDP Context Request (Sekundäre PDP-Kontextanforderung erstellen) zum GGSN erzeugt. Man beachte, daß an dieser Stelle die Abwärts-QoS auf "Null" gesetzt ist. Es wird ein Verfahren Modify Secondary PDP Context (Sekundären PDP-Kontext abändern) aktiviert, wenn eine nachfolgende Auffrischungs-PATH-Nachricht unterschiedliche QoS- oder Verkehrsspezifikationen bietet. In diesem Szenario werden Auffrischungs-RESV-Nachrichten erstellt, die die neue ausgehandelte Aufwärts-QoS ("a'b'c'") führen, und als Antwort zur TE gesendet.
3B und 3C zeigen zwei unterschiedliche Ansätze für die Abwärts-QoS in diesen Szenario. Es wird für beide Ansätze davon ausgegangen, daß ein sekundärer PDP-Kontext besteht. In diesen beiden Ansätzen ist die Aufwärts-QoS auf die bestehenden "a'b'c'" gesetzt und die anfänglich angeforderte Abwärts-QoS ist auf "efg" gesetzt. Die sich ergebende neue ausgehandelte Abwärts-QoS ist "e'f'g'".
Bei dem in 3B dargestellten ersten Ansatz versucht MT vor Erzeugen der PATH-Nachricht zur TE einen sekundären PDP-Kontext herzustellen. Man beachte, daß angenommen wird, daß die vom Netz eingeleitete PDU-Benachrichtigung (Protocol Data Unit) Abwärts-QoS-Parameter zum MT führt. Das Verfahren Modify Secondary PDP Context (Sekundären PDP-Kontext abändern) muß möglicherweise zum Aktualisieren der Abwärts-QoS für die folgenden drei Zustände benutzt werden:

(a) die erstmalige RESV-Nachricht von der TE führt unterschiedliche QoS-Spezifikationen;
(b) die Auffrischungs-RSVP-Nachrichten führen andere QoS-Spezifikationen, und
(c) die Anforderung/Abwärts-QoS ändern/aktualisieren wird von der entfernten Seite entsprechend der "vom Netz angeforderte PDP-Nachricht" eingeleitet.

Bei dem zweiten, in 3C dargestellten Ansatz aktiviert das MT den sekundären PDP-Kontext nur nach Empfang von RESV-Nachrichten von TE. Das Verfahren sekundären PDP-Kontext abändern wird nur in den folgenden zwei Zuständen benutzt:

(a) die Auffrischungs-RSVP-Nachricht führt unterschiedliche QoS-Spezifikationen; und
(b) die Anforderung Abwärts-QoS ändern/aktualisieren wird von der entfernten Seite entsprechend der "vom Netz angeforderte PDP-Nachricht" eingeleitet.

Dem Fachmann wird offenbar sein, daß ein geeignetes Verfahren zur Verwendung, wenn kein sekundärer PDP-Kontext besteht und PDU-Benachrichtigung das Herstellen eines sekundären PDP-Kontexts auslöst, ganz einfach aus den Diagrammen der 3B und 3C erzeugt werden kann.
Szenario 2: am MT und GGSN terminiertes RSVP
Es werden unten vier verschiedene Ansätze zur Verwendung im Szenario 2 beschrieben. Ein erster Ansatz wird in Verbindung mit 4A und 4B, ein zweiter Ansatz in Verbindung mit 5A und 5B, ein dritter Ansatz in Verbindung mit 6A und 6B und ein vierter Ansatz in Verbindung mit 7 beschrieben.
Für alle diese Ansätze kann der GGSN eine vom Netz eingeleitete Anforderung eines sekundären PDP-Kontexts über die PDU-Benachrichtigungs-Anforderungsnachricht durchführen, um die PDU weiterzuleiten, die das Abwärts-QoS-Erfordernis enthält. Empfang einer PDU-Benachrichtigung am SGSN aktiviert diesen zum Senden einer Nachricht PDP-Kontextaktivierung anfordern zum MT. Der Empfang einer solchen Nachricht PDP- Kontextaktivierung anfordern bewirkt beim MT die Einleitung einer Nachricht sekundäre PDP-Kontextanforderung aktivieren, wenn kein sekundärer PDP-Kontext besteht.
Im ersten Ansatz des Szenarios 2 wird durch eine erstmalige PATH-Nachricht ein Verfahren 2. PDP-Kontext aktivieren ausgelöst. Bei diesem Ansatz werden die PATH- und RESV-Nachrichten von sowohl MT als auch GGSN abgefangen, die die Nachrichten verarbeiten, um zu bestimmen, ob die Nachrichten erstmalige Nachrichten oder Auffrischungsnachrichten sind. Für Auffrischungsnachrichten werden sowohl MT als auch GGSN in der Lage sein, festzustellen, ob sich die QoS-Parameter von den bestehenden QoS-Erfordernissen ändern, die als Teil eines bidirektionalen PDP-Kontexts gespeichert sind.
Für das MT wird der Empfang einer erstmaligen PATH-Nachricht von der TE ein Verfahren sekundären PDP-Kontext aktivieren auslösen, wenn kein sekundärer PDP-Kontext besteht. Wenn ein unvollständiger bidirektionaler PDP-Kontext besteht, dann wird ein Verfahren PDP-Kontextanforderung aktualisieren durchgeführt, wenn keine ausstehende PDP-Kontexttransaktion vorliegt. Nachfolgende Ankunft von Auffrischungs-PATH-Nachrichten am MT von der TE werden nur dann weitergeleitet oder als Huckepackinformationen geführt, wenn Änderungen vorliegen.
Für das MT wird der Empfang einer erstmaligen RESV von der TE ein Verfahren PDP-Kontext aktualisieren auslösen, wenn ein unvollständiger bidirektionaler PDP-Kontext besteht. Nachfolgende Ankunft von Auffrischungs-RESV-Nachrichten von der TE wird das Verfahren PDP-Kontext aktualisieren nur dann auslösen, wenn sich die in diesen Nachrichten enthaltenen QoS-Parameter von den bestehenden QoS-Parametern in einem bidirektionalen PDP-Kontext unterscheiden. Bei Empfang einer Nachricht PDP-Kontextaktivierung anfordern mit QoS-Informationen vom SGSN wird ein Verfahren 2. PDP-Kontext aktivieren eingeleitet, wenn kein sekundärer PDP-Kontext vorliegt.
Für den GGSN wird eine erstmalige PATH-Nachricht vom externen Netz immer transparent zum MT weitergeleitet. Wenn jedoch der GGSN wahrnimmt, daß es für diese RSVP-Sitzung keinen sekundären PDP-Kontext gibt, wird er die Netz-PDU-Benachrichtigung zum MT auslösen. Wenn das MT eine solche Benachrichtigung empfängt, kann das MT ein Verfahren 2. PDP-Kontextanforderung aktivieren einleiten. Wenn ein unvollständiger bidirektionaler sekundärer PDP-Kontext vorliegt und es keine ausstehende PDP-Kontexttransaktion gibt, dann wird ein Verfahren PDP-Kontext aktualisieren aktiviert. Wenn ein unvollständiger bidirektionaler sekundärer PDP-Kontext bereits vorliegt und ein Verfahren PDP-Kontext aktualisieren stattfindet, dann wird GGSN nicht noch einen anderen PDP-Kontext aktualisieren einleiten und sich stattdessen darauf verlassen, daß das MT die Korrektur für Abwärts-QoS durchführt, wenn das MT die erstmalige RESV-Nachricht von der TE empfängt. Nachfolgende Auffrischungs-PATH-Nachrichten werden nur dann durch den GGSN weitergeleitet, wenn sie QoS-Parameter enthalten, die sich von den bestehenden QoS-Parametern in einem bidirektionalen PDP-Kontext unterscheiden. Für den GGSN wird die erstmalige, vom externen Netz empfangene RESV-Nachricht ein Verfahren PDP-Kontext aktualisieren auslösen. Nachfolgende Auffrischungs-RESV-Nachrichten vom externen Netz werden nur dann ein Verfahren PDP-Kontext aktualisieren auslösen, wenn eine Änderung der QoS-Erfordernisse vorliegt.
4A zeigt ausführlicher das oben beschriebene Verfahren zum Herstellen eines bidirektionalen PDP-Kontexts:

(1a) die Ankunft der erstmaligen PATH-Nachricht von der TE bewirkt beim MT die Erzeugung einer Nachricht sekundäre PDP-Kontextanforderung aktivieren zum SGSN mit angeforderten Aufwärts-QoS-Parametern, die aus den QoS-Informationen in der PATH-Nachricht entnommen werden.
(1b) Der SGSN löst dann eine Nachricht sekundäre PDP-Kontextanforderung erstellen zum GGSN aus.
(2a) Der GGSN erzeugt eine Antwort sekundären PDP-Kontext erstellen mit ausgehandelten Aufwärts-QoS-Parametern (die sich von der angeforderten Aufwärts-QoS unterscheiden können) zum SGSN. Sowohl SGSN als auch GGSN können sitzungsbezogene Informationen speichern, z.B. IP-Ursprungs- und Zieladressen für Aufwärts- und Abwärtsrichtungen, Ursprungs- und Zielanschlußnummern usw. als Teil des Zustandes eines bidirektionalen PDP-Kontexts.
(2b) Der SGSN erzeugt dann eine Nachricht Activate Secondary PDP Context Accept (Annahme sekundärer PDP-Kontext aktivieren) zum MT.
(3a) Mittlerweile wird die erstmalige RESV am GGSN empfangen. Vom GGSN wird ein Verfahren Update PDP Context Request (Anforderung PDP-Kontext aktualisieren) zum Aktualisieren der ausgehandelten Aufwärts-QoS ausgelöst, wenn sich die QoS-Anforderung in der RESV von der unterscheidet, die er bereits besitzt.
(3b) Diese Nachricht Update PDP Context Request wird vom SGSN zum MT weitergeleitet.
(3c) Vom MT wird eine Update PDP Context Response (Antwort PDP-Kontext aktualisieren) zum SGSN erzeugt.
(3d) Vom SGSN wird diese Nachricht zum GGSN weitergeleitet.
(4) Angenommen, daß mittlerweile eine erstmalige PATH-Nachricht, die ein Abwärts-QoS-Erfordernis enthält, am GGSN ankommt. Vom GGSN wird keine QoS-Anforderung abgeändert, sondern diese erstmalige PATH-Nachricht einfach als Trägerdaten behandelt, die dem MT zugeliefert werden müssen.
(5a) Wenn das MT die erstmalige RESV empfängt, die das Abwärts-QoS-Erfordernis führt, wird von ihm ein Verfahren Update PDP Context Request (Anforderung PDP-Kontext aktualisieren) mit SGSN eingeleitet.
(5b) Diese Nachricht wird vom SGSN zum GGSN weitergeleitet.
(6a)–(6b) Vom GGSN wird eine Update PDP Context Response (Antwort PDP-Kontext aktualisieren) mit der zutreffenden ausgehandelten Abwärts-QoS zum SGSN erzeugt, der sie zum MT weiterleitet.
(7a)–(7b) Wenn eine Auffrischungs-PATH-Nachricht empfangen wird, wird sie vom MT nur bei einer Änderung weitergeleitet. Auf ähnliche Weise wird, wenn der GGSN eine Auffrischungs-RESV-Nachricht empfängt, vom GGSN eine Update PDP Context Request mit abgeänderten Aufwärts-QoS-Parametern, z.B. "hlm", nur dann ausgelöst, wenn die Auffrischungs-RESV-Nachricht Änderungen der Aufwärts-QoS-Erfordernisse enthält. Es wird die entsprechende Antwort Update PDP Context (PDP-Kontext aktualisieren)(8a)–(8b) erzeugt.
(9a)–(9b) Auf ähnliche Weise werden, wenn Auffrischungs-PATH-Nachrichten vom GGSN empfangen werden, diese nur bei einer Änderung weitergeleitet. Wenn eine Auffrischung-RESV am MT empfangen wird, wird sie nur bei einer Änderung weitergeleitet. Vom MT wird auch eine Update PDP Context Request mit abgeänderten Abwärts-QoS-Parametern, z.B. "svw" immer dann ausgelöst, wenn eine Änderung des Abwärts-QoS-Erfordernisses in der Auffrischungs-RESV-Nachricht vorliegt. Die Update PDP Context Response wird vom GGSN erzeugt (10a) und vom SGSN zum MT weitergeleitet (10b).

4B zeigt den ersten Ansatz des Szenarios 2, wenn die PDU-Benachrichtigungsanforderung zuerst vorkommt. Man beachte, daß bei diesem Beispiel, wenn eine erstmalige PATH-Nachricht von der TE (3) nach Einleitung des Verfahrens Update PDP Context Request ankommt (5a), dann muß ein weiteres Verfahren Modify PDP Context nach Beendigung des Verfahrens (5a) aktiviert werden. Man beachte, daß dies bedeutet, daß die erstmalige RESV (4) nicht rechtzeitig ankommt, daß ihre Informationen in (6a) eingeschlossen werden. Auf ähnliche Weise muß, wenn die erstmalige RESV vom externen Netz später als die durch GGSN erzeugte Update PDP Context Response (6a) ankommt, ein noch weiteres Verfahren Update PDP Context durchgeführt werden. So werden in einem Szenario des schlimmsten Falls ein Verfahren Activate und drei Verfahren Update oder Modify PDP Context erforderlich sein. Im allgemeinen erfordert dieser Ansatz mindestens ein Verfahren Activate und zwei Verfahren Update oder Modify PDP Context, um die Herstellung eines bidirektionalen PDP-Kontexts zu beenden. Beispielhafte, im Ansatz der 4B gezeigte QoS-Parameter umfassen "klm" und "k'l'm'", "hlj" und "h'l'j'" und "svw" und "s'v'w'".
Man beachte, daß in diesem Szenario nicht angenommen wird, daß MT oder GGSN auf erstmalige PATH- oder RESV-Nachrichten warten, um die UMTS-PDP-Kontext Zeichengabenachrichten auszulösen. Es wird jedoch angenommen, daß SGSN und GGSN Zustandsinformationen bewahren, damit sie wissen können, ob eine Nachricht eine erstmalige PATH- oder RESV-Nachricht ist und ob ein neuer bidirektionaler PDP-Kontext hergestellt werden muß.
Der zweite Ansatz des Szenarios 2, der in Verbindung mit 5A und 5B dargestellt wird, unterscheidet sich vom ersten Ansatz des Szenarios 2, indem vom MT eine Anforderung 2. PDP-Kontext aktivieren nur nach Empfang der erstmaligen RESV-Nachricht entweder für Abwärts- oder Aufwärtsverkehr eingeleitet wird.
Wenn vom MT die erstmalige RESV-Nachricht von der TE für Abwärtsverkehr empfangen wird, wird sie eine Activate 2nd PDP Context Request (Anforderung 2. PDP-Kontext aktivieren) einleiten, wenn keine vorliegt. Für nachfolgende, durch das MT von TE empfangene Auffrischungs-RESV-Nachrichten werden nur diejenigen, die Änderungen der QoS-Erfordernisse enthalten, eine Update PDP Context Request auslösen.
Für die erstmalige PATH-Nachricht wird MT sie transparent zum GGSN überführen. Für nachfolgende Auffrischungs-PATH-Nachrichten wird MT nur weiterleiten, wenn es Änderungen bei Aufwärts-QoS-Parametern gibt. Wenn der GGSN eine erstmalige PATH-Nachricht vom externen Netz empfängt, transportiert er das Paket transparent über das UMTS-Netz zum MT. Für nachfolgende PATH-Nachrichten wird der GGSN nur dann weiterleiten, wenn irgendwelche Änderungen der Abwärts-QoS-Parameter vorliegen. Wenn der GGSN eine erstmalige RESV-Nachricht für Aufwärtsverkehr vom externen Netz empfängt, wird er ein Verfahren Update PDP Context einleiten, wenn kein anderes Verfahren Activate oder Update PDP Context für die gleiche Sitzung stattfindet. Ansonsten können die Informationen in der erstmaligen RESV zum Aktualisieren des Abwärts-QoS-Informationselements (IE) in der Nachricht Activate PDP Context Accept (Annahme PDP Kontext aktivieren) benutzt werden. Vom GGSN wird nur die erstmalige, vom MT für Abwärts-QoS empfangene RESV-Nachricht weitergeleitet. Für nachfolgende Auffrischungs-RESV-Nachrichten vom externenen Netz zum GGSN wird das Verfahren Update PDP Kontext nur dann ausgelöst, wenn eine Änderung der Aufwärts-QoS-Erfordernisse vorliegt. Für diejenigen, vom GGSN vom MT empfangenen RESV-Nachrichten, die Abwärts-QoS-Erfordernisse führen, werden sie vom GGSN einfach zum externen Netz weitergeleitet.
5A zeigt den oben beschriebenen zweiten Ansatz des Szenarios 2 für den Fall, wo eine erstmalige PATH- Nachricht zuerst am MT ankommt. Vom MT wird die Activate 2nd PDP Context Request nur nach Empfang der erstmaligen RESV von der TE eingeleitet.
5B zeigt den oben beschriebenen zweiten Ansatz des Szenarios 2 für den Fall, wo durch eine erstmalige PATH-Nachricht am GGSN die PDU-Benachrichtigung ausgelöst wird. In diesem Fall wird die erstmalige PATH-Nachricht vom externen Host unter Verwendung des bestehenden primären PDP-Kontexts transparent zur TE geführt.
Das in 5B dargestellte Verfahren ist wie folgt:

(1a) Wenn das MT eine erstmalige RESV von der TE empfängt, löst sie eine Nachricht Activate Secondary PDP Context Request (Anforderung sekundären PDP-Kontext aktivieren) aus, wobei die Abwärts-QoS-Parameter aus der erstmaligen RESV-Nachricht zum SGSN abgeleitet werden.
(1b) Vom SGSN wird dann die Nachricht Create Secondary PDP Context Request (Anforderung sekundären PDP-Kontext erstellen) zum GGSN gesendet.
(2a)–(2b) Vom GGSN wird eine ausgehandelte Abwärts-QoS-Parameter enthaltende Nachricht Create Secondary PDP Context Response (Antwort sekundären PDP-Kontext erstellen) zum SGSN erzeugt, der sie dann zum MT weiterleitet.
(3) Die erstmalige PATH-Nachricht wird am MT empfangen und transparent über das UMTS-Netz zum externen Host transportiert.
(4) Erstmalige RESV wird am GGSN empfangen.
(5a)–(5b) Vom GGSN wird eine Update PDP Context Request mit aus der erstmaligen RESV-Nachricht abgelei teten Aufwärts-QoS-Parametern zum SGSN ausgelöst, der sie zum MT weiterleitet.
(6a)–(6b) Vom MT wird eine Modify PDP Context Response (Antwort PDP-Kontext abändern) mit abgeänderten Aufwärts-QoS-Parametern zum SGSN erzeugt, der sie zum GGSN weiterleitet.
(7)–(8) Die Auffrischungs-PATH-Nachricht wird nur bei Änderungen vom MT zum GGSN weitergeleitet. Auf ähnliche Weise wird nur eine am GGSN empfangene Auffrischungs-RESV-Nachricht mit Änderungen das Verfahren Update PDP Context am GGSN zum Ändern der Aufwärts-QoS-Erfordernisse auslösen.
(9a)–(9b) Zeigt die vom Netz eingeleitete Update PDP Context Request vom GGSN zum SGSN und vom SGSN zum MT.
(10a)–(10b) Zeigt die entsprechende Rückantwort vom MT zum SGSN und dann zum GGSN.

Bei dem in 5A und 5B dargestellten Ansatz wartet das MT vor Einleitung des Verfahrens Activate oder Update Secondary PDP Context auf eine erstmalige RESV. Es ist daher zum Vervollständigen einer bidirektionalen PDP-Kontext-Herstellung nur ein Activate-Verfahren und ein Update PDP Context-Verfahren erforderlich. Das Warten auf die Ankunft der erstmaligen RESV-Nachricht kann jedoch eine größere Latenzzeit zum Herstellen eines bidirektionalen PDP-Kontexts bewirken.
In 6A und 6B ist der dritte Ansatz des Szenarios 2 dargestellt und umfaßt eine durch PATH ausgelöste Activate 2nd PDP Request mit verzögerter PDP-Antwort. Dieser Ansatz unterscheidet sich vom ersten Ansatz des Szenarios 2, indem der andere PDP-Kontext-Partner auf eine erstmalige RESV-Nachricht wartet, ehe er auf die Nachricht PDP Context Request vom sendenden Partner antwortet. Er unterscheidet sich vom zweiten Ansatz des Szenarios 2, indem das Verfahren Activate PDP Context Request durch die erstmalige PATH-Nachricht und nicht die erstmalige RESV ausgelöst wird.
Für das MT wird der Empfang der erstmaligen PATH-Nachricht (Aufwärts-QoS) von der TE eine Nachricht Activate Secondary PDP Context Request zum SGSN auslösen. Nachfolgende PATH Nachrichten von der TE werden nur unter der Voraussetzung weitergeleitet, daß Änderungen an den QoS-Parametern vorliegen. Wenn das MT die erstmalige RESV-Nachricht (Abwärts-QoS) von der TE empfängt, wird sie eine Update PDP Context Request auslösen, vorausgesetzt, es gibt keine ausstehende PDP-Kontexttransaktion für die gleiche Sitzung und es besteht ein unvollständiger bidirektionaler PDP-Kontext. Wenn es eine ausstehende PDP-Kontextanforderung gibt, die eine Antwort benötigt, erzeugt das MT eine Antwort. Nachfolgende Auffrischungs-RESV-Nachrichten (Abwärts-QoS) von der TE werden nur dann weitergeleitet und Update PDP Context Requestverfahren auslösen, wenn Änderungen der QoS-Erfordernisse vorliegen.
Für GGSN wird der Empfang der erstmaligen RESV-Nachricht (Aufwärts-QoS) vom externen Netz die Create PDP Context Response zurück zum MT auslösen, wenn eine ausstehende PDP-Kontexttransaktion besteht und wird ansonsten eine Update PDP Context Request auslösen. Nachfolgende RESV-Nachrichten vom externen Netz werden nur zum MT weitergeleitet und lösen auch Update PDP Context Requestverfahren aus, vorausgesetzt, es gibt Änderungen im Aufwärts-QoS-Erfordernis. Wenn der GGSN erstmalige oder Auffrischungs-PATH-Nachrichten vom MT empfängt, werden diese vom GGSN einfach zum externen Netz weitergeleitet. Wenn der GGSN eine erstmalige PATH-Nachricht vom externen Netz empfängt, leitet er die erstmalige PATH-Nachricht transparent zum MT weiter. Nachfolgende Auffrischungs-PATH-Nachrichten vom externen Netz werden nur zum MT gesendet, wenn es Änderungen der Abwärts-QoS-Parameter gibt.
6A zeigt den oben beschriebenen dritten Ansatz des Szenarios 2 für den Fall des vom MT eingeleiteten Verfahrens Activate Secondary PDP Context (sekundären PDP-Kontext aktivieren).
Das in 6A dargestellte Verfahren ist wie folgt:

(1a)–(1b) Wenn das MT eine erstmalige PATH-Nachricht empfängt, wird eine Nachricht Activate Secondary PDP Context Request mit entsprechenden Parametern Aufwärts-QoS anfordern zum SGSN gesendet. Diese Nachricht wird vom SGSN zum GGSN weitergeleitet.
(2) Vom GGSN wird keine Antwort erzeugt, bis er eine erstmalige RESV-Nachricht vom externen Host hört.
(3a)–(3b) Wenn vom GGSN die erstmalige RESV-Nachricht empfangen wird, erzeugt er eine PDP Context Response zum SGSN, die dann zum MT weitergeleitet wird.
(4), (5a)–(5b) Wenn der GGSN eine erstmalige PATH-Nachricht empfängt, löst er eine Nachricht Update PDP Context Request zum SGSN aus, die dann zum MT weitergeleitet wird.
(6a)–(6b) Vom MT wird solange keine Antwort erzeugt, bis es die erstmalige RESV-Nachricht von der TE hört. Sobald diese erstmalige RESV-Nachricht empfangen wird, erzeugt das MT die Nachricht Update PDP Context Response mit ausgehandelten Abwärts-QoS-Parametern und sendet sie zum SGSN. Vom SGSN wird diese Nachricht zum GGSN weitergeleitet.

Am MT empfangene Auffrischungs-PATH-Nachrichten werden nur dann weitergeleitet, wenn sie Änderungen enthalten. Am GGSN empfangene Auffrischungs-RESV-Nachrichten zur Aufwärts-QoS-Aushandlung werden vom GGSN nur unter der Voraussetzung weitergeleitet, daß eine Änderung vorliegt.
Die Schritte (8a)–(8d) zeigen, daß der GGSN ein Verfahren Update PDP Context Request auslöst, wenn eine solche Änderung in Aufwärts-QoS-Parametern vorliegt. Vom MT wird eine entsprechende Antwort erzeugt. Auf ähnliche Weise wird, wenn der GGSN eine Auffrischungs-PATH-Nachricht empfängt, sie vom GGSN nur bei einer Änderung weitergeleitet. Wenn eine Auffrischungs-RESV-Nachricht am MT ankommt, wird vom MT ein Verfahren Update PDP Context Request mit einer entsprechenden Abwärts-QoS-Anforderung eingeleitet. Der GGSN antwortet mit einem entsprechenden Parameter Negotiated Downlink QoS (ausgehandelter Abwärts-QoS-Parameter) in seiner Nachricht Update PDP Context Response zum SGSN, die zum MT weitergeleitet wird. Vom MT wird dann die Auffrischungs-RESV-Nachricht weitergeleitet. Man beachte, daß sowohl am MT als auch am GGSN Proxies benutzt werden können, so daß Auffrischungsnachrichten nicht weitergeleitet, sondern stattdessen am MT oder GGSN neu erzeugt werden.
6B zeigt den dritten Ansatz für den Fall des vom Netz eingeleiteten Verfahrens Activate Secondary PDP Context. In diesem Fall wartet das Verfahren vor Erzeugung der PDP Context Response bis zum Empfang der erstmaligen RESV-Nachricht. Im Ergebnis sind minimal ein Verfahren Activate und ein Verfahren Update PDP Context zum Aufbauen eines bidirektionalen PDP-Kontexts unter Verwendung des dritten Ansatzes des Szenarios 2 erforderlich. In einigen Fällen könnten ein Verfahren Activate und zwei Verfahren Update PDP Context zum Aufbauen eines bidirektionalen PDP-Kontexts unter Verwendung dieses Ansatzes erforderlich sein. Zusätzlich könnte es notwendig sein, Zeitgeber bereitzustellen, um Fehlerfälle zu behandeln, wenn die entsprechenden RESV-Nachrichten nicht ankommen.
Der vierte Ansatz des Szenarios 2 wird in Verbindung mit 7 beschrieben. Dieser Ansatz unterscheidet sich von den vorhergehenden Ansätzen, indem ein sekundärer PDP-Kontext nur nach Empfang der vollständigen Informationen über die QoS-Erfordernisse in beiden Richtungen durch das MT aufgebaut wird. Insbesondere wird vom MT eine Nachricht Activate 2nd PDP Context Request nur nach Empfang von sowohl einer erstmaligen RESV-Nachricht von der TE als auch einer erstmaligen vom GGSN weitergeleiteten RESV-Nachricht ausgelöst. Nachfolgende Auffrischungs-PATH-Nachrichten von der TE werden nur bei einer Änderung weitergeleitet. Auf ähnliche Weise werden nachfolgende Auffrischungs-RESV-Nachrichten von der TE nur bei einer Änderung weitergeleitet. Ein Verfahren Update PDP Context wird vom MT eingeleitet, wenn eine solche Änderung vorliegt.
Bei diesem vierten Ansatz wird vom GGSN eine erstmalige PATH vom externen Netz weitergeleitet. Vom externen Netz empfangene nachfolgende PATH-Nachrichten werden nur bei einer Änderung der QoS-Parameter weitergeleitet. Empfang der erstmaligen RESV-Nachricht vom externen Netz wird zum MT weitergeleitet. Empfang von nachfolgenden RESV-Nachrichten vom externen Netz wird ein Verfahren Update PDP Context nur bei einer Änderung des QoS-Erfordernisses auslösen.
Wenn für diesen Ansatz vom GGSN empfangene PATH und RESV-Nachrichten transparent zum MT weitergeleitet werden, dann muß nur das MT RSVP-Zeichengabenachrichten auswerten. Wenn jedoch Auffrischungs-PATH- und RESV-Nachrichten nur dann durch das UMTS-Netz weitergeleitet werden, wenn eine Änderung besteht, dann müssen sowohl MT als auch GGSN Zeichengabenachrichten auswerten.
Man beachte, daß zum Aufbauen eines bidirektionalen PDP-Kontexts unter Verwendung dieses Ansatzes nur ein Verfahren Activate 2nd PDP durchgeführt werden muß. Der Ansatz hat jedoch eine lange Aufbauverzögerung zum Herstellen eines zweiten PDP-Kontexts in Echtzeit zur Folge. Ehe ein zweiter PDP-Kontext in Echtzeit aufgebaut werden kann, können alle Trägerdaten nur über einen PDP-Kontext nach besten Bemühungen geführt werden, der normalerweise der primäre PDP-Kontext ist.
Unter den oben beschriebenen vier Ansätzen des Szenarios 2 könnte der zweite Ansatz der bevorzugte Ansatz für UMTS sein, wenn man sowohl die Latenzzeit beim Aufbauen eines Echtzeit-RAB und die Anzahl von zur Herstellung dieses Echtzeit-RAB erforderlichen Zeichengabenachrichten berücksichtigt. Es versteht sich natürlich, daß diese und andere hier beschriebenen Ansätze als Beispiel gegeben werden und die vorliegende Erfindung auf andere Weisen implementiert werden kann.
Abänderungen am bestehenden UMTS-Standard zum Unterstützen bidirektionalen PDP-Kontexts
In diesem Abschnitt werden gewisse Änderungen beschrieben, die in der UMTS-Kernnetzspezifikation notwendig sein würden, um einen bidirektionalen PDP-Kontext der hier beschriebenen Art zu unterstützen. Wie schon bemerkt, wird durch diesen bidirektionalen PDP-Kontext das oben beschriebene Racing-Problem überwunden. Um einen derartigen bidirektionalen PDP-Kontext zu unterstützen, müssen unter Umständen die nachfolgenden geringfügigen Änderungen an den UMTS Core Network Specifications durchgeführt werden:

(a) Zur Bereitstellung einer umfangreicheren Menge von QoS-Aushandlungsfähigkeiten müssen möglicherweise dem QoS-Informationselement (IE) die folgenden Markierungen zugefügt werden, z.B. unter Verwendung von zwei der drei unbenutzten Bit im vierten Byte des IE:

Wenn es ein getrenntes QoS-IE gibt, das sowohl Aufwärts- als auch Abwärtsstrecke abdeckt, könnte eine einzige Markierung wie folgt zugefügt werden:

Mrkg 0

0 keine QoS-Verkopplung mit der entgegengesetzten Richtung (Einweg-PDP-Kontext)

1 QoS-Verkopplung mit der entgegengesetzten Richtung (bidirektionaler PDP-Kontext)
(b) Es wird davon ausgegangen, daß ein Aufwärts-QoS-IE und ein Abwärts-QoS-IE als Teil der Nachricht Activate PDP Context oder Update PDP Context eingeschlossen werden. Zum Unterscheiden zwischen den beiden können verschiedene Nachrichtenarten benutzt werden, so daß ein Empfänger der Nachricht Activate PDP Context oder Update PDP Context leicht unterscheiden kann, ob in der gleichen Nachricht QoS-IE für Aufwärtsrichtung, Abwärtsrichtung oder beide enthalten sind.
(c) Es können gewisse Zeitgeber definiert werden, um die Fehlersituationen für diejenigen Ansätze zu bearbeiten, die auf die RESV-Nachricht warten, ehe sie irgendeine auf PDP-Kontext bezogene Nachricht erzeugen.
(d) In die Nachricht PDU Notification Request und die Nachricht Request PDP Context Activation können Aufwärts-/Abwärts-QoS-Parameter zugefügt werden. In die Nachricht Request PDP Context Activation kann eine verzögerte Aktivierungsmarkierung eingefügt werden, um das MT zu informieren, ob es vor Aktivieren des sekundären PDP-Kontexts auf irgendeine Nachricht von der TE warten muß.

Die oben beschriebenen Ausführungsformen der Erfindung sollen nur beispielhaft sein. Alternative Ausführungsformen der Erfindung können andere Arten von Zeichengabeanordnungen und andere Arten und Anordnungen von Telekommunikationssystemelementen nutzen. Dem Fachmann werden diese und zahlreiche andere alternative Ausführungsformen im Rahmen der nachfolgenden Ansprüche offenbar sein.

Claims

Verfahren zum Herstellen von Ressourcereservierungen in einem Telekommunikationssystem (20), gekennzeichnet durch folgendes: Bestimmen, ob ein Benutzer Ressourcereservierungen in sowohl einer Aufwärtsrichtung (a'b'c') als auch einer Abwärtsrichtung (e'f'g') im System erfordert; und Implementieren eines bidirektionalen Protokolls zur Herstellung der erforderlichen Ressourcereservierungen, wobei das bidirektionale Protokoll Ressourceaushandlungsverfahren für sowohl die Aufwärtsrichtung als auch die Abwärtsrichtung so integriert, um sicherzustellen, daß die erforderlichen Ressourcereservierungen für beide Richtungen bereitgestellt werden; wobei das bidirektionale Protokoll bestimmte Werte für eine oder mehrere aushandelbare Dienstgüte-(QoS)-Parameter (Quality of Service) für mindestens eine der Aufwärtsrichtung (a'b'c') und der Abwärtsrichtung (e'f'g') bestimmt; wobei die Bestimmung der bestimmten Werte für einen oder mehrere aushandelbare QoS-Parameter mindestens einen ersten Kontext in einer ersten Menge von Systemelementen (abc) und einen zweiten Kontext mit einer zweiten Menge von Systemelementen (a'b'c') benutzt, wobei der erste und zweite Kontext jeweils einem oder mehreren der aushandelbaren QoS-Parameter entspricht; wobei das bidirektionale Protokoll so konfiguriert ist, daß es mindestens eine Teilmenge des einen oder der mehreren QoS-Parameter des ersten Kontexts mit mindestens einer Teilmenge des einen oder der mehreren QoS-Parameter des zweiten Kontexts in Zusammenhang bringt; wobei das bidirektionale Protokoll eine Mehrzahl von Nachrichten umfaßt, wobei eine gegebene der Nachrichten Informationen führt, die aktuelle Werte von einem oder mehreren der aushandelbaren QoS-Parameter sowohl für die Aufwärtsrichtung als auch die Abwärtsrichtung angibt.
Verfahren nach Anspruch 1, wobei das Telekommunikationssystem gemäß dem UMTS-Standard (Universal Mobile Telecommunication System) konfiguriert ist.
Verfahren nach Anspruch 1, wobei das bidirektionale Protokoll ein PDP-Protokoll (Packet Data Protocol) umfaßt.
Verfahren nach Anspruch 1, wobei das bidirektionale Protokoll eine Ressourcereservierungsaushandlung für die Aufwärtsrichtung gefolgt von einer Ressourcereservierungsaushandlung für die Abwärtsrichtung durchführt.
Verfahren nach Anspruch 1, wobei das Ressourceaushandlungsverfahren ein RSVP-Verfahren (Resource Reservation Protocol) umfaßt.
Verfahren nach Anspruch 5, wobei das bidirektionale Protokoll in einem Systembetriebsszenario implementiert ist, in dem RSVP-Zeichengabenachrichten nur an MT-Elementen (Mobile Terminal) des Systems terminiert werden.
Verfahren nach Anspruch 5, wobei das bidirektionale Protokoll in einem Systembetriebsszenario implementiert ist, in dem RSVP-Zeichengabenachrichten an sowohl MT- als auch GGSN-Elementen (Gateway GPRS (General Packet Radio Service) Support Node) terminiert werden.
Verfahren nach Anspruch 1, wobei Empfang einer erstmaligen PATH-Nachricht von einem TE-Element (Terminal Equipment) des Systems in einem MT-Element des Systems ein Verfahren zum Aktivieren eines sekundären PDP-Kontexts auslöst, wenn kein sekundärer PDP-Kontext besteht.
Verfahren nach Anspruch 1, wobei Empfang einer erstmaligen RESV-Nachricht von einem TE-Element des Systems in einem MT-Element des Systems ein Verfahren zur Aktualisierung eines sekundären PDP-Kontexts auslöst, wenn ein unvollständiger bidirektionaler PDP-Kontext besteht.
Verfahren nach Anspruch 1, wobei Empfang einer erstmaligen PATH-Nachricht von einem externen Netzelement des Systems in einem GGSN-Element des Systems veranlaßt, daß ein MT-Element des Systems ein Verfahren zum Aktivieren eines sekundären PDP-Kontexts auslöst, wenn kein sekundärer PDP-Kontext besteht.
Verfahren nach Anspruch 1, wobei Empfang einer erstmaligen RESV-Nachricht von einem TE-Element des Systems in einem MT-Element des Systems ein Verfahren zum Aktivieren eines sekundären PDP-Kontexts auslöst, wenn kein sekundärer PDP-Kontext besteht.
Verfahren nach Anspruch 1, wobei Empfang in einem MT-Element des Systems von sowohl einer erstmaligen RESV-Nachricht von einem TE-Element des Systems als auch einer von einem GGSN-Element des Systems weitergeleiteten erstmaligen RESV-Nachricht ein Verfahren zum Aktivieren eines sekundären PDP-Kontexts auslöst.
Verfahren nach Anspruch 1, wobei das bidirektionale Protokoll für ein gegebenes MT- Element des Systems implementier wird, nachdem ein primärer oder Vorgabe-Ressourcereservierungskontext für das MT-Element hergestellt worden ist.
Verfahren nach Anspruch 1, wobei der Schritt des Bestimmens ein oder mehrere Markierungsbit benutzt, um festzustellen, ob der Benutzer Ressourcereservierungen für sowohl die Aufwärts- als auch die Abwärtsrichtung erfordert.
Verfahren nach Anspruch 9, wobei ein oder mehrere Markierungsbit einem QoS-Informationselement (IE) des Systems zugeordnet sind.
Verfahren nach Anspruch 9, wobei das eine oder die mehreren Markierungsbit dem Benutzer erlauben, zwischen Anwendung des bidirektionalen Protokolls und Anwendung eines Einweg-Protokolls zu wählen.
Verfahren nach Anspruch 9, wobei das eine oder die mehreren Markierungsbit ein Paar von Markierungsbit umfassen, wobei die Werte der Bit anzeigen, ob der Benutzer keine Ressourcereservierungen entweder in der Aufwärtsrichtung oder der Abwärtsrichtung, Ressourcereservierungen nur in der Aufwärtsrichtung, Ressourcereservierungen nur in der Abwärtsrichtung oder Ressourcereservierungen sowohl in der Aufwärts- als auch in der Abwärtsrichtung erfordert.
Verfahren nach Anspruch 9, wobei das eine oder die mehreren Markierungsbit ein einziges Markierungsbit umfassen, das für eine gegebene Richtung von Ressourcereservierungserfordernis anzeigt, ob das Erfordernis mit einem entsprechenden Erfordernis in der entgegengesetzten Richtung verkoppelt ist.
Vorrichtung zum Herstellen von Ressourcereservierungen in einem Telekommunikationssystem (20), gekennzeichnet durch folgendes: ein oder mehrere Systemelemente zum Bestimmen, ob ein Benutzer Ressourcereservierungen sowohl in einer Aufwärtsrichtung (abc) als auch einer Abwärtsrichtung (efg) im System erfordert, und zum Implementieren eines bidirektionalen Protokolls zur Herstellung der erforderlichen Ressourcereservierungen, wobei das bidirektionale Protokoll Ressourceaushandlungsverfahren für sowohl die Aufwärtsrichtung als auch die Abwärtsrichtung integriert, um sicherzustellen, daß die erforderlichen Ressourcereservierungen für beide Richtungen bereitgestellt werden; wobei das bidirektionale Protokoll bestimmte Werte für eine oder mehrere aushandelbare QoS-Parameter für mindestens eine der Aufwärtsrichtung (a'b'c') und der Abwärtsrichtung (e'f'g') bestimmt; wobei die Bestimmung der bestimmten Werte für einen oder mehrere aushandelbare QoS-Parameter mindestens einen ersten Kontext in einer ersten Menge von Systemelementen (abc) und einen zweiten Kontext mit einer zweiten Menge von Systemelementen (a'b'c') benutzt, wobei der erste und zweite Kontext jeweils einem oder mehreren der aushandelbaren QoS-Parameter entspricht; wobei das bidirektionale Protokoll so konfiguriert ist, daß es mindestens eine Teilmenge des einen oder der mehreren QoS-Parameter des ersten Kontexts mit mindestens einer Teilmenge des einen oder der mehreren QoS-Parameter des zweiten Kontexts in Zusammenhang bringt; wobei das bidirektionale Protokoll eine Mehrzahl von Nachrichten umfaßt, wobei eine gegebene der Nachrichten Informationen führt, die aktuelle Werte von einem oder mehreren der aushandelbaren QoS-Parameter sowohl für die Aufwärtsrichtung als auch die Abwärtsrichtung angibt.
Maschinenlesbares Mittel zum Speichern eines oder mehrerer Softwareprogramme zur Verwendung beim Herstellen von Ressourcereservierungen in einem Telekommunikationssystem (20), dadurch gekennzeichnet, daß das eine oder die mehreren Programme bei ihrer Ausführung folgende Schritte bereitstellen: Bestimmen, ob ein Benutzer Ressourcereservierungen sowohl in einer Aufwärtsrichtung (abc) als auch einer Abwärtsrichtung (efg) im System erfordert, und zum Implementieren eines bidirektionalen Protokolls zur Herstellung der erforderlichen Ressourcereservierungen, wobei das bidirektionale Protokoll Ressourceaushandlungsverfahren für sowohl die Aufwärtsrichtung als auch die Abwärtsrichtung integriert, um sicherzustellen, daß die erforderlichen Ressourcereservierungen für beide Richtungen bereitgestellt werden; wobei das bidirektionale Protokoll bestimmte Werte für eine oder mehrere aushandelbare QoS-Parameter für mindestens eine der Aufwärtsrichtung (a'b'c') und der Abwärtsrichtung (e'f'g') bestimmt; wobei die Bestimmung der bestimmten Werte für einen oder mehrere aushandelbare QoS-Parameter mindestens einen ersten Kontext in einer ersten Menge von Systemelementen (abc) und einen zweiten Kontext mit einer zweiten Menge von Systemelementen (a'b'c') benutzt, wobei der erste und zweite Kontext jeweils einem oder mehreren der aushandelbaren QoS-Parameter entspricht; wobei das bidirektionale Protokoll so konfiguriert ist, daß es mindestens eine Teilmenge des einen oder der mehreren QoS-Parameter des ersten Kontexts mit mindestens einer Teilmenge des einen oder der mehreren QoS-Parameter des zweiten Kontexts in Zusammenhang bringt; wobei das bidirektionale Protokoll eine Mehrzahl von Nachrichten umfaßt, wobei eine gegebene der Nachrichten Informationen führt, die aktuelle Werte von einem oder mehreren der aushandelbaren QoS-Parameter sowohl für die Aufwärtsrichtung als auch die Abwärtsrichtung angibt.