[go: up one dir, main page]

DE60120354T2 - Rsvp-verarbeitung in 3g-netzwerken - Google Patents

Rsvp-verarbeitung in 3g-netzwerken Download PDF

Info

Publication number
DE60120354T2
DE60120354T2 DE60120354T DE60120354T DE60120354T2 DE 60120354 T2 DE60120354 T2 DE 60120354T2 DE 60120354 T DE60120354 T DE 60120354T DE 60120354 T DE60120354 T DE 60120354T DE 60120354 T2 DE60120354 T2 DE 60120354T2
Authority
DE
Germany
Prior art keywords
pdp context
message
terminal
qos
rsvp
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
DE60120354T
Other languages
English (en)
Other versions
DE60120354D1 (de
Inventor
Gabor Fodor
Oyama
Robertsson c/o
Ina Widegren
Brian Melbourne WILLIAMS
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE60120354D1 publication Critical patent/DE60120354D1/de
Application granted granted Critical
Publication of DE60120354T2 publication Critical patent/DE60120354T2/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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2491—Mapping quality of service [QoS] requirements between different networks
    • 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/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
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • H04L47/786—Mapping reservation between domains
    • 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
    • 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
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • 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
    • 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
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
  • Air Bags (AREA)
  • Radar Systems Or Details Thereof (AREA)
  • Analogue/Digital Conversion (AREA)
  • Small-Scale Networks (AREA)

Description

  • QUERVERWEIS AUF EINE VERWANDTE ANMELDUNG
  • Die vorliegende Patentanmeldung steht in einer rechtlichen Beziehung zu und beansprucht Priorität der vorläufigen US-Patentanmeldung, Seriennr. 60/178,086, mit dem Titel "Processing RSVP Signalling in the MT", die am 25. Januar 2000 eingereicht wurde und deren Offenbarung durch Querverweis in die vorliegende Patentanmeldung einbezogen ist.
  • ALLGEMEINER STAND DER TECHNIK
  • Die vorliegende Patentanmeldung betrifft allgemein Internet-Protokoll- ("IP"-) Netze und spezieller Mechanismen zur Bereitstellung von Dienstgüte (Quality of Service, "QoS") in IP-Netzen.
  • Ursprünglich waren IP-Netze dazu bestimmt, "Best Effort" Verkehr" zu transportieren. Das heißt, das Netz garantierte nicht, dass ein Datenpaket des Benutzers am Ziel ankommen würde. Aufgrund des Markterfolges von IP-Netzen besteht heute eine klare Forderung nach Mechanismen, welche IP-Netzen ermöglichen, verschiedene Typen von Anwendungen zu unterstützen. Einige dieser Anwendungen weisen QoS-Anforderungen auf. Zu den Beispielen solcher Anwendungen gehören verschiedene Echtzeitanwendungen (IP-Telefonie, Videokonferenzen), Streaming-Dienste (Audio oder Video) oder Datendienste von hoher Qualität (Browsen mit begrenzten Download-Verzögerungen). Diesen Anforderungen Rechnung tragend, hat die Internet Engineering Task Force ("IETF"), welche die wichtigste Organisation für Standards für IP-Netze ist, unlängst eine Gruppe von Protokollen und Mechanismen standardisiert, welche Betreiber von IP-Netzen in die Lage versetzen, QoS-fähige IP-Netze aufzubauen.
  • 1 zeigt ein vereinfachtes High-Level-Modell eines IP-Netzes, welches bei der Erläuterung der QoS-Bereitstellung von Nutzen sein kann. Wie zu erkennen ist, enthält das Modell zwei Benutzer, könnte jedoch leicht so erweitert werden, dass es mehrere Benutzer enthält, ohne die Grundfunktionalität des Netzes zu ändern.
  • In 1 kann Benutzer-A 101 mit Benutzer-B 102 oder mit einem Anwendungsserver 103 kommunizieren. Zum Beispiel kann im Falle einer IP-Telefonie-Sitzung Benutzer-A 101 mit Benutzer-B 102 kommunizieren. Ähnlich kann im Falle von Streaming-Diensten Benutzer-A 101 mit dem Anwendungsserver 103 kommunizieren, welcher als ein Videoserver konfiguriert sein kann. In beiden Fällen greift Benutzer-A 101 über ein lokales Zugangsnetz 105, wie etwa ein Telefon-, GSM- oder UMTS-Netz, auf ein IP-Backbone-Netz 104 zu. Der Benutzer-B 102 ist ähnlich über ein lokales Zugangsnetz 106 an das IP-Netz 104 angeschlossen. Es ist jedoch leicht einzusehen, dass Benutzer-A und Benutzer-B nicht denselben Typ eines Zugangsnetzes verwenden müssen.
  • Wie allgemein bekannt ist, kann das IP-Netz 104 aus einer Anzahl von IP-Routern und Verbindungsabschnitten bestehen, welche zusammen die Konnektivität zwischen den Eintritts- und Austrittspunkten des IP-Netzes gewährleisten und dadurch eine Zweierkommunikation ermöglichen.
  • Soweit es die Benutzer betrifft, hängt die wahrgenommene QoS von den Mechanismen sowohl in den Zugangsnetzen 105, 106 als auch im IP-Backbone-Netz 104 ab. Von besonderem Interesse ist der spezielle Fall, in dem wenigstens eines der Zugangsnetze ein UMTS-Netz ist.
  • Wenn Benutzer auf IP-basierte Dienste zugreifen, verwenden sie normalerweise eine Vorrichtung, welche ein Anwenderprogramm ausführt, das die Schnittstelle für den Benutzer zur Verfügung stellt, um auf den speziellen Dienst zuzugreifen. Zum Beispiel kann in 1 Benutzer-A einen Laptop verwenden, der ein Conferencing-Anwenderprogramm ausführt, um an einer IP-Netz-gestützten Besprechung teil zunehmen, wobei die Teilnehmer der Besprechung unter Verwendung unterschiedlicher Programme zusammenarbeiten. Solche Programme sind in der Technik wohlbekannt.
  • Verschiedene Anwendungen können auf Netzdienste über eine Anwenderprogramm-Schnittstelle (Application Programming Interface, "API") zugreifen. Eine API stellt Anwendungsprogrammierern eine einheitliche Schnittstelle zur Verfügung, um auf zugrunde liegende Systemressourcen zuzugreifen. Zum Beispiel kann eine API verwendet werden, um den Netzressourcen-Manager so zu konfigurieren, dass er fordert, dass ein bestimmtes IP-Paket, das von einer gegebenen Anwendung stammt, eine gewisse Behandlung durch das Netz erfährt, wie etwa eine bestimmte QoS. Falls zum Beispiel das IP-Netz ein Differentiated Services IP-Netz ist, kann ein Anwenderprogramm fordern, dass seine sämtlichen IP-Pakete die Behandlung "Expedited Forwarding" erhalten.
  • Es ist anzumerken, dass der Benutzer (und die API im Gerät des Benutzers) möglicherweise nicht die unterschiedlichen Technologien bemerkt, welche verschiedene Zugangsnetze und IP-Backbone-Netze anwenden, um Ende-zu-Ende-Dienstgüte bereitzustellen. Zum Beispiel kann der Benutzer eine RSVP/IntServ-basierte API verwenden, und die Ende-zu-Ende-Ausführungsform, in welche der Benutzer einbezogen ist, kann ein UMTS-Zugangsnetz und ein nicht RSVP-fähiges IP-Netz umfassen. In solchen Fällen können bestimmte Interworking-Mechanismen zwischen den verschiedenen Technologien erforderlich sein, um sicherzustellen, dass die QoS als Ende-zu-Ende-QoS bereitgestellt wird.
  • Integrierte Dienste (Integrated Services, "IntServ") bieten Anwendungen die Möglichkeit, zwischen mehreren gesteuerten Niveaus des Übergabedienstes für ihre Datenpakete zu wählen. Um diese Fähigkeit zu unterstützen, sind zwei Dinge erforderlich. Erstens müssen die einzelnen Netzelemente wie etwa Teilnetze und IP-Router entlang des Weges, den die Datenpakete einer Anwendung nehmen, Mechanismen unterstützen, um die Dienstgüte zu steuern, die diesen Paketen geliefert wird. Zweitens muss eine Verfahrensweise vorgesehen sein, um die Anforderungen der Anwendung den Netzelementen entlang des Weges zu übermitteln und QoS-Management-Informationen zwischen Netzelementen und der Anwendung zu transportieren.
  • IntServ definiert eine Anzahl von Diensten wie etwa Controlled-Load (definiert in IETF RFC 2211) und Guaranteed (definiert in IETF RFC 2212). Die Dienstdefinition legt die erforderlichen Eigenschaften der Netzausrüstung fest, um den Dienst zu liefern. Zum Beispiel stellt garantierter Dienst (Guaranteed Service) feste, mathematisch nachweisbare Schranken für Ende-zu-Ende-Warteschlangenverzugszeiten von Datagrammen bereit und ermöglicht es, einen Dienst bereitzustellen, welcher sowohl Verzug als auch Bandbreite garantiert. Dienst mit Laststeuerung (Controlled-Load Service) versorgt den Client-Datenfluss mit einer Dienstgüte, die der QoS nahe kommt, welche derselbe Datenfluss von einem unbelasteten Netzelement empfangen würde, verwendet jedoch eine Kapazitätssteuerung (Zulassungssteuerung), um sicherzustellen, dass dieser Dienst sogar dann empfangen wird, wenn das Netzelement überlastet ist. Die einzelnen Netzelemente (Teilnetze und IP-Router), welche den Dienst unterstützen, müssen die für den Dienst festgelegten Definitionen erfüllen.
  • Die Dienstdefinition legt auch die Informationen fest, welche über das Netz zur Verfügung gestellt werden müssen, um den Dienst einzurichten. Diese Funktion kann auf vielfältige Weise bereitgestellt werden, wird jedoch häufig durch ein Ressourcenreservierungsprotokoll wie etwa RSVP (definiert in IETF RFC 2205) implementiert.
  • RSVP (Resource reSerVation Protokoll) ist ein Ressourcenreservierungsprotokoll, das für ein IntServ Internet (defi niert in IETF RFC 1633, 2205 und 2210) bestimmt ist. Das RSVP Protokoll wird von einem Host verwendet, um von dem Netz spezielle Dienstgüten für Datenströme oder Datenflüsse einer bestimmten Anwendung anzufordern. RSVP wird außerdem von Routern verwendet, um allen Knoten entlang des Weges (der Wege) der Datenflüsse Dienstgüte- ("QoS"-) Anforderungen zu liefern und um den Zustand zum Bereitstellen des angeforderten Dienstes herzustellen und aufrechtzuerhalten. RSVP-Anforderungen werden im Allgemeinen zur Folge haben, dass in jedem Knoten entlang des Datenweges Ressourcen reserviert werden.
  • 2 zeigt den Ende-zu-Ende integrierten Dienst zwischen den Hosts. Der Dienst wird unter Verwendung von Routern und Hosts bereitgestellt, welche die für den geforderten Dienst festgelegte Dienstdefinition unterstützen, sowie durch Signalisierung der relevanten Informationen zwischen den Knoten.
  • Da RSVP ein Protokoll ist, welches primär dazu bestimmt ist, ein Ende-zu-Ende-Protokoll zu sein, ist in einer Situation, in welcher der Absender RSVP zur Ressourcenreservierung nur in einem bestimmten Teil des durchgehenden Weges verwenden möchte, eine gewisse zusätzliche Funktionalität erforderlich. Dieser Fall kann eintreten, wenn RSVP in einem Zugangsnetz verwendet wird und im Backbone-Netz Overprovisioning verwendet wird. In solchen Situationen ist das Konzept des RSVP-Proxy von Nutzen.
  • Der RSVP-Proxy ist eine von einem Netzgerät wie etwa einem Router oder einer Weiche bereitgestellte Funktionalität, in welcher das Netzgerät die RESV-Nachricht in Reaktion auf eine ankommende PATH-Nachricht im Namen eines oder mehrerer Empfänger, die durch die PATH-Nachricht bezeichnet werden, erzeugt. Anders ausgedrückt, der RSVP-Proxy handelt im Namen des entfernten Hosts und ermöglicht dadurch eine Ressourcenreservierung zwischen dem erzeugenden Host und dem RSVP-Proxy. Dies ist in 3 dargestellt. Der RSVP-Proxy kann die Kenntnis der Netzbedingungen zwischen dem RSVP-Proxy und dem Nicht-RSVP-Host nutzen.
  • Verbesserungen des Internet-Protokolls durch differenzierte Dienste (Differentiated Services, "DiffServ") sind dazu vorgesehen, eine Diskrimination skalierbarer Dienste im Internet zu ermöglichen, ohne dass Per-flow State und Signalisierung bei jedem Hop benötigt werden. Aus einer kleinen, wohldefinierten Menge von Bausteinen, welche in Netzknoten eingesetzt sind, kann eine Vielzahl von Diensten aufgebaut werden. Die Dienste können entweder Ende-zu-Ende-Dienste oder Intradomain-Dienste sein; zu den Diensten gehören jene, welche quantitative Leistungsanforderungen erfüllen können (z.B. Spitzen-Bandbreite), und jene, die auf relativer Leistung beruhen (z.B. "Klassen"-Differenzierung). Dienste können durch eine Kombination des Setzens von Bits in einem IP-Header-Feld an Netzgrenzen (Grenzen autonomer Systeme, interne administrative Grenzen oder Hosts), des Verwendens jener Bits, um zu bestimmen, wie Pakete von den Knoten innerhalb des Netzes weitergeleitet werden, und des Konditionierens der markierten Pakete an Netzgrenzen entsprechend den Anforderungen oder Regeln des jeweiligen Dienstes konstruiert werden.
  • Differenzierte Dienste definieren einen Edge-Router an der Netzgrenze und Kern-Router innerhalb des Netzes. Der Edge-Router und die Kern-Router haben unterschiedliche Aufgaben. Der Edge-Router muss den Verkehr konditionieren, um sicherzustellen, dass der Verkehr mit der Dienstvereinbarung konform ist. Der Edge-Router markiert außerdem den Paketverkehr mit dem entsprechenden Differentiated Services Code Point ("DSCP") und leitet danach die Pakete entsprechend dem Dienstverhalten weiter, das für diesen DSCP definiert ist. Das Dienstverhalten, Weiterleitungsverhalten (Per Hop Behavior, "PHB") genannt, kann die Priorisierung oder Wichtung des betreffenden Typs von Verkehr definieren, um dem Verkehr einen besseren Dienst zu geben als anderem Verkehr von einem anderen Typ. Die Kern-Knoten prüfen den DSCP und wenden das Dienstverhalten an, das für den betreffenden Dienst geeignet ist.
  • 4 zeigt den Ende-zu-Ende-Dienst. Die DS Edge-Router führen die Konditionierung des Verkehrs durch, während die DS Kern-Router einfach das PHB anwenden.
  • Die IntServ-Architektur stellt ein Mittel zur Lieferung von Ende-zu-Ende-QoS für Anwendungen über heterogene Netze bereit. Um dieses Ende-zu-Ende-Modell zu unterstützen, muss die IntServ-Architektur über eine breite Vielfalt unterschiedlicher Typen von Netzelementen unterstützt werden. In diesem Kontext kann ein Netz, welches differenzierte Dienste unterstützt, als ein Netzelement in dem gesamten Ende-zu-Ende-Weg angesehen werden.
  • Aus der Perspektive von IntServ werden DiffServ-Regionen des Netzes als virtuelle Verbindungen behandelt, welche IntServ-fähige Router oder Hosts verbinden (etwa so wie ein Ethernet-LAN als eine virtuelle Verbindung behandelt werden kann). Innerhalb der DiffServ-Regionen des Netzes implementieren Router spezielle PHBs (aggregierte Verkehrssteuerung). Die Gesamtmenge des Verkehrs, welcher in die DiffServ-Region eingelassen wird, welche ein gewisses PHB empfangen soll, wird durch das Konditionieren an den Edge Routern gesteuert. Ein IntServ-Dienst kann über eine DiffServ-Domain hinweg bereitgestellt werden, indem Zulassungskontrolle und Verkehrskonditionierung am Edge-Router und Signalisierung unter Verwendung von RSVP über die DiffServ-Domain hinweg angewendet werden. Die Informationen, die in der RSVP-Signalisierung zur Verfügung gestellt werden, sollten für den Dienst über die DiffServ-Domain hinweg geeignet sein. Dies ist in 5 dargestellt.
  • Um einen QoS Trägerdienst mit klar definierten Eigenschaften und klar definierter Funktionalität zu realisieren, muss der Träger von der Quelle bis zum Ziel des Dienstes eingerichtet werden. Ein Trägerdienst umfasst alle Aspekte, um die Bereitstellung einer vertraglich festgelegten QoS zu ermöglichen. Diese Aspekte sind unter anderem die Steuersignalisierung, Benutzerebenentransport und QoS-Management-Funktionalität.
  • Mobilfunk-Zugangsdatennetze, zu denen General Packet Radio Service ("GPRS") und Universal Mobile Telecommunication System ("UMTS") gehören, können einen Bestandteil des Gesamtnetzes bilden und eine wichtige Rolle im Ende-zu-Ende-Trägerdienst für Kunden, die an ihn angeschlossen sind, spielen. Folglich muss der über das GPRS-/UMTS-Netz bereitgestellte Dienst unter den oben erwähnten Aspekten der Steuersignalisierung und des Benutzerebenentransports geeignet sein, um den geforderten Ende-zu-Ende-Trägerdienst zur Verfügung zu stellen.
  • Das GPRS-/UMTS-Netz besteht aus einer Menge von Netzelementen zwischen dem Host, der als die Mobilstation ("MS") bezeichnet wird, und dem externen Paketvermittlungsnetz, an das der Benutzer angeschlossen ist. Diese Knoten sind in 6 dargestellt.
  • Der Gateway GPRS Support Node ("GGSN") gewährleistet das Interworking mit externen paketvermittelten Netzen.
  • Um paketvermittelte (packet-switched, "PS") Daten zu senden und zu empfangen, muss die MS den Paketdatenprotokoll-Kontext aktivieren, welchen die MS benutzen möchte. Diese Operation macht die MS in dem entsprechenden GGSN bekannt, und das Interworking mit externen Datennetzen kann beginnen.
  • Benutzerdaten werden transparent zwischen der MS und den externen Datennetzen mit einem Verfahren übertragen, das unter der Bezeichnung Kapselung und Tunnelung bekannt ist: Datenpakete werden mit PS-spezifischen Protokollinformationen ausgestattet und zwischen der MS und dem GGSN übermittelt.
  • Dienstgüte (Quality of Service, "QoS") spielt auch bei 3G Mobilnetzen eine äußerst wichtige und zentrale Rolle. QoS ist ein Mittel, um Endbenutzer mit einem zufrieden stellenden Dienst zu versorgen, und ist auch für das Netzmanagement wesentlich, was Kenntnisse anbelangt. QoS setzt Kenntnisse des Verkehrs im Netz voraus, und folglich ermöglicht QoS auch eine effiziente Nutzung der Spektrumsressourcen.
  • Die Erfindung wird anhand einer UMTS QoS-Architektur beschrieben. Dementsprechend wird, um einen einheitlichen Grad des Verständnisses sicherzustellen, ein dem Stand der Technik entsprechender Überblick über QoS bei UMTS gegeben. Es wird die 3GPP UMTS QoS-Architektur beschrieben, einschließlich einer Erläuterung des Paketdatenprotokoll-Kontextes ("PDP-Kontext"), des Traffic Flow Templates ("TFT") und der QoS-Wartungsprozeduren für aktivierte UMTS Träger.
  • Es ist zu erwarten, dass die mit Funk verknüpfte Bandbreite die teuerste und wertvollste Ressource in der Ende-zu-Ende-Kette ist. Innerhalb von UMTS-Zugangsnetzen werden die Funknetzressourcen mit einer Granularität je nach PDP-Kontext verwaltet, welche einem User Flow und einem gewissen QoS-Niveau entspricht.
  • Das QoS-Rahmenwerk für R99 3G Netze ist in TS23.107 V.3.4.0 spezifiziert. Der Schwerpunkt liegt auf der QoS-Architektur, die auf der UMTS-Ebene zu verwenden ist, wobei die Liste von QoS-Attributen, die für UMTS Trägerdienst und den Radio Access Bearer Service (Funkzugangs-Trägerdienst) anwendbar sind, zusammen mit entsprechenden Abbildungsregeln spezifiziert ist.
  • TS23.060 V.3.4.0 spezifiziert die allgemeinen Mechanismen, die von R99 3G Netzen für paketvermittelte Konnektivitätsdienste auf der UMTS-Ebene verwendet werden. Dies definiert die Dienstbeschreibung für die Paketdomain des 3G Netzes, welche den General Packet Radio Service ("GPRS") in GSM und UMTS umfasst.
  • In einer UMTS QoS-Architektur werden Netzdienste Ende-zu-Ende betrachtet, von einer Endeinrichtung (Terminal Equipment, "TE") zu einer anderen TE. Ein Ende-zu-Ende-Dienst kann eine gewisse Dienstgüte aufweisen, welche dem Benutzer eines Netzdienstes zur Verfügung gestellt wird.
  • Um eine gewisse Netz-QoS zu realisieren, wird ein Trägerdienst mit klar definierten Eigenschaften und klar definierter Funktionalität von der Quelle bis zum Ziel eines Dienstes eingerichtet. Der Trägerdienst umfasst alle Aspekte, um die Bereitstellung einer vertraglich festgelegten QoS zu ermöglichen, z.B. Steuersignalisierung, Benutzerebenentransport, QoS-Management-Funktionalität usw.
  • Eine Mehrschichtenarchitektur eines UMTS Trägerdienstes ist in 7 dargestellt. Jeder Trägerdienst bietet auf einer bestimmten Schicht seine individuellen Dienste unter Verwendung der Dienste, die von den darunter befindlichen Schichten bereitgestellt werden. Träger werden in zugrunde liegende Träger heruntergebrochen, von denen jeder eine QoS durch eine Realisierung bereitstellt, welche von den anderen Trägern unabhängig ist. Dienstvereinbarungen werden zwischen Netzkomponenten abgeschlossen, welche in 7 horizontal angeordnet sind. Die Dienstvereinbarungen können von einer oder mehreren Schichten des Dienstes ausgeführt werden.
  • Zum Beispiel besteht der UMTS Trägerdienst aus einem Radio Access Bearer ("RAB") Dienst (Funkzugangs-Trägerdienst) und einem Core Network ("CN") Trägerdienst (Kernnetz-Trägerdienst). Der RAB Dienst ist dann in einen Funk-Trägerdienst und einen Iu Trägerdienst unterteilt. Die Iu Schnittstelle ist die Schnittstelle zwischen dem Funkzugangsnetz und dem Kernnetz.
  • Das Folgende sind Beispiele der in 7 dargestellten Entitäten. Die Endeinrichtung ("TE") kann ein Laptop sein, und das mobile Endgerät (Mobile Terminal, "MT") kann ein Handapparat sein. Das UTRAN kann aus einer Kombination von Knoten B und einer Funknetzsteuerung (Radio Network Controller, "RNC") bestehen. Der CN Iu Edge Node kann ein Serving GPRS Support Node ("SGSN") sein, und das CN Gateway kann ein Gateway GPRS Support Node ("GGSN") sein.
  • Die QoS Management-Funktionen in UMTS werden verwendet, um einen UMTS-Trägerdienst mit einer spezifischen QoS, die durch spezifische QoS-Attribute definiert ist, aufzubauen, zu modifizieren und zu warten. Die QoS Management-Funktionen aller UMTS Entitäten stellen kombiniert die Bereitstellung des verhandelten UMTS Trägerdienstes sicher.
  • Die UMTS-Architektur umfasst vier Management-Funktionen in der Steuerungsebene und vier in der Benutzerebene. Die Management-Funktionen der Steuerungsebene sind:
    Bearer Service ("BS") Manager, welcher den entsprechenden Trägerdienst einrichtet, steuert und beendet. Jeder BS Manager übersetzt auch die Attribute seiner Ebene während Dienstanforderungen in Attribute des zugrunde liegenden Trägerdienstes.
  • Übersetzungsfunktion, welche zwischen externer Dienstsignalisierung und internen Dienstprimitiven konvertiert, ein schließlich der Übersetzung der Dienstattribute, und sich im MT und im Gateway befindet.
  • Zulassungskontrolle (Admission Control)/Capability Control, welche bestimmt, ob die Netzentität den spezifischen angeforderten Dienst unterstützt und ob die benötigten Ressourcen verfügbar sind.
  • Subscription Control (Abonnement-Kontrolle), welche bestimmt, ob der Benutzer das Abonnement für den Dienst hat, welcher angefordert wird.
  • Die Management-Funktionen der Benutzerebene sind:
    Abbildungsfunktion, welche jede Dateneinheit mit der spezifischen QoS-Angabe markiert, die sich auf den Trägerdienst bezieht, der die Übertragung der Dateneinheit durchführt. Zum Beispiel kann die Abbildungsfunktion DiffServ Code Points zu Pakete hinzufügen, bevor die Pakete auf den Iu- oder CN-Träger gebracht werden.
  • Klassifizierungsfunktion, welche in dem GGSN und in dem MT resident ist, weist Benutzerdaten-Einheiten (z.B. IP-Paketen), die von dem externen Trägerdienst (oder dem lokalen Trägerdienst) empfangen wurden, dem entsprechenden UMTS Trägerdienst zu, entsprechend den QoS-Anforderungen der jeweiligen Benutzerdaten-Einheit. Hier befinden sich die Traffic Flow Template ("TFT") und Paketfilter, wie weiter unten beschrieben ist.
  • Ressourcenmanager, welcher seine Ressourcen unter allen Trägerdiensten verteilt, welche eine Verwendung dieser Ressourcen anfordern. Der Ressourcenmanager versucht, die QoS-Attribute bereitzustellen, die für jeden einzelnen Trägerdienst erforderlich sind. Ein Beispiel eines Ressourcenmanagers ist ein Packet Scheduler.
  • Traffic Conditioner (Verkehrskonditionierer), welcher eine verkehrsformende (Shaping) und verkehrsüberwachende (Policing) Funktion ist, welche für die Konformität des Benutzerdatenverkehrs mit den QoS-Attributen des betreffenden UMTS Trägerdienstes sorgt. Er ist im GGSN und im MT sowie im UTRAN resident.
  • Die QoS-Management-Funktionen zum Steuern des UMTS Trägerdienstes sind in 8 dargestellt. Der Zweck dieser Steuerungsfunktionen ist es, den Aufbau und die Modifizierung von UMTS Trägerdiensten durch Interaktion mit der Local Service Control in der TE und der External Service Control im externen Netz zu unterstützen.
  • Die QoS-Management-Funktionen des UMTS Trägerdienstes in der Benutzerebene sind in 9 dargestellt. Diese Funktionen halten zusammen die Eigenschaften der Datenübertragung gemäß den durch die Steuerungsfunktionen des UMTS Trägerdienstes festgelegten Verpflichtungen aufrecht, die durch die Attribute des Trägerdienstes ausgedrückt werden. Die Benutzerebene verwendet die QoS-Attribute. Die relevanten Attribute werden den Management-Funktionen der Benutzerebene durch die QoS-Management-Steuerungsfunktionen zur Verfügung gestellt.
  • Vier verschiedene QoS-Klassen sind in UMTS standardisiert und in Tabelle 1 dargestellt. Der Datentransport kann für den entsprechenden Typ von Anwendungsdaten oder für einen Trägerdienst einer bestimmten Klasse optimiert werden. Das hauptsächliche Unterscheidungsmerkmal zwischen diesen Klassen ist, wie verzögerungsempfindlich der Verkehr ist: Die Konversationsklasse bezeichnet Verkehr, welcher sehr verzögerungsempfindlich ist (für Echtzeitdienste), während die Hintergrundklasse die am meisten verzögerungsunempfindliche Verkehrsklasse ist (für Nicht-Echtzeitdienste).
  • Um einen Trägerdienst im Einzelnen zu charakterisieren, ist in UMTS eine Menge von Trägerdienstattributen standardisiert, wie in den Tabellen weiter unten angegeben ist. Eine bestimmte QoS wird angefordert, indem eine Menge von Attributwerten gewählt wird, welche die Träger-Anforderung beschreibt. Die Parameter unterscheiden sich in Abhängigkeit vom Typ des angeforderten Trägerdienstes.
  • Tabelle 2 zeigt, welche Attribute für welche Verkehrsklasse anwendbar sind. Tabelle 3 gibt einen Überblick darüber, wofür die verschiedenen QoS-Attribute verwendet werden. Die exakten Definitionen der QoS-Attribute sind in TS23.107 zu finden, von dem gegenwärtig die Version 3.4.0 aktuell ist.
  • Ein Abonnement ist mit einer oder mehreren Paketdatenprotokoll- ("PDP"-) Adressen verknüpft, d.h. IP-Adressen im Fall von IP-Verkehr. Jede PDP-Adresse wird durch einen oder mehrere PDP-Kontexte beschrieben, die in der MS, im SGSN und im GGSN gespeichert sind. Standardwerte sind außerdem im HLR verfügbar, welches die Abonnements-Information speichert. Jeder PDP-Kontext kann mit einem Traffic Flow Template ("TFT") verknüpft sein. Zu einem beliebigen Zeitpunkt kann höchstens ein PDP-Kontext (der mit derselben PDP-Adresse verknüpft ist) existieren, dem kein TFT zugeordnet ist. Die Beziehung zwischen PDP-Adresse, PDP-Kontext und TFT ist in 10 dargestellt.
  • Ein PDP-Kontext ist eine dynamische Tabelle von Dateneinträgen, die alle benötigten Informationen zum Übertragen von PDP PDUs zwischen MS und GGSN umfasst, zum Beispiel Adressierungsinformationen, Datenfluss-Steuerungsvariable, QoS-Profil, Gebühreninformationen usw. Die Beziehung zwischen UMTS Trägerdiensten und PDP-Kontext ist eine eineindeutige Abbildung, d.h. wenn zwei UMTS Trägerdienste für eine PDP-Adresse festgelegt sind, so sind zwei PDP-Kontexte definiert.
  • Die PDP-Kontext-Prozeduren sind in TS23.060 definiert, von dem gegenwärtig die Version 3.4.0 aktuell ist. Die Konzepte, welche mit dem QoS-Profil und dem Traffic Flow Template ("TFT") zusammenhängen, sind aus der Perspektive der QoS relevant.
  • Die UMTS QoS-Attribute sind hauptsächlich zur Unterstützung einer effizienten Realisierung des Funks gewählt und definiert worden. Ein QoS-Profil ist durch eine Menge von UMTS QoS-Attributen definiert. Der RNC erhält das relevante RAB QoS-Profil von dem SGSN während der PDP-Kontext Aktivierung. Es gibt drei verschiedene QoS-Profile, die an einer PDP-Kontext Aktivierung beteiligt sind – das angeforderte QoS-Profil, das verhandelte QoS-Profil und das abonnierte QoS-Profil (oder das Standard-QoS-Profil).
  • In Abhängigkeit vom Typ der benötigten Information unterscheiden sich die gespeicherten PDP-Kontext-Informationen in der MS, im RNS, SGSN, GGSN und HLR. In Bezug auf das QoS-Profil gilt Folgendes:
    • GGSN:
    Verhandeltes QoS-Profil
    MS:
    Verhandeltes QoS-Profil, angefordertes QoS-Profil und abonniertes QoS-Profil
    SGSN:
    Verhandeltes QoS-Profil, angefordertes QoS-Profil und abonniertes QoS-Profil
    RNC:
    Verhandeltes RAB QoS-Profil
    HLR:
    Abonniertes QoS-Profil
  • Ein TFT ist ein Paketfilter (oder eine Satz von Filtern), welches Pakete mit dem richtigen PDP-Kontext verknüpft und damit sicherstellt, dass die Pakete in dem entsprechenden GTP-Tunnel weitergeleitet werden. Das TFT ermöglicht es, über verschiedene PDP-Kontexte mit variierenden QoS-Profilen zu verfügen, die mit einer einzigen PDP-Adresse verknüpft sind. Das TFT wird von dem MT sowohl für Uplink- als auch für Downlink-Ströme verwaltet und initiiert. Das Uplink TFT ist im MT resident, während das Downlink TFT im GGSN resident ist. Das Downlink TFT wird vom MT während der PDP-Kontext Aktivierung/Modifizierung an den GGSN gesendet. Die Downlink TFTs können zu einem PDP-Kontext hinzugefügt werden, welcher ohne ein solches erzeugt wurde, und der Inhalt kann ebenfalls modifiziert werden.
  • Tabelle 4 zeigt die Attribute der TFT Paketfilter und gültige Kombinationen. Jedes TFT hat eine Kennung und einen Evaluations-Rangfolgeindex, welcher eindeutig innerhalb aller TFTs ist, die mit den PDP-Kontexten verknüpft sind, welche gemeinsam dieselbe PDP-Adresse benutzen. Die MS verwaltet die Kennungen und die Evaluations-Rangfolgeindezes und ebenso die Paketfilter-Inhalte.
  • Einige der Attribute in Tabelle 4 können in einem Paketfilter nebeneinander bestehen, während andere einander gegenseitig ausschließen. Nur diejenigen Attribute, die mit einem "X" gekennzeichnet sind, können für ein einziges Paketfilter spezifiziert werden. Alle gekennzeichneten Attribute können spezifiziert werden, jedoch mindestens eines muss spezifiziert werden.
  • Die PDP-Kontext Signalisierung ist das Mittel zum Transportieren des angeforderten und verhandelten QoS-Profils zwischen den Knoten in dem UMTS-Netz. PDP-Kontext Signalisierung spielt eine zentrale Rolle für das QoS-Handling in Bezug auf Zulassungskontrolle, Verhandlung und Modifizierung von Trägern auf einer QoS-Ebene. Der Austausch von PDP-Kontext Signalisierungsnachrichten wird nachfolgend unter Bezugnahme auf die Bezugszahlen in 11 beschrieben.
  • In Schritt 1 wird eine RRC-Verbindung aufgebaut. Diese Prozedur ist notwendig, um eine Verbindung zwischen der MS und dem UTRAN aufzubauen. Vom Standpunkt der QoS aus betrachtet beinhaltet die Aufbauphase jedoch kaum mehr, als dass der Typ des Funkkanals angegeben wird, welcher verwendet wird.
  • In Schritt 2 sendet die MS eine PDP-Nachricht an den SGSN, um den PDP-Kontext zu aktivieren. Das angeforderte QoS-Profil ist in dieser Nachricht enthalten. Zu diesem Zeitpunkt führt der SGSN eine Zugangsprüfung durch und könnte die angeforderte QoS einschränken, falls das System überlastet ist.
  • In Schritt 3 sendet der SGSN eine RANAP-Nachricht "RAB Assignment Request" (RAB Zuweisungsanforderung) an den RNC. RANAP, oder Radio Access Network Application Part, ist ein Anwendungsprotokoll zur Unterstützung der Signalisierung und Steuerungsübertragung zwischen dem Funkzugangsnetz (Radio Access Network, "RAN") und dem externen CN. RANAP ermöglicht die Kommunikation zwischen dem RAN und leitungsvermittelten oder paketvermittelten Netzen. Diese Anforderung, einen Funknetz-Trägerdienst aufzubauen, transportiert die RAB QoS-Attribute, welche von dem SGSN modifiziert worden sein können.
  • In Schritt 4 verwendet der RNC die RAB QoS-Attribute, um die mit dem Funk zusammenhängenden Parameter zu bestimmen, die dem QoS-Profil entsprechen. Diese Parameter können Transportformatmenge und Transportformatkombinationsmenge enthalten. Außerdem führt das UTRAN eine Zulassungskontrolle auf diesem Träger durch.
  • In Schritt 5 sendet der RNC eine RRC-Nachricht "Radio Bearer Set-up" (Einrichtung des Funkträgers) an die MS. Die RRC-Nachricht enthält die mit dem Funk zusammenhängenden Parameter, welche in Schritt 4 bestimmt wurden.
  • In Schritt 6 wenden das UTRAN und die MS die Funkparameter an und sind bereit, Verkehr zu übertragen. Um dies zu signalisieren, sendet die MS eine RRC-Nachricht "Radio Bearer Set-up Complete" (Einrichtung des Funkträgers abgeschlossen) an den RNC.
  • In Schritt 7 sendet das UTRAN eine RANAP-Nachricht "RAB Assignment Complete" (RAB-Zuweisung abgeschlossen) an den SGSN.
  • In Schritt 8 kann eine Ablaufverfolgungsprozedur initiiert werden. Dies ist eine Betriebs- und Wartungsfunktion zum Befragen von Teilnehmern.
  • In Schritt 9 sendet der SGSN eine "Create PDP Context Request" (Anforderung, PDP-Kontext zu erzeugen) an den GGSN, welche das QoS-Profil transportiert. Das QoS-Profil kann jedoch andere Parameter aufweisen als diejenigen, welche von der MS in Schritt 2 angefordert wurden. Auf der Basis dieses Profils wird auf der Ebene des GGSN eine Zulassungskontrolle durchgeführt, und der GGSN kann die QoS einschränken, falls zum Beispiel das System überlastet ist. Der GGSN speichert den PDP-Kontext in seiner Datenbank.
  • In Schritt 10 sendet der GGSN die verhandelte QoS an den SGSN in einer Nachricht "Create PDP Context Response" ("PDP-Kontext erzeugen"-Antwort) zurück, und der SGSN speichert den PDP-Kontext in seiner Datenbank.
  • In Schritt 11 wird die verhandelte QoS von dem SGSN in einer Nachricht "Activate PDP Context Accept" (PDP-Kontext aktivieren – Annahme) an die MS gesendet. Falls entweder der SGSN oder der GGSN das QoS-Profil geändert hat, muss die MS dieses Profil entweder annehmen oder zurückweisen.
  • Es sind verschiedene lokale Zulassungskontrollen vorhanden, die während der Prozedur stattfinden. Da jedoch mit Funk verknüpfte Bandbreite die teuerste Ressource ist, wird während der PDP-Kontext Aktivierung oder Modifizierung das UTRAN konsultiert, wenn bestimmt wird, ob Funkressourcen verfügbar sind oder nicht. Somit wird die Zulassungskontrolle bei UMTS auf eine Art und Weise durchgeführt, bei der Funk die zentrale Rolle spielt.
  • Um IP QoS Ende-zu-Ende bereitzustellen, ist es erforderlich, die QoS innerhalb jeder Domain zu verwalten. Es wird ein IP BS Manager im Gateway verwendet, um den externen IP-Trägerdienst zu steuern. Aufgrund der unterschiedlichen Verfahren, die innerhalb des IP-Netzes angewendet werden, kommuniziert dieser mit dem UMTS BS Manager über die Übersetzungsfunktion.
  • Ebenso ist es erforderlich, dass eine IP-Trägerdienst Manager-Funktion in einem UE (Teilnehmergerät) vorgesehen ist, wobei der Trägerdienst-Manager die QoS-Anforderungen der Anwendung auf die entsprechenden QoS-Mechanismen abbildet.
  • 12 zeigt die Ausführungsform zur Steuerung eines IP-Dienstes unter Verwendung eines IP BS Managers an beiden möglichen Orten im UE und im Gateway-Knoten. Die Figur gibt auch den optionalen Kommunikationsweg zwischen den IP BS Managern im UE und im Gateway-Knoten an.
  • Die IP BS Manager verwenden standardmäßige IP-Mechanismen, um den IP-Trägerdienst zu verwalten. Diese Mechanismen können von den Mechanismen verschieden sein, die innerhalb von UMTS verwendet werden, und können andere Parameter aufweisen, welche den Dienst steuern. Die Übersetzungs-/Abbildungsfunktion gewährleistet das Interworking zwischen den Mechanismen und Parametern, die innerhalb des UMTS Trägerdienstes verwendet werden, und jenen, die innerhalb des IP-Trägerdienstes verwendet werden, und interagiert mit dem IP BS Manager.
  • Falls ein IP BS Manager sowohl im UE als auch im Gateway-Knoten existiert, ist es möglich, dass diese IP BS Manager unter Verwendung relevanter Signalisierungsprotokolle direkt miteinander kommunizieren.
  • Obwohl eine Signalisierung auf IP-Ebene wie etwa RSVP von Nutzen sein kann, um Ende-zu-Ende-Signifikanz einer Dienstgüte-Unterstützungs-Anforderung vom Endbenutzer sicherzustellen, hat sie eine Anzahl von Nachteilen. Zu ihnen gehören eine schlechte Funkressourcen-Effizienz, und dass die Dienstdefinition für heterogene Netze möglicherweise nicht geeignet ist und die Prozeduren möglicherweise für bidirektionale Ströme nicht geeignet sind. Dementsprechend besteht Bedarf an einer Signalisierung auf IP-Ebene in Funknetzen bei gleichzeitiger Vermeidung dieser Mängel.
  • KURZDARSTELLUNG
  • Die Erfindung beseitigt eine Anzahl von Unzulänglichkeiten des Standes der Technik durch Verwendung eines Proxy-Verfahrens in einem Funknetz wie etwa UMTS. Es wird eine Lösung für RSVP-Unterstützung und Interworking bereitgestellt.
  • Im Kontext der Erfindung beinhaltet Interworking das Abbilden von Informationen in einem Protokoll auf Informationen in einem anderen Protokoll. Die Informationen können einen Verkehrsdeskriptor oder eine QoS-Definition enthalten. Interworking kann auch das Verwenden von Ereignissen in der Zustandsmaschine einer Seite des Interworkings beinhalten, um Aktionen in der Funktion der anderen Seite des Interworkings auszulösen. Ferner kann Interworking das Verwenden von Informationen beinhalten, die an der Eingangsseite des Interworkings empfangen werden, um das Shaping (Formen)/Marking (Markieren) der Ausgangsseite des Interworkings zu konfigurieren.
  • Gemäß der vorliegenden Erfindung wird ein Verfahren in einem mobilen Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung bereitgestellt, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht. Das Verfahren umfasst die folgenden Schritte: Beenden einer PATH-Nachricht, die von der Endeinrichtung des Benutzers gesendet wurde; Bestimmen, ob ein neuer PDP-Kontext erzeugt oder ein existierender PDP-Kontext geändert werden soll, auf der Basis der in der PATH-Nachricht enthaltenen RSVP-Parameter; und Senden einer Anforderung, den PDP-Kontext zu erzeugen oder zu ändern, über das Funknetz.
  • Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Verfahren in einem mobilen Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung bereitgestellt, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht. Das Verfahren umfasst die Schritte: Empfangen einer Nachricht von dem Funknetz; Bestimmen aus der Nachricht, ob eine Anwendung in der Endeinrichtung RSVP-Signalisierung erfordert; Erzeugen einer PATH-Nachricht; Senden der PATH-Nachricht an die Endeinrichtung; Empfangen einer RESV-Nachricht von der Endeinrichtung; Bestimmen der Anforderungen für einen PDP-Kontext; und Senden einer Anforderung, den PDP-Kontext zu erzeugen oder zu ändern, über das Funknetz.
  • Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Verfahren in einem mobilen Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung bereitgestellt, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht. Das Verfahren umfasst die Schritte: Empfangen einer PATH-Nachricht, die von der Endeinrichtung des Benutzers gesendet wurde; Ändern der PATH-Nachricht entsprechend einer lokalen Konfiguration; Senden der geänderten PATH-Nachricht an das Funknetz; Empfangen einer RESV-Nachricht von dem Funknetz in Reaktion auf die PATH-Nachricht; Bestimmen, ob ein neuer PDP-Kontext erzeugt oder ein existierender PDP-Kontext geändert werden soll, auf der Basis von in der RESV-Nachricht enthaltenen RSVP-Parametern; Senden einer Anforderung, den PDP-Kontext zu erzeugen oder zu ändern, über das Funknetz; Empfangen einer Antwort auf die Anforderung, einen PDP-Kontext zu erzeugen oder zu ändern, von dem Funknetz; und Senden der RESV-Nachricht an die Endeinrichtung.
  • Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Verfahren in einem mobilen Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung bereitgestellt, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht. Das Verfahren umfasst die Schritte: Empfangen einer PATH-Nachricht von dem Funknetz; Senden der PATH-Nachricht an die Endeinrichtung; Empfangen einer RESV-Nachricht von der Endeinrichtung; Bestimmen der Anforderungen für einen PDP-Kontext aus der RESV-Nachricht; Senden einer Anforderung, den PDP-Kontext zu erzeugen oder zu ändern, über das Funknetz; Empfangen einer Antwort auf die Anforderung, den PDP-Kontext zu erzeugen oder zu ändern, von dem Funknetz; und Senden der RESV-Nachricht an das Funknetz.
  • Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Verfahren zum Einbinden von IP QoS-Information in einen PDP-Kontext und zum Transportieren der QoS-Information über ein UMTS-Netz bereitgestellt. Das Verfahren umfasst die Schritte: Einbinden der QoS-Information in den PDP-Kontext; und Interworking zwischen der QoS-Information und RSVP in einem GGSN.
  • Es muss betont werden, dass der Begriff "umfasst" oder "umfassend", wenn er in dieser Beschreibung verwendet wird, benutzt wird, um das Vorhandensein von genannten Merkmalen, ganzen Zahlen, Schritten oder Komponenten anzugeben, jedoch nicht das Vorhandensein oder das Hinzukommen eines oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte oder Komponenten oder von Gruppen davon ausschließt.
  • BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockschaltbild eines High-Level IP-Netzes;
  • 2 ist ein Blockschaltbild, das ein Beispiel eines Netzes darstellt, das Ende-zu-Ende integrierte Dienste verwendet;
  • 3 ist ein Blockschaltbild, das ein Beispiel eines Netzes darstellt, das einen RSVP-Proxy verwendet;
  • 4 ist ein Blockschaltbild, das ein Beispiel eines Netzes darstellt, das Ende-zu-Ende differenzierte Dienste verwendet;
  • 5 ist ein Blockschaltbild, das ein Beispiel eines Netzes darstellt, das RSVP-Signalisierung im Interworking mit differenzierten Diensten verwendet;
  • 6 ist ein Blockschaltbild, das ein Mobilfunk-Zugangsdatennetz darstellt, das als ein DiffServ modelliert ist;
  • 7 ist ein Blockschaltbild einer UMTS QoS-Architektur;
  • 8 ist ein Blockschaltbild, das QoS Management-Funktionen für UMTS Trägerdienst in der Steuerungsebene darstellt;
  • 9 ist ein Blockschaltbild, das QoS Management-Funktionen für UMTS Trägerdienst in der Benutzerebene darstellt;
  • 10 ist ein Blockschaltbild der Beziehung zwischen PDP-Adresse, PDP-Kontext und TFT;
  • 11 ist ein Schema des Nachrichtenaustausches des PDP-Kontexts;
  • 12 ist ein Blockschaltbild der QoS Management-Funktionen für UMTS Trägerdienst in der Steuerungsebene und QoS Management-Funktionen für Ende-zu-Ende IP QoS;
  • 13 ist ein Schema, das IP-Signalisierung darstellt, welche für das UMTS-Netz transparent ist;
  • 14 ist ein Schema, das IP-Signalisierung darstellt, welche im GGSN interpretiert wird;
  • 15 ist ein Funktionsblockdiagramm der ersten Ausführungsform der Erfindung;
  • 16 ist ein Nachrichtenflussdiagramm der ersten Ausführungsform der Erfindung, in welchem das MT eine PATH-Nachricht von der TE empfängt;
  • 17 ist ein Nachrichtenflussdiagramm der ersten Ausführungsform der Erfindung, in welchem das MT Daten vom Netz empfängt;
  • 18 ist ein Funktionsblockdiagramm der zweiten Ausführungsform der Erfindung;
  • 19 ist ein Nachrichtenflussdiagramm der zweiten Ausführungsform der Erfindung, in welchem das MT eine PATH-Nachricht von der TE empfängt;
  • 20 ist ein Nachrichtenflussdiagramm der zweiten Ausführungsform der Erfindung, in welchem das MT eine PATH-Nachricht vom Netz empfängt;
  • 21 ist ein Funktionsblockdiagramm der dritten Ausführungsform der Erfindung;
  • 22 ist ein Nachrichtenflussdiagramm der dritten Ausführungsform der Erfindung, in welchem das MT eine PATH-Nachricht von der TE empfängt;
  • 23 ist ein Nachrichtenflussdiagramm der dritten Ausführungsform der Erfindung, in welchem das MT eine PATH-Nachricht vom Netz empfängt;
  • 24 ist ein Nachrichtenflussdiagramm der dritten Ausführungsform der Erfindung, welche die Aufbauphase und die Datenphase definiert;
  • 25 ist ein Signalflussdiagramm, in welchem das UE IP-spezifische Elemente in der PDP-Kontext-Nachricht unterstützt und der GGSN Interworking mit RSVP gewährleistet;
  • 26 ist ein Funktionsblockdiagramm der vierten Ausführungsform der Erfindung;
  • 27 ist eine Prinzipskizze eines Netzmodells, welches die vierte Ausführungsform der Erfindung beinhaltet;
  • 28 ist ein Nachrichtenflussdiagramm der vierten Ausführungsform der Erfindung, in welchem der GGSN RSVP-Nachrichten für den Uplink-Strom aufruft;
  • 29 ist ein Nachrichtenflussdiagramm der vierten Ausführungsform der Erfindung, in welchem der GGSN RSVP-Nachrichten für den Downlink-Strom beendet und aufruft;
  • 30 ist ein Nachrichtenflussdiagramm, welches die Phasen des Aufbaus des Trägers zeigt; und
  • 31 ist ein Signalflussdiagramm, in welchem das UE IP-spezifische Elemente in der PDP-Kontext-Nachricht unterstützt und der GGSN Interworking mit DiffServ gewährleistet.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Obwohl eine Signalisierung auf IP-Ebene wie etwa RSVP verwendet werden kann, um Ende-zu-Ende-Signifikanz einer Dienstgüte-Unterstützungs-Anforderung vom Endbenutzer sicherzustellen, weist sie eine Anzahl von Unzulänglichkeiten auf.
  • Die Erfindung beseitigt eine Anzahl von Unzulänglichkeiten, die mit der Signalisierung auf IP-Ebene über Funknetze zusammenhängen, durch Verwendung eines Proxy-Verfahrens. Dementsprechend können Verfahren der Signalisierung auf IP-Ebene wie etwa RSVP über ein Funknetz wie etwa UMTS verwendet werden, ohne wertvolle Funkbandbreite zu verschwenden. Wie leicht einzusehen ist, kann die Signalisierung auf IP-Ebene transparent für das UMTS-Netz sein, oder die Signalisierung auf IP-Ebene kann im GGSN interpretiert werden. Bevor die Erfindung anhand ihrer Ausführungsformen erörtert wird, ist es nützlich, die Prinzipien des Interworking zu erörtern, die bei diesen zwei Fällen der IP-Signalisierung eine Rolle spielen.
  • 15 zeigt ein Funktionsblockdiagramm einer Netzkonfiguration zwischen der Endeinrichtung (Terminal Equipment, "TE") des Benutzers und dem externen Netz. Wie in dem Diagramm dargestellt ist, ist die TE des Benutzers mit dem mobilen Endgerät (Mobile Terminal, "MT") verbunden. Die TE kann irgendeines aus einer Vielzahl von bekannten Rechengeräten sein, wie etwa ein tragbarer Computer oder ein persönlicher Datenassistent. Das MT bedient die Schnittstelle zum Kommunikationsnetz wie etwa einem UMTS- oder anderen Funknetz. Wie leicht einzusehen ist, kann das MT physisch in die TE integriert sein oder mit der TE durch Kabel, Infrarotverbindung oder mit einem anderen Verfahren verbunden sein.
  • Das UTRAN oder UMTS Funkzugangsnetz beendet die Funkverbindung von dem MT. Das UTRAN wickelt die Aufgaben ab, die mit der Aufrechterhaltung der physischen Verbindung zum MT zusammenhängen, und hat keine Kenntnis von Anwendungen, welche möglicherweise auf der TE oder dem MT ausgeführt werden. Ähnlich hat das UTRAN keine Kenntnis von Netzteilnehmern.
  • Das UMTS/GPRS Kernnetz stellt Routing und den Zugang zum externen Internet zur Verfügung. Somit werden über UMTS gesendete Daten empfangen und für die Übertragung zum IP-Netz geeignet formatiert. Ebenso werden Daten, die vom IP-Netz empfangen werden, für die Übertragung über das UMTS geeignet formatiert.
  • 15 zeigt auch eine Anzahl von Funktionen, die mit den einzelnen Knoten verknüpft sind. Anwendungsfunktionen enthalten im Allgemeinen irgendeine Anwendung, welche einen Kommunikationsweg erfordert und von der TE oder dem MT ausgeführt werden kann. Beispiele von üblichen Anwendungsfunktionen sind Web-Browser, Multimedia-Clients und Audiotools.
  • Ebenfalls innerhalb der TE und des MT sind IP-Signalisierungsfunktionen vorhanden. Diese Funktionen wickeln die Signalisierung auf der IP-Ebene ab, wie etwa RSVP.
  • UMTS-Funktionen wickeln die Aufgaben ab, die mit dem Kommunizieren in einem UMTS-Netz zusammenhängen. Diese Aufgaben können PDP Mobilitätsmanagement, Verbindungsmanagement, Funkressourcenmanagement und Handover-Prozeduren umfassen.
  • IP-Funktionen umfassen IP-Routing, welches erforderlich sein kann, um IP-Pakete in einem IP-Netz weiterzuleiten.
  • Obwohl 15 nur den Netzknoten von der TE bis zum externen Netz zeigt, ist leicht einzusehen, dass der Benutzer wahrscheinlich wünschen wird, eine Verbindung zu einer TE eines anderen Benutzers oder einem bestimmten Anwendungsserver herzustellen. Diese zweite TE oder dieser Server kann mit dem externen Netz auf dieselbe oder eine ähnliche Weise verbunden sein, wie in 15 dargestellt.
  • Bei einer Ausführungsform der Erfindung wird die IP-Signalisierung im MT beendet. 16 ist ein Nachrichtenflussdiagramm, wobei die TE eine PATH-Nachricht initiiert und das MT die RSVP-Signalisierung beendet. Wenn die PATH-Nachricht empfangen wird, empfängt das MT sämtliche RSVP-Parameter und bestimmt, ob ein neuer sekundärer PDP-Kontext erzeugt oder ein existierender geändert werden soll, um den Verkehr zu transportieren. Der sekundäre PDP-Kontext wird dann auf eine Art und Weise erzeugt oder geändert, die durch Standards definiert und in der Technik bekannt ist.
  • Sobald der sekundäre PDP-Kontext erfolgreich aufgebaut worden ist, kann das MT eine RSVP-Proxy instanzieren. Der RSVP kann sich in einem Modus befinden, in dem der RSVP-Proxy die Signalisierung beendet. In diesem Modus kann der RSVP-Proxy eine PATH-Nachricht empfangen und eine RESV-Antwort erzeugen. Das MT kann ebenfalls auf die ursprüngliche PATH-Nachricht mit einer RESV-Nachricht antworten.
  • 17 ist ein entsprechendes Nachrichtenflussdiagramm, wobei das MT die RSVP-Signalisierung beendet und ankommende Daten vom externen Netz vorhanden sind. In diesem Falle initiiert das MT die PATH-Nachricht. Damit das MT die RSVP PATH initiiert, muss es irgendeine Aktion geben, welche eintritt, um dies auszulösen. Der Auslöser könnte aus dem Empfangen von Daten in einem existierenden sekundären PDP- Kontext resultieren, welcher mit einer bestimmten Filterspezifikation übereinstimmt, welche erkennt, dass dieser Verkehr mit einer anderen QoS versehen sein sollte. Eine andere Möglichkeit ist, falls der Benutzer das MT konfiguriert (entweder direkt oder über eine API von der TE), sich auf einen erwarteten Datenstrom vorzubereiten.
  • Falls das MT bestimmt, dass die Anwendung RSVP-Signalisierung erfordert, so initiiert das MT eine PATH-Nachricht. Beim Empfangen der RESV-Nachricht von der TE können die Anforderungen für den PDP-Kontext bestimmt werden, und der sekundäre PDP-Kontext kann erzeugt/modifiziert werden.
  • Das MT muss außerdem Timer ausführen, die für die RSVP-Prozeduren geeignet sind. Zum Beispiel kann das MT in Reaktion auf den periodischen Ablauf des Timers eine PATH-Nachricht an die TE senden. Das MT muss so konfiguriert sein, dass es bestimmt, welche Aktion durchzuführen ist, falls die RESV-Nachricht nicht von der TE empfangen wird. Zum Beispiel kann das MT bestimmen, dass die Anwendung nicht mehr auf der TE ausgeführt wird und der Kommunikationsweg, der durch den PDP-Kontext definiert ist, nicht mehr benötigt wird.
  • Wie man leicht sieht, ermöglicht diese Ausführungsform das Interworking von zwei verschiedenen Protokollen. 13 zeigt die Prinzipien des Interworkings in dem Fall, wenn die IP-Signalisierung (RSVP) für das UMTS-Netz transparent ist. In diesem Fall stellt das UE, welches sowohl die TE als auch das MT umfassen kann, eine IP-Trägerdienst- (Bearer Service, "BS") Funktion zur Verfügung, welche Ende-zu-Ende-QoS unter Verwendung von IP-Schicht-Signalisierung zum entfernten Ende ermöglicht. Es ist keine IP-Schicht-Signalisierung zwischen den IP BS Managern in dem UE und im GGSN vorhanden. Jedoch kann der GGSN Informationen betreffs des PDP-Kontextes nutzen, welche zwischen den UMTS BS Managern signalisiert wird und über die Übersetzungs-/Abbildungsfunktion zur Verfügung gestellt wird.
  • In 13 wird angenommen, dass das UE und der GGSN DiffServ Edge-Funktionen unterstützen und dass das Backbone-IP-Netz DiffServ-fähig ist. Außerdem kann das UE RSVP-Signalisierung unterstützen, welche innerhalb des UE ein Interworking realisiert, um die DiffServ zu steuern.
  • Die Steuerung der QoS über das UMTS-Zugangsnetz (vom UE zum GGSN) kann vom Endgerät aus unter Verwendung der PDP-Kontext-Signalisierung durchgeführt werden. Stattdessen können auch Abonnementsdaten, auf die durch den SGSN zugegriffen wird, die QoS überschreiben, die mittels Signalisierung vom UE angefordert wird.
  • Das Endgerät kann Signalisierung über das RSVP-Protokoll unterstützen, um die QoS am lokalen und am entfernten Zugang zu steuern. Das Endgerät kann auch DiffServ unterstützen, um die IP QoS über das Backbone-IP-Netz zu steuern. Das RSVP Signalisierungsprotokoll kann für verschiedene Dienste verwendet werden. Es ist zu erwarten, dass nur RSVP, das die Integrated Services ("IntServ") Semantik verwendet, unterstützt wird, obwohl in der Zukunft neue Dienstdefinitionen und Semantiken eingeführt werden können. Die Entitäten, welche die RSVP-Signalisierung unterstützen, unterstützen möglicherweise vollständig ebenso die Spezifikationen für IntServ und IntServ/DiffServ Interworking. Wenn nicht, ist zu erwarten, dass sie das Break-Bit setzen.
  • Die QoS für den drahtlosen Zugang wird durch den PDP-Kontekt gewährleistet. Das UE kann die QoS des drahtlosen Zugangs durch Signalisierung für den PDP-Kontext steuern. Die Eigenschaften für den PDP-Kontext können aus der RSVP-Signalisierungsinformation abgeleitet werden, oder sie können andere Informationen verwenden.
  • QoS für die IP-Schicht wird auf zwei Ebenen ausgeführt. Die Ende-zu-Ende-QoS wird durch die RSVP-Signalisierung gesteuert. Obwohl RSVP-Signalisierung im QoS-Modell Ende-zu-Ende verwendet werden kann, wird sie nicht zwangsläufig von allen Zwischenknoten unterstützt. Stattdessen wird DiffServ verwendet, um die QoS über das Backbone-IP-Netz bereitzustellen.
  • Am UE werden die Daten ebenfalls für DiffServ klassifiziert. Dazwischenliegende QoS Domains können QoS gemäß entweder der RSVP-Signalisierungsinformation oder DiffServ Mechanismen anwenden. Bei dieser Ausführungsform gewährleistet das UE Interworking zwischen den RSVP und DiffServ Domains. Der GGSN kann die DiffServ Einstellung vom UE aufheben. Dieser GGSN kann Informationen betreffs des PDP-Kontextes verwenden, um die geeignete anzuwendende DiffServ Einstellung zu wählen, wie in 13 dargestellt ist.
  • Die Ende-zu-Ende-QoS wird von einem lokalen Mechanismus im UE, dem PDP-Kontext über das UMTS-Zugangsnetz, DiffServ durch das Backbone-IP-Netz hindurch und DiffServ im entfernten Zugangsnetz bereitgestellt, welche ebenfalls in 13 dargestellt sind. Die RSVP-Signalisierung kann die QoS sowohl am lokalen als auch am entfernten Zugang steuern. Diese Funktion kann verwendet werden, um die Eigenschaften für den PDP-Kontext zu bestimmen, so dass das UE das Interworking zwischen der RSVP-Signalisierung und dem PDP-Kontext durchführen kann.
  • Das UE kann eine Steuerung des DiffServ zur Verfügung stellen, obwohl diese von dem GGSN überschrieben werden kann. In Wirklichkeit bestimmt das UE das geeignete Interworking zwischen dem PDP-Kontext und DiffServ.
  • Bei dieser Ausführungsform kann das Interworking durch Abbilden von Informationen in einem Protokoll auf Informa tionen in einem anderen Protokoll durchgeführt werden. Zum Beispiel wird in dem Fall, wenn die TE die PATH-Nachricht erzeugt, der Verkehrsdeskriptor im RSVP PATH auf verschiedene UMTS-Attribute abgebildet, und die QoS-Definition in den UMTS-Attributen wird auf die RSVP RESV Antwort abgebildet. Ebenso kann in dem Fall, wenn das MT die PATH-Nachricht erzeugt, der Verkehrsdeskriptor im MT konfiguriert werden, oder Informationen, die von der Anwendungsfunktion im MT erzeugt wurden, können auf den RSVP PATH abgebildet werden. Die QoS-Definition in der RSVP RESV kann auf die UMTS-Attribute abgebildet werden.
  • Das Interworking kann auch durchgeführt werden, indem Ereignisse in der Zustandsmaschine eines Protokolls verwendet werden, um Aktionen in Funktionen auszulösen, die das andere Protokoll implementieren. Zum Beispiel kann in dem Fall, wenn die TE die PATH-Nachricht erzeugt, der Empfang der PATH-Nachricht die Erzeugung oder Änderung eines sekundären PDP-Kontextes auslösen. Der Empfang einer "PDP-Kontext erzeugen/ändern"-Antwort löst die Erzeugung von RSVP RESV aus und ist auch eine Bedingung für die Erzeugung von RSVP RESV mit der Angabe, dass der Strom angenommen wird. Ähnlich aktiviert in dem Fall, wenn das MT die PATH-Nachricht erzeugt, ein von der Anwendungsfunktion im MT erzeugter Auslöser RSVP PATH. Der Empfang einer "PDP-Kontext erzeugen/ändern"-Antwort löst den Start der Erzeugung einer RSVP Soft-State Nachricht aus.
  • Diese Ausführungsform ermöglicht Standardanwendungen in einer TE wie etwa einem Laptop, auf dem ein netzfähiges Betriebssystem wie etwa Microsoft Windows läuft, einen standardmäßigen IP-Signalisierungsmechanismus wie etwa RSVP zu verwenden. Normalerweise erfordert dieser Typ von Mechanismus zusätzliches Overhead, welches das Funknetz übermäßig belasten kann. Bei dieser Ausführungsform muss die IP-Signalisierung nicht über das Funknetz gesendet werden, was zur Folge hat, dass die Funkressourcen optimiert werden.
  • Dies ist insbesondere wichtig, wenn RSVP-Signalisierung verwendet wird, da RSVP-Signalisierung regelmäßig Soft-State-Information für "Keep-Alive"- und andere Zwecke erzeugen muss.
  • 18 zeigt ein Funktionsblockdiagramm einer Netzkonfiguration zwischen der Endeinrichtung (Terminal Equipment, "TE") des Benutzers und dem externen Netz. Diese Figur enthält viele der Komponenten, die zuvor im Zusammenhang mit 15 beschrieben wurden. In 18 wird die IP-Signalisierung Ende-zu-Ende verwendet. Dementsprechend wurden den UMTS/GPRS-Kernnetzknoten und dem externen Netz IP-Signalisierungsfunktionen hinzugefügt. Wie zuvor kann das entfernte Ende, welches ein anderer Benutzer oder ein externer Anwendungsserver sein kann, auf ähnliche Weise mit dem externen Netz verbunden sein.
  • Die in 18 dargestellte Netzkonfiguration kann zu einer anderen Ausführungsform der Erfindung gehören. Bei dieser Ausführungsform wird die IP-Signalisierung zu der entfernten Seite übertragen. 19 ist ein Nachrichtenflussdiagramm, in welchem das MT die ankommende PATH-Nachricht von der TE abfängt. Wenn das MT die PATH-Nachricht empfängt, kann das MT die PATH-Parameter ändern, so dass sie einer lokalen Konfiguration entsprechen. Die PATH-Nachricht wird dann zum Netz weitergeleitet. Wenn die RESV-Antwort durch das MT empfangen wird, verwendet das MT die Informationen in der RESV-Antwort zusammen mit der relevanten lokalen Konfiguration, um endgültig die Parameter zu bestimmen, die für den PDP-Kontext erforderlich sind. Das MT erzeugt oder ändert dann einen PDP-Kontext, um diese Netzparameter widerzuspiegeln, und die angepasste RESV-Nachricht wird weiter zur TE gesendet. Auf diese Weise können die verschiedenen Netzkomponenten die Dienstparameter auf der Basis der verfügbaren Ressourcen ändern.
  • 20 ist ein entsprechendes Nachrichtenflussdiagramm, in welchem das MT die PATH-Nachricht von dem externen Netz weiterleitet, jedoch die RESV-Antwort von der TE abfängt. Wenn die PATH-Nachricht über die Funkschnittstelle empfangen wird, wird die PATH-Nachricht zur TE weitergesendet. Wenn die TE mit der RESV-Nachricht antwortet, fängt das MT sie ab und kann die RESV-Parameter ändern, so dass sie einer lokalen Konfiguration entsprechen. Das MT kann auch einen PDP-Kontext erzeugen oder ändern, um diese gewünschten Netzparameter zu widerspiegeln. Die Anforderung, einen PDP-Kontext zu erzeugen oder zu ändern, wird zum Netz weitergeleitet, um den PDP-Kontext aufzubauen. Sobald der PDP-Kontext aufgebaut ist, wird die geänderte RESV-Nachricht weitergesendet.
  • Wie man leicht sieht, ermöglicht diese Ausführungsform das Interworking von zwei verschiedenen IntServ-Diensten oder zwei Instanzen desselben Dienstes mit unterschiedlichen Parametern. Dieses Interworking kann durchgeführt werden, indem Informationen in einem Protokoll auf Informationen in einem anderen Protokoll abgebildet werden. Zum Beispiel enthält in dem Fall, wenn die TE die PATH-Nachricht erzeugt, die resultierende RESV-Nachricht verschiedene UMTS-Attribute, die verwendet werden, um den PDP-Kontext zu erzeugen oder zu ändern. Die UMTS-Attribute in der empfangenen "PDP-Kontext erzeugen/ändern"-Antwort werden auf entsprechende Parameter in der RESV-Nachricht abgebildet und zur TE gesendet. Ähnlich enthält in dem Fall, wenn das MT die PATH-Nachricht vom Netz empfängt, die entsprechende RESV-Nachricht, die von der TE empfangen wird, Parameter, welche auf verschiedene UMTS-Attribute abgebildet werden und verwendet werden, um eine Nachricht "PDP-Kontext erzeugen oder ändern" zu erzeugen. Die UMTS-Attribute, die vom Netz in der "PDP-Kontext erzeugen/ändern"-Antwort empfangen werden, werden auf Parameter in der RESV-Nachricht abgebildet, welche durch das Netz hindurch übertragen wird. Auf diese Weise können Verkehrsdeskriptor und QoS-Parameter von einem Protokoll auf ein anderes abgebildet werden.
  • Das Interworking kann auch durchgeführt werden, indem Ereignisse in der Zustandsmaschine eines Protokolls verwendet werden, um Aktionen in Funktionen auszulösen, die das andere Protokoll implementieren. Zum Beispiel löst in dem Fall, wenn die TE die PATH-Nachricht erzeugt, das Empfangen der RESV-Nachricht am MT die Erzeugung einer Nachricht "PDP-Kontext erzeugen oder ändern" aus. Ein erfolgreicher Empfang der RESV-Nachricht ist auch eine Bedingung für die Erzeugung einer Nachricht "PDP-Kontext erzeugen/ändern". Ähnlich löst der Empfang einer "PDP-Kontext erzeugen oder ändern"-Antwort im MT die Erzeugung der RESV-Nachricht aus, die an die TE gesendet wird, und ist auch eine Bedingung für die Erzeugung einer RESV-Nachricht mit einer Angabe, dass der Strom angenommen wird. Ebenso löst in dem Fall, wenn die PATH-Nachricht über das Netz empfangen wird, der Empfang einer RESV-Nachricht am MT die Erzeugung einer Nachricht "PDP-Kontext erzeugen oder ändern" aus. Wenn das MT eine "PDP-Kontext erzeugen/ändern"-Antwort empfängt, löst dieses Ereignis eine RESV-Nachricht aus, die an die entfernte Seite gesendet wird. Ein erfolgreicher Empfang der "PDP-Kontext erzeugen/ändern"-Antwort ist auch eine Bedingung für die Erzeugung einer RESV-Nachricht mit einer Angabe, dass der Strom angenommen wird. Der Empfang der PATH-Nachricht kann die Erzeugung oder Änderung eines sekundären PDP-Kontextes auslösen. Der Empfang einer "PDP-Kontext erzeugen/ändern"-Antwort löst die Erzeugung von RSVP RESV aus und ist außerdem eine Bedingung für die Erzeugung von RSVP RESV mit einer Angabe, dass der Strom angenommen wird.
  • Diese Ausführungsform ermöglicht Standardanwendungen, die auf einer TE laufen, wie etwa Laptops mit einem netzfähigen Betriebssystem wie etwa Microsoft Windows, einen standardmäßigen IP-Signalisierungsmechanismus wie etwa RSVP zu verwenden. Der RSVP-Signalisierung wird Interworking mit UMTS-Signalisierung in dem MT ermöglicht, und sie wird Ende-zu-Ende übertragen, um dem entfernten Gerät zu ermöglichen, mit dem UMTS-System und den UMTS-Endgeräten zu interagieren. Dementsprechend stellt diese Ausführungsform Ende-zu-Ende Abwicklung für die Steuerung von Ende-zu-Ende User Flows bereit.
  • Ein potentieller Nachteil dieser Ausführungsform ist die Notwendigkeit, Ende-zu-Ende RSVP-Signalisierung weiterhin zu unterstützen, nachdem der PDP-Kontext aufgebaut worden ist. Wie weiter oben angemerkt wurde, erfordert eine Unterstützung von RSVP-Signalisierung den Transport von periodischen PATH-Nachrichten und RESV-Antworten. Dies kann eine ineffiziente Nutzung von Funkbandbreite zur Folge haben.
  • 21 zeigt ein Funktionsblockdiagramm einer Netzkonfiguration zwischen der Endeinrichtung (Terminal Equipment, "TE") des Benutzers und dem externen Netz. Diese Figur enthält viele der Komponenten, die zuvor im Zusammenhang mit den 15 und 17 beschrieben wurden. In 21 wird der Signalisierungsweg zwischen dem MT und dem UMTS/GPRS-Kernnetzknoten nur während des Aufbaus des PDP-Kontextes verwendet. Während der Datenphase wird von dem MT und dem GGSN eine gesonderte Prozedur angewendet. Wie zuvor kann das entfernte Ende, welches ein anderer Benutzer oder ein externer Anwendungsserver sein kann, auf ähnliche Weise mit dem externen Netz verbunden sein.
  • Die in 21 dargestellte Netzkonfiguration kann zu einer anderen Ausführungsform der Erfindung gehören. Bei dieser Ausführungsform wird die RSVP-Sitzung Ende-zu-Ende verwendet. Jedoch ist ein RSVP-Proxy in einem Leistungsverbesserungs-Modus am MT und Gateway eingefügt. Der Zweck des Proxys in diesem Modus ist es, die Natur der RSVP-Sitzung durch Benutzen des sekundären PDP-Kontextes von einem Soft-State zu einem Hard-State zwischen den zwei Proxys zu än dern. Dies verbessert die Zuverlässigkeit der RSVP-Sitzung und bewirkt eine Verringerung des Umfangs der Signalisierung über die Funkschnittstelle.
  • 22 ist ein Nachrichtenflussdiagramm, welches den Fall widerspiegelt, wenn das MT den RSVP-Proxy benutzt, um in Reaktion auf eine ankommende PATH-Nachricht von der TE RSVP-Signalisierung weiterzuleiten. Wie bei der vorhergehenden Ausführungsform kann das MT, wenn das MT die PATH-Nachricht empfängt, die PATH-Parameter ändern, so dass sie einer lokalen Konfiguration entsprechen. Die PATH-Nachricht wird dann zum Netz weitergeleitet. Wenn die RESV-Antwort durch das MT empfangen wird, verwendet das MT die Informationen in der RESV-Antwort zusammen mit der relevanten lokalen Konfiguration, um endgültig die Parameter zu bestimmen, die für den PDP-Kontext erforderlich sind. Das MT erzeugt oder ändert dann einen PDP-Kontext, um diese Netzparameter widerzuspiegeln, und die angepasste RESV-Nachricht wird weiter zur TE gesendet.
  • Beim Empfang der Anforderung des sekundären PDP-Kontextes wird ein RSVP-Proxy-Dienst instanziert. Diese Instanz des RSVP-Proxy-Dienstes ist mit der RSVP-Sitzung zum externen Netz hin verknüpft, wie bei normaler RSVP-Signalisierung. Sobald der sekundäre PDP-Kontext und der Proxy-Dienst aufgebaut sind, wird die RESV dann wie zuvor zur TE weitergesendet. Nach diesem Zeitpunkt werden die am MT empfangenen PATH-Nachrichten lokal beantwortet, und PATH-Nachricht werden periodisch am Gateway erzeugt. Nur wenn Änderungen in der RSVP-Sitzung vorhanden sind, wird die aktualisierte PATH- oder RESV-Nachricht zu dem anderen Proxy übertragen.
  • Für die RSVP-Sitzung vom externen Netz ist die Sequenz ähnlich wie bei Ende-zu-Ende, mit der Ausnahme, dass der lokale Proxy mit dem PDP-Kontext installiert ist. Dies ist in 23 dargestellt.
  • 14 zeigt die Prinzipien es Interworking in dem Fall, wenn die IP-Signalisierung (RSVP) in GGSN interpretiert wird und für das Interworking mit dem Backbone verwendet wird. In diesem Fall führt das UE eine IP BS Funktion aus, welche Ende-zu-Ende-QoS unter Verwendung von IP-Schicht-Signalisierung zum entfernten Ende ermöglicht. Das UE ist jedoch darauf angewiesen, dass diese Ende-zu-Ende-Kommunikation wenigstens von dem Zugangspunkt (GGSN) benutzt wird, um die Ende-zu-Ende-QoS bereitzustellen.
  • In 14 wird angenommen, dass das UE und GGSN RSVP-Signalisierung unterstützen, welche die QoS direkt steuern oder mit DiffServ zusammenwirken kann. Das Backbone-IP-Netz kann RSVP, DiffServ oder beides unterstützen.
  • Das Endgerät kann Signalisierung über das RSVP-Protokoll unterstützen, um die QoS entlang des Ende-zu-Ende-Weges zu steuern. Der GGSN unterstützt ebenfalls RSVP-Signalisierung und verwendet diese Informationen anstelle des PDP-Kontextes, um die QoS durch das Backbone-IP-Netz zu steuern. Es ist zu erwarten, dass die Steuerung der QoS durch den Kern durch Interworking mit DiffServ am GGSN unterstützt wird, obwohl sie optional durch Ressourcenreservierung per Flow unterstützt werden kann. Das RSVP-Signalisierungsprotokoll kann für verschiedene Dienste verwendet werden. Es ist nur zu erwarten, dass nur RSVP, das die Integrated Services (IntServ) Semantik verwendet, unterstützt wird, obwohl in der Zukunft neue Dienstdefinitionen und Semantiken eingeführt werden können. Die Entitäten, welche die RSVP-Signalisierung unterstützen, unterstützen möglicherweise vollständig die Spezifikationen für IntServ und IntServ/DiffServ Interworking. Wenn nicht, ist zu erwarten, dass sie das Break-Bit setzen.
  • Die Steuerung der QoS über das UMTS-Zugangsnetz (vom UE bis zum GGSN) kann vom Endgerät aus unter Verwendung der PDP-Kontext-Signalisierung durchgeführt werden. Stattdessen können auch Abonnementsdaten, auf die durch den SGSN zugegriffen wird, die QoS überschreiben, die mittels Signalisierung vom UE angefordert wird.
  • QoS für die IP-Schicht wird auf zwei Ebenen ausgeführt. Die Ende-zu-Ende-QoS wird durch die RSVP-Signalisierung gesteuert. Obwohl RSVP-Signalisierung im QoS-Modell Ende-zu-Ende erfolgt, wird sie nicht zwangsläufig von allen Zwischenknoten unterstützt. DiffServ wird verwendet, um die QoS im gesamten Backbone-IP-Netz bereitzustellen, obwohl optional jeder Knoten RSVP-Signalisierung und Zuweisung von Ressourcen per Flow unterstützen kann.
  • Der GGSN unterstützt die RSVP-Signalisierung und wirkt als der Interworking-Punkt zwischen RSVP und DiffServ. Dazwischenliegende QoS Domains können QoS gemäß entweder den RSVP oder DiffServ Mechanismen anwenden.
  • Bei der Ausführungsform, die in der untenstehenden Figur dargestellt ist, wird die Ende-zu-Ende-QoS von einem lokalen Mechanismus im UE, dem PDP-Kontext über das UMTS-Zugangsnetz, DiffServ durch das Backbone-IP-Netz hindurch und RSVP im entfernten Zugangsnetz bereitgestellt. Die RSVP-Signalisierung kann die QoS am lokalen Zugang steuern. Diese Funktion kann verwendet werden, um die Eigenschaften für den PDP-Kontext zu bestimmen, so dass das UE das Interworking zwischen RSVP und dem PDP-Kontext durchführen kann.
  • Wie in 24 dargestellt, stellt diese Ausführungsform eine Gateway-Funktion in GGSN zur Verfügung, welche einen RSVP-Proxy emuliert, wenn der User Flow in die Datenphase eintritt. Die Ausführungsform ermöglicht Standardanwendungen in einer TE, wie etwa Laptops mit einem netzfähigen Betriebssystem wie etwa Microsoft Windows, einen standardmäßigen IP-Signalisierungsmechanismus wie etwa RSVP zu verwenden. Während der Aufbauphase wird der RSVP-Signalisierung Interworking in dem MT ermöglicht, wie für die vor hergehende Ausführungsform beschrieben, und sie wird Ende-zu-Ende signalisiert, um dem entfernten Gerät zu ermöglichen, mit dem UMTS-System/Endgeräten zu interagieren. Während der Datenphase erfolgt das Soft-State-Handling, d.h. das regelmäßige Erzeugen von Soft-State-Information für "Keep-Alive"- und andere Zwecke, lokal im MT und im GGSN. Diese Ausführungsform optimiert die Funkressourcen, da die IP-Signalisierung während der Datenphase nicht über Funk gesendet werden muss. Diese Optimierung wird erreicht, ohne die Ende-zu-Ende Abwicklung während der Aufbauphase zu beeinträchtigen.
  • Auf der Basis der vorhergehenden Ausführungsformen können die Funktionen zum GGSN und zum MT hinzugefügt werden, um Interworking-Fähigkeiten im GGSN und MT bereitzustellen. Zum Beispiel kann das MT mit einem IP BS Manager und einer Interworking-Funktion zwischen dem IP BS Manager und UMTS-Funktionen ausgestattet sein. Dies ermöglicht einen "Huckepack-Transport" von Verkehrsdeskriptor und QoS-Informationen, die im IP BS Manager erzeugt wurden, in Nachrichten der PDP-Kontext-Aktivierung/Änderung. Außerdem kann der GGSN mit einer IP BS Manager-Funktionalität ausgestattet sein, welche Verbindungszulassungskontrolle und Interworking mit anderen Netzmanagement-Komponenten wie etwa Bandbreiten-Brokern durchführen kann. Der IP BS Manager im GGSN kann auch mit Policy-Decision-Funktionen im Netz zusammenwirken. Der GGSN kann mit einer Interworking-Funktion zwischen UMTS-Funktionen und IP BS Manager ausgestattet sein. 25 zeigt die Prinzipien des Interworking, die zur Anwendung kommen, wenn der GGSN IP-Signalisierung zum externen Netz unterstützt und emuliert.
  • Bei dieser Ausführungsform führt das UE eine IP BS Funktion aus, welche Ende-zu-Ende-QoS ohne IP-Schicht-Signalisierung und Verhandlung zur IP BS Funktion im GGSN oder zum entfernten Host ermöglicht. Das UE liefert dem GGSN Informationen über Ende-zu-Ende-QoS auf IP-Ebene unter Verwendung IP-spezifischer Elemente der Kontext-Aktivierungs-/Änderungs-Nachricht, um die Interworking-Optionen zu einer RSVP-Funktion im GGSN zu verbessern. Der Ende-zu-Ende IP QoS Trägerdienst zum entfernten Host wird vom GGSN gesteuert.
  • Für die Ausführungsform wird vorausgesetzt, dass der GGSN DiffServ Edge-Funktionen unterstützt und dass das Backbone-IP-Netz DiffServ-fähig ist. Diese Ausführungsform schließt nicht aus, dass das Backbone-IP-Netz RSVP nicht-transparente Router aufweist.
  • Der GGSN kann die IP-spezifischen Elemente in einer PDP-Kontext-Aktivierungs-/Änderungs-Nachricht verwenden, um RSVP-Nachrichten aufzurufen, um den Uplink- sowie die Downlink-Strom im Backbone-IP-Netz bis zum entfernten Host einzurichten. Zum Beispiel kann der GGSN in der Uplink-Richtung die IP-spezifischen Elemente in einer PDP-Kontext-Aktivierungs-/Änderungs-Nachricht verwenden, um die RSVP PATH-Nachrichten mit den gewünschten QoS- und Verkehrs-Spezifikationen zu der spezifizierten Ziel-IP-Adresse zu erzeugen. Außerdem kann die GGSN DiffServ Edge-Funktion die IP-spezifischen Elemente in einer PDP-Kontext-Aktivierungs-/Änderungs-Nachricht verwenden, um die geeignete anzuwendende DiffServ-Einstellung zu wählen. IP-spezifische Elemente der PDP-Kontext-Aktivierungs-/Änderungs-Nachricht können vom UE zum GGSN vorhanden sein.
  • Bei dieser Ausführungsform kann die Steuerung der QoS über das UMTS-Zugangsnetz (vom UE bis zum GGSN) vom Endgerät aus unter Verwendung der PDP-Kontext-Signalisierung durchgeführt werden. Stattdessen können auch Abonnementsdaten, auf die durch den SGSN zugegriffen wird, die QoS überschreiben, die mittels Signalisierung vom UE angefordert wird.
  • Die QoS für die Downlink-Richtung kann zwischen dem UE und dem GGSN durch den PDP-Kontext gesteuert werden. Der GGSN beendet die RSVP-Signalisierung, die vom entfernten Host empfangen wird, und kann bei der Verarbeitung von RSVP die Informationen in den IP-spezifischen Elementen in der PDP-Kontext-Aktivierungs-/Änderungs-Nachricht verwenden. Die QoS in der Uplink-Richtung wird durch den PDP-Kontext bis hin zum GGSN gesteuert. Der GGSN kann die IP-spezifischen Elementen in der PDP-Kontext-Aktivierungs-/Änderungs-Nachricht verwenden, um das Interworking mit RSVP zum entfernten Host sicherzustellen. Die IP-spezifischen Elementen in der PDP-Kontext-Aktivierungs-/Änderungs-Nachricht können den Aufbau der RSVP-Sitzung ermöglichen.
  • Die Ende-zu-Ende-QoS wird von einem lokalen Mechanismus im UE, dem PDP-Kontext über das UMTS-Zugangsnetz, DiffServ durch das Backbone-IP-Netz hindurch und RSVP im entfernten Zugangsnetz bereitgestellt.
  • Beim Konzipieren eines UMTS-Systems sind zwei Anforderungen zu beachten. Erstens darf der UMTS QoS Verhandlungsmechanismus keinerlei Annahmen über Signalisierungsprotokolle der Anwendungsschicht machen. Zweitens muss das UMTS-Netz in der Lage sein, Ende-zu-Ende-QoS auch für mobile Endgeräte und Anwendungen zu verhandeln, welche nicht in der Lage sind, andere QoS Verhandlungsmechanismen zu verwenden als diejenigen, die von UMTS zur Verfügung gestellt werden.
  • Das Bereitstellen von Ende-zu-Ende-QoS erfordert, dass Ressourcen in dem externen IP-Netz von dem IP BS Manager im GGSN verwaltet werden müssen. Dem IP BS Manager stehen verschiedene Verfahren der IP Ressourcenverwaltung zur Verfügung, um die IP-Ressourcen zu verwalten, und einige von ihnen erfordern Call Admission Control (Verbindungszulassungssteuerung, "CAC") Funktionalität im GGSN. Damit der GGSN CAC durchführen kann, können Informationen über den IP-Verkehr (z.B. mittlere und maximale Übertragungsgeschwindigkeiten, erforderliche QoS und Ziel) notwendig sein.
  • Die erste oben genannte Anforderung hat zur Folge, dass sich das auslösende Endgerät nicht auf Signalisierung auf der Anwendungsebene stützen kann, um zu prüfen, ob Ressourcen durch das Netz hindurch und am entfernten Zugang verfügbar sind. Daraus folgt, dass eine solche Ressourcenprüfung auf der Trägerebene durchgeführt werden muss. Falls das UE diese Anforderung auf der Trägerebene nicht ausführt, muss möglicherweise der GGSN diese Funktion ausführen und benötigt Informationen über die Ziel-IP-Adresse, um eine CAC-Entscheidung zu treffen.
  • Die zweite oben angegebene Anforderung hat zur Folge, dass Ende-zu-Ende-QoS sogar für Endgeräte bereitgestellt werden muss, welche die Funktionalität des IP BS Managers nicht implementieren und nur den UMTS BS Manager (z.B. PDP-Kontext-Signalisierung) verwenden, um Ressourcen innerhalb des UMTS-Netzes anzufordern.
  • 26 zeigt ein Blockschaltbild eines Netzes, in welchem Interworking-Funktionen im GGSN unterstützt werden. Zusätzlich zu den Funktionen, die bei den vorhergehenden Ausführungsformen erörtert wurden, wurden weitere Funktionen hinzugefügt. Zum Beispiel sind externe Funktionen beliebige Funktionen in Servern oder Knoten außerhalb von UMTS. Der Bandbreiten-Broker ist eine Funktion in einem Knoten, welche das Netzmanagement von Transportressourcen abwickelt. Er hat von der aktuellen Ressourcensituation im Netz Kenntnis. Der IP BS Manager kann eine Anforderung von Ressourcen ausgeben, und der Bandbreiten-Broker kann, ausgehend von der aktuellen Ressourcensituation im Netz, die Anforderung entweder zurückweisen oder bestätigen. Die Policy-Decision-Funktion hat eine vergleichbare Aufgabe wie der Bandbreiten-Broker. Die Policy-Decision-Funktion berücksichtigt zusätzlich zur reinen Ressourcenverfügbarkeit weitere Faktoren. Zum Beispiel kann die Policy-Decision-Funktion die Tageszeit, die verwendete Anwendung und die Ziel-IP-Adresse als Faktoren bei der Zuweisung von Bandbreite verwenden.
  • Aus den Anforderungen und den obigen Erläuterungen folgt, dass das UE möglicherweise Informationen, welche die Ende-zu-Ende-QoS betreffen, an den GGSN signalisieren muss. Bei dieser Ausführungsform können Informationen, welche die Ende-zu-Ende-QoS betreffen, als neues Informationsattribut zu dem existierenden PDP-Kontext hinzugefügt werden. Dieses Attribut der Ende-zu-Ende-QoS kann für das UMTS-Netz transparent sein und kann innerhalb der existierenden PDP-Kontext-Signalisierung im "Huckepack-Verfahren" transportiert werden.
  • 27 ist eine Prinzipskizze eines Netzmodells, welches verwendet werden soll, um diese Ausführungsform zu beschreiben. Die entsprechende Erweiterung des PDP-Kontextes hängt von der IP BS Funktionalität ab, welche gegenwärtig im GGSN implementiert ist. In Abhängigkeit vom Umfang der Call Admission Control im GGSN unterscheiden wir die folgenden beiden Fälle.
  • Im ersten Fall beruht die CAC auf der Verfügbarkeit von Ressourcen, über welche der GGSN die Kontrolle hat. In diesem Fall können die erforderlichen QoS-Informationen aus dem existierenden PDP-Kontext mittels der Übersetzungsfunktion zwischen dem UMTS BS Manager und dem IP BS Manager extrahiert werden. Um eine effiziente Nutzung der IP-Ressourcen zu fördern und Policy-Entscheidungen auf der Basis von RSVP-Parametern zu ermöglichen, könnte der PDP-Kontext zusätzliche, die QoS betreffende Informationen transportieren, die für den IP-Träger spezifisch sind. Zum Beispiel kann ein solcher zusätzlicher Parameter Verkehrsdeskriptoren und QoS-Deskriptoren spezifizieren. Solche Deskriptoren können auf denen basieren, die mit Standard-IP-Mechanismen verknüpft sind, wie etwa den differenzierten Diensten oder integrierten Diensten. Stattdessen können diese Deskriptoren auch auf dem Konzept der generischen IP-Träger basieren.
  • Im zweiten Fall beruht die CAC zusätzlich auf der Ressourcensituation an der Eingangs-SLA. In diesem Fall muss die Ziel-IP-Adresse im IP-Kontext transportiert werden (getrennt von den Deskriptoren von Fall 1).
  • Interworking, Policy Control und Admission Control sind verschiedene Konzepte mit unterschiedlichen Zielen. Diese können sich jedoch in einer konkreten Implementierung (da eine solche im Implementierungsprozess von einer anderen abhängig oder Teil einer anderen sein kann) überlappen und im Wesentlichen mit derselben oder einer ähnlichen Menge von RSVP/DS Parametern verknüpft sein. Welche Funktionalitäten am GGSN implementiert sind, ist der Wahl des Betreibers überlassen. Es ist vorgesehen, dass es möglich sein wird, für leichte Mobilgeräte die drei Funktionalitäten gleichzeitig unter Verwendung eines einzigen Mechanismus zu behandeln, welcher mit den IP-spezifischen Elementen in der IP-Kontext-Aktivierungs- und Änderungs-Nachricht verbunden ist. Zur Vereinfachung der Beschreibung wird dieser Mechanismus im Weiteren als "UMTS-spezifischer IP QoS Mechanismus" bezeichnet.
  • Die natürliche Forderung nach Exaktheit und Vollständigkeit der Implementierung der obigen Funktionalitäten führt zusammen mit den allgemeinen Richtlinien betreffs der Sauberkeit der Lösung (Trennung und Unabhängigkeit von Schichten sicherstellen) und der Zukunftsbeständigkeit der Lösung, obwohl dies die Kernprinzipien des guten Designs sind, zu der Tendenz, den UMTS-spezifischen IP QoS Mechanismus komplexer zu machen, und kann das Hauptziel zunichte machen, welches darin besteht, einfache, leichte Implementierungen für Mobiltelefone zu ermöglichen.
  • Es wird daher vorgeschlagen, gewisse Annahmen und Einschränkungen anzuwenden, wenn der UMTS-spezifische IP QoS Mechanismus verwendet wird. Diese Annahmen und Einschränkungen umfassen:
    • 1. Ein PDP-Kontext soll höchstens einen IP-Ebenen-Strom pro Richtung transportieren (d.h. kein Multiplexing von unidirektionalen IP-Ebenen-Strömen in ein und demselben PDP-Kontext).
    • 2. Falls das UE eine Unterstützung des UMTS-spezifischen IP QoS Mechanismus am GGSN wünscht, müssen die folgenden Informationen durch das UE zum GGSN transportiert werden. Der UMTS-spezifische IP QoS Mechanismus soll jedoch nur die minimale Teilmenge der Informationen transportieren, welche in den Mechanismen der UMTS-Ebene nicht verfügbar sind.
    • • Eine Angabe der Anforderung von Unterstützung des UMTS-spezifischen IP QoS Mechanismus zum Interworking desselben mit einem Ende-zu-Ende-QoS-Mechanismus der IP-Ebene,
    • • eine Angabe der Richtung des Stroms,
    • • eine Verkehrsspezifikation, welche das gewünschte QoS-Niveau spezifiziert,
    • • eine Filterspezifikation, welche eindeutig die Menge der Datenpakete oder den "Strom" in der IP-Ebene definiert, welcher die in der Verkehrsspezifikation definierte QoS empfangen soll.
    • 3. Angabe der Anforderung von Unterstützung des UMTS-spezifischen IP QoS Mechanismus zum Interworking mit einem Ende-zu-Ende-QoS-Mechanismus der IP-Ebene. Das UE muss seine Anforderung von Interworking am GGSN angeben, um Ende-zu-Ende-QoS zu erhalten. Diese Angabe muss vom UE über den UMTS-spezifischen IP QoS Mechanismus zum GGSN gesendet werden. Diese Angabe schließt jedoch nicht aus, dass der GGSN möglicherweise die Anforderung des UE überschreibt oder ignoriert, und es ist der Wahl des Betriebs über lassen, ob Interworking, Policy Control oder Admission Control oder eine Kombination dieser Funktionalitäten implementiert wird. Außerdem kann, wenn das UE nicht Ende-zu-Ende-QoS fordert oder sich nicht darum kümmert, dies dem GGSN implizit dadurch angezeigt werden, dass Attribute der UMTS-spezifischen IP QoS vollständig fehlen.
    • 4. Angabe der Richtung des Stroms. Das UE muss Informationen betreffs der Richtung des Stroms liefern. Diese Angabe kann aus dem Anzeigeparameter des UMTS-spezifischen IP QoS Mechanismus abgeleitet werden, welcher für Uplink und Downlink separat einstellbar sein muss. Somit muss der UMTS-spezifische IP QoS Mechanismus keine explizite Angabe der Richtung des Stroms transportieren.
    • 5. Verkehrsspezifikation. Um die Implementierung in einem leichten UE zu vereinfachen, sollen QoS-Parameter der IP-Ebene von den Attributen des UMTS Trägerdienstes am GGSN entsprechend der in 16 dargestellten Übersetzungsfunktion abgeleitet werden. Das UE muss nur dann die QoS-Parameter der IP-Ebene liefern, wenn die entsprechenden QoS-Parameter der UMTS-Ebene nicht in der PDP-Kontext-Aktivierungs-/Änderungs-Nachricht verfügbar sind. Ferner soll eine minimale Menge von QoS-Parametern, welche das UE liefert, spezifiziert werden. Die Parameter sind Peak Data Rate [p], Token Bucket Rate [r], Maximum Packet Size [M] und Token Bucket Size [b]. Die Definition der Parameter stimmt mit dem Parameter Token Bucket Tspec überein (service number 1, Parameter 127, wie in IETF RFC2215 definiert). In Abhängigkeit von dem Mechanismus der IP-Ebene, der von dem GGSN für Interworking, Policy Control oder Admission Control gewählt wird (RSVP oder DS), führt der GGSN Folgendes durch:
    • • Fall RSVP: Der GGSN verwendet die Parameter Peak Data Rate [p], Token Bucket Rate [r], Maximum Packet Size [M] und Token Bucket Size [b], die vom UE zur Verfügung gestellt werden. Der GGSN stellt, wenn notwendig, die folgenden Parameter zur Verfügung: Minimum Policed Unit [m] (abgeleitet aus Informationen der Anwendungsschicht, z.B. von IP MM CN SS, oder ein Default-Wert), Rate [R] und Slack Term [S] (abgeleitet aus der ankommenden RSVP PATH-Nachricht, oder ein Default-Wert). Es ist zu erwarten, dass die Host RSVP Implementierung im GGSN den Default-Wert von ADSPEC liefert, welcher von den QoS Steuerungsdiensten abhängen würde, die dem Host bekannt sind. Andere relevante Anfangswerte in der PATH/RESV-Nachricht werden ebenfalls vom GGSN zur Verfügung gestellt (z.B. Integritätsparameter, Policy-Daten, Refresh Period, Style-Parameter usw.).
    • • Fall DS: Der GGSN verwendet die Parameter Token Bucket Rate [r] und Token Bucket Size [b], die vom UE zur Verfügung gestellt werden, zum Einstellen/Konfigurieren des Verkehrsprofils (Regeln, um zu bestimmen, ob ein bestimmtes Paket "in-profile" oder "out-of-profile" ist).
    • 6. Filterspezifikation. Das UE soll nur eine Filterspezifikation pflegen müssen, welche eindeutig die Menge der Datenpakete oder den "Strom" auf der IP-Ebene definiert, welcher die in der Verkehrsspezifikation definierte QoS erhalten soll. Die Filterspezifikation soll für das TFT auf der UMTS-Ebene verwendet werden, ebenso wie die Filterspezifikation auf der IP-Ebene. Die Filterparameter sind Source Address (Quelladresse), Destination Address, (Zieladresse) Protocol Number (Protokollnummer) (IPv4) oder Next Header (IPv6), Destination Port (Zielport), Source Port (Quellport), IPSec Security Parameter Index (SPI), Flow Label (IPv6). Im Vergleich zur Benutzung von TFT in TS23.060 werden zusätzliche Einschränkungen in Bezug auf mögliche Kombinationen von Filterparametern spezifiziert, die vom Typ oder der Natur des IP-Stroms abhängen (z.B. es ist nur ein Filter zulässig, einzelne Portnummer im Unter schied zu einem Portbereich, TOS/Verkehrsklasse nicht enthalten usw.). Die Einschränkungen sollten in einem separaten Dokument spezifiziert werden, da dies über den Umfang von TS23.107 hinausgeht.
    • • Fall Downlink: Downlink TFTs müssen der Filterspezifikation der IP-Ebene für die Downlink-Richtung entsprechen. Dies kann mit einer zusätzlichen Einschränkung für die Parameter in den Downlink TFTs verbunden sein. Somit muss der UMTS-spezifische IP QoS Mechanismus keine Downlink TFTs transportieren.
    • • Fall Uplink: Uplink TFTs müssen der Filterspezifikation der IP-Ebene für die Uplink-Richtung entsprechen. Dies kann mit einer zusätzlichen Einschränkung für die Parameter in den Uplink TFTs verbunden sein. Da die aktuelle UMTS GPRS Spezifikation die Uplink TFTs auf das UE beschränkt, muss der UMTS-spezifische IP QoS Mechanismus die Uplink TFTs vom UE zum GGSN transportieren. Die damit verbundenen Filterparameter verwenden dieselbe Definition/Benutzung, wie die in TS23.060 definierte TFT.
  • Es ist anzumerken, dass eine Anwendungsinstanz, die in dem leichten UE resident ist, nicht selbst an dem Steuerungsprozess der Ende-zu-Ende-QoS teilnimmt und nicht spezifiziert, welcher Typ von QoS Steuerungsdienst (für RSVP) oder PHB (für DS) verwendet wird. Die Anwendung stellt dem UE eine Ausgangs-Verkehrsspezifikation und eine Filterspezifikation zur Verfügung. Es ist dann Angelegenheit des GGSN, den geeigneten Mechanismus der IP-Ebene zu wählen, der verwendet werden soll. Wie der GGSN die Wahl trifft (ob das UE eine Präferenz angibt, oder ob APN-abhängig, oder Policy von den oberen Schichten, oder als Default-Einstellung), bedarf einer weiteren Untersuchung.
  • Das UE liefert dem GGSN Informationen über Ende-zu-Ende-QoS auf IP-Ebene unter Verwendung IP-spezifischer Elemente in der PDP-Kontext-Aktivierungs-/Änderungs-Nachricht, und der GGSN verwendet diese Informationen, um RSVP-Nachrichten zum Einrichten des Uplink- sowie des Downlink-Stroms aufzurufen. Die RSVP-Signalisierung wird von dem GGSN erzeugt und beendet, wie in den 28 und 29 dargestellt ist. In diesen Figuren wird die Verknüpfung zwischen der RSVP PATH-Nachricht und dem PDP-Kontext in dem GGSN durchgeführt.
  • 30 zeigt die Phasen eines Bearer Setups. Die verschiedenen Interworking-Aspekte werden weiter unten unter Bezugnahme auf die Phasen erörtert.
  • Wie bei den vorhergehenden Ausführungsformen ist ein Aspekt des Interworkings das Abbilden von Informationen in einem Protokoll auf die Informationen in einem anderen Protokoll. Zum Beispiel können der Verkehrsdeskriptor und QoS-Definitionen wie folgt abgebildet werden.
  • Wenn das UE die Aufbauphase einleitet, wird der Verkehrsdeskriptor, welcher empfangen oder in der PATH- oder RESV-Prozedur des IP BS Managers im UE erzeugt wird, auf das entsprechende Attribut in dem IP-spezifischen Element abgebildet und in einer PDP-Kontext-Aktivierungs- oder Änderungs-Nachricht gesendet. Wenn das UE die Aufbauphase beendet, empfängt das UE eine "Sekundären PDP-Kontext erzeugen oder ändern"-Antwort, und die mit dem Verkehrsdeskriptor zusammenhängenden Attribute können auf entsprechende RSVP-Elemente abgebildet werden. Die RSVP-Elemente können von dem IP BS Manager bei der RESV-Verarbeitung im UE verwendet werden.
  • Wie in 28 dargestellt, wird, wenn der GGSN den Verkehrsdeskriptor in dem IP-spezifischen Element empfängt, dieser auf den RSVP-Verkehrsdeskriptor abgebildet und in der RSVP PATH-Nachricht zum externen Netz verwendet. Er kann auch auf Attribute abgebildet werden, die für die Call Admission Control und Policy verwendet werden.
  • Der Verkehrsdeskriptor, welcher in der RESV-Nachricht an den IP BS Manager im GGSN empfangen wird, kann auf ein UMTS-Attribut in der PDP-Kontext-Aktivierungs-/Änderungs-Antwortnachricht abgebildet werden. Er kann auch auf Attribute abgebildet werden, die für die Call Admission Control und Policy verwendet werden.
  • In 29 wird, wenn der GGSN den Verkehrsdeskriptor in dem IP-spezifischen Element der PDP-Kontext-Aktivierungs-/Änderungs-Nachricht empfängt, dieser auf den RSVP-Verkehrsdeskriptor abgebildet und in der RSVP RESV-Nachricht verwendet, die zum externen Gerät gesendet wird. Er kann auch auf Attribute abgebildet werden, die für die Call Admission Control und Policy verwendet werden.
  • Der Verkehrsdeskriptor einer empfangenen RSVP PATH-Nachricht kann auf ein entsprechendes Attribut in der PDP-Kontext-Aktivierungs-/Änderungs-Antwortnachricht abgebildet werden. Er kann auch auf Attribute abgebildet werden, die für die Call Admission Control und Policy verwendet werden.
  • Ähnlich werden, wenn das UE die Aufbauphase einleitet, die QoS-Attribute, welche empfangen oder in der RESV-Prozedur des IP BS Managers im UE erzeugt werden, auf das entsprechende Attribut in dem IP-spezifischen Element abgebildet und in einer PDP-Kontext-Aktivierungs- oder Änderungs-Nachricht gesendet. Wenn das UE die Aufbauphase beendet, empfängt das UE eine "Sekundären PDP-Kontext erzeugen oder ändern"-Antwort, und die UMTS QoS-Attribute können auf entsprechende RSVP-Elemente abgebildet und von dem IP BS Manager bei der RSVP RESV-Verarbeitung im UE verwendet werden.
  • Wie in 28 dargestellt, werden RSVP QoS Attribute, welche in der RSVP RESV-Nachricht an den IP BS Manager im GGSN empfangen werden, auf ein UMTS QoS-Attribut in der PDP-Kontext-Aktivierungs-/Änderungs-Antwortnachricht abgebildet. Sie können auch auf Attribute abgebildet werden, die für die Call Admission Control und Policy verwendet werden.
  • Wie in 29 dargestellt, werden, wenn der GGSN die QoS-Attribute der PDP-Kontext-Aktivierungs- oder Änderungs-Nachricht empfängt, diese auf die RSVP QoS abgebildet und in der RSVP RESV-Nachricht verwendet, die zum externen Gerät gesendet wird. Sie können auch auf Attribute abgebildet werden, die für die Call Admission Control und Policy verwendet werden.
  • Ein anderer Aspekt des Interworkings betrifft das Verwenden von Ereignissen in der Zustandsmaschine einer Seite des Interworkings, um Aktionen in der Funktion der anderen Seite des Interworkings auszulösen. Zum Beispiel wenn das das UE die Aufbauphase einleitet, lösen die RSVP-Einleitungsprozeduren (RSVP PATH-Prozedur) des IP BS Managers im UE aus, dass eine PDP-Kontext-Aktivierungs-/Änderungs-Nachricht in der Uplink-Richtung gesendet wird. Der Empfang einer "Sekundären PDP-Kontext erzeugen oder ändern"-Antwort löst eine RSVP RESV-Verarbeitung im UE aus und beendet die Aufbauphase.
  • Wie in 28 dargestellt, wird, wenn der GGSN eine PDP-Kontext-Aktivierungs- oder Änderungs-Nachricht mit einem IP-spezifischen Element empfängt, das RSVP-Interworking spezifiziert, dadurch die Initiierung eines RSVP-Hosts im IP BS Manager des GGSN ausgelöst, und eine RSVP PATH-Nachricht wird zum externen Netz gesendet. Auf diese Weise kann eine Call Admission Control durchgeführt werden, um zu entscheiden, ob der Träger angenommen werden kann. Die Call Admission Control Prozedur kann mit Interworking mit einem Bandbreiten-Broker oder einem Policy Decision Server verbunden sein.
  • In 29 löst der Empfang einer PDP-Kontext-Aktivierungs- oder Änderungs-Nachricht mit einem IP-spezifischen Element, das RSVP-Interworking spezifiziert, die Initiierung eines RSVP-Hosts im IP BS Manager des GGSN aus. Auf diese Weise kann eine Call Admission Control durchgeführt werden, um zu entscheiden, ob der Träger angenommen werden kann. Die Call Admission Control Prozedur kann mit Interworking mit einem Bandbreiten-Broker oder einem Policy Decision Server verbunden sein.
  • Der Empfang einer RSVP PATH-Nachricht löst einen Zustandsübergang aus einer Ruhephase in eine Aufbauphase aus. In Abhängigkeit von der Nachrichtensequenz kann er auch das Senden einer PDP-Kontext-Aktivierungs- oder Änderungs-Antwortnachricht auslösen.
  • Wenn der RSVP-Host initiiert ist oder ein IP BS Manager des GGSN in die Aufbauphase eingetreten ist, wird eine RSVP RESV-Nachricht zum externen Gerät gesendet. Auf diese Weise kann eine Call Admission Control durchgeführt werden, um zu entscheiden, ob der Träger angenommen werden kann. Die Call Admission Control Prozedur kann mit Interworking mit einem Bandbreiten-Broker oder einem Policy Decision Server verbunden sein.
  • Interworking kann auch das Verwenden von Informationen beinhalten, die an der Eingangsseite des Interworkings empfangen werden, um das Shaping oder Marking der Ausgangsseite des Interworkings zu konfigurieren. Zum Beispiel kann im Falle eines Interworkings, das den IP BS Manager des GGSN Uplink-Verkehrs betrifft, der Verkehr, der gemäß einem Verkehrsvertrag und Verkehrsdeskriptor des PDP-Kontextes empfangen wird, so markiert und geformt werden, dass er mit der Konfiguration und den Mitteln des externen Netzes konform ist. Der Algorithmus, der für das Shaping und Marking verantwortlich ist, kann auch die Eigenschaften für den PDP-Kontext-Strom berücksichtigen.
  • Wenn Interworking im IP BS Manager des GGSN Downlink-Verkehrs abgewickelt wird, können die Downlink-Pakete entsprechend der möglichen Markierung der IP-Pakete gefiltert und geformt werden, bevor sie als PDP-Kontext-Strom transportiert werden. Der IP BS Manager führt das Interworking zwischen spezifischer Markierung der empfangenen Pakete und den QoS-Eigenschaften eines spezifischen PDP-Kontext-Stroms durch.
  • Speziell für leichte UE, welche IP-Schicht-Signalisierung und Verhandlung in Richtung der IP BS Funktion im GGSN nicht unterstützen können, wird die Übertragung von QoS-Informationen auf der IP-Ebene vom UE zum GGSN für vielfältige Zwecke benötigt, einschließlich der Verbesserung von Interworking-Optionen für DS und RSVP in GGSN und des Ermöglichens von Policy Control und Admission Control ("AC") am GGSN.
  • Diese Ausführungsform kombiniert außerdem einige der Vorteile der ersten zwei Ausführungsformen. Speziell werden Funkressourcen gespart, ohne dass das Ende-zu-Ende Konzept der Signalisierung auf IP-Ebene beeinträchtigt wird. Außerdem entlastet diese Ausführungsform die Komplexität des Handlings der QoS auf zwei Träger-Ebenen im UE und ermöglicht somit die Entwicklung von in hohem Grade optimierten und wenig Energie verbrauchenden mobilen Endgeräten.
  • Im Vergleich zur vorhergehenden Ausführungsform hat diese Ausführungsform den Vorteil, dass sie vollständig den Prinzipien folgt, die für IP-Signalisierung festgelegt wurden, ohne dass sie die Notwendigkeit mit sich bringt, QoS auf zwei verschiedenen Ebenen im GGSN oder TE/MT zu signalisieren.
  • Bei manchen Anwendungen kann es wünschenswert sein, ein Interworking zwischen IP BS Manager-Funktion und der DiffServ-Funktion sicherzustellen. Dies kann realisiert werden, indem die vorhergehende Ausführungsform so modifiziert wird, dass der GGSN keine IP-Signalisierungs-Host-Funktionalität zur Verfügung stellt. Der IP BS Manager gewährleistet dann nur Interworking zu Mitteln für die Verkehrsaggregation wie etwa DiffServ.
  • Wie in 31 dargestellt ist, führt das UE eine IP BS Funktion aus, welche Ende-zu-Ende-QoS ohne IP-Schicht-Signalisierung und Verhandlung zur IP BS Funktion im GGSN oder zum entfernten Host ermöglicht. Das UE stellt dem GGSN IP-spezifische Informationen zur Verfügung, unter Verwendung IP-spezifischer Elemente der PDP-Kontext-Aktivierungs- oder Änderungs-Nachricht, um die Interworking-Optionen der DiffServ Edge-Funktion des GGSN zu verbessern. Diese Ausführungsform setzt voraus, dass der GGSN DiffServ Edge-Funktionen unterstützt und dass das Backbone-IP-Netz DiffServ-fähig ist.
  • Die DiffServ Edge-Funktion des GGSN kann die IP-spezifischen Informationen für die DiffServ Classifier Funktionalität verwenden, wie etwa eine Kombination von Quell- und Ziel-IP-Adresse, Quell- und Ziel-Portnummer, und den Protocol Identifier. Die Informationen können auch für die DiffServ Class Admission Control verwendet werden; so kann etwa der GGSN im Voraus über die vom UE angeforderte Ende-zu-Ende Bandbreite für einen bestimmten Strom informiert werden, damit die DiffServ Edge-Funktion des GGSN bestimmt, ob der Strom für eine gewisse DiffServ Klasse oder einen Eingangspunkt zugelassen werden kann. Im Ergebnis kann der GGSN die geeignete DiffServ Einstellung wählen, die angewendet werden soll. Die IP-spezifischen Elemente einer PDP-Kontext-Aktivierungs- oder Änderungs-Nachricht, welche vom UE zum GGSN übertragen werden und im Zusammenhang mit den vorhergehenden Ausführungsformen erörtert wurden, können auch für diese Ausführungsform existieren.
  • Bei dieser Ausführungsform kann die Steuerung der QoS über das UMTS-Zugangsnetz (vom UE bis zum GGSN) vom Endgerät aus unter Verwendung der PDP-Kontext-Signalisierung durchgeführt werden. Stattdessen können auch Abonnementsdaten, auf die durch den SGSN zugegriffen wird, die QoS überschreiben, die mittels Signalisierung vom UE angefordert wird.
  • Die QoS für die Downlink-Richtung wird durch den entfernten Host vom entfernten Netz bis zum GGSN gesteuert. Der PDP-Kontext steuert die QoS der UMTS-Ebene zwischen dem GGSN und dem UE. Die QoS in der Uplink-Richtung wird durch den PDP-Kontext bis hin zum GGSN gesteuert. Der GGSN verwendet die IP-spezifischen Elemente der UMTS-Signalisierung für das Interworking mit DiffServ im Backbone-IP-Netz und bei der Steuerung des IP QoS Trägerdienstes zum entfernten Host hin.
  • Die Ende-zu-Ende-QoS wird von einem lokalen Mechanismus im UE, dem PDP-Kontext über das UMTS-Zugangsnetz, DiffServ durch das Backbone-IP-Netz hindurch und DiffServ im entfernten Zugangsnetz bereitgestellt. Es ist anzumerken, dass in diesem Beispiel eine Steuerung durch DiffServ am entfernten Host dargestellt ist. Am entfernten Ende können jedoch auch andere Mechanismen verwendet werden, wie bei den anderen Ausführungsformen dargelegt wurde.
  • Signalisierung auf der IP-Ebene wie etwa RSVP wird noch nicht in größerem Umfang angewendet. Eine Lösung für leichte Geräte unter Verwendung des am häufigsten benutzten DiffServ Paradigmas ist daher vorteilhaft.
  • Die Erfindung wurde unter Bezugnahme auf verschiedene Ausführungsformen beschrieben. Angesichts der vorliegenden Offenbarung können Fachleute andere Ausführungsformen dieser Erfindung herstellen, wie etwa durch Einbeziehung zusätzlicher Aufgaben oder die Verwendung anderer Netzeinrichtungen. Diese und andere alternative Ausführungsformen sollen im Schutzbereich der nachfolgenden Patentansprüche enthalten sein.

Claims (13)

  1. Verfahren für ein mobiles Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht, wobei das Verfahren die folgenden Schritte umfasst: Beenden einer PATH-Nachricht, die von der Endeinrichtung des Benutzers gesendet wurde; Bestimmen, ob ein neuer PDP-Kontext erzeugt oder ein existierender PDP-Kontext geändert werden soll, auf der Basis der in der PATH-Nachricht enthaltenen RSVP-Parameter; und Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern.
  2. Verfahren nach Anspruch 1, welches ferner die folgenden Schritte umfasst: Empfangen einer Antwort von dem Funknetz auf die Anforderung einen PDP-Kontext zu erzeugen oder zu ändern; Erzeugen einer RESV-Nachricht auf der Basis der Antwort; und Senden der RESV-Nachricht zu der Endeinrichtung.
  3. Verfahren nach Anspruch 1, welches ferner die folgenden Schritte umfasst: Instanzieren eines RSVP-Proxys in einem Modus, welcher die IP-Signalisierung beendet, wobei der RSVP-Proxy PATH-Nachrichten beendet, die von der Endeinrichtung empfangen wurden, und eine RESV-Antwort auf der Basis der PATH-Nachricht erzeugt.
  4. Verfahren nach Anspruch 3, welches ferner die folgenden Schritte umfasst: Empfangen einer Nachricht von dem Funknetz; Bestimmen aus der Nachricht, ob eine Anwendung in der Endeinrichtung RSVP-Signalisierung erfordert; Erzeugen einer PATH-Nachricht; Senden der PATH-Nachricht an die Endeinrichtung; Empfangen einer RESV-Nachricht von der Endeinrichtung; Bestimmen von Anforderungen für einen PDP-Kontext; und Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern.
  5. Verfahren für ein mobiles Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht, wobei das Verfahren die folgenden Schritte umfasst: Empfangen einer Nachricht von dem Funknetz; Bestimmen aus der Nachricht, ob eine Anwendung in der Endeinrichtung RSVP-Signalisierung erfordert; Erzeugen einer PATH-Nachricht; Senden der PATH-Nachricht zu der Endeinrichtung; Empfangen einer RESV-Nachricht von der Endeinrichtung; Bestimmen von Anforderungen für einen PDP-Kontext; und Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern.
  6. Verfahren nach Anspruch 5, welches ferner die folgenden Schritte umfasst: Ablaufen lassen eines Timers, der für RSVP-Prozeduren geeignet ist; und Senden der PATH-Nachricht an die Endeinrichtung, wenn der Timer abläuft.
  7. Verfahren für ein mobiles Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht, wobei das Verfahren die folgenden Schritte umfasst: Empfangen einer PATH-Nachricht, die von der Endeinrichtung des Benutzers gesendet wurde; Ändern der PATH-Nachricht entsprechend einer lokalen Konfiguration; Senden der geänderten PATH-Nachricht an das Funknetz; Empfangen einer RESV-Nachricht von dem Funknetz als Antwort auf die PATH-Nachricht; Bestimmen, ob ein neuer PDP-Kontext erzeugt oder ein existierender PDP-Kontext geändert werden soll, auf der Basis von in der RESV-Nachricht enthaltenen RSVP-Parameter; Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern; Empfangen einer Antwort von dem Funknetz auf die Anforderung einen PDP-Kontext zu erzeugen oder zu ändern; und Senden der RESV-Nachricht an die Endeinrichtung.
  8. Verfahren für ein mobiles Endgerät zum Bereitstellen von Unterstützung für IP-Signalisierung, wobei das mobile Endgerät in Kommunikation mit einer Endeinrichtung eines lokalen Benutzers steht und außerdem in Kommunikation mit einem Funknetz steht, wobei das Verfahren die folgenden Schritte umfasst: Empfangen einer PATH-Nachricht von dem Funknetz; Senden der PATH-Nachricht an die Endeinrichtung; Empfangen einer RESV-Nachricht von der Endeinrichtung; Bestimmen der Anforderungen für einen PDP-Kontext aus der RESV-Nachricht; Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern; Empfangen einer Antwort von dem Funknetz auf die Anforderung den PDP-Kontext zu erzeugen oder zu ändern; und Senden der RESV-Nachricht an das Funknetz.
  9. Verfahren zum Einbinden von IP QoS-Information in einen PDP-Kontext und zum Transportieren der QoS-Information über ein UMTS-Netz, wobei das Verfahren die folgenden Schritte umfasst: Einbinden der QoS-Information in den PDP-Kontext; und Interworking zwischen QoS-Information und RSVP in einem GGSN.
  10. Mobiles Endgerät, das Unterstützung für IP-Signalisierung bereitstellt, wobei das mobile Endgerät in der Lage ist, mit einer Endeinrichtung eines lokalen Benutzers zu kommunizieren, und in der Lage ist, mit einem Funknetz zu kommunizieren, wobei das mobile Endgerät umfasst: Mittel zum Beenden einer PATH-Nachricht, die von der Endeinrichtung des Benutzers gesendet wurde; Mittel zum Bestimmen, ob ein neuer PDP-Kontext erzeugt oder ein existierender PDP-Kontext geändert werden soll, auf der Basis der in der PATH-Nachricht enthaltenen RSVP-Parameter; und Mittel zum Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern.
  11. Mobiles Endgerät, das Unterstützung für IP-Signalisierung bereitstellt, wobei das mobile Endgerät in der Lage ist, mit einer Endeinrichtung eines lokalen Benutzers zu kommunizieren, und außerdem in der Lage ist, mit einem Funknetz zu kommunizieren, wobei das mobile Endgerät umfasst: Mittel zum Empfangen einer Nachricht von dem Funknetz; Mittel zum Bestimmen aus der Nachricht, ob eine Anwendung in der Endeinrichtung RSVP-Signalisierung erfordert; Mittel zum Erzeugen einer PATH-Nachricht; Mittel zum Senden der PATH-Nachricht an die Endeinrichtung; Mittel zum Empfangen einer RESV-Nachricht von der Endeinrichtung; Mittel zum Bestimmen von Anforderungen für einen PDP-Kontext; und Mittel zum Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern.
  12. Mobiles Endgerät, das Unterstützung für IP-Signalisierung bereitstellt, wobei das mobile Endgerät in der Lage ist, mit einer Endeinrichtung eines lokalen Benutzers zu kommunizieren, und außerdem in der Lage ist, mit einem Funknetz zu kommunizieren, wobei das mobile Endgerät umfasst: Mittel zum Empfangen einer PATH-Nachricht, die von der Endeinrichtung des Benutzers gesendet wurde; Mittel zum Ändern der PATH-Nachricht entsprechend einer lokalen Konfiguration; Mittel zum Senden der geänderten PATH-Nachricht an das Funknetz; Mittel zum Empfangen einer RESV-Nachricht von dem Funknetz in Reaktion auf die PATH-Nachricht; Mittel zum Bestimmen, ob ein neuer PDP-Kontext erzeugt oder ein existierender PDP-Kontext geändert werden soll, auf der Basis von in der RESV-Nachricht enthaltenen RSVP-Parametern; Mittel zum Senden einer Anforderung, den PDP-Kontext zu erzeugen oder zu ändern, über das Funknetz; Mittel zum Empfangen einer Antwort auf die Anforderung, einen PDP-Kontext zu erzeugen oder zu ändern, von dem Funknetz; und Mittel zum Senden der RESV-Nachricht an die Endeinrichtung.
  13. Mobiles Endgerät, das Unterstützung für IP-Signalisierung bereitstellt, wobei das mobile Endgerät in der Lage ist, mit einer Endeinrichtung eines lokalen Benutzers zu kommunizieren, und außerdem in der Lage ist, mit einem Funknetz zu kommunizieren, wobei das mobile Endgerät umfasst: Mittel zum Empfangen einer PATH-Nachricht von dem Funknetz; Mittel zum Senden der PATH-Nachricht an die Endeinrichtung; Mittel zum Empfangen einer RESV-Nachricht von der Endeinrichtung; Mittel zum Bestimmen der Anforderungen für einen PDP-Kontext aus der RESV-Nachricht; Mittel zum Senden einer Anforderung über das Funknetz den PDP-Kontext zu erzeugen oder zu ändern; Mittel zum Empfangen einer Antwort von dem Funknetz auf die Anforderung den PDP-Kontext zu erzeugen oder zu ändern; und Mittel zum Senden der RESV-Nachricht an das Funknetz.
DE60120354T 2000-01-25 2001-01-25 Rsvp-verarbeitung in 3g-netzwerken Expired - Lifetime DE60120354T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US768956 1985-08-23
US17808600P 2000-01-25 2000-01-25
US178086P 2000-01-25
US09/768,956 US20010027490A1 (en) 2000-01-25 2001-01-24 RSVP handling in 3G networks
PCT/SE2001/000145 WO2001056250A1 (en) 2000-01-25 2001-01-25 Rsvp handling in 3g networks

Publications (2)

Publication Number Publication Date
DE60120354D1 DE60120354D1 (de) 2006-07-20
DE60120354T2 true DE60120354T2 (de) 2007-05-16

Family

ID=26873951

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60120354T Expired - Lifetime DE60120354T2 (de) 2000-01-25 2001-01-25 Rsvp-verarbeitung in 3g-netzwerken

Country Status (7)

Country Link
US (1) US20010027490A1 (de)
EP (1) EP1250787B1 (de)
CN (2) CN1592304A (de)
AT (1) ATE329441T1 (de)
AU (1) AU3067401A (de)
DE (1) DE60120354T2 (de)
WO (1) WO2001056250A1 (de)

Families Citing this family (87)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI974558A7 (fi) * 1997-12-18 1999-06-19 Nokia Corp Resurssin varaus liikkuvassa Internet-protokollassa
US6728365B1 (en) * 1999-09-13 2004-04-27 Nortel Networks Limited Method and system for providing quality-of-service on packet-based wireless connections
US7106756B1 (en) 1999-10-12 2006-09-12 Mci, Inc. Customer resources policy control for IP traffic delivery
US7369536B2 (en) * 1999-11-02 2008-05-06 Verizon Business Global Llc Method for providing IP telephony with QoS using end-to-end RSVP signaling
US6970930B1 (en) * 1999-11-05 2005-11-29 Mci, Inc. Method and system of providing differentiated services
US7023820B2 (en) * 2000-12-28 2006-04-04 Nokia, Inc. Method and apparatus for communicating data in a GPRS network based on a plurality of traffic classes
US6944150B1 (en) * 2000-02-28 2005-09-13 Sprint Communications Company L.P. Method and system for providing services in communications networks
GB0005363D0 (en) * 2000-03-06 2000-04-26 Nokia Networks Oy Interworking in a communication system
ES2292436T3 (es) * 2000-03-16 2008-03-16 Nokia Corporation Metodo, sistema y dispositivo terminal para activar un contexto de abonado de datos por paquetes para datos por paquetes.
US7298697B2 (en) * 2000-04-10 2007-11-20 Nokia Corporation Setting a communication channel
US7792119B2 (en) * 2000-05-22 2010-09-07 Telefonaktiebolaget L M Ericsson (Publ) Method for a connection through a core network
US7423971B1 (en) * 2000-05-31 2008-09-09 Cisco Technology, Inc. Method and apparatus providing automatic RESV message generation for non-RESV-capable network devices
US6944473B2 (en) * 2000-06-27 2005-09-13 Motorola, Inc Method for radio access bearer reconfiguration in a communications system
GB0016185D0 (en) * 2000-06-30 2000-08-23 Nokia Networks Oy Dynamic DSCP availability request method
GB0016086D0 (en) * 2000-07-01 2000-08-23 Ericsson Telefon Ab L M Data transmission in a telecommunications network
US7068607B2 (en) * 2000-08-31 2006-06-27 Telefonktiebolaget Lm Ericsson (Publ) Bandwidth broker for cellular radio access networks
WO2002037869A2 (en) * 2000-11-06 2002-05-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with ip bearer resources
SE0004178D0 (sv) * 2000-11-14 2000-11-14 Ericsson Telefon Ab L M Network requested packet data protocol context activation
US6990086B1 (en) 2001-01-26 2006-01-24 Cisco Technology, Inc. Method and system for label edge routing in a wireless network
US7106718B2 (en) * 2001-02-09 2006-09-12 Telefonaktiebolaget Lm Ericsson (Publ) Signaling quality of service class for use in multimedia communicatations
US6973071B1 (en) * 2001-03-06 2005-12-06 Rfmd Wpan, Inc. Method and apparatus for controlling the flow of data in a wireless communication system
US7483989B2 (en) * 2001-03-13 2009-01-27 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for establishing a protocol proxy for a mobile host terminal in a multimedia session
US7209439B2 (en) * 2001-03-20 2007-04-24 Mci, Llc Pool-based resource management in a data network
US7796608B2 (en) * 2001-03-20 2010-09-14 Verizon Business Global Llc Edge-based per-flow QoS admission control in a data network
US7069337B2 (en) * 2001-03-20 2006-06-27 Mci, Inc. Policy-based synchronization of per-class resources between routers in a data network
EP1380135B1 (de) * 2001-04-04 2007-10-10 Nokia Corporation Trassierungsverfahren und -system
US7287070B2 (en) * 2001-05-25 2007-10-23 Interdigital Technology Corporation Determining control of an internet communication between a sender and receiver
FR2825561B1 (fr) * 2001-06-01 2005-04-15 Nortel Networks Ltd Procede de transmission de paquets ip a travers un systeme cellulaire de radiocommunication, et equipements du systeme cellulaire pour la mise en oeuvre de ce procede
US7339903B2 (en) 2001-06-14 2008-03-04 Qualcomm Incorporated Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address
US7474650B2 (en) * 2001-06-26 2009-01-06 Qualcomm Incorporated Methods and apparatus for controlling resource allocation where tunneling and access link packet aggregation are used in combination
US8000241B2 (en) 2001-06-26 2011-08-16 Qualcomm Incorporated Methods and apparatus for controlling access link packet flow aggregation and resource allocation in a mobile communications system
US7027400B2 (en) 2001-06-26 2006-04-11 Flarion Technologies, Inc. Messages and control methods for controlling resource allocation and flow admission control in a mobile communications system
US7123598B1 (en) * 2001-06-29 2006-10-17 Nokia Inc. Efficient QoS signaling for mobile IP using RSVP framework
US20030039259A1 (en) * 2001-07-10 2003-02-27 Lila Madour Traffic flow template for managing packet data flows
US20030074452A1 (en) * 2001-10-11 2003-04-17 Nokia Corporation System and method of determining QoS establishment mode
TW201006267A (en) * 2001-11-02 2010-02-01 Interdigital Tech Corp Bi-directional and reverse directional resource reservation setup protocol
KR100438430B1 (ko) * 2002-01-24 2004-07-03 삼성전자주식회사 이동통신시스템에서 트래픽 플로우 탬플릿 재정렬 장치 및방법
AU2003205797A1 (en) * 2002-02-13 2003-09-04 Nokia Corporation Filtering of data packets in a communication network according to interface identifiers
FI115687B (fi) * 2002-04-09 2005-06-15 Nokia Corp Pakettidatan siirtäminen langattomaan päätelaitteeseen
US7206324B2 (en) * 2002-05-03 2007-04-17 Telefonaktiebolaget Lm Ericsson (Publ) QoS translator
JP3880451B2 (ja) * 2002-05-20 2007-02-14 富士通株式会社 Ｒｓｖｐを用いた移動通信システム
AU2003243346A1 (en) * 2002-06-06 2003-12-22 Thomson Licensing S.A. Interworking function (iwf) as logical radio network controller (rnc) for hybrid coupling in an interworking between wlan and a mobile communications network
FI20021093A0 (fi) * 2002-06-07 2002-06-07 Nokia Corp Tiedonsiirtomenetelmä ja -järjestelmä
WO2003105442A2 (en) * 2002-06-10 2003-12-18 Qualcomm, Incorporated Packet flow processing in a communication system
US7277455B2 (en) 2002-06-10 2007-10-02 Qualcomm Incorporated Packet flow processing in a communication system
US6741595B2 (en) * 2002-06-11 2004-05-25 Netrake Corporation Device for enabling trap and trace of internet protocol communications
US20040037264A1 (en) * 2002-08-23 2004-02-26 Charbel Khawand Pre-negotiated quality of service
US6904058B2 (en) * 2002-09-20 2005-06-07 Intel Corporation Transmitting data over a general packet radio service wireless network
US8161158B2 (en) * 2002-09-25 2012-04-17 Nokia Corporation Method in a communication system, a communication system and a communication device
US20040064555A1 (en) * 2002-09-27 2004-04-01 Renaud Cuny Service level allocation for IP networks
US20040121778A1 (en) * 2002-10-08 2004-06-24 Interdigital Technology Corporation Quality of service mapping between various types of wireless communication systems
US8488462B2 (en) * 2002-12-31 2013-07-16 Nokia Corporation Handling traffic flows in a mobile communications network
CN100426733C (zh) * 2003-01-16 2008-10-15 华为技术有限公司 网络通信中实现资源分配的系统及其方法
CN1553663B (zh) * 2003-05-26 2010-04-28 华为技术有限公司 减少软状态刷新的资源预留协议实现方法
EP1521405A1 (de) * 2003-09-30 2005-04-06 Sony International (Europe) GmbH Umkehrbare QoS Reservierung innerhalb einer Inbandsignalisierungseinheit
EP1695496B1 (de) * 2003-12-19 2011-03-30 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Betriebsmittelreservierung in einem paketvermittelten telekommunikationsnetz
US20050198264A1 (en) * 2004-01-29 2005-09-08 Bekiares Tyrone D. Dynamic selection of behavior sets for middleware
CN1981278B (zh) * 2004-03-12 2010-11-03 诺基亚公司 在无线通信系统中提供服务质量支持的方法和设备
CN100396054C (zh) * 2004-04-30 2008-06-18 华为技术有限公司 通用移动通信系统内部与外部间传输业务流数据包的方法
CN100420232C (zh) * 2004-04-30 2008-09-17 华为技术有限公司 一种传输业务流数据包的方法
CN100438497C (zh) * 2005-01-13 2008-11-26 华为技术有限公司 移动通信网络中处理应用功能实体信息的方法
CN101159740B (zh) * 2005-03-08 2011-05-04 华为技术有限公司 下一代网络中实现代理请求模式资源预留的方法和装置
CN101180835B (zh) * 2005-05-25 2010-07-14 韩国电子通信研究院 网络互联系统和网络互联系统中用于协商服务质量的方法
KR100788889B1 (ko) * 2005-06-22 2007-12-27 한국전자통신연구원 서비스 품질을 협상하는 장치 및 방법
WO2006137705A1 (en) * 2005-06-22 2006-12-28 Electronics And Telecommunications Research Institute Apparatus and method for negotiating quality of service
US20100005154A1 (en) * 2006-01-13 2010-01-07 Lg Electronics Inc. Method and apparatus for obtaining information for transfer of an external content
CN100450303C (zh) * 2006-01-24 2009-01-07 华为技术有限公司 Sgsn间切换的实现方法
DE102006006953A1 (de) * 2006-02-14 2007-08-23 T-Mobile International Ag & Co. Kg Verfahren zur Gewährleistung von Dienstgüte in paketvermittelnden Mobilfunknetzen
US8966113B2 (en) * 2006-03-03 2015-02-24 Cisco Technology, Inc. Technique for dynamically restoring original TE-LSP attributes for interdomain TE-LSPs
US8095475B2 (en) * 2006-03-23 2012-01-10 Exceleron Software, Inc. System and method for prepay account management system
US8289861B2 (en) 2006-03-24 2012-10-16 Qualcomm Incorporated Systems and methods for managing resources during handoff across communication systems having different grades of quality of service awareness
CN101416448B (zh) * 2006-03-31 2013-10-16 艾利森电话股份有限公司 在边缘路由器中更新状态的方法及相应的边缘路由器
US7933205B1 (en) * 2006-05-01 2011-04-26 At&T Mobility Ii Llc Generalized interconnection apparatus for delivering services based on real time performance requirements
DE602006010606D1 (de) * 2006-06-02 2009-12-31 Ericsson Telefon Ab L M Einrichtungen und verfahren zum garantieren einer dienstgüte pro dienstdatenfluss durch die trägerschicht
US8228798B2 (en) * 2006-06-28 2012-07-24 Cisco Technology, Inc. QoS-aware service flow mapping in mobile wireless all IP networks
US8363546B2 (en) 2006-10-16 2013-01-29 Bridgewater Systems Corp. Systems and methods for subscriber-centric dynamic spectrum management
WO2008079094A1 (en) * 2006-12-22 2008-07-03 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for communication device configuration
US8098639B2 (en) * 2007-01-02 2012-01-17 Motorola Solutions, Inc. System and method for managing communication channel assignments for different types of communication units in a communication system
WO2009025592A1 (en) * 2007-08-21 2009-02-26 Telefonaktiebolaget Lm Ericsson (Publ) Scheduling in wireless networks
US8301744B2 (en) * 2008-08-08 2012-10-30 Telcordia Technologies, Inc. Systems and methods for QoS provisioning and assurance for point-to-point SIP sessions in DiffServ-enabled MPLS networks
CN101505438B (zh) * 2008-12-31 2011-12-07 深圳市共进电子有限公司 一种epon终端ctc协议栈的实现方法及装置
US8498208B2 (en) * 2009-07-20 2013-07-30 Qualcomm Incorporated Turning on flows in network initiated QoS
CN101867906B (zh) * 2010-05-25 2012-12-12 中国科学院计算技术研究所 一种基于无线资源控制的信令交互管理方法
CN102572964B (zh) * 2010-12-16 2015-06-24 北京邮电大学 一种支持下一代信令(nsis)的ggsn的功能及流程设计
US20130124708A1 (en) * 2011-11-10 2013-05-16 Electronics And Telecommunications Research Institute Method and system for adaptive composite service path management
CN102685118B (zh) * 2012-05-02 2014-12-17 中兴通讯股份有限公司 单pdp双栈串行拨号方法和系统
US12531811B2 (en) * 2024-01-02 2026-01-20 Verizon Patent And Licensing Inc. Systems and methods for Quality of Service treatment of network traffic for different user interface elements

Family Cites Families (5)

* 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
US6671276B1 (en) * 1997-11-18 2003-12-30 Nec Corporation Switch based network architecture for IP multicast and integrated services
FI108192B (fi) * 1998-03-19 2001-11-30 Nokia Networks Oy Menetelmä ja laitteisto palvelun laadun kontrolloimiseksi matkaviestinjärjestelmässä
GB9806912D0 (en) * 1998-03-31 1998-05-27 Madge Networks Ltd A communications network end station
US6708034B1 (en) * 1999-09-13 2004-03-16 Nortel Networks Ltd. End-to-end quality of service guarantee in a wireless environment

Also Published As

Publication number Publication date
DE60120354D1 (de) 2006-07-20
CN1193565C (zh) 2005-03-16
CN1419773A (zh) 2003-05-21
AU3067401A (en) 2001-08-07
CN1592304A (zh) 2005-03-09
EP1250787B1 (de) 2006-06-07
ATE329441T1 (de) 2006-06-15
EP1250787A1 (de) 2002-10-23
WO2001056250A1 (en) 2001-08-02
US20010027490A1 (en) 2001-10-04

Similar Documents

Publication Publication Date Title
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE60130114T2 (de) Anwendungsbeeinflusste richtlinie
DE60211881T2 (de) Bindungsinformation für ip mediendatenströmen
DE602004009913T2 (de) Verfahren, system und netzwerkelement zur autorisierung einer datenübertragung
DE69921831T2 (de) Kontrolle der dienstqualitäten in einem mobilkommunikationssystem
DE602004005994T2 (de) Verteiltes Dienstgüte-Verwaltungssystem
DE60008735T2 (de) Steuerung von pdp-kontexten in mobilstationen
DE602004005604T2 (de) Verfahren zur dienstqualitätsdifferenzierung in paketmodus-mobilkommunikationsnetzen
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE60115030T2 (de) Kommunikationen unter verwendung von adaptiven mehrraten kodierern/dekodierern
DE60127869T2 (de) Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente
DE602005006095T2 (de) Bereitstellen von Informationen über die Beziehungen individueller Träger für mobile Endgeräte, die einen Multicast- oder Broadcastdienst empfangen
DE69834188T2 (de) Dynamische dienstqualitätreservierung in einem mobilen kommunikationsnetz
DE602004005842T2 (de) Skalierbare und adaptive QoS-Architektur für Mehrkanal Multicast/Broadcast Dienste
DE60213147T2 (de) Verfahren zur Dienstqualitätsauswahl in einem drahtlosen Kommunikationssystem
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60314860T2 (de) Betrachtung der mobilstationsfähigkeit bei der aushandlung der dienstqualität für paketvermittelte dienste
DE69833111T2 (de) Bestimmung von trägerdiensten in einem funkzugriffsnetz
DE60034654T2 (de) System und Verfahren zur Adaption und Verwaltung von IP Dienstqualität
DE60109809T2 (de) Verfahren und system für betriebsmittelreservierungen in einem multicast-netzwerk
DE60218992T2 (de) Verfahren und Vorrichtung zum Datenrundsenden in Netzwerken der dritten Generation
DE69935397T2 (de) Verfahren und Vorrichtung zur Echtzeitdatenübertragung in einem Paketfunknetz
DE60130911T2 (de) Verfahren und gerät für die koordinierte verrechnung von diensten in einer multimedia-sitzung
DE60125422T2 (de) Abbildung von paketen auf pdp-kontexte bei vielfach-verbindungen
WO2002096030A2 (de) Verfahren zur übertragung von datenpaketen über eine luftschnittstelle eines mobilfunksystems

Legal Events

Date Code Title Description
8364 No opposition during term of opposition