DE60114781T2

DE60114781T2 - Zusammenwirkung in einem kommunikationssystem

Info

Publication number: DE60114781T2
Application number: DE60114781T
Authority: DE
Inventors: Marc Greis
Original assignee: Nokia Inc
Current assignee: Nokia Inc
Priority date: 2000-03-06
Filing date: 2001-02-09
Publication date: 2006-08-03
Anticipated expiration: 2021-02-10
Also published as: WO2001067687A3; DE60114781D1; ATE426976T1; DE05076867T1; ATE309659T1; WO2001067687A2; ES2255899T1; PT1601141E; ES2252196T3; AU2001237371A1; GB0005363D0; US20030137960A1; EP1262046B1; ES2255899T3; DE60138144D1; EP1601141A1; EP1601141B1; EP1262046A2

Description

Erfindungsgebiet
Die vorliegende Erfindung bezieht sich auf ein Zusammenarbeiten (Interworking) zwischen verschieden Funktionen eines Telekommunikationssystems.
Hintergrund der Erfindung
Telekommunikationsnetze arbeiten typischerweise in Übereinstimmung mit einem gegebenen Standard oder einer Spezifikation, die festlegt, was die verschiedenen Elemente des Netzes vornehmen dürfen und wie dies erreicht werden sollte. Beispielsweise kann der Standard oder die Spezifikation definieren, ob der Benutzer, oder präziser, die Benutzerausstattung oder das Endgerät mit leitungsvermittelten oder paketvermittelten Diensten ausgestattet ist. Der Standard oder die Spezifikation können auch die Kommunikationsprotokolle und/oder Parameter definieren, die für die Verbindung verwendet werden sollen. Mit anderen Worten definieren Standards und/oder Spezifikationen die „Regeln", auf denen die Kommunikation innerhalb eines Kommunikationssystems basieren kann. Beispiele für verschiedene Standards und/oder Spezifikationen enthalten, ohne darauf beschränkt zu sein, Spezifikationen wie beispielsweise GSM (Global System for Mobil communications) oder verschiedene auf GSM basierende Systeme (wie beispielsweise GPRS: General Packet Radio Service), AMPS (American Mobile Phone System), DAMPS (Digital AMPS), WCDMA (Wideband Code Division Multiple Access) oder TD/CDMA in UMTS (Time Division/Code Division Multiple Access in Universal Mobile Telecommunications System), IMT 2000 usw.
In einem zellularen Kommunikationssystem bedient eine Basisstation Mobilstationen oder eine ähnliche Endgerätevorrichtung (Mobilstation MS in dem GSM, Benutzerausstattung (User Equipment) UE in dem UMTS) über eine drahtlose Schnittstelle. Jede der Zellen des zellularen Systems kann durch eine geeignete Sendeverstärkervorrichtung bedient werden. In dem WCDMA-Funkzugangsnetz wird die Zelle beispielsweise durch einen Node B bedient, der verbunden ist mit und gesteuert wird durch ein Element, das als ein Funknetzcontroller (Radio Network Controller, RNC)-Knotenpunkt bezeichnet wird. In dem GSM-Funknetz wird die Zelle durch eine Basisstation (BTS) bedient, die verbunden ist mit und gesteuert wird durch einen Basisstationssteuerungs-(Base Station Controller, BSC)-Knoten. Das BSC/RNC-Element kann verbunden sein mit und gesteuert werden durch eine Mobilvermittlungszentrale (Mobile Switching Center, MSC) oder eine ähnliche Einrichtung. Das BSC/RNC kann auch verbunden sein mit und gesteuert werden durch einen Bedienungs-GPRS-Unterstützungsknoten (Serving GPRS support node, SGSN). Die MSCs eines Netzes sind typischerweise miteinander verbunden und es können einer oder mehrere Gateway MSC (GMSC) vorhanden sein zum Verbinden des zellularen Netzes mit anderen Telekommunikationsnetzen. Der SGSN kann mit einem Gateway-GPRS-Unterstützungsknoten (Gateway GPRS Support Node, GGSN) verbunden sein zum Verbinden des mobilen Netzes mit dem Internet und anderen Paketvermittlungsnetzen.
Obwohl die Mobilstation über lediglich einen Controller und/oder Gatewayknoten zum selben Zeitpunkt in Kommunikation stehen kann, kann sie auch über mehrere verschiedene Knoten kommunizieren. Die Knoten, mit denen die Mobilstation verbunden ist, können auch konfiguriert und betrieben werden basierend auf verschiedenen Standards und/oder Spezifikationen. Die Unterschiede in den Standards und/oder Spezifikationen können Schwierigkeiten hinsichtlich des Zusammenarbeitens der verschiedenen Elemente der verschiedenen Netzsysteme hervorrufen. Im Folgenden wird ein Beispiel des möglichen Inkompatibilitätsproblems in dem Kontext einer Servicequalität-(Quality of Service, QoS)-Signalisierung zwischen den verschiedenen Elementen und Protokollen eines Kommunikationssystems mit einem oder mehreren paketvermittelten UMTS/GPRS-Netzen beschrieben.
Der General Packet Radio Service GPRS bezieht sich auf den Transfer von Daten zu und von Mobilstationen. Typischerweise wird der GPRS-Standard in Verbindung mit dem Standard des Global System for Mobile communications GSM bereitgestellt. Der GSM-Standard ist ein leitungsvermittelter Dienst und ist ursprünglich ausgestaltet für Sprachdienste. Es gibt Elemente des GSM-Standards und des GPRS-Standards, die gemeinsam sind. Die GPRS-Netze sind zum Beispiel in 3GPP Technical Specification 3G TS 23.060 Version 3.2.0, "General Packet Radio Services (GPRS); Service description; Stage 2", Januar 2000 näher erläutert. Dieses Dokument wird hier als Bezug aufgenommen. Eine Anpassung des GPRS-Standards wird ebenfalls gerade vorgeschlagen zur Verwendung mit dem Standard der dritten Generation UMTS, bei dem typischerweise ein Codemultiplexzugang verwendet wird. Der Paketdatenteil des UMTS ist in der vorgenannten 23.060-Spezifikation enthalten, d.h. 23.060 ist für paketvermittelte Daten sowohl für das UMTS als auch den GPRS anwendbar.
Zur Verhandlung eines End-zu-End-QoS zwischen Endgeräten in UMTS/GPRS-Netzen und Endgeräten in anderen Datennetzen, wie beispielsweise IP-(Internet Protocol)-oder X.25-basierte Netze, ein herkömmliches festes IP-Netz, oder ein anderes UMTS/GPRS-Netz kann ein Protokoll wie beispielsweise Resource Reservation Protocol RSVP verwendet werden. Ein Beispiel für die Verwendung des RSVP in einem IP-Netz wird durch das RFC 2746 von A. Terzis u.a. bereitgestellt, in dem IPv4-Pakete in IPv6-Tunneln gesendet werden.
Allerdings hat der Erfinder herausgefunden, dass in dem aktuellen Zusammenarbeiten zwischen der RSVP-QoS-Signalisierung und den UMTS/GPRS-QoS-Mechanismen (d.h. sogenannte PDP-Kontextaktivierung) die RSVP-Nachrichten nicht genügend QoS-Information befördern, um den vollen Satz der UMTS/GPRS-QoS-Parameter von diesen Nachrichten zu bestimmen. Im Einzelnen befördert die RSVP-PATH-Nachricht QoS-Information in einem „SEN-DER_TSPEC"-Objekt. Das „SENDER_TSPEC"-Objekt enthält lediglich die nachfolgen QoS-Parameter: ''Token Bucket Rate', 'Token Bucket Size', 'Peak Date Rate', 'Minimum Policed Unit', 'Maximum Packet Size''. Dieses UMTS/GPRS-QoS und dessen Parameter sind definiert beispielsweise in 3GPP Technical Specification 3G TS 23.107 Version 3.1.0, "QoS Concept and Architecture", Oktober 1999. Eine nähere Beschreibung der RSVP-PATH-Nachricht kann gefunden werden beispielsweise im Dokument von Braden, R., u.a., „Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification", IETF RFC 2205, September 1997. Das "SENDER_TSPEC"-Objekt ist definiert beispielsweise durch Wroclawski, J. im Dokument „The Use of RSVP with IETF Intigrated Services", IETF RFC 2210, September 1997. Diese drei Dokumente werden hier als Bezug aufgenommen.
Einem Netzelement innerhalb eines UMTS-Netzes ist es nicht möglich, wesentliche UMTS-QoS-Parameter wie „Traffic Class" und „Transfer Delay" ausschließlich anhand der in diesem SENDER_TSPEC-Objekt enthaltenen QoS-Parameter zu bestimmen.
Die RSVP-RESV-Nachricht kann ein zusätzliches „RSPEC" (innerhalb eines „FLOWSPEC"-Objekts) mit einer Rate und einem Schlupfausdruck (Slack Term) befördern, die verwendet werden können zum Ableiten des Parameters „Transfer Delay". Die Zuordnung kann allerdings problematisch sein, da das RSPEC (wie alle anderen RSVP-QoS-Parameter) zur Verwendung für End-zu-End-QoS gedacht ist, während der Parameter UMTS Transfer Delay lediglich die Verzögerung innerhalb des UMTS-Netzes definiert. Darüber hinaus ist der RSPEC auf eine Warteschlangenverzögerung anwendbar, während QoS in dem UMTS/GPRS eine Transferverzögerung spezifiziert.
Die UMTS/QoS-Parameter und die RSVP-QoS-Parameter, wie sie in einem FLOWSPEC-Objekt enthalten sind, und eine mögliche Zuordnung zwischen diesen Parametern ist in der Tabelle 1 gezeigt. Diese Tabelle zeigt die UMTS-spezifischen QoS-Parameter die nicht von den RSVP-QoS-Parametern abgeleiten werden können.
Tabelle 1: UMTS- und RSVP-QoS-Parameter
Es ist auch anzumerken, dass es lediglich drei RSVP/IntServ-Serviceklassen (Best Effort, Controlled Load, Guaranteed Service) gibt, aber vier UMTS-Serviceklassen (Conversational, Streaming, Interactive, Background), wodurch die Zuordnung zwischen diesen beiden Parametern weiter verkompliziert wird.
Zusammenfassung der Erfindung
Es ist ein Ziel der Ausführungsbeispiele der vorliegenden Erfindung, eines oder mehrere der vorgenannten Probleme zu behandeln.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren in einem Kommunikationssystem mit einem ersten Untersystem und einem zweiten Untersystem bereitgestellt, wobei das Verfahren umfasst:
Generieren einer Steuerungsnachricht, welche von zumindest einem Element des ersten Untersystems und zumindest einem Element des zweiten Untersystems interpretiert werden kann; Hinzufügen eines für die Elemente des zweiten Untersystems transparente Steuerungsinformationen enthaltenden Objekts zu der Steuerungsnachricht; Übertragen der Steuerungsnachricht über das erste und zweite Untersystem; und Steuern der Operation zumindest eines der Elemente des ersten Untersystems basierend auf der in dem Objekt enthaltenen Steuerungsinformation.
Das erste Untersystem kann ein Paketvermittlungsnetz aufweisen, das drahtlose Dienste für dessen Nutzer bereitstellt. Das zweite Untersystem kann auch ein Datennetz aufweisen, das auf einen Paketvermittlungskommunikationsprotokoll basiert, das von dem durch das erste Untersystem verwendeten Kommunikationsprotokoll abweicht. Die Nachricht kann zu einem dritten Untersystem weitergesendet werden, da es zumindest ein Element aufweist, das ein Interpretieren der durch das Objekt beförderten Information ermöglicht. Das dritte Untersystem kann auf im Wesentlichen gleichen operationalen Prinzipien wie das erste Untersystem basieren.
Das Kommunikationssystem kann zumindest ein erstes Endgerät und ein zweites Endgerät aufweisen, wobei das erste Endgerät zu dem ersten Untersystem gehört, und wobei eine Verbindung zwischen den beiden Endgeräten basierend auf einem Servicequalitätsmechanismus für Paketdaten verhandelt wird. Die Steuerungsnachricht kann eine Ressourcenreservierungsprotokollnachricht aufweisen. Das Objekt kann zumindest einen Servicequalitätsparameter enthalten, der von dem ersten Untersystem für Verbindungsaufbauzwecke gefordert wird.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Kommunikationssystem bereitgestellt, mit: einem ersten Untersystem mit einer ersten Vielzahl von Elementen zum Übertragen von Nachrichten; einem zweiten Untersystem mit einer zweiten Vielzahl von Elementen zur Übertragung von Nachrichten; einer Steuereinrichtung zum Generieren einer Steuerungsnachricht, welche von zumindest einem Element des ersten Untersystems und zumindest einem Element des zweiten Untersystems interpretiert werden kann; und einer Steuereinrichtung zum Hinzufügen eines Objekts zu der Steuerungsnachricht, weiches für die Elemente des zweiten Untersystem transparente Steuerungsinformation enthält, wobei die Anordnung so ist, dass eine Operation zumindest eines der Elemente des ersten Untersystems basierend auf der in dem Objekt enthaltenen Steuerungsinformation gesteuert wird, während die Elemente des zweiten Untersystems nicht durch die in dem Objekt enthaltene Steuerungsinformation beeinflusst werden.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird eine Nutzerausstattung für ein System bereitgestellt, welches eine drahtlose Paketvermittlungskommunikation zwischen einem ersten und einem zweiten Paketvermittlungsnetz bereitstellt, wobei die Nutzerausstattung aufweist: eine Steuerung zum Generieren einer von dem ersten Netz an das zweite Netz zu signalisierenden Steuerungsnachricht, wobei die Steuerungsnachricht von Elementen einer ersten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes lesbar ist, und eine Steuerung zum Hinzufügen eines Steuerinformation enthaltenden Objekts zu der Steuerungsnachricht, wobei die Nachricht nur für Elemente einer zweiten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes lesbar ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird eine Steuerungsnachricht in einem Kommunikationssystem bereitgestellt, das drahtlose Paketdaten-Kommunikation zwischen ersten und zweiten Netzen bereitgestellt, wobei die Steuerungsnachricht aufweist: einen von Elementen einer ersten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes interpretierbaren Anteil; und ein Steuerungsinformation enthaltendes Objekt, wobei das Objekt nur von Elementen einer zweiten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes lesbar ist.
Die Ausführungsbeispiele der Erfindung können das Zusammenarbeiten zwischen den verschiedenen Funktionen, wie beispielsweise Protokolle und Mechanismen, verbessern. Beispielsweise kann das Zusammenwirken des Ressourcenreservierungsprotokolls (Resource Reservation Protocol) RSVP und Paketdaten-QoS-Mechanismen eines paketvermittelten Dienstes wie beispielsweise das Universal Mobile Telecommunications System (UMTS) oder der General Packet Radio Service (GPRS) verbessert werden. In einem spezielleren Ausführungsbeispiel kann das Zusammenarbeiten zwischen zwei UMTS/GPRS-Netzen verbessert werden, da es eine Möglichkeit für eine End-zu-End-Signalisierung zwischen UMTS-Netzen basierend auf RSVP-Nachrichten bereitstellt.
Kurzbeschreibung der Zeichnungen
Zum besseren Verständnis der vorliegenden Erfindung wird im Folgenden beispielhaft auf die beigefügten Zeichnungen Bezug genommen, wobei:
1 ein Kommunikationssystem zeigt, in dem die Ausführungsbeispiele der vorliegenden Erfindung verwendet werden können; und
2 ein Flussdiagramm zeigt, das die Funktionsweise eines Ausführungsbeispiels der vorliegenden Erfindung veranschaulicht.
Beschreibung bevorzugter Ausführungsbeispiele der Erfindung
Es wird Bezug genommen auf 1, die ein Kommunikationssystem zeigt, in dem die Ausführungsbeispiele der vorliegenden Erfindung eingesetzt werden können. Der durch das Kommunikationssystem abgedeckte Bereich ist aufgeteilt in eine Vielzahl von Zellen (nicht gezeigt). Jeder Zelle ist eine Basisstation 6 zugeordnet. In Abhängigkeit des von dem Netz verwendeten Standards wird die Basisstation manchmal als Node 8 bezeichnet, beispielsweise in den Standards der dritten Generation. Der Begriff Basisstation wird in diesem Dokument verwendet zum Erfassen aller Elemente, die über die Luftschnittstelle zu Mobilstationen 1 oder dergleichen übertragen. Die Mobilstationen 1 oder eine andere Nutzerausstattung ist zur Kommunikation mit der jeweiligen Basisstation ausgestaltet. Die Mobilstation 1 kann einer Endgeräteausstattung 11 zugeordnet sein, wie später erläutert werden wird.
Das Ausführungsbeispiel der Erfindung wird in dem Kontext eines UMTS (Universal Mobile Telecommunications System) und eines GPRS (General Packet radio Service) und Paketdaten involvierenden Kommunikationen beschrieben. Es sollte jedoch ersichtlich sein, dass Ausführungsbeispiele der vorliegenden Erfindung bei jedem anderen Kommunikationssystem anwendbar sind, das mit Paketdaten, Nicht-Paketdaten oder sogar Sprachkommunikation oder dergleichen arbeitet, wie beispielsweise das IMT 2000, Wireless LAN oder andere Zugangsnetze.
Die Elemente eines UMTS-Netzes TM2 werden nun näher diskutiert. Die Mobilstation oder Nutzerausstattung 1 ist ausgestaltet zum Kommunizieren mit einer jeweiligen Basisstation 6 über die Luftschnittstelle. Die Basisstation wird durch einen Funknetzcontroller (Radio Network Controller) RNC 7 gesteuert. Der Funknetzcontroller RNC und die Basisstation können manchmal als das Funknetzsubsystem (Radio Network Subsystem) RNS 8 oder Funkzugangsnetz (radio access network) RAN bezeichnet werden. Es sollte ersichtlich sein, dass ein UMTS-Netz typischerweise mit mehr als einem RNC ausgestattet ist, und dass jeder Funknetzcontroller im Allgemeinen ausgestaltet ist zum Steuern von mehr als einer Basisstation 6, obwohl lediglich eine Basisstation in 1 gezeigt ist. Die Elemente des RNS können in jedem oder beiden des RNC und der Basisstation enthalten sein. Dies ist ein Implementierungsaspekt.
Das Funknetzsubsystem 8 kann mit einem SGSN (Serving GPRS Support Node) 14 verbunden sein. Der SGSN 14 behält die Position der Mobilstation im Auge und führt Sicherheitsfunktionen und Zugangskontrolle durch. Die Funktionen des SGSN sind beispielsweise definiert in der 3GPP-Spezifikation 33.060. Der SGSN 14 ist mit einem GGSN (Gateway GPRS Support Node) 16 verbunden. Der GGSN 16 stellt eine Zusammenarbeit mit externen paketvermittelten Netzen bereit, d.h. der GGSN wirkt als Gateway zwischen dem UMTS-Datennetz 2 und einem externen Netz 3, wie beispielsweise ein IP-basiertes Datennetz. Die Funktionen eines typischen GGSN sind ebenfalls in der 3GPP-Spezifikation definiert.
1 zeigt des weiteren ein zweites UMTS-Netz 4. Das zweite UMTS-Netz kann eine im Wesentlichen ähnliche Ausgestaltung wie das erste UMTS-Netz 2 aufweisen.
Obwohl nicht gezeigt, kann das Netzsystem 2 auch mit herkömmlichen Telekommunikationsnetzen, wie beispielsweise einem GSM-basierten zellularen Mobilfunknetz (Public Land Mobile Network, PLMN) oder einem Festnetz (Public Switched Telephone Network, PSTN), verbunden sein. Die verschiedenen Netze können miteinander oder über geeignete Schnittstellen und/oder Gateways verbunden sein.
Im Folgenden wird ein Ausführungsbeispiel zum Verbessern der Zusammenarbeit zwischen dem Resource Reservation Protocol (RSVP) und Paketdaten-QoS- Mechanismen des Universal Mobile Telecommunication System UMTS und/oder des General Packet Radio Service GPRS beschrieben. Die Anwendung des RSVP zum Befördern von UMTS-QoS-Parametern durch Definieren eines neuen RSVP-Objekts, das von UMTS-Netzelementen interpretiert werden kann, während das Objekt transparent durch andere Netze oder Verbindungen zwischen zwei UMTS-Netzen befördert wird, so dass das Element des anderen Netzes oder der anderen Verbindung dieses zusätzliche Objekt der RSVP-Nachricht nicht bemerkt. Die beschriebenen Ausführungsbeispiele können sowohl für UMTS-Netze als auch für GPRS-Netze und beliebige Hybride davon angewendet werden.
Ein Merkmal des RSVP-Protokolls ist, dass es modular ist. Eine RSVP-Nachricht besteht aus einer vordefinierten Gruppe von Objekten, wobei der Objekttyp durch das Class-Num-Oktett in dem Header eines jeden Objekts angegeben wird. Falls ein RSVP-Prozess in einem Netzelement auf ein unbekanntes Objekt trifft, während er eine RSVP-Nachricht bearbeitet, gibt es alternative Möglichkeiten hinsichtlich der Art und Weise der Bearbeitung dieses Objekts und der gesamten Nachricht basierend auf den beiden hochwertigen Bits in dem Class-Num-Oktett des Objekts. Zum Beispiel wenn:

