DE10131561A1 - Verfahren zur Übertragung von Anwendungspaketdaten - Google Patents

Verfahren zur Übertragung von Anwendungspaketdaten

Info

Publication number
DE10131561A1
DE10131561A1 DE10131561A DE10131561A DE10131561A1 DE 10131561 A1 DE10131561 A1 DE 10131561A1 DE 10131561 A DE10131561 A DE 10131561A DE 10131561 A DE10131561 A DE 10131561A DE 10131561 A1 DE10131561 A1 DE 10131561A1
Authority
DE
Germany
Prior art keywords
packet data
terminal
application
protocol
service
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.)
Withdrawn
Application number
DE10131561A
Other languages
English (en)
Inventor
Serge Haumont
Tuija Hurtta
Bo Axerud
Thomas Reichler
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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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=7690025&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE10131561(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Nokia Oyj filed Critical Nokia Oyj
Priority to DE10131561A priority Critical patent/DE10131561A1/de
Priority to PCT/IB2002/003883 priority patent/WO2003003652A2/en
Priority to AT02780926T priority patent/ATE300826T1/de
Priority to US10/481,756 priority patent/US20040148425A1/en
Priority to EP02780926A priority patent/EP1413099B1/de
Priority to DE60205260T priority patent/DE60205260D1/de
Priority to AU2002334299A priority patent/AU2002334299A1/en
Publication of DE10131561A1 publication Critical patent/DE10131561A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer [OSI layer 5]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zur Übertragung von Anwendungspaketdaten über ein erstes Paketdatennetzwerk zwischen einem Endgerät und einem zweiten Paketdatennetzwerk, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb eines ersten Paketdatennetzwerks eingeführt sind, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem für das die Anwendung verwendenden Endgerät implementierten Diensttyp unterscheidbar sind, wobei das Verfahren die Schritte aufweist: Erfassen des Diensttyps und abhängig von der Übertragungsrichtung der Anwendungspaketdaten, Entfernen und/oder Hinzufügen zumindest einer der vielen einzelnen Protokollschichten für einen speziellen erfassten Dienttyp. Die vorliegende Erfindung betrifft ebenfalls entsprechend angepasste Endgeräte und Netzwerkknoten.

Description

    GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft ein Verfahren zur Übertragung von Anwendungspaketdaten über ein erstes Paketdatennetzwerk zwischen einem Endgerät und einem zweiten Paketdatennetzwerk. Ebenfalls betrifft die vorliegende Erfindung entsprechend angepasste Endgeräte und Gateway-Netzwerkknoten.
  • HINTERGRUND DER ERFINDUNG
  • Kürzlich machte die Informationstechnologie als solche und ebenfalls die Informationstechnologie in Verbindung mit Kommunikationsnetzwerken wesentliche Fortschritte. Insbesondere wurden Kommunikationsnetzwerke entwickelt, die mobile Kommunikation für sich bewegende Benutzer und/oder Endgeräte erlauben. Derzeitige Entwicklungen neigen dazu, paketvermittelte Netzwerkarchitekturen einzuführen bzw. zu verwirklichen. Im allgemeinen sind paketvermittelte Netzwerke zur Kommunikation bzw. Übertragung von Daten in Einheiten von Paketen angepasst. Beispiele für derartige Paketdatennetzwerke sind das Internet oder das GPRS Netzwerk (GPRS = General Packet Radio Service bzw. Allgemeiner Paketfunkdienst) als ein Beispiel eines mobilen Paketdatennetzwerks.
  • Nachfolgend wird die vorliegende Erfindung mit Bezug auf ein derartiges GPRS Netzwerk als einem Beispiel beschrieben. Selbstverständlich soll das gewählte Beispiel für die vorliegende Erfindung nicht einschränkend sein, und andere Netzwerke, die von dem GPRS Netzwerk unterschiedlich sind, können entsprechend an die vorliegende Erfindung angepasst werden, das heißt, die vorliegende Erfindung ist geeignet, um in verschiedenen Paketdatennetzwerken implementiert zu werden. Beispielsweise ist es bekannt, dass GPRS Netzwerke parallel zu GSM Netzwerken existieren (GSM = Global Standard of Mobile Communication bzw. Globaler Standard für Mobilkommunikation), als auch parallel zu UMTS Netzwerken existieren (UMTS = Universal Mobile Telecommunication System bzw. Universelles Mobiltelekommunikationssystem). GSM Netzwerke werden ebenfalls als 2G (Netzwerke der zweiten Generation) bezeichnet, wohingegen UMTS Netzwerke auch als 3G (Netzwerke der dritten Generation) bezeichnet werden.
  • Typischerweise werden Anwendungspaketdaten über ein erstes Paketdatennetzwerk wie beispielsweise ein GPRS Netzwerk zwischen einem auch als Mobilstation MS bezeichneten Endgerät und einem zweiten Paketdatennetzwerk wie beispielsweise dem Internet übertragen. Das Endgerät MS kann, muss jedoch nicht, aus zwei Komponenten bestehen: einem Mobilendgerät, welches mobile und/oder drahtlose Kommunikation mit dem ersten Paketdatennetzwerk (z. B. GPRS Netzwerk) ermöglicht, und einer Endgerätausstattung wie beispielsweise einem Personal Computer/Laptop oder irgendeiner anderen an das Mobilendgerät angeschlossenen geeigneten Datenverarbeitungseinrichtung. Die Schnittstelle zwischen dem Endgerät MS und beispielsweise dem GPRS Paketdatennetzwerk wird als Um oder Uu Schnittstelle im Falle eines GSM bzw. UMTS Netzwerks bezeichnet. Weiterhin wird die Schnittstelle zwischen dem GPRS Paketdatennetzwerk als einem ersten Paketdatennetzwerk und beispielsweise dem Internet als einem zweiten Paketdatennetzwerk als Gi Schnittstelle bezeichnet. Es ist zu beachten, dass der Ausdruck "Schnittstelle", wie er hier benutzt wird, in einigen ETSI Standards (ETSI = European Telecommunication Standards Institute bzw. Europäisches Institut für Telekommunikationsstandards) als "Bezugspunkt" bzw. "Reference Point" bezeichnet wird. Ein sein Endgerät zur Datenübertragung verwendender Benutzer lässt eine Anwendung auf seinem Endgerät ablaufen bzw. arbeiten, die zu übertragende Anwendungsdaten erzeugt. Diese Anwendungsdaten werden als paketförmige Daten übertragen. Derartige Anwendungspaketdaten werden unter Verwendung eines Anwendungsprotokolls übertragen. Ein Anwendungsprotokoll wird oben auf einem bzw. am oberen Ende eines Protokollstapels bzw. Protokollstacks betrieben, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für eine derartige Übertragung innerhalb eines Paketdatennetzwerks eingeführt sind.
  • Datenübertragung zwischen einer Sendeseite und einer Empfangsseite beruht auf dem OSI Referenzmodell (OSI = Open System Interconnection bzw. Offene Systemverbindung). Wie allgemein bekannt ist, unterteilt das OSI Referenzmodell den Kommunikationsprozess zwischen einer Sende- und einer Empfangsseite in sieben unabhängige Schichten. Schichten der gleichen Hierarchie auf der Sende- und der Empfangsseite teilen sich ein gemeinsames Protokoll, während eine gewisse Schicht auf einer Seite ebenfalls ein Protokoll mit den Schichten unmittelbar darüber und darunter zur Zwischenschichtverbindung bzw. Interlayerverbindung teilt. Jedoch muss die höchste Schicht (Schicht 7, Anwendungsschicht) keinerlei Einzelheiten der niedrigsten bzw. untersten Schicht, Schicht 1, der physikalischen Schicht kennen. Da erwartet wird, dass das OSI Referenzmodell Fachleuten bekannt ist, wird eine ausführlichere Beschreibung davon in der vorliegenden Anmeldung für entbehrlich gehalten.
  • Beispielsweise sind sendeseitig, wenn die Sendeseite durch die Mobilstation und/oder das Endgerät repräsentiert ist, die Protokollschichten gemäß GSM von der unteren Schicht zur oberen Schicht wie folgt gestapelt: GSM RF Schicht (Funkfrequenzschicht), MAC/RLC (Media Access Control/Radio Link Control bzw. Medienzugriffssteuerung/Funkverbindungssteuerung), LLC (Logical Link Control bzw. logische Verbindungssteuerung), SNDCP (Subnetwork Dependent Convergence Protocol bzw. subnetzwerkabhängiges Konvergenzprotokoll), die alle zusammen den Paketdomänenträger bzw. Packet Domain Bearer bilden. Entsprechend ist in einer UMTS Mobilstation der Protokollstapel an dem Endgerät L1, MAC/RLC; PDCP (Packet Data Control Protocol bzw. Paketdatensteuerungsprotokoll), die zusammen den Paketdomänenträger für UMTS bilden (vergleiche auch ETSI TS 129061, V 3.4.0, September 2000, Seiten 10 und 11).
  • Oben auf dem Paketdomänenträger kann eine weitere Protokollschicht wie beispielsweise IP/X.25 (Internetprotokoll) laufen bzw. betrieben werden, auf dem bzw. auf der wiederum die Anwendung aufgesetzt bzw. gestapelt ist. Somit ist in einem Paketdatennetzwerk wie beispielsweise dem GSM GPRS Netzwerk der Fluss von Benutzerdaten von der Anwendungsschicht an der Mobilstation über die Protokollstapel (in "vertikaler Richtung") nach unten zu der Schicht 1, von dort über das Basisstationssubsystem BSS (Funknetzwerksubsystem bzw. Radio Network Subsystem RNS gemäß UMTS) über den SGSN (Serving GPRS Support Node bzw. versorgender GPRS Unterstützungsknoten (3G SGSN in UMTS)) zu dem Gateway GPRS Support Node bzw. Gateway GPRS Unterstützungsknoten GGSN (3G GGSN in UMTS). Der Datenfluss von MS, BSS, SGSN, GGSN ist in "horizontaler Richtung" und an dem GGSN wird der Datenfluss erneut "vertikal" von Schicht 1 über Schicht 2, IP, UDP/TCP, GTP, IP/X.25 werden. An dem GGSN sind die Anwendungspaketdaten kurz davor, das erste Paketdatennetzwerk zu verlassen, zum Beispiel zu einem zweiten Paketdatennetzwerk und/oder werden auf eine ähnliche jedoch umgekehrte Sequenz zu einer Empfangsseite weitergeleitet (UDP/TCP = User Datagram Protocol/Transmission Control Protocol bzw. Benutzerdatagrammprotokoll/Übertragungssteuerungsprotokoll, GTP = GPRS Tunneling Protocol bzw. GPRS Tunnelprotokoll).
  • Auf der Anwendungsschicht laufen Anwendungen ab. Beispiele für derartige Anwendungen sind das drahtlose Anwendungsprotokoll bzw. Wireless Application Protocol WAP, das Sitzungsinitiierungsprotokoll bzw. Session Initiation Protocol SIP, das Echtzeitprotokoll bzw. Real Time Protocol RTP, digitale Paketdaten- bzw. Digital Packet Data DPD Signalisierung oder dergleichen.
  • Für einen speziellen Benutzer, der es wünscht, eine Anwendung ablaufen zu lassen oder eine Anwendung ablaufen lässt, wird bzw. ist ein sogenannter Kontext definiert. Ein solcher Kontext ist beispielsweise als PDP Kontext (PDP = Paket Data Protocol bzw. Paketdatenprotokoll) bekannt. Ein PDP Kontext ist definiert durch den PDP Typ, die Adresse (des Benutzers, d. h. des Endgeräts) und gewisse Dienstqualitätsanforderungen bzw. "Quality of Service" Anforderungen für die Anwendung (QoS).
  • Es ist zu beachten, dass verschiedenste derzeit bekannte Anwendungen und/oder selbst jene die noch zu entwickeln sind, von der vorliegenden Erfindung, wie sie nachfolgend beschrieben wird, profitieren können. Ungeachtet dessen wird die Beschreibung, um die Beschreibung einfach und nicht verwirrend zu halten, ein besonderes Augenmerk auf das Wireless Application Protocol WAP und das Session Initiation Protocol SIP als spezielle Beispiele für Anwendungen richten.
  • Es ist zu beachten, dass Tunneltechnologien im Internet allgemein bekannt sind. Sie bestehen im Senden eines an einen Tunnelendpunkt adressierten Pakets, wobei der Tunnelendpunkt das untere Übertragungsprotokoll entfernen wird, bestimmen wird, dass der Inhalt des Pakets zu einem anderen Knoten übertragen werden muss, und das Paket weiterleiten wird.
  • In GPRS als auch in UMTS besteht eine Einschränkung dahingehend, dass ein die selbe Adresse enthaltender PDP Kontext den gleichen PDP Typ haben muss. Gemäß ETSI Spezifikationen darf nämlich die sekundäre PDP Kontextaktivierungsprozedur nur initiiert werden, nachdem ein PDP Kontext bereits für die selbe PDP Adresse und APN (Access Point Name bzw. Zugriffspunktname) aktiviert ist. Es ist zu beachten, dass die PDP Adresse hinsichtlich der verwendeten Kodierung den PDP Typ enthält. Zusätzlich ist es bei gewissen Diensten/Anwendungen wie beispielsweise WAP und/oder SIP Signalisierung nicht einfach, die Adresse des Anwendungsservers zu entdecken. Für den WAP Dienst ist die IP Adresse des WAP Gateways heutzutage in der MS vorkonfiguriert. Für VoIP, wie es von 3GPP vorgesehen ist, wird zusätzliche Signalisierung benötigt, um es der MS zu ermöglichen, die lokale SIP-Proxy- (d. h. CSCF-) IP-Adresse zu entdecken. Ebenfalls möchten einige Netzwerkbetreiber den Teilnehmer dazu zwingen, die eigenen Dienste des Netzwerkbetreibers (Proxy Server, Gateway Server) zu benutzen. Dies impliziert, dass eine Einschränkung (wie beispielsweise FW (Firewall)), ein Uplink Filter bzw. ein Filter in Aufwärtsverkehrsrichtung wie beispielsweise TFT (Traffic Flow Template bzw. Verkehrsflussindikator) eingeführt wird, die eine Stelle innerhalb des Netzwerks betrifft, an der der Benutzer sich mit dem Netzwerk für gewisse Dienste verbinden bzw. an dieses anschliessen kann. Ein derzeitiger Vorschlag für VoIP (Voice over IP bzw. Sprache über IP) in 3GPP (Third Generation Partnership Project bzw. Partnerschaftsprojekt der dritten Generation) besteht in der Verwendung eines gewidmeten Signalisierungs-PDP-Kontextes mit einer neuen Funktion in dem GGSN, um eine Bestimmungsadresse von Paketdaten vorzuselektieren, die von dieser Bestimmungsadresse bzw. Zieladresse gesendet wurden und sie darauf einzuschränken, Uplink Filter wie beispielsweise Traffic Flow Templates (TFTs) nur zu einer erlaubten und/oder zu erlaubten Zieladressen zu verwenden.
  • Derzeit wird WAP über GPRS unter Verwendung von IP/UDP getragen. Ähnlich soll SIP gesendet werden bzw. SIP wird gesendet, und zwar über IP/UDP. Mit Bezug auf WAP bedeutet dies, dass mit jedem WAP Paket (von 3-200 Oktetten) ein IP/UDP Header bzw. Kopfabschnitt (aus 28 Oktetten) zur Übertragung über die Funkstrecke und den Backbone hinzugefügt ist. Zudem muss eine IP Adresse für jeden WAP Benutzer zugewiesen werden, und dieser IP Kopfabschnitt muss in der Mobilstation, d. h., dem Endgerät verarbeitet werden. Obwohl der IP Kopfabschnitt über die Funkschnittstelle komprimiert werden kann, kann dies nicht über den Backbone erfolgen. Derzeit wird Kopfabschnittskomprimierung bzw. Header-Komprimierung oder andere Kopfabschnittanpassungen wie beispielsweise Kopfabschnittsstrippen als Funkzugriffsnetzwerkfunktionalität implementiert. UTRAN (UMTS Terrestrial Radio Access Network bzw. UMTS terrestrisches Funkzugriffsnetzwerk) verwendet Kopfabschnittskomprimierung, wohingegen GERAN (GPRS Enhanced Radio Access Network bzw. GPRS verbessertes Funkzugriffsnetzwerk) Kopfabschnittsstrippen verwendet. Zudem erfordert IP Kopfabschnittskomprimierung eine gewisse zusätzliche Verarbeitung in dem Endgerät MS, als auch in 2G/3G SGSN und/oder dem Funknetzwerkcontroller RNC.
  • Offensichtlich sind aufgrund von Overheads bzw. Verwaltungsdaten und/oder Kopfabschnitten, die zusätzlich zu übertragen sind, Verzögerungen bei Anwendungen wie beispielsweise WAP über GPRS und/oder SIP über GPRS ziemlich signifikant. Insbesondere für Sprache-über-IP-Signalisierung (VoIP) sind Verzögerungen des Anrufaufbaus kritisch, so dass Verzögerungen für WAP und/oder SIP Implementierungen über GPRS minimiert werden sollten.
  • Die unterschiedlichen identifizierten Probleme wie beispielsweise Verzögerung, Bedürfnis zum Herausfinden einer Anwendungsserveradresse und Uplink-Beschränkungen können mittels der nachfolgend beschriebenen Erfindung verbessert oder gelöst werden.
    • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist folglich Aufgabe der vorliegenden Erfindung, ein Verfahren zur Übertragung von Anwendungspaketdaten über ein erstes Paketdatennetzwerk zwischen einem Endgerät und einem zweiten Paketdatennetzwerk anzugeben, welches die vorstehend genannten Nachteile beseitigt, die bei bekannten Verfahren und/oder Systemen inhärent sind. Weiterhin ist es eine Aufgabe der vorliegenden Erfindung, entsprechend angepasste Endgeräte und Netzwerkknoten zu schaffen, um das erfindungsgemäße Verfahren auszuführen.
  • Erfindungsgemäß wird die obige Aufgabe beispielsweise gelöst durch ein Verfahren zur Übertragung von Anwendungspaketdaten über ein erstes Paketdatennetzwerk zwischen einem Endgerät und einem zweiten Paketdatennetzwerk, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb des ersten Paketdatennetzwerks eingeführt sind, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem für das die Anwendung verwendenden Endgerät implementierten Diensttyp unterscheidbar sind, wobei das Verfahren die Schritte aufweist: Erfassen des Diensttyps, und abhängig von der Übertragungsrichtung der Anwendungspaketdaten, Entfernen und/oder Hinzufügen zumindest einer der vielen einzelnen Protokollschichten für einen speziellen erfassten Diensttyp.
  • Gemäß vorteilhaften Weiterentwicklungen des erfindungsgemäßen Verfahrens
    • - wird Entfernen und/oder Hinzufügen zumindest einer der vielen einzelnen Protokollschichten erreicht durch Entfernen und/oder Hinzufügen von auf die jeweilige Protokollschicht bezogenen Kopfabschnittsinformationen,
    • - wird Entfernen/Hinzufügen von zumindest einer der vielen einzelnen Protokollschichten an einem Gatewayknoten des ersten Paketdatennetzwerks zu dem zweiten Paketdatennetzwerk vorgenommen,
    • - wird in Downlink-Übertragung von dem zweiten Paketdatennetzwerk zu dem Endgerät, die zumindest eine der vielen einzelnen Protokollschichten entfernt, und wird in Uplink-Übertragung von dem Endgerät zu dem zweiten Paketdatennetzwerk, die zumindest eine der vielen einzelnen Protokollschichten hinzugefügt,
    • - wird Hinzufügen/Entfernen der zumindest einen der vielen einzelnen Protokollschichten an dem Endgerät vorgenommen, welches über das erste Paketdatennetzwerk mit dem zweiten Paketdatennetzwerk kommuniziert,
    • - wird in Downlink-Übertragung, die an dem Endgerät endet, die zumindest eine der vielen einzelnen Protokollschichten hinzugefügt, und wird in Uplink-Übertragung, die ihren Ursprung an dem Endgerät hat, die zumindest eine der vielen einzelnen Protokollschichten entfernt,
    • - wird der Diensttyp durch das Endgerät dem Gatewayknoten angezeigt,
    • - ist der Diensttyp einer Anwendung anhand eines Kontextes unterscheidbar, der für das Endgerät und die Anwendung definiert ist,
    • - weist eine Kontextdefinition Diensttyp, Adressinformation eines Endgeräts, für welches der Dienst implementiert ist, und eine Dienstqualitätsdefinition auf,
    • - weist die Kontextdefinition zusätzlich Filterinformationen, Anwendungstypinformationen, Zieladresse und Typ des hinzuzufügenden Kopfabschnitts auf,
    • - in dem Fall, dass unterschiedliche Anwendungen in dem Endgerät die gleiche Adresse teilen, bildet der Gateway Downlink-Pakete unter Verwendung eines Filtermechanismus auf den geeigneten Kontext ab,
    • - werden hinzuzufügende Protokollkopfabschnitte von dem Kontext und/oder konfigurierten Informationen bestimmt.
  • Weiterhin wird erfindungsgemäß die obige Aufgabe beispielsweise gelöst durch einen Gatewayknoten eines ersten Paketdatennetzwerks, wobei der Gatewayknoten angepasst ist, um Anwendungspaketdaten zwischen einem an das erste Paketdatennetzwerk anschließbaren Endgerät und einem an das Paketdatennetzwerk anschließbaren zweiten Paketdatennetzwerk zu übertragen, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb des ersten Paketdatennetzwerks eingeführt wurden, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem Diensttyp unterscheidbar sind, der für das die Anwendung verwendende Endgerät implementiert ist, wobei der Gatewayknoten aufweist: eine Erfassungseinrichtung, die angepasst ist, um den Diensttyp zu erfassen, und eine Auswahleinrichtung, die angepasst ist, um selektiv zumindest eine der vielen einzelnen Protokollschichten abhängig von der Übertragungsrichtung der Anwendungspaketdaten für einen speziellen erfassten Diensttyp zu entfernen und/oder hinzuzufügen.
  • Gemäß vorteilhaften Weiterentwicklungen des Gatewayknotens:
    • - ist die Auswahleinrichtung angepasst, um Kopfabschnittsinformationen zu entfernen und/oder hinzuzufügen, die auf die jeweilige Protokollschicht bezogen sind,
    • - ist die Auswahleinrichtung angepasst, um zumindest eine der vielen einzelnen Protokollschichten in Downlink- Übertragung von dem zweiten Paketdatennetzwerk zu dem Endgerät hin zu entfernen, und um die zumindest eine der vielen einzelnen Protokollschichten in Uplink-Übertragung von dem Endgerät zu dem zweiten Paketdatennetzwerk hinzuzufügen,
    • - ist die Auswahleinrichtung angepasst, um Protokollkopfabschnitte beruhend auf Informationen von dem Kontext und/oder konfigurierten Informationen hinzuzufügen,
    • - ist die Erfassungseinrichtung angepasst, um den Diensttyp einer Anwendung ausgehend von einem für die Anwendung definierten Kontext zu unterscheiden,
    • - ist die Erfassungseinrichtung angepasst, um den geeigneten Kontext unter Verwendung eines Filtermechanismus auszuwählen, wenn unterschiedliche Anwendungen in dem Endgerät die gleiche Adresse teilen,
    • - weist eine Kontextdefinition Anwendungstypinformationen, Adressinformationen eines Endgeräts, für welches der Dienst implementiert ist, und eine Dienstqualitätsdefinition auf,
    • - weist die Kontextdefinition zusätzlich Filterinformationen, Anwendungstypinformationen, Zieladresse und Typ des hinzuzufügenden Kopfabschnitts auf.
  • Zudem wird erfindungsgemäß die obige Aufgabe beispielsweise gelöst durch ein Endgerät, anschließbar an ein erstes Paketdatennetzwerk und angepasst, um Anwendungspaketdaten über das erste Paketdatennetzwerk zu einem zweiten Paketdatennetzwerk zu übertragen, welches an das erste Paketdatennetzwerk anschließbar ist und um Anwendungspaketdaten über das erste Paketdatennetzwerk von dem zweiten Paketdatennetzwerk zu empfangen, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb des ersten Paketdatennetzwerks eingeführt wurden, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem für das die Anwendung verwendenden Endgerät implementierten Diensttyp unterscheidbar sind, wobei das Endgerät aufweist: eine Erfassungseinrichtung, die angepasst ist, um den Diensttyp zu erfassen, eine Aktivierungseinrichtung, um eine Verbindung zu einem Gatewayknoten zu errichten, und eine Auswahleinrichtung, die angepasst ist, um zumindest eine der vielen einzelnen Protokollschichten abhängig von der Übertragungsrichtung der Anwendungspaketdaten für einen speziellen erfassten Diensttyp selektiv zu entfernen und/oder hinzuzufügen.
  • Gemäß vorteilhaften Weiterentwicklungen des Endgeräts:
    • - ist die Auswahleinrichtung angepasst, um auf die jeweilige Protokollschicht bezogene Kopfabschnittsinformationen zu entfernen und/oder hinzuzufügen,
    • - ist die Auswahleinrichtung angepasst, um zumindest eine der vielen einzelnen Protokollschichten in Downlink-Übertragung, die an dem Endgerät endet, hinzuzufügen, und um die zumindest eine der vielen einzelnen Protokollschichten in Uplink-Übertragung, die von dem Endgerät ausgeht, zu entfernen,
    • - ist die Erfassungseinrichtung angepasst, um den Diensttyp einer Anwendung ausgehend von einem für die Anwendung definierten Kontext zu unterscheiden,
    • - ist die Erfassungseinrichtung angepasst, um den geeigneten Kontext auszuwählen, wenn unterschiedliche Anwendungen in dem Endgerät die gleiche Adresse teilen,
    • - ist die Aktivierungseinrichtung angepasst, um einen oder viele Kontexte in einem Gatewayknoten zu errichten,
    • - weist eine Kontextdefinition einen Diensttyp, Adressinformationen eines Endgeräts, für welches der Dienst implementiert ist, und eine Dienstqualitätsdefinition auf,
    • - weist die Kontextdefinition zudem Filterinformationen, Zieladresse, Anwendungstypinformationen und den Typ des hinzuzufügenden Kopfabschnitts auf.
  • Demgemäss werden mit dem Verfahren und/oder dem Netzwerkknoten und/oder dem Endgerät gemäss der vorliegenden Erfindung Overheads bzw. Verwaltungsdaten und Verzögerungen verringert und die Übertragung somit optimiert. Ebenfalls wird ein Bedürfnis zur IP Kopfabschnittskomprimierung in dem Funknetzwerk beseitigt.
  • Weiterhin wird für die Verwendung spezieller Anwendungsserver erfordernden Verkehr ein Bedürfnis zum Entdecken eines externen Anwendungsservers wie beispielsweise einer CSCF (Call State Control Functional Entity bzw. Anrufzustandssteuerungsfunktionseinheit) des zweiten Netzwerks unterdrückt. Der Gatewayknoten (beruhend auf dessen Konfiguration) sendet jeglichen Uplink Verkehr bzw. Aufwärtsrichtungsverkehr zu geeigneten Servern, wie durch den Betreiber definiert. Dies unterdrückt ebenfalls die Möglichkeit für das Endgerät, seine Zieladresse bzw. Bestimmungsadresse auszuwählen, so dass das Bedürfnis der Uplink Beschränkung in dem Gatewayknoten beseitigt ist. Aufgrund der vorliegenden Erfindung kann die Verwendung von SIP und/oder WAP direkt über dem Paketdomänenträger (für einen speziellen Diensttyp) erzielt werden, wobei folgende Vorteile erzielt werden:
    • - geringere Verwaltungsdaten über die Funkschnittstelle und den Backbone (insbesondere, da IPv6 das obligatorische Protokoll in 3GPP Standards ist),
    • - schnellere Auslieferung von Nachrichten,
    • - Vermeidung von Aufwärtsrichtungsverkehrsflussindikatoren bzw. Uplink Traffic Flow Templates im GGSN
    • - Ermöglichen unterschiedlicher Gebührenbelastung (aufgrund der Verwendung der Diensttypparameter, die in den Gebührenabrechnungsdatensatz eingefügt werden können)
    • - Verringerung der Verarbeitung in dem Mobilstations-Endgerät als einer der Quellen der Verzögerung, was noch um so signifikanter ist, wenn (zuvor) IP Kopfabschnittskomprimierung zu verwenden war,
    • - Verringerung der Verwaltungsdaten erzielte Kapazität in dem Backbone und/oder über die Funkschnittstelle; IP Kopfabschnittskomprimierung kann über die Funkschnittstelle verwendet werden, aber nicht über den Backbone (Iu und Gn Schnittstellen) (es ist zu beachten, dass in jedem Fall die ersten Kopfabschnitte unkomprimiert gesendet werden, so würden beispielsweise die IP Kopfabschnitte einer bidirektionalen SIP Registrierung nicht komprimiert werden).
  • Unter besonderer Bezugnahme auf WAP, liegt der Gewinn teilweise in der Übertragungsgeschwindigkeit in der Größenordnung von 20-25 msec pro WAP Paket (28 × 8 bit/10 kbit/s = 22 msec), so dass, wenn WAP Übertragung vier Iterationen erfordert, der Gewinn bei etwa 100 msec liegt. Der Gewinn verringert teilweise die Wahrscheinlichkeit einer erneuten Übertragung. Wenn ein Paket mit zwei Funkverbindungssteuerungsschichtblöcken anstatt mit dreien gesendet wird, verringert sich die Wahrscheinlichkeit, dass einer dieser Blöcke fehlerhaft bzw. beeinträchtigt wird. Dies ist weniger signifikant, wenn IP Kopfabschnittskomprimierung verwendet wird (Verwaltungsdaten sind dann 2-4 Oktette).
  • Ebenfalls könnte die Endgerät-Mobilstation einfacher sein, da sie ihre WAP Anwendung direkt über GPRS/UMTS Protokolle ablaufen lassen könnte (ähnlich zum Betreiben dieser über SMS (Short Message Service bzw. Kurznachrichtendienst)). Weniger Verarbeitung wäre dann von dem Mobilstations-Endgerät gefordert. Ebenfalls müsste eine WAP Gateway-Adresse nicht in dem Mobilstations-Endgerät konfiguriert sein. Bei einer alternativen Implementierung eines Gatewayknotens wie beispielsweise einem GGSN liegen die Vorteile in weniger für WAP Benutzer in dem GGSN benötigten Adressen, einem einfacheren WAP Gatewayknoten, da die MSISDN (Mobile Station Integrated Service Digital Network Number bzw. ISDN Nummer der Mobilstation) zu WAP in einem Erweiterungskopfabschnitt hinzugefügt werden könnte, anstatt in dem WAP Gateway gespeichert zu werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNG
  • Die vorliegende Erfindung wird besser verständlich, wenn sie in Verbindung mit der beigefügten Zeichnung gelesen wird. Dabei zeigen:
  • Fig. 1 einen Protokollstapel in Verbindung mit der vorliegenden Erfindung für eine SIP Anwendung;
  • Fig. 2 einen Protokollstapel in Verbindung mit der vorliegenden Erfindung, der für eine WAP Anwendung verwendet wird;
  • Fig. 3 eine einer Anwendungsniveauregistrierung vorangehende Signalisierung gemäß derzeitigen Standards, wobei die Signalisierung mittels der vorliegenden Erfindung vereinfacht werden könnte;
  • Fig. 4 ein Beispiel einer Implementierung eines Mobilstations-Endgeräts gemäß der Erfindung hinsichtlich des implementierten Protokollstapels;
  • Fig. 5, bestehend aus Tabelle 1 und Tabelle 2, ein Beispiel zur Zuweisung bzw. Vergabe eines separaten Werts, der einen PDP Typ für einen speziellen Diensttyp darstellt;
  • Fig. 6 eine Signalisierung zur PDP Kontextaktivierung.
    • AUSFÜHRLICHE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
  • Ausführungsbeispiele der vorliegenden Erfindung werden nun mit Bezug auf die beigefügte Zeichnung beschrieben.
  • Im allgemeinen ist erfindungsgemäß eine Aktivierung eines anzufordernden sekundären Kontextes mit einem unterschiedlichen PDP Typ erlaubt, da bei diesem bevorzugten Ausführungsbeispiel der PDP Typ verwendet wird, um den Diensttyp anzuzeigen. Der GGSN wird einen derartigen sekundären Kontext akzeptieren, falls er die erforderliche Fähigkeit hat (das heißt, geeignete Auswahleinrichtungen sind implementiert) und wird sie andernfalls zurückweisen. Wenn das vorgeschlagene erfindungsgemäße Verfahren bei dem GGSN als einem Paketdatennetzwerkknoten implementiert wird, das heißt, einem Gatewayknoten, führt der GGSN ferner in Abwärtsübertragungsrichtung bzw. Downlink-Richtung eine Kopfabschnittsentfernung durch und führt eine Kopfabschnittshinzufügung in Uplink- bzw. Aufwärtsrichtung für zu diesem sekundären PDP Kontext gehörende Datenpakete durch. Ein sekundärer PDP Kontext muss somit als ein spezieller Diensttyp angesehen werden, der mit einer Anwendung wie beispielsweise WAP und/oder SIP implementiert ist. Somit wird ein spezieller sekundärer Kontext einen unterschiedlichen PDP Typ über GPRS/UMTS benutzen.
  • Hinsichtlich eines Endgeräts wie einer Mobilstation ist im allgemeinen das Entfernen und/oder Hinzufügen von auf Protokollschichten bezogenen Kopfabschnittsinformationen nicht notwendig. Genauer gesagt, kann ein in Uplink-Richtung sendendes Endgerät WAP (oder SIP) Signalisierung direkt über die Paketdomänenträgerschicht senden und kann in Downlink-Richtung die entsprechenden SIP/WAP Pakete direkt empfangen. Jedoch kann ein mehrere Typen von Diensten unterstützendes Endgerät (beispielsweise einen die Verwendung von IP/UDP erfordernden Diensttyp) angepasst sein, um zwischen unterschiedlichen Protokollstapeln umzuschalten, die in der Mobilstation implementiert sind, abhängig von dem zu verwendenden und/oder zu verarbeiteten Diensttyp. Wenn von einem Protokollstapel mit IP/UDP Protokollschichten zu einem Protokollstapel ohne diese Schichten umgeschaltet wird, könnte somit auch ein Mobilstations-Endgerät als derartige Protokollschichten selektiv entfernend und/oder hinzufügend angesehen werden. In einem speziellen Fall, bei dem ein mobiles Endgerät von einer anderen Endgerätausstattung wie beispielsweise einem Laptop oder Personal Computer getrennt ist, führt auch die Mobilstation als die Kombination der Endgerätausstattung und des mobilen Endgeräts Kopfabschnittsentfernung im Uplink und/oder Kopfabschnittshinzufügung im Downlink für zu einem sekundären PDP Kontext als einem speziellen Diensttyp gehörende Datenpakete durch.
  • Grundlegend wird erfindungsgemäß, falls es nicht erwünscht ist, dem Benutzer zu erlauben, Netzwerkfähigkeiten zu verwenden, die durch die IP Protokollschicht innerhalb des Protokollstapels bereitgestellt sind, dann für diesen speziellen Kontext die IP Protokollschicht aus dem Stapel entfernt. Aufgrund dessen wird eine Verringerung von Verwaltungsdaten bzw. Overhead und Beschleunigung von Diensten eingeführt. Ebenfalls erübrigt sich eine Implementierung einer besonderen Einschränkung.
  • Anders ausgedrückt, ist es erfindungsgemäß nicht stets so, dass ein SIP Stapel ohne IP verwendet wird, was die Anwendung und/oder den Dienst einschränken würde, der für den Benutzer bereitgestellt ist. Vielmehr erfolgt dies lediglich selektiv für spezielle Dienste wie beispielsweise Sprache über IP (VoIP) Signalisierung in 3GPP UMTS, die von einer speziellen Behandlung profitieren, wie beispielsweise keine Gebührenbelastung, automatische CSCF Auswahl, und die abonniert werden können oder nicht. Dies kann erreicht werden durch Hinzufügen eines neuen PDP Typs als einem Diensttyp wie beispielsweise "SIP Signalisierung für VoIP" zu den in dem Heimatregister HLR (gemäß GSM) und/oder dem Heimatteilnehmerserver bzw. Home Subscriber Server HSS (gemäß UMTS) geführten Teilnehmerdaten. Demgemäß kann ein Benutzer weiterhin einen grundlegenden IP Zugang haben, SIP aufgesetzt auf IP transparent benutzen, wird jedoch nicht in den Genuss einer speziellen Behandlung kommen.
  • Die Erfindung ist anwendbar, wenn der Verkehr dieses sekundären PDP Kontextes zu einer Zieladresse unter der Steuerung des Netzwerkbetreibers gesendet wird. Solch eine Zieladresse kann einen WAP Gateway oder einen SIP Proxy Server identifizieren. Ebenfalls ist die vorliegende Erfindung für SIP Signalisierung (für Sprache über IP) als auch WAP Verkehr anwendbar. Ungeachtet dessen sind diese Dienste nicht beabsichtigt, um für die vorliegende Erfindung einschränkend zu sein, und andere Diensttypen können auf ähnliche Weise in Verbindung mit der vorliegenden Erfindung eingesetzt werden.
  • Insbesondere braucht der Gatewayknoten bei einem noch allgemeineren Ausführungsbeispiel der Erfindung keine konfigurierten Informationen bezüglich eines Diensttyps zu haben, sondern muss lediglich Kopfabschnitte, wie durch den durch das Endgerät gesendeten Kontext definiert, hinzuzufügen und zu entfernen. Beispielsweise in einem RTP Fluss zugeordneten Kontext könnte das Endgerät in dem Kontext einen hinzuzufügenden/zu entfernenden Kopfabschnitt (z. B. IPv6/UDP) anzeigen und zum Kreieren des Kopfabschnitts benötigte Informationen (Portnummer; IP Zieladresse, . . .) angeben. Der GGSN könnte den Kopfabschnitt ohne auf RTP bezogenes Wissen hinzufügen/entfernen.
  • Fig. 1 zeigt grafisch die Protokollstapel beteiligter Netzwerkknoten und des Endgeräts bei der Implementierung der vorliegenden Erfindung. Fig. 1 stellt dies für SIP dar, welches direkt über 3G GPRS (UMTS) getragen wird. Das heißt, wenn ein SIP Proxy Server (z. B. CSCF) SIP Verkehr unter Beteiligung der IP/UDP Protokollschicht über die Schnittstelle Gi zwischen dem SIP Proxy und dem GGSN sendet, wird der SIP Verkehr an dem GGSN einschließlich der IP/UDP Schicht wie in Fig. 1 angezeigt empfangen. Auf die Verarbeitung des empfangenen IP/UDP/SIP Verkehrs hin erfasst der GGSN den Diensttyp des Verkehrs (beruhend auf in dem PDP Kontext enthaltenen Filterinformationen) und, in Downlink-Richtung, entfernt auf die Erfassung hin die IP/UDP Protokollschicht aus dem Protokollstapel. Folglich leitet der GGSN den SIP Verkehr direkt auf dem Paketdomänenträger, transparent für den SGSN (SGSN leiten den Verkehr nur weiter) zu dem Endgerät, das heißt, der Mobilstation, die die Endgerätausstattung und ein Mobilendgerät umfasst, weiter. Auf ähnliche Weise erfasst der GGSN den speziellen Diensttyp wenn er SIP Verkehr empfängt, der von dem Mobilstationsendgerät in Uplink-Richtung transparent über den SGSN zu dem GGSN gesendet wird, und fügt die IP/UDP Protokollschicht hinzu, damit der SIP Verkehr mit IP/UDP über die Gi Schnittstelle zu dem SIP Proxy weitergeleitet wird. Die SIP Proxy Adresse und Typ des hinzuzufügenden Kopfabschnitts (IPv6/UDP) sind dem GGSN durch Konfiguration bekannt.
  • Es ist zu beachten, dass Fig. 1 die Situation für den speziellen Diensttyp zeigt. Beispielsweise können die Endgeräteausstattung und das Mobilendgerät diensttypspezifische Protokollstapel aufweisen, von denen einer abhängig von dem zu implementierenden und/oder zur Übertragung zu verwendenden Diensttyp auszuwählen ist. Bei 3GPP gibt es eine Anforderung dahingehend, dass es dem Betreiber möglich sein sollte, den Benutzer zu zwingen, den eigenen SIP Proxy Server des Betreibers zu verwenden. Dies kann durch Entfernen der "Netzwerkschicht", das heißt, IP/UDP Schicht, erzielt werden. Diese Lösung vermeidet die Beschränkung der Ziele des Benutzerverkehrs (unter Verwendung von Uplink Verkehrsflussindikatoren bzw. Traffic Flow Templates TFT) und das Durchführen einer CSCF Entdeckung ("CSCF Discovery"), da es der GGSN übernimmt, eine geeignete Anrufzustandssteuerungsfunktionseinheit bzw. Call State Control Functional Entity CSCF innerhalb des zweiten Paketdatennetzwerks zu finden, und unnötige Verwaltungsdaten bzw. Overhead (IPv6 und UDP) wird über den Backbone als auch über die Funkschnittstelle eingespart.
  • Fig. 2 zeigt ein ähnliches Szenario eines Protokollschichtenstapels wie in Fig. 1 gezeigt. Der Unterschied dazwischen besteht darin, dass Fig. 2 den Protokollschichtenstapel für WAP als eine direkt über dem Paketdomänenträger getragene Anwendung anstelle von SIP zeigt. Somit gilt im wesentlichen die gleiche Beschreibung wie die in Verbindung mit Fig. 1 gegebene auch für Fig. 2. Lediglich SIP muss durch WAP ersetzt werden.
  • Um die Erfassung und Auswahl des Hinzufügens/Entfernens einer Protokollschicht zu bzw. aus dem Stapel bei dem GGSN beispielsweise zu ermöglichen, ist ein neuer PDP Typ definiert, der den speziellen Dienst spezifiziert, für den die vorliegende Erfindung anwendbar ist.
  • Ein Beispiel einer derartigen neuen PDP Typ Definition ist in Fig. 5 gezeigt:
    Tabelle 1 bezieht sich auf den Fall von Fig. 1, die sich mit SIP Anwendungen beschäftigt, die auf der Paketdomänenträgerschicht getragen werden;
    Tabelle 2 von Fig. 5 ist für den Fall von Fig. 2 anwendbar, die sich mit WAP Anwendungen beschäftigt, die direkt auf der Paketdomänenträgerschicht getragen werden.
  • Wie in Tabelle 1 von Fig. 5 gezeigt, ist ein neuer PDP Typ zu der GPRS/UMTS Spezifikation beispielsweise als ein ETSI PDP Typ hinzugefügt. Auf ähnliche Weise zeigt Tabelle 2 von Fig. 5 einen der GPRS/UMTS Spezifikation als einen ETSI PDP Typ hinzugefügten neuen PDP Typ.
  • Optional könnte WAP als ein Diensttyp als PPP DLL Protokollnummern hinzugefügt werden (Punkt-zu-Punkt-Protokoll Datenverbindungsschicht bzw. Point-to-Point-Protocol Data Link Layer), was schneller als in 3GPP ist. Als ein Vorteil könnte der zusätzliche UDP/IP Kopfabschnitt auch von der Konvergenzsubschicht CS entfernt werden, und WAP könnte direkt über PPP (Point-to-Point-Protocol) gesendet werden. Somit kann ein Mobilstations-Endgerät, aufgrund der definierten neuen PDP Typen, einen PDP Kontext mit einem PDP Typ "SIP Signalisierung für Sprache über IP" und/oder "WAP" anfordern, während andererseits ein GGSN einen solchen, einen speziellen Dienst anzeigenden PDP Kontext erfassen kann. Die diesem PDP Kontext zugewiesene IP Adresse (wie sie von dem zweiten Netzwerk gesehen wird) kann ebenfalls für anderen IP Verkehr verwendet werden, der einen anderen Kontext verwendet. Dies ist der Fall, wenn unterschiedliche PDP Kontexte mit unterschiedlichem PDP Typ die gleiche IP-Adresse verwenden. Es ist zu beachten, dass diese neuen PDP Typen sowohl für primären als auch sekundären Kontext anwendbar sind.
  • Wenn sie auf einem primären PDP Kontext verwendet werden, muss der GGSN den Typ der Adresse (z. B. IPv4 oder IPv6) bestimmen, die dem Endgerät zuzuordnen bzw. zuzuweisen ist. In dem Fall der SIP Signalisierung, bei der 3GPP die Verwendung von IPv6 fordert, könnte dies auf der GGSN Konfiguration beruhen.
  • Bei einer bevorzugten Implementierung signalisiert das Endgerät während der PDP Kontextaktivierungsprozedur nicht nur den Diensttyp (z. B. WAP), sondern ebenfalls den Typ der angeforderten Adresse (z. B. IPv6). Dies ist nicht notwendig bei einer sekundären PDP Kontextaktivierung, da die Adresse des primären Kontexts automatisch verwendet wird, selbst wenn der Diensttyp unterschiedlich sein kann. Wenn der PDP Typ verwendet wird, um den Diensttyp anzuzeigen, könnte ein neues Feld verwendet werden, um den Typ der Adresse anzuzeigen.
  • Es ist jedoch zu beachten, dass bei einem alternativen Ausführungsbeispiel andere Kodierungen verwendet werden sollten. Beispielsweise könnte ein neues Feld hinzugefügt werden, um den Diensttyp anzuzeigen, während PDP Typ verwendet werde könnte, um den Typ der Adresse anzuzeigen. Es ist zu beachten, dass ein Aspekt der Neuheit der Erfindung der ist, dass das über den Paketdomänenträger (d. h. erstes Netzwerk) transportierte Protokoll unterschiedlich ist zu dem durch das Anwendungsnetzwerk (d. h. zweites Netzwerk) zum Adressieren des Endgeräts verwendeten Protokoll. Dies ist der Grund dafür, warum das Feld PDP Typ, das zuvor beide Protokolle identifizierte, bei der Erfindung verwendet werden kann, um das eine oder das andere Protokoll anzuzeigen.
  • Für Downlink-Benutzerdatentransfer, wie allgemein bereits zuvor erwähnt, überprüft der GGSN, ob das empfangene Paket ein WAP/IP/UDP Paket (und/oder SIP/IP/UDP Paket im Fall von Fig. 1) ist. Falls dem so ist, wird der IP/UDP Kopfabschnitt entfernt und die Pakete werden als ein Teil eines WAP PDP Kontexts (oder SIP VoIP Kontexts) weitergeleitet. Diese Überprüfung könnte vorteilhafterweise, aber muss nicht notwendigerweise durch Überprüfen des UDP Ports bzw. UDP Anschlusses durchgeführt werden. Falls die vorstehend genannte Überprüfung negativ ist, werden die IP Pakete normal als ein Teil eines der existierenden PDP Kontexte für diese IP Adresse weitergeleitet. Alternativ könnten sie in einem derartigen Fall ebenfalls verworfen werden.
  • Es ist zu beachten, dass die Auswahl des PDP Kontextes den existierenden Verkehrsflussindikatormechanismus bzw. Traffic Flow Template Mechanismus verwendet. Jedoch ist es in Verbindung mit der vorliegenden Erfindung nicht erforderlich, dass der Traffic Flow Template von dem Mobilstations-Endgerät gesendet wird, da WAP einen allgemein bekannten Port verwendet. Somit ist der Traffic Flow Template TFT dem GGSN lokal bekannt.
  • Obwohl vorangehend die vorliegende Erfindung mit einem Schwerpunkt auf WAP und/oder SIP Signalisierung beschrieben wurde, ist dies für die vorliegende Erfindung nicht einschränkend. Andere Protokolle können direkt über den Paketdomänenträger getragen bzw. befördert werden, wie beispielsweise RTP (Echtzeitprotokoll bzw. Real Time Protocol) oder VoIP Verkehr oder TCP (Übertragungssteuerungsprotokoll bzw. Transmission Control Protocol) (beispielweise wenn der gesamte TCP Verkehr einen TCP Proxy zur Drahtlos-Optimierung verwenden muss).
  • Ebenfalls muss der Protokollstapel, auf dem die vorliegende Anmeldung anwendbar ist, nicht auf den zuvor hierin beschriebenen beschränkt sein. Beispielsweise ist die vorliegende Erfindung auf ähnliche Weise anwendbar bei einem an die Mobilstation über eine Konvergenzsubschicht-Verbindung bzw. CS Verbindung angeschlossenen Zugangsserver. In diesem Fall sind die Stapelschichten von unten nach oben CS/PPP/IP/UDP/WAP. Somit würde auf das Entfernen von IP/UDP hin WAP direkt auf CS/PPP getragen bzw. befördert werden.
  • In Verbindung mit Fig. 2 ist anzumerken, dass der GGSN die IP Adresse des WAP Gateways aus seiner Konfiguration kennen kann. Dies vermeidet die Notwendigkeit des Konfigurierens der WAP Gateway IP Adresse in das Mobilstations-Endgerät. Alternativ wird die IP Adresse des WAP Gateways (oder dessen logischer Name) als ein Teil der PDP Kontextaktivierungsprozedur gesendet. In diesem Fall wird der GGSN angepasst sein, um sie zu speichern und als die Zieladresse für alle Pakete zu verwenden. Mittels dieses Merkmals ist das Mobilstations-Endgerät in die Lage versetzt, den zu verwendenden WAP Gateway auszuwählen.
  • Fig. 3 zeigt eine Kontextaktivierungsprozedur gemäß der derzeitigen Arbeitsgrundlage bei 3GPP. Fig. 3 stellt in horizontaler Richtung die beteiligten Vorrichtungen und Netzwerkeinheiten dar, wohingegen in vertikaler Richtung die Abfolge von Schritten und übertragener Nachrichten dargestellt ist. Bei Schritt 1 führt eine Benutzerausstattung als ein 3G-Endgerät eine GPRS Attach-Prozedur mit einem versorgenden GPRS Unterstützungsknoten bzw. GPRS Support Node SGSN durch. Danach, in Schritt 2, leitet die Benutzerausstattung bzw. das User Equipment UE eine PDP Kontextaktivierungsanforderung zu dem SGSN weiter. Im Ansprechen darauf leitet der SGSN in Schritt 3 eine Anforderung zum Kreieren eines PDP Kontextes bzw. eine Kreiere-PDP-Kontext-Anforderung zu einem Gateway GPRS Unterstützungsknoten GGSN weiter. In einem darauffolgenden Schritt antwortet der GGSN mit einer Kreiere-PDP-Kontext-Antwort an den SGSN, die eine Adresse einer Proxy-Anrufzustandssteuerungsfunktionseinheit enthält. Es ist zu beachten, dass eine Proxy-Anrufzustandssteuerungsfunktionseinheit als P-CSCF bezeichnet ist. Der SGSN als der versorgende GPRS Unterstützungsknoten leitet in Schritt S diese PDP Kontextaktivierungsantwort einschließlich der P-CSCF Adresse zu der Benutzerausstattung weiter. Falls die P-CSCF Adresse nicht durch die SIP Anwendung empfangen wurde (z. B. die SIP-Anwendung kann in einem separaten Laptop sein) leitet die Benutzerausstattung in Schritt 6 eine DHCP: Anforderungs-/Informationsnachricht zu einem DHCP Server weiter (DHCP = Dynamic Host Configuration Protocol bzw. dynamisches Hostkonfigurationsprotokoll). Der somit adressierte Server antwortet in Schritt 7 mit einer DHCP:ACK (P-CSCF Name/Adresse) Bestätigungsnachricht an die Benutzerausstattung. Die Benutzerausstattung wiederum gibt in Schritt 8 eine den Namen des P-CSCF enthaltende DNS-Abfrage zu dem Domänennamenssystemserver DNS aus. Dieser Domänennamenssystemserver DNS antwortet in Schritt 9 mit einer DNS-Antwort an die Benutzerausstattung, wobei die Antwort die Adresse des P-CSCF enthält. Danach führt die Benutzerausstattung in Schritt 10 eine Anwendungsniveauregistrierung mit der Anrufzustandssteuerungsfunktionseinheit P-CSCF durch. Diese Signalisierung ist die derzeit in der Standardisierung erörterte Signalisierung.
  • Diese Signalisierung wäre jedoch im Fall der Implementierung der vorliegenden Erfindung vereinfacht: In der PDP-Kontext-Aktivierungs-Antwort wäre keine P-CSCF-Adresse erforderlich, was 16 Oktette übertragener Daten einspart, und Schritte 6 bis 9 sind nicht erforderlich (diese Schritte könnten vorgesehen werden im Fall, dass das Endgerät in zwei Komponenten unterteilt ist, d. h., einen Computer wie beispielsweise einen Laptop getrennt von einem Mobilstationsendgerät, wie vorstehend erwähnt). Fig. 6 zeigt ein derartiges vereinfachtes Signalisierungsszenario, welches bei Implementierung der vorliegenden Erfindung erreicht werden kann. Auf ähnliche Weise sind in horizontaler Richtung die beteiligten Ausstattungen und Netzwerkeinheiten dargestellt, wohingegen in vertikaler Richtung die ausgetauschten Nachrichten wie sie sequenziell gesendet werden dargestellt sind. Wie gezeigt, sind an der Signalisierung eine Benutzerausstattung UE als ein 3G-Endgerät bzw. Endgerät der dritten Generation, ein Funkzugangsnetzwerk RAN, welches aus (nicht gezeigten) Node_B's und Funknetzwerksteuerungseinrichtungen RNC besteht, und der SGSN und GGSN als ein Teil des Kernnetzwerks beteiligt. Das Endgerät, d. h. Benutzerausstattung oder Mobilstation, fordert einen PDP Kontext mit dem PDP Typ "SIP Signalisierung für VoIP" an. Es ist zu beachten, dass obwohl diese Beschreibung mit Bezug auf das Beispiel von "SIP" erfolgt, die gleiche Signalisierung im Fall des PDP Typs "WAP" oder irgendeinem anderen der vorstehend erwähnten PDP Typen angewendet werden kann, die in Verbindung mit der vorliegenden Erfindung verwendbar sind. Zusätzlich kann optional der Typ der angeforderten Adresse ebenfalls in dieser Anforderung eingefügt sein. Bei einem allgemeineren Ausführungsbeispiel der Erfindung können gleichermaßen Informationen eingefügt sein, die definieren, wie Kopfabschnitte (wie beispielsweise Zieladresse, Anwendungstypinformationen und Typ des hinzuzufügenden/zu entfernenden Kopfabschnitts) hinzuzufügen und zu entfernen sind. Diese Anforderung wird in Schritt 1 als eine Aktiviere-PDP-Kontextanforderung von der Benutzerausstattung über das Funkzugangsnetzwerk zu dem SGSN geleitet. Der SGSN prüft, ob der angeforderte PDP Typ (Diensttyp) aufgrund des Abonnements für die Benutzerausstattung zugelassen ist. Diese Überprüfung wird durch Abfrage der in dem Heimatregister (2G) oder dem Heimatteilnehmerserver (3G) geführten Daten durchgeführt. Falls zugelassen, erzeugt bzw. kreiert der SGSN einen PDP Kontext zu einem GGSN, der SIP PDP Typ (oder WAP PDP Typ oder dergleichen) unterstützt. Vor dem Kreieren davon wird in Schritt 2 der Funkzugangsträger zwischen der Benutzerausstattung und dem SGSN über das Funkzugangsnetzwerk aufgebaut. In Schritt 3 leitet der SGSN dann die vorstehend erwähnte Kreiere-PDP- Kontext-Anforderung zu dem Gateway GPRS Unterstützungsknoten GGSN weiter, welcher in Schritt 4 eine Kreiere-PDP-Kontext-Antwort an den SGSN zurückliefert. In Schritt 5 sendet der SGSN dann eine Aktiviere-PDP-Kontext-Akzeptiert- Nachricht über das RAN zu der Benutzerausstattung UE.
  • Anders ausgedrückt, initiiert die Benutzerausstattung eine PDP Kontextaktivierung und zeigt mit dem PDP Typ "SIP- Signalisierung für VoIP" und/oder "WAP" an, dass der PDP Kontext ein Signalisierungs PDP Kontext ist. Dieser Kontext ist bei diesem Beispiel ein primärer Kontext. Dann wird der Funkzugangsträger bzw. Radio Access Bearer aufgebaut. Der SGSN wählt den den angezeigten PDP Typ unterstützenden GGSN aus, und der SGSN sendet die Kreiere-PDP-Kontext- Anforderungs-Nachricht zu dem ausgewählten GGSN. Die Nachricht enthält den PDP Typ SIP-Signalisierung für Sprache über IP. Der GGSN kreiert den PDP Kontext. Ebenfalls ermittelt der GGSN die Proxy-CSCF-Adresse aus seinen Konfigurationsdaten (beispielweise APN Konfiguration, APN = Access Point Name bzw. Zugangspunktname). Dann sendet der GGSN die Kreiere-PDP-Kontext-Antwort-Nachricht zu dem SGSN, und der SGSN sendet die Aktiviere-PDP-Kontext-Akzeptiert-Nachricht zu dem Endgerät (Benutzerausstattung und/oder Mobilstation).
  • Nach der Signalisierung der PDP Kontextaktivierung hat das Endgerät einen zur Kommunikation mit der Anrufzustandssteuerungsfunktionseinheit CSCF (in Fig. 6 nicht gezeigt) geeigneten PDP Kontext. Dieser Kontext wird lediglich für SIP-Signalisierung (bzw. WAP Signalisierung) verwendet werden, die stets zu der durch den GGSN ausgewählten Proxy-CSCF gehen wird.
  • Im Fall eines zwei Komponenten umfassenden Endgeräts wie beispielsweise einem von dem Mobilendgerätteil getrennten Laptopcomputer ist ein SIP-Protokollstapel auf einem Laptop implementiert. Dann sendet der Laptop SIP-Signalisierung über IP mit einer vorkonfigurierten Dummy-Zieladresse. Das Mobilstationsteil entfernt den IP/UDP Kopfabschnitt und leitet die SIP Signalisierungsnachricht direkt auf den Funkzugangsträgerstapel weiter.
  • Der SGSN und der GGSN enthalten den PDP Typ "SIP-Signalisierung für VoIP" in den Anrufeinzelheitendatensätzen bzw. Call Detail Records (CDR), die sie für den Signalisierungs- PDP-Kontext kreieren. Dies ermöglicht es dem Betreiber, Anrufsteuerungssignalisierung unterschiedlich zu anderem Verkehr abzurechnen bzw. mit Gebühren zu belasten. Wenn ein neues Feld verwendet wird, um den Diensttyp anzuzeigen, sollte dieses Feld gleichermaßen in den's CDR enthalten sein.
  • Wenn ein Sprache über IP (VoIP) Anruf initiiert wird, muss ein Echtzeit - RT - sekundärer PDP Kontext aktiviert werden. Dieser sekundäre PDP Kontext hat dann einen unterschiedlichen PDP Typ, wie beispielsweise IPv6 oder RTP.
  • Nachfolgend wird vorliegende Erfindung mit einem Augenmerk auf mögliche Implementierungen für den GGSN als einem Gatewayknoten beschrieben. Es ist zu beachten, dass im Fall von SIP-Paketen/WAP Paketen die auf TCP/IP empfangen werden, der Gatewayknoten wie beispielsweise ein GGSN die nachfolgenden Alternativen hat:
    • - Weiterleiten der SIP TCP Nachricht über einen PDP Kontext unter Verwendung des PDP Typs TCP,
    • - Weiterleiten der SIP TCP IP Nachricht über einen PDP- Kontext unter Verwendung des PDP Typs IPv6,
    • - Verwerfen des Pakets,
    • - Zurücksenden einer TCP Bestätigung,
    • - Entfernen des IP/TCP-Kopfabschnitts und Weiterleiten der SIP-Nachricht über einen PDP Kontext unter Verwendung des PDP Typs SIP-Signalisierung für Sprache über IP.
  • Erneut ist zu beachten, dass SIP oder WAP als Diensttypen und/oder Anwendungen getragen bzw. befördert werden können, sodass obwohl die Beschreibung auf einen von SIP oder WAP fokussiert ist, es selbstverständlich möglich ist, dass dies ebenfalls für den anderen von SIP oder WAP anwendbar ist. In diesem Bewusstsein werden GGSN Implementierungen nun mit Bezug auf WAP Pakete als einem Beispiel beschrieben. Es ist zu beachten, dass im Fall, dass WAP Pakete betroffen sind, ein WAP Gateway als Teil des zweiten Paketdatennetzwerks beteiligt ist, wohingegen im Fall, das SIP- Paketdaten betroffen sind, ein auch als SIP-Proxy bezeichneter Proxy-CSCF für das zweite Paketdatennetzwerk beteiligt ist.
    • Erste GGSN Implementierung
  • Wenn er die PDP Kontextanforderung empfängt, weist der GGSN (intern oder von DHCP; RADIUS (DHCP = Dynamic Host Configuration Protocol bzw. dynamisches Host-Konfigurationsprotokoll, RADIUS = Remote Authentication Dial-In User bzw. Fern-Authentifikations-Einwahlbenutzer)) eine IP Adresse für den PDP Kontext zu. Der GGSN informiert einen WAP Gateway (oder eine Datenbank, die der WAP Gateway abfragen kann) bezüglich der Abbildung bzw. Zuordnung zwischen der IP Adresse und der Endgeräteidentität (dargestellt beispielsweise durch die MSISDN und/oder die IMSI) unter Verwendung beispielsweise des RADIUS Protokolls, welches bei dem GGSN implementiert ist. Es ist zu beachten, dass die IP Adresse des WAP Gateways in dem GGSN als Teil der Zugangspunktnamenkonfiguration bzw. APN Konfiguration vorkonfiguriert ist.
  • Eine Unterscheidung muss getroffen werden zwischen Downlink-Benutzerdatenübertragung und Uplink-Benutzerdatenübertragung.
  • Für Downlink-Benutzerdatenübertragung verhält sich der WAP Gateway normal. Das heißt, er sendet ein WAP Paket zu dem GGSN auf den UDP/IP Protokollschichten (wie schematisch in Fig. 2 dargestellt). Jedoch entfernt der GGSN UDP/IP und leitet die WAP Information direkt über GTP (GPRS Tunnelprotokoll) weiter und leitet die GTP Pakete zu dem richtigen SGSN weiter. Falls die empfangenen Pakete kein WAP/UDP/IP Paket waren, kann der GGSN implementiert sein, um eine der vorstehend erwähnten alternativen Optionen zu haben, beispielsweise, um die Pakete zu verwerfen. Dies wäre der Fall, falls die Filterinformation (z. B. TFT) anzeigt, dass dieses Paket zu keinem PDP Kontext gehört. Der SGSN und das Funknetzwerk leiten die Pakete lediglich zu dem Endgerät weiter, und es ist für den SGSN nicht erforderlich, dieses neue Protokoll zu verstehen. Wenn das Endgerät (Mobilstation oder Benutzerausstattung) das zu dem WAP PDP Kontext gehörende Paket empfängt, sendet das Mobilstations-Endgerät dieses Paket zu seiner internen WAP Anwendungsschicht.
  • Für Uplink-Benutzerdatenübertragung sendet das Mobilstations-Endgerät das Paket direkt über die "Paketdomänenschicht" (was bei 2G (GSM) bedeutet, bis hin zu SNDCP = Subnetwork Dependent Convergence Protocol bzw. subnetzwerkabhängiges Konvergenzprotokoll, wohingegen in 3G (UMTS) dies bedeutet, bis hin zu PDCP = Packet Data Convergence Protocol bzw. Paketdatenkonvergenzprotokoll auf der Funkverbindungssteuerung bzw. Radio Link Control RLC). Der SGSN leitet das Paket lediglich zu dem GGSN weiter. Der GGSN erfasst den PDP Kontext von dem GTP Kopfabschnitt, der durch den SGSN gesendet wurde, und fügt den geeigneten Kopfabschnitt hinzu. Die Information zum Kreieren des geeigneten Kopfabschnitts wird aus dem PDP Kontext genommen (Quellenadresse ist MS PDP Adresse) und aus Konfigurationsinformationen (Zieladresse ist eine konfigurierte WAP Gateway Adresse, UDP mit statischer Portnummer bzw. Anschlussnummer wird stets durch WAP Anwendung verwendet). Dann leitet der GGSN das Paket in einem UDP/IP Paket zu dem WAP Gateway als dem Ziel der Datenpaketübertragung weiter. Die Zieladresse ist die IP Adresse des WAP Gateways, während die Ursprungs- bzw. Quelladresse die für diesen PDP Kontext zugeordnete IP Adresse ist.
  • Bei einem allgemeineren Ausführungsbeispiel der Erfindung werden Informationen, die angeben, wie Kopfabschnitte (wie beispielsweise Zieladresse, Port Information und Typ des hinzuzufügenden/zu entfernenden Kopfabschnitts) hinzuzufügen und zu entfernen sind, lediglich aus dem PDP Kontext entnommen. Dies vermeidet das Bedürfnis nach Konfigurationsinformationen im GGSN für jeden Diensttyp.
  • Es ist zu beachten, dass eine Verbesserung darin besteht, den GGSN in die Lage zu versetzen, die Verkehrslast über viele WAP Gateways zu spreizen bzw. zu verteilen. Sie kann verwendet werden, indem die jüngste bzw. letzte zum senden von Downlink-Paketen verwendete Quellenadresse gespeichert wird, was die gewidmete Lastteilungslösung ersetzt, bei der auf mehrere WAP Gateways durch die selbe IP Adresse zugegriffen wird.
  • Auf ähnliche Weise besteht im Fall von SIP eine Verbesserung darin, dem GGSN zu ermöglichen, die Last über viele Proxy-CSCF zu verteilen, beispielsweise anhand eines logischen Namens, dem eine Liste von Proxy-CSCFs zugeordnet ist. In diesem Fall wird für jeden PDP Kontext die IP Adresse des ausgewählten Proxy-CSCF gespeichert.
    • Zweite GGSN Implementierung
  • Nun wird eine zweite GGSN Implementierung beschrieben. Bei dieser Implementierung verwendet der GGSN die gleiche IP Adresse für mehrere oder sogar alle WAP PDP Kontexte. Es ist zu beachten, dass ein proprietäres bzw. anwendereigenes bzw. herstellerabhängiges Kopfabschnittsfeld in den WTP (Wireless Transaction Protocol bzw. drahtloses Transaktionsprotokoll) Nachrichten hier zur Teilnehmeridentifikation in Uplink- als auch in Downlink-Richtung verwendet wird. Die WAP Gateway IP Adresse ist in dem GGSN als Teil der Zugangspunktnamenskonfiguration bzw. APN Konfiguration vorkonfiguriert.
  • Für Downlink-Benutzerdatenübertragung muss der WAP Gateway die gleiche MSISDN (Mobilstations ISDN Nummer) oder den gleichen Alias-Namen zu dem Kopfabschnitt jeder WTP Nachricht hinzufügen. Der GGSN entfernt die UDP/IP Protokollschicht, verwendet die MSISDN oder den Alias-Namen, um herauszufinden, zu welchem PDP Kontext (d. h. Mobilstations- Endgerät) die Pakete zu senden sind. Dann entfernt er diesen optionalen WTP Kopfabschnitt und leitet die WAP Informationen (oder SIP Informationen) direkt über GTP (GPRS Tunnelprotokoll) weiter und leitet die GTP Pakete zu dem richtigen SGSN weiter. Auch hier kann der GGSN, falls die empfangenen Pakete keine WAP/UDP/IP Pakete waren, die Pakete gemäß einer der zuvor erwähnten Optionen verwerfen. Der SGSN leitet die Pakete lediglich zu dem Mobilstations- Endgerät weiter (für den SGSN besteht kein Bedürfnis, dieses neue Protokoll zu verstehen). Wenn das Mobilstations- Endgerät diese zu dem WAP PDP Kontext gehörenden Pakete empfängt, sendet das Mobilstations-Endgerät diese Pakete zu seiner internen WAP Anwendungsschicht.
  • Für Uplink-Benutzerübertragung bzw. -Benutzerdatenübertragung sendet das Mobilstations-Endgerät ein Paket direkt über die "Paketdomänenschicht" (SNDCP = Subnetwork Dependent Convergence Protocol bzw. subnetzwerkabhängiges Konvergenzprotokoll für 2G (GSM) oder PDCP = Packet Data Convergence Protocol bzw. Paketdatenkonvergenzprotokoll auf RLC Funkstreckensteuerung bzw. Radio Link Control für 3G (UMTS)). Der SGSN leitet die Pakete lediglich zu dem GGSN weiter. Der GGSN erfasst den PDP Kontext und fügt den geeigneten Kopfabschnitt wie bei der ersten Implementierung hinzu. Zusätzlich modifiziert der GGSN den Anwendungskopfabschnitt (WTP) durch hinzufügen eines optionalen (proprietären) WTP Feldes, welches die MSISDN Nummer oder irgend einen anderen Benutzer-Alias-Namen des Mobilstations- Endgeräts enthält, die bzw. der zur Identifizierung des Mobilstations-Endgeräts geeignet ist. Es ist zu beachten, dass die MSISDN Nummer dem GGSN bekannt ist, da sie ein Teil der PDP Kontextinformationen ist. Der GGSN leitet die WAP Pakete (die den WTP Kopfabschnitt enthalten) in einem UDP/IP Paket zu dem WAP Ziel-Gateway weiter (die Zieladresse ist die WAP Gateway IP Adresse, die Ursprungs- bzw. Quelladresse ist die IP Adresse, die allen WAP PDP Kontexten zugeordnet ist). Der WAP Gateway verwendet die MSISDN oder den Benutzer-Alias-Namen zur Benutzeridentifikation.
  • Es ist zu beachten, dass das Hinzufügen eines WAP Kopfabschnitts in dem GGSN ein proprietäres Merkmal ist, welches gleichermaßen durch den WAP Gateway unterstützt werden muss, auf den zugegriffen wird.
  • Es ist somit anzumerken, dass mit der vorliegenden Erfindung eine derartige Verbesserung erzielt werden kann, die es dem GGSN ermöglicht, Verkehrslast über viele WAP Gateways zu spreizen. Ebenfalls ist eine externe Datenbank zur Teilnehmeridentifikation nicht mehr länger erforderlich. Die Lösung löst mögliche Probleme mit Netzwerkadressenübersetzern bzw. Network Adress Translators NAT zwischen GGSN und einem WAP Gateway. Ebenfalls ist aufgrund der vorliegenden Erfindung ein neues proprietäres Merkmal in der Protokollstapelimplementierung des WAP Gateways einzuführen.
  • Vorangehend wurden mögliche Implementierungen des GGSN als einem Gatewayknoten des Paketdatennetzwerks beschrieben.
  • Nachfolgend wird eine mögliche Implementierung eines Mobilstations-Endgeräts beschrieben, welches über das erste Paketdatennetzwerk mit einem zweiten Paketdatennetzwerk kommuniziert. Eine solche mögliche Implementierung ist in Fig. 4 dargestellt.
  • Fig. 4 stellt das Mobilstations-Endgerät hinsichtlich der verwendeten Protokollstapel dar. Es ist zu beachten, dass alle dargestellten Protokollstapel auf die (nicht gezeigte) Paketdomänenträgerschicht am "Fuß" bzw. unteren Ende von Fig. 4 zugreifen. Das wie in Fig. 4 dargestellte Endgerät ist mit Bezug auf SIP Signalisierung angegeben, ist jedoch auf ähnliche Weise für WAP oder andere Diensttypen und/oder Anwendungen anwendbar. Allgemein gesagt, kann der Protokollschichtenstapel des Mobilstations-Endgeräts in zwei Hauptteile unterteilt werden: einen rechten Teil unterhalb der mit IM CN Anwendungen bezeichneten "Wolke" und einen linken Teil. Der linke Teil des Protokollschichtenstapels enthält UDP/TCP und IP Protokollschichten, wohingegen diese Schichten nicht in dem rechten Teil vorhanden sind. Es ist zu beachten, dass der interne SIP Signalisierungsstapel als IM CN Anwendungsprotokoll bezeichnet ist (IP Mulitmediakernnetzwerkanwendungsprotokoll bzw. IP Multimedia Core Network Application Protocol). Abhängig von den Benutzeranwendungen erzeugt das IM CN Anwendungsprotokoll somit die SIP Nachricht (oder WAP Nachricht) und reicht sie zu der Sockel API (Application Programming Interface bzw. Anwendungsprogrammierungsschnittstelle) weiter, anzeigend, dass dies für einen PDP Kontext mit einem PDP Typ "SIP Signalisierung für VoIP" beabsichtigt ist. Die Sockel API bzw. Socket API leitet dann die Informationen direkt zu dem (nicht gezeigten) Paketdomänenträger an dem "Fuß" bzw. an der unteren Seite des Protokollstapels weiter. Somit "umgeht" diese Paketdatenübertragung von der Sockel API zu dem Paketdomänenträger UDP/TCP und IP Protokollschichten, da diese für diesen Diensttyp entfernt sind. In dem anderen Fall, d. h., die Benutzeranwendungen ergeben einen "normalen" Diensttyp, für den UDP/TCP und IP Protokollschichten nicht zu entfernen sind, greifen die Benutzeranwendungen auf die Benutzeranwendungsprotokolle in dem linken Teil des dargestellten Protokollschichtenstapels zu und das Mobilstations-Endgerät sendet diese Paketdaten wie normal, was auch bedeutet, unter Beteiligung bzw. Einbeziehung von UDP/TCP und IP Protokollschichten. Somit werden abhängig von dem Diensttyp der Anwendung zumindest einige der Protokollschichten selektiv entfernt oder nicht.
  • Eine weitere Implementierung für das Mobilstations-Endgerät könnte darin bestehen, dass die Sockel API zuerst SIP über UDP/IP hinzufügt und dann, dass ein Entfernungs-Funktionsteil der UMTS-Schicht dieses wieder entfernt. Dies ist jedoch in Fig. 4 nicht dargestellt.
  • Wie vorstehend bereits erwähnt, wird erfindungsgemäß die Kopfabschnittsinformation selektiv hinzugefügt/entfernt und entsprechend werden Protokollschichten anhängig von einem speziellen Diensttyp zu dem Protokollstapel hinzugefügt/von dem Protokollstapel entfernt.
  • Um die Kopfabschnittsentfernung in dem GGSN Gateway Netzwerkknoten allgemeiner zu gestalten, könnte dies bereits bei der PDP Kontextaktivierung angezeigt werden, beispielsweise unter Verwendung eines neuen Informationsfeldes: "GGSN-Kopfabschnittsentfernung angefordert". Für solch eine allgemeine Anzeige könnte ein neuer Parameter eingeführt werden oder ein bereits existierender Parameter (beispielsweise ein Dienstqualitätsparameter) könnte verwendet werden.
  • Zusätzlich zeigt die MS dem GGSN ebenfalls an, was mit dem Kopfabschnitt durchzuführen bzw. wie die Kopfabschnittsentfernung durchzuführen ist, indem die folgende Information in der PDP Kontextaktivierungsanforderung angezeigt wird:
    • Das zum Senden zu verwendende Protokoll
    • - IPv4/UDP: GGSN wird das Anwendungspaket in einem IPv4/UDP Paket einschließen,
    • - IPv6/UDP: GGSN wird das Anwendungspaket in einem IPv6/UDP Paket einschließen,
    • - IPv4/TCP: GGSN wird das Anwendungspaket in einem IPv4/TCP Paket einschließen,
    • - IPv6/TCP: GGSN wird das Anwendungspaket in einem IPv6/TCP Paket einschließen.
  • Es ist zu beachten, dass eine Alternative darin besteht, dieses Feld auszulassen, so dass UDP stets verwendet wird und der PDP Typ IPv6 oder IPv4 anzeigt.
  • Es ist zu beachten, dass andere Protokolle angezeigt werden können, wie beispielsweise L2TP/PPP. . .
    • Zum Senden zu verwendende Port-Nummer bzw. Anschlussnummer
  • Die Verwendung dieses Anschlusses dient dazu, das Bedürfnis des GGSN zu begrenzen, das Anwendungsprotokoll zu kennen. Somit zeigt dieses Feld dem GGSN an, wenn ein fester UDP Anschluss zu verwenden ist (einschließlich des Wertes) oder falls der UDP Anschluss aus einem gewissen Bereich ausgewählt werden muss.
    • Zieladresstyp
  • Dies zeigt an, ob die Adresse ein logischer Name, eine IPv6 oder IPv4 Adresse ist.
  • Es ist alternativ zu beachten, dass diese Information aus dem TFT abgeleitet werden könnte, wenn die MS die Zieladresse anzeigt, auf die der Verkehr für dieses PDP zu beschränken ist.
    • Diensttyp
  • Es ist zu beachten, dass dieses Feld ausgelassen werden könnte, da diese generische bzw. allgemeine Lösung den GGSN nicht benötigt, um das Anwendungsprotokoll zu interpretieren oder eine konfigurierte Aktion anzuwenden.
  • Bei diesem Vorschlag ist der Typ der PDP Adresse (d. h. der Endgerätadresse) durch das Feld PDP Typ angezeigt.
  • All diese Parameter können als optional codiert sein, sodass ein diese Funktion nicht unterstützender GGSN dieses Feld ignorieren würde. Ein die allgemeine Kopfabschnittsentfernung unterstützender GGSN würde es jedoch mit einem neuen Parameter (Kopfabschnittsentfernung aktiviert) in der PDP Kontextantwortnachricht anzeigen.
  • Dann würde das Mobilstations-Endgerät bereits eine Kopfabschnittsentfernungsanforderung senden, wenn es die Funktion unterstützt und die Kopfabschnittsentfernung aktivieren, wenn der GGSN deren Unterstützung bestätigt.
  • Zur Kopfabschnitts-Entfernung/-Hinzufügung muss die Kopfabschnittsinformation von dem Mobilstations-Endgerät zu dem GGSN und umgekehrt signalisiert werden, abhängig von Uplink- und/oder Downlink-Übertragung. Die Kopfabschnittsinformation bzw. Header-Information könnte unter Verwendung von Verkehrsflussindikatoren bzw. Traffic Flow Templates TFT zu dem GGSN und/oder zu dem Mobilstations-Endgerät befördert werden. In diesem Fall muss das Mobilstations- Endgerät die erforderlichen Parameter in dem Traffic Flow Template einstellen (beispielsweise Zieladresse, Zielanschluss usw.). Wenn ebenfalls Kopfabschnitte entfernt werden, die von IP/TCP/UDP unterschiedlich sind, muss das Mobilstations-Endgerät zusätzliche protokollspezifische Kopfabschnittsinformationen bei der PDP Kontextaktivierung zu dem Gateway GPRS Unterstützungsknoten senden (beispielsweise RTP (Echtzeitprotokoll bzw. Real Time Protocol) Kopfabschnittsinformationen im Fall einer RTP/UDP/IP Kopfabschnittsentfernung).
  • Eine Anzeige "GGSN Kopfabschnittsentfernung verwendet" könnte ebenfalls zu Anrufeinzelheitendatensätzen bzw. Call Detail Records CDR's hinzugefügt werden (zumindest zu den durch den GGSN kreierten bzw. erzeugten Anrufeinzelheitendatensätzen). Somit könnte GGSN Kopfabschnittsentfernung, d. h. Entfernen von Protokollschichtenkopfabschnitten bei dem GGSN als ein zusätzlicher Dienst angesehen werden, der Kostenersparnisse für den Benutzer mit sich bringt. Mit GGSN Kopfabschnittsentfernung spart der Benutzer in gewissem Umfang Geld, da einige der tatsächlichen Benutzerdaten nicht abgerechnet werden. Zudem erhöht sich die Funktionalität des GGSN. Das heißt, wenn der Betreiber wünscht, dies bei der Rechnungserstellung zu berücksichtigen, ist die "GGSN Kopfabschnittsentfernung verwendet" Anzeige in Anrufeinzelheitendatensätzen erforderlich.
  • Ebenfalls ist die Ende-zu-Ende-Verschlüsselung (beispielsweise bei dem IP Sicherheitsprotokoll IPSec) ein Punkt von Interesse bei Kopfabschnittsentfernung. Falls IPSec verwendet wird, kann lediglich der IP Kopfabschnitt (und möglicher Weise ESP (Encapsulation Security Payload bzw. Verkapselungssicherheitsnutzlast)) entfernt und rekonstruiert werden. Andere Kopfabschnitte wie beispielsweise TCP und UDP sind verschlüsselt. Eine Verbesserung könnte für das Mobilstations-Endgerät darin bestehen, dass der angeforderte Kopfabschnittsentfernungsgrad angezeigt wird (beispielsweise IP Kopfabschnittsentfernung, IP/TCP Kopfabschnittsentfernung, IP/UDP Kopfabschnittsentfernung, IP/UDP/RTP Kopfabschnittsentfernung, oder dergleichen). Ein IPSec verwendendes Mobilstations-Endgerät könnte die IP Kopfabschnittsentfernung anfordern. Ebenfalls weiß der GGSN mit der Kopfabschnittsentfernungsgradanzeige, welche Kopfabschnitte für Uplink-Pakete zu rekonstruieren sind.
  • Selbstverständlich kann das Wissen hinsichtlich der Kopfabschnitte dadurch abgeleitet werden, indem überprüft wird, welche Informationen die Mobilstation sendet, um zur Kopfabschnittsrekonstruktion verwendet zu werden. Falls jedoch das Mobilstations-Endgerät gar nichts sendet, sondern der GGSN diese Informationen selbst bestimmt, kann ein Wissen bezüglich des erforderlichen Kopfabschnittsentfernungsgrads nicht möglich sein, ohne die Kopfabschnittsentfernungsgradanzeige.
  • Derzeit ist Kopfabschnittsadaptierung als die Funkzugangsnetzwerkfunktionalität implementiert. Falls Kopfabschnittsentfernung in dem GGSN als einem Teil des Kernnetzwerks durchgeführt wird, ist es vorteilhaft, dies dem Funkzugangsnetzwerk anzuzeigen. Falls das Funkzugangsnetzwerk weiß, dass lediglich Benutzerdaten mit unterschiedlichen Kopfabschnitten übertragen werden, besteht kein Bedürfnis, eine Kopfabschnittsadaptierung in dem Funkzugangsnetzwerk durchzuführen. Der SGSN könnte es dem Funkzugangsnetzwerk anzeigen, falls Kopfabschnittsentfernung in dem GGSN durchgeführt wird. Wenn GGSN Kopfabschnittsentfernung angefordert wird, sollte der SGSN lediglich einen solchen GGSN auswählen, der Kopfabschnittsentfernung unterstützt, so dass der SGSN dem Funkzugangsnetzwerk anzeigen kann, dass "keine Kopfabschnittsentfernung erforderlich ist".
  • Somit wird aus dem obigen deutlich, dass es erfindungsgemäß möglich ist, dass mehrere unterschiedliche Typen von PDP Kontexten gleichzeitig aktiviert sind. Erfindungsgemäß ist eine Aktivierung eines sekundären Kontextes mit einem anzufordernden unterschiedlichen PDP Typ erlaubt. Der GGSN wird die Anforderung nur akzeptieren, wenn er die erforderliche Fähigkeit hat. Zusätzlich führt der GGSN eine gewisse Kopfabschnittsentfernung in Downlink-Richtung und Kopfabschnittshinzufügung in Uplink-Richtung für zu diesem sekundären PDP Kontext (spezieller Diensttyp) gehörende Datenpakete durch. Somit könnten in speziellen Fällen zumindest ein Teil des Protokollschichtenstapels wie beispielsweise die IP Schicht des Stapels aus dem sekundären Kontext entfernt werden, wodurch Dienste beschleunigt werden und Signalisierungsverwaltungsdaten bzw. Signalisierungs-Overhead verringert wird. Ungeachtet dessen besteht kein Bedürfnis, einen SIP-Stapel und/oder WAP-Stapel stets ohne IP zu verwenden, sondern nur für spezielle Dienste wie beispielsweise "Sprache über IP" Signalisierung in 3GPP, die von der speziellen Behandlung, wie beispielsweise keine Gebührenbelastung profitieren. Damit es möglich ist, Kopfabschnitte im Downlink zu entfernen, muss das Mobilstations-Endgerät ausdrücklich wissen, dass die eingehenden Pakete von einem gewissen Typ sind. Diese Information kann dem Mobilstations-Endgerät unter Verwendung von Traffic Flow Templates signalisiert werden.
  • Ebenfalls existiert mit der vorliegenden Erfindung die Möglichkeit, von dem Mobilstations-Endgerät die Ziel-IP-Adresse als einen Teil der PDP Kontextaktivierung zu signalisieren. Falls jedoch keine Ziel-IP-Adresse vorgesehen ist, könnte der Gateway "automatische Bereitstellung eines vorab bestimmten Anwendungsservers" (z. B. WAP Gateway) bereitstellen, wenn Roaming über GPRS Netzwerke möglich ist. Das heisst, falls das Endgerät in Bezug zu einem neuen GGSN steht, führt dies dazu, das automatisch zu einem zugehörigen WAP Gateway verbunden wird, ohne irgendeine ausdrückliche Bereitstellung. Durch Auswählen des GGSN in dem HPLMN (Home Public Land Mobile Network bzw. öffentliches landgestütztes Heimat-Mobilnetzwerk) hält die Mobilstation beim Roaming ihren Heimat-WAP-Dienst, wohingegen durch Auswählen des GGSN im VPLMN (Visited Public Land Mobile Network bzw. besuchtes öffentliches landgestütztes Mobilnetzwerk) das Mobilstations-Endgerät automatisch örtliche bzw. lokale WAP-Dienste nutzt.
  • Demgemäß, wie vorstehend beschrieben betrifft die vorliegende Erfindung ein Verfahren zur Übertragung von Anwendungspaketdaten über ein erstes Paketdatennetzwerk zwischen einem Endgerät und einem zweiten Paketdatennetzwerk, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb des ersten Paketdatennetzwerks eingeführt sind, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem für das die Anwendung verwendenden Endgerät implementierten Diensttyp unterscheidbar sind, wobei das Verfahren die Schritte aufweist: Erfassen des Diensttyps, und abhängig von der Übertragungsrichtung der Anwendungspaketdaten, Entfernen und/oder Hinzufügen zumindest einer der vielen einzelnen Protokollschichten für einen speziellen erfassten Diensttyp. Die vorliegende Erfindung betrifft ebenfalls entsprechend angepasste Endgeräte und Netzwerkknoten.
  • Obwohl die vorliegende Erfindung vorangehend mit Bezug auf ihre bevorzugten Ausführungsbeispiele beschrieben wurde, ist es selbstverständlich, dass zahlreiche Modifikationen daran vorgenommen werden können, ohne vom Gedanken und Schutzbereich der Erfindung abzuweichen. Es ist beabsichtigt, dass alle solchen Modifikationen innerhalb des Schutzbereichs der beigefügten Patentansprüche liegen. ANHANG





Claims (28)

1. Verfahren zur Übertragung von Anwendungspaketdaten über ein erstes Paketdatennetzwerk zwischen einem Endgerät und einem zweiten Paketdatennetzwerk, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb des ersten Paketdatennetzwerks eingeführt sind, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem für das die Anwendung verwendenden Endgerät implementierten Diensttyp unterscheidbar sind, wobei das Verfahren die Schritte aufweist:
Erfassen des Diensttyps, und
abhängig von der Übertragungsrichtung der Anwendungspaketdaten, Entfernen und/oder Hinzufügen zumindest einer der vielen einzelnen Protokollschichten für einen speziellen erfassten Diensttyp.
2. Verfahren nach Anspruch 1, wobei Entfernen und/oder Hinzufügen zumindest einer der vielen einzelnen Protokollschichten erreicht wird durch Entfernen und/oder Hinzufügen von auf die jeweilige Protokollschicht bezogenen Kopfabschnittsinformationen.
3. Verfahren nach Anspruch 1 oder 2, wobei Entfernen/Hinzufügen von zumindest einer der vielen einzelnen Protokollschichten an einem Gatewayknoten des ersten Paketdatennetzwerks zu dem zweiten Paketdatennetzwerk vorgenommen wird.
4. Verfahren nach Anspruch 3, wobei in Downlink-Übertragung von dem zweiten Paketdatennetzwerk zu dem Endgerät, die zumindest eine der vielen einzelnen Protokollschichten entfernt wird, und in Uplink-Übertragung von dem Endgerät zu dem zweiten Paketdatennetzwerk, die zumindest eine der vielen einzelnen Protokollschichten hinzugefügt wird.
5. Verfahren nach Anspruch 1 oder 2, wobei Hinzufügen/Entfernen der zumindest einen der vielen einzelnen Protokollschichten an dem Endgerät vorgenommen wird, welches über das erste Paketdatennetzwerk mit dem zweiten Paketdatennetzwerk kommuniziert.
6. Verfahren nach Anspruch 5, wobei
in Downlink-Übertragung, die an dem Endgerät endet, die zumindest eine der vielen einzelnen Protokollschichten hinzugefügt wird, und
in Uplink-Übertragung, die ihren Ursprung an dem Endgerät hat, die zumindest eine der vielen einzelnen Protokollschichten entfernt wird.
7. Verfahren nach Anspruch 1, wobei der Diensttyp durch das Endgerät dem Gatewayknoten angezeigt wird.
8. Verfahren nach Anspruch 1, wobei der Diensttyp einer Anwendung anhand eines Kontextes unterscheidbar ist, der für das Endgerät und die Anwendung definiert ist.
9. Verfahren nach Anspruch 8, wobei eine Kontextdefinition Diensttyp, Adressinformation eines Endgeräts, für welches der Dienst implementiert ist, und eine Dienstqualitätsdefinition aufweist.
10. Verfahren nach Anspruch 8 oder 9, wobei die Kontextdefinition zusätzlich aufweist Filterinformationen, Anwendungstypinformationen, Zieladresse und Typ des hinzuzufügenden Kopfabschnitts.
11. Verfahren nach einem der vorangehenden Patentansprüche, wobei in dem Fall, dass unterschiedliche Anwendungen in dem Endgerät die gleiche Adresse teilen, der Gateway Downlink- Pakete unter Verwendung eines Filtermechanismus auf den geeigneten Kontext abbildet.
12. Verfahren nach einem der vorangehenden Patentansprüche, wobei hinzuzufügende Protokollkopfabschnitte von dem Kontext und/oder konfigurierten Informationen bestimmt werden.
13. Gatewayknoten eines ersten Paketdatennetzwerks, wobei der Gatewayknoten angepasst ist, um Anwendungspaketdaten zwischen einem an das erste Paketdatennetzwerk anschließbaren Endgerät und einem an das Paketdatennetzwerk anschließbaren zweiten Paketdatennetzwerk zu übertragen, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb des ersten Paketdatennetzwerks eingeführt wurden, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem Diensttyp unterscheidbar sind, der für das die Anwendung verwendende Endgerät implementiert ist,
wobei der Gatewayknoten aufweist:
eine Erfassungseinrichtung, die angepasst ist, um den Diensttyp zu erfassen, und
eine Auswahleinrichtung, die angepasst ist, um selektiv zumindest eine der vielen einzelnen Protokollschichten abhängig von der Übertragungsrichtung der Anwendungspaketdaten für einen speziellen erfassten Diensttyp zu entfernen und/oder hinzuzufügen.
14. Gatewayknoten nach Anspruch 13, wobei die Auswahleinrichtung angepasst ist, um Kopfabschnittsinformationen zu entfernen und/oder hinzuzufügen, die auf die jeweilige Protokollschicht bezogen sind.
15. Gatewayknoten nach Anspruch 13 oder 14, wobei
die Auswahleinrichtung angepasst ist, um zumindest eine der vielen einzelnen Protokollschichten in Downlink-Übertragung von dem zweiten Paketdatennetzwerk zu dem Endgerät hin zu entfernen, und
um die zumindest eine der vielen einzelnen Protokollschichten in Uplink-Übertragung von dem Endgerät zu dem zweiten Paketdatennetzwerk hinzuzufügen.
16. Gatewayknoten nach Anspruch 13 oder 14, wobei die Auswahleinrichtung angepasst ist, um Protokollkopfabschnitte beruhend auf Informationen von dem Kontext und/oder konfigurierten Informationen hinzuzufügen.
17. Gatewayknoten nach Anspruch 13, wobei die Erfassungseinrichtung angepasst ist, um den Diensttyp einer Anwendung ausgehend von einem für die Anwendung definierten Kontext zu unterscheiden.
18. Gatewayknoten nach Anspruch 15 oder 16, wobei die Erfassungseinrichtung angepasst ist, um den geeigneten Kontext unter Verwendung eines Filtermechanismus auszuwählen, wenn unterschiedliche Anwendungen in dem Endgerät die gleiche Adresse teilen.
19. Gatewayknoten nach Anspruch 17, wobei eine Kontextdefinition Anwendungstypinformationen, Adressinformationen eines Endgeräts, für welches der Dienst implementiert ist, und eine Dienstqualitätsdefinition aufweist.
20. Gatewayknoten nach Anspruch 17 bis 19, wobei die Kontextdefinition zusätzlich Filterinformationen, Anwendungstypinformationen, Zieladresse und Typ des hinzuzufügenden Kopfabschnitts aufweist.
21. Endgerät, anschließbar an ein erstes Paketdatennetzwerk und angepasst, um Anwendungspaketdaten über das erste Paketdatennetzwerk zu einem zweiten Paketdatennetzwerk zu übertragen, welches an das erste Paketdatennetzwerk anschließbar ist und um Anwendungspaketdaten über das erste Paketdatennetzwerk von dem zweiten Paketdatennetzwerk zu empfangen, wobei die Anwendungspaketdaten übertragen werden unter Verwendung eines Anwendungsprotokolls, welches auf einem Protokollstapel betrieben wird, wobei der Protokollstapel mehrere einzelne gestapelte Protokollschichten aufweist, die für die Übertragung innerhalb des ersten Paketdatennetzwerks eingeführt wurden, wobei die Anwendungspaketdaten an das Endgerät adressiert sind und gemäß einem für das die Anwendung verwendenden Endgerät implementierten Diensttyp unterscheidbar sind,
wobei das Endgerät aufweist
eine Erfassungseinrichtung, die angepasst ist, um den Diensttyp zu erfassen,
eine Aktivierungseinrichtung, um eine Verbindung zu einem Gatewayknoten zu errichten, und
eine Auswahleinrichtung, die angepasst ist, um zumindest eine der vielen einzelnen Protokollschichten abhängig von der Übertragungsrichtung der Anwendungspaketdaten für einen speziellen erfassten Diensttyp selektiv zu entfernen und/oder hinzuzufügen.
22. Endgerät nach Anspruch 21, wobei die Erfassungseinrichtung angepasst ist, um den Diensttyp einer Anwendung ausgehend von einem für die Anwendung definierten Kontext zu unterscheiden.
23. Endgerät nach Anspruch 21 oder 22, wobei die Erfassungseinrichtung angepasst ist, um den geeigneten Kontext auszuwählen, wenn unterschiedliche Anwendungen in dem Endgerät die gleiche Adresse teilen.
24. Endgerät nach Anspruch 21, wobei die Aktivierungseinrichtung angepasst ist, um einen oder viele Kontexte in einem Gatewayknoten zu errichten.
25. Endgerät nach Anspruch 21, wobei die Auswahleinrichtung angepasst ist, um auf die jeweilige Protokollschicht bezogene Kopfabschnittsinformationen zu entfernen und/oder hinzuzufügen.
26. Endgerät nach Anspruch 21 oder 25, wobei
die Auswahleinrichtung angepasst ist,
um zumindest eine der vielen einzelnen Protokollschichten in Downlink-Übertragung, die an dem Endgerät endet, hinzuzufügen, und
um die zumindest eine der vielen einzelnen Protokollschichten in Uplink-Übertragung, die von dem Endgerät ausgeht, zu entfernen.
27. Endgerät nach Anspruch 22, wobei eine Kontextdefinition einen Diensttyp, Adressinformationen eines Endgeräts, für welches der Dienst implementiert ist, und eine Dienstqualitätsdefinition aufweist.
28. Endgerät nach Anspruch 22, wobei die Kontextdefinition zudem Filterinformationen, Zieladresse, Anwendungstypinformationen und den Typ des hinzuzufügenden Kopfabschnitts aufweist.
DE10131561A 2001-06-29 2001-06-29 Verfahren zur Übertragung von Anwendungspaketdaten Withdrawn DE10131561A1 (de)

Priority Applications (7)

Application Number Priority Date Filing Date Title
DE10131561A DE10131561A1 (de) 2001-06-29 2001-06-29 Verfahren zur Übertragung von Anwendungspaketdaten
PCT/IB2002/003883 WO2003003652A2 (en) 2001-06-29 2002-04-25 A method for transmitting application packet data
AT02780926T ATE300826T1 (de) 2001-06-29 2002-04-25 Verfahren zum senden von anwendungspaketdaten
US10/481,756 US20040148425A1 (en) 2001-06-29 2002-04-25 Method for transmitting application packet data
EP02780926A EP1413099B1 (de) 2001-06-29 2002-04-25 Verfahren zum senden von anwendungspaketdaten
DE60205260T DE60205260D1 (de) 2001-06-29 2002-04-25 Verfahren zum senden von anwendungspaketdaten
AU2002334299A AU2002334299A1 (en) 2001-06-29 2002-04-25 A method for transmitting application packet data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10131561A DE10131561A1 (de) 2001-06-29 2001-06-29 Verfahren zur Übertragung von Anwendungspaketdaten

Publications (1)

Publication Number Publication Date
DE10131561A1 true DE10131561A1 (de) 2003-01-16

Family

ID=7690025

Family Applications (2)

Application Number Title Priority Date Filing Date
DE10131561A Withdrawn DE10131561A1 (de) 2001-06-29 2001-06-29 Verfahren zur Übertragung von Anwendungspaketdaten
DE60205260T Expired - Lifetime DE60205260D1 (de) 2001-06-29 2002-04-25 Verfahren zum senden von anwendungspaketdaten

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60205260T Expired - Lifetime DE60205260D1 (de) 2001-06-29 2002-04-25 Verfahren zum senden von anwendungspaketdaten

Country Status (6)

Country Link
US (1) US20040148425A1 (de)
EP (1) EP1413099B1 (de)
AT (1) ATE300826T1 (de)
AU (1) AU2002334299A1 (de)
DE (2) DE10131561A1 (de)
WO (1) WO2003003652A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004107701A1 (de) * 2003-05-27 2004-12-09 Hans Wulff, Volker Kanitz, Alireza Assadi Gbr Verfahren und system zur übertragung von sprachinformationen zwischen mindestens zwei teilnehmern

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8266677B2 (en) * 2000-12-20 2012-09-11 Intellisync Corporation UDP communication with a programmer interface over wireless networks
FR2840758B1 (fr) * 2002-06-11 2004-11-26 Evolium Sas Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles
US7920590B2 (en) * 2002-07-12 2011-04-05 Spyder Navigations L.L.C. Wireless communications system having built-in packet data compression and support for enabling non-standard features between network elements
US7593716B2 (en) * 2003-02-28 2009-09-22 Siemens Aktiengesellschaft Method for transmitting data in a WLAN network
DE50308295D1 (de) * 2003-02-28 2007-11-08 Siemens Ag Verfahren zur übertragung von daten in einem wlan-netz
JP4173517B2 (ja) * 2003-03-05 2008-10-29 インテリシンク コーポレイション コンピューティング・ネットワークとリモート装置との間のバーチャル・プライベート・ネットワーク
GB0306863D0 (en) * 2003-03-25 2003-04-30 Nokia Corp Service provisioning in a communication system
US7849130B2 (en) * 2003-04-30 2010-12-07 International Business Machines Corporation Dynamic service-on-demand delivery messaging hub
GB2403097A (en) * 2003-06-16 2004-12-22 Orange Personal Comm Serv Ltd Communicating internet packets having care-of-address as destination address to a mobile node
US9160714B2 (en) * 2003-06-30 2015-10-13 Telefonaktiebolaget L M Ericsson (Publ) Using tunneling to enhance remote LAN connectivity
US9614772B1 (en) * 2003-10-20 2017-04-04 F5 Networks, Inc. System and method for directing network traffic in tunneling applications
US7185091B2 (en) * 2003-11-20 2007-02-27 Motorola, Inc. Method and system for transmitting compressed messages at a proxy to a mobile device in a network
US20060056379A1 (en) * 2004-09-14 2006-03-16 Motorola, Inc. System and method for network-assisted connection in a wireless environment
US20060083242A1 (en) * 2004-10-20 2006-04-20 Nokia Corporation Address modification in application servers
TWI272811B (en) * 2004-12-23 2007-02-01 Mediatek Inc Method of negotiation for IP configuration, machine readable medium thereof, and terminal equipment and mobile terminal utilizing same
FI20050187A0 (fi) * 2005-02-17 2005-02-17 Nokia Corp Kuljetuspalveluun liittyvän informaation tuottaminen pakettidataverkossa
US8418233B1 (en) 2005-07-29 2013-04-09 F5 Networks, Inc. Rule based extensible authentication
US8533308B1 (en) 2005-08-12 2013-09-10 F5 Networks, Inc. Network traffic management through protocol-configurable transaction processing
CN100488284C (zh) * 2006-01-26 2009-05-13 华为技术有限公司 一种3gpp演进网络中漫游用户数据路由优化方法
US8565088B1 (en) 2006-02-01 2013-10-22 F5 Networks, Inc. Selectively enabling packet concatenation based on a transaction boundary
US8332926B2 (en) * 2006-05-12 2012-12-11 Qualcomm Incorporated Efficient modification of packet filters in a wireless communication network
US7890636B2 (en) * 2006-06-28 2011-02-15 Cisco Technology, Inc. Application integrated gateway
KR100809019B1 (ko) * 2006-12-06 2008-03-03 한국전자통신연구원 이동통신 시스템에서의 룩-어헤드 대역 요구 방법 및 그방법을 수행하는 이동 단말기
CA2577030A1 (en) * 2007-01-31 2008-07-31 Unlimi-Tech Software Inc. Improved data transfer method, system and protocol
US9106606B1 (en) 2007-02-05 2015-08-11 F5 Networks, Inc. Method, intermediate device and computer program code for maintaining persistency
US20080298354A1 (en) 2007-05-31 2008-12-04 Sonus Networks, Inc. Packet Signaling Content Control on a Network
US8553554B2 (en) * 2008-05-16 2013-10-08 Alcatel Lucent Method and apparatus for providing congestion control in radio access networks
US9832069B1 (en) 2008-05-30 2017-11-28 F5 Networks, Inc. Persistence based on server response in an IP multimedia subsystem (IMS)
US20090296613A1 (en) * 2008-06-03 2009-12-03 Colin Kahn Method and apparatus for providing quality-of-service in radio access networks
US9130846B1 (en) 2008-08-27 2015-09-08 F5 Networks, Inc. Exposed control components for customizable load balancing and persistence
US8503432B2 (en) * 2008-09-30 2013-08-06 Alcatel Lucent Method and apparatus for signaling proprietary information between network elements of a core network in a wireless communication network
US9769287B2 (en) * 2010-05-10 2017-09-19 Telefonaktiebolaget Lm Ericsson (Publ) Reducing protocol overhead in single-block packet access procedures
JP5551061B2 (ja) * 2010-12-27 2014-07-16 株式会社Ｐｆｕ 情報処理装置、アドレス重複対処方法およびアドレス重複対処用プログラム
CN102595375B (zh) * 2011-01-07 2015-08-12 中兴通讯股份有限公司 漫游用户与归属地间分组交换业务的实现方法及系统
CN102595367B (zh) * 2011-01-07 2015-01-28 中兴通讯股份有限公司 漫游用户与归属地间分组交换业务的实现方法及系统
US20120182934A1 (en) * 2011-01-18 2012-07-19 John Diachina Application layer communication via an intermediate node
US8719926B2 (en) * 2011-02-11 2014-05-06 Verizon Patent And Licensing Inc. Denial of service detection and prevention using dialog level filtering
US9894692B2 (en) * 2011-10-06 2018-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Transmission of data to or from a node of a mobile network
US20130258929A1 (en) * 2012-04-03 2013-10-03 T-Mobile Usa, Inc. Rule-Based Application Controller for Signaling Reduction
US10560882B2 (en) * 2012-06-08 2020-02-11 Blackberry Limited Method and apparatus for multi-rat transmission
CN103517266B (zh) 2012-06-29 2017-03-22 国际商业机器公司 移动网络侧激活移动终端的方法和移动网关系统
US9237482B2 (en) * 2012-12-31 2016-01-12 Alcatel Lucent Method of transmitting real time traffic with reduced header in wireless network
US9825884B2 (en) 2013-12-30 2017-11-21 Cavium, Inc. Protocol independent programmable switch (PIPS) software defined data center networks
US10616380B2 (en) 2014-06-19 2020-04-07 Cavium, Llc Method of handling large protocol layers for configurable extraction of layer information and an apparatus thereof
US9635146B2 (en) 2014-06-19 2017-04-25 Cavium, Inc. Method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof
EP3282721B1 (de) * 2015-04-07 2021-06-23 Sharp Kabushiki Kaisha Endgerätevorrichtung, pgw und twag
WO2016190641A1 (ko) * 2015-05-22 2016-12-01 엘지전자(주) 무선 통신 시스템에서 데이터 송수신 방법 및 이를 위한 장치
DK3286954T3 (da) * 2015-08-21 2019-05-20 Ericsson Telefon Ab L M Kommunikation af ikke-ip-data over pakkedatanetværk
US10027627B2 (en) * 2015-10-07 2018-07-17 Cisco Technology, Inc. Context sharing between endpoint device and network security device using in-band communications

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870474A (en) * 1995-12-04 1999-02-09 Scientific-Atlanta, Inc. Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providers
JP3636399B2 (ja) * 1996-05-29 2005-04-06 富士通株式会社 プロトコル変換システム及びプロトコル変換方法
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
JP3397144B2 (ja) * 1998-09-29 2003-04-14 日本電気株式会社 パケット処理装置とパケット処理方法とパケット交換機
FI107770B (fi) * 1999-06-07 2001-09-28 Nokia Mobile Phones Ltd PDP-kontekstien hallinta matkaviestimessä
FI111436B (fi) * 1999-06-14 2003-07-15 Nokia Corp Menetelmä ja järjestelmä PDP-kontekstien palvelutarkoituksen ilmaisemiseksi
DE20023936U1 (de) * 2000-05-17 2007-09-27 Matsushita Electric Works, Ltd. Hybride ARQ-Sende- und Empfangsvorrichtung
US7072329B2 (en) * 2000-05-22 2006-07-04 Telefonaktiebolaget Lm Ericsson (Publ) Combining differing transport technologies in a telecommunications system
US7315554B2 (en) * 2000-08-31 2008-01-01 Verizon Communications Inc. Simple peering in a transport network employing novel edge devices
US6985459B2 (en) * 2002-08-21 2006-01-10 Qualcomm Incorporated Early transmission and playout of packets in wireless communication systems

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004107701A1 (de) * 2003-05-27 2004-12-09 Hans Wulff, Volker Kanitz, Alireza Assadi Gbr Verfahren und system zur übertragung von sprachinformationen zwischen mindestens zwei teilnehmern

Also Published As

Publication number Publication date
EP1413099A2 (de) 2004-04-28
AU2002334299A1 (en) 2003-03-03
WO2003003652A3 (en) 2003-03-13
DE60205260D1 (de) 2005-09-01
WO2003003652A2 (en) 2003-01-09
ATE300826T1 (de) 2005-08-15
EP1413099B1 (de) 2005-07-27
US20040148425A1 (en) 2004-07-29

Similar Documents

Publication Publication Date Title
DE10131561A1 (de) Verfahren zur Übertragung von Anwendungspaketdaten
DE19742681C2 (de) GPRS-Teilnehmerauswahl von mehreren Internet-Dienstanbietern
DE60216791T2 (de) Adressenübergang und korrelation von nachrichten zwischen netzknoten
DE69634690T2 (de) Paketfunksystem und verfahren zur protokollunabhängigen wegesuche eines datenpakets in paketfunknetzen
EP1861982B1 (de) Verfahren und system zur aktivierung eines kontextes für ein packetdatenprotokoll
EP1391081B1 (de) Heterogenes mobilfunksystem
DE60131572T2 (de) Zugriffssystem fur ein zellulares netzwerk
DE69934734T2 (de) Mehrstrecken Punkt-zu-Punkt Protokoll
US8971246B2 (en) Packet radio network and method
EP1226692B2 (de) Verfahren zum betreiben eines mobilfunknetzes
EP1869841B1 (de) Herstellen eines gemeinsamen pdp-kontexts zur bereitstellung einer ip-multimedia-kommunikationssitzung für ein mobilfunk-endgerät
DE60312184T2 (de) Verfahren eines gateways zum auswählen eines kanals zur übertragung von datenpaketen
WO2003105435A1 (de) Verfahren und vorrichtung zum übertragen von ip-paketen zwischen einem radio network controller (rnc) und einer weiteren einrichtung eines mobilfunknetzwerkes
DE60130498T2 (de) Verfahren und vorrichtung zur trägerberechtigung in einem drahtlosen kommunikationsnetzwerk
WO2007068613A1 (de) Verfahren zur übertragung von auf dem ethernet-übertragungsprotokoll basierenden datenpaketen zwischen zumindest einer mobilen kommunikationseinheit und einem kommunikationssystems
DE60012168T2 (de) Verfahren und anordnung zur übertragung multimediabezogener information in einem paketvermittelten zellularen funknetz mit externer verbindung
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
DE102010028974A1 (de) Bereitstellung einer Ende-zu-Ende-Verbindung von einer Endeinheit in ein Netz
DE69935863T2 (de) Mobilendgerät und drahtloses gerät mit gemeinsamer ip-adresse
DE202006010953U1 (de) Drahtloses Kommunikationssystem zum Implementieren eines fortentwickelten Systemanschlußverfahrens
DE60318755T2 (de) Verfahren für ein gateway zum auswählen eines kanals zur übertragung von datenpaketen
WO2003085920A2 (de) Verfahren zur übertragung von informationen über ip-netzwerke
DE102005014852A1 (de) Entscheidung zur Zuordnung und Ressourcenvergabe für mindestens einem Datenstrom und mindestens eine Nutzverbindung
WO2003036995A2 (de) Verfahren zur durchführung von augenblicklichem nachrichtenverkehr (instant messaging) mit paketvermittelten daten
DE102005024122A1 (de) Funk-Kommunikationseinrichtung, funkbasiertes Kommunikationsendgerät und Chipkarte

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee