DE202007019449U1 - Mobilkommunikationssystem - Google Patents

Mobilkommunikationssystem Download PDF

Info

Publication number
DE202007019449U1
DE202007019449U1 DE202007019449U DE202007019449U DE202007019449U1 DE 202007019449 U1 DE202007019449 U1 DE 202007019449U1 DE 202007019449 U DE202007019449 U DE 202007019449U DE 202007019449 U DE202007019449 U DE 202007019449U DE 202007019449 U1 DE202007019449 U1 DE 202007019449U1
Authority
DE
Germany
Prior art keywords
sgsn
ggsn
tunnel
rnc
payload
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE202007019449U
Other languages
English (en)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=38992401&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE202007019449(U1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of DE202007019449U1 publication Critical patent/DE202007019449U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/12Setup of transport tunnels

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Measurement Of Radiation (AREA)

Abstract

Mobilkommunikationssystem der dritten Generation, zum Bestimmen, dass ein Serving General Packet Radio Service Support Node, SGSN, einen Direkttunnel durch einen Gateway General Packet Radio Service Support Node, GGSN, in einer Paketdomäne gestartet hat, wobei das Mobilkommunikationssystem der dritten Generation Endgeräte, einen Radio Network Controller, RNC, den SGSN und den GGSN umfasst, wobei im SGSN ein Markierungseinstellungsmodul hinzugefügt ist und im GGSN ein Markierungsbestimmungsmodul hinzugefügt ist, wobei: das Markierungseinstellungsmodul im SGSN zum Einstellen einer Direkttunnelmarkierung in einer Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext verwendet wird, die nach dem Starten eines Direkttunnelschemas in einem Tunnelherstellungsverfahren an den GGSN gesendet wird, um anzuzeigen, ob der SGSN den Direkttunnel gestartet hat; und das Markierungsbestimmungsmodul im GGSN zum Bestimmen, ob die empfangene Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext die Direkttunnelmarkierung aufweist, und wenn dies der Fall ist, zum Anzeigen, dass der SGSN den Direkttunnel gestartet hat, verwendet wird.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung betrifft eine Paketdomäne in einem Mobilkommunikationssystem der dritten Generation und insbesondere ein System zum Bestimmen, dass ein SGSN einen Direkttunnel durch ein GGSN in einer Paketdomäne gestartet hat.
  • STAND DER TECHNIK
  • General Packet Radio Service (GPRS) ist ein Mobilkommunikationsnetz der zweiten Generation, das auf Paketvermittlung basiert, und die entsprechenden Normen werden durch das Europäische Institut für Telekommunikationsnormen (ETSI) aufgestellt. Im Mobilkommunikationssystem der dritten Generation entwickelt sich GPRS zu einer UMTS-PS-Paketvermittlungsdomäne (Universal Mobile Telecommunication System Packet Switch – UMTS PS). Die Netzarchitektur für UMTS PS gemäß dem Stand der Technik wird wie in 1 gezeigt bereitgestellt. Die Netzarchitektur umfasst die folgenden Netzelemente:
    einen NodeB zum Bereitstellen einer Funkverbindung für ein Endgerät;
    einen Radio Network Controller (RNC), der hauptsächlich für das Verwalten der Funkressource und für das Steuern des NodeB verwendet wird, wobei sowohl der NodeB als auch der Radio Network Controller allgemein als Radio Network System (RNS) bezeichnet werden, wobei der RNC über eine Iub-Schnittstelle mit dem NodeB verbunden ist und ein Endgerät mit einem Packet Core Network des UMTS verbunden ist;
    einen Serving GPRS Support Node (SGSN), der zum Speichern von Positionsinformationen eines Routing-Bereichs eines Benutzers verwendet wird und für die Sicherheit und die Zugriffskontrolle verantwortlich ist, wobei der SGSN durch eine Iu-Schnittstelle mit dem Radio Network System verbunden ist und die Iu-Schnittstelle eine Iu-C-Schnittstelle und eine Iu-U-Schnittstelle umfasst;
    einen Gateway GPRS Support Node (GGSN), der zum Vergeben von IP-Adressen an die Endgeräte verwendet wird und als ein Gateway zu einem externen Netz wirkt, wobei der GGSN intern durch eine Gn-C-Schnittstelle und eine Gn-U-Schnittstelle mit dem SGSN verbunden ist;
    ein Home Location Register (HLR), das zum Speichern von Vertragsdaten für die Benutzer und ihrer aktuellen SGSN-Adresse verwendet wird, wobei das HLR über eine Gr-Schnittstelle mit dem SGSN und über eine Gc-Schnittstelle mit dem GGSN verbunden ist;
    ein Packet Data Network (PDN), das verwendet wird, um den Benutzern ein paketbasiertes Dienstnetz bereitzustellen, wobei das PDN über eine Gi-Schnittstelle mit dem GGSN verbunden ist.
  • Die in 1 gesendeten Daten werden in zwei Arten unterteilt, die Daten einer Benutzerebene und die Daten einer Signalisierungsebene. Die Benutzerebene wird hauptsächlich für das Senden von Dienstdaten für den Benutzer verwendet und die Signalisierungsebene wird hauptsächlich für das Verwalten der Benutzerebene einschließlich Herstellen, Freigeben und Ändern der Nutzdaten verwendet. Ein Nutzdatenpfad von einem User Equipment (UE) zum PDN im UMTS-PS-System durchläuft 3 Netzelemente: den RNC, den SGSN und den GGSN. Dementsprechend sind zwei Tunnel vorhanden: einer von dem RNC zum SGSN und der andere vom SGSN zum GGSN. Dies wird daher als Doppeltunnelschema bezeichnet. Beide Tunnel gründen auf dem GPRS Tunneling Protocol (GTP) und werden auch GTP-U-Tunnel genannt.
  • Mit der fortschreitenden Entwicklung des IP Multimedia Subsystem (IMS) Dienstes und der Erweiterung anderer Multimedia-Dienste weisen die Dienste zunehmend hohe Anforderungen an die Verzögerung und die Leistung der Transportschicht auf. Daher führt die Organisation Third Generation Partnership Project (SGPP) eine Studie zur Trennung des SGSN vom Nutzdatenpfad als einzelnes Netzelement der Signalisierungsdaten durch. Die Nutzdaten umfassen nur einen Tunnel: den direkten Tunnel GTP-U vom RNC zum GGSN. Dies wird auch als Direkttunnelschema bezeichnet, wie in 2 gezeigt.
  • Im Vergleich zum Doppeltunnelschema ist das Direkttunelschema für die Sendung von Multimedia-Diensten vorteilhafter, da es in den Nutzdaten einen Knoten weniger aufweist und die Datenverzögerung daher geringer ist. Manchmal ist indes das Doppeltunnelschema erforderlich, insbesondere, wenn der SGSN den Zustand der Daten für die Nutzdaten kennen muss, wie zum Beispiel, wenn der Benutzer roamt und sich zum GGSN begeben muss, zu dem er gehört, wenn Nutzdaten gesetzlich durch den SGSN überwacht werden müssen, wenn der Benutzer einen intelligenten Dienst besitzt und wenn der GGSN kein Direkttunnelschema unterstützt, bestimmt der SGSN, ob das Direkttunnelschema oder das Doppeltunnelschema zu verwenden ist.
  • Wie in 3 gezeigt, wird eine Methode zum Herstellen eines Direkttunnels gemäß der vorliegenden Schrift beschrieben; die Methode umfasst die folgenden Schritte:
    Schritt 301: Das Endgerät UE 10 leitet durch den RNC 20 eine Anforderung zum Aktivieren eines Packet-Data-Protocol-Kontexts (PDP) an den SGSN 30 ein;
    Schritt 302: Der SGSN 30 erhält nach dem Untersuchen eines unterzeichneten Vertrags eine Adresse des GGSN 40. Der SGSN 30 verteilt Nutzdaten-Tunnelinformationen und leitet dann eine Anforderung zum Erzeugen des PDP-Kontexts mit der Adresse und den verteilten Nutzdaten-Tunnelinformationen des SGSN 30 an den GGSN 40 ein;
    Schritt 303: Der GGSN 40 speichert nach dem Erzeugen der PDP-Kontextanforderung die Adresse und die Nutzdaten-Tunnelinformationen des SGSN 30 zum Erzeugen von PDP-Kontext;
    Schritt 304: Der GGSN 40 verteilt als Reaktion auf das Erzeugen eines PDP-Kontexts seine Nutzdaten-Tunnelinformationen und sendet die Informationen gemeinsam mit der Adresse des GGSN 40 an den SGSN 30;
    Schritt 305: Der SGSN 30 speichert die Adresse und die Nutzdaten-Tunnelinformationen des GGSN 40 und bestimmt dann, ob das Direkttunnelschema zu verwenden ist. In den Fällen, in denen der Benutzer roamt, eine gesetzliche Überwachung erforderlich ist, der Benutzer ein intelligenter Benutzer ist und so weiter, ist das Doppeltunnelschema erforderlich;
    Schritt 306: Wenn der SGSN 30 entscheidet, das Direkttunnelschema zu verwenden, wird ein Radio-Access-Bearer-Zuweisungsverfahren (RAB) eingeleitet, um dem RNC 20 anzuzeigen, den Radio Bearer herzustellen. Der SGSN 30 sendet eine RAB-Zuweisungsanforderungsnachricht mit der Adresse und den Nutzdaten-Tunnelinformationen des GGSN 40 an den RNC 20;
    Schritt 307: der RNC 20 kennt nach dem Empfangen der RAB-Zuweisungsanforderungsnachricht die Adresse und die Nutzdateninformationen des GGSN 40. Der RNC 20 fährt fort, um das RAB-Zuweisungsverfahren zum Abschluss zu bringen und verteilt Tunnelnummern des RNC 20. Nachdem dies beendigt wurde, wird eine RAB-Zuweisungsantwort mit der Adresse und den verteilten Nutzdaten-Tunnelinformationen des RNC 20 an den SGSN 30 zurückgesendet.
    Schritt 308: Der SGSN 30 bestimmt, dass das Direkttunnelschema gestartet wurde, und sendet die Adresse und die Nutzdaten-Tunnelinformationen des RNC 20 in der Anforderungsnachricht zum Aktualisieren von PDP-Kontext an den GGSN 40;
    Schritt 309: Nachdem sie durch den GGSN 40 empfangen wurde, ersetzen die Adresse und die Nutzdaten-Tunnelinformationen des RNC 20 die vorhergehend gespeicherte/n Adresse und Nutzdaten-Tunnelinformationen des SGSN 30. So wird der GTP-U-Tunnel zwischen dem RNC 20 und dem GGSN 40 hergestellt;
    Schritt 310: Der GGSN 40 sendet die Antwort des Aktualisierens von PDP-Kontext an den SGSN 30 zurück;
    Schritt 311: Der SGSN 30 sendet die Antwort des Aktivierens von PDP-Kontext an das Endgerät UE 10 zurück, um den PDP-Kontext erfolgreich zu aktivieren.
  • Im vorhergehend beschriebenen Direkttunnelschema hat das Schema, da beim Erzeugen und Aktualisieren einer PDP-Kontextnachricht keine Änderung erforderlich ist, keine Auswirkung auf den GGSN 40 und der GGSN 40 muss nicht aufgerüstet werden. In dem Schema ist indes ein Problem vorhanden: Der GGSN 40 ist nicht in der Lage, zu wissen, ob der SGSN 30 das Direkttunnelschema verwendet hat oder ob er immer noch das Doppeltunnelschema verwendet. In einigen Fällen muss dies bekannt sein, zum Beispiel muss der GGSN 40, wenn der GGSN 40 eine Fehleranzeigenachricht für die Nutzdaten verarbeitet, wissen, ob diese Fehleranzeigenachricht vom RNC 20 (für das Direkttunnelschema) oder vom SGSN 30 (für das Doppeltunnelschema) kommt. Der GGSN 40 weist für diese zwei Fälle unterschiedliche Verarbeitungsverfahren auf.
  • Aus diesem Grund besteht ein Bedarf an einer Lösung, die die Anforderungsnachricht zum Aktualisieren von PDP-Kontext ändert, damit der GGSN 40 wissen kann, ob der SGSN 30 den Direkttunnel gestartet hat.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Ein technisches Problem, das durch die vorliegende Erfindung zu lösen ist, ist das Bereitstellen eines Systems zum Bestimmen, dass der SGSN einen Direkttunnel durch den GGSN in einer Paketdomäne gestartet hat, um so den Nachteil zu beseitigen, dass der Gateway GPRS Support Node des Stands der Technik nicht in der Lage ist, zu wissen, ob der Serving GPRS Support Node den Direkttunnel gestartet hat.
  • Zum Lösen des vorhergehend beschriebenen technischen Problems stellt die vorliegende Erfindung zuerst eine Methode zum Bestimmen, dass der SGSN einen Direkttunnel durch den GGSN in einer Paketdomäne gestartet hat, bereit, und die Methode wird auf das Mobilkommunikationssystem der dritten Generation angewandt, das Endgeräte, einen Radio Network Controller (RNC), einen Serving GPRS Support Node (SGSN) und einen Gateway GPRS Support Node (GGSN) umfasst, wobei die Methode die folgenden Schritte umfasst:
    Markierung einstellen: In einem Tunnelherstellungsverfahren, Einstellen einer Direkttunnelmarkierung in einer Anforderungsnachricht zum Aktualisieren von an den Gateway GPRS Support Node gesendetem Packet-Data-Protocol-Kontext, zum Anzeigen, ob ein Serving GPRS Support Node den Direkttunnel gestartet hat, wenn der Serving GPRS Support Node ein Direkttunnelschema gestartet hat;
    Markierung bestimmen: Anzeigen, dass der Serving GPRS Support Node den Direkttunnel gestartet hat und die in der Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext enthaltene/n Adresse und Nutzdaten-Tunnelinformationen des Radio Network Controllers bestimmt, wenn der Gateway GPRS Support Node bestimmt, dass die empfangene Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext die Direkttunnelmarkierung aufweist.
  • In der vorhergehend beschriebenen Methode umfasst der Schritt des Einstellens der Markierung das Einstellen verschiedener Werte der Direkttunnelmarkierung in Abhängigkeit davon, ob die Nutzdaten-Tunnelinformation der Doppeltunnel gelöscht oder reserviert ist, wenn der GPRS Support Node den Direkttunnel gestartet hat.
  • Ferner umfasst der Schritt des Bestimmens der Markierung im vorhergehend beschriebenen Verfahren das Bestimmen des Werts der Direkttunnelmarkierung, wobei, wenn der Wert der Direkttunnelmarkierung anzeigt, dass der Serving GPRS Support Node die Nutzdaten-Tunnelinformation der Doppeltunnels gelöscht hat, der Gateway GPRS Support Node die gespeicherte Nutzdaten-Tunnelinformation des Serving GPRS Support Node löscht; und wenn der Wert der Direkttunelmarkierung anzeigt, dass der Serving GPRS Support Node die Nutzdaten-Tunnelinformation der Doppeltunnel reserviert hat, dann reserviert der Gateway GPRS Support Node die gespeicherte/n Adresse und Nutzdaten-Tunnelinformation des Serving GPRS Support Node.
  • Ferner empfängt der Gateway GPRS Support Node im vorhergehend beschriebenen Verfahren nach dem Schritt des Bestimmens der Markierung, wenn der Serving GPRS Support Node den Direkttunnel gestartet hat und die Nutzdaten-Tunnelinformationen der Doppeltunnel reserviert hat, eine durch den Radio Network Controller gesendete Fehleranzeige und verarbeitet sie.
  • Ferner umfasst der Schritt des Empfangens und Verarbeitens der durch den Radio Network Controller gesendeten Fehleranzeige durch den Gateway GPRS Support Node im vorhergehend beschriebenen Verfahren ferner Folgendes:
    Schritt 51: Der Gateway GPRS Support Node sendet durch einen GTP-U-Tunnel ein Downlink-Paket an den Radio Network Controller;
    Schritt 52: Wenn im Radio Network Controller eine Anomalie auftritt und der entsprechende Kontext nicht gefunden werden kann, sendet der Radio Network Controller eine Fehleranzeige, die erste Fehleranzeige genannt wird, an den Gateway GPRS Support Node zurück;
    Schritt 53: Der Gateway GPRS Support Node empfängt die durch den Radio Network Controller zurückgesendete erste Fehleranzeige, löscht die Adresse und die Nutzdaten-Tunnelinformationen des Radio Network Controllers und verwendet die Adresse und die Nutzdaten-Tunnelinformationen des Serving GPRS Support Node.
  • Ferner umfasst die vorhergehend beschriebene Methode nach dem Schritt 53 Folgendes:
    Schritt 61: Der Gateway GPRS Support Node empfängt das Downlink-Paket erneut und sendet es an den Serving GPRS Support Node, dann leitet der Serving GPRS Support Node das Downlink-Paket an den Radio Network Controller weiter;
    Schritt 62: Wenn im Radio Network Controller eine Anomalie auftritt und der entsprechende Radio Access Bearer nicht gefunden werden kann, sendet der Radio Network Controller eine Fehleranzeige, die zweite Fehleranzeige genannt wird, an den Serving GPRS Support Node;
    Schritt 63: Der Gateway GPRS Support Node empfängt die durch den Radio Network Controller zurückgesendete zweite Fehleranzeige, löscht den Radio Access Bearer und reserviert Packet-Data-Protocol-Kontext.
  • Zusätzlich stellt die vorliegende Erfindung auch ein Mobilkommunikationssystem der dritten Generation zum Bestimmen, dass der SGSN einen Direkttunnel durch den GGSN in einer Paketdomäne gestartet hat, bereit. Das Mobilkommunikationssystem der dritten Generation umfasst Endgeräte, einen Radio Network Controller (RNC), einen Serving GPRS Support Node (SGSN) und einen Gateway GPRS Support Node (GGSN), wobei ein Markierungseinstellungsmodul im Serving GPRS Support Node hinzugefügt ist, und ein Markierungsbestimmungsmodul im Gateway GPRS Support Node hinzugefügt ist, wobei:
    das Markierungseinstellungsmodul im Serving GPRS Support Node zum Einstellen einer Direkttunnelmarkierung in einer Anforderungsnachricht zum Aktualisieren von nach dem Starten des Direkttunnelschemas im Tunnelherstellungsverfahren an den Gateway GPRS Support Node gesendetem Packet-Data-Protocol-Kontext verwendet wird, um anzuzeigen, ob der Serving GPRS Support Node den Direkttunnel gestartet hat;
    das Markierungsbestimmungsmodul im Gateway GPRS Support Node verwendet wird, um zu bestimmen, ob die empfangene Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext die Direkttunnelmarkierung aufweist und, wenn dies der Fall ist, anzuzeigen, dass der Serving GPRS Support Node den Direkttunnel gestartet hat.
  • In dem System gemäß der vorliegenden Erfindung, stellt das Markierungseinstellungsmodul im Serving GPRS Support Node ferner verschiedene Werte der Direkttunnelmarkierung in Abhängigkeit davon ein, ob der Serving GPRS Support Node die Nutzdaten-Tunnelinformationen der Doppeltunnel gelöscht oder reserviert hat.
  • Ferner bestimmt im System gemäß der vorliegenden Erfindung das Markierungsbestimmungsmodul im Gateway GPRS Support Node gemäß dem Wert der Direkttunnelmarkierung, ob der Serving GPRS Support Node die Nutzdaten-Tunnelinformationen der Doppeltunnel gelöscht hat.
  • Gemäß der vorliegenden Erfindung wird in der Anforderungsnachricht zum Aktualisieren des Packet-Data-Protocol-Kontexts eine Direkttunnelmarkierung eingestellt, die angibt, ob der Serving GPRS Support Node den Direkttunnel gestartet hat. Wenn der Gateway GPRS Support Node die Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext empfängt, bestimmt der Gateway GPRS Support Node, dass der Serving GPRS Support Node den Direkttunnel gestartet hat, wenn die Anforderungsnachricht zum Aktualisieren des Paket-Data-Protocol-Kontexts die Direkttunnelmarkierung aufweist.
  • Darüber hinaus kann gemäß der vorliegenden Erfindung durch die Direkttunnelmarkierung bestimmt werden, ob der Serving GPRS Support Node die vorhergehend verteilten Nutzdaten-Tunnelinformationen reserviert.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Diagramm einer Doppeltunnel-Systemarchitektur von UMTS/GPRS des Standes der Technik;
  • 2 ist ein Diagramm einer Direkttunnel-Systemarchitektur von UMTS/GPRS des Standes der Technik;
  • 3 ist ein Diagramm der Methode zur Nutzdatenherstellung des Direkttunnelschemas des Standes der Technik;
  • 4 ist eine Ausführungsform einer Methode zur Herstellung eines Direkttunels;
  • 5 ist eine Ausführungsform einer Verarbeitungsmethode, wenn der GGSN eine Fehleranzeige empfängt.
  • BEVORZUGTE AUSFÜHRUNGSFORMEN DER ERFINDUNG
  • Die vorliegende Erfindung wird unten im Zusammenhang mit den Figuren und den spezifischen Ausführungsformen beschrieben, mit denen nicht die Einschränkung der vorliegenden Erfindung beabsichtigt wird.
  • Immer noch wie in 2 gezeigt, umfasst das Mobilkommunikationssystem der dritten Generation gemäß der vorliegenden Erfindung Endgeräte, einen Radio Network Controller (RNC), einen Serving GPRS Support Node (SGSN) und einen Gateway GPRS Support Node (GGSN). Zum Bestimmen, dass der SGSN einen Direkttunnel durch den GGSN in einer Paketdomäne gestartet hat, müssen ein Markierungseinstellungsmodul im SGSN hinzugefügt und ein Markierungsbestimmungsmodul im GGSN eingesetzt werden, wobei:
    das Markierungseinstellungsmodul im SGSN verwendet wird, um eine Direkttunnelmarkierung in einer nach dem Starten eines Direkttunnelschemas im Tunnelherstellungsverfahren an den GGSN gesendeten Anforderungsnachricht zum Aktualisieren von PDP-Kontext einzustellen, um anzuzeigen, ob der SGSN den Direkttunnel gestartet hat, und verschiedene Werte für die Direkttunnelmarkierung in Abhängigkeit davon einzustellen, ob der SGSN Nutzdaten-Tunnelinformation von Doppeltunneln gelöscht oder reserviert hat,
    das Markierungsbestimmungsmodul in dem GGSN verwendet wird, um zu bestimmen, ob die empfangene Anforderungsnachricht zum Aktualisieren von PDP-Kontext die Direkttunnelmarkierung aufweist und, wenn dies der Fall ist, anzugeben, dass der SGSN den Direkttunnel gestartet hat; und ferner, um in Abhängigkeit von dem Wert der Direkttunnelmarkierung zu bestimmen, ob der SGSN die Nutzdaten-Tunnelinformation der Doppeltunnel gelöscht hat, und ein Dienstverarbeitungsmodul des GGSN zu informieren.
  • Das Dienstverarbeitungsmodul des GGSN erhält eine Adresse und Nutzdaten-Tunnelinformationen von dem in der Anforderungsnachricht zum Aktualisieren von PDP-Kontext enthaltenen RNC, und löscht, nachdem es weiß, dass der SGSN den Direkttunnel gestartet hat, die lokal gespeicherten Nutzdaten-Tunnelinformation des SGSN, wenn es weiß, dass der SGSN die Nutzdaten-Tunnelinformation der Doppeltunnel gelöscht hat, und reserviert die lokal gespeicherte/n Adresse und Nutzdaten-Tunnelinformation des SGSN, wenn es weiß, dass der SGSN die Nutzdaten-Tunnelinformation der Doppeltunnel reserviert hat, das heißt, zu diesem Zeitpunkt reserviert der GGSN die Adressen und die Nutzdaten-Tunnelinformationen von sowohl dem SGSN als auch dem RNC.
  • Wie in 4 gezeigt, wird eine Ausführungsform der Methode des Herstellens eines Direkttunnels bereitgestellt. In dieser Ausführungsform kann der GGSN wissen, ob der SGSN den Direkttunnel gestartet hat.
  • Eine Direkttunnelmarkierung, die anzeigt, ob der SGSN 30 den Direkttunnel gestartet hat, wird in der Anforderungsnachricht zum Aktualisieren des PDP-Kontexts hinzugefügt.
  • Wenn der GGSN 40 die Anforderungsnachricht zum Aktualisieren von PDP-Kontext empfängt, bestimmt der GGSN 40, dass der SGSN 30 den Direkttunnel gestartet hat, wenn die empfangene Nachricht die Direkttunnelmarkierung aufweist. Dann weiß der GGSN 40, dass die Adresse und die Nutzdaten-Tunnelinformationen des RNC 20 in der Anforderungsnachricht zum Aktualisieren von PDP-Kontext enthalten sind.
  • Darüber hinaus zeigt die Direkttunnelmarkierung, wenn die Direkttunnelmarkierung anzeigt, dass der Direkttunnel gestartet wurde, auch an, ob die Nutzdaten-Tunnelinformationen von Doppeltunneln im SGSN 30 gespeichert sind und der GGSN 40 bestimmt in Abhängigkeit von der Direkttunnelmarkierung, ob die vorhergehend gespeicherten Nutzdaten-Tunnelinformationen des SGSN 30 zu reservieren oder zu löschen sind.
  • Gemäß der vorhergehenden Beschreibung weist die Anforderungsnachricht zum Aktualisieren von PDP-Kontext die Direkttunnelmarkierung auf, wenn der Direkttunnel gestartet wurde; darüber hinaus kann die Direkttunnelmarkierung bestimmen, ob der SGSN 30 die vorhergehend verteilten Nutzdaten-Tunnelinformationen reserviert. Die Herstellungsmethode umfasst die folgenden Schritte:
    Schritt 401: Das Endgerät UE 10 leitet durch den RNC 20 eine Anforderung zum Aktivieren eines Packet-Data-Protocol-Kontexts (PDP) an den SGSN 30 ein;
    Schritt 402: Der SGSN 30 beschafft nach dem Untersuchen eines unterzeichneten Vertrags eine Adresse des GGSN 40. Der SGSN 30 verteilt Nutzdaten-Tunnelinformationen und leitet dann eine Anforderung zum Erzeugen des PDP-Kontexts mit der Adresse und den verteilten Nutzdaten-Tunnelinformationen des SGSN 30 ein;
    Schritt 403: Der GGSN 40 speichert nach dem Erzeugen der PDP-Kontextanforderung die Adresse und die Nutzdaten-Tunnelinformationen des SGSN 30 zum Erzeugen von PDP-Kontext;
    Schritt 404: Der GGSN 40 verteilt die Nutzdaten-Tunnelinformationen und sendet die Informationen in der Antwort des Erzeugens eines PDP-Kontexts gemeinsam mit der Adresse des GGSN 40 an den SGSN 30;
    Schritt 405: Der SGSN 30 speichert die Nutzdaten-Tunnelinformationen des GGSN 40 und bestimmt dann, ob der Direkttunnel zu verwenden ist. In den Fällen, in denen der Benutzer roamt, eine Überwachung gesetzlich erforderlich ist und der Benutzer ein intelligenter Benutzer ist, ist das Doppeltunnelschema erforderlich;
    Schritt 406: Wenn der SGSN 30 entscheidet, das Direkttunnelschema zu verwenden, wird ein Radio-Access-Bearer-Zuweisungsverfahren (RAB) eingeleitet, um dem RNC 20 anzugeben, den Radio Bearer herzustellen. Der SGSN 30 sendet die Adresse und die Nutzdaten-Tunnelinformationen des GGSN 40 in einer RAB-Zuweisungsanforderungsnachricht an den RNC 20;
    Schritt 407: Der RNC 20 kennt nach dem Empfangen der RAB-Zuweisungsanforderungsnachricht die Adresse und die Nutzdaten-Tunnelinformationen des GGSN 40. Der RNC 20 fährt fort, um das RAB-Zuweisungsverfahren zum Abschluss zu bringen und verteilt Tunnelnummern des RNC 20. Nachdem dies durchgeführt wurde, wird eine RAB-Zuweisungsantwort mit der Adresse und den verteilten Nutzdaten-Tunnelinformationen des RNC 20 an den SGSN 30 zurückgesendet.
    Schritt 408: Wenn der SGSN 30 bestimmt, dass das Direkttunnelschema gestartet wurde, wird die Direkttunnelmarkierung in die Anforderungsnachricht zum Aktualisieren von PDP-Kontext durch das Markierungseinstellungsmodul im SGSN 30 eingeschlossen. In Abhängigkeit von der Betriebs- und Geschäftsstrategie bestimmt der SGSN 30, ob die in Schritt 402 verteilten Nutzdaten-Tunnelinformationen der Doppeltunnel zu löschen sind und stellt unter Verwendung seines Markierungseinstellungsmoduls verschiedene Werte der Direkttunnelmarkierung ein. Der SGSN 30 sendet den Wert der Direkttunnelmarkierung gemeinsam mit der Adresse und den Nutzdaten-Tunnelinformationen des RNC 20 in der Anforderungsnachricht zum Aktualisieren von PDP-Kontext an den GGSN 40;
    Schritt 409: Nachdem der GGSN 40 die vorhergehenden Informationen empfangen hat, bestimmt sein Markierungsbestimmungsmodul, dass die Direkttunnelmarkierung vorhanden ist, und so weiß GGSN 40, dass SGSN 30 den Direkttunnel gestartet hat, und die in der Anforderungsnachricht eingeschlossene Adresse und Nutzdaten-Tunnelinformation sind vom RNC 20. Wenn der Wert der Direkttunnelmarkierung anzeigt, dass der SGSN 30 die Nutzdaten-Tunnelinformationen der Doppeltunnel gelöscht hat, löscht der GGSN 40 auch die gespeicherte/n Adresse und Nutzdaten-Tunnelinformationen des SGSN 30, und daher behält der GGSN 40 in diesem Fall nur die Adresse und die Nutzdaten-Tunnelinformationen des RNC 20; wenn der Wert der Direkttunnelmarkierung anzeigt, dass der SGSN 30 die Nutzdaten-Tunnelinformationen der Doppeltunnel reserviert hat, reserviert der GGSN 40 auch die Adresse und die Nutzdaten-Tunnelinformationen des SGSN 30, und daher reserviert der GGSN 40 in diesem Fall gleichzeitig die Adressen und die Nutzdaten-Tunnelinformationen des SGSN 30 und des RNC 20; wenn keine Direkttunnelmarkierung vorhanden ist, dann zeigt dies an, dass der SGSN 30 ein Doppeltunnelschema gestartet hat;
    Schritt 410: Der GGSN 40 sendet die Antwort der Aktualisierung von PDP-Kontext an den SGSN 30 zurück;
    Schritt 411: Der SGSN 30 sendet die Antwort des Aktivierens von PDP-Kontext an ein Endgerät zurück, um den PDP-Kontext erfolgreich zu aktivieren.
  • Wie in 5 gezeigt, wird eine Ausführungsform einer Verarbeitungsmethode bereitgestellt, bei dem der GGSN 40 eine Fehleranzeige empfängt, wobei der GGSN eine Fehleranzeige empfängt, wenn der SGSN 30 den Direkttunnel gestartet und die Nutzdaten-Tunnelinformationen der Doppeltunnel reserviert hat. Gemäß der vorliegenden Erfindung:
    Schritt 501: Der GGSN 40 weiß, dass der Direkttunnel gestartet wurde und reserviert gleichzeitig die Adressen und die Nutzdaten-Tunnelinformationen des SGSN 30 und des RNC 20;
    Schritt 502: Der GGSN 40 sendet durch einen GTP-U-Tunnel ein Downlink-Paket an den RNC 20;
    Schritt 503: Wenn im RNC 20 eine Anomalie auftritt und der entsprechende Kontext nicht gefunden werden kann, wird eine Fehleranzeige, die erste Fehleranzeige genannt wird, an den GGSN 40 zurückgesendet;
    Schritt 504: Nachdem der GGSN 40 die Fehleranzeige empfängt, weiß er, dass die Fehleranzeige vom RNC 20 kommt, da er weiß, dass der Direkttunnel gestartet wurde. Der GGSN 40 löscht die Adresse und die Nutzdaten-Tunnelinformationen des RNC 20 und benutzt die Adresse und die Nutzdaten-Tunnelinformationen des SGSN 30. Die darauffolgenden Schritte sind dieselben wie diejenigen für das Doppeltunnelschema;
    Schritt 505: Wenn der GGSN 40 erneut das Downlink-Paket empfängt, sendet er das Downlink-Paket an den SGSN 30;
    Schritt 506: Der SGSN 30 leitet das Downlink-Paket an den RNC 20 weiter;
    Schritt 507: Wenn im RNC 20 eine Anomalie auftritt und der entsprechende RAB nicht gefunden werden kann, wird eine Fehleranzeige, die zweite Fehleranzeige genannt wird, an den SGSN 30 zurückgesendet;
    Schritt 508: Nachdem der GGSN 30 die zweite Fehleranzeige empfängt, löscht er den RAB und behält PDP-Kontext.
  • Die folgenden Schritte sind optional:
    Schritt 509: der SGSN 30 sendet eine RAB-Zuweisungsanforderungsnachricht mit der Adresse und den Nutzdaten-Tunnelinformationen des GGSN 40 zum erneuten Herstellen des RAB;
    Schritt 510: Der RNC 20 bringt das RAB-Zuweisungsverfahren zum Abschluss und verteilt Tunnelnummern des RNC 20; nachdem dies durchgeführt wurde, wird eine RAB-Zuweisungsantwort mit der Adresse und den verteilten Nutzdaten-Tunnelinformationen 20 an den SGSN 30 zurückgesandt;
    Schritt 511: Wenn der SGSN 30 bestimmt, dass das Direkttunnelschema gestartet wurde, sendet es die Direkttunnelmarkierung und die Adresse und die Nutzdaten-Tunnelinformationen des RNC 20 in der Anforderungsnachricht zum Aktualisieren von PDP-Kontext an den GGSN 40;
    Schritt 512: Der GGSN 40 reserviert nach dem Empfang der vorhergehend genannten Informationen die Adresse und die Nutzdaten-Tunnelinformationen des RNC 20;
    Schritt 513: Der GGSN 40 sendet die Antwort des Aktualisierens von PDP-Kontext an den SGSN 30 zurück.
  • Der SGSN 30 stellt mit den vorhergehenden Schritten erneut den Direkttunnel zwischen dem RNC 20 und dem GGSN 40 her.
  • Die vorhergehende Beschreibung betrifft nur die bevorzugten Ausführungsformen der Erfindung und damit wird keine Einschränkung des Schutzumfangs der Erfindung beabsichtigt; es wird beabsichtigt, dass der Schutzumfang der vorliegenden Erfindung sämtliche Äquivalenzen, Varianten und Abwandlungen, die gemäß der vorliegenden Erfindung vorgenommen werden, umfasst.
  • GEWERBLICHE ANWENDBARKEIT
  • Das System gemäß der vorliegenden Erfindung hat den Nachteil beseitigt, dass der GGSN im Stand der Technik nicht in der Lage ist, zu wissen, ob der SGSN den Direkttunnel gestartet hat. Darüber hinaus kann die vorliegende Erfindung bestimmen, ob der SGSN die vorhergehend verteilten Nutzdaten-Tunnelinformationen reserviert, und wird auf das Mobilkommunikationssystem der dritten Generation angewandt, das Endgeräte, einen Radio Network Controller (RNC), einen Serving GPRS Support Node (SGSN) und einen Gateway GPRS Support Node (GGSN) umfasst.

Claims (7)

  1. Mobilkommunikationssystem der dritten Generation, zum Bestimmen, dass ein Serving General Packet Radio Service Support Node, SGSN, einen Direkttunnel durch einen Gateway General Packet Radio Service Support Node, GGSN, in einer Paketdomäne gestartet hat, wobei das Mobilkommunikationssystem der dritten Generation Endgeräte, einen Radio Network Controller, RNC, den SGSN und den GGSN umfasst, wobei im SGSN ein Markierungseinstellungsmodul hinzugefügt ist und im GGSN ein Markierungsbestimmungsmodul hinzugefügt ist, wobei: das Markierungseinstellungsmodul im SGSN zum Einstellen einer Direkttunnelmarkierung in einer Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext verwendet wird, die nach dem Starten eines Direkttunnelschemas in einem Tunnelherstellungsverfahren an den GGSN gesendet wird, um anzuzeigen, ob der SGSN den Direkttunnel gestartet hat; und das Markierungsbestimmungsmodul im GGSN zum Bestimmen, ob die empfangene Anforderungsnachricht zum Aktualisieren von Packet-Data-Protocol-Kontext die Direkttunnelmarkierung aufweist, und wenn dies der Fall ist, zum Anzeigen, dass der SGSN den Direkttunnel gestartet hat, verwendet wird.
  2. System nach Anspruch 1, wobei das Markierungseinstellungsmodul im SGSN ferner zum Einstellen verschiedener Werte der Direkttunnelmarkierung genutzt wird, in Abhängigkeit davon, ob der SGSN die Nutzdaten-Tunnelinformationen von Doppeltunneln gelöscht oder reserviert hat.
  3. System nach Anspruch 1 oder 2, wobei das Markierungsbestimmungsmodul im GGSN ferner zum Bestimmen genutzt wird, ob der SGSN die Nutzdaten-Tunnelinformationen der Doppeltunnel gelöscht hat in Abhängigkeit vom Wert der Direkttunnelmarkierung.
  4. System nach Anspruch 3, wobei der GGSN ferner genutzt wird zum: Löschen der gespeicherten Nutzdaten-Tunnelinformationen des SSGN, wenn der Wert der Direkttunnelmarkierung anzeigt, dass der SGSN die Nutzdaten-Tunnelinformationen der Doppeltunnel gelöscht hat; und Reservieren der gespeicherten Adresse und Nutzdaten-Tunnelinformationen des SGSN, wenn der Wert der Direkttunnelmarkierung anzeigt, das der SGSN die Nutzdaten-Tunnelinformationen der Doppeltunnel reserviert hat.
  5. System nach einem der Ansprüche 1 bis 4, wobei der GGSN ferner genutzt wird zum Empfangen und Verarbeiten einer durch den RNC gesendeten Fehleranzeige, wenn der SGSN den Direkttunnel gestartet und die Nutzdaten-Tunnelinformationen der Doppeltunnel reserviert hat.
  6. System nach Anspruch 5, wobei: der GGSN ferner genutzt wird zum Senden eines Downlink-Pakets an den RNC durch einen GTP-U-Tunnel; der RNC ferner genutzt wird zum Zurücksenden einer Fehleranzeige, die erste Fehleranzeige genannt wird, an den GGSN, wenn im RNC eine Anomalie auftritt und der entsprechende Kontext nicht gefunden werden kann; der GGSN ferner genutzt wird zum Empfangen der durch den RNC zurückgesendeten ersten Fehleranzeige, zum Löschen der Adresse und der Nutzdaten-Tunnelinformationen des RNCs, und zum Verwenden der Adresse und der Nutzdaten-Tunnelinformationen des SGSN.
  7. System nach Anspruch 6, wobei: der GGSN ferner genutzt wird zum erneuten Empfangen des Downlink-Pakets und zum Senden des Downlink-Pakets an den SGSN; der SGSN ferner genutzt wird zum Weiterleiten des Downlink-Pakets an den RNC; der RNC ferner genutzt wird zum Zurücksenden einer Fehleranzeige, die zweite Fehleranzeige genannt wird, an den SGSN, wenn im RNC eine Anomalie auftritt und der entsprechende Radio Access Bearer nicht gefunden werden kann; der GGSN ferner genutzt wird zum Empfangen der durch den RNC zurückgesendeten zweiten Fehleranzeige, zum Löschen des Radio Access Bearer, und zum Reservieren des Packet-Data-Protocol-Kontext.
DE202007019449U 2006-08-18 2007-05-16 Mobilkommunikationssystem Expired - Lifetime DE202007019449U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB2006101124596A CN100486381C (zh) 2006-08-18 2006-08-18 分组域中ggsn获知sgsn启用单隧道信息的方法
CN200610112459 2006-08-18

Publications (1)

Publication Number Publication Date
DE202007019449U1 true DE202007019449U1 (de) 2012-10-11

Family

ID=38992401

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202007019449U Expired - Lifetime DE202007019449U1 (de) 2006-08-18 2007-05-16 Mobilkommunikationssystem

Country Status (5)

Country Link
EP (1) EP2061264B8 (de)
CN (1) CN100486381C (de)
DE (1) DE202007019449U1 (de)
DK (1) DK201200119U1 (de)
WO (1) WO2008022518A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101588570B (zh) * 2008-05-20 2011-06-08 华为技术有限公司 建立用户面单隧道的方法、系统及其基站子系统
CN101621784B (zh) * 2008-11-21 2011-12-28 中国移动通信集团广东有限公司 一种移动分组域终端的推送式设置辅导方法
CN101959175B (zh) * 2009-07-17 2014-03-19 中兴通讯股份有限公司 本地ip访问连接建立的实现方法及系统
CN101959176B (zh) * 2009-07-20 2014-09-10 中兴通讯股份有限公司 建立本地ip访问连接的实现方法和系统
EP2444429B1 (de) * 2010-10-20 2016-09-07 Agfa Graphics N.V. Led-härtbare zusammensetzungen

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE272301T1 (de) * 2000-05-16 2004-08-15 Siemens Ag Verfahren zum umlegen eines tunnels zwischen knoten eines gprs-systems
CN1177446C (zh) * 2002-01-23 2004-11-24 华为技术有限公司 一种单信息源至多接收点的分组数据业务实现方法
CN101128041B (zh) 2006-08-15 2010-05-12 华为技术有限公司 接入网和核心网间下行数据隧道失效后的处理方法和系统

Also Published As

Publication number Publication date
CN100486381C (zh) 2009-05-06
EP2061264B1 (de) 2013-12-25
EP2061264A1 (de) 2009-05-20
CN101094440A (zh) 2007-12-26
EP2061264A4 (de) 2011-10-19
DK201200119U1 (da) 2012-09-14
EP2061264B8 (de) 2014-02-26
WO2008022518A1 (fr) 2008-02-28

Similar Documents

Publication Publication Date Title
DE19721273B4 (de) Verfahren zur Vorerrichtung von Kommunikationen in einem drahtlosen Kommunikationsnetz
DE69431946T2 (de) Verfahren und System zur Bestimmung der Weglenkung für mobile Arbeitsstationen in einem lokalen Mehrsegmentnetz
DE60203448T2 (de) Verfahren und System zum Steuern eines Kommunikationsnetzes und eines im Netz verwendeten Routers
DE10307259B4 (de) Verfahren und System, das Roaming zwischen verschiedenen drahtlosen Netzwerken erlaubt
DE69935971T2 (de) Verfahren zur wiederverbindung eines unterbrochenen rufes in einem mobilen kommunikationssystem
DE69923034T2 (de) Mobilkommunikationssystem zur Bereitstellung eines IP-Paketkommunikationsdienstes und Vorrichtung zur Leitweglenkung von IP-Paketen
DE69817188T2 (de) Punkt-zu-mehrpunkt mobilfunkübertragungen
DE69905888T2 (de) Ortsaktualisierungs-verfahren und weiterreichen-verfahren zwischen kernnetz-einheiten
DE69924679T2 (de) Reduzierung der signalisierungslast in einem funkpaketnetzwerk
DE60007313T2 (de) Anordnung einer steuersignalisierung in einem telekommunikationssystem
EP1282997B1 (de) Verfahren zum umlegen eines tunnels zwischen knoten eines gprs-systems
DE69929193T2 (de) Verfahren zur steuerung von kommunikation sowie kommunikationssystem
DE60034241T2 (de) Paketdatenprotokoll-kontextaktivierung für umherstreifende teilnehmer
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60120511T2 (de) Weiterleiten der identität eines mobilfunkteilnehmers zwischen kernnetzwerkknoten
DE69923673T2 (de) RAU optimierung für UMTS im URA zustand
DE60106549T2 (de) Regionales Tunnelsteuerungverfahren in einem Mobilkommunikationssystem mit Mobile-IP
DE60132497T2 (de) Verfahren und system zum implementieren einer zeichengabeverbindung in einem verteilten funkzugriffsnetzwerk
EP1077556B1 (de) Datenübertragung zwischen einer ersten Mobilfunkvermittlungsstelle eines ersten Mobilfunksystems und einer zweiten Mobilfunkvermittlungsstelle eines zweiten Mobilfunksystems
DE60029292T2 (de) System und Verfahren zur mobilen Kommunikation mit Vermeidung von Verzögerungen bei der Datenübertragung
DE60225306T2 (de) Optimierung von weiterreichungsprozeduren bei gprs
DE10145596A1 (de) Netzwerk mit mehreren Sub-Netzwerken
DE60106729T2 (de) Verfahren zur bereitstellung eines konkurrierenden dienstes in einem mobilen kommunikationssystem
DE202007019449U1 (de) Mobilkommunikationssystem
DE60311949T2 (de) Verbesserte OpenRAN Architektur für Funknetzsteuerungseinheit, Mobilkommunikationssystem, und Verfahren zur Steuerung eines Funkbasisstationsgeräts

Legal Events

Date Code Title Description
R150 Term of protection extended to 6 years
R207 Utility model specification

Effective date: 20121206

R157 Lapse of ip right after 6 years

Effective date: 20131203