DE60031435T2

DE60031435T2 - Dienstgütebezogene Herstellung einer Kommunikationssitzung in einem Kommunikationssystem

Info

Publication number: DE60031435T2
Application number: DE60031435T
Authority: DE
Inventors: Sanjoy Plano SEN; A. Jayshree Plano BHARATIA; C. Glenn Plano MORROW
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 1999-10-14
Filing date: 2000-08-30
Publication date: 2007-03-29
Anticipated expiration: 2020-08-31
Also published as: DE60031435D1; AU7088200A; WO2001028160B1; EP1226683B1; WO2001028160A3; EP1226683A2; WO2001028160A2

Description

Hintergrund
Die Erfindung bezieht sich auf den Aufbau einer Paket-Kommunikationssitzung mit einer Dienstgüte in einem Kommunikationssystem.
Mobile Kommunikationssysteme, wie zum Beispiel zellulare oder persönliche Kommunikationsdienste (PCS-Systeme) bestehen aus einer Vielzahl von Zellen. Jede Zelle schließt eine Funk-Basisstation ein, wobei jede Basisstation mit einer Funk-Vermittlungsstelle verbunden ist, die die Verarbeitung von Anrufen zwischen mobilen Einheiten oder mobilen Einheiten und drahtgebundenen Einheiten verarbeitet, die mit einem öffentlichen Fernsprechwählnetz (PSTN) verbunden sind.
Traditionell wurden mobile Kommunikationssysteme als leitungsvermittelte Netzwerke implementiert. In einem leitungsvermittelten Netzwerk wird eine Leitung zwischen zwei Endpunkten (beispielsweise zwischen zwei mobilen Einheiten) für die Dauer der Verbindung zwischen den Endpunkten belegt. Eine derartige Verbindung ist für Kommunikationen optimal, die relativ kontinuierlich sind, wie zum Beispiel Sprache. Datennetzwerke, wie zum Beispiel Intranetze und das Internet, verwenden jedoch paketbasierte Verbindungen, bei denen die Kommunikationen zwischen Knoten auf einer Verbindungsstrecke durch Datenpakete erfolgen. In derartigen Daten-Netzwerken belegt jeder Knoten die Kommunikations-Verbindungsstrecke lediglich solange, wie der Knoten ein Datenpaket senden oder empfangen muss.
Es wurden verschiedene paketbasierte drahtlose Protokolle vorgeschlagen, um effizientere Verbindungen zwischen einer mobilen Einheit und einem paketbasierten Daten-Netzwerk zu schaffen, wie zum Beispiel Internet-Protokoll- (IP-) Netzwerken. Ein derartiges Protokoll ist das allgemeine Paket-Funkdienst- (GPRS-) Protokoll, das vorhandene GSM-Systeme (globale Systeme für mobile Kommunikation) ergänzt. Andere Techniken, die auf GPRS aufbauen, sind die verbesserte GPRS- (EGPRS-) Technologie (die auch als vergrößerte Datenrate für globale Entwicklung oder EDGE bezeichnet wird) und die EGPRS-Kompakt- (oder EDGE-Kompakt-) Technologien, die höhere Datenraten bieten und GSM- und IS-136-Systeme ergänzen. Paketbasierte Kommunikation, wie zum Beispiel IP-Kommunikationen können somit über eine drahtlose Infrastruktur übertragen werden, die für derartige Paketdienste ausgestattet ist. Eine mobile Einheit, die „paketfähig" ist, kann somit auf effizientere Weise einen Zugang an traditionelle drahtgebundene paketbasierte Netzwerke erhalten, unter Einschluss des Internets und von lokalen Netzwerken (LAN) und Weitbereichs-Netzwerken (WAN).
Mit der vergrößerten Kapazität und Verfügbarkeit von paketbasierten Daten-Netzwerken haben die Arten von Diensten, die über derartige Netzwerke verfügbar sind, zugenommen. Traditionelle Formen von Kommunikationen über paketbasierte Daten-Netzwerke schließen die elektronische Post, die Dateiübertragung, das Web-Browsen und andere Austausch-Vorgänge von digitalen Daten ein. In letzterer Zeit wurden jedoch auch Audio- und Video-Kommunikationen (beispielsweise Sprachkommunikationen, Video-Konferenzen, Sammelsendungen von Multimedien-Daten) möglich. Sprachkommunikationen über paketbasierte Daten-Netzwerke unterscheiden sich von Sprachkommunikationen in einem konventionellen PSTN-System, das Benutzern diesen ausschließlich zugeordnete Ende-zu-Ende-Leitungsverbindungen für die Dauer jedes Anrufs zur Verfügung stellt. Sprache und andere Formen von Datenströmen, die über ein paketbasiertes Daten-Netzwerk ausgesandt werden, müssen sich die Netzwerk-Bandbreite mit konventionellen, keinen Datenstrom bildenden Daten teilen.
In einem paketbasierten Daten-Netzwerk, wie zum Beispiel einen IP- (Internet-Protokoll-) Netzwerk kann sich die Übertragungs-Geschwindigkeit der verschiedenen Pakete in weiten Umfang in Abhängigkeit von der Nutzung von Daten-Netzwerken ändern, über die die Datenpakete übertragen werden. Während Perioden starker Nutzung von Daten-Netzwerken können Verzögerungen bei der Übertragung von Sprach- oder anderen Datenstrom-Datenpaketen ein schlechtes Betriebsverhalten derartiger Kommunikationen hervorrufen. Sprach-Datenpakete, die aufgrund einer unzureichenden oder nicht verfügbaren Kapazität von Daten-Netzwerke verlorengehen oder verzögert werden, können zu Lücken, einer Stille und zu einer Begrenzung der Tonsignale an dem Empfangsende führen.
Um Kommunikationen, die Datenströme (wie zum Beispiel Sprache oder Video-Konferenzen) beinhalten, über Daten-Netzwerke zu verbessern, wurde ein Ressourcen-Reservierungsprotokoll (RSVP), wie es in der Aufforderung zu Kommentaren (RFC) 2205 mit dem Titel „Ressource Reservation Protokoll (RSVP)" vom 19. September 1997 beschrieben ist, vorgeschlagen, um Ressourcen für Verkehr über ein Daten-Netzwerk zu identifizieren und zu reservieren. Durch Reservieren derartiger Ressourcen entlang von Knoten auf dem Pfad von Kommunikationen kann ein gewisser Grad einer Dienstgüte (QoS) für einen Benutzer bereitgestellt werden, um den Eindruck zu verbessern, den ein Benutzer bei der Verwendung des Daten-Netzwerkes für verschiedene Arten von Kommunikationen erhält, unter Einschluss von Kommunikationen von Audio- und/oder Video-Daten.
Ein Knoten, unabhängig davon, ob er stationär oder mobil ist, kann verschiedene Anwendungen haben, die unterschiedliche Arten von Kommunikationen über das Daten-Netzwerk vorsehen. Beispielsweise haben Kommunikationen, wie zum Beispiel elektronische Post und das Web-Browsen, nur geringe QoS-Anforderungen, während Kommunikationen, wie zum Beispiel Audio- oder Video-Konferenzen, hohe QoS-Anforderungen stellen können. Dies ergibt sich daraus, das aufgrund der unterschiedlichen möglichen Arten von Kommunikationen die Unterstützung mehrfacher gleichzeitiger Datenströme mit unterschiedlichen QoS-Anforderungen erforderlich sein kann. Ein QoS-Profil kann in einem Paketdaten-Protokoll- (PDP-) Kontext definiert werden. Ein primärer PDP-Kontext kann einer IP-Adresse des mobilen Knotens zugeordnet werden. Um mehrfache QoS-Anforderungen pro IP-Adresse zu unterstützen, können ein oder mehrere sekundäre PDP-Kontexte oder PDP-Teil-Kontexte für den mobilen Knoten erzeugt werden. Unter der Vorgabe eines primären PDP-Kontextes kann ein mobiler Knoten mehrfache sekundäre PDP-Kontexte mit unterschiedlichen QoS-Profilen aktivieren, wenn und sobald diese erforderlich sind. Eine Diskussion der Aktivierung primärer und sekundärer PDP-Kontexte ist in der Veröffentlichung 3G TS 23.060 DRAFT-2 V3.1.0 (1999) enthalten.
Die Endpunkte einer paketbasierten Kommunikationssitzung können eine mit einem paketbasierten drahtlosen Netzwerk verbundene mobile Einheit und ein mit einem leitungsvermittelten Netzwerk, wie zum Beispiel dem PSTN, verbundenes Endgerät einschließen. Um eine derartige Kommunikationssitzung zu ermöglichen, ist eine Medien-Überleiteinrichtung zwischen dem paketbasierten drahtlosen Netzwerk und dem leitungsvermittelten Netzwerk vorgesehen. Die Medien-Überleiteinrichtung führt die Umsetzung zwischen paketbasierten Signalen und leitungsvermittelten Signalen aus. Obwohl QoS für paketbasierte Netzwerke definiert ist, unabhängig davon, ob drahtgebunden oder drahtlos, steht die QoS in leitungsvermittelten Netzwerken nicht zur Verfügung.
Das Dokument WO9905828 beschreibt ein Verfahren zum Aufbau einer Kommunikationssitzung zwischen einer mobilen Einheit und einem Endsystem an dem ISP, wobei ein RSVP-Protokoll verwendet wird.
Es besteht daher ein Bedarf an einem Mechanismus und einem Verfahren zur Bereitstellung von QoS in Kommunikationssitzungen zwischen mobilen Einheiten, die mit paketbasierten drahtlosen Netzwerken verbunden sind, und Endgeräten, die mit einem leitungsvermittelten Netzwerk verbunden sind.
Zusammenfassung
Gemäß der vorliegenden Erfindung wird ein Verfahren zum Aufbau einer Kommunikationssitzung zwischen einer mobilen Einheit und einem Endgerät gemäß Anspruch 1 geschaffen. Gemäß einem zweiten Gesichtspunkt der Erfindung wird ein Programmprodukt geschaffen, das ein oder mehrere maschinenlesbare Speicher-Medien umfasst, die Befehle enthalten, wie dies in Anspruch 16 beansprucht ist. Gemäß einem weiteren Gesichtspunkt der Erfindung wird ein System zur Verwendung in einem Kommunikations-Netzwerk geschaffen, das ein paketbasiertes drahtloses Netzwerk und ein leitungsvermitteltes Netzwerk umfasst, wie es im Anspruch 24 beansprucht ist.
Einige Ausführungsformen der Erfindung können ein oder mehrere der folgenden Vorteile einschließen. Es wird ein flexibles und zweckmäßiges Verfahren und ein Mechanismus zur Ausbildung einer Dienstgüte (QoS) in einem drahtlosen Netzwerk geschaffen, das paketbasierte Kommunikationsdienste unterstützt. QoS kann für Kommunikationen zwischen mobilen Einheiten oder Kommunikationen zwischen einer mobilen Einheit und einem Endgerät definiert werden, das mit einem leitungsvermittelten Netzwerk verbunden ist. Durch die Bereitstellung einer QoS in paketbasierten drahtlosen Netzwerken können vergrößerte Qualitätsstufen für Datenströme bereitgestellt werden, wie zum Beispiel Audio- oder Video-Daten.
Weitere Merkmale und Vorteile werden aus der folgenden Beschreibung, aus den Zeichnungen und den Ansprüchen ersichtlich.
In der folgenden Beschreibung sollen die Worte „Erfindung" und „Ausführungsform" so interpretiert werden, dass sie nur zur Erläuterung des technischen Hintergrundes und nicht zur Beschreibung des Schutzumfanges verwendet werden.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockschaltbild einer Ausführungsform eines Kommunikationssystems unter Einschluss eines paketbasierten drahtlosen Netzwerkes und eines leitungsvermittelten Netzwerkes.
2 ist ein Blockschaltbild eines Teils des Kommunikationssystems nach 1.
3 ist ein Mitteilungs-Flussdiagramm zum Aufbau einer Kommunikationssitzung mit einen Dienstgüte- (QoS-) Grad in dem Kommunikationssystem nach 1 gemäß einer Ausführungsform.
4 zeigt Komponenten eines Richtlinien-Steuermoduls und eine GPRS-Versorgungs-Unterstützungsknotens, die einen Teil des Kommunikationssystems nach 1 gemäß einer Ausführungsform bilden.
5 ist ein Mitteilungs-Flussdiagramm zum Aufbau einer Kommunikationssitzung mit einem QoS-Grad in dem Kommunikationssystem nach 1 gemäß einer weiteren Ausführungsform.
6 ist ein Mitteilungs-Flussdiagramm zur Einleitung einer sekundären Paketdaten-Protokoll- (PDP-) Kontext Aktivierung, die beim Aufbau der Kommunikationssitzung nach 5 ausgeführt wird.
7 ist ein Blockschaltbild von Komponenten in einem Überleiteinrichtungs-GPRS-Versorgungsknoten und eines QoS-Verwaltungsmoduls in dem Kommunikationssystem nach 1 gemäß einer weiteren Ausführungsform.
Ausführliche Beschreibung
In der vorliegenden Beschreibung werden vielfältige Einzelheiten angegeben, um ein Verständnis der vorliegenden Erfindung zu schaffen. Es sollte jedoch für den Fachmann verständlich sein, dass die vorliegende Erfindung ohne diese Einzelheiten in die Praxis umgesetzt werden kann, und dass vielfältige Abänderungen oder Modifikationen der beschriebenen Ausführungsformen möglich sind.
Gemäß 1 schließt ein Kommunikationssystem 10 ein paketbasiertes drahtloses Netzwerk ein. Mobile Einheiten 12 sind über entsprechende Funk-Zugangsnetzwerke (RAN) 16 mit einem GPRS-Versorgungs-Unterstützungsknoten (SGSN) 22 in dem paketbasierten Netzwerk gekoppelt. Kommunikationen in dem paketbasierten drahtlosen Netzwerk können gemäß einem allgemeinen Paket-Funkdienst- (GPRS-) Protokoll oder alternativ gemäß einem verbesserten allgemeinen Paket-Funkdienst- (EGPRS-) Protokoll (verbesserte Datenrate für globale Entwicklung oder EDGE) oder einem EGPRS-Kompakt-Protokoll (oder EDGE Kompakt) erfolgen. Das GPRS- oder EGPRS-Protokoll ergibt paketbasierte drahtlose Verbindungsstrecken mit einem drahtgebundenen paketbasierten Daten-Netzwerk 20, wie zum Beispiel einem Internet-Protokoll- (IP-) Netzwerk 20. Eine Version des IP ist in der Anforderung für Kommentare (RFC) 791 mit dem Titel „Internet Protocol" vom September 1981 beschrieben. Andere Versionen des IP, wie zum Beispiel IPv6 oder andere verbindungslose paketvermittelte Normen können ebenfalls in weiteren Ausführungsformen verwendet werden. Eine Version von IPv6 ist in der RFC 2460 mit dem Titel „Internet Protocol, Version 6 (IPv6) Specification" vom Dezember 1998 beschrieben.
Gemäß weiterer Ausführungsformen können anstelle von GPRS, EGPRS oder EGPRS-Kompakt auch andere Protokolle (wie zum Beispiel IS-2000 oder W-CDMA) zur Ermöglichung von paketbasierten drahtlosen Verbindungsstrecken zwischen mobilen Einheiten und einem paketbasierten Daten-Netzwerk verwendet werden.
Der SGSN 22 ist über eine Gn-Verbindungsstrecke mit einem GPRS-Überleiteinrichtungs-Unterstützungsknoten (GGSN) 24 gekoppelt, der die Schnittstelle zu dem paketbasierten Daten-Netzwerk 20 ist. Der SGSN 22 kann mit anderen SGSNs gekoppelt sein, wie zum Beispiel einem SGSN 26. Der SGSN 22 kann weiterhin mit anderen GGSNs gekoppelt sein, wie zum Beispiel dem GGSN 28. Wie dies hier verwendet wird, bilden die Infrastruktur, die die RANs, die SGSNs, die GGSNs und andere verwandte Einheiten einschließt, einen Teil des paketbasierten drahtlosen Netzwerkes.
Eine Medien-Überleiteinrichtung (MGG) 30 ergibt eine Schnittstelle zwischen dem drahtlosen Netzwerk und einem leitungsvermittelten Netzwerk, wie zum Beispiel einem öffentlichen Fernsprechwählnetz (PSTN) 32. Somit kann die mobile Einheit 12 in der Lage sein, eine Kommunikationssitzung mit einem Endgerät 33 aufzubauen, das mit dem PSTN 32 gekoppelt ist. Obwohl dies in 1 nicht gezeigt ist, kann eine Netzwerk-Wolke zwischen dem GGSN 24 und der Medien-Überleiteinrichtung 30 vorhanden sein. Eine derartige Netzwerk-Wolke kann einen Teil des Daten-Netzwerkes 20 bilden und eine Anzahl von Routern einschließen.
Der Pfad durch den SGSN 22, GGSN 24 und irgendwelche anderen Router zu der Medien-Überleiteinrichtung 30 oder dem Daten-Netzwerk 20 schließt Ressourcen ein, die von verschiedenen Kommunikationssitzungen gemeinsam genutzt werden, an denen mehrfache Einheiten beteiligt sind. Derartige Ressourcen können reserviert worden sein, um irgendeinen gewünschten Dienstgüte- (QoS-) Grad für aktive Kommunikationssitzungen bereitzustellen.
Gemäß mancher Ausführungsformen kann die QoS für eine Kommunikationssitzung zwischen einer mobilen Einheit, die mit dem paketbasierten drahtlosen Netzwerk gekoppelt ist, und einem Endgerät definiert werden, das mit einem leitungsvermittelten Netzwerk gekoppelt ist (und als „leitungsvermitteltes Endgerät" bezeichnet wird). Tatsächlich können bei einer aufgebauten Kommunikationssitzung mehrfache gleichzeitige Datenströme (beispielsweise IP-Ströme) mit unterschiedlichen QoS-Anforderungen zwischen einer mobilen Einheit und dem leitungsvermittelten Endgerät unterstützt werden. Ein Datenfluss bezieht sich auf den Austausch von Daten in einer Kommunikationssitzung zwischen zwei Endpunkten. Ein Datenfluss kann durch einen Tupel <Quellen-Adresse, Ziel-Adresse, Quellen-Port, Ziel-Port, Protokoll-ID> definiert werden. Jedem Datenfluss kann eine bestimmte QoS zugeordnet werden. Mehrfache Datenflüsse können aktiv sein und können unterschiedlichen QoS-Anforderungen zugeordnet sein.
Bei einer Ausführungsform wird ein QoS-Profil für eine mobile Einheit in einem Paketdaten-Protokoll- (PDP-) Kontext spezifiziert, dem eine IP-Adresse der mobilen Einheit zugeordnet ist. Daher können zur Unterstützung mehrfacher QoS-Datenflüsse pro IP-Adresse ein primärer PDP-Kontext und ein oder mehrere sekundäre PDP-Kontexte oder PDP-Teil-Kontexte für die mobile Einheit geschaffen werden. Unter der Voraussetzung eines primären PDP-Kontextes kann die mobile Einheit mehrfache sekundäre PDP-Kontexte oder PDP-Teil-Kontexte mit unterschiedlichen QoS-Profilen aktivieren, wenn und sobald dies erforderlich ist.
Ein PDP-Kontext kann die folgende Information enthalten. Der PDP-Typ kann spezifiziert werden, der IP, X.25 oder PPP (Punkt-zu-Punkt-Protokoll) als das Paketdaten-Protokoll identifizieren kann. Die PDP-Adresse ist ebenfalls in dem PDP-Kontext enthalten, ebenso wie ein QoS-Profil, das das für einen vorgegebenen Datenfluss angeforderte oder ausgehandelte QoS-Profil identifiziert. Wenn eine Kommunikationssitzung anfänglich aufgebaut wird, wird ein primärer PDP-Kontext aktiviert, der das Vorgabe-QoS-Profil enthält. Wenn unterschiedliche QoS-Profile für unterschiedliche Datenflüsse (beispielsweise für e-Mail-Verkehr, Audio- oder Video-Konferenzen, und so weiter) in der Kommunikationssitzung erwünscht sind, so können PDP-Teil-Kontexte mit unterschiedlichen QoS-Profilen aktiviert werden.
Gemäß mancher Ausführungsformen wird ein Aktivierungsmechanismus, der verfügbare Signalisierungstechniken nutzt, zur Aktivierung von PDP-Teil-Kontexten verwendet. Ein Beispiel einer derartiger Signalisierungstechnik schließt die Signalisierung ein, die durch das Ressourcen-Reservierungsprotokoll (RSVP) definiert ist. Eine Version von RSVP ist in der RFC 2205 mit dem Titel „Ressource Reservation Protocol (RSVP)" vom September 1997 beschrieben. Somit kann die RSVP-Signalisierung zur Einleitung der PDP-Teil-Kontext-Aktivierung (und wahlweise der Ressourcen-Reservierung) für Anrufe zwischen einer mobilen Einheit und einer Einheit verwendet werden, die mit dem PSTN 32 oder anderen leitungsvermittelten Netzwerken gekoppelt ist.
RSVP ist ein Signalisierungsprotokoll, das für die Ressourcen-Reservierung verwendet wird, um die Zuteilung unterschiedlicher Dienste-Grade für unterschiedliche Benutzer zu ermöglichen. RSVP kann dazu verwendet werden, eine Dienste-Unterscheidung für verzögerungsempfindliche Anwendungen durch die explizite Zuteilung von Ressourcen in dem Netzwerk zu bieten. RSVP ergibt eine Art von Leitungs-Emulation in paketvermittelten Netzwerken, wie zum Beispiel IP-Netzwerken. Unter RSVP ist ein RSVP-fähiger Sender in der Lage, abgehenden Verkehr in Ausdrücken der Bandbreite, der Verzögerung und des Jitter in vorgegebenen Mitteilungen zu charakterisieren. Jeder RSVP-fähige Router entlang der Netzabwärts-Route bildet einen Pfad-Zustand auf der Grundlage der empfangenen RSVP-Information aus. Als Antwort senden Empfänger Mitteilungen zurück, die den erforderlichen QoS-Grad einschließen.
Ein Vorteil der Verwendung der RSVP-Signalisierung besteht darin, das RSVP bereits Teil einiger Betriebssysteme ist, wie zum Beispiel WINDOWS^® 98 oder WINDOWS^® NT. Derartige Betriebssysteme können weiterhin Anwendungs-Programmierschnittstellen (APIs) für die QoS bereitstellen. Beispielsweise schließen WINDOWS^® 98 und WINDOWS^® NT QoS- (generische QoS- oder GQoS-) APIs ein. GQoS-APIs sind in der Veröffentlichung von Yoram Bernet et al, „Windows Networking Group: Winsock Generic QoS Mapping (draft)", Version 3.1. vom September 1998 beschrieben. Es wird erwartet, dass zukünftige Versionen der meisten vorhandenen Betriebssysteme QoS-APIs und RSVP-Unterstützung bereitstellen. Die Nutzung der bereits verfügbaren IP QoS-Unterstützung in dem Kommunikationssystem 10 kann in folgender Weise nützlich sein: die Funkstrecken-Mitteilungsübermittlung ist zum Aufbau eines PDP-Teil Kontextes optimiert. Vorhandene Mitteilungs-Sätze können mit relativ kleineren Modifikationen verwendet werden. Die Entwicklungskosten und die Entwicklungszeit kann verringert werden, weil Standard- und/oder bereits vorhandene Software-Komponenten verwendet werden können. Neue funkspezifische APIs müssen nicht entwickelt werden.
Somit wird gemäß mancher Ausführungsformen ein Verfahren und eine Vorrichtung zur Verwendung der RSVP-Signalisierung zur Zugangssteuerung, Ressourcen-Reservierung und PDP-Kontext-Aktivierung/Modifizierung (zur Ausbildung mehrfacher QoS-Profile für entsprechende Datenflüsse) für Anrufe zwischen Endpunkten in dem System geschaffen. Bei einem Beispiel kann ein Endpunkt eine mobile Einheit sein, die mit dem paketbasierten drahtlosen Netzwerk gekoppelt ist, während der andere Endpunkt beim leitungsvermitteltes Endgerät ist.
Wie dies weiterhin in 1 gezeigt ist, kann auch ein Heimatregister (HLR) 34, das eine Datenbank von Teilnehmer-Informationen enthält, vorhanden sein. Das HLR 34 wird durch einen Zellulardienst-Anbieter verwaltet und schließt die Heimat-Datenbank für Teilnehmer ein, die Vereinbarungen über einen Dienst mit einem Zellulardienst-Anbieter getroffen haben. Das HLR 34 enthält einen Datensatz für jeden Heimat-Teilnehmer, der Orts-Information, Teilnehmer-Status, vereinbarte Merkmale und Telefonnummern einschließt. Die Verbindungsstrecke zwischen dem HLR 34 und dem SGSN 22 ist eine Gr-Verbindungsstrecke.
Eine Verbindungszustands-Steuerfunktions- (CSCF-) Aufgabe ist ebenfalls in dem Kommunikationssystem 10 vorhanden. Die CSCF-Aufgabe 36 kann sich in irgendeiner eine Anzahl von Plattformen befinden, wie zum Beispiel dem SGSN 22 oder GGSN 24, und sie ergibt eine Gesamt-Anruf- oder Verbindungssteuerung für eine paketbasierte Kommunikationssitzung in dem drahtlosen Netzwerk. Ein weiteres Modul ist die Medien-Überleiteinrichtungs-Steuerfunktions- (MGCF-) Aufgabe 38, die die Medien-Überleiteinrichtung 30 steuert. Um eine Kommunikationssitzung zwischen der mobilen Einheit 12 und dem leitungsvermittelten Endgerät 33 aufzubauen, schließt der Pfad für die Steuer-Signalisierung die mobile Einheit 12, das Funkzugangs-Netzwerk 16, den SGSN 22, den GGSN 24, eine MRF- (Multimedien-Ressourcen-Funktions-) Aufgabe 37, die CSCF-Aufgabe 36 und die MGCF-Aufgabe 38 ein. Der Pfad für den Paket-Sprachverkehr für PSTN-Anrufe ist geringfügig verschieden und schließt die mobile Einheit 12, das Funkzugangs-Netzwerk 16, den SGSN 22, den GGSN 24 und die Medien-Überleiteinrichtung 30 ein.
Einige Ausführungsformen der Erfindung verhindern nicht die Nutzung anderer sekundärer PDP-Kontext- (oder PDP-Teil-Kontext-) Aktivierungs-Prozeduren, wie zum Beispiel derjenigen, die in der Veröffentlichung „Enhanced QoS Support in GPRS", Vorschlag für einen Änderungsantrag an die SMG vom 30. September 1999, oder in der Veröffentlichung „Extending GPRS to Support Fine-Grained QoS", Entwurf, der von der Firma AT & T-Wireless System auf dem 3GIP-Meeting in Toronto im August 1999 eingereicht wurde, beschrieben sind. Es können jedoch geeignete Prüfungen zum Vermeiden der Duplizierung von Aufgaben durchgeführt werden.
In 2 sind ein Teil des Kommunikationssystems 10 nach 1 und Komponenten von einigen der Netzwerk-Elemente gemäß einer Ausführungsform gezeigt. Die mobile Einheit 12 schließt ein oder mehrere QoS-fähige Anwendungen 102 und ein Betriebssystem (OS) 104 ein, das RSVP-fähig ist. Irgendeine QoS-fähige Anwendung kann Informationen über ihre QoS-Anforderungen und Verkehrsprofile an einen RSVP-Agenten 106 liefern, der einen Teil des OS 104 bildet oder diesem zugeordnet ist, wobei eine QoS-Anwendungs-Programmierschnittstelle (API) ähnlich der generischen QoS- (GQoS-) API verwendet wird. Der RSVP-Agent 106 kann dann PATH-/ oder RESV-Mitteilungen (gemäß RSVP) erzeugen. Es wird angenommen, dass der SGSN 22 ein RSVP-fähiger Router ist, obwohl der GGSN 24 kein RSVP-fähiger Router sein muss. Weitere Router können sich ebenfalls auf dem Pfad befinden. Mitteilungen, die von der mobilen Einheit 12 übertragen werden, werden von der Funkschnittstelle 108 ausgesandt oder von dieser empfangen, die mit einer Antenne 110 gekoppelt ist. Die Antenne 110 ist in der Lage, Funkfrequenz- (RF-) Signale mit einer Antenne 112 einer Basisstation 114 auszutauschen, die einen Teil des Funk-Zugangs-Netzwerkes 16 bildet. Die Basisstation 114 überträgt Mitteilungen an den SGSN 22, der seinerseits Mitteilungen an den GGSN 24 überträgt. Der GGSN 24 ist über eine Netzwerk-Wolke 125 mit der Medien-Überleiteinrichtung 30 gekoppelt. Die Netzwerk-Wolke 125 schließt verschiedene (nicht gezeigte) Router ein, die eine Routenführung von Datenpaketen über die Netzwerk-Wolke 125 zwischen dem GGSN 24 und der Medien-Überleiteinrichtung 30 ermöglichen. Die Router in der Netzwerk-Wolke 125 müssen nicht RSVP-fähig sein. Die Netzwerk-Wolke 125 kann ein Teil des Daten-Netzwerkes 20 sein, das in 1 gezeigt ist.
Für eine Kommunikationssitzung, die einen PSTN-Anruf beinhaltet, wird Datenverkehr zu der Medien-Überleiteinrichtung 30 übertragen. In einer Ausführungsform kann die Medien-Überleiteinrichtung 30 einen RSVP-Agenten 118 einschließen, der zur Verarbeitung der RSVP-Signalsisierung fähig ist. Der RSVP-Agent 118 in der Medien-Überleiteinrichtung 30 in dieser Ausführungsform ergibt den Endpunkt für die RSVP-Steuersignalisierung in einer Kommunikationssitzung zwischen der mobilen Einheit 12 und dem leitungsvermittelten Endgerät 33. Der GGSN 24 und der SGSN 22 können ebenfalls jeweilige RSVP-Agenten 116 und 120 einschließen.
Gemäß einer weiteren Ausführungsform kann, statt dass der Endpunkt für die RSVP-Signalisierung in der Medien-Überleiteinrichtung 30 liegt, ein getrenntes QoS-Verwaltungsmodul 40 den Endpunkt der RSVP-Signalisierung an das leitungsvermittelte Endgerät 33 bereitstellen. Das QoS-Verwaltungsmodul 40 kann als ein IP-QoS-Verwaltungsfunktion- (IQMF-) Modul in einer Ausführungsform bezeichnet werden. Wie dies gezeigt ist, ist das IQMF-Modul 40 mit einer ersten Seite der Netzwerk-Wolke 125 gekoppelt, die näher an dem GGSN 24 liegt.
Tatsächlich kann das IQMF-Modul 40 ein Teil des GGSN 24 sein. In einer anderen Ausführungsform kann das IQMF-Modul 40 mit der anderen Seite der Netzwerk-Wolke 125, die näher an der Medien-Überleiteinrichtung 30 liegt, oder mit einem Punkt im Inneren der Netzwerk-Wolke 125 verbunden sein.
Die Verwendung von RSVP dient zu QoS-Signalisierungs-Zwecken und ist unabhängig davon, ob ein Int-Serv oder Diff-Serv-basiertes QoS-Rahmenwerk oder irgendeine Art von Ressourcen-Reservierung innerhalb des Kommunikationssystem 10 verwendet wird. Die RSVP-Signalisierung wird zur Übertragung von QoS-Information zwischen Anwendungen in dem Kommunikationssystem 10 für die Aktivierung von PDP-Teil-Kontexten verwendet, um mehrfache QoS-Profile für unterschiedliche Flüsse bereitzustellen.
Das Int-Serv- oder Diff-Serv-Rahmenwerk kann in der Netzwerk-Wolke 125 implementiert werden. Das Int-Serv- (integrierte Dienst-) Rahmenwerk teilt Netzwerk-Ressourcen auf der Grundlage der QoS-Anforderung einer Anwendung in Abhängigkeit von irgendeiner Bandbreiten-Verwaltungs-Richtlinie zu. Das RSVP ergibt den Mechanismus zur Durchführung der Reservierung von Ressourcen in dem Int-Serv-Rahmenwerk. Das Diff-Serv- (differenzierte Dienste-) Rahmenwerk ist ein reservierungsfreier Mechanismus zur Bereitstellung unterschiedlicher Klassen von Diensten für Netzwerk-Verkehr. Um QoS unter Diff-Serv zu ermöglichen, werden Klassifizierungen von Netzwerk-Verkehr geschaffen, um eine bevorzugte Behandlung denjenigen Anwendungen zu geben, die als Anwendungen mit größeren Anforderungen identifiziert sind. Die Netzwerk-Wolke 125 kann weiterhin die MPLS- (Mehrprotokoll-Etikettvermittlungs-) Technologie implementieren. MPLS fügt verbindungsorientierte Mechanismen zu verbindungslosen Netzwerk-Schichtprotokollen hinzu.
In einer Kommunikationssitzung, die eine mobile Einheit und ein leitungsvermitteltes Endgerät beinhaltet, kann lediglich ein Endpunkt RSVP unterstützen (die mobile Einheit). Das leitungsvermittelte Endgerät kann RSVP nicht unterstützen. Als Ergebnis sind bei derartigen Kommunikationssitzungen die RSVP-Endpunkte die mobile Einheit 12 und ein Gerät innerhalb des paketbasierten Kommunikationssystems Das Gerät kann die Medien-Überleiteinrichtung 30 oder das IQMF-Modul 40 sein.
In 3 ist der Aufbau eines PDP-Teil-Kontextes (oder eines sekundären PDP-Kontextes) für einen Datenfluss mit einer bestimmten QoS gezeigt. Bei der Ausführungsform nach 3 wird angenommen, dass die Medien-Überleiteinrichtung 30 ein Endpunkt für die RSVP-Signalisierung ist. Es werden anfängliche Aufbau-Aufgaben ausgeführt (bei 202) bei denen die mobile Einheit Sitzungs-Aufbaumitteilungen mit der CSCF-Aufgabe 36 und der MGCF-Aufgabe 38 austauscht (wobei die CSCF-Aufgabe 36 als ein Proxy wirkt). Als Teil des Anruf-Aufbaus wird ein primärer PDP-Kontext mit einer Vorgabe-QoS aufgebaut. In einem Beispiel kann eine Anruf-Sitzung unter Verwendung einer Mitteilungsübermittlung gemäß einem Sitzungs-Initialisierungs-Protokoll (SIP) aufgebaut werden. Eine Version von SIP ist in der RFC 2543 mit dem Titel „SIP: Session Initiation Protocol" aus dem Jahr 1999 beschrieben. Bei dem SIP wird eine Anruf-Sitzung dadurch eingeleitet, dass die Anruf-Einheit eine SIP-Einladungs-Anforderung sendet, gefolgt von der Übertragung einer SIP-Rufton-Antwort, um anzuzeigen, dass ein Versuch zum Erreichen der angerufenen Einheit gemacht wird.
Es wurden auch Erweiterungen für das SIP vorgeschlagen, unter Einschluss derjenigen, die Mitteilungen definieren, die für die Aushandlung und die Reservierungs-Bestätigung vor der Rufton-Übertragung zurück von der angerufenen Einheit verwendet werden. Beispielsweise kann zwischen der Einladung und der Rufton-Übermittlung eine Vorschlag-Mitteilung übertragen werden, um ein spezielles Ressourcen-Reservierungs-Signalisierungsprotokoll, gewünschte Audio-Codierer/Decodierer (Codecs) und andere Information anzuzeigen. In einem in dem PSTN endenden Anruf kann die die Einladungs-Anforderung verarbeitende Einheit die MGCF 38 sein, die weiterhin die Vorschlags-Mitteilung erzeugen und senden kann. Als Antwort auf die Vorschlags-Mitteilung kann die anrufende Einheit eine Festlegungs-Mitteilung senden, um den speziellen gewählten Codec, das gewählte Reservierungsverfahren und andere Information zu identifizieren. Eine weitere Diskussion eines derartigen Aushandlungs-Mechanismus ist in der Veröffentlichung von Glenn Morrow, „Transaction Negotiation and Ringback Optimization Considerations", Nortel 3G. IP-Beitrag vom 14. September 1999 enthalten.
Bei einer Ausführungsform sendet die MGCF-Aufgabe 38 Adressen-Information der Medien-Überleiteinrichtung 30 an die mobile Einheit (für RSVP-Signalisierungszwecke). Die MGCF-Aufgabe 38 kann diese Information in die Vorschlags-Mitteilung einschließen, die an die CSCF-Aufgabe 36 gesandt wird, wobei die Adressen-Information der Medien-Überleiteinrichtung an die mobile Einheit durch die CSCF-Aufgabe 36 vermittelt wird. Bei weiteren Ausführungsformen können andere Anrufsitzungs-Aufbaumechanismen (oder Aufbau-Mechanismen für andere Arten von Kommunikationssitzungen) verwendet werden. Beispielsweise kann der GGSN die RSVP-Mitteilungen an den RSVP-Agenten lenken. Dies setzt nicht voraus, dass die mobile Station die IP-Adresse des RSVP-Endpunktes kennt.
Als nächstes liefert die QoS-fähige Anwendung 102 in der mobilen Einheit dem RSVP-Agenten 106 die Verkehrs- und QoS-Charakteristiken, die (bei 204) zur Erzeugung einer RSVP-PATH-Mitteilung verwendet werden, die die Sender_Tspec-Information enthält. Die Sender_Tspec enthält Information über das Verkehrsprofil, das von der Anwendung 102 zu erzeugen ist, das heißt peak_rate, token_rate, token_bucket_size, max_sdu_size, und so weiter. Bei dieser Ausführungsform ist die Zieladresse der PATH-Mitteilung die Adresse der Medien-Überleiteinrichtung 30. Die Sender_Tspec-Information definiert die Verkehrs-Charakteristiken des Datenflusses, den der Sender (in diesem Fall die mobile Einheit) erzeugen wird.
Wahlweise kann in der Pfad-Mitteilung die Audio-/Video-Codierer/Decodierer- (Codec-) Information als ein Objekt der Sender_Tspec Information enthalten sein. Die Codec-Information wird zur Information beider Enden der Kommunikationssitzung über den zu verwendenden Codec verwendet. Die Verwendung der Codec-Information in der Pfad-Mitteilung kann einen ungleichen Ende-zu-Ende-Schutz an segmentierte Zugangsnetzwerken ermöglichen, wie zum Beispiel CDMA 2000- und UMTS- (universelle mobile Telekommunikationssystem-) Netzwerken. Weiterhin kann, wenn IPv4 und MPLS verwendet werden, ein MPLS-Fluss-Etikett, das dem Codec zugeordnet ist, in die Sender_Tspec Information der Pfad-Mitteilung eingefügt werden, um einen Datenfluss Ende-zu-Ende derart zu identifizieren, dass Ende-zu-Ende-Verschlüsselungs-Mechanismen, die zum Beispiel IP-Security (IPSEC) verwendet werden können. Das MPLS-Datenfluss-Etikett ermöglicht eine Identifikation pro Datenfluss und die Abwicklung von Datenströmen (beispielsweise die Verwendung und Auswahl von Funkverbindungsstrecken-Transport-Mechanismen sowie geeigneter Funk-Kompressionsverfahren) Ende-zu-Ende. Wenn IPv6 verwendet wird, ist jedoch ein getrenntes MPLS-Datenfluss-Etikett nicht erforderlich, weil IPv6 bereits das Datenfluss-Etikett vorsieht.
Die Pfad-Mitteilung wird von den RSVP-fähigen Routern auf dem Pfad (dem SGSN 22 und möglicherweise weiteren) abgefangen, von denen jeder den Pfad-Zustand installiert und die Pfad-Mitteilung in Richtung auf den Empfänger weiterleitet (in dieser Ausführungsform an die Medien-Überleiteinrichtung 30). Der in dem SGSN 22 installierte Pfad-Zustand kann die IP-Adresse des Senders und die RSVP-Sitzungsinformation einschließen. Wie die in 2 gezeigt ist, kann die Pfad-Mitteilung Router in der Netzwerk-Wolke 125 durchlaufen, die nicht RSVP-fähig sind.
Der RSVP-Agent 118 in der Medien-Überleiteinrichtung 30 fängt die Pfad-Mitteilung ab und erzeugt eine RESV-Mitteilung (bei 206), die die Flow_Spec-Information (Datenfluss-Spezifikations-Information, die R_Spec und Receiver_ (Empfänger) Tspec) enthält. R_Spec enhält Information über die QoS-Anforderungen (Rate und Verzögerungs-Durchgang_Ausdruck) für den Verkehr, der in Receiver_Tspec beschrieben ist. Die Receiver_Tspec wird durch Kopieren der Information von der Sender_Tspec in der Pfad-Mitteilung geschaffen. Die RESV-Mitteilung wird an die mobile Einheit zurückgesandt.
Der RSVP-Agent 118 in der Medien-Überleiteinrichtung 30 kann optional (bei 210) eine Pfad-Mitteilung erzeugen und diese an die mobile Einheit senden. Die Inhalte dieser Mitteilung werden von der Pfad-Mitteilung abgeleitet, die von der mobilen Einheit empfangen wird. Die Erzeugung dieser Pfad-Mitteilung leitet die Ressourcen-Reservierung in der entgegengesetzten Richtung ein (von der Medien-Überleiteinrichtung 30 an die mobile Einheit 12). Als Antwort auf die Pfad-Mitteilung bei 210 kann eine RESV-Mitteilung (bei 212) von dem empfangenden Endpunkt zurückgeliefert werden.
Die RESV-Mitteilung (die bei 206 durch die Medien-Überleiteinrichtung 30 als Antwort auf die Pfad-Mitteilung von der mobilen Einheit erzeugt wird) durchläuft das Netzwerk Hop für Hop in der Rücklaufrichtung. An jedem RSVP-fähigen Router wird eine Anruf-Zulassungs-Entscheidung auf der Grundlage der Flow_Spec-Information durchgeführt, die in der RESV-Mitteilung enthalten ist. Wenn der Fluss zugelassen wird, werden Ressourcen für diesen Fluss in dem Route reserviert, und die RESV-Mitteilung wird an den nächsten Knoten gesandt. Anderenfalls wird eine RESV_FEHLER-Mitteilung erzeugt und an den Empfänger zurückgesandt (in diesem Fall die Medien-Überleiteinrichtung 30).
Der RSVP-Agent 120 in dem SGSN 22 empfängt die RESV-Mitteilung. Wenn die RESV-Sitzung in der RESV-Mitteilung mit der in dem installierten Pfad-Zustand übereinstimmt, so führt der SGSN 22 eine Anruf-Zuslassungs-Entscheidung auf der Grundlage der Router-Ressourcen aus. Im Erfolgsfall leitet der SGSN 22 (bei 208) die Flow-Spec-Information an ein Übersetzungs-Modul 302 in einer Richtlinien-Steueraufgabe 300 (4) gemäß einer Ausführungsform weiter. Die IP-Adresse des Senders und die RSVP-Sitzungsinformation werden (bei 208) an eine Zulassungs-Steuerung 304 gesandt, die ebenfalls Teil der Richtlinien- (policy) Steueraufgabe 300 ist. Die Richtlinien-Steueraufgabe 300 kann in dem SGSN 22 implementiert sein.
Die Verantwortlichkeiten des Übersetzungs-Moduls 302 bestehen in der Umwandlung zwischen den QoS-Parametern externer Netzwerke (beispielsweise der RSVP-Parameter) und Trägerdienst-Attributen entsprechend UMTS. Bei einer Ausführungsform kann das Übersetzungs-Modul 302 die Flow_Spec-Parameter in 3GIP- (dritte Generations-IP-) Träger-Attribute umsetzen, wie dies in dem 3G TR23.907-Technical Report, „3^rd Generation Partnership Project: Technical Specification Group Services and System Aspects, QoS Concept and Architecture", Version 1.4.0 vom September 1999 beschrieben ist (nachfolgend als die „3G TR23.907-Spezifikation" bezeichnet), deren Inhalt durch diese Bezugnahme hier aufgenommen wird. Alternativ können die Flow_Spec-Parameter so wie sie sind ohne Umsetzung verwendet werden. Das Übersetzungs-Modul 302 setzt weiterhin die Diensteklassen-Information in der Flow_Spec auf eine der UMTS QoS-Klassen um. Das Übersetzungs-Modul 302 leitet dann die Information an die Zulassungs-Steuerung 304 weiter.
Die RSVP-Flow_Spec-Information enthält ein Dienste_Typ-Feld, das die Dienste-Klasse angibt, nämlich „Bestes Bemühen", „Gesteuerte Last" oder „Garantierter Dienst". Der „Garantierte Dienst" ergibt feste (mathematisch beweisbare) Grenzen hinsichtlich der Ende-zu-Ende-Paket-Warteschlangen-Verzögerungen. Dieser Dienst macht es möglich, einen Server bereitzustellen, der sowohl die Verzögerung als auch die Bandbreite garantiert und für Anwendungen bestimmt ist, die eine feste Garantie benötigen, dass ein Datenpaket nicht später als eine bestimmte Zeit nach seiner Aussendung durch seine Quelle ankommt, wie in Echtzeit-Kommunikationen. Der „Gesteuerte Last"-Dienst liefert den Klienten-Datenfluss mit einer Dienstgüte, die eng an die QoS angenähert ist, die der gleiche Fluss von einem unbelasteten Netzwerk-Element erhalten würde, verwendet jedoch eine Kapazitäts- (Zulassungs-) Steuerung, um sicherzustellen, dass dieser Dienst selbst bei einer Überlastung des Netzwerk-Elementes empfangen wird. Der Dienst „Besten Bemühens" ist die Vorgabe-QoS.
Die UMTS-QoS-Klasse „Hintergrund" kann auf die Dienste-Klasse „Besten Bemühens" umgesetzt werden, während die UMTS-"Konversations"- und „Datenstrom"-Klassen auf die „Garantierter Dienst"-Klasse umgesetzt werden können, und die „UMTS-Interaktiv"-Klasse kann auf die „Gesteuerte Last"-Klasse umgesetzt werden. Die durch UMTS definierte Hintergrund-Klasse bezieht sich auf Verkehr, der die am wenigsten verzögerungsempfindliche Verkehrsklasse ist. Die interaktive Klasse und die Hintergrund-Klasse sind traditionellen Daten-Netzwerk-Anwendungen zugeordnet, wie Web-Browsen, e-mail-Kommunikation, Dateiübertragungen und so weiter. Die interaktive Klasse wird von dem Verkehr verwendet, der interaktiven Anwendungen zugeordnet ist, wie zum Beispiel textbasierten Unterhaltungs-Sitzungen, während die Hintergrund-Klasse für Hintergrund-Verkehr bestimmt ist, wie zum Beispiel das Herunterladen von e-mails im Hintergrund oder das Herunterladen von Dateien im Hintergrund. Die Konversations- und Datenstrom-Klassen sind hauptsächlich zur Übertragung von Echtzeit-Verkehrsflüssen bestimmt, wie zum Beispiel Audio, Video oder Multi-Medien-Verkehr. Der Konversations-Klassen-Verkehr ist am stärksten verzögerungsempfindlich, und er kann für Telefonie (Audio, Video oder Multi-Medien) verwendet werden. Anderseits kann der Datenstrom-Klassen-Verkehr typischerweise für Einweg-Audio- oder Video-Echtzeit-Datenströme verwendet werden, beispielsweise dann, wenn ein Benutzer Echtzeit-Video (oder Audio) betrachtet (oder hört).
Auf der Grundlage der Information, die von dem Übersetzungs-Modul 302 übertragen wird, führt die Zulassungs-Steuerung 304 eine richtlinienbasierte Anruf-Zulassungs-Entscheidung auf der Grundlage von Teilnehmer-Information (auf der Grundlage der IP-Adresse des Senders gewonnen) und der angeforderten QoS- (Träger-Attribute) aus. Die Anruf-Zulassungs-Entscheidung wird (bei 214) an den SGSN 22 gesandt.
Wenn ein neuer Funk-Zugangs-Träger (RAB) benötigt wird, sendet der SGSN 22 (bei 216) eine Funk-Zugangs-Träger-Zuordnungs-Mitteilung an eine Ressourcen-Verwaltung in dem Funk-Zugangs-Netzwerk 16, um die RAB-Zuordnungs-/Modifikations-Prozedur auszulesen. Der Abschluss der RAB-Zuordnungs-/Identifikations-Prozedur wird durch eine RAB-Zuordnung-Abgeschlossen-Mitteilung angezeigt, die (bei 218) von dem Funk-Zugangs-Netzwerk 16 an den SGSN 22 gesandt wird.
Gemäß einer Ausführungsform leitet, sobald der Anruf unter Einschluss der neuen Flow_Spec-Information zugelassen wird, der SGSN 22 eine PDP-Teil-Kontext- (oder sekundäre PDP-Kontext-) Aktivierungs-Prozedur dadurch ein, dass er (bei 220) eine Modifiziere-PDP-Kontext-Mitteilung an die mobile Einheit sendet, die das neue QoS-Profil enthält, wie es in den PATH- und RSV-Mitteilungen ausgehandelt wurde, die vorstehend erläutert werden. Als nächstes empfängt der SGSN 22 (bei 222) eine Modifiziere-PDP-Kontext-Antwort-Mitteilung von der mobilen Einheit. Als Antwort sendet der SGSN 22 (bei 224) eine Aktualisiere-PDP-Kontext-Anforderungs-Mitteilung an den GGSN 24, um eine Aktualisierung mit dem neuen QoS-Profile durchzuführen. Als Antwort sendet der SGSN 24 (bei 226) eine Aktualisierungs-PDP-Kontext-Antwort zurück an den SGSN 22.
Wenn die Anruf-Zulassung erfolgreich ist, leitet der RSVP-Agent 114 in dem SGSN 22 (bei 228) die RESV-Mitteilung (die modifiziert werden sein kann) an den nächsten Knoten auf seinen Pfad. Wenn der nächste Knoten auf den Pfad die mobile Einheit ist, so ist der Empfang der RESV-Mitteilung eine Anzeige, dass ein Ende-zu-Ende-QoS-Pfad erfolgreich aufgebaut wurde, und die QoS-fähige Anwendung 102 kann mit der Kommunikation von Daten beginnen. Die Reservierung kann fehlschlagen, wenn der nächste Knoten in dem Pfad ein anderer Router ist. Wegen diesem Fall kann die von dem Router erzeugte RESV_FEHLER-Mitteilung die PDP-Teil-Kontext-Deaktivierungs-Prozedur auf dem Teil des Netzwerkes auslösen.
In 5 ist gemäß einer alternativen Ausführungsform ein Mitteilungs-Fluss gezeigt, der den RSVP-Agenten 106 in der mobilen Einheit 12, den GGSN 24 und das IQMF-Modul 40 beteiligt, um einen PDP-Teil-Kontext mit einem anderen QoS- Profil als dem Vorgabe-QoS-Profil des primären PDP-Kontextes zu aktivieren. Wie bei der Ausführungsform nach 3 können anfängliche Aufbau-Aufgaben (bei 402) ausgeführt werden, um eine Anruf-Sitzung aufzubauen. Der Anruf-Aufbau kann unter Verwendung einer SIP-Mitteilungs-Übermittlung durchgeführt werden. Bei dem Anruf-Aufbau kann das CSCF-Modul 36 (1) die IP-Adresse des IQMF-Moduls 40 als die Adresse des RSVP-Endpunktes liefern. Als nächstes sendet der RSVP-Agent 106 (bei 404) die Verkehrs- und QoS-Charakteristiken, die der QoS-fähigen Anwendung 102 in einer PATH-Mitteilung zugeordnet sind. Die PATH-Mitteilung enthält die Sender_Tspec-Information. Die PATH-Mitteilung wird von dem RSVP-fähigen Routern auf dem Pfad zwischen der mobilen Einheit 12 und dem IQMF-Modul 40 abgefangen. Der RSVP-Agent 122 in dem IQMF-Modul 40 empfängt die PFAD-Mitteilung und leitet die Filter_Spec-Information des Senders ab, die die IP-Adresse und die UDP/TCP-Port-Identifikation einschließt. Die Ressourcen-Anforderung in Form der Dienste-Klasse in der Sender_Tspec wird ebenfalls abgeleitet. Auf der Grundlage der in dem IQMF-Modul 40 durchgeführten Verarbeitung sendet das IQMF-Modul 40 (bei 406) eine Trigger-Anzeige an den GGSN 24, um zu bewirken, dass der GGSN 24 eine Netzwerk-initiierte PDP-Teil-Kontext-Aktivierung (bei 408) ausführt, wie dies weiter unten in Verbindung mit 6 beschrieben wird. Sobald die PDP-Teil-Kontext-Aktivierung durchgeführt wurde, sendet der GGSN 24 (bei 410) eine Auslöse-Antwort zurück an das IQMF-Modul 40. Das IQMF-Modul 40 sendet dann (bei 412) die RESV-Mitteilung an den RSVP-Agenten 106 in der mobilen Einheit 12 entlang des Rückwärts-Pfades der PATH-Mitteilung (bei 404 gesendet). Der Rest des Anruf-Aufbaus wird dann durchgeführt (bei 414).
In 6 ist die Netzwerk-initiierte sekundäre PDP-Kontext-Aktivierungs-Prozedur, die bei 408 ausgeführt wird, mit weiteren Einzelheiten gezeigt. Der GGSN 24 empfängt (bei 502) einen Stimulus von dem externen Netzwerk, dass eine Aktivierung eines PDP-Teil-Kontextes für einen neuen IP-Fluss erforderlich ist. Dieser externe Stimulus ist der Trigger, das bei 406 in 5 gesendet wird. Aus der primären PDP-Kontext-Information kann der GGSN 24 den SGSN bestimmen, der derzeit die mobile Einheit 12 mit Diensten versorgt.
Als nächstes sendet der GGSN 24 eine PDU-Benachrichtigungs-Anforderung (bei 504) an den SGSN 22. Die PDU-Benachrichtigungs-Anforderung kann die QoS- Anforderungs-Information enthalten. Der SGSN 22 sendet dann (bei 506) eine PDU-Benachrichtigungs-Antwort an den GGSN 24, um zu bestätigen, dass er die mobile Einheit 12 auffordern wird, den PDP-Teil-Kontext zu aktivieren.
Als nächstes sendet der SGSN 22 (bei 508) eine PDP-Teil-Kontext-Aktivierungs-Anforderungs-Mitteilung, die QoS-Parameter, eine TFT (Verkehrsfluss-Schablone) und andere Information enthält, an die mobile Einheit 12. Die mobile Einheit 12 kann die QoS-Parameter, die TFT u.s.w. Modifizieren, die in der sekundären PDP-Kontext-Aktivierungs-Anforderungs-Mitteilung von dem SGSN 22 angegeben sind. Ein weiterer Mitteilungs-Austausch erfolgt (bei 510), um den PDP-Teil-Kontext zwischen der mobilen Einheit 12 und dem SGSN 22 auszubilden, was eine Aktiviere-Sekundäre-PDP-Kontext-Anforderung einschließen kann, die von der mobilen Einheit an den SGSN 22 gesandt wird. Die Aktiviere-Sekundäre-PDP-Kontext-Anforderung enthält das gewünschte QoS-Profil.
In 7 sind die Komponenten des GGSN 24 und des IQMF-Moduls 40 gemäß dieser alternativen Ausführungsform gezeigt. Bei dieser Ausführungsform schließt der GGSN 24 eine Zulassungs-/Fähigkeits-Steuerung 602 ein, die Informationen über die verfügbaren Ressourcen einer Netzwerk-Einheit und aller Ressourcen unterhält, die den UMTS-Träger-Diensten zugeteilt sind. Der GGSN 24 schließt weiterhin ein Übersetzer-Modul 604 ein, das eine Umwandlung zwischen QoS-Parametern gemäß einen externen Netzwerk-Protokoll (beispielsweise RSVP) und internen Dienste-Primitiven für die UMTS-Trägerdienst-Attribute durchführt. Eine UMTS-Basisstation- (BS-) Verwaltung in der GGSN 24 kommuniziert über das Übersetzungs-Modul 604 mit externen Instanzen der UMTS-BS-Verwaltung in der mobilen Einheit 12 und dem SGSN 22, um einen UMTS-Träger-Dienst aufzubauen oder zu modifizieren. Die UMTS-BS-Verwaltung 606 befragt die Zulassungs-/Fähigkeits-Steuerung 602, ob die Netzwerk-Einheit den speziellen angeforderten Dienst unterstützt, und ob die erforderlichen Ressourcen zur Verfügung stehen. Das IQMF-Modul 40 schließt den RSVP-Agenten 122 und eine QoS-Richtlinien-Verwaltung 608 ein.
Ein Verfahren und eine Vorrichtung wird geschaffen, um ein oder mehrere gewünschte QoS-Profile in entsprechenden einen oder mehreren Datenströmen in einer Kommunikationssitzung bereitzustellen, die zwischen einer mobilen Einheit und einem Endgerät aufgebaut wird, das mit einem leitungsvermittelten Netzwerk gekoppelt ist. Eine RSVP-Signalisierung oder Signalisierung entsprechend anderer Protokolle zur Reservierung von Netzwerk-Ressourcen kann verwendet werden, um die Aktivierung unterschiedlicher QoS-Profile einzuleiten. Die QoS-Profile können durch sekundäre PDP-Kontexte (oder PDP-Teil-Kontexte) definiert werden. Dies ermöglicht die Auswahl eines QoS-Profil, das die Notwendigkeiten unterschiedlicher Anwendungen erfüllt, wie zum Beispiel von Anwendungen in der mobilen Einheit. Beispielsweise können e-mail- oder Web-Browser-Anwendungen in der mobilen Einheit niedrigere QoS-Anforderungen haben, als Anwendungen, die Kommunikationen mit Datenströmen bereitstellen, wie zum Beispiel Audio-, Video- oder Multi-Medien-Kommunikationen.
Die verschiedenen Software-Routinen, Module oder Aufgaben, die hier beschrieben werden, können auf verschiedenen Steuereinheiten ausführbar sein. Jede Steuereinheit kann einen Mikroprozessor, einen Mikrocontroller, eine Prozessor-Karte (die ein oder mehreren Mikroprozessoren oder Mikrocontroller enthält) oder andere Steuer- oder Recheneinrichtungen einschließen. Wie der Begriff hier verwendet wird, kann eine „Steuerung" Hardware, Software oder eine Kombination von Beidem einschließen.
Das Speichergerät kann ein oder mehrere maschinenlesbare Speichermedien zum Speichern von Daten und Befehlen einschließen. Die Speichermedien können unterschiedliche Formen von Speichern unter Einschluss von Haltleiter-Speichereinrichtungen, wie zum Beispiel dynamischen oder statischen Speichern mit wahlfreien Zugriff (DRAMs oder SRAMs), löschbare und programmierbare Festwertspeicher (EPROMs), elektrisch löschbare und programmierbare Festwertspeicher (EEPROMs) und Flash-Speicher, Magnetplatten, wie zum Beispiel Festplatten, Floppy- und Wechsel-Platten, andere magnetische Medien unter Einschluss von Bändern, und optische Medien einschließen, wie zum Beispiel Kompaktdisks (CDs) oder digitale Video-Disks (DVDs). Befehle, die die verschiedenen Software-Schichten, Routinen oder Module in verschiedenen Netzwerk-Elementen bilden, können auf jeweiligen Speichergeräten gespeichert werden. Die Befehle bewirken bei ihrer Ausführung durch eine jeweilige Steuereinheit, dass das entsprechende Netzwerk-Element die programmierten Vorgänge ausführt.
Die Befehle der Software-Schichten, Routinen oder Module können an das Netzwerk-Element auf eine von verschiedenen Arten transportiert werden. Beispielsweise können Code-Segmente unter Einschluss von Befehlen, die auf Floppy-Disk, CD- oder DVD-Medien oder Festplatten gespeichert oder über eine Netzwerk-Schnittstellenkarte, ein Modem oder eine andere Schnittstellen-Einrichtung transportiert werden, in das System geladen und als entsprechendes Software-Schichten, Routinen oder Module ausgeführt werden. In dem Lade- oder Transport-Prozess können Datensignale, die in Trägerschwingungen verkörpert sind (und über Telefonleitungen, Netzwerk-Leitungen, drahtlose Verbindungsstrecken, Kabel und dergleichen übertragen werden) Code-Segmente unter Einschluss von Befehlen an die Netzwerk-Elemente übertragen. Derartige Trägerschwingungen können die Form von elektrischen, optischen, akustischen, elektromagnetischen oder anderen Arten von Signalen haben.
Obwohl die Erfindung bezüglich einer begrenzten Anzahl von Ausführungsformen beschrieben wurde, wird der Fachmann ohne weiteres erkennen, dass vielfältige Modifikationen und Abänderungen hiervon möglich sind. Die beigefügten Ansprüche soll alle derartigen Modifikationen und Abänderungen abdecken, die in dem Schutzumfang der Erfindung fallen.

Claims

Verfahren zum Aufbau einer Kommunikationssitzung zwischen einer mobilen Einheit (12) und einem Endgerät (33), das mit einem leitungsvermittelten Netzwerk (32) verbunden ist, wobei ein primärer PDP- (Paketdaten-Protokoll-) Kontext eine erste Dienstgüte hat, die in der Kommunikationssitzung festgelegt wird, dadurch gekennzeichnet, dass das Verfahren Folgendes umfasst: Empfangen (404) einer Ressourcen-Reservierungsprotokoll-, RSVP, PATH- (Pfad-) Mitteilung, die von der mobilen Einheit (12) ausgeht; Empfangen (406) einer Antwort-Mitteilung von einem Gerät (30, 40), das als Zielgerät für eine Dienstgüte-Signalisierung für das Endgerät (33) ausgelegt ist, wobei die Antwort-Mitteilung eine Antwort auf die RSVP PATH-Mitteilung darstellt; und Senden (508) einer Anzeige an die mobile Einheit (12) zum Aufbau eines sekundären PDP-Kontextes, der eine zweite Dienstgüte für die Kommunikationssitzung identifiziert, wobei die zweite Dienstgüte von der ersten Dienstgüte verschieden ist, die von dem primären PDP-Kontext geliefert wird.
Verfahren nach Anspruch 1, das weiterhin den Empfang (510) einer Anforderungs-Mitteilung für das Aktivieren des sekundären-PDP-Kontextes von der mobilen Einheit (12) umfasst, um den sekundären Kontext festzulegen, wobei die Anforderungs-Mitteilung für das Aktivieren des sekundären-PDP-Kontextes ein Dienstgüte-Profil für den zweiten Kontext enthält.
Verfahren nach Anspruch 2, wobei das Senden der Anzeige das Senden (508) eine Mitteilung für das Anfordern der sekundären PDP-Aktivierung umfasst.
Verfahren nach Anspruch 1, das weiterhin die Durchführung einer Netzwerk initiierten sekundären Kontext-Aktivierungs-Prozedur als Antwort auf die Antwort-Mitteilung umfasst.
Verfahren nach Anspruch 1, bei dem der Empfang der Mitteilung von dem Gerät (30, 40) den Empfang einer Mitteilung von einer Medien-Überleiteinrichtung einschließt.
Verfahren nach Anspruch 1, bei dem der Empfang der Mitteilung von dem Gerät (30, 40) den Empfang einer Mitteilung von einem QoS- (Dienstgüte-) Verwaltungsmodul einschließt.
Verfahren nach Anspruch 1, das weiterhin den Empfang einer zweiten Mitteilung umfasst, die von der mobilen Einheit (12) ausgeht, die Information bezüglich der Reservierung von Netzwerk-Ressourcen mit einer dritten Dienstgüte enthält.
Verfahren nach Anspruch 7, das weiterhin das Senden einer weiteren Anzeige an die mobile Einheit (12) zum Aufbau eines weiteren sekundären Kontextes als Antwort auf die zweite Mitteilung umfasst.
Verfahren nach Anspruch 1, bei dem der Empfang der von der mobilen Einheit (12) ausgehenden RSVP PATH-Mitteilung den Empfang einer RSVP PATH-Mitteilung einschließt, die Information enthält, die einer ersten QoS-fähigen Anmeldung zugeordnet ist die auf der mobilen Einheit (12) abläuft.
Verfahren nach Anspruch 9 das weiterhin den Empfang einer zweiten von der mobilen Einheit (12) ausgehenden Mitteilung umfasst, die Information enthält, die einer zweiten QoS-fähigen Anwendung zugeordnet ist, um Netzwerk-Ressourcen mit einer dritten Dienstgüte zu reservieren.
Verfahren nach Anspruch 10, das weiterhin das Aktivieren erster und zweiter sekundärer PDP-Kontexte als Antwort auf die ersten und zweiten Mitteilungen umfasst.
Verfahren nach Anspruch 11, das weiterhin die Ausführung mehrfacher Datenströme entsprechend den zweiten und dritten Dienstgüten umfasst, die von den ersten und zweiten sekundären PDP-Kontexten geliefert werden.
Verfahren nach Anspruch 1, bei dem das Senden der Anzeige zum Aufbau des sekundären Kontextes durch einen Versorgungs-GPRS-Unterstützungsknoten SGSN ausgeführt wird.
Verfahren nach Anspruch 1 bei dem das Senden der Anzeige zum Aufbau des sekundären Kontextes von einem Überleiteinrichtungs-GPRS-Unterstützungsknoten GGSN ausgeführt wird.
Verfahren nach Anspruch 1, das weiterhin die Durchführung einer die Durchführung einer Verbindungszulassung auf der Grundlage der Antwort-Mitteilung umfasst.
Programmprodukt, das ein oder mehrere maschinenlesbare Speichermedien umfasst, die Befehle zum Aufbau eines Datenstroms enthalten, der einem primären PDP-Kontext zugeordnet ist, der eine erste Dienstgüte hat, wobei die Befehle bewirken, dass eine mobile Einheit (12) ein Verfahren ausführt, dadurch gekennzeichnet, dass das Verfahren Folgendes umfasst: Aufbau des Datenstroms mit einem entfernt angeordneten Endgerät (33), das mit einem leitungsvermittelten Netzwerk (12) verbunden ist; Senden (404) einer Ressourcen-Reservierungsprotokoll-, RSVP, PATH-Mitteilung, die ein Verkehrsprofil für den Datenstroms identifiziert; und Empfangen (508) einer vom Netzwerk erzeugten Anzeige zum Aufbau eines sekundären PDP-Kontextes für den Datenstrom, wobei der sekundäre PDP-Kontext einen zweiten Dienstgüte-Wert ergibt, der von dem ersten Dienstgüte-Wert verschieden ist, wobei die vom Netzwerk erzeugte Anzeige eine Antwort auf eine Antwort-Mitteilung auf die RSVP PATH-Mitteilung ist.
Programmprodukt nach Anspruch 16, bei dem das Verfahren weiterhin die Ausbildung des den ersten Dienstgüte-Wert ergebenden primären Kontextes umfasst, wobei der primäre Kontext einen PDP-Kontext umfasst.
Programmprodukt nach Anspruch 17, bei dem das Verfahren weiterhin die Ausbildung eines weiteren PDP-Kontextes umfasst, der einen dritten Dienstgüte-Wert ergibt.
Programmprodukt nach Anspruch 18 bei dem das Verfahren weiterhin die Ausführung von unterschiedliche Dienstgüten aufweisenden Datenströmen unter Verwendung der Dienstgüte-Werte umfasst, die sich aus den sekundären PDP-Kontexten ergeben.
Programmprodukt nach Anspruch 16, bei dem der Empfang der vom Netzwerk erzeugten Anzeige den Empfang der Anzeige als Teil einer von einem Netzwerk initiierten sekundären Kontext-Aktivierungs-Prozedur umfasst, die als Antwort auf eine Antwort-Mitteilung auf die RSVP PATH-Mitteilung initiiert wird.
Programmprodukt nach Anspruch 16, bei dem der Empfang der Anzeige den Empfang (220) einer Modifiziere-PDP-Kontext-Mitteilung umfasst.
Programmprodukt nach Anspruch 16, bei dem das Verfahren weiterhin das Senden (510) einer Anforderungs-Mitteilung für das Aktivieren des sekundären PDP-Kontextes umfasst.
Programmprodukt nach Anspruch 22, bei dem der Empfang der Anzeige den Empfang (508) einer Fordere-Sekundäre-PDP-Kontext-Aktivierungs-Mitteilung von einem SGSN umfasst.
System zur Verwendung in einem Kommunikations-Netzwerk, das ein paketbasiertes drahtloses Netzwerk und ein leitungsvermitteltes Netzwerk (32) umfasst, mit: einer Steuereinrichtung (22, 24), die zum Aufbau einer Kommunikationssitzung mit einer erste Dienstgüte zwischen einer mobilen Einheit (12), die mit dem paketbasierten drahtlosen Netzwerk verbunden ist, und einem Endgerät (33) ausgebildet ist, das mit dem leitungsvermittelten Netzwerk (32) verbunden ist, wobei die erste Dienstgüte in einem primären Kontext definiert ist, dadurch gekennzeichnet, dass: die Steuereinrichtung (22, 24) weiterhin so ausgebildet ist, dass sie eine Ressourcen-Reservierungsprotokoll-, RSVP, PATH-Mitteilung von der mobilen Einheit (12) empfängt (404), die Informationen bezüglich der Dienstgüte enthält, und dass sie eine Anzeige an die mobile Einheit (12) sendet (508), um einen sekundären PDP-Kontext zu schaffen, der eine zweite unterschiedliche Dienstgüte definiert.
System nach Anspruch 24 bei dem die Steuereinrichtung zur Kommunikation einer RSVP-Signalisierung mit einem Modul ausgebildet ist, das dem Endgerät zugeordnet ist.
System nach Anspruch 24, bei dem die Steuereinrichtung so ausgebildet ist, dass sie eine Antwort-Mitteilung empfängt, die eine Antwort auf die RSVP PATH-Mitteilung darstellt, und eine Netzwerk initiierte sekundäre Kontext-Aktivierungs-Prozedur als Antwort auf die Antwort-Mitteilung ausführt.
System nach Anspruch 24, bei dem die PATH-Mitteilung Sender_Tspec-Information enthält, die ein Feld zur Identifikation eines Codec enthält.
System nach Anspruch 24, bei dem die PATH-Mitteilung Sender_Tspec-Information enthält, die ein MPLS-Datenfluss-Etikett zur Identifikation eines Ende-zu-Ende-Datenflusses aufweist.
System nach Anspruch 24, bei dem die PATH-Mitteilung Sender_Tspec-Information mit einem IPv6-Datenstrom-Etikett aufweist.