[go: up one dir, main page]

DE60115967T2 - Eine methode für handhabung von meldungen zwischen einem terminal und einem datennetz - Google Patents

Eine methode für handhabung von meldungen zwischen einem terminal und einem datennetz Download PDF

Info

Publication number
DE60115967T2
DE60115967T2 DE60115967T DE60115967T DE60115967T2 DE 60115967 T2 DE60115967 T2 DE 60115967T2 DE 60115967 T DE60115967 T DE 60115967T DE 60115967 T DE60115967 T DE 60115967T DE 60115967 T2 DE60115967 T2 DE 60115967T2
Authority
DE
Germany
Prior art keywords
message
data network
protocol
messages
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.)
Expired - Lifetime
Application number
DE60115967T
Other languages
English (en)
Other versions
DE60115967D1 (de
Inventor
Markus ISOMÄKI
Tuija Hurtta
Serge Haumont
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.)
Intellectual Ventures I LLC
Original Assignee
Nokia Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Inc filed Critical Nokia Inc
Application granted granted Critical
Publication of DE60115967D1 publication Critical patent/DE60115967D1/de
Publication of DE60115967T2 publication Critical patent/DE60115967T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/30—Routing of multiclass traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security 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/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Telephonic Communication Services (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung betrifft ein Verfahren zum Handhaben von Nachrichten zwischen einem Endgerät und einem Datennetzwerk ebenso wie eine entsprechende Netzwerksteuerinstanz und einen Netzwerkzugangsknoten sowie ein Datennetzwerk.
  • HINTERGRUND DER ERFINDUNG
  • In letzter Zeit haben Kommunikationstechnik und Datennetzwerke einen erheblichen Fortschritt erfahren. Datennetzwerke zum Übertragen von Daten entweder über feste Leitungen oder zur drahtlosen Übertragung finden zunehmende Aufmerksamkeit. Auch Daten- und/oder Kommunikationsnetzwerke, die drahtlose und drahtgebundene Kommunikation kombinieren, befinden sich in Entwicklung. Ein Beispiel für ein derartiges Netzwerk ist das UMTS-("Universal Mobile Telecommunication Standard")Netzwerk, das sich zurzeit in Entwicklung befindet und von 3GPP ("3rd Generation Partnership Project") standardisiert wird. Das UMTS-Netzwerk der 3GPP-Version 5 ermöglicht neben verschiedenen anderen Diensten Telefonie unter Verwendung des Internetprotokolls (IP) (VoIP, "Voice over IP") oder Datenübertragung unter Verwendung des Internetprotokolls.
  • Die Bezugnahme auf das UMTS-Netzwerk ist jedoch nicht dazu bestimmt, die Erfindung einzuschränken, und die Erfindung wie hierin nachstehend beschrieben kann gleichermaßen in anderen ähnlichen Netzwerken verwendet werden. Um die der Erfindung zu Grunde liegenden Prinzipien deutlich zu beschreiben, wird jedoch auf die UMTS-Netzwerkarchitektur als Beispiel Bezug genommen.
  • Im Allgemeinen werden Daten (Sprache oder andere Daten) in dem UMTS-Netzwerk in Einheiten von Paketen übertragen. Ein Endgerät und/oder eine Teilnehmervorrichtung UE kommuniziert mit einem durch einen APN ("Access Point Name": Zugangspunktname) identifizierten Zugangsknoten des Netzwerks, wobei der Knoten zum Beispiel ein GGSN-Knoten ("Gateway GPRS Support Node": Gateway-GPRS-Unterstützungsknoten, GPRS: "General Packet Radio Service") sein kann. Ein Zugangsknoten meint hier einen Eingangsknoten zu dem Netzwerkteil, der Dienste bereitstellt und unabhängig von der eigentlichen Verbindungstechnologie ist, d.h. einen Eingangspunkt zum Kernnetzwerk. Zwischen dem Zugangsknoten und dem Endgerät ist ein Zugangsnetzwerk angeordnet, das im Fall eines mobilen/drahtlosen Zugangs ein Funkzugangsnetzwerk aufweist, welches aus Funknetzwerksteuerungen RNC und Knoten B's (die jeweils GSM-Basisstationssteuerungen und -Basisstationen entsprechen) besteht. Da das Zugangsnetzwerk bei der vorliegenden Erfindung jedoch nicht behandelt wird, wird die ausführliche Beschreibung von diesem weggelassen.
  • Der Zugangspunkt knoten, d.h. GGSN, ist zum Kommunizieren mit einer Rufzustandssteuerungs-Funktionsinstanz CSCF angepasst. In dem das Endgerät momentan bedienenden Netzwerkteil ist dies im Allgemeinen eine sogenannte Proxy-CSCF, d.h. P-CSCF. Jedes Endgerät hat eine Dienst-CSCF zugewiesen, S-CSCF, die sich in dem "Heimat"-Netzwerk des das Endgerät verwendenden Teilnehmers befindet. Die CSCF ist wiederum mit einer HSS-Instanz verbunden, Heimatteilnehmerserver, die funktional weitgehend einem HLR bei GSM ("Home Location Register": Heimataufenthaltsverzeichnis) entspricht.
  • Mit dem Fortschritt in der Datennetzwerktechnik können von dem (Kern-) Netzwerk dem an diesem angemeldeten bzw. registrierten Endgerät immer mehr unterschiedliche Dienste bereitgestellt werden. Ein Endgerät UE wird durch eine Adresse identifiziert/adressiert, an die die Dienste bereitgestellt werden. Eine solche Adresse wird als PDP-Adresse (Paketdatenprotokoll) bezeichnet. Für eine derartige Adresse können mehrere Kontexte, d.h. PDP-Kontexte, definiert sein. Jeder Kontext kann aktiv oder inaktiv sein. Ein Kontext wie etwa ein PDP-Kontext hat als Merkmale/Parameter einen den verwendeten Protokolltyp identifizierenden PDP-Typ, die PDP-Adresse selbst als die Adresse des Protokolls, ein Dienstgüte-(QoS: "Quality of Service")Profil, das eine Standard-QoS für diesen PDP-Kontext festlegt, und eine GGSN-Adresse bzw. einen APN (Zugangspunktnamen), die/der den Zugangspunkt des Endgeräts zum Netzwerk festlegt, d.h. eine logische Adresse des Knotens und/oder Servers, der diesen PDP-Kontext gerade bedient.
  • Es wird bemerkt, dass die Erfindung nicht auf PDP-Kontexte beschränkt ist, sondern jedes ähnliche Konzept gleichermaßen in Verbindung mit der Erfindung anwendbar ist, solange es sich um eine "Protokollumgebung" und/oder einen Kontext handelt.
  • Demnach wird für ein über einen speziellen APN/GGSN unter Verwendung eines speziellen Protokolls kommunizierendes Endgerät eine spezielle QoS festgelegt. Ein Beispiel eines derartigen Protokolls ist das Sitzungseinleitungsprotokoll SIP. (Ein weiteres Beispiel wäre WRP, "Wireless Application Protocol": Drahtlosanwendungsprotokoll.) Um die Erklärung einfach zu halten, konzentriert sich die nachfolgende Beschreibung jedoch auf SIP, während dies als die Erfindung nicht einschränkend zu betrachten ist.
  • SIP ist ein vielseitiges Protokoll. Einerseits wird es zum Aufbauen von Telefonrufen verwendet (wobei zu beachten ist, dass SIP nicht die Sprache selbst transportiert), wenn eine schnelle und zuverlässige Lieferung von Signalisierungsnachrichten entscheidend ist (QoS = Echtzeit (RT)). Andererseits kann es zum Transportieren von Objekten und zum Einleiten von Diensten verwendet werden, die keine schwierigen Echtzeit-Lieferanforderungen aufweisen, wie etwa "Instant Messaging" bzw. sofortige Nachrichtenübermittlung, Präsenz- bzw. Anwesenheitsaktualisierungen (z.B. Aufenthaltsbereichsaktualisierungen) oder Push-Dienste. ("Push-Dienst" ist gedacht, jeden Dienst zu meinen, der irgendwelche Inhalte asynchron sendet, ohne dass diese von der Empfangsseite angefordert sind.)
  • Bei 3GPP-Version 5 kann ein Signalisierungs-PDP-Kontext zum Transportieren von SIP-Signalisierung zwischen UE und P-CSCF verwendet werden. Der Signalisierungs-PDP-Kontext kann eine erhöhte bzw. verbesserte QoS erfordern, wie z.B. eine höhere Priorität als andere PDP-Kontexte. Eine erhöhte QoS ist für SIP-Sitzungsaufbaunachrichten wichtig, aber nicht für alle SIP-Nachrichten. Zum Beispiel müssen SIP-Nachrichten, die für Push-Dienste verwendet werden, nicht unter Verwendung der erhöhten QoS transportiert werden, die von dem Signalisierungs-PDP-Kontext bereitgestellt wird.
  • Dies führt dazu, dass eine SIP-Verkehrsmenge ziemlich groß ist, und macht eine Signalisierungs-PDP-Bereitstellung schwierig, da alle SIP-Nachrichten ungeachtet ihrer tatsächlichen Anforderungen in ähnlicher Weise behandelt werden müssen. Das Problem wird besonders dann bedeutsam werden, wenn GERAN- (GSM/EDGE-RAN, EDGE = "Enhanced Data Rates for GSM Evolution", RAN = "Radio Access Network", GSM = "Global Standard of Mobile Communication") Zugangstechnologie verwendet wird.
  • Die Druckschrift WO-00/70825 offenbart eine Verwendung von GPRS-Signalisierung, d.h. dieser Stand der Technik beschreibt nur eine Überwachung einer Rufherstellungsnachricht oder einer Verbindungszustandsänderung und aktiviert oder modifiziert basierend darauf einen PDP-Kontext. Im Rahmen von Fachwissen in Bezug auf GPRS-Signalisierung in Verbindung mit einer PDP-Kontextaktivierung gelten die folgenden Definitionen für ein System/Verfahren gemäß dem Stand der Technik: GPRS definiert unterschiedliche PDP-Typen, das heißt auf GPRS transportierte Protokolle. Ein PDP-Kontext ist eine Instanz bzw. ein Fall eines PDP-Typs. Dies bedeutet wiederum, dass jeder aktive PDP-Kontext eines bestimmten PDP-Typs eine (PDP-) Adresse aufweist, die für das Endgerät des Teilnehmers reserviert ist. Obgleich mehrere PDP-Kontexte nebeneinander aktiv sein können, bedeutet dies, dass ein Teilnehmer bis zu einer entsprechenden Anzahl dieser mehreren Adressen gleichzeitig in Verwendung haben kann. Kurz gesagt müssen separate PDP-Kontexte unterschiedliche Adressen verwenden. Bevor irgendeine Teilnehmerdatenlieferung möglich ist, muss ein geeigneter PDP-Kontext aktiviert werden, möglicherweise mit einer entsprechenden Endteilnehmeradresse.
  • Weiterer Stand der Technik ist aus der Druckschrift WO-99/48310-A bekannt.
  • KURZFASSUNG DER ERFINDUNG
  • Folglich ist es eine Aufgabe der Erfindung, ein verbessertes Verfahren zum Handhaben von Nachrichten zwischen einem Endgerät und einem Datennetzwerk vorzuschlagen, das die vorstehenden Probleme löst, ebenso wie eine entsprechende Netzwerksteuerinstanz und einen Netzwerkzugangsknoten sowie ein Datennetzwerk.
  • Gemäß der Erfindung wird diese Aufgabe zum Beispiel durch ein Verfahren zum Handhaben von Nachrichten zwischen einem Endgerät und einem Datennetzwerk wie gemäß Anspruch 1 definiert erreicht.
  • Außerdem wird diese Aufgabe gemäß der Erfindung zum Beispiel durch eine Datennetzwerk-Steuerinstanz wie gemäß Anspruch 13 definiert erreicht.
  • Gemäß der Erfindung wird diese Aufgabe zum Beispiel durch einen Datennetzwerk-Zugangsknoten wie gemäß Anspruch 18 definiert erreicht.
  • Gemäß einer vorteilhaften Weiterbildung dieses Knotens ist der Leitweglenkungsindikator, auf den diese Markierung abgebildet wird, eine Verkehrsflussvorlage TFT.
  • Außerdem wird diese Aufgabe gemäß der Erfindung zum Beispiel auch durch ein Datennetzwerk wie gemäß Anspruch 20 definiert erreicht.
  • Weitere vorteilhafte Weiterbildungen der Erfindung sind in den entsprechenden abhängigen Ansprüchen dargelegt.
  • Mittels der Erfindung können, wenn sie in einem Datennetzwerk implementiert wird, die folgenden Vorteile erreicht werden:
    • – es kann vermieden werden, dass der ganze SIP-Verkehr über einen Signalisierungs-PDP-Kontext verläuft,
    • – die Verwendung von SIP-Signalisierungsnachrichten kann gesteuert werden,
    • – werden nicht mit Signalisierung (z.B. nicht mit Rufherstellung) in Bezug stehende SIP-Nachrichten verwendet, kann dafür gesorgt werden, dass diese über einen Nicht-Signalisierungs-PDP-Kontext verlaufen,
    • – PDP-Kontexte können basierend auf Differenzierter-Dienst-Codepunkten (DiffServ-Codepunkten und/oder DS-Codepunkten) unterschieden werden und QoS für unterschiedliche SIP-Nachrichten kann basierend auf den DiffServ-Codepunkten zugeordnet werden,
    • – Echtzeitverkehr kann von Nicht-Echtzeitverkehr im Hinblick auf den für den entsprechenden Verkehr verwendeten Kontext getrennt werden,
    • – Nachrichten eines speziellen Protokolltyps können daher an mehrere gleichzeitige Kontexte verteilt werden,
    • – das Endgerät kann über die Paketmarkierungspraxis des Netzwerks informiert werden.
  • Mit anderen Worten werden gemäß der Erfindung SIP-Nachrichten, die keine erhöhte QoS (wie für eine (Echtzeit-) Signalisierung erforderlich) benötigen, nicht auf dem Signalisierungs-PDP-Kontext transportiert. Das UE kann für diese Nachrichten (die eine Nicht-Echtzeit-QoS erfordern) einen anderen PDP-Kontext aktivieren. Das UE wird von dem Netzwerk jedoch mit Informationen versorgt, um die Verkehrsflussvorlagen TFTs dieser PDP-Kontexte richtig einzustellen. Mit richtigen TFTs kann GGSN/APN Echtzeit-QoS erfordernde SIP-Nachrichten, z.B. die mit einem Sitzungsaufbau in Bezug stehenden, auf einem unterschiedlichen PDP-Kontext senden als SIP-Nachrichten, die keine Echtzeit-QoS erfordern, z.B. die mit anderen Diensten (wie etwa Push-Diensten) in Bezug stehenden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird anschließend unter Bezugnahme auf Beispiele ausführlich beschrieben, wie sie in den begleitenden Zeichnungen veranschaulicht sind, bei denen zeigen:
  • 1 schematisch eine Teilnehmervorrichtung und Netzwerkinstanzen, die in Verbindung mit der Erfindung beteiligt sind, und entsprechende Signalisierung/Verfahrensschritte;
  • 2 ein erstes Signalisierungsszenario in Verbindung mit der Erfindung zum richtigen Einstellen von TFTs;
  • 3 ein zweites Signalisierungsszenario in Verbindung mit der Erfindung zum richtigen Einstellen von TFTs; und
  • 4 ein drittes Signalisierungsszenario in Verbindung mit der Erfindung zum richtigen Einstellen von TFTs.
  • AUSFÜHRLICHE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
  • Im Anschluss wird die Erfindung beispielhaft unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
  • Wie aus dem Vorstehenden ableitbar betrifft die Erfindung dementsprechend ein Verfahren zum Handhaben von Nachrichten zwischen einem Endgerät und einem (z.B. durch einen Netzwerkknoten wie etwa eine P-CSCF dargestellten) Datennetzwerk, wobei Nachrichten eines speziellen Protokolls (z.B. SIP-Nachrichten) unter Verwendung festgelegter spezieller Kontexte (z.B. PDP-Kontexte) für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll (SIP) basierende Nachrichten (SIP-Signalisierungsnachrichten (mit Echtzeit-QoS-Anforderungen) und/oder SIP-Nutzlastliefernachrichten (ohne Echtzeit-QoS-Anforderungen) wie etwa SIP-Push) auf unterschiedliche Dienstkategorien beziehen, nämlich auf einen Signalisierungs-(Echtzeit-)Dienst beziehungsweise Liefer-(Nicht-Echtzeit-)Dienste.
  • Gemäß der Erfindung wird eine Nachricht am Netzwerk empfangen, wird die Dienstkategorie dieser empfangenen Nachricht analysiert (Signalisierung/Echtzeit oder Nicht-Echtzeit) und wird dieser Nachricht abhängig von der analysierten Dienstkategorie ein spezieller Kontext zugeordnet.
  • Unterschiedliche SIP-Nachrichten und sogar Nutzlasttypen werden mit unterschiedlichen QoS transportiert. Im Speziellen bedeutet dies, dass z.B. in einer 3G-Umgebung nicht alle SIP-Nachrichten in einem Signalisierungs-PDP-Kontext transportiert werden müssen, sondern einige klassifiziert werden können, als Best-Effort-Daten bzw. Daten bestmöglicher Leistung (Nicht-Echtzeit-Verkehr) transportiert zu werden.
  • Gemäß der Erfindung kann dies zum Beispiel erreicht werden durch:
    • – Festlegen eines Profils für Teilnehmeragenten und Proxies (bei 3G: CSCFs), das die standardmäßigen QoS- Anforderungen für jeden SIP-Nachrichtentyp angibt, d.h. für rufbezogene Nachricht (zu Zwecken einer Rufversuchssignalisierung) oder für Best-Effort-Nachricht (für Datenlieferung, Nicht-Echtzeit) oder für beliebige andere Nachrichten, die nicht mit einer Rufversuchssignalisierung in Bezug stehen. Mit anderen Worten werden die Nachrichtennamen zum Beispiel auf Nachrichtentypen abgebildet, wobei diese Typen auf Dienstkategorien abgebildet werden.
  • Abhängig von dem Nachrichtentyp und/oder der Dienstkategorie (d.h. zum Beispiel einem Nachrichtennamen wie etwa SIP-INVITE) entscheidet die P-CSCF, dass ein Signalisierungs-PDP-Kontext erforderlich ist oder ein anderer PDP-Kontext erforderlich ist.
  • Zusätzlich kann ein Teilnehmer seine/ihre eigenen Richtlinien bzw. Strategien aufstellen, die beliebige in SIP-Nachrichten transportierte Informationen einsetzen, und auf diese Weise die standardmäßigen Regeln bzw. Vorschriften überwinden, die von dem Netzwerkbetreiber eingestellt sind.
  • Ein derartiges Profil legt die Richtlinie bzw. Strategie für eine Handlung fest, die bezüglich der Nachricht durchzuführen ist. Die Richtlinie bzw. Strategie ist an der CSCF bekannt (wird an dieser im Voraus gespeichert) oder wird (z.B. von einem HSS) an die CSCF heruntergeladen und/oder aktualisiert, wenn sich ein Endgerät an dem Netzwerk anmeldet. Mit anderen Worten ist an einem diese Nachricht empfangenden Netzwerksknoten demnach für jeden Nachrichtentyp ein Profil festgelegt, das zum Zuweisen einer Dienstkategorie an jede empfangene Nachricht angepasst ist, und basiert das Analysieren der Nachricht auf diesem Profil. Der Knoten kann der Dienst- CSCF oder jeder andere Knoten innerhalb des Netzwerks sein, von dem erwartet wird, dass die Nachrichten über ihn verlaufen und/oder geleitet werden. Das Profil kann zum Analysieren von von einem Endgerät abgehenden Nachrichten sogar an einem Endgerät UE gespeichert sein.
  • Wahlweise und/oder zusätzlich ist es auch möglich, die Möglichkeit eines expliziten Hinweises auf den Diensttyp in den Nachrichten selbst zu ermöglichen. Dies kann z.B. durch Verwendung von Kopffeldern gemacht werden. Daher kann entweder ein neues Kopffeld definiert werden, das diesem Zweck dient (z.B. ein Ereignisfeld), und/oder können bestehende Kopffelder wie etwa die DiffServ-Codepunkte verwendet werden.
  • Ein DiffServ-Codepunkt (wobei DiffServ oder DS für Differenzierte-Dienste steht) ist ein 6 Bit-Feld im IP-Nachrichtenkopf jedes Pakets und der Inhalt von diesem legt fest, wie ein Paket von Leitweglenkungsknoten und/oder Netzwerkknoten, durch die das Paket verläuft, behandelt werden soll.
  • Demnach stellt das 6 Bit-Feld ein QoS-Attribut für das Paket (die Pakete) gemäß bisher bestehenden Standards dar (z.B. 3GPP TS 23.107 V3.4.0 (2000-10), Seite 31), was für den gleichen PDP-Kontext unterschiedliche anwendungsspezifische QoS-Stufen zulässt. Werden DiffServ-Codepunkte in Verbindung mit der Erfindung wie hierin beschrieben verwendet, ermöglichen DiffServ-Codepunkte abhängig von der Einstellung der DiffServ-Codepunkte jedoch sogar die Auswahl unterschiedlicher PDP-Kontexte. Demnach kann ein Einstellen von DiffServ-Bits gemäß dem erfassten/analysierten Diensttyp der empfangenen Nachricht als ein Markieren der Nachricht abhängig von einer analysierten Dienstkategorie unter Verwendung von DiffServ-Bits betrachtet werden.
  • Die von dem empfangenden Netzwerkknoten durchgeführte Analyse kann nicht nur auf dem Diensttyp basieren, sondern wahlweise und/oder zusätzlich auf den Quell- oder Zieladressparametern der Nachricht.
  • Es ist zu beachten, dass ein vorstehend erwähnter expliziter Hinweis sogar für unterschiedliche Nutzlasten (innerhalb des gleichen Nachrichtentyps) angewendet werden könnte. In diesem Fall könnte z.B. der empfangende Netzwerkknoten wie etwa die P-CSCF nicht vorrangige und/oder Nicht-Echtzeit-(NRT-)Nutzlast von einer ansonsten Echtzeit-(RT-)Nachricht abstreifen und sie mit einer adäquaten späteren Nachricht versenden oder einen Verweis auf sie als URL ("Uniform Resource Locator": Einheitlicher Ressourcenortsangeber) angeben.
  • Eine Verwendung der vorstehend genannten IP-DiffServ-Bits zum Bezeichnen der Dienstkategorie auf IP-Ebene wird nun ausführlicher dargelegt. Bestimmt zum Beispiel eine P-CSCF bei 3G, dass eine bestimmte SIP-Nachricht als Best-Effort (NRT-Typ-Dienstkategorie) behandelt werden soll, setzt/markiert sie die DiffServ-Bits dementsprechend. Im GGSN würde dies bewirken, dass das die SIP-Nachricht transportierende IP-Paket in einen anderen PDP-Kontext als das Signalisierungs-PDP klassifiziert würde, in diesem Fall für ein PDP der Best-Effort-Klasse. Dies bedeutet wiederum, dass das Endgerät UE z.B. wissen muss, welche DiffServ-Codepunkte von der CSCF verwendet werden, damit das Endgerät in der Lage ist, die TFTs an dem Zugangsknoten, d.h. GGSN, richtig einzustellen.
  • TFT bedeutet "Traffic Follow Template" bzw. Verkehrsflussvorlage und stellt einen Parameter dar, der aufgrund mehrerer PDP-Kontexte pro IP-Adresse (d.h. pro Endgerät) notwendig ist. Der TFT-Parameter wird in Aufwärtsstreckenrichtung (von dem Endgerät UE zum Netzwerk) geliefert, genauer gesagt von dem Endgerät zum GGSN als ein Zugangsknoten/Zugangspunktname APN des Netzwerks. Dem GGSN wird dann ermöglicht, Pakete basierend auf den TFTs an den richtigen PDP-Kontext zu leiten. Mit anderen Worten werden Pakete, die über den GGSN an das Endgerät zu liefern sind, basierend auf den TFTs in unterschiedliche PDP-Kontexte gedemultiplext bzw. entschachtelt. Demnach stellt die TFT einen Leitweglenkungsindikator dar, der zum selektiven Zuordnen eines speziellen Kontexts an die Nachricht angepasst ist. Der Leitweglenkungsindikator ist wiederum abhängig von der Markierung einzustellen. (DiffServ-Codepunkte werden auf die richtigen TFTs abgebildet und das Endgerät informiert den GGSN dementsprechend oder der GGSN weiß bereits, welche TFTs für welche DiffServ-Codepunkte zu verwenden sind, wie es nachstehend beschrieben wird.)
  • Wahlweise können in Verbindung mit der Erfindung anstelle von DiffServ-Codepunkten auch Transportprotokoll-Portnummern verwendet werden.
  • 1 zeigt beispielhaft eine Signalisierung und Verfahrensschritte gemäß der Erfindung. Für den Zweck von 1 sei angenommen, dass die TFTs in dem GGSN richtig eingestellt sind. (Eine Einstellung von TFTs wird hierin nachstehend in Verbindung mit 2 bis 4 ausführlich beschrieben.)
  • Wie gemäß 1 gezeigt empfängt das Netzwerk (hier der P-CSCF-Knoten) in Schritt S01 eine Nachricht wie etwa eine SIP-Nachricht. (Für den Zweck der Beschreibung der Erfindung ist der Ausgangspunkt der empfangenen Nachricht von untergeordnetem Interesse und eine Beschreibung von diesem wird daher weggelassen.) Die Nachricht wird in Schritt S02 analysiert, um die mit dieser Nachricht in Zusammenhang stehende Dienstkategorie zu bestimmen, z.B. Echtzeit/Signalisierungsdienst oder Nicht-Echtzeit. Basierend auf der Analyse markiert das Netzwerk (der P-CSCF-Knoten) Datenpakete dieser Nachricht durch Einstellen von Kopffeldinformationen in den Paketen, die die Dienstkategorie der Nachricht bezeichnen. (Dies kann für die Nachricht als Ganzes oder auf Basis einzelner Datenpakete für die in der Nachricht enthaltenen Pakete durchgeführt werden.) Die eingestellten Kopffeldinformationen sind wie vorstehend erläutert z.B. DiffServ-Codepunkte. In Schritt S04 werden die markierten Pakete der Nachricht zur Lieferung an das Endgerät, an das die Nachricht adressiert ist, an den GGSN weitergeleitet.
  • An dem GGSN werden die eingestellten Markierungen in Schritt S05 auf TFTs abgebildet. Unter der Annahme, dass eine Dienstkategorie "Signalisierung"/(Echtzeit-)Rufherstellung zu einer Markierung DiffServ 001010 geführt hat, während eine Dienstkategorie Nicht-Echtzeit (z.B. "Push") zu einer Markierung DiffServ 001110 geführt hat, wird dann zum Beispiel DiffServ 001010 auf TFT#1 abgebildet, während DiffServ 001110 auf TFT#2 abgebildet wird.
  • Basierend auf den auf diese Weise zugeordneten/abgebildeten TFTs für die Datenpakete weiß der GGSN dann, dass Pakete mit einer TFT als Leitweglenkungsindikator von TFT#1 unter Verwendung eines ersten PDP-Kontexts (PDP-Kontext#1) an das Endgerät zu leiten sind, während die anderen unter Verwendung eines anderen PDP-Kontexts, d.h. PDP-Kontext#2 in dem dargestellten Beispiel, an das Endgerät zu leiten sind. Beide PDP-Kontexte gehören zu der gleichen PDP-Adresse, die zwischen dem Endgerät und dem betreffenden GGSN festgelegt ist.
  • Demzufolge wird gemäß der Erfindung den Nachrichten abhängig von der analysierten Dienstkategorie ein spezieller Kontext zugeordnet.
  • Die Einstellung von TFTs wird nun in Verbindung mit 2 bis 4 beschrieben.
  • Im Allgemeinen, und wie vorstehend beschrieben wurde, aktiviert ein Endgerät UE einen Signalisierungs-PDP-Kontext für zum Sitzungsaufbau verwendete SIP-Nachrichten und einen anderen PDP-Kontext für SIP-Nachrichten, die für andere Dienste (z.B. Push-Dienste, "Instant Messaging", Präsenz oder dergleichen) verwendet werden. Die P-CSCF markiert zum Sitzungsaufbau verwendete SIP-Nachrichten anders als für andere Dienste verwendete SIP-Nachrichten. Die P-CSCF kennt die Dienste z.B. durch Überprüfung des in der SIP-Nachricht enthaltenen Ereignisparameters. Eine Markierung kann z.B. auf unterschiedlichen Quellportnummern, unterschiedlichen DiffServ-Codepunkten oder unterschiedlichen Flusskennzeichnungen basieren.
  • Das Endgerät UE muss Kenntnis von der Paketmarkierung haben (d.h., welche Pakete basierend auf der Dienstkategorie, auf die sie sich beziehen, in welcher Weise markiert sind), um TETs richtig einzustellen. Das Endgerät UE erhält diese Informationen von dem die Dienste bereitstellenden externen Netzwerk (d.h. in diesem Fall von dem IP-Multimedia-Subsystem wie zum Beispiel durch den P-CSCF-Knoten dargestellt).
  • Das Endgerät UE kann Informationen bezüglich der Paketmarkierung erhalten, wenn es einen Anwendungsserver (P-CSCF) in dem externen Netzwerk erstmals kontaktiert (z.B. gemäß 3 als Antwort (Schritt S24) auf eine REGISTER- oder eine SUBSCRIBE-Nachricht (Schritt S23)), oder wenn es den ersten PDP-Kontext in Richtung des externen Netzwerks aktiviert (2, Schritt S12 in Erwiderung auf Schritt S10). Typischerweise wird der erste PDP-Kontext ein Signalisierungs-PDP-Kontext in Richtung des IP-Mutimedia-Subsystems sein.
  • Ein Beispiel dieser Informationen wie vorstehend erwähnt ist "SIP-Echtzeit-Lieferung = DiffServ 001010, SIP-Nicht-Echtzeit-Lieferung = DiffServ 001110". Es ist zu beachten, dass in den Figuren "Echtzeit-Lieferung" durch das Beispiel "Sitzungsaufbau" dargestellt wird, während "Nicht-Echtzeit-Lieferung" durch Verweis auf "Push" beispielhaft gezeigt ist. Bei Empfang dieser Informationen kann das UE die TFTs richtig einstellen (d.h. den GGSN anweisen, die TFTs richtig einzustellen) und empfängt daher SIP-Nachrichten z.B. bezüglich Sitzungsaufbau auf einem anderen PDP-Kontext als SIP-Nachrichten z.B. bezüglich Push-Diensten.
  • Wie gemäß 2 dargestellt wird der GGSN in einer ersten PDP-Kontext-Aktivierungsantwort (Schritt S12) eine Liste von Diensten oder Anwendungs-IDs mit zusätzlichen Konfigurationsformationen für jeden Dienst einfügen (DiffServ-Codepunkte, Anwendungsserveradresse (z.B. Proxy-CSCF, Push-Proxy oder Präsenzserveradresse oder WAP-Gateway-Adresse oder Adresse von Server für "Instant Messaging")). Beim Anfordern einer PDP-Aktivierung für einen SIP-Nicht-Echtzeit-Dienst (z.B. "Push" wie gemäß Schritt S13 gezeigt) wird der GGSN dann von dem UE bezüglich der einzustellenden TFT und/oder der auf die so eingestellte TFT abzubildenden DiffServ-Codepunkte informiert und stellt die TFT dementsprechend ein (Schritt S14) [ähnlich zu Schritten S25 bis S27 gemäß 3].
  • Des Weiteren ist der GGSN implementiert (was in den Figuren nicht gezeigt ist), um das Endgerät UE zu aktualisieren, falls irgendwelche Parameter hinzugefügt oder modifiziert werden (z.B. ein neuer Dienst angeboten wird). Dies kann durch Senden einer Nachricht "Modifizieren PDP-Kontext" an alle UEs mit zumindest einem aktiven PDP-Kontext in diesem Zugangspunkt knoten implementiert werden.
  • Als eine gemäß 4 gezeigte Alternative kann der GGSN Zugangspunkt-spezifische Informationen bezüglich der Paketmarkierung für jeden Dienst aufweisen. Diese Informationen können am GGSN konfiguriert werden oder der GGSN kann diese Informationen von einem Richtlinien- bzw. Strategieserver (z.B. dem HSS) empfangen. Das Endgerät UE gibt bei PDP-Kontextaktivierung (S30, S33) den Dienst (SIP-Sitzungsaufbau/-Signalisierung/-Echtzeit, SIP-Push/-Nicht-Echtzeit) oder Anwendungs-ID(s) an und der GGSN stellt eine (für Abwärtsstreckenrichtung verwendete) TFT richtig ein (S31, S34). Zusätzlich kann der GGSN die für Aufwärtsstreckenverkehr verwendete TFT an das UE senden müssen.
  • Es ist wichtig zu beachten, dass viele Anwendungen den gleichen PDP-Kontext verwenden können, weshalb die MS bei der aktiven PDP-Anforderung eine Liste von Diensten oder Anwendungs-IDs angeben kann.
  • Auch wenn eine einen PDP-Kontext benötigende Anwendung aktiviert wird, überprüft das UE zuerst, ob ein geeigneter PDP-Kontext bereits aktiviert ist. Ist dies der Fall, fügt das UE unter Verwendung dieses PDP-Kontexts diese Anwendung zu der Liste von Anwendungen hinzu und wird, falls diese Anwendung Konfigurationsinformationen benötigt, an dem Netzwerk auf diese neue Anwendung mit einer Nachricht "Modifizieren PDP-Kontext" hinweisen. Ist keiner aktiviert, wird das UE einen passenden PDP-Kontext (möglicherweise einen sekundären) für diese Anwendung aktivieren und auf diese Anwendung in der PDP-Kontext-Aktivierungsanforderungsnachricht hinweisen. Es sollte beachtet werden, dass beim Einschalten des UE erwartet wird, dass viele Anwendungen automatisch aktiviert werden, und dass das UE die Liste aller Anwendungen, die sich einen bestimmten PDP-Kontext teilen, unverzüglich senden könnte.
  • Es ist zu beachten, dass die Erfindung, obwohl die vorstehende Beschreibung sich hauptsächlich auf einige spezielle Beispiele von Dienstkategorien konzentriert, nicht darauf beschränkt ist. Weitere Beispiele von Dienstkategorien können Echtzeit RT, Nicht-Echtzeit NRT, Signalisierung, Best-Effort, Push, WAP-Email, interaktiv, Hintergrund, "Instant Messaging" oder viele andere sein, solange sie im Hinblick auf Dienstgüte QoS unterscheidbar sein können. Auch die Anzahl von PDP-Kontexten muss nicht auf zwei beschränkt sein, wie es gemäß 1 gezeigt ist, sondern kann abhängig von der Anzahl unterschiedlicher Dienstkategorien, die von dem Endgerät UE gehandhabt werden können, auf n verallgemeinert werden. Ferner wurde SIP als ein bloßes Beispiel für ein Nachrichtenprotokoll gewählt und gleichermaßen könnten WAP-Nachrichten gehandhabt werden, ohne von der der Erfindung zu Grunde liegenden Idee abzuweichen.
  • Zusätzlich ist es selbstverständlich, dass die Erfindung, obwohl die vorstehende Beschreibung hauptsächlich im Hinblick auf das implementierte Verfahren angegeben wurde, auch ein entsprechend angepasstes Netzwerk betrifft, das zumindest eine Steuerinstanz CSCF und einen Zugangsknoten GGSN aufweist.
  • Genauer gesagt umfasst eine Datennetzwerk-Steuerinstanz (CSCF) zur Verwendung in einem Datennetzwerk, wobei Nachrichten eines speziellen Protokolls unter Verwendung festgelegter spezieller Kontexte für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll basierende Nachrichten auf unterschiedliche Dienstkategorien beziehen, eine Übertragungseinrichtung, die zum Empfangen einer Nachricht an der Netzwerkinstanz angepasst ist, eine Analyseeinrichtung, die zum Analysieren der Dienstkategorie der empfangenen Nachricht angepasst ist, eine Markierungseinrichtung, die zum Markieren von Paketen basierend auf einem Ergebnis der Analyse durch die Analyseeinrichtung angepasst ist, wobei die Übertragungseinrichtung zusätzlich zum Weiterleiten der markierten Pakete an einen Datennetzwerk-Zugangsknoten (GGSN) angepasst ist.
  • Weiter umfasst ein Datennetzwerk-Zugangsknoten (GGSN) zur Verwendung in einem Datennetzwerk, wobei Nachrichten eines speziellen Protokolls unter Verwendung festgelegter spezieller Kontexte für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll basierende Nachrichten auf unterschiedliche Dienstkategorien beziehen, eine Übertragungseinrichtung, die zum Empfangen markierter Pakete von einer Datennetzwerk-Steuerinstanz (CSCF) angepasst ist, eine Abbildungseinrichtung, die zum Abbilden einer Markierung eines empfangenen Pakets auf einen Leitweglenkungsindikator angepasst ist, und eine Zuordnungseinrichtung, die zum Zuordnen eines speziellen Kontexts an die Nachricht abhängig von dem abgebildeten Leitweglenkungsindikator angepasst ist.
  • Dementsprechend bezieht sich die Erfindung, wie es hierin vorstehend beschrieben wurde, auf ein Verfahren zum Handhaben von Nachrichten zwischen einem Endgerät und einem Datennetzwerk, wobei Nachrichten eines speziellen Protokolls unter Verwendung festgelegter spezieller Kontexte für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll basierende Nachrichten auf unterschiedliche Dienstkategorien beziehen, wobei das Verfahren die Schritte aufweist: Empfangen einer Nachricht am Netzwerk, Analysieren der Dienstkategorie der empfangenen Nachricht, und Zuordnen eines speziellen Kontexts an die Nachricht abhängig von der analysierten Dienstkategorie. Die Erfindung bezieht sich auch auf eine Netzwerksteuerinstanz, einen Zugangsknoten und ein Netzwerk, das diese aufweist.

Claims (25)

  1. Verfahren zum Handhaben von Nachrichten zwischen einem Endgerät und einem Datennetzwerk, wobei Nachrichten eines speziellen Protokolls unter Verwendung festgelegter spezieller Kontexte für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll basierende Nachrichten auf unterschiedliche Dienstkategorien beziehen, wobei das Verfahren die Schritte aufweist: Empfangen einer Nachricht am Netzwerk, Analysieren der Dienstkategorie der empfangenen Nachricht, und Zuordnen eines speziellen Kontexts an die Nachricht abhängig von der analysierten Dienstkategorie, dadurch gekennzeichnet, dass Kontexte für Nachrichten eines speziellen Protokolls auf einer gleichen Kontextadresse beruhen, die zwischen dem Endgerät und dem Datennetzwerk festgelegt ist.
  2. Verfahren gemäß Anspruch 1, bei dem das Zuordnen zusätzlich die Schritte aufweist: Markieren der Nachricht abhängig von der analysierten Dienstkategorie, und Einstellen eines Leitweglenkungsindikators abhängig von der Markierung, wobei der Leitweglenkungsindikator angepasst ist, der Nachricht selektiv den speziellen Kontext zuzuordnen.
  3. Verfahren gemäß Anspruch 2, bei dem das Markieren durch Einstellen von Kopffeldinformationen in der Nachricht auf einen der Dienstkategorie entsprechenden Wert ausgeführt wird.
  4. Verfahren gemäß Anspruch 3, bei dem das Markieren durch Einstellen von Differenzierter-Dienst-Codepunkten unter Verwendung des Differenzierter-Dienst-Bitfelds im Nachrichtenkopffeld ausgeführt wird.
  5. Verfahren gemäß Anspruch 2, bei dem das Markieren durch Einstellen von Transportprotokoll-Portnummern auf einen der Dienstkategorie entsprechenden Wert ausgeführt wird.
  6. Verfahren gemäß Anspruch 2, bei dem der Leitweglenkungsindikator, auf den die Markierung abgebildet wird, eine Verkehrsflussvorlage TFT ist.
  7. Verfahren gemäß Anspruch 1, bei dem die unterschiedlichen Dienstkategorien (RT, NRT) durch eine in der Nachricht enthaltene Diensttypkennung (SIP-SIGNALISIERUNG, SIP-PUSH) bezeichnet werden, und das Analysieren auf der Diensttypkennung basiert.
  8. Verfahren gemäß Anspruch 1, bei dem an einem die Nachricht empfangenden Netzwerkknoten für jeden Nachrichtentyp ein Profil definiert ist, das zum Zuweisen einer Dienstkategorie an jede empfangene Nachricht angepasst ist, und das Analysieren auf diesem Profil basiert.
  9. Verfahren gemäß Anspruch 1, bei dem ein Festlegen der speziellen Kontexte für Nachrichten des Protokolls den Schritt aufweist: Konfigurieren (S11; S21; S31; S14; S26; S34) eines Teils von Abbildungsinformationen (TFT-DS), die Markierungsinformationen an entsprechende Leitweglenkungsindikatorinformationen zuweisen, in Erwiderung auf eine Kontextaktivierungsanforderung (S10; S20; S30; S13; S25; S33) von dem Endgerät (UE) an einen Zugangsknoten (GGSN) des Datennetzwerks.
  10. Verfahren gemäß Anspruch 9, bei dem die Kontextaktivierungsanforderung (S10) an dem Zugangsknoten (GGSN) als eine erste Kontextaktivierungsanforderung erfasst wird und ein Konfigurieren (S11) basierend auf der Tatsache ausgeführt wird, dass eine erste Anforderung eine Anforderung nach einem vorbestimmten Kontext ist.
  11. Verfahren gemäß Anspruch 9, bei dem die Kontextaktivierungsanforderung (S20; S30; S33) den angeforderten Kontext bezeichnet und ein Konfigurieren (S21; S31; S34) basierend auf dem erfassten angeforderten Kontext ausgeführt wird.
  12. Verfahren gemäß Anspruch 9, zusätzlich mit den Schritten: Zurückgeben von Markierungsinformationen (S12; S24), die zum Markieren von Paketen verwendet werden, von dem Datennetzwerk an das Endgerät in Erwiderung auf eine vorhergehende Anforderung (S10; S23) von dem Endgerät an das Datennetzwerk, anschließendes Anfordern (S13; S25) der Aktivierung eines Kontexts unter Verwendung der im Zurückgabeschritt an das Endgerät zurückgegebenen Markierungsinformationen von dem Endgerät an das Datennetzwerk, und Konfigurieren (S14; S26) eines Teils von Abbildungsinformationen unter Verwendung der zurückgegebenen Markierungsinformationen.
  13. Datennetzwerk-Steuerinstanz (CSCF), wobei Nachrichten eines speziellen Protokolls unter Verwendung festgelegter spezieller Kontexte für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll basierende Nachrichten auf unterschiedliche Dienstkategorien beziehen, wobei die Instanz aufweist: eine Übertragungseinrichtung, die zum Empfangen einer Nachricht an der Netzwerkinstanz angepasst ist, eine Analyseeinrichtung, die zum Analysieren der Dienstkategorie der empfangenen Nachricht angepasst ist, eine Markierungseinrichtung, die zum Markieren von Paketen basierend auf einem Ergebnis der Analyse durch die Analyseeinrichtung angepasst ist, wobei die Übertragungseinrichtung zusätzlich zum Weiterleiten der markierten Pakete an einen Datennetzwerk-Zugangsknoten (GGSN) angepasst ist, und dadurch gekennzeichnet, dass Kontexte für Nachrichten eines speziellen Protokolls auf einer gleichen Kontextadresse beruhen, die zwischen einem Endgerät und dem Datennetzwerk-Zugangsknoten festgelegt ist.
  14. Instanz gemäß Anspruch 13, bei der die Markierungseinrichtung zusätzlich angepasst ist, die Nachricht abhängig von der analysierten Dienstkategorie zu markieren.
  15. Instanz gemäß Anspruch 14, bei der das Markieren durch Einstellen von Kopffeldinformationen in der Nachricht auf einen der Dienstkategorie entsprechenden Wert ausgeführt wird.
  16. Instanz gemäß Anspruch 15, bei der das Markieren durch Einstellen von Differenzierter-Dienst-Codepunkten unter Verwendung des Differenzierter-Dienst-Bitfelds im Nachrichtenkopffeld ausgeführt wird.
  17. Instanz gemäß Anspruch 14, bei der das Markieren durch Einstellen von Transportprotokoll-Portnummern auf einen der Dienstkategorie entsprechenden Wert ausgeführt wird.
  18. Datennetzwerk-Zugangsknoten (GGSN), wobei Nachrichten eines speziellen Protokolls unter Verwendung festgelegter spezieller Kontexte für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll basierende Nachrichten auf unterschiedliche Dienstkategorien beziehen, wobei der Knoten aufweist: eine Übertragungseinrichtung, die zum Empfangen markierter Pakete von einer Datennetzwerk-Steuerinstanz (CSCF) angepasst ist, eine Abbildungseinrichtung, die zum Abbilden einer Markierung eines empfangenen Pakets auf einen Leitweglenkungsindikator angepasst ist, und eine Zuordnungseinrichtung, die zum Zuordnen eines speziellen Kontexts an die Nachricht abhängig von dem abgebildeten Leitweglenkungsindikator angepasst ist, und dadurch gekennzeichnet, dass Kontexte für Nachrichten eines speziellen Protokolls auf einer gleichen Kontextadresse beruhen, die zwischen einem Endgerät und dem Datennetzwerk festgelegt ist.
  19. Zugangsknoten gemäß Anspruch 18, bei dem der Leitweglenkungsindikator, auf den die Markierung abgebildet wird, eine Verkehrsflussvorlage TFT ist.
  20. Datennetzwerk, mit zumindest einer Datennetzwerk-Steuerinstanz (CSCF), und zumindest einem Datennetzwerk-Zugangsknoten (GGSN), wobei Nachrichten eines speziellen Protokolls unter Verwendung festgelegter spezieller Kontexte für Nachrichten dieses Protokolls gehandhabt werden, und wobei sich auf dem gleichen speziellen Protokoll basierende Nachrichten auf unterschiedliche Dienstkategorien beziehen, wobei die Datennetzwerk-Steuerinstanz aufweist: eine Übertragungseinrichtung, die zum Empfangen einer Nachricht an der Netzwerkinstanz angepasst ist, eine Analyseeinrichtung, die zum Analysieren der Dienstkategorie der empfangenen Nachricht angepasst ist, eine Markierungseinrichtung, die zum Markieren von Paketen basierend auf einem Ergebnis der Analyse durch die Analyseeinrichtung angepasst ist, wobei die Übertragungseinrichtung zusätzlich zum Weiterleiten der markierten Pakete an einen Datennetz-Zugangsknoten (GGSN) angepasst ist, wobei der Datennetzwerk-Zugangsknoten aufweist: eine Übertragungseinrichtung, die zum Empfangen markierter Pakete von einer Datennetzwerk-Steuerinstanz (CSCF) angepasst ist, eine Abbildungseinrichtung, die zum Abbilden einer Markierung eines empfangenen Pakets auf einen Leitweglenkungsindikator angepasst ist, und eine Zuordnungseinrichtung, die zum Zuordnen eines speziellen Kontexts an die Nachricht abhängig von dem abgebildeten Leitweglenkungsindikator angepasst ist, dadurch gekennzeichnet, dass Kontexte für Nachrichten eines speziellen Protokolls auf einer gleichen Kontextadresse beruhen, die zwischen dem Endgerät und dem Datennetzwerk-Zugangsknoten festgelegt ist.
  21. Datennetzwerk gemäß Anspruch 20, bei dem der Leitweglenkungsindikator, auf den die Markierung abgebildet wird, eine Verkehrsflussvorlage TFT ist.
  22. Datennetzwerk gemäß Anspruch 20, bei dem die Markierungseinrichtung zusätzlich angepasst ist, die Nachricht abhängig von der analysierten Dienstkategorie zu markieren.
  23. Datennetzwerk gemäß Anspruch 22, bei dem das Markieren durch Einstellen von Kopffeldinformationen in der Nachricht auf einen der Dienstkategorie entsprechenden Wert ausgeführt wird.
  24. Datennetzwerk gemäß Anspruch 23, bei dem das Markieren durch Einstellen von Differenzierter-Dienst-Codepunkten unter Verwendung des Differenzierter-Dienst-Bitfelds in dem Nachrichtenkopffeld ausgeführt wird.
  25. Datennetzwerk gemäß Anspruch 22, bei dem das Markieren durch Einstellen von Transportprotokoll-Portnummern auf einen der Dienstkategorie entsprechenden Wert ausgeführt wird.
DE60115967T 2001-10-31 2001-10-31 Eine methode für handhabung von meldungen zwischen einem terminal und einem datennetz Expired - Lifetime DE60115967T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2001/012630 WO2003039080A1 (en) 2001-10-31 2001-10-31 A method for handling of messages between a terminal and a data network

Publications (2)

Publication Number Publication Date
DE60115967D1 DE60115967D1 (de) 2006-01-19
DE60115967T2 true DE60115967T2 (de) 2006-08-03

Family

ID=8164660

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60115967T Expired - Lifetime DE60115967T2 (de) 2001-10-31 2001-10-31 Eine methode für handhabung von meldungen zwischen einem terminal und einem datennetz

Country Status (5)

Country Link
US (1) US7406057B2 (de)
EP (1) EP1442565B1 (de)
AT (1) ATE313193T1 (de)
DE (1) DE60115967T2 (de)
WO (1) WO2003039080A1 (de)

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2547666C (en) 2003-12-01 2018-09-04 Interdigital Technology Corporation Session initiation protocol (sip) based user initiated handoff
JP4118800B2 (ja) * 2003-12-26 2008-07-16 ソフトバンクモバイル株式会社 プレゼンス表示システム及びゲートウエイ装置
US20060050683A1 (en) * 2004-09-09 2006-03-09 Nextel Communications, Inc. Prioritization of service requests received at a session initiation protocol (SIP) server
CN101167329B (zh) * 2005-04-28 2011-09-07 艾利森电话股份有限公司 Ip多媒体子系统中的消息处理方法和服务器
BRPI0520192B8 (pt) 2005-05-25 2018-12-26 Cluster Llc método para indicar o(s) serviço(s) de comunicação de subsistema de multimídia de ip e aplicativo terminal com que uma mensagem de protocolo de iniciação de sessão se relaciona e para operar um terminal de usuário ou nó de rede de ims
GB2432281A (en) * 2005-11-14 2007-05-16 Orange Personal Comm Serv Ltd Handling calls via the cellular network for the duration of the call irrespective of the location of the subscriber.
GB0601007D0 (en) * 2006-01-10 2006-03-01 Samsung Electronics Co Ltd Mobile Communications
EP1993243B1 (de) * 2006-03-16 2012-06-06 Panasonic Corporation Endgerät
US8094644B2 (en) * 2006-05-05 2012-01-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for dynamically configuring a traffic flow template
US8315162B2 (en) * 2006-08-24 2012-11-20 Research In Motion Limited System and method for determining that a maximum number of IP sessions have been established
US8687586B2 (en) * 2006-10-13 2014-04-01 Blackberry Limited System and method for managing IP sessions based on how many IP sessions are supported
US20080089303A1 (en) * 2006-10-13 2008-04-17 Jeff Wirtanen System and method for deactivating IP sessions of lower priority
US8611946B2 (en) * 2007-01-25 2013-12-17 Blackberry Limited Methods and systems for configuring multi-mode mobile stations
US7822035B2 (en) * 2007-03-07 2010-10-26 Nokia Corporation Use of communication service identifiers
US8144591B2 (en) * 2007-07-05 2012-03-27 Cisco Technology, Inc. System and method for reducing latency in call setup and teardown
CN101483613B (zh) * 2008-01-09 2012-02-15 国际商业机器公司 为呈现服务器提供QoS控制能力的方法和设备及其系统
US8984628B2 (en) * 2008-10-21 2015-03-17 Lookout, Inc. System and method for adverse mobile application identification
US9781148B2 (en) 2008-10-21 2017-10-03 Lookout, Inc. Methods and systems for sharing risk responses between collections of mobile communications devices
US8087067B2 (en) 2008-10-21 2011-12-27 Lookout, Inc. Secure mobile platform system
US9235704B2 (en) 2008-10-21 2016-01-12 Lookout, Inc. System and method for a scanning API
US9043919B2 (en) 2008-10-21 2015-05-26 Lookout, Inc. Crawling multiple markets and correlating
US8108933B2 (en) 2008-10-21 2012-01-31 Lookout, Inc. System and method for attack and malware prevention
US8347386B2 (en) 2008-10-21 2013-01-01 Lookout, Inc. System and method for server-coupled malware prevention
US8533844B2 (en) 2008-10-21 2013-09-10 Lookout, Inc. System and method for security data collection and analysis
US9367680B2 (en) 2008-10-21 2016-06-14 Lookout, Inc. System and method for mobile communication device application advisement
US8060936B2 (en) 2008-10-21 2011-11-15 Lookout, Inc. Security status and information display system
US8051480B2 (en) * 2008-10-21 2011-11-01 Lookout, Inc. System and method for monitoring and analyzing multiple interfaces and multiple protocols
US8369313B2 (en) * 2008-12-17 2013-02-05 At&T Intellectual Property I, L.P. IMS and method of multiple S-CSCF operation in support of single PUID
US8942246B2 (en) * 2009-02-13 2015-01-27 Telefonaktiebolaget L M Ericsson (Publ) Method and an apparatus for providing configuration information to a mobile terminal
US8855601B2 (en) 2009-02-17 2014-10-07 Lookout, Inc. System and method for remotely-initiated audio communication
US8467768B2 (en) * 2009-02-17 2013-06-18 Lookout, Inc. System and method for remotely securing or recovering a mobile device
US9042876B2 (en) 2009-02-17 2015-05-26 Lookout, Inc. System and method for uploading location information based on device movement
US8538815B2 (en) * 2009-02-17 2013-09-17 Lookout, Inc. System and method for mobile device replacement
US9955352B2 (en) 2009-02-17 2018-04-24 Lookout, Inc. Methods and systems for addressing mobile communications devices that are lost or stolen but not yet reported as such
US8686951B2 (en) 2009-03-18 2014-04-01 HJ Laboratories, LLC Providing an elevated and texturized display in an electronic device
US8194572B2 (en) * 2009-06-15 2012-06-05 Motorola Mobility, Inc. Method and apparatus for increasing performance of a wireless communication system
US8397301B2 (en) 2009-11-18 2013-03-12 Lookout, Inc. System and method for identifying and assessing vulnerabilities on a mobile communication device
US20110199342A1 (en) 2010-02-16 2011-08-18 Harry Vartanian Apparatus and method for providing elevated, indented or texturized sensations to an object near a display device or input detection using ultrasound
US8644176B1 (en) * 2010-03-11 2014-02-04 Sprint Spectrum L.P. Methods and systems for supporting enhanced non-real-time services for real-time applications
US8811281B2 (en) 2011-04-01 2014-08-19 Cisco Technology, Inc. Soft retention for call admission control in communication networks
US8738765B2 (en) 2011-06-14 2014-05-27 Lookout, Inc. Mobile device DNS optimization
EP2538719B1 (de) * 2011-06-24 2020-03-11 Vodafone IP Licensing limited Telekommunikationsnetzwerk
US8788881B2 (en) 2011-08-17 2014-07-22 Lookout, Inc. System and method for mobile device push communications
US9407443B2 (en) 2012-06-05 2016-08-02 Lookout, Inc. Component analysis of software applications on computing devices
US9589129B2 (en) 2012-06-05 2017-03-07 Lookout, Inc. Determining source of side-loaded software
CN103517266B (zh) 2012-06-29 2017-03-22 国际商业机器公司 移动网络侧激活移动终端的方法和移动网关系统
US8655307B1 (en) 2012-10-26 2014-02-18 Lookout, Inc. System and method for developing, updating, and using user device behavioral context models to modify user, device, and application state, settings and behavior for enhanced user security
US9208215B2 (en) 2012-12-27 2015-12-08 Lookout, Inc. User classification based on data gathered from a computing device
US9374369B2 (en) 2012-12-28 2016-06-21 Lookout, Inc. Multi-factor authentication and comprehensive login system for client-server networks
US8855599B2 (en) 2012-12-31 2014-10-07 Lookout, Inc. Method and apparatus for auxiliary communications with mobile communications device
US9424409B2 (en) 2013-01-10 2016-08-23 Lookout, Inc. Method and system for protecting privacy and enhancing security on an electronic device
US20160157280A1 (en) * 2013-04-24 2016-06-02 Telefonaktiebolaget L M Ericsson (Publ) Signalling reduction for ip traffic in wireless networks
US9642008B2 (en) 2013-10-25 2017-05-02 Lookout, Inc. System and method for creating and assigning a policy for a mobile communications device based on personal data
US9973534B2 (en) 2013-11-04 2018-05-15 Lookout, Inc. Methods and systems for secure network connections
US10122747B2 (en) 2013-12-06 2018-11-06 Lookout, Inc. Response generation after distributed monitoring and evaluation of multiple devices
US9753796B2 (en) 2013-12-06 2017-09-05 Lookout, Inc. Distributed monitoring, evaluation, and response for multiple devices
WO2016178816A1 (en) 2015-05-01 2016-11-10 Lookout, Inc. Determining source of side-loaded software
US10440053B2 (en) 2016-05-31 2019-10-08 Lookout, Inc. Methods and systems for detecting and preventing network connection compromise
US10218697B2 (en) 2017-06-09 2019-02-26 Lookout, Inc. Use of device risk evaluation to manage access to services
WO2024147077A2 (en) * 2023-01-04 2024-07-11 Securing Sam Ltd. Computer-based systems for an intelligent identification of computing services and categories of services in use within a plurality of computing networks and methods of use thereof

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI108192B (fi) 1998-03-19 2001-11-30 Nokia Networks Oy Menetelmä ja laitteisto palvelun laadun kontrolloimiseksi matkaviestinjärjestelmässä
FI108185B (fi) 1999-05-12 2001-11-30 Nokia Networks Oy Yhteyksien hallintamenetelmä
US6707813B1 (en) * 2000-02-21 2004-03-16 Telefonaktiebolaget L M Ericsson (Publ) Method of call control to minimize delays in launching multimedia or voice calls in a packet-switched radio telecommunications network
US20020064164A1 (en) * 2000-10-06 2002-05-30 Barany Peter A. Protocol header construction and/or removal for messages in wireless communications
US7870196B2 (en) * 2000-11-08 2011-01-11 Nokia Corporation System and methods for using an application layer control protocol transporting spatial location information pertaining to devices connected to wired and wireless internet protocol networks
ES2288490T3 (es) * 2000-12-22 2008-01-16 Nokia Corporation Metodo y sistema que permiten un servicio de prepago en una red todo-ip.
US7054945B2 (en) * 2001-04-09 2006-05-30 Nokia Corporation Technique for providing announcements in mobile-originated calls
US7512151B2 (en) * 2001-04-17 2009-03-31 Nokia Corporation Providing a network node with service reference information
ATE472218T1 (de) * 2001-04-27 2010-07-15 Nokia Corp Teilnehmerendgerät, netzwerkelement, und verfahren und kommunikationssystem zur herstellung einer notfallsitzung
US7120156B2 (en) * 2001-07-16 2006-10-10 Telefonaktiebolaget Lm Ericsson (Publ) Policy information transfer in 3GPP networks

Also Published As

Publication number Publication date
EP1442565B1 (de) 2005-12-14
WO2003039080A1 (en) 2003-05-08
DE60115967D1 (de) 2006-01-19
US20040259532A1 (en) 2004-12-23
ATE313193T1 (de) 2005-12-15
US7406057B2 (en) 2008-07-29
EP1442565A1 (de) 2004-08-04

Similar Documents

Publication Publication Date Title
DE60115967T2 (de) Eine methode für handhabung von meldungen zwischen einem terminal und einem datennetz
DE60117288T2 (de) Richtlinien koordination in einem kommunikationsnetz
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE69927238T2 (de) Mobil-IP mit Unterstützung für Dienstqualität
DE60211881T2 (de) Bindungsinformation für ip mediendatenströmen
DE69833111T2 (de) Bestimmung von trägerdiensten in einem funkzugriffsnetz
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE69821628T2 (de) Telekommunikationssystem
DE60212404T2 (de) Mehrfachsendung in paketvermittelten punkt-zu-punkt-netzwerken
DE60225278T2 (de) Technik zur verbesserung von ansagen in anrufen mit mobilursprung
DE602004009669T2 (de) Routing-optimierung bei der sip-verbindungsherstellung
EP3035634B1 (de) Telekommunikationsanordnung und verfahren zum herstellen einer rtc-verbindung zwischen einem ersten endpunkt und einem zweiten endpunkt
DE60130911T2 (de) Verfahren und gerät für die koordinierte verrechnung von diensten in einer multimedia-sitzung
EP2018765B1 (de) Steuerung der dienstqualität und/oder der vergebührung von telekommunikationsdiensten
DE20212587U1 (de) Ein Netzwerk zur Verwendung eines Sitzungseinleitungsprotkolls zur Identifizierung von Benutzergeräts-Ressourcenreservierungs-Aufbauprotokollfähigkeiten
EP1908234B1 (de) Verfahren zur steuerung von ressourcen in netzelementen eines telekommunikationsnetzes
DE602004002471T2 (de) Verfahren und System zur Beteitstellung einer Übertragungsverbindung für Datenstromverkehr
DE60022913T2 (de) Lösen einer verbindung in einem zwei schichten netzwerk
DE60219263T2 (de) Überwachung und Übertragung von QOS-Daten in einem Telekommunikationsnetzwerk
EP1317820B1 (de) Verfahren zum aufbau von verbindungen mit vorgegebener dienstgüte für ein paketorientiertes kommunikationsnetz mit einem resourcenmanager
WO2005039139A1 (de) Behandlung von early media-daten i
DE60318502T2 (de) Verfahren zum wiederauffinden und zustellung von multimedianachrichten unter verwendung des sitzungseinleitungsprotokolls
DE602004002926T2 (de) Auswahl eines datenübertragungsverfahrens
DE602004006171T2 (de) Sitzungseinleitungsprotokollsignalisierung (sip)
DE60017917T2 (de) Verbindungsaufbau in einem multimediennetz

Legal Events

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

Owner name: SPYDER NAVIGATIONS LLC, WILMINGTON, DEL., US

R082 Change of representative

Ref document number: 1442565

Country of ref document: EP

Representative=s name: TBK, DE

R081 Change of applicant/patentee

Ref document number: 1442565

Country of ref document: EP

Owner name: INTELLECTUAL VENTURES I LLC, US

Free format text: FORMER OWNER: SPYDER NAVIGATIONS LLC, WILMINGTON, US

Effective date: 20121119

R082 Change of representative

Ref document number: 1442565

Country of ref document: EP

Representative=s name: TBK, DE

Effective date: 20121119