[go: up one dir, main page]

DE60130318T2 - Reservierung von dienstqualitäten in einem drahtlosen telekommunikationssystem - Google Patents

Reservierung von dienstqualitäten in einem drahtlosen telekommunikationssystem Download PDF

Info

Publication number
DE60130318T2
DE60130318T2 DE60130318T DE60130318T DE60130318T2 DE 60130318 T2 DE60130318 T2 DE 60130318T2 DE 60130318 T DE60130318 T DE 60130318T DE 60130318 T DE60130318 T DE 60130318T DE 60130318 T2 DE60130318 T2 DE 60130318T2
Authority
DE
Germany
Prior art keywords
path
messages
mobile station
reservation
support node
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
DE60130318T
Other languages
English (en)
Other versions
DE60130318D1 (de
Inventor
Sami Uskela
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.)
Callahan Cellular LLC
Original Assignee
Nokia Inc
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 Nokia Inc filed Critical Nokia Inc
Application granted granted Critical
Publication of DE60130318D1 publication Critical patent/DE60130318D1/de
Publication of DE60130318T2 publication Critical patent/DE60130318T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/15Flow control; Congestion control in relation to multipoint traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/824Applicable to portable or mobile terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/826Involving periods of time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/26Resource reservation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing 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/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14Backbone network devices

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)
  • Telephonic Communication Services (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • Die Erfindung bezieht sich auf das Reservieren der Dienstgüte in einem drahtlosen Telekommunikationssystem.
  • Die Dienstgüte (QoS) bestimmt, wie Daten, wie beispielsweise Paketdateneinheiten (PDU), in einem Telekommunikationssystem während der Übertragung verarbeitet werden. QoS-Niveaus, die für verschiedene Verbindungen bestimmt worden sind, steuern beispielsweise die Reihenfolge, mit der PDUs verschiedener Verbindungen in verschiedenen Netzelementen übertragen, gepuffert (PDU-Warteschlangen) und zurückgewiesen werden. Somit stellen verschiedene QoS-Niveaus beispielsweise verschiedene Ende-zu-Ende-Verzögerungen, Bitraten und die Anzahl verlorener PDUs dar.
  • RSVP (Resource Reservation Protocol, Ressourcenreservierungsprotokoll) ist ein wohl bekanntes Protokoll für das Reservieren der Dienstgüte, die durch irgend eine Anwendung in IP-Netzen (Internetprotokoll) gefordert wird. Das RSVP wird von einem Host verwendet, um eine spezifische Dienstgüte vom Netz für spezielle Anwendungsdatenflüsse anzufordern. Das RSVP wird auch von Routern verwendet, um QoS-Anforderungen an alle Knoten entlang dem oder den Pfaden der Flüsse zu liefern, und um geeignete Netzressourcen für das Liefern des geforderten Dienstes aufzubauen und aufrecht zu halten. Das RSVP befördert die Anforderung durch das IP-Netz, wobei es jeden Knoten besucht, den das Netz verwendet, um den Fluss zu befördern. An jedem Knoten versucht das RSVP eine Ressourcenreservierung für den Fluss zu machen.
  • Das RSVP fordert Ressourcen für einfache Flüsse an, das heißt es fordert Ressourcen nur in einer Richtung an. Somit behandelt das RSVP einen Sender als logisch unterschieden von einem Empfänger, obwohl dasselbe Anwendungsverfahren zur selben Zeit sowohl als ein Sender als auch als ein Empfänger agieren kann. Das RSVP arbeitet auf dem IPv4 oder IPv6, wobei es den Platz eines Transportprotokolls im Protokollstapel belegt. Das RSVP transportiert aber keine Anwendungsdaten.
  • Um eine Ressourcenreservierung an einem Knoten vorzunehmen, werden zwei Entscheidungsmodule, eine Zugangssteuerung (admission control) und eine Statutensteuerung (policy control), verwendet. Die Zugangssteuerung bestimmt, ob der Knoten ausreichend verfügbare Ressourcen hat, um die geforderte QoS zu liefern. Die Statutensteuerung bestimmt, ob der Benutzer eine administrative Erlaubnis hat, um die Reservierung vorzunehmen. Wenn eine Prüfung fehlschlägt, so gibt das RSVP eine Protokolleinheit mit einer Fehlermeldung an das Anwendungsverfahren, das die Anforderung ausgegeben hat. Wenn beide Prüfungen erfolgreich sind, werden Parameter in einer Paketklassifiziervorrichtung und einer Paketsteuervorrichtung eingestellt, um die gewünschte QoS zu erhalten. Die Paketklassifiziervorrichtung bestimmt die QoS-Klasse für jedes Paket, und die Steuervorrichtung fordert ordnet die Paketübertragung, um die versprochene QoS für jeden Fluss zu erzielen.
  • Es gibt zwei fundamentale RSVP-Nachrichtentypen: die Pfadnachrichten PFAD (PATH) und die Reservierungsnachrichten RESV. Jeder RSVP-Senderhost überträgt RSVP "Pfad" Nachrichten stromabwärts entlang der Einpunktverbindungsrouten (unicast) oder der Mehrpunktverbindungsrouten (multicast), die von dem oder den Verkehrslenkungsprotokollen geliefert werden, den Pfaden der Daten folgend. Diese Pfadnachrichten speichern einen "Pfadzustand" in jedem Knoten entlang des Weges. Dieser Pfadzustand umfasst mindestens die Unicast-IP-Adresse des vorherigen Sprungknotens, die verwendet wird, um die RESV-Nachrichten Sprung für Sprung in der umgekehrten Richtung zu lenken.
  • Jeder Empfängerhost sendet RSVP-Reservierungs-(RESV)-Nachrichten stromaufwärts zu den Sendern. Diese RESV-Reservierungsnachrichten müssen exakt der Umkehrung des Pfades oder der Pfade folgen, die die Datenpakete benutzen werden, das heißt sie werden stromauf zu allen Senderhosts, die in der Senderauswahl enthalten sind, gesendet. Sie schaffen und halten einen "Reservierungszustand" in jedem Knoten entlang dem Pfad oder den Pfaden aufrecht. RESV-Nachrichten müssen schließlich an die Senderhosts selber geliefert werden, so dass die Hosts die passenden Verkehrssteuerparameter für den ersten Sprung aufstellen können.
  • Das RSVP macht es erforderlich, dass Auffrischungsnachrichten periodisch von Ende zu Ende übertragen werden. Auffrischungsnachrichten umfassen Pfadnachrichten PFAD und Reservierungsnachrichten RESV. Eine IETF-Spezifikation (Internet Engineering Task Force) für das RSVP, die RFC2205 (Request for Comments: 2005), empfiehlt ein Auffrischungsintervall von 30 Sekunden, wobei aber jeder Knoten das Auffrischungsintervall unabhängig einstellen kann.
  • In drahtlosen Telekommunikationssystemen, wie GPRS-Netzen (General Packet Radio Service, allgemeiner Paketfunkdienst), die einen Paketfunkdienst liefern, ist die Bandbreite eine ziemlich begrenzte Ressource. Eine periodische Auffrischung, die vom RSVP gefordert wird, ist für die Verwendung von Funkressourcen nicht ökonomisch.
  • Die WO 99/50999 offenbart ein Kommunikationsnetz, das ein Ressourcenreservierungsprotokoll (RSVP) verwendet, um eine Dienstgüte zwischen Kommunikationsstationen zu reservieren. RSVP-Pfadnachrichten und Reservierungsnachrichten werden über ein Netz zwischen den kommunizierenden Stationen übertragen.
  • KURZE BESCHREIBUNG DER ERFINDUNG
  • Eine Aufgabe der Erfindung besteht darin, ein Verfahren und eine Ausrüstung, die das Verfahren implementiert, zu liefern, so dass die Dienstgüte in einem drahtlosen Telekommunikationssystem reserviert werden kann, wobei die Funkressourcen möglichst wenig in Anspruch genommen werden. Die Aufgaben der Erfindung werden mittels eines Verfahrens, eines Systems, einer Mobilstation und einem Unterstützungsknoten eines drahtlosen Telekommunikationssystems, die durch das gekennzeichnet sind, was in den unabhängigen Ansprüchen offenbart ist, gelöst. Die bevorzugten Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen offenbart.
  • Die Grundidee der Erfindung besteht darin, dass Pfad- und Reservierungsnachrichten, die periodisch übertragen werden, um die Dienstgütereservierung aufrecht zu halten, nicht zwischen einer Mobilstation und einem Unterstützungsknoten, der die Mobilstation bedient, weitergegeben werden. Wenn die Dienstgüte reserviert werden soll, werden erste Pfad- und Reservierungsnachrichten zwischen einer Mobilstation und einem Datenendgerät, das mit der Mobilstation kommuniziert, übertragen. Daten zumindest der ersten Pfad- und Reservierungsnachrichten werden in der Mobilstation und im Unterstützungsknoten gespeichert. Wenn nachfolgende Pfad- oder Reservierungsnachrichten empfangen werden, so wird geprüft, ob die Daten der ersten Pfad- und Reservierungsnachrichten desselben Flusses schon gespeichert sind. Wenn solche Daten gespeichert sind, werden die nächsten Pfad- und Reservierungsnachrichten verworfen, was bedeutet, dass sie nicht vom Unterstützungsknoten an die Mobilstation oder in umgekehrter Richtung übertragen werden. Um den QoS-Reservierungszustand aufrecht zu halten, werden Nachrichten, die den ersten Pfad- und Reservierungsnachrichten entsprechen, periodisch an die QoS-Protokolleinheiten der Mobilstation und des Datenendgeräts auf der Basis der gespeicherten Daten übertragen. Die Operation geht in dieser Weise weiter, immer wenn Pfad- und Reservierungsnachrichten empfangen werden, bis die Reservierung gelöscht wird.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung wird ein Zeitgeber in der Mobilstation und im Unterstützungsknoten aktiviert, wenn die ersten Nachrichten gespeichert sind, und die Nachrichten, die den ersten Pfad- und Reservierungsnachrichten entsprechen, werden periodisch an die QoS-Reservierungsanwendungen auf der Basis des Zeitgebers übertragen.
  • Ein Vorteil des Verfahrens und des Systems gemäß der Erfindung besteht darin, dass kritische Funkschnittstellenressourcen beträchtlich eingespart werden können. Die existierenden QoS-Protokolle können verwendet werden, und die erforderliche neue Funktion betrifft nur die Mobilstation und den Unterstützungsknoten. Gemäß einer bevorzugten Ausführungsform der Erfindung übertragen der Unterstützungsknoten und die Mobilstation unabhängig Nachrichten, die den gespeicherten Pfad- und Reservierungsnachrichten entsprechen, an die QoS-Protokolleinheiten. Als ein Ergebnis werden keine Funkressourcen für das Übertragen periodischer Pfad- und Reservierungsnachrichten benötigt, um die QoS-Reservierung aufrecht zu halten.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird nachfolgend detaillierter mittels bevorzugter Ausführungsformen unter Bezug auf die begleitenden Zeichnungen beschrieben.
  • 1 zeigt ein drahtloses Telekommunikationssystem, das eine GPRS-Funktion umfasst;
  • 2 zeigt Protokollschichten eines Systems gemäß einer bevorzugten Ausführungsform der Erfindung;
  • 3 ist ein Flussdiagramm, das die Funktion gemäß einer bevorzugten Ausführungsform der Erfindung darstellt;
  • 4 zeigt eine von einer Mobilstation ausgehende Dienstgütereservierung; und
  • 5 zeigt die Dienstgütereservierung, die von einem Datenendgerät, das mit dem Internet verbunden ist, aktiviert wird.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Nachfolgend wird eine bevorzugte Ausführungsform der Erfindung beispielhaft unter Verwendung der Funktionen und der Struktur des GSM/GPRS-System beschrieben, wobei die Erfindung aber auch auf andere mobile Kommunikationssysteme, die Mittel für die Reservierung einer QoS liefern, angewandt werden kann.
  • 1 beschreibt die Basiskomponenten des GSM/GPRS-Systems, ohne ihre Merkmale oder andere Komponenten des Systems detaillierter darzustellen. Eine Mobilstation MS ist in einer Zelle angeordnet, die von einer Basisstation BTS bedient wird. Die MS umfasst eine entfernbare SIM-Anwendung (Teilnehmeridentifizierungsmodul), um den Teilnehmer zu identifizieren. Eine Anzahl von Basisstationen BTS sind mit einer Basisstationssteuerung BSC verbunden, die die Funkfrequenzen und Kanäle steuert. Basisstationssteuerungen BSC sind mit einer Mobildienstvermittlungszentrale MSC verbunden.
  • In 1 umfasst das GPRS-System, das mit dem GSM-Netz verbunden ist, einen bedienenden GPRS-Unterstützungsknoten SGSN und einen GPRS-Gateway-Unterstützungsknoten GGSN. Die verschiedenen SGSNs und GGSNs sind durch ein GPRS-Hauptnetz, das typischerweise auf dem IP-Protokoll basiert, verbunden.
  • Der SGSN ist mit der BSC verbunden, und er stellt den Dienstzugangspunkt zum GPRS-Netz für die GPRS-Mobilstation MS dar. Der SGSN handhabt auch die Authentifizierung der GPRS-Mobilstationen. Wenn die Authentifizierung erfolgreich ist, registriert der SGSN die MS beim GPRS-Netz und kümmert sich um dessen Mobilitätsverwaltung. Das Heimatregister HLR umfasst GPRS-Teilnehmerdaten und Verkehrslenkungsinformation und wird typischerweise auch von der MSC verwendet.
  • Um GPRS-Daten zu senden und zu empfangen, sollte die MS die Paketdatenadresse aktivieren, die es verwenden will, durch das Anfordern eines PDP-Aktivierungsverfahrens (Paketdatenprotokoll). Diese Operation macht die MS im entsprechenden GGSN bekannt, und eine Zusammenarbeit mit externen Datennetzen kann beginnen. Insbesondere wird ein PDP-Kontext in der MS, dem GGSN und dem SGSN erzeugt. Der PDP-Kontext definiert verschiedene Datenübertragungsparameter, wie den PDP-Typ (typischerweise IP), die PDP-Adresse (typischerweise eine IP-Adresse), die Dienstgüte QoS und die Netzdienstzugangspunktkennung (Network Service Access Point Identifier, NSAPI). Die MS aktiviert den PDP-Kontext mit einer spezifischen Nachricht, Aktiviere PDP-Kontext Anforderung, in welcher sie Information über die temporäre logische Verbindungskennung (Temporary Logical Link Identity, TLLI), den PDP-Typ, die PDP-Adresse, die geforderte QoS und die NSAPI und optional den Zugangspunktnamen (Access Point Name, APN) angibt. Die MS kann mehrere PDP-Kontexte mit unterschiedlichen QoS-Parametern aktiv halten.
  • Aktuell können fünf QoS-Parameter im GPRS verwendet werden: Dienstvorrang, Verzögerungsklasse, Zuverlässigkeit und mittlere Bitrate und Spitzenbitrate. "Dienstvorrang" definiert eine gewisse Art einer Priorität für die Pakete, die zu einem gewissen PDP-Kontext gehören (das sind Pakete, die im Fall einer Verstopfung fallen gelassen werden). Die "Verzögerungsklasse" definiert mittlere und maximale Verzögerung für die Übertragung jedes Datenpakets, das zu diesem Kontext gehört. Die "Zuverlässigkeit" wiederum spezifiziert, ob bestätigte oder nicht bestätigte Dienste auf den LLC-Schichten (Logical Link Control, logische Verbindungssteuerung) und RLC-Schichten (Radio Link Control, Funkverbindungssteuerung) verwendet werden. Zusätzlich spezifiziert sie, ob ein geschützter Modus im Fall eines nicht bestätigten Dienstes verwendet werden soll, und ob die GPRS-Hauptverbindung das TCP oder das UDP verwenden soll, um Datenpakete, die zum PDP-Kontext gehören, zu übertragen.
  • Der GGSN ist mit dem Internet verbunden. N1 und N2 sind Internetknoten, und DT ist ein Datenendgerät, das auch mit dem Internet verbunden ist. Vom Blickpunkt der externen Netze stellt der GGSN einen Router zu einem Unternetz da, da der GGSN die GPRS-Infrastruktur gegenüber den externen Netzen verbirgt. Wenn der GGSN Daten empfängt, die an einen GPRS-Teilnehmer adressiert sind, so prüft er, ob ein PDP-Kontext für den Teilnehmer aktiv ist. Wenn dem so ist, gibt der GGSN die Daten an den SGSN, der die MS bedient, wenn aber die Adresse inaktiv ist, können die Daten verworfen werden oder es kann ein vom Netz ausgehender PDP-Kontext aktiviert werden. Die von der Mobilstation ausgehenden Pakete werden vom GGSN an das Internet gelenkt.
  • Wenn der PDP-Kontext aktiv ist, kann das RSVP verwendet werden, um eine QoS zwischen der MS und dem DT zu reservieren. In Abhängigkeit davon, welcher der Urheber der Datenlieferung ist, werden PFAD-Nachrichten durch jeden Knoten zwischen den RSVP-Protokolleinheiten der MS und dem DT gesandt (Sprung um Sprung) (GGSN, N1), wobei die PFAD-Nachrichten das Paketformat und die Verkehrseigenschaften des Datenflusses, der erzeugt werden wird, definieren. Wenn die PFAD-Nachrichten empfangen werden, sendet der Empfänger RESV-Nachrichten, die verwendet werden, um die geforderte QoS zu reservieren. Wenn die QoS durch das RSVP reserviert wird, werden die QoS-Parameter auf die passenden GPRS-QoS-Parameter abgebildet, und die Netzressourcen werden für die Verbindung entsprechend reserviert. Im Falle von Daten einer Aufwärtsverbindung (von der Mobilstation ausgehende, MO) kann die MS schon einen PDP-Kontext anfordern, wobei die QoS die Anwendungsbedürfnisse erfüllt. In ähnlicher Weise sollte für Daten einer Abwärtsverbindung (an der Mobilstation endend, MT) der GGSN die QoS-Information von den RSVP-Nachrichten in die GPRS QoS-Parameter übersetzen.
  • Wenn der aktivierte PDP-Kontext für die QoS-Anforderungen, die von der RSVP-Protokolleinheit angefordert werden, nicht passend ist, kann die Mobilstation MS den existierenden PDP-Kontext modifizieren oder einen anderen PDP-Kontext initiieren, um die geforderte QoS besser zu erfüllen.
  • Protokollschichten des Systems gemäß einer bevorzugten Ausführungsform der Erfindung sind in 2 dargestellt. Auf der Basis der Anwendungs-APP-Bedürfnisse reserviert die RSVP-Schicht in der Mobilstation MS QoS-Reservierungen und hält diese aufrecht durch das Senden und Empfangen von RSVP-Nachrichten durch eine Internetprotokoll-IP-Schicht und GPRS-Schichten L1/L2 zu einem RSVP-Dienstknoten im GPRS, wobei dieser vorteilhafterweise ein GGSN ist. Der GGSN umfasst Schichten 1 und 2 L1/L2 und eine IP-Schicht, um mit GPRS-Netzelementen, Mobilstationen (MS) und auf der anderen Seite mit Knoten im Internet zu kommunizieren. Das IPv4 oder das IPv6 können verwendet werden. Die RSVP-Schicht sorgt dafür, dass RSVP-Nachrichten an/von der Mobilstation MS und an/von einem Datenendgerät DT im Internet gesendet werden. Die Mobilstation MS umfasst eine neue Funktion, die als RSVP-Einhüllung (RSVP wrapper) in der Mobilstation MS bezeichnet wird, und der GGSN umfasst eine RSVP-Einhüllung', die ein Gegenstück der RSVP-Einhüllung ist. Die RSVP-Einhüllung und die RSVP-Einhüllung verwerfen die PFAD- oder RESV-Nachrichten (die über das GPRS-Netz zu übertragen sind), wenn es notwendig ist, um somit die Verkehrslast über der Funkschnittstelle zu reduzieren. Sie erlauben jedoch vorteilhafterweise die Übertragung anderer Arten von RSVP-Nachrichten, wie Pfadabbruchnachrichten PFADABBRUCH (PATHTEAR) und Reservierungsabbruchnachrichten RESVABBRUCH (RESVTEAR), die verwendet werden, um QoS-Reservierungen zu entfernen. Die RSVP-Einhüllung sorgt dafür, dass die passenden PFAD- oder RESV-Nachrichten zur RSVP-Schicht der MS periodisch übertragen werden, und die RSVP-Einhüllung' sorgt dafür, dass die passenden PFAD- oder RESV-Nachrichten an die RSVP-Schicht des Datenendgeräts DT periodisch übertragen werden.
  • Wie oben beschrieben wurde, werden PFAD- und RESV-Nachrichten gemäß dem RSVP zwischen RSVP QoS Protokolleinheiten oder Teilnehmern, die an der Reservierung beteiligt sind, periodisch übertragen. Es wird Bezug genommen auf die 3, die ein Flussdiagramm ist, das die Funktion gemäß einer bevorzugten Ausführungsform der Erfindung darstellt. Die in 3 gezeigte Funktion kann in einer RSVP-Einhüllung einer Mobilstation MS und in einer RSVP Einhüllung' eines Unterstützungsknotens GGSN angewandt werden. Wenn eine PFAD- oder RESV-Nachricht in 300 empfangen wird, so wird in 301 geprüft, ob Daten über eine ähnliche Nachricht, die sich auf dieselbe Reservierung beziehen, schon gespeichert sind. Wenn Daten über eine ähnliche Nachricht nicht gespeichert sind, werden mindestens die Daten über die empfangene Nachricht gespeichert, wonach die Nachricht an 302 gesandt wird. Wenn Daten über PFAD- und RESV-Nachrichten, die einander entsprechen und die sich auf dieselbe Reservierung beziehen, dann gespeichert sind, wird in 303 vorzugsweise ein Zeitgeber aktiviert. Eine PFAD- oder RESV-Nachricht wird dann in 304 periodisch an die RSVP-Protokolleinheit gesandt. Wenn Daten über eine ähnliche Nachricht gespeichert sind, wird in 305 geprüft, ob Daten über PFAD- und RESV-Nachrichten, die einander entsprechen und die sich auf dieselbe Reservierung beziehen, gespeichert sind. Wenn beispielsweise die empfangene Nachricht eine RESV-Nachricht ist, so wird geprüft, ob Daten über eine entsprechende PFAD-Nachricht gespeichert sind. Wenn Daten sowohl über eine PFAD- als auch eine RESV-Nachricht gespeichert sind, wird in 306 die empfangene Nachricht verworfen oder nicht weitergeleitet. Wenn keine Daten über entsprechenden PFAD- und RESV-Nachrichten gespeichert sind, so kann die Nachricht an 307 geschickt werden.
  • Mindestens die Basisdaten über die ersten PFAD- und RESV-Nachrichten werden gespeichert, um die Nachrichten voneinander zu unterscheiden, das heißt mindestens Daten über dem Nachrichtentyp (PFAD oder RESV) und über die Reservierung (und den Fluss), zu dem die Nachricht gehört. Gemäß einer Ausführungsform der Erfindung werden die ersten PFAD- und RESV-Nachrichten als solche gespeichert, und die nachfolgend empfangenen Nachrichten können direkt mit den gespeicherten Nachrichten verglichen werden. In den Beispielen, die in Verbindung mit den 4 und 5 beschrieben werden, werden die Nachrichten als solche gespeichert.
  • Es sollte angemerkt werden, dass die Verwendung eines Zeitgebers nicht die einzige mögliche Art des periodischen Übertragens von Nachrichten ist. Gemäß einer Ausführungsform der Erfindung informiert die Mobilstation oder der Unterstützungsknoten GGSN, der die Nachricht verworfen hat, den Unterstützungsknoten GGSN oder die Mobilstation von der Notwendigkeit, die Nachricht zu übertragen. Diese Information kann beispielsweise in einer kurzen Signalisiernachricht über das GPRS-Netz übertragen werden.
  • Eine Mobilstation oder ein Unterstützungsknoten gemäß einer bevorzugten Ausführungsform der Erfindung umfasst Mittel, um den oben beschriebenen Empfang von Nachrichten, das Prüfen von Nachrichten, das Speichern der Nachrichteninformation, das Verwerfen von Nachrichten, das Senden von Nachrichten und die zeitliche Steuerung von Nachrichten zu liefern. Sie umfassen Prozessoren und einen Speicher, die verwendet werden können, um die erfinderische Funktion zu liefern.
  • Unter Bezug auf 4 wird eine QoS-Reservierung beschrieben, bei dem eine MS die Reservierung verursacht. Die MS hat einen aktiven PDP-Kontext, und die Anwendung APP fordert ein spezifisches QoS-Niveau an. Die RSVP-Schicht der Mobilstation erzeugt und sendet eine passende PFAD-Nachricht 401. Die RSVP-Einhüllung fängt die PFAD-Nachricht ab und speichert eine Kopie der Nachricht, 402, wonach die Nachricht an die IP-Schicht gesandt wird. Die IP-Schicht lenkt die Nachricht an den GGSN 403, der im optimalen Fall der erste Router nach dem drahtlosen Netz ist.
  • Die RSVP-Einhüllung' im GGSN fängt die PFAD-Nachricht ab, speichert eine Kopie der Nachricht, 404, und sendet die Nachricht an die RSVP-Schicht. Die RSVP-Schicht des GGSN verhält sich gemäß der RSVP-Spezifikation und sendet die PFAD-Nachricht an den nächsten Sprungrouter 405, der in diesem Beispiel das Datenendgerät DT ist. Obwohl es in 4 aus Gründen der Klarheit nicht gezeigt ist, kann es eine Vielzahl von Knoten geben, die das RSVP-Verfahren handhaben und die QoS reservieren. Das DT empfängt die PFAD-Nachrichten und sendet eine RESV-Nachricht an den GGSN 406.
  • Wenn die RESV-Nachricht im Unterstützungsknoten GGSN empfangen wird, agiert die RSVP-Schicht gemäß der RSVP-Spezifikation und sendet die RESV-Nachricht weiter. Die RSVP-Einhüllung' des GGSN fängt die RESV-Nachricht ab und findet heraus, dass die RESV-Nachricht eine Antwort auf die PFAD-Nachricht ist, die früher gespeichert wurde. Die RSVP-Einhüllung' speichert eine Kopie der RESV-Nachricht 407 und sendet die Nachricht an die Mobilstation MS 408. Da die PFAD- und RESV-Nachrichten, die sich auf denselben Fluss beziehen, nun gespeichert sind, startet die RSVP-Einhüllung' vorteilhafterweise einen Zeitgeber.
  • Die RSVP-Einhüllung in der MS fängt die RESV-Nachricht ab und findet heraus, dass die RESV-Nachricht eine Antwort auf die PFAD-Nachricht ist, die früher gespeichert wurde. Die RSVP-Einhüllung speichert eine Kopie der RESV-Nachricht 409 und sendet die Nachricht an die RSVP-Schicht. Da die PFAD- und RESV-Nachrichten, die sich auf denselben Fluss beziehen, nun gespeichert sind, startet auch die RSVP-Einhüllung vorteilhafterweise einen Zeitgeber. Die Ende-zu-Ende RSVP-Reservierung für die Verbindung ist nun aufgebaut, und die RSVP-Schicht informiert die Anwendung, dass sie die Datenübertragung starten kann, 410.
  • Die RSVP-PFAD-Nachrichten müssen periodisch gemäß dem verwendeten Wiederauffrischungsintervall gesendet werden, um die Ende-zu-Ende-QoS-Reservierungen aufrecht zu halten. Die RSVP-Schicht der Mobilstation sendet PFAD-Nachrichten 411, die die RSVP-Einhüllung abfängt. Wenn sie zu den PFAD-Nachrichten passen, die früher gesendet wurden, und die RESV-Nachricht desselben Flusses auch gespeichert ist, verwirft die Einhüllung die Nachrichten 412.
  • Auf der Basis des Zeitgebers halt die RSVP-Einhüllung' im GGSN die RSVP-Reservierung durch das periodisch Senden der geforderten PFAD-Nachrichten an die RSVP-Schicht gemäß den Parametern in den abgefangenen PFAD- und RESV-Nachrichten 413 aufrecht. Die RSVP-Schicht des GGSN agiert gemäß der RSVP-Spezifikation und sendet eine PFAD-Nachricht an das DT 414.
  • Das DT sendet eine RESV-Nachricht zurück an den GGSN 415, und die RSVP-Einhüllung' verwirft die RESV-Nachricht 416. Die RSVP-Einhüllung sendet die RESV-Nachrichten an die RSVP-Schicht der MS 417 auf der Basis des Zeitgebers, der von der RSVP-Einhüllung aktiviert wurde.
  • Die RSVP-"Abbruch"-Nachrichten heben einen Pfad- oder Reservierungszustand auf, und sie werden vorteilhafterweise, so bald die Anwendung endet, übertragen. Es gibt zwei Typen von RSVP-Abbruchnachrichten, PFADABBRUCH und RESVABBRUCH. Eine PFADABBRUCH-Nachricht bewegt sich zu allen Empfängern stromabwärts von ihrem Initiierungspunkt und löscht den Pfadzustand als auch alle abhängigen Reservierungszustände entlang des Weges. Eine RESVABBRUCH-Nachricht löscht den Reservierungszustand und bewegt sich zu allen Sendern stromaufwärts von ihrem Initiierungspunkt. Eine PFADABBRUCH (RESVABBRUCH) Nachricht kann als eine PFAD-Nachricht (beziehungsweise RESV-Nachricht) im umgekehrten Sinn begriffen werden. RESVERR (Reservierungsfehler) und PFADERR (Pfadfehler) Nachrichten werden verwendet, um Fehler zu berichten und werden vorteilhafterweise über das GPRS-Netz geliefert, ohne verworfen zu werden.
  • In 4 wird eine PFADABBRUCH-Nachricht durch die RSVP-Schicht 418 erzeugt. Wenn die Nachricht keine PFAD- oder RESV-Nachricht ist, sendet die RSVP-Einhüllung die Nachricht an den GGSN 419 weiter. Entsprechend wird die PFADABBRUCH-Nachricht an das DT 420 weiter gesandt, und die Pfad- und Reservierungszustände werden gelöscht.
  • Es sollte angemerkt werden, dass die QoS-Reservierung nur für eine Aufwärtsverbindung oder eine Abwärtsverbindung oder in beiden Richtungen vorgenommen werden kann. Dies hängt von den Anwendungsbedürfnissen ab, beispielsweise kann eine Videoverbindungs-QoS-Reservierung in beiden Richtungen erforderlich sein, wohingegen bei einem Surfen durch das WWW (World Wide Web), die QoS-Reservierung nur für die Daten der Abwärtsverbindung erforderlich sein kann.
  • Die 5 zeigt eine QoS-Reservierung gemäß einer Ausführungsform der Erfindung, wo das Datenendgerät DT die Reservierung initiiert. Dieselben Mechanismen finden auch auf ankommende QoS-Reservierung (das sind PFAD-Nachrichten) Anwendung; die Rollen der RSVP-Einhüllung und der RSVP-Einhüllung' sind nur ausgetauscht.
  • Die RSVP-Schicht des DT erzeugt und sendet eine passende PFAD-Nachricht an den GGSN 501. Die RSVP-Schicht des GGSN agiert gemäß der RSVP-Spezifikation und liefert die Nachricht weiter. Die RSVP-Einhüllung' fängt die PFAD-Nachricht ab und speichert eine Kopie der Nachricht 502. Die PFAD-Nachricht wird an die MS 503 gesandt. Die RSVP-Einhüllung in der MS fängt die PFAD-Nachricht ab, speichert eine Kopie der Nachricht 504 und gibt die Nachricht an die RSVP-Schicht. Die RSVP-Schicht der MS verhält sich gemäß der RSVP-Spezifikation und erzeugt eine RESV-Nachricht 505. Die RSVP-Einhüllung speichert eine Kopie der erzeugten RESV- Nachricht 506 und sendet die Nachricht vorwärts an den GGSN 507. Da die PFAD- und RESV-Nachrichten, die sich auf denselben Fluss beziehen, nun gespeichert sind, startet die RSVP-Einhüllung vorteilhafterweise einen Zeitgeber.
  • Wenn die RESV-Nachricht im Unterstützungsknoten GGSN empfangen wird, fängt die RSVP-Einhüllung' die RESV-Nachricht ab und findet heraus, dass die RESV-Nachricht eine Antwort auf die PFAD-Nachricht ist, die früher gespeichert wurde. Die RSVP-Einhüllung' speichert eine Kopie der RESV-Nachricht 508, wonach die RSVP-Schicht die Nachricht an das DT 509 weitergibt. Da die PFAD- und RESV-Nachrichten, die sich auf denselben Fluss beziehen, nun gespeichert sind, startet die RSVP-Einhüllung' vorteilhafterweise einen Zeitgeber.
  • Gemäß dem RSVP sendet das DT die PFAD-Nachrichten periodisch, 510. Die RSVP-Einhüllung' fängt eine PFAD-Nachricht ab und verwirft die Nachricht, wenn sie zur PFAD-Nachricht passt, die früher gespeichert wurde (und wenn die RESV-Nachricht desselben Flusses auch gespeichert ist), 511. Auf der Basis des Zeitgebers, den die RSVP-Einhüllung aktiviert hat, sendet die RSVP-Einhüllung eine PFAD-Nachricht auf der Basis der gespeicherten PFAD-Nachricht an die RSVP-Schicht, 512. Die RSVP-Schicht erzeugt eine RESV-Nachricht, 513. Die RSVP-Einhüllung verwirft die RESV-Nachricht, wenn sie zur RESV-Nachricht passt, die früher gespeichert wurde, und wenn die PFAD-Nachricht desselben Flusses auch gespeichert ist, 514.
  • Auf der Basis des Zeitgebers, der in der RSVP-Einhüllung' im GGSN aktiviert wurde, hält die RSVP-Einhüllung die RSVP-Reservierung aufrecht durch das periodische Senden der geforderten RESV-Nachrichten an die RSVP-Schicht gemäß den Parametern, die in den PFAD- und RESV-Nachrichten 515 gespeichert sind. Die RSVP-Schicht des GGSN agiert gemäß der RSVP-Spezifikation und sendet eine RESV-Nachricht an das DT, 516. Um die QoS-Reservierung aufzuheben, kann die RSVP-Schicht im DT oder der MS dann eine PFADABBRUCH- oder RESVABBRUCH-Nachricht senden, die über die Schnittstelle zwischen der MS und dem GGSN übertragen wird (nicht gezeigt).
  • Die RSVP-Einhüllung und die RSVP-Einhüllung' wissen, ob die MS oder das DT die Reservierung verursacht hat und wissen somit, ob PFAD- oder RESV-Nachrichten an die RSVP-Protokolleinheiten zu senden sind. Die Übertragungszeiten der PFAD/RESV-Nachrichten, die vorzugsweise von Zeitgebern bestimmt werden, hängen auch davon ab, ob die MS oder das DT die Reservierung verursacht hat.
  • Die oben beschriebenen Mechanismen erfordern es nur, dass ein PFAD/RESV-Nachrichtenpaar über die Funkschnittstelle während der gesamten Sitzung gesandt wird, während das Standardverfahren typischerweise mehrere Nachrichtenpaare pro Minute erfordert. Dies spart in beträchtlicher Weise Funkschnittstellenressourcen.
  • Die einzige Modifikation zu existierenden Systemen besteht im Einschub der RSVP-Einhüllungsfunktion und der RSVP-Einhüllungsfunktion'. Die aktuellen RSVP-Implementierungen werden im System gemäß einer bevorzugten Ausführungsform der Erfindung perfekt arbeiten.
  • Die oben beschriebene Funktion der Erfindung kann natürlich auch bei anderen Verbindungen als den Punkt-zu-Punkt-Verbindungen, die im obigen Beispiel beschrieben wurden, verwendet werden. Beispielsweise können bei Mehrpunktübertragungen die PFAD- und RESV-Nachrichten, die sich auf die Verbindungen zwischen einer Mobilstation und mehreren verschiedenen Internet-Hosts beziehen, in der Mobilstation MS und im bedienenden GGSN gespeichert werden. Wenn das RSVP in einer Verbindung von Mobilstation zu Mobilstation verwendet wird, ist es nicht notwendig, die PFAD- und RESV-Nachrichten immer über die Funkschnittstelle beider drahtlosen Netze zu übertragen, wie das oben beschrieben wurde.
  • Die Erfindung kann auch auf andere drahtlose Telekommunikationssysteme, insbesondere das UMTS, angewandt werden, dessen Kernnetz auf GSM/GPRS-Netzen basiert. Die Erfindung ist auch für die QoS-Reservierung von IP-basierten Anwendungen, die auf leitungsvermittelten Diensten arbeiten, wie HSCSD (High Speed Circuit Switched Data) geeignet, wo die RSVP-Einhüllungsfunktion' beispielsweise in einem Zugangspunkt zum Internet implementiert werden kann. Die Erfindung kann auch auf verschiedene drahtlose lokale Netze (WLAN) angewandt werden.
  • Es ist für einen Fachmann offensichtlich, dass wenn die Technologie fortschreitet, das erfinderische Konzept auf viele verschiedene Arten implementiert werden kann. Somit sind die Erfindung und ihre Ausführungsformen nicht auf die obigen Beispiele begrenzt, sondern sie können innerhalb des Umfangs der angefügten Ansprüche variieren.

Claims (13)

  1. Verfahren zum Reservieren einer Dienstgüte (QoS) in einem drahtlosen Telekommunikationssystem, umfassend mindestens eine Mobilstation, einen Supportknoten, der die Mobilstation bedient, und ein Daten-Endgerät, das mit der Mobilstation kommuniziert, wobei in dem System eine Dienstgüte reserviert und aufrechterhalten wird durch Übertragen (403; 406) von Pfadnachrichten und Reservierungsnachrichten zwischen QoS-Protokoll-Entitäten der Mobilstation und des Daten-Endgeräts, gekennzeichnet durch – Speichern (402; 404; 407; 409) von Daten über mindestens erste Pfad- und Reservierungsnachrichten, die zwischen der Mobilstation und dem Daten-Endgerät zu übertragen sind, in der Mobilstation und dem Supportknoten, beim Reservieren einer Dienstgüte; – Verwerfen (412; 416) von nächsten Pfad- und Reservierungsnachrichten, die von dem Supportknoten an die Mobilstation und von der Mobilstation an das Daten-Endgerät zu übertragen sind und die zu dem gleichen Fluss wie die ersten Pfad- und Reservierungsnachrichten gehören, auf der Basis der gespeicherten Daten; – Übertragen (413; 417) von Nachrichten, die den ersten Pfad- oder Reservierungsnachrichten entsprechen, periodisch von der Mobilstation an die QoS-Protokoll-Entität der Mobilstation und von dem Supportknoten an die QoS-Protokoll-Entität des Daten-Endgeräts, auf der Basis der gespeicherten Daten.
  2. Verfahren nach Anspruch 1, gekennzeichnet durch – Aktivieren (303) eines Zeitgebers, in Reaktion auf das Empfangen der ersten Pfad- und Reservierungsnachrichten in der Mobilstation und/oder dem Supportknoten; – Übertragen (304) von Nachrichten, die den ersten Pfad- oder Reservierungsnachrichten entsprechen, periodisch an die QoS-Protokoll-Entitäten der Mobilstation und des Daten-Endgeräts, auf der Basis des Zeitgebers.
  3. Verfahren nach Anspruch 1 oder 2, gekennzeichnet durch – Übertragen (419; 420) von Nachrichten, die sich auf ein Aufheben der Dienstgütereservierung und auf Fehlersituationen beziehen, zwischen einer Mobilstation und einem Daten-Endgerät, auch falls Pfad- und Reservierungsnachrichten verworfen wurden.
  4. Verfahren nach Anspruch 3, gekennzeichnet durch – Löschen der gespeicherten Daten aus dem Speicher, in Reaktion auf das Aufheben der Dienstgütereservierung zwischen der Mobilstation und dem Daten-Endgerät.
  5. Verfahren nach irgendeinem der vorherigen Ansprüche, dadurch gekennzeichnet – dass die Dienstgüte gemäß RSVP reserviert wird; und – dass die Pfadnachrichten PATH-Nachrichten sind und die Reservierungsnachrichten RESV-Nachrichten sind.
  6. Verfahren nach irgendeinem der vorherigen Ansprüche, gekennzeichnet durch – Speichern der ersten Pfad- und Reservierungsnachrichten als solche; – Verwerfen der nächsten Nachrichten, falls sie den gespeicherten ersten Pfad- und Reservierungsnachrichten entsprechen; und – Übertragen von Nachrichten periodisch an die QoS-Protokoll-Entitäten, auf der Basis der gespeicherten ersten Pfad- und Reservierungsnachrichten.
  7. Verfahren nach irgendeinem der vorherigen Ansprüche, dadurch gekennzeichnet dass – die Mobilstation den General Packet Radio Service (GPRS) unterstützt, und der Support-Knoten ein GPRS-Gateway-Supportknoten (GGSN) ist.
  8. Drahtloses Telekommunikationssystem, umfassend mindestens eine Mobilstation, einen Supportknoten, der die Mobilstation bedient, und ein Daten-Endgerät, das mit der Mobilstation kommuniziert, wobei in dem System eine Dienstgüte reserviert und aufrechterhalten wird durch Übertragen (403; 406) von Pfadnachrichten und Reservierungsnachrichten zwischen QoS-Protokoll-Entitäten der Mobilstation und des Daten-Endgeräts, dadurch gekennzeichnet, dass – die Mobilstation und der Supportknoten eingerichtet sind zum Speichern (402; 404; 407; 409) von Daten über mindestens erste Pfad- und Reservierungsnachrichten, die zwischen der Mobilstation und dem Daten-Endgerät zu übertragen sind, beim Reservieren einer Dienstgüte; – die Mobilstation eingerichtet zum Verwerfen (412) von nächsten Pfad- oder Reservierungsnachrichten, die von der Mobilstation an das Daten-Endgerät zu übertragen sind und die zu dem gleichen Fluss wie die ersten Pfad- und Reservierungsnachrichten gehören, auf der Basis der gespeicherten Daten; – der Supportknoten eingerichtet ist zum Verwerfen (416) von nächsten Pfadoder Reservierungsnachrichten an die Mobilstation und die zu dem gleichen Fluss wie die ersten Pfad- und Reservierungsnachrichten gehören, auf der Basis der gespeicherten Daten; – wobei die Mobilstation eingerichtet ist zum Übertragen einer Nachricht, die der ersten Pfad- oder Reservierungsnachricht entspricht, periodisch an die QoS-Protokoll-Entität der Mobilstation; und – der Supportknoten eingerichtet ist zum Übertragen einer Nachricht, die der ersten Pfad- oder Reservierungsnachricht entspricht, periodisch an die QoS-Protokoll-Entität des Daten-Endgeräts, auf der Basis der gespeicherten Daten.
  9. Drahtloses Telekommunikationssystem nach Anspruch 8, dadurch gekennzeichnet, dass – die Mobilstation und der Supportknoten eingerichtet sind zum Aktivieren (303) eines Zeitgebers, in Reaktion auf das Empfangen der ersten Pfad- und Reservierungsnachrichten in der Mobilstation und/oder dem Supportknoten; und – die Mobilstation und der Supportknoten eingerichtet sind zum Übertragen (304) der nächsten Nachrichten, die den ersten Pfad- und Reservierungsnachrichten entsprechen, periodisch an die QoS-Protokoll-Entitäten, auf der Basis des Zeitgebers.
  10. Drahtloses Telekommunikationssystem nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass – die Mobilstation und der Supportknoten eingerichtet sind zum Übertragen (419; 420) von Nachrichten, die sich auf ein Aufheben der Dienstgütereservierung und Fehlersituationen beziehen, zwischen der Mobilstation und dem Daten-Endgerät, auch falls Pfad- und Reservierungsnachrichten verworfen wurden.
  11. Mobilstation, umfassend eine QoS-Protokoll-Entität, eingerichtet zum Senden (403) und Empfangen von Pfad- und Reservierungsnachrichten, die übertragen werden, um eine Dienstgüte zu reservieren und aufrechtzuerhalten, dadurch gekennzeichnet, dass die Mobilstation weiter umfasst – Mittel zum Speichern (402; 409) von Daten über mindestens erste Pfad- und Reservierungsnachrichten, die übertragen werden, um eine Dienstgüte zu reservieren; – Mittel zum Vergleichen (301; 305) von Pfad- und Reservierungsnachrichten mit den gespeicherten Daten; – Mittel zum Blockieren (412) der Übertragung einer Pfad- oder Reservierungsnachricht über die Funkschnittstelle, in Reaktion darauf, dass die Pfad- oder Reservierungsnachricht zu dem gleichen Fluss gehört wie die erste Pfad- oder Reservierungsnachricht; und – Mittel zum Übertragen (417) einer Nachricht, die der ersten Pfad- oder Reservierungsnachricht entspricht, periodisch an die QoS-Protokoll-Entität der Mobilstation, auf der Basis der gespeicherten Daten.
  12. Supportknoten in einem drahtlosen Telekommunikationssystem, wobei der Supportknoten eingerichtet ist zum Übertragen (405; 408) von Pfadnachrichten und einer Reservierungsnachricht, zwischen einer Mobilstation und einem Datenendgerät, um eine Dienstgüte zu reservieren und aufrechtzuerhalten, dadurch gekennzeichnet, dass der Supportknoten umfasst – Mittel zum Speichern (404; 407) von Daten zumindest über erste empfangene Pfad- und Reservierungsnachrichten; – Mittel zum Vergleichen (301; 305) von nächsten empfangenen Pfad- und Reservierungsnachrichten mit gespeicherten Daten; – Mittel zum Blockieren (416) der Übertragung von empfangenen nächsten Pfad- und Reservierungsnachrichten über die Funkschnittstelle, in Reaktion darauf, dass die empfangenen Nachrichten zu dem gleiche Fluss wie die ersten Pfad- und Reservierungsnachrichten gehören; und – Mittel zum Übertragen (413) einer Nachricht, die der ersten Pfad- oder Reservierungsnachricht entspricht, periodisch an eine QoS-Protokoll-Entität des Daten-Endgeräts, auf der Basis der gespeicherten Daten.
  13. Supportknoten nach Anspruch 12, dadurch gekennzeichnet, dass – der Supportknoten ein GPRS-Gateway-Supportknoten (GGSN) in einem GPRS-Netzwerk ist.
DE60130318T 2000-01-24 2001-01-23 Reservierung von dienstqualitäten in einem drahtlosen telekommunikationssystem Expired - Lifetime DE60130318T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI20000138 2000-01-24
FI20000138A FI20000138A7 (fi) 2000-01-24 2000-01-24 Palvelun laadun varaaminen langattomasa tietoliikennejärjestelmässä
PCT/FI2001/000057 WO2001056319A1 (en) 2000-01-24 2001-01-23 Reserving quality of service in wireless telecommunication system

Publications (2)

Publication Number Publication Date
DE60130318D1 DE60130318D1 (de) 2007-10-18
DE60130318T2 true DE60130318T2 (de) 2008-05-29

Family

ID=8557181

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60130318T Expired - Lifetime DE60130318T2 (de) 2000-01-24 2001-01-23 Reservierung von dienstqualitäten in einem drahtlosen telekommunikationssystem

Country Status (7)

Country Link
US (1) US7170872B2 (de)
EP (1) EP1252789B1 (de)
AT (1) ATE372651T1 (de)
AU (1) AU2001230281A1 (de)
DE (1) DE60130318T2 (de)
FI (1) FI20000138A7 (de)
WO (1) WO2001056319A1 (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1130931A1 (de) * 2000-03-03 2001-09-05 Lucent Technologies Inc. Reservierung von Netzresourcen in einem mobilen Paketdatennetz
US20020150099A1 (en) * 2001-04-13 2002-10-17 Pung Hung Keng Multicast routing method satisfying quality of service constraints, software and devices
US7349433B2 (en) 2001-11-01 2008-03-25 Texas Instruments Incorporated Signaling for parameterized quality of service (QoS) support
US6661780B2 (en) 2001-12-07 2003-12-09 Nokia Corporation Mechanisms for policy based UMTS QoS and IP QoS management in mobile IP networks
AU2002325975A1 (en) * 2002-09-23 2004-04-08 Nokia Corporation Method and system for resource management in a communication network
FR2846841B1 (fr) * 2002-10-31 2005-02-18 Orange France Sa Systeme et procede de gestion d'acces d'un reseau de communication a un terminal mobile
WO2004077783A1 (de) * 2003-02-28 2004-09-10 Siemens Aktiengesellschaft Verfahren zur übertragung von daten in einem wlan-netz
CN1553663B (zh) * 2003-05-26 2010-04-28 华为技术有限公司 减少软状态刷新的资源预留协议实现方法
KR100542580B1 (ko) * 2003-06-26 2006-01-11 삼성전자주식회사 이동망환경에서의 자원예약 시스템 및 자원예약 방법
US7327746B1 (en) * 2003-08-08 2008-02-05 Cisco Technology, Inc. System and method for detecting and directing traffic in a network environment
US7796557B2 (en) * 2004-01-05 2010-09-14 Research In Motion Limited Methods and apparatus for the communication of network capability information over a traffic channel
EP1800440A1 (de) * 2004-10-14 2007-06-27 Telefonaktiebolaget LM Ericsson (publ) Router und verfahren zum auffrischen von dienstqualitätsreservierung
US9942511B2 (en) 2005-10-31 2018-04-10 Invention Science Fund I, Llc Preservation/degradation of video/audio aspects of a data stream
US9191611B2 (en) * 2005-06-02 2015-11-17 Invention Science Fund I, Llc Conditional alteration of a saved image
US8953596B2 (en) * 2006-01-06 2015-02-10 Qualcomm Incorporated Conserving network capacity by releasing QoS resources
KR100819055B1 (ko) * 2006-12-08 2008-04-02 한국전자통신연구원 이동 IPv6 네트워크에서 플로우 기반 QoS 보장을위한 3 계층 핸드오버 경로 설정 방법
US8903393B2 (en) * 2007-06-28 2014-12-02 Qualcomm Incorporated Wireless communication device for maintaining minimum quality of service (QoS) communication sessions during hard handoffs
US8886975B2 (en) * 2010-06-04 2014-11-11 Broadcom Corporation Method and system for managing power consumption utilizing inter-gateway communication
US8688162B1 (en) * 2010-02-22 2014-04-01 Sprint Spectrum L.P. Method and device for reducing latency by anticipating responsive data communications
CN103716881B (zh) * 2012-10-08 2018-08-14 华为技术有限公司 空口信息处理系统、方法及设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101549A (en) * 1996-09-27 2000-08-08 Intel Corporation Proxy-based reservation of network resources
US6058113A (en) 1997-09-30 2000-05-02 Lucent Technologies, Inc. Method for enhancing resource reservation communication
US6201971B1 (en) * 1998-03-26 2001-03-13 Nokia Mobile Phones Ltd. Apparatus, and associated method for controlling service degradation performance of communications in a radio communication system
US6473419B1 (en) * 1998-03-26 2002-10-29 Nokia Corporation State apparatus, and associated methods, for controlling packet data communications in a radio communication system
GB9806912D0 (en) * 1998-03-31 1998-05-27 Madge Networks Ltd A communications network end station
GB2341059A (en) * 1998-08-28 2000-03-01 Nokia Oy Ab Internet protocol flow detection
FR2799326B1 (fr) * 1999-10-04 2001-12-28 France Telecom Protocole de lancement d'une application logicielle a distance et de reservation de ressources reseau avec qualite de service

Also Published As

Publication number Publication date
AU2001230281A1 (en) 2001-08-07
EP1252789A1 (de) 2002-10-30
EP1252789B1 (de) 2007-09-05
FI20000138L (fi) 2001-07-25
FI20000138A7 (fi) 2001-07-25
FI20000138A0 (fi) 2000-01-24
US20030026232A1 (en) 2003-02-06
DE60130318D1 (de) 2007-10-18
ATE372651T1 (de) 2007-09-15
WO2001056319A1 (en) 2001-08-02
US7170872B2 (en) 2007-01-30

Similar Documents

Publication Publication Date Title
DE60130318T2 (de) Reservierung von dienstqualitäten in einem drahtlosen telekommunikationssystem
DE69834188T2 (de) Dynamische dienstqualitätreservierung in einem mobilen kommunikationsnetz
DE60031435T2 (de) Dienstgütebezogene Herstellung einer Kommunikationssitzung in einem Kommunikationssystem
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
DE69806507T2 (de) Ressourcenreservierung in einem mobilen internetprotokoll
DE69935397T2 (de) Verfahren und Vorrichtung zur Echtzeitdatenübertragung in einem Paketfunknetz
DE60112480T2 (de) Dienstqualität (QoS) für ein Universales Mobiltelekommunikationssystem (UMTS) mit Unterstützung einer Verhandlung einer einstellbaren Dienstqualität
DE60218992T2 (de) Verfahren und Vorrichtung zum Datenrundsenden in Netzwerken der dritten Generation
DE69829764T2 (de) Auswahl zwischen paketvermittelte und leitungsvermittelte dienste in einem mobilen kommunikationssystem
DE60317350T2 (de) Datenübertragung über ein gprs-funkkommunikationsnetz
US9319242B2 (en) Handling traffic flows in a mobile communications network
DE60107827T2 (de) Zuteilung von betriebsmitteln beim paketvermittelten datentransfer
EP1152571B1 (de) Bidirektionales Reservierungsprotokoll
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE60037830T2 (de) Dynamische aktualisierung der dienstqualität in einem paketvermittlungsnetz
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE60115030T2 (de) Kommunikationen unter verwendung von adaptiven mehrraten kodierern/dekodierern
DE60024107T2 (de) Zuweisung von funkressourcen eines netzes in einem paketvermittelten datenübertragungssystem
DE602005006095T2 (de) Bereitstellen von Informationen über die Beziehungen individueller Träger für mobile Endgeräte, die einen Multicast- oder Broadcastdienst empfangen
DE60317992T2 (de) Verfahren zum Übertragen von GPRS Datenpaketen aus unterschiedlichen PDP Kontexten gemäss ihrer relativen Priorität
DE69731370T2 (de) Verfahren zur funkverbindungsherstellung im rahmen eines atm-netzwerkes
DE60106457T2 (de) Zuteilung von datenübertragungsbetriebsmitteln bei der paketvermittelten datenübertragung
DE69927405T2 (de) Paketkanal-architektur für zugangsnetze
EP1451980A1 (de) Verfahren zur uebertragung von daten von applikationen mit unterschiedlicher qualität

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: AMOSMET INVESTMENTS LLC, DOVER, DEL., US