– Class-Num = 0bbbbbbb
– Die gesamte dieses Objekt enthaltende Nachricht wird zurückgewiesen und eine Fehlernachricht erzeugt;
– Class-Num = 10bbbbbb
– Das Netzelement ignoriert das Objekt und leitet es nicht weiter und keine Fehlernachricht wird erzeugt;
– Class-Num = 11bbbbbb
– Das Netzelement ignoriert das Objekt, leitet das Objekt aber in allen aus der verarbeiteten Nachricht resultierenden Nachrichten weiter.

Die letztgenannte Alternative kann somit für die Erweiterung des RSVP-Protokolls mit netzspezifischen Objekten verwendet werden. Im Prinzip ist es möglich, jede beliebige Information in diesen Objekten hinzuzufügen. Es ist somit möglich, Objekte zu haben, die lediglich beispielsweise für das GGSN eines Netzes anwendbar sind, und/oder Objekte, die lediglich beispielsweise für die Mobilstation MS anwendbar sind. Die hinzugefügten Objekte können transparent durch andere Netze und/oder Elemente, die auf anderen Standards, Spezifikationen oder Einstellungen basieren, befördert werden. D.h., das Weiterleiten der RSVP-Nachrichten wird in keiner Weise durch ein solches hinzugefügtes Objekt in Netzen beeinflusst, die es nicht interpretieren können. Alle diese Netzelemente oder Knoten, die das Objekt nicht interpretieren können, werden weiterhin in der Lage sein, den Rest der RSVP-Nachricht zu interpretieren.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird ein zuvor undefiniertes RSVP-Objekt (im Folgenden als „UMTS-QoS-Objekt" bezeichnet) mit einem Class-Num-Oktett, das mit der Maske „11 bbbbbb" übereinstimmt, zum Befördern einer UMTS-QoS-(Quality of Service)-Information angepasst. Das RSVP-Objekt kann alle UMTS-QoS-Parameter befördern, die beispielsweise in der vorgenannten technischen 3GPP-Spezifikation „QoS-Concept and Architecture" definiert sind. Das RSVP-Objekt kann auch lediglich eine Untergruppe dieser Parameter befördern. Das RSVP-Objekt kann auch QoS-Information befördern, die derzeit nicht in den RSVP-QoS-Parametern enthalten ist und die zur Bestimmung aller UMTS-QoS-Parameter oder einer Untergruppe dieser Parameter benutzt werden kann.
Die UMTS-QoS-Information kann durch die Netzelemente innerhalb des UMTS-Netzes 2 verwendet werden (die Elemente enthalten die Mobilstation 1 und auch eine angebrachte Endgeräteausstattung), um die insbesondere in den PATH-Nachrichten enthaltene Information zu erweitern. Die UMTS-QoS-Information kann auch in anderen RSVP-Nachrichten verwendet werden, um zusätzliche QoS-Information für das UMTS-Netz 2 bereitzustellen. Die zusätzliche Information ist in herkömmlichen RSVP-Nachrichten nicht enthalten. Das Netzelement kann ausgestaltet sein zum Verwenden der in dem UMTS-QoS-Objekt enthaltenen Information zur Vermeidung von Übereinstimmungsinkonsistenzen zwischen den RSVP-QoS-Parametern und den UMTS-QoS-Parametern. Die UMTS-QoS-Information kann auch verwendet werden zum Ermöglichen des Transfers einer UMTS-QoS-Information zwischen zwei abgesetzten Endpunkten oder zwei UMTS-Netzen innerhalb RSVP-Nachrichten.
Die Verwendung von UMTS-QoS-Information erfordert, dass Netzelemente innerhalb des UMTS-Netzes 2 vorhanden sind, die diese Information erzeugen können, und dass Elemente innerhalb des UMTS-Netzes 2, des empfangenden UMTS-Netzes oder eines anderen Datennetzes vorhanden sind, die diese Information verarbeiten und verwenden können, wie oben beschrieben.
Gemäß einem alternativen Ausführungsbeispiel, kann ein Class-Num-Oktett verwendet werden, das mit der vorstehend beschriebenen zweiten möglichen Maske „10bbbbbb" übereinstimmt, um mögliche Störungen mit proprietären Lösungen in anderen Zugangsnetzen zu vermeiden. D.h., das Objekt wird nicht von dem die Nachricht und das Objekt interpretierenden Element weitergeleitet und somit kann das Objekt keine Störung verursachen. Das Störungsproblem kann jedoch auch durch Standardisieren des Class-Num für das UMTS-QoS-Objekt innerhalb der geeigneten Instanzen vermieden werden.
Das zusätzliche Objekt innerhalb der RSVP-Nachricht kann intern innerhalb eines UMTS-Netzes interpretiert werden, nicht aber in einer End-zu-End-QoS-Verhandlung (zum Beispiel könnte es durch den GGSN 16 oder ein beliebiges anderes geeignetes Element von der abgehenden RSVP-Nachricht abgetrennt werden). Das Objekt kann auch verwendet werden in der End-zu-End-QoS-Verhandlung zwischen zwei UMTS-Netzen, so dass ein Endgerät in einem UMTS-Netz über die exakten UMTS-QoS-Anforderungen eines Endgeräts in einem anderen UMTS-Netz informiert werden kann.
Das erste Netzelement (inklusive der Endgeräteausstattung 11 und/oder der Mobilstation 1) in dem UMTS-Netz 2, das eine RSVP-Nachricht verarbeitet und einen Abgleich zwischen RSVP- und UMTS-QoS-Parametern durchführen kann, wird vorzugsweise für das Abgleichen und Hinzufügen eines UMTS-QoS-Objekts zu der weitergeleiteten RSVP-Nachricht, die die resultierenden Parameter enthält, verwendet. Dieses Objekt kann auch durch die das QoS-anfordernde Anwendung hinzugefügt werden. Eine Möglichkeit bietet das Hinzufügen des Objekts durch Treiber oder Serviceprogramme (Utilitiies) innerhalb der Endgeräteausstattung 11. Der Benutzer kann die Endgeräteausstattung 11 beispielsweise mittels der Benutzerschnittstelle (typischerweise Tastatur) der Mobilstation 1 steuern.
Das UMTS-QoS-Objekt könnte in einer in der mit der Mobilstation 1 integrierten oder an dieser angebrachten Endgeräteausstattung 11 laufenden Anwendung zur einer RSVP-Nachricht hinzugefügt werden. Die Anwendung bemerkt sowohl RSVP als auch das UMTS-Zugangsnetz 8. Mit anderen Worten kann die Anwendung eine RSVP-Nachricht signalisieren, erkennt die Tatsache, dass die UE an ein UMTS-Netz angeschlossen ist, und kennt das UMTS-QoS (d.h. kann das UMTS-QoS-Objekt zu der RSVP-Nachricht hinzufügen). Das Hinzufügen des Objekts kann auch in Treibern oder anderen Serviceprogrammanwendungen, die in der Endgeräteausstattung laufen, vorgenommen werden. Es kann auch eine RSVP-bewusste Mobilstation verwendet werden. Wenn das Objekt an der Benutzerausstattung oder einer beliebigen anderen durch den Benutzer steuerbaren Einheit hinzugefügt wird, erhält der Benutzer eine direkte Kontrolle über die zu dem Netz übertragen UMTS-QoS-Parameter. Dies kann einen Vorteil darstellen, da der Benutzer typischerweise das Beste oder Erste-Hand-Wissen über die Art des zu übertragenden Verkehrs besitzt (beispielsweise Videodaten oder Sprachdaten).
Die UMTS-QoS-Parameter können auch in einer Abgleichprozedur aus den RSVP-QoS-Parametern mittels eines Netzelements des UMTS-Neztes 2 bestimmt werden. Das Netzelement kann nicht unter der direkten Kontrolle des Benutzers stehen. Beispielsweise kann ein UMTS-QoS-Objekt auch durch den GGSN 16 zu einer RSVP-Nachricht hinzugefügt werden, beim Empfang einer RSVP-Nachricht. Dies ermöglicht die Signalisierung von UMTS-QoS-Anforderungen an entfernte Endpunkte. Es ermöglicht auch eine Signalisierung durch ein separates Netzelement innerhalb des UMTS-Netzes, das für die QoS-Verhandlung zuständig ist (zum Beispiel Bandbreitenmakler (Bandwidth Broker), usw.).
Es sollte ersichtlich sein, dass das UMTS-QoS-Objekt auch an einigen anderen Orten zu den RSVP-Nachrichten hinzugefügt werden könnte und dass die obigen Beispiele diese nicht enthalten.
Die Endgeräteausstattung kann ein externes Gerät wie beispielsweise ein Laptop-Computer sein, der an der Mobilstation 1 angebracht ist.
Das UMTS-QoS-Objekt kann abhängig von der Anwendung in mehreren Elementen des Kommunikationssystems interpretiert werden. Es sollte ersichtlich sein, dass die nachfolgende Liste der möglichen Netzelemente als nicht vollständig beabsichtigt ist.
Die Interpretation kann in einer RSVP-bewussten Mobilstation 5 vorgenommen werden, die eine RSVP-Nachricht von einer angebrachten Endgeräteausstattung empfängt, um eine PDP-Kontextaktivierungsprozedur mit den in der RSVP-Nachricht enthaltenen QoS-Parametern einzuleiten. Die Interpretation kann auch in einer RSVP-bewussten Mobilstation 5 vorgenommen werden, die eine RSVP-Nachricht von einem abgesetzten Endgerät empfängt, das entweder in einem UMTS-Netz implementiert ist oder das ein UMTS-QoS-Objekt zu einer RSVP-Nachricht hinzufügen kann, um eine PDP-Kontextaktivierungsprozedur mit den in der RSVP-Nachricht enthaltenen QoS-Parametern einzuleiten.
Ein möglicher Knoten für die Interpretation ist ein GGSN-Knoten, der ankommende oder abgehenden RSVP-Nachrichten empfängt und der möglicherweise PDP-Kontextaktivierungsprozeduren basierend auf diesen Nachrichten einleiten, Zugangskontrolle durchführen, oder RSVP-QoS-Parameter mit UMTS-QoS-Parametern abgleichen muss.
In den Ausführungsbeispielen kann das RSVP oder ein beliebiges ähnliches Protokoll, das darin eine Möglichkeit bereitstellt zum Hinzufügen einer oder mehrerer Objekte, zum Befördern von UMTS-QoS-Parametern oder einem oder mehrerer anderer von dem Netz geförderter Parameter eingesetzt werden, durch Definieren eines neuen Objekts in der Nachricht. Das hinzugefügte Objekt kann von den Elementen des speziellen Netzes interpretiert werden, für das die einen oder mehreren Parameter beabsichtigt sind, während das Objekt in transparenter Weise durch Netze befördert werden kann, die Ihre Operation nicht auf dem einen oder mehreren Parametern basieren. Das Objekt kann zu der Nachricht so hinzugefügt werden, dass die anderen Netze nicht einmal von diesem zusätzlichen Teil der Nachricht Kenntnis nehmen.
Das Hinzufügen eines UMTS-QoS-Objekts zu RSVP-Nachrichten ermöglicht Anmeldungen, Treibern oder nutzergesteuerten Serviceprogrammanwendungen, die sowohl RSVP als auch UMTS-QoS zur Kenntnis nehmen, volle Kontrolle über das UMTS-QoS zu übernehmen, anstatt des Abgleichen zwischen RSVP-QoS-Parametern und UMTS-QoS-Parametern anderen Netzelementen zu überlassen.
Die durch die RSVP-Nachrichten signalisierten QoS-Anforderungen können aufgeteilt werden in QoS-Anforderungen für das Zugangsnetz (enthalten in dem UMTS-QoS-Objekt) und End-zu-End-QoS-Anforderungen (enthalten in den Objekten SENDER_TSPEC und FLOWSPEC).
RSVP-Nachrichten, die das UMTS-QoS-Objekt enthalten, können transparent durch ein oder mehrere externe Datennetze, wie beispielsweise TCP/IP-Internet und/oder X.25-Netze, transferiert werden, unabhängig davon ob diese Netze die RSVP-Modifikation erkennen oder nicht. RSVP-Nachrichten, die das UMTS-QoS-Objekt enthalten, werden weder gelöscht noch verursachen sie Fehlernachrichten in Netzknoten, die dieses Objekt nicht interpretieren können. Dies ermöglicht die Signalisierung von QoS-Anforderungen zwischen Endgeräten in zwei UMTS-Netzen.
Das hinzugefügte Objekt kann als optionales Merkmal implementiert sein. Falls eine Kommunikationsanwendung dieses Objekt nicht erzeugen kann, kann es beispielsweise durch ein RSVP-bewusstes MT oder durch den GGSN erzeugt werden. Dies ermöglicht eine hohe Flexibilität (zum Beispiel mag der Betreiber Netzelemente so konfigurieren zu wollen, dass das Objekt ignoriert oder übergangen wird) und sogar proprietäre Implementierungen ohne Verursachung von Zusammenarbeitsproblemen mit „traditionellem" RSVP.
Gemäß einem weiteren Ausführungsbeispiel wird die RSVP-Nachricht zur Signalisierung der Servicequalität-QoS-Kommunikation zwischen zwei Datennetzen verwendet, die drahtlose Dienste für deren Nutzer bereitstellen. Die erforderliche QoS-Information wird in dem Objekt übertragen, und keine weitere QoS-Signalisierung ist erforderlich.
Es sollte ersichtlich sein, dass Ausführungsbeispiele der vorliegenden Erfindung in jedem anderen geeigneten Typ von Netzen und Protokollen einsetzbar sind, während Ausführungsbeispiele der vorliegenden Erfindung in Bezug auf UMTS- und GPRS-Netze und RSVP-Nachrichten beschrieben worden sind.
In einem Ausführungsbeispiel wird die Kommunikation zwischen zwei Datennetzen nicht über ein zwischen den zwei Netzen angeordnetes drittes Netz übertragen, sondern das Subsystem zwischen den zwei Netzen weist eine geeignete Verbindung oder Gateway auf. Diese Art von Ausführungsbeispiel wird beispielsweise bereitgestellt, wenn das IP-Netz 3 der 1 ersetzt wird durch eine geeignete Verbindung zwischen den UMTS-Netzen 2 und 4. Es ist auch eine Anordnung möglich, bei der die Elemente der Verbindung zwischen den zwei Datennetzen die Nachricht nicht interpretieren können. Entsprechend kann die Anordnung so gestaltet sein, dass Elemente eines Netzes zwischen den zwei Datennetzen nicht mit Mitteln zum Interpretieren eines Teils der Nachricht ausgestattet sind. Gemäß einem weiteren Ausführungsbeispiel sind die Elemente eines Datennetzes in zumindest zwei Untergruppen aufgeteilt, sodass die erste Gruppe ein für die zweite Untergruppe transparentes Objekt interpretieren kann.
Die Daten sind als in Paketform beschrieben. In alternativen Ausführungsbeispielen der Erfindung können die Daten in einem beliebigen geeigneten Format gesendet werden.
Es wird hier ebenfalls angemerkt, dass mehrere Variationen und Modifikationen, die an der offenbarten Lösung ohne Verlassen des in den beigefügten Patentansprüchen definierten Umfangs der vorliegenden Erfindung vorgenommen werden können, vorhanden sind, während das Obige beispielhafte Ausführungsbeispiele der Erfindung beschreibt.

Claims

Verfahren in einem Kommunikationssystem, welches ein erstes Untersystem und ein zweites Untersystem enthält, wobei das Verfahren aufweist: Generieren einer Steuerungsnachricht, welche von zumindest einem Element des ersten Untersystems und zumindest einem Element des zweiten Untersystems interpretiert werden kann; Hinzufügen eines für die Elemente des zweiten Untersystems transparente Steuerungsinformationen enthaltenden Objektes zu der Steuerungsnachricht; Übertragen der Steuerungsnachricht über das erste und zweite Untersystem; Steuern der Operation zumindest eines der Elemente des ersten Untersystems basierend auf der in dem Objekt enthaltenen Steuerungsinformation, wobei das zweite Untersystem ein Datennetz aufweist, welches auf einem Paketvermittlungskommunikationsprotokoll basiert, welches sich von dem im ersten Untersystem verwendeten Kommunikationsprotokoll unterscheidet.
Verfahren nach Anspruch 1, wobei das erste Untersystem ein dessen Nutzern drahtlose Dienste bereitstellendes Paketvermittiungsnetz aufweist.
Verfahren nach Anspruch 1 oder 2, wobei das erste Untersystem auf einem universellen Mobiltelefonsystem und/oder auf allgemeinen Paketfunkdiensten basiert.
Verfahren nach einem der vorangehenden Ansprüche, wobei das zweite Untersystem ein auf dem Internetprotokoll basierendes Datennetz ist.
Verfahren nach einem der vorangehenden Ansprüche, wobei die Nachricht weiter an ein drittes Untersystem übertragen wird, welches zumindest ein Element aufweist, das die von dem Objekt geführte Information interpretieren kann.
Verfahren nach Anspruch 5, wobei das dritte Untersystem auf zu dem ersten Untersystem im Wesentlichen ähnlichen operationalen Grundsätzen basiert.
Verfahren nach Anspruch 5, wobei das Objekt in einem Element des dritten Untersystems interpretiert wird.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Kommunikationssystem zumindest ein erstes Endgerät und ein zweites Endgerät aufweist, wobei das erste Endgerät dem ersten Untersystem angehört und wobei eine Verbindung zwischen den beiden Endgeräten basierend auf einem Dienstqualitätsmechanismus für Paketdaten verhandelt wird.
Verfahren nach Anspruch 8, wobei das zweite Endgerät einem dritten Untersystem angehört.
Verfahren nach einem der vorangehenden Ansprüche, wobei die Steuerungsnachricht eine Ressourcenreservierungsprotokollnachricht aufweist.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Objekt zumindest einen von dem ersten Untersystem zu Verbindungsaufbauzwecken benötigten Dienstqualitätsparameter enthält.
Verfahren nach Anspruch 11, wobei das Objekt alle für den Verbindungsaufbau benötigten Parameter führt.
Verfahren nach Anspruch 12, wobei das Objekt eine Untergruppe der für den Verbindungsaufbau benötigten Parameter führt.
Verfahren nach einem der Ansprüche 1 bis 10, wobei Dienstqualitätsinformation basierend auf von dem Objekt übertragener Information bestimmt wird.
Verfahren nach einem der vorangehenden Ansprüche, wobei zusätzliche Dienstqualitätsinformation basierend auf von dem Objekt übertragener Information bestimmt wird und die zusätzliche Information zum Vermeiden von Inkonsistenzen zwischen den Dienstqualitätsparametern verschiedener Kommunikationsnetze verwendet wird.
Verfahren nach einem der vorangehenden Ansprüche, wobei die Netzelemente des zweiten Untersystems das Objekt ignorieren und das Objekt in allen aus Verarbeitung der Steuerungsnachricht resultierenden Nachrichten weiterleiten.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Objekt zumindest ein Bit enthält, welches das die Steuerungsnachricht verarbeitende Element anweist, ob das Objekt von dem Element ignoriert werden sollte oder nicht.
Verfahren nach Anspruch 16, wobei ein Bit mit hoher Wertigkeit im Klassenzahloktett des Objektes enthalten ist.
Verfahren nach einem der vorangehenden Ansprüche, wobei ein Netzelement den Informationsinhalt des Objektes liest und das Objekt vor dem Weiterleiten der Nachricht aus der Nachricht entfernt.
Verfahren nach einem der vorangehenden Ansprüche, wobei ein Netzelement auf dem Kommunikationspfad die Objekte generiert und das Objekt der Steuerungsnachricht hinzufügt.
Verfahren nach Anspruch 20, wobei das Element eine Mobilstation aufweist.
Verfahren nach Anspruch 20, wobei das Element ein Element eines Funkzugriffsnetzes des ersten Untersystems aufweist.
Verfahren nach Anspruch 20, wobei das Element einen Gatewayknoten zwischen zwei verschiedenen Netzen aufweist.
Verfahren nach einem der Ansprüche 20 bis 23, wobei es dem Nutzer des Netzelementes möglich ist, die Verwendung der Objekte zu kontrollieren.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Objekt in einem die Verbindung abschließenden Endgerät interpretiert wird.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Objekt in einem Gatewayknoten zwischen verschiedenen Netzen interpretiert wird.
Kommunikationssystem mit: einem ersten Untersystem mit einer ersten Vielzahl von Elementen zur Übertragung von Nachrichten; einem zweiten Untersystem mit einer zweiten Vielzahl von Elementen zur Übertragung von Nachrichten; einer Steuereinrichtung zum Generieren einer Steuerungsnachricht, welche von zumindest einem Element des ersten Untersystems und zumindest einem Element des zweiten Untersystems interpretiert werden kann; und einer Steuereinrichtung zum Hinzufügen eines Objektes zu der Steuerungsnachricht, welches für die Elemente des zweiten Untersystems transparente Steuerungsinformation enthält, wobei die Anordnung so ist, dass eine Operation zumindest eines der Elemente des ersten Untersystems basierend auf die in dem Objekt enthaltene Steuerungsinformation gesteuert wird, während die Elemente des zweiten Untersystems nicht durch die in dem Objekt enthaltene Steuerungsinformation beeinflusst werden, wobei das zweite Untersystem ein Datennetz aufweist, welches auf einem sich von dem im ersten Untersystem verwendeten Kommunikationsprotokoll unterscheidenden Paketvermittlungskommunikationsprotokoll basiert.
Kommunikationssystem nach Anspruch 27, wobei das erste Untersystem ein dessen Nutzern drahtlose Dienste bereitstellendes Paketvermittlungsnetz aufweist.
Kommunikationssystem nach Anspruch 27 oder 28, wobei das erste Untersystem auf Universalmobiltelefonsystemspezifikationen und/oder allgemeinen Paketfunkdienstspezifikationen basiert.
Kommunikationssystem nach einem der Ansprüche 27 bis 29, wobei das zweite Untersystem ein auf dem Internetprotokoll basierendes Datennetz ist.
Kommunikationssystem nach einem der Ansprüche 27 bis 30, wobei das erste Untersystem ein erstes Netz und ein zweites Netz aufweist, wobei die Nachricht von dem ersten Netz an das zweite Netz über das zweite Untersystem übertragen wird.
Kommunikationssystem nach Anspruch 31, wobei das erste und das zweite Netz auf ähnlichen operationalen Grundsätzen basieren.
Kommunikationssystem nach einem der Ansprüche 27 bis 32, wobei das Kommunikationssystem zumindest ein erstes Endgerät und ein zweites Endgerät aufweist, wobei das erste Endgerät dem ersten Untersystem angehört und wobei eine Verbindung zwischen den beiden Endgeräten basierend auf einem Dienstqualitätsmechanismus für Paketdaten verhandelt wird.
Kommunikationssystem nach einem der Ansprüche 27 bis 33, wobei die Steuerungsnachricht eine Ressourcenreservierungsprotokollnachricht aufweist.
Kommunikationssystem nach einem der Ansprüche 27 bis 34, wobei das Objekt zumindest einen von dem ersten Untersystem zu Verbindungsaufbauzwecken benötigten Dienstqualitätsparameter enthält.
Kommunikationssystem nach einem der Ansprüche 27 bis 35, wobei Dienstqualitätsinformation basierend auf von dem Objekt mitgeführter Information bestimmt wird.
Kommunikationssystem nach einem der Ansprüche 27 bis 36, wobei die Netzelemente des zweiten Untersystems angepasst sind, das Objekt zu ignorieren, und das Objekt in allen aus Verarbeitung der Steuerungsnachricht resultierenden Nachrichten weiterleiten.
Kommunikationssystem nach einem der Ansprüche 27 bis 37, wobei das Netzelement auf dem Kommunikationspfad, welches die Objekte generiert und der Steuerungsnachricht das Objekt hinzufügt, eines von folgenden ist: eine Mobilstation; ein Element eines Funkzugriffsnetzes des ersten Untersystems; ein Gatewayknoten zwischen zwei verschiedenen Netzen.
Kommunikationssystem nach einem der Ansprüche 27 bis 38, wobei das Objekt von einem der Folgenden interpretiert wird: einem die Verbindung abschließenden Endgerät; einem Gatewayknoten zwischen verschiedenen Netzen.
Kommunikationssystem nach Anspruch 31, wobei das zweite Untersystem eine Verbindung zwischen dem ersten und dem zweiten Netz aufweist.
Nutzerausstattung für ein System, welches eine drahtlose Paketvermittlungskommunikation zwischen einem ersten und einem zweiten Paketvermittlungsnetz bereitstellt, wobei die Nutzerausstattung aufweist: eine Steuerung zum Generieren einer von dem ersten Netz an das zweite Netz zu signalisierenden Steuerungsnachricht, wobei die Steuerungsnachricht von Elementen einer ersten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes lesbar ist, und eine Steuerung zum Hinzufügen eines Steuerinformation enthaltenden Objektes zu der Steuerungsnachricht, wobei die Nachricht nur für Elemente einer zweiten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes lesbar ist, wobei das erste Netz auf einem Paketvermittlungskommunikationsprotokoll basiert, welches sich von dem in dem zweiten Netz verwendeten Kommunikationsprotokoll unterscheidet.
Nutzerausstattung nach Anspruch 41, wobei die Nachricht eine Ressourcenreservierungsprotokollnachricht aufweist und das Objekt eine Dienstqualitätsinformation enthält.
Steuerungsnachricht für ein Kommunikationssystem, wobei das Kommunikationssystem drahtlose Paketdatenkommunikation zwischen einem ersten und einem zweiten Netz bereitstellt, wobei die Steuerungsnachricht aufweist: einen von Elementen einer ersten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes zu interpretierenden Anteil; und ein Steuerungsinformationen enthaltendes Objekt, wobei das Objekt nur von Elementen einer zweiten vordefinierten Gruppe von Elementen des ersten und des zweiten Netzes lesbar ist, wobei das erste Netz auf einem Paketvermittlungskommunikationsprotokoll basiert, welches sich von dem von dem zweiten Netz verwendeten Kommunikationsprotokoll unterscheidet.
Steuerungsnachricht nach Anspruch 43, wobei die Nachricht eine Ressourcenreservierungsprotokollnachricht aufweist und das Objekt eine Dienstqualitätsinformation enthält.