DE60225278T2 - Technik zur verbesserung von ansagen in anrufen mit mobilursprung - Google Patents

Technik zur verbesserung von ansagen in anrufen mit mobilursprung Download PDF

Info

Publication number
DE60225278T2
DE60225278T2 DE60225278T DE60225278T DE60225278T2 DE 60225278 T2 DE60225278 T2 DE 60225278T2 DE 60225278 T DE60225278 T DE 60225278T DE 60225278 T DE60225278 T DE 60225278T DE 60225278 T2 DE60225278 T2 DE 60225278T2
Authority
DE
Germany
Prior art keywords
pdp
die
der
sgsn
qos
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
DE60225278T
Other languages
English (en)
Other versions
DE60225278D1 (de
Inventor
Tuija Hurtta
Stefano Dallas FACCIN
Nedko Ivanov
Bertenyl Balazs
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
Spyder Navigations LLC
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 Spyder Navigations LLC filed Critical Spyder Navigations LLC
Application granted granted Critical
Publication of DE60225278D1 publication Critical patent/DE60225278D1/de
Publication of DE60225278T2 publication Critical patent/DE60225278T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/24Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18Negotiating wireless communication parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/06Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Description

  • STAND DER TECHNIK
  • Die vorliegende Erfindung bezieht sich auf Mobilnetze und insbesondere bezieht sich die vorliegende Erfindung auf eine Technik für das Liefern von Ankündigungen für von Mobilstationen ausgehenden Gesprächen in einem Mobilnetz, das einen IP-Transportmechanismus (Internetprotokoll) verwendet. Im allgemeinen liefern paketvermittelnde drahtlose Netze Verbindungen für mobile Endgeräte, bei denen keine physikalische Verbindung für die Netzadresse erforderlich ist. Der General Packet Radio Service (GPRS, allgemeiner Paketfunkdienst) im Global System for Mobile communications (GSM, globales System für Mobilkommunikation) und das Universal Mobile Terrestrial System (universelles, mobiles, terrestrisches System, UMTS) sind beide entwickelt worden, um drahtlose Kommunikationsnetze sowohl mit einer paketvermittelnden Seite als auch einer leitungsvermittelnden Seite zu versehen.
  • Wie auf ihrer Website http://www.3gpp.org angegeben ist, ist das Partnerschaftsprojekt der dritten Generation, das normalerweise durch sein Akronym 3GPP bekannt ist, eine Organisation, deren Partner darüber übereingekommen sind, bei der Erzeugung von global anwendbaren Technischen Spezifikationen und Technischen Berichten für ein Mobilsystem der dritten Generation, basierend auf GSM-Kernnetzen und den radialen Zugangstechnologien, die diese unterstützen (das ist der Universal Terrestrial Radio Access (UTRA)) sowohl im Frequenzduplex (Frequency Division Duplex, FDD) als auch im Zeitduplex (Time Division Duplex, TDD), zusammen zu arbeiten.
  • Die 3GPP-Partner sind weiter übereingekommen, bei der Unterhaltung und der Entwicklung der technischen Spezifikationen und technischen Berichte des Global System for Mobile Communication (GSM), die entwickelte radiale Zugangstechniken (beispielsweise den General Packet Radio Service, GPRS) und verbesserte Datenraten für die GSM-Entwicklung (EDGE) einschließen, zusammen zu arbeiten.
  • Das 3GPP gibt somit verschiedene technische Spezifikationen heraus, die dann von der Telekommunikationsindustrie verwendet werden, um mobile Endgeräte und zugehörige Systeme zu erzeugen, die standardisiert wurden, so dass ein mobiles Endgerät eines Herstellers mit einem System oder einem mobilen Endgerät eines anderen Herstellers kommunizieren kann. Diese technischen Spezifikationen werden gemäß den Vereinbarungen durch die 3GPP-Partner konstant überarbeitet, um Änderungen und Verbesserungen in der Technik zu ermöglichen.
  • Die technische Spezifikation TS 23.060, Version V3.3.0 wurde im Januar 2001 von der 3GPP herausgegeben und definiert die Stufe 2 Dienstbeschreibung für den Paketbereich, die das GPRS in GSM und UMTS einschließt.
  • Ein Netzteilnehmer kann eine oder mehrere (PDP) Adressen haben. Jede PDP-Adresse wird durch einen oder mehrere PDP-Kontexte in der Mobilstation (MS), dem Dienst-GPRS-Unterstützungsknoten (SGSN) und dem Gateway-GPRS-Unterstützungsknoten (GGSN) beschrieben. Ein GGSN ist ein Gateway zu einem externen Netz. Jeder PDP-Kontext kann Routing- und Abbildungsinformation für das Richten des Transfers von Daten zu und von der zugewiesenen PDP-Adresse, und ein Traffic Flow Template (TF) für das erneute Betrachten der übertragenen Daten haben.
  • Jeder PDP-Kontext kann selektiv und unabhängig aktiviert, modifiziert und deaktiviert werden. Der Aktivierungszustand des PDP-Kontextes zeigt an, ob der Datentransfer für eine entsprechende PDP-Adresse und einen TFT aktiviert ist. Wenn alle PDP-Kontexte, die mit derselben PDP-Adresse verknüpft sind, inaktiv oder deaktiviert sind, so sind alle Datenübertragungen für diese PDP-Adresse gesperrt.
  • Alle PDP-Kontexte eines Teilnehmers werden mit demselben Mobilitätsverwaltungs-(MM)-Kontext für die internationale Mobilteilnehmerkennung (IMSI) dieses Teilnehmers verknüpft. Das Einrichten eines PDP-Kontextes bedeutet das Einrichten eines Kommunikationskanals zwischen der MS und dem GGSN.
  • 1, die nur als Beispiel bereitgestellt wird, zeigt das PDP-Kontextaktivierungsverfahren zwischen einer MS und einem GGSN in einem UMTS-System und entspricht der 62 der vorher zitierten technischen Spezifikation. Die folgenden Diskussion der Schritte der 1 ist auch dort enthalten.
    • 1) Die MS sendet eine Aktiviere-PDP-Kontext-Anforderungsnachricht (NSAPI, TI, PDP-Typ, PDP-Adresse, Name des Zugangspunkts, geforderte QoS, PDP-Konfigurationsoptionen) an den SGSN. Die MS sollte die PDP-Adresse verwenden, um anzugeben, ob sie die Verwendung einer statischen PDP-Adresse fordert, oder ob sie die Verwendung einer dynamischen PDP-Adresse fordert. Die MS sollte die PDP-Adresse leer lassen, um eine dynamische PDP-Adresse anzufordern. Die MS kann den Namen des Zugangspunkts verwenden, um einen Referenzpunkt für ein gewisses externes Netz zu wählen, und/oder um einen Dienst zu wählen. Der Name des Zugangspunkts ist ein logischer Name, der sich auf das externe Paketdatennetz und/oder auf einen Dienst bezieht, mit dem der Teilnehmer verbunden werden will. Die angeforderte QoS gibt das gewünschte QoS-Profil an. Die PDP-Konfigurationsoptionen können verwendet werden, um optionale PDP-Parameter vom GGSN anzufordern (siehe GSM 09.60). Die PDP-Konfigurationsoptionen werden transparent durch den SGSN gesandt.
    • 3) Im UMTS erfolgt ein RAB-Aufbau durch das RAB-Zurodnungsverfahren, siehe Unterfall "RAB-Zuordnungsverfahren".
    • 5) Der SGSN validiert die Aktiviere PDP-Kontextanforderung unter Verwendung des PDP-Typs (optional), der PDP-Adresse (optional) und des Zugangspunktnamens (optional), der von der MS geliefert wird, und den PDP-Kontextteilnehmeraufzeichnungen. Die Validierungskriterien, die APN-Auswahlkriterien und die Abbildung vom APN auf einen GGSN sind im Anhang A beschrieben. Wenn keine GGSN-Adresse abgeleitet werden kann, oder wenn der SGSN bestimmt hat, dass die Aktivierte PDP-Kontextanforderung gemäß den Regeln, die im Anhang A beschrieben sind, nicht gültig ist, weist der SGSN die PDP-Kontextaktivierungsanforderung zurück. Wenn eine GGSN-Adresse abgeleitet werden kann, erzeugt der SGSN eine TEID für den geforderten PDP-Kontext . Wenn die MS eine dynamische Adresse fordert, lässt dann der SGSN einen GGSN die dynamische Adresse zuweisen. Der SGSN kann die geforderten QoS-Attribute anhand seiner Fähigkeiten, der aktuellen Belastung und dem eingeschriebenen QoS-Profil beschränken.
  • Der SGSN sendet eine Erzeuge PDP-Kontext-Anforderungsnachricht (PDP-Typ, PDP-Adresse, Zugangspunktnamen, ausgehandelte QoS, TEID, NSAPI, MSISDN, Auswahlmodus, Abrechnungscharakteristika, Spurreferenz, Spurtyp, Auslöse-Id, OMS-Kennung, PDP-Konfigurationsoptionen) an den beeinflussten GGSN. Der Zugangspunktname soll die APN-Netzkennung des APN, der gemäß dem in Anhang A beschriebenen Verfahren ausgewählt wird, sein. Die PDP-Adresse soll leer sein, wenn eine dynamische Adresse gefordert wird. Der GGSN kann den Zugangspunktnamen verwenden, um ein externes Netz zu finden und optional, um einen Dienst für diesen APN zu aktivieren. Der Auswahlmodus zeigt an, ob ein eingeschriebener APN ausgewählt wurde, oder ob ein nicht eingeschriebener APN, der durch die MS gesandt wurde, oder ein nicht eingeschriebener APN, der vom SGSN gewählt wurde, ausgewählt worden ist. Der Auswahlmodus wird gemäß Anhang A festgelegt. Der GGSN kann den Auswahlmodus verwenden, wenn er entscheidet, ob er die PDP-Kontextaktivierung akzeptieren oder zurückweisen wird. Wenn beispielsweise ein APN eine Teilnahme fordert, so wird der GGSN konfiguriert, um nur die PDP-Kontextaktivierung zu akzeptieren, die einen eingeschriebenen APN fordert, wie das durch den SGSN mit dem Auswahlmodus angegeben ist. Die Abrechnungseigenschaften zeigen an, für welche Art von Abrechnung der PDP-Kontext verantwortlich ist. Der SGSN sollte die Abrechnungseigenschaften von den eingeschriebenen Abrechnungseigenschaften kopieren, wenn diese vom HLR empfangen werden. Der SGSN sollte die Spurreferenz, den Spurtyp, die Auslöserkennung und die OMC-Kennung einfügen, wenn die GGSN-Spur aktiviert ist. Der SGSN sollte die Spurreferenz, den Spurtyp und die OMC-Kennung von der Spurreferenz kopieren, die vom HLR oder OMC empfangen wird. Der GGSN erzeugt einen neuen Eintrag in seine PDP-Kontexttabelle und er erzeugt eine Abrechunns-Id. Der neue Eintrag erlaubt es dem GGSN PDU PDUs zwischen dem SGSN und dem externen PDP-Netz zu lenken und die Abrechnung zu starten. Der GGSN kann weiter die geforderte, ausgehandelte QoS in Abhängigkeit von seinen Fähigkeiten und der aktuellen Belastung beschränken. Der GGSN gibt dann eine Erzeuge PDP-Kontext-Antwortnachricht (TEID, PDP-Adresse, PDP-Konfigurationsoptionen, ausgehandelte QOS, Abrechnungs-Id, Grund) an den SGSN. Die PDP-Adresse wird eingeschlossen, wenn der GGSN eine PDP-Adresse zugewiesen hat. Wenn der GGSN vom Betreiber konfiguriert worden ist, eine externe PDP-Adressenzuweisung für die geforderte APN zu verwenden, dann sollte die PDP-Adresse auf 0.0.0.0 gesetzt werden, was anzeigt, dass die PDP-Adresse durch die MS mit dem externen PDN nach dem PDP-Kontext-Aktivierungsverfahren ausgehandelt werden sollte. Der GGSN sollte sich auf diese Aushandlungen beziehen, sie modifizieren und überwachen, so lange wie sie der PDP-Kontext im Zustand AKTIV befindet und das GGSN-Initiert-PDP-Kontext-Modifikationsverfahren verwenden, um die aktuell verwendete PDP-Adresse an den SGSN und die MS zu übertragen. Die PDP-Konfigurationsoptionen enthalten optional PDP-Parameter, die der GGSN an die MS übertragen mag. Diese optionalen PDP-Parameter können durch die MS in der Aktiviere-PDP-Kontext-Anforderungsnachricht angefordert werden, oder sie können unaufgefordert vom GGSN gesandt werden. Die PDP-Konfigurationsoptionen werden transparent durch den SGSN gesandt. Die Erzeuge-PDP-Kontext-Nachrichten werden über das Hauptverbindungsnetz gesandt. Wenn die ausgehandelte QoS, die vom SGSN empfangen wird, inkompatibel mit dem zu aktivierenden PDP-Kontext ist, so weist der GGSN die Erzeuge-PDP-Kontext-Anforderungsnachricht zurück. Die kompatiblen QoS-Profile werden durch den GGSN-Betreiber konfiguriert.
    • 7. Der SGSN schiebt die NSAPI zusammen mit der GGSN-Adresse in seinen PDP-Kontext ein. Wenn die MS eine dynamische Adresse gefordert hat, so wird die PDP-Adresse, die vom GGSN empfangen wird, in den PDP-Kontext eingeschoben. Der SGSN wählt die Funkpriorität und die Paket-Fluss-Id auf der Basis der ausgehandelten QoS und gibt eine Aktiviere-PDP-Kontext-Akzeptiert-Nachricht (PDP-Typ, PDP-Adresse, TI, ausgehandelte QoS, Funkpriorität, Paketfluss-ID, PDP-Konfigurationsoptionen) an die MS. Der SGSN kann nun PDP PDUs zwischen der GGSN und der MS lenken und die Abrechnung starten.
  • In ähnlicher Weise illustriert die 2 auch nur für beispielhafte Zwecke das zweite PDP-Kontext-Aktivierungsverfahren und sie entspricht der 64 der vorher zitierten technischen Spezifikation. Die folgende Diskussion der Schritte der 2 ist auch darin enthalten.
  • Das sekundäre PDP-Kontextaktivierungsverfahren kann verwendet werden, um einen PDP-Kontext zu aktivieren, während es die PDP-Adresse und die andere PDP-Kontextinformation von einem schon aktiven PDP-Kontext erneut verwendet, aber mit einem anderen QoS-Profil. Verfahren für eine APN-Auswahl und eine PDP-Adressenaushandlung werden nicht ausgeführt. Jeder PDP-Kontext, der dieselbe PDP-Adresse und APN teilt, soll durch eine eindeutige TI und eine eindeutige NSAPI identifiziert werden.
  • Das zweite PDP-Kontextaktivierungsverfahren kann ausgeführt werden, ohne ein Traffic Flow Template (TFT) an den neu aktivierten PDP-Kontext zu liefern, wenn alle anderen aktiven PDP-Kontexte für diese PDP-Adresse und APN schon eine zugeordnete TFT haben, ansonsten soll ein TFT geliefert werden. Das TFT enthält Attribute, die einen IP-Kopfteilfilter spezifizieren, der verwendet wird, um Datenpakete, die vom verbundenen externen Paketdatennetz empfangen werden, zum neu aktivierten PDP-Kontext zu lenken.
    • 1) Die MS sendet eine Aktiviere-Zweite-PDP-Kontext-Anforderung (Verbundene TI, NSAPI, TI, geforderte QoS, TFT) an den SGSN. Die verbundene TI gibt den TI-Wert an, der irgend einem der schon aktivierten PDP-Kontexte für diese PDP-Adresse und APN zugewiesen wurde. Die geforderte QoS zeigt das gewünschte QoS-Profil an. TFT wird transparent durch den SGSN an den GGSN gesandt, um eine Paketklassifikation für einen Abwärtsverbindungsdatentransfer zu ermöglichen. Die TI und die NSAPI enthalten Werte, die nicht von irgend einem anderen aktivierten PDP-Kontext verwendet werden.
    • 3) Im UMTS wird ein RAB-Aufbau durch ein RAB-Zuordnungsverfahren ausgeführt.
    • 4) Der SGSN validiert die Aktiviere-Sekundäre-PDP-Kontext-Anforderung unter Verwendung der TI, die durch die verbundene TI angegeben wird. Dieselbe GGSN-Adresse wird vom SGSN wie für den (die) schon aktivierten PDP-Kontexte) für diese TI und die PDP-Adresse verwendet. Der SGSN und der GGSN können die geforderte QoS beschränken und aushandeln, wie das im Unterfall "PDP-Kontextaktivierungsverfahren" spezifiziert ist. Der SGSN sendet eine Erzeuge-PDP-Kontext-Anforderungsnachricht (ausgehandelte QoS, TEID, NSAPI, Primäre NSAPI, TFT) an den beeinflussten GGSN. Die primäre NSAPI gibt den NSAPI-Wert an, der irgend einem der schon aktivierten PDP-Kontexte für diese PDP-Adresse und APN zugewiesen wurden. Das TFT ist nur eingeschlossen, wenn es in der Aktiviere-Sekundäre-PDP-Kontext-Anforderungsnachricht empfangen wurde. Der GGSN verwendet dasselbe externe Netz, wie es vom (den) schon aktivierten PDP-Kontexten) für diese PDP-Adresse verwendet wird, er erzeugt einen neue Eintrag in seine PDP-Kontexttabelle und speichert das TFT. Der neue Eintrag erlaubt es dem GGSN, die PDP PDUs über verschiedene GTP-Tunnel zwischen dem SGSN und dem externen PDP-Netz zu lenken. Der GGSN gibt eine Erzeuge-PDP-Kontext-Antwortnachricht (TEID, ausgehandelte QoS, Grund) an den SGSN.
    • 6) Der SGSN wählt eine Funkpriorität und Paketfluss-ID auf der Basis der ausgehandelten QDS und gibt eine Aktiviere-Sekundäre-PDP-Kontext-Akzeptiert-Nachricht (TI, ausgehandelte QDS, Funkpriorität, Paketfluss-Id) an die MS. Der SGSN kann nun PDP PDUs zwischen dem GGSn und der MS über verschiedene GTP-Tunnels und möglicherweise verschiedene LLC-Verbindungen lenken.
  • 3 liefert auch nur für beispielhafte Zwecke das vom SGSN initiierte PDP-Kontext-Modifikationsverfahren und entspricht 68 der vorher zitierten technischen Spezifikation. Die folgende Diskussion der Schritte in 3 ist auch darin enthalten.
  • Eine MS oder ein GGSN kann anfordern, ein SGSN kann entscheiden, möglicherweise durch das HLR ausgelöst, wie es im Unterfall "Teilnehmerdateneinschiebeverfahren" erläutert ist, oder ausgelöst durch ein RAB-Auslöseverfahren, die durch eine RNC oder eine MS initiiert wird, und der SGSN kann nach einer von der RNC initiierten Iu-Auslösung entscheiden, Parameter zu modifizieren, die während eines Aktivierungsverfahrens für einen oder mehrere PDP-Kontexte ausgehandelt wurden. Die folgenden Parameter können modifiziert werden:
    • – ausgehandelte QDS;
    • – Funkpriorität;
    • – Paketfluss-Id;
    • – PDP-Adresse (im Fall eines vom GGSN initiierten Modifikationsverfahren); und
    • – TFT (im Fall eines von der MS initiierten Modifikationsverfahrens).
  • Der SGSN kann die Modifikation von Parametern durch das Senden einer Modifiziere-PDP-Kontext-Anforderungsnachricht an die MS anfordern.
  • Ein GGSN kann die Modifikation von Parametern durch das Senden einer Aktualisiere-PDP-Kontext-Anforderungsnachricht an den SGSN anfordern.
  • Eine MS kann die Modifikation von Parametern durch das Senden einer Modifiziere-PDP-Kontext-Anforderungsnachricht an den SGSN anfordern.
  • Eine RNC kann eine Iu-Auslösung durch das Senden einer Iu-Auslöse-Anforderungsnachricht an den SGSN anfordern. Nach der Iu-Auslösung sollten die MS und der SGSN die PDP-Kontexte gemäß den Regeln modifizieren, die im Unterfall "RNC-Initiertes-PDP-Kontext-Modifikationsverfahren" definiert sind.
  • Eine RNC kann die Auslösung eines Funkzugangsträgers anfordern. Nach der RAB-Auslösung sollten die MS und der SGSN lokal den entsprechenden PDP-Kontext gemäß den Regeln, die im Unterfall "RAB-Auslöse-Initiiert-Lokal-PDP-Kontext-Modifikationsverfahren" definiert sind, modifizieren.
  • Eine Spur kann aktiviert werden, während ein PDP-Kontext aktiv ist. Um eine Spuraktivierung in einem GGSN zu ermöglichen, sollte der SGSN eine Aktualisiere-PDP-Kontext-Anforderungsnachricht an den GGSN senden. Wenn die PDP-Kontextmodifikation nur ausgeführt wird, um eine Spur zu aktivieren, dann sollte der SGSN keine Modifiziere-PDP-Kontext-Anforderungsnachricht an die MS senden.
    • 1) Der SGSN kann eine Akualisiere-PDP-Kontextanforderungsnachricht (TEID, NSAPI, ausgehandelte QOS, Spurreferenz, Spurtyp, Trigger-ID, OMC-Identität) an den GGSN senden. Wenn die ausgehandelte QoS, die vom SGSN empfangen wurde, inkompatibel mit dem modifizierten PDP-Kontext ist, dann weist der GGSN die Aktualisiere-PDP-Kontextanforderung zurück. Die kompatiblen QoS-Profile werden durch den GGSN-Betreiber konfiguriert. Der SGSN sollte die Spurreferenz, den Spurtyp, die Trigger-Id und die OMC-Identität in der Nachricht einschießen, wenn GGSN-Spur aktiviert ist, während der PDP-Kontext inaktiv ist. Der SGSN sollte die Spurreferenz, den Spurtyp und die OMC-Identität von der Spurinformation, die vom HLR oder OMC empfangen wird, kopieren.
    • 2) Der GGSN kann gemäß seinen Fähigkeiten und der aktuellen Belastung die ausgehandelte QoS beschränken. Der GGSN speichert die ausgehandelte QoS und gibt eine Aktualisiere-PDP-Kontext-Antwortnachricht (TEID, ausgehandelte QoS, Grund) zurück.
    • 3) Der SGSN wählt die Funkpriorität und die Paketfluss-Id auf der Basis der ausgehandelten QoS und kann eine Modifiziere-PDP-Kontext-Anforderungsnachricht (TI, ausgehandelte QoS, Funkpriorität, Paketfluss-ID) an die MS senden.
    • 4) Die MS führt eine Bestätigung aus durch das Zurückgeben einer Modifiziere-PDP-Kontext-Akzeptanznachricht. Wenn die MS die neue ausgehandelte QoS nicht akzeptiert, so soll sie stattdessen den PDP-Kontext mit der PDP-Kontext-Deaktivierung, initiiert durch das MS-Verfahren, deaktivieren.
    • 5) Bei UMTS kann die Funkträgermodifikation durch das RAB-Zuweisungsverfahren ausgeführt werden.
    • 6) Wenn BSS-Spur aktiviert ist, während PDP-Kontext aktiv ist, dann sollte der SGSN eine Aufruf-Spurnachricht (Spurreferenz, Spurtyp, Trigger-Id, OMC-Identität) an die BSS oder UTRAN senden. Die Spurreferenz und der Spurtyp werden von Spurinformation, die vom HLR oder OMC empfangen wird, kopiert.
    • 1) Der SGSN kann eine Aktualisiere-PDP-Kontext-Anforderungsnachricht (TEID, NSAPI, ausgehandelte QoS, Spurreferenz, Spurtyp, Trigger-Id, OMC-Identität) an den GGSN senden. Wenn die ausgehandelte QoS, die vom SGSN empfangen wird, inkompatibel mit dem modifizierten PDP-Kontext ist, dann weist der GGSN die Aktualisiere-PDP-Kontext-Anforderung zurück. Die kompatiblen QoS-Profile werden vom GGSN-Betreiber konfiguriert. Der SGSN sollte die Spurreferenz, den Spurtyp, die Trigger-Id und die OMC-Identität in der Nachricht einschließen, wenn die GGSN-Spur aktiviert wird, während der PDP-Kontext aktiv ist. Der SGSN sollte die Spurreferenz, den Spurtyp und die OMC-Identität von der Spurinformation, die vom HLR oder OMC empfangen wird, kopieren.
    • 2) Der GGSN kann gemäß seinen Fähigkeiten und der aktuellen Belastung die ausgehandelte QoS beschränken. Der GGSN speichert die ausgehandelte QoS und gibt eine Aktualisiere-PDP-Kontext-Antwortnachricht (TEID, ausgehandelte QoS, Grund) zurück.
    • 3) Der SGSN wählt die Funkpriorität und die Paketfluss-Id auf der Basis der ausgehandelten QoS und kann eine Modifiziere-PDP-Kontext-Anforderungsnachricht (TI, ausgehandelte QoS, Funkpriorität, Paketfluss-ID) an die MS senden.
    • 4) Die MS führt eine Bestätigung aus durch das Zurückgeben einer Modifiziere-PDP-Kontext-Akzeptanznachricht. Wenn die MS die neue ausgehandelte QoS nicht akzeptiert, so soll sie stattdessen den PDP-Kontext mit der PDP-Kontext-Deaktivierung, initiiert durch das MS-Verfahren, deaktivieren.
    • 5) Bei UMTS kann die Funkträgermodifikation durch das RAB-Zuweisungsverfahren ausgeführt werden.
    • 6) Wenn BSS-Spur aktiviert ist, während PDP-Kontext aktiv ist, dann sollte der SGSN eine Aufruf-Spurnachricht (Spurreferenz, Spurtyp, Trigger-Id, OMC-Identität) an die BSS oder UTRAN senden. Die Spurreferenz und der Spurtyp werden von Spurinformation, die vom HLR oder OMC empfangen wird, kopiert.
  • 4, die auch nur für beispielhafte Zwecke vorgesehen ist, zeigt das vom GGSN initiierte PDP-Kontextmodifikationsverfahren und entspricht der 69 der vorher zitierten technischen Spezifikation. Die folgende Diskussion der Schritte der 4 ist auch darin enthalten.
    • 1) Die GGSN sendet eine Aktualisiere PDP-Kontextanforderung (TEID, NSAPI, PDP-Adresse, angeforderte QoS) an den SGSN. Die angeforderte QoS gibt das gewünschte QoS-Profil an. Die PDP-Adresse ist optional.
    • 2) der SGSN kann das gewünschte QoS-Profil unter Berücksichtigung seiner Fähigkeiten, der aktuellen Belastung, des aktuellen QoS-Profils und des eingeschriebenen QoS-Profils beschränken. Der SGSN wählt die Funkpriorität und die Paketfluss-Id auf der Basis der ausgehandelten QoS und sendet eine PDP-Kontext-Anforderungsnachricht (TI, PDP-Adresse, ausgehandelte QoS, Funkpriorität, Paketfluss-Id) an die MS. Die PDP-Adresse ist optional.
    • 3) Der MS gibt eine Bestätigung durch das Zurückgeben einer Modifiziere-PDP-Akzeptanznachricht aus. Wenn die MS die neue ausgehandelte QoS nicht akzeptiert, sollte sie stattdessen den PDP-Kontext mit der PDP-Kontext-Deaktivierung, initiiert durch das MS-Verfahren, deaktivieren.
    • 4) Beim UMTS kann eine Funkträgermodifikation durch ein RAB-Zuweisungsverfahren ausgeführt werden.
    • 5) Beim Empfangen der Modifiziere-PDP-Kontext-Akzeptanznachricht oder nach der Vollendung des RAB-Modifikationsverfahrens gibt der SGSN eine Aktualisiere PDP-Kontextantwortnachricht (TEID, ausgehandelte QoS) an den GGSN zurück. Wenn der SGSN eine Deaktiviere-PDP-Kontextanforderungsnachricht empfängt, soll er stattdessen der PDP-Kontext-Deaktivierung, initiiert durch das MS-Verfahren, folgen.
  • 5, die auch nur für beispielhafte Zwecke geliefert ist, zeigt das von der MS initiierte PDP-Kontext-Modifikationsverfahren und entspricht 70 der vorher zitierten technischen Spezifikation. Die folgende Diskussion der Schritte der 5 ist auch hierin enthalten.
    • 1) Die MS sendet eine Modifiziere-PDP-Kontext-Anforderungsnachricht (TI, angeforderte QoS, TFT) an den SGSN. Entweder die angeforderte QoS oder der TFT oder beide können eingeschlossen sein. Die angeforderte QoS gibt das gewünschte QoS-Profil an, während der TFT den TFT angibt, der zum PDP-Kontext hinzuzufügen, zu modifizieren oder von diesem zu löschen ist.
    • 2) Der SGSN kann das gewünschte QoS-Profil gemäß seinen Fähigkeiten, der aktuellen Belastung und dem eingeschriebenen QoS-Profil beschränken. Der SGSN sendet eine Aktualisiere-PDP-Kontext-Anforderungsnachricht (TEID, NSAPI, ausgehandelte QoS, TFT) an den GGSN. Wenn die ausgehandelte QoS und/oder der TFT, der vom SGSN empfangen wird, inkompatibel mit dem modifizierten PDP-Kontext ist (beispielsweise enthält der TFT inkonsistente Paketfilter), dann weist der GGSN die Aktualisiere-PDP-Kontext-Anforderung zurück. Die kompatiblen QoS-Profile werden durch den GGSN-Betreiber konfiguriert.
    • 3) Der GGSN kann weiter die ausgehandelte QoS gemäß seinen Fähigkeiten und der aktuellen Belastung beschränken. Der GGSN speichert die ausgehandelte QoS, speichert, modifiziert oder löscht den TFT des PDP-Kontexts, wie das im TFT angegeben ist, und gibt eine Aktualisiere-PDP-Kontextantwortnachricht (TEID, ausgehandelte QoS) zurück.
    • 4) Im UMTS kann eine Funkzugangsträgermodifikation durch das RAB-Zuweisungsverfahren ausgeführt werden.
    • 5) Der SGSN wählt die Funkpriorität und die Paketfluss-ID auf der Basis der ausgehandelten QoS und gibt eine Modifiziere-PDP-Kontext-Akzeptanznachricht (TI, ausgehandelte QoS, Funkpriorität, Paketfluss-Id) an die MS zurück.
  • BEACHTE: Wenn der SGSN die geforderte QoS nicht akzeptiert, dann werden die Schritte 2 und 3 dieses Verfahrens verworfen, und die existierende ausgehandelte QoS wird im Schritt 4 an die MS zurückgegeben.
  • Trotz der vielen Details, die in der vorher zitierten technischen Spezifikation geliefert werden, sind viele Merkmale, die mit Mobilnetzen verknüpft sind, nicht behandelt worden. Es wurden nämlich Techniken für das Vorsehen von Ankündigungen in von einer Mobilstation ausgehenden Gesprächen noch nicht in die vorher zitierte technische Spezifikation eingeschlossen, und auf diese Details richtet sich die vorliegende Erfindung.
  • OFFENBARUNG DER ERFINDUNG
  • In der vorliegenden Erfindung ist die Signalisierung, die durch die Anwendungsschicht in der MS ausgetauscht wird, gemäß dem Verfahren/den Nachrichten, das oder die durch die Transportebenen in der MS und im Netz ausgeführt werden müssen, um IP-Multimediaverbindungen aufzubauen, angeordnet.
  • Wenn die Anwendungsebene in der MS eine Aufbaunachricht sendet, um eine IP-Multimediaverbindung aufzubauen, so führt vor oder nach dem Senden einer solchen Nachricht über die Funkschnittstelle die MS in Abhängigkeit vom Typ des verwendeten Zugangs die passenden Verfahren aus, um die passenden Träger über die Funkschnittstelle und im Netz aufzubauen, um die Verbindungsanforderungen, die auf der Anwendungsebene spezifiziert werden, in der Aufbaunachricht zu befriedigen.
  • Die Technik der vorliegenden Erfindung findet Anwendung auf den Fall von von einer Mobilstation ausgehenden Gesprächen, wobei die MS die oben angegebenen Verfahren auf der Transportebene vor oder nach dem Senden einer Aufbaunachricht und vor dem Senden einer Bestätigungs-/Rufakzeptanznachricht zurück an die gerufene Partei ausführt.
  • Bei der Technik gemäß der vorliegenden Erfindung wird für das Antworten auf ein von einer Mobilstation ausgehendes Gespräch die MS über die Transportadresse des Knotens, der die Ankündigung abspielen wird, informiert, und die MS initiiert ein PDP-Kontextmodifikationsverfahren, um das Traffic Flow Template (TF) gemäß der Transportadresse (TA) des Knotens einzurichten.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Das Vorangehende und ein besseres Verständnis der vorliegenden Erfindung ergeben sich aus der folgenden detaillierten Beschreibung beispielhafter Ausführungsformen und den Ansprüchen, wenn diese in Verbindung mit den begleitenden Zeichnungen gelesen werden, wobei alle einen Teil der Offenbarung dieser Erfindung bilden. Während die vorangehende und folgende geschriebene und dargestellte Offenbarung sich auf das Angeben von beispielhaften Ausführungsformen der Erfindung fokussiert, sollte klar verständlich sein, dass dies nur illustrierend und beispielhaft erfolgt, und dass die Erfindung nicht darauf begrenzt ist. Der Umfang der vorliegenden Erfindung ist nur durch die Ausdrücke der angefügten Ansprüche begrenzt.
  • Das Folgende ist eine kurze Beschreibung der Zeichnungen:
  • 1 zeigt die Schritte in einem PDP-Kontextaktivierungsverfahren.
  • 2 zeigt die Schritte in einem zweiten PDP-Kontextaktivierungsverfahren.
  • 3 bis 5 zeigen die Schritte, die jeweils in einem vom SGSN, dem GGSN beziehungsweise der MS initiierten PDP-Kontextmodifikationsverfahren auftreten.
  • 6 und 7 zeigten auch im Detail die Schritte, die während eines Verbindungsaufbauverfahrens auftreten.
  • 8 zeigt ein Beispiel der Schritte, die in einer Technik für das Liefern von Ankündigungen in von einer Mobilstation ausgehenden Verbindungen auftreten, gemäß der aktuellen Erfindung.
  • BESTE ART FÜR DAS AUSFÜHREN DER ERFINDUNG
  • Vor dem Beginn einer detaillierten Beschreibung des Erfindungsgegenstands sollte folgendes erwähnt werden. Wenn es passend ist, so können gleiche Bezugszahlen und Zeichen verwendet werden, um identische, sich entsprechende oder ähnliche Komponenten in verschiedenen Zeichnungsfiguren zu bezeichnen. Weiterhin können in der folgenden detaillierten Beschreibung beispielhafte Größen, Modelle, Werte, Bereiche angegeben werden, obwohl die vorliegende Erfindung nicht darauf beschränkt ist. Zuletzt kann es sein, dass wohl bekannte Elemente in den Zeichnungsfiguren für eine einfachere Darstellung und Diskussion und um die Erfindung zu verhüllen, nicht gezeigt werden.
  • Zusätzlich zur vorher zitierten technischen Spezifikation definiert die Technische Spezifikation TS 23.228, Version V1.5.0, herausgegeben vom 3GPP im März 2001 die Stufe-2 Dienstbeschreibung für das IM-Multimedia-(IM) Untersystem, das die Elemente einschließt, die notwendig sind, um IP-Multimediadienste (IM) beim UMTS zu unterstützen.
  • 6, die der 5.7 der TS 23.228 Technischen Spezifikation entspricht, zeigt im Detail die folgenden Schritte, die bei einem Verbindungsaufbauverfahren auftreten:
    • 1. Die UE (A) startet ein Sitzungsinitiierungsverfahren zur UE (B), die einen SDP-Vorschlag einschließt.
    • 2. Der Benutzer bei der UE (B) wird voralarmiert (optional).
    • 3. Eine Angabe der Voralarmierung kann zur UE (A) gesandt werden (optional).
    • 4. Der Benutzer an der UE (B) wird dann interagieren und seine Wünsche im Hinblick auf die tatsächliche Sitzung ausdrücken (optional).
    • 5. Die UE (B) erzeugt ein akzeptiertes SDP auf der Basis der Einstellungen des Endgeräts, der rekonfigurierten Profile des Endgeräts und wahlweise den Wünschen des Benutzers.
    • 6. Das akzeptierte SDP wird an die UE (A) in den Nutzdaten einer zuverlässigen SIP-Antwort weitergegeben.
    • 7. Ein anfängliches Trägererzeugungsverfahren wird ausgeführt. Während dieses Schritts der Trägererzeugung werden die Ressourcen im Zugangsnetz der UE (A) und der UE (B) mit den PDP-Kontextverfahren reserviert. Die Trägerressourcen in den externen Netzen können ebenfalls an diesem Punkt reserviert werden.
    • 8. Das Endgerät bei der UE (B) beginnt mit dem Läuten (optional).
    • 9. Die Alarmierungsangabe wird zur UE (A) gesandt (optional).
    • 10. Der Benutzer an der UE (B) kann interagieren und seine Wünsche in Bezug auf die tatsächliche Sitzung ausdrücken (optional).
    • 11. Die UE (A) und die UE (B) können ein Trägermodifikationsverfahren an diesem Punkt ausführen, wenn die anfänglichen Träger, die in Schritt 7 reserviert wurden, und die Wünsche des Benutzers an der UE (B) verschieden sind. Während dieses Trägermodifikationsschrittes können die Ressourcen in dem Zugangsnetz der UE (A) und der UE (B) modifiziert werden durch das Modifizieren des PDP-Kontexts, und die Ressourcenreservierung im externen Netz kann auch modifiziert werden.
    • 12. Das Sitzungsinitiierungsverfahren wird bestätigt.
  • Weiterhin zeigt 7 die Schritte, die bei einem Verbindungsaufbauverfahren auftreten und entspricht der 5.15 des Abschnitts 5.6.2 der zweiten zitierten technischen Spezifikation. Die folgenden Schritte werden darin auch beschrieben.
    • 1. UE#1 sendet die SIP AUFFORDERUNGS-Anforderung, die ein anfängliches SDP enthält, an den P-CSCF, der über den CSCF-Entdeckungsmechanismus bestimmt wird. Das anfängliche SDP kann ein oder mehrere Medien für eine Multimediensitzung darstellen.
    • 2. P-CSCF erinnert sich (aus dem Registrierverfahren) an die nächste Sprung-CSCF für diese UE. In diesem Fall gibt sie die AUFFORDERUNG an die S-CSCF im Heimatnetz.
    • 3. S-CSCF validiert das Dienstprofil und führt eine Ausgangsdienststeuerung, die für diesen Teilnehmer erforderlich ist, aus. Dies umfasst die Autorisierung des angeforderten SDP auf der Basis der Benutzerteilnahme an Multimediadiensten.
    • 4. S-CSCF gibt die Anforderung, wie sie durch die S-S-Verfahren spezifiziert ist, weiter.
    • 5. Die Medienstreamfähigkeiten des Ziels werden entlang dem Signalisierungspfad per S-S-Verfahren zurückgegeben.
    • 6. S-CSCF gibt die SDP-Nachricht an die P-CSCF weiter.
    • 7. P-CSCF autorisiert die Ressourcen, die für diese Sitzung notwendig sind.
    • 8. P-CSCF gibt die SDP-Nachricht an den Ursprungsendpunkt weiter.
    • 9. Die UE legt den endgültigen Satz von Medienströmen für diese Sitzung fest und sendet das endgültige SDP an die P-CSCF.
    • 10. Die P-CSCF gibt diese Nachricht an die S-CSCF.
    • 11. Die S-CSCF gibt diese Nachricht an den abschließenden Endpunkt, wie beispielsweise über das S-S-Verfahren.
    • 12. Nach dem Bestimmen der endgültigen Medienströme im Schritt #9 initiiert die UE die Reservierungsverfahren für die Ressourcen, die für diese Sitzung benötigt werden.
    • 13. Wenn die Ressourcenreservierung vollständig ist, sendet die UE die Nachricht "Ressourcenreservierung erfolgreich" an den abschließenden Endpunkt, über den Signalisierpfad, der von der AUFFORDERUNGS-Nachricht aufgebaut wurde. Die Nachricht wird zuerst an die P-CSCF gesandt.
    • 14. Die P-CSCF gibt diese Nachricht an die S-CSCF.
    • 15. Die S-CSCF gibt diese Nachricht an den abschließenden Endpunkt, wie beispielsweise per S-S-Verfahren.
    • 16. Die Ziel-UE kann wahlweise eine Alarmierung ausführen. Wenn dem so ist, signalisiert sie dies an die Ursprungspartei durch eine vorläufige Antwort, die ein Läuten angibt. Diese Nachricht wird an die S-CSCF über das S-S-Verfahren gesandt.
    • 17. Die S-CSCF gibt diese Nachricht an die P-CSCF.
    • 18. Die P-CSCF gibt diese Läutenachricht an die UE.
    • 19. Die UE gibt dem Ursprungsteilnehmer an, dass das Ziel läutet.
    • 20. Wenn die Zielpartei antwortet, sendet der abschließende Endpunkt eine SIP 200-OK Endantwort, wie das durch die Beendigungsverfahren und die S-S-Verfahren spezifiziert ist, an die S-CSCF.
    • 21. Die S-CSCF führt eine Ursprungsdienststeuerung aus, die von der Sitzungsaufbauvollendung gefordert wird.
    • 22. Die S-CSCF gibt die 200-OK-Antwort zurück zur P-CSCF, dem Pfad der AUFFORDERUNGS-Anforderung des obigen Schritts (2) folgend.
    • 23. Die P-CSCF gibt an, dass die Ressourcen, die für diese Sitzung reserviert sind, nun festgelegt werden sollen.
    • 24. Die P-CSCF gibt die 200-OK-Antwort zurück an die UE.
    • 25. Die UE startet den oder die Medienflüsse für diese Sitzung.
    • 26. Die UE antwortet auf die 200 OK mit einer ACK-Nachricht, die an die P-CSCF gesandt wird.
    • 27. Die P-CSCF gibt die endgültige ACK-Nachricht an die S-CSCF.
    • 28. Die S-CSCF gibt die endgültige ACK-Nachricht an den abschließenden Endpunkt, über das S-S-Verfahren. Oft ist es jedoch für die MS notwendig, eine aufgezeichnete Ankündigung von der gerufenen Partei zu empfangen, statt sich mit der gerufenen Partei zu verbinden, um eine Konversation weiterzuführen. In einem solchen Fall wird die aufgezeichnete Ankündigung von einem Knoten an einer anderen Adresse als der der gerufenen Partei ausgegeben, und die Technik gemäß der vorliegenden Erfindung erleichtert die Initiierung eines PDP-Kontextmodifikationsverfahrens, um das Traffic FloW Template (TFT) gemäß der Transportadresse (TA) des Knotens festzulegen.
  • Betrachtet man die 8, die ein Beispiel einer Technik für das Liefern von Ankündigungen in von einer Mobilstation ausgehenden Verbindungen gemäß der vorliegenden Erfindung zeigt, so wird in Schritt#1 eine Aufbaunachricht von einer MS an einen Teilnehmer gesandt.
  • Diese Aufbaunachricht wird vom Netz abgefangen, das angewiesen worden ist, eine Ankündigungsnachricht in Erwiderung auf einen Rufaufbau an die gerufene Partei zu geben. Die Maschine, die die Ankündigung abspielen wird, die in der Zeichnungsfigur als Entfernte CSCF/REP bezeichnet wird, bestätigt in Schritt#2 die Aufbaunachricht mit einer Verbindungsnachricht, die ihre IP-Adresse und Port-Nummer einschließt, das ist die TA der entfernten Einrichtung, um es so der MS zu erlauben, dass sie sich passend mit ihr verbindet.
  • Nachfolgend aktiviert die MS in den Schritten #3, #4, #5, #6 und #7 einen zweiten PDP-Kontext, der ein TFT einschließt, das es der Maschine erlaubt, Verkehr zur MS zu senden. Das heißt, das TFT umfasst die entfernte Ausrüstung TA (das ist die IP-Adresse und die Port-Nummer).
  • Im Schritt #8 bestätigt die MS die Akzeptanz des zweiten PDP-Kontexts, und im Schritt #9 spielt die entfernte Ausrüstung die Ankündigung der MS ab.
  • Somit wird gemäß der vorliegenden Erfindung, nachdem eine MS versucht hat, eine Verbindung mit einer gerufenen Partei aufzubauen, die wünscht, mit einer Ankündigung zu antworten, die entfernte Ausrüstungsmaschine, die durch die gerufene Partei bestimmt wurde, eine solche Ankündigung zu machen, ihre TA an die MS liefern. Die MS wiederum aktiviert einen zweiten PDP-Kontext mit einem TFT der entfernten Ausrüstung, um es der entfernten Ausrüstungsmaschine zu erlauben, ihre Ankündigung an die MS zu geben.
  • Dies beschließt die Beschreibung der beispielhaften Ausführungsformen. Obwohl die vorliegende Erfindung unter Bezug auf eine illustrierende Ausführungsform beschrieben wurde, sollte verständlich sein, dass viele andere Modifikationen und Ausführungsformen, die in den Umfang der Prinzipien dieser Erfindung fallen, von Fachleuten ins Auge gefasst werden können. Insbesondere sind angemessene Variationen und Modifikationen in den Bauteilen und/oder den Anordnungen der gegenständlichen Kombinationsanordnung innerhalb des Umfangs der angefügten Ansprüche möglich. Zusätzlich zu Variationen und Modifikationen in den Bauteilen und/oder Anordnungen werden Fachleute alternative Gebrauchsmöglichkeiten erkennen.

Claims (9)

  1. Verfahren zum Bereitstellen einer Ankündigung in einem Kommunikationsnetzwerk, wobei das Verfahren umfasst: – Einrichten eines ersten Paketdatenprotokoll-, PDP, Kontextes für ein erstes Netzwerkelement; – Bestimmen, dass eine Ankündigung dem ersten Netzwerkelement abzuspielen ist; – Senden, unter Verwendung des ersten PDP Kontextes, einer Identität eines zweiten Netzwerkelements, das die Ankündigung abspielen soll; – Einrichten eines sekundären PDP Kontextes, wobei Parameter des sekundären PDP Kontextes gemäß der übertragenen Identität eingerichtet werden; und – dem ersten Netzwerkelement die Ankündigung unter Verwendung des sekundären PDP Kontextes abspielen.
  2. Verfahren nach Anspruch 1, wobei die übertragene Identität eine Internet Protokoll, IP, Adresse umfasst.
  3. Verfahren nach Anspruch 1, wobei die übertragene Identität eine Portnummer umfasst.
  4. Verfahren nach Anspruch 1, wobei die übertragene Identität eine Transportadresse, TA, umfasst.
  5. Verfahren nach Anspruch 1, wobei das erste Netzwerkelement eine Mobilstation, MS, umfasst.
  6. Verfahren nach Anspruch 1, wobei die Parameter Filterinformationen umfassen.
  7. Verfahren nach Anspruch 6, wobei die Filterinformationen ein Traffic Flow Template, TFT, umfassen.
  8. Verfahren nach Anspruch 1, wobei das Einrichten des sekundären PDP Kontextes das Einschließen einer Transportadresse, TA, in einem Traffic Flow Template, TFT, umfasst.
  9. Maschinenlesbare Programmspeichervorrichtung, umfassend ein Programm von Anweisungen, die eine Maschine anweisen, alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 8 auszuführen, wenn durch die Maschine ausgeführt.
DE60225278T 2001-04-09 2002-04-09 Technik zur verbesserung von ansagen in anrufen mit mobilursprung Expired - Lifetime DE60225278T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/827,917 US7054945B2 (en) 2001-04-09 2001-04-09 Technique for providing announcements in mobile-originated calls
US827917 2001-04-09
PCT/IB2002/001121 WO2002082781A2 (en) 2001-04-09 2002-04-09 Technique for providing announcements in mobile-originated calls

Publications (2)

Publication Number Publication Date
DE60225278D1 DE60225278D1 (de) 2008-04-10
DE60225278T2 true DE60225278T2 (de) 2009-03-26

Family

ID=25250475

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60225278T Expired - Lifetime DE60225278T2 (de) 2001-04-09 2002-04-09 Technik zur verbesserung von ansagen in anrufen mit mobilursprung

Country Status (15)

Country Link
US (1) US7054945B2 (de)
EP (1) EP1397750B1 (de)
JP (1) JP3901095B2 (de)
KR (1) KR100879811B1 (de)
CN (1) CN1278250C (de)
AT (1) ATE387669T1 (de)
AU (1) AU2002246300B2 (de)
BR (1) BR0208709A (de)
CA (1) CA2443690A1 (de)
DE (1) DE60225278T2 (de)
ES (1) ES2302799T3 (de)
MX (1) MXPA03009181A (de)
RU (1) RU2282312C2 (de)
WO (1) WO2002082781A2 (de)
ZA (1) ZA200307615B (de)

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8295269B1 (en) 2000-04-10 2012-10-23 Nokia Corporation Technique for informing network of voice traffic
SE0002572D0 (sv) 2000-07-07 2000-07-07 Ericsson Telefon Ab L M Communication system
US7249170B2 (en) * 2000-12-06 2007-07-24 Intelliden System and method for configuration, management and monitoring of network resources
EP1250023A1 (de) * 2001-04-11 2002-10-16 Alcatel Garantie der Servicequalität für Teilnehmer, die mittels eines anderen Netzes kommunizieren
DE10120772A1 (de) * 2001-04-24 2002-11-07 Siemens Ag Heterogenes Mobilfunksystem
US20040255039A1 (en) * 2001-05-10 2004-12-16 Bernard Honeisen Method, system and network element device for controlling sessions between terminals
US20050013285A1 (en) * 2001-05-28 2005-01-20 Iikka Westman Optimal routing when two or more network elements are integrated in one element
US20030003894A1 (en) * 2001-06-27 2003-01-02 Kumar Anil K. Developing mobile unit based estimates of metered packet charges
KR100389819B1 (ko) * 2001-07-09 2003-07-02 삼성전자주식회사 부호분할다중접속 이동통신시스템에서 패킷 데이터 전송방법
US20030039259A1 (en) * 2001-07-10 2003-02-27 Lila Madour Traffic flow template for managing packet data flows
US7406057B2 (en) * 2001-10-31 2008-07-29 Spyder Navigations L.L.C. Method for handling of messages between a terminal and a data network
FI20012561A (fi) * 2001-12-21 2003-06-22 Nokia Corp Loogisen yhteyden modifiointi
KR100438430B1 (ko) 2002-01-24 2004-07-03 삼성전자주식회사 이동통신시스템에서 트래픽 플로우 탬플릿 재정렬 장치 및방법
NO20020667D0 (no) * 2002-02-11 2002-02-11 Ericsson Telefon Ab L M Fremgangsmåte for å unngå unödig okkupering av ressurser i pakkesvitsjede mobilnett
US7792973B2 (en) * 2002-03-12 2010-09-07 Verizon Business Global Llc Systems and methods for initiating announcements in a SIP telecommunications network
GB2387069A (en) * 2002-03-27 2003-10-01 Ericsson Telefon Ab L M Indicating different charging regimes for user and signalling data in a communications network
US7616607B2 (en) * 2002-04-10 2009-11-10 Telefonaktiebolaget L M Ericsson (Publ) Data preservation
BR0305017A (pt) * 2002-06-06 2005-02-09 Thomson Licensing Sa Wlan como um nó de suporte lógico para acoplamento hìbrido em uma interação entre wlan e um sistema de comunicação móvel
US20040028080A1 (en) * 2002-08-06 2004-02-12 Harish Samarasinghe Method of defining a SIP message body for communications between core network elements
US7254643B1 (en) 2002-08-08 2007-08-07 At&T Corp. System and method for providing multi-media services to communication devices over a communications network
US7330448B2 (en) * 2002-08-21 2008-02-12 Thomson Licensing Technique for managing quality of services levels when interworking a wireless local area network with a wireless telephony network
US20040037264A1 (en) * 2002-08-23 2004-02-26 Charbel Khawand Pre-negotiated quality of service
WO2004030309A2 (en) 2002-09-24 2004-04-08 Orange Sa A method for a gateway to select a channel for transferring data packets
KR100554799B1 (ko) 2002-11-19 2006-02-22 엘지전자 주식회사 Gsm이동통신 시스템의 전송 데이타 암호화 및 암호화 해제 방법
GB2396444A (en) * 2002-12-18 2004-06-23 Nokia Corp A Method of Announcing Sessions
US7180912B1 (en) 2003-01-06 2007-02-20 At&T Corp. System and method for providing a plurality of multi-media services using a number of media servers to form a preliminary interactive communication relationship with a calling communication device
JP4164379B2 (ja) * 2003-02-06 2008-10-15 キヤノン株式会社 検査方法
US7508923B1 (en) 2003-02-27 2009-03-24 At&T Corp. Call control element constructing a session initiation protocol (SIP) message including provisions for incorporating address related information of public switched telephone network (PSTN) based devices
US7701915B2 (en) * 2003-06-27 2010-04-20 Nokia Corporation Method in a communication system, a communication system and a communication device
US7327746B1 (en) * 2003-08-08 2008-02-05 Cisco Technology, Inc. System and method for detecting and directing traffic in a network environment
US20050041631A1 (en) * 2003-08-20 2005-02-24 Naveen Aerrabotu Apparatus and method for primary link packet control
GB2405557A (en) * 2003-08-27 2005-03-02 Nokia Corp Service identification data relating services at a given frequency to services and identifying their media format
US7283506B2 (en) * 2003-10-13 2007-10-16 Nokia Corporation System and method for releasing sessions at network entities associated with the sessions
GB0324596D0 (en) * 2003-10-21 2003-11-26 Nokia Corp Sessions in a communication system
ATE398376T1 (de) 2003-12-05 2008-07-15 Ericsson Telefon Ab L M Verfahren und vorrichtung zur herstellung einer kommunikationssitzung zwischen zwei endgeräten
GB2417650A (en) 2004-07-30 2006-03-01 Orange Personal Comm Serv Ltd Tunnelling IPv6 packets over IPv4 packet radio network wherein an IPv6 address including a tunnel end identifier of the IPv4 bearer is formed
US8230144B1 (en) * 2004-10-19 2012-07-24 Broadcom Corporation High speed multi-threaded reduced instruction set computer (RISC) processor
US8139739B2 (en) * 2005-05-06 2012-03-20 At&T Mobility Ii Llc Enhanced alerting system
US7907541B2 (en) * 2005-08-22 2011-03-15 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for establishing a communication session for multimedia
WO2007029593A1 (ja) * 2005-09-07 2007-03-15 Matsushita Electric Industrial Co., Ltd. 携帯電話装置およびその制御方法
TW200803370A (en) * 2006-05-03 2008-01-01 Interdigital Tech Corp Wireless communication method and system for activating multiple service bearers via efficient packet data protocol context activation procedures
US20070258427A1 (en) * 2006-05-03 2007-11-08 Interdigital Technology Corporation Wireless communication method and system for activating multiple service bearers via efficient packet data protocol context activation procedures
CN101128041B (zh) 2006-08-15 2010-05-12 华为技术有限公司 接入网和核心网间下行数据隧道失效后的处理方法和系统
US8239241B2 (en) * 2006-08-29 2012-08-07 International Business Machines Corporation Method and apparatus for providing information about anticipated delays to customers at service centers, contact centers, or call centers
US7684387B2 (en) * 2006-10-06 2010-03-23 Motorola, Inc. Method for routing combinational services to a single endpoint
CN101094152B (zh) * 2006-11-07 2010-08-18 中兴通讯股份有限公司 一种分组域单隧道无线网络控制器错误的处理方法
US8959239B2 (en) * 2006-12-29 2015-02-17 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for reporting streaming media quality
US20080235778A1 (en) * 2007-03-21 2008-09-25 Motorola, Inc. Communication network, an access network element and a method of operation therefor
US20080235185A1 (en) * 2007-03-21 2008-09-25 Motorola, Inc. Communication system and method of accessing therefor
US8077685B2 (en) * 2007-04-24 2011-12-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for avoiding hanging PDP contexts
WO2009006942A1 (en) * 2007-07-10 2009-01-15 Telefonaktiebolaget Lm Ericsson (Publ) Methods, apparatuses and computer program for ims recovery upon restart of a s-cscf
JP2010535449A (ja) * 2007-07-30 2010-11-18 テレフオンアクチーボラゲット エル エム エリクソン(パブル) メディアフローの選択方法
CN101808270B (zh) * 2010-03-10 2016-03-30 华为终端有限公司 一种基于Android的业务处理方法和装置
KR101791533B1 (ko) * 2011-04-28 2017-10-30 삼성전자 주식회사 이동통신 시스템에서 자원 예약 방법 및 시스템
CN109195200B (zh) * 2018-08-27 2021-01-15 京信通信系统(中国)有限公司 Apn分配方法、装置、通信设备和系统
US11082536B2 (en) * 2018-10-24 2021-08-03 Jeffrey T. Schultz Mobile announcement system

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3949288B2 (ja) 1997-09-22 2007-07-25 株式会社東芝 ゲートウェイ装置及び無線端末装置
JPH11163947A (ja) 1997-09-22 1999-06-18 Toshiba Corp ゲートウェイ装置、無線端末装置、ルータ装置および通信ネットワークのゲートウェイ制御方法
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
DE19849540B4 (de) * 1998-07-06 2006-09-28 Siemens Ag Verfahren und Mobilfunknetz zur Behandlung eines Paketdatendienstes
JP2003502379A (ja) * 1999-06-17 2003-01-21 ファルマシア・アクチボラゲット 性的機能不全の治療のための成長ホルモン(hGH)投与
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
US7123920B1 (en) 2000-04-10 2006-10-17 Nokia Corporation Technique for setting up calls in mobile network
US6654610B1 (en) * 2000-05-05 2003-11-25 Lucent Technologies Inc. Two-way packet data protocol methods and apparatus for a mobile telecommunication system
US6621793B2 (en) * 2000-05-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Application influenced policy
US7126939B2 (en) * 2000-07-24 2006-10-24 Nortel Networks Limited Packet-based calls in a wireless network
US6546247B1 (en) * 2000-09-08 2003-04-08 Telefonaktiebolaget L M Ericsson (Publ) Home location server and call processing method in a hybrid second/third generation radio telecommunications network
US6834044B2 (en) * 2001-02-15 2004-12-21 Telefonaktiebolaget L M Ericsson (Publ) Multi-path data streaming in a wireless packet data network

Also Published As

Publication number Publication date
EP1397750B1 (de) 2008-02-27
CN1278250C (zh) 2006-10-04
US7054945B2 (en) 2006-05-30
EP1397750A4 (de) 2005-09-14
ZA200307615B (en) 2004-06-03
RU2003132473A (ru) 2005-05-27
US20020147824A1 (en) 2002-10-10
RU2282312C2 (ru) 2006-08-20
EP1397750A2 (de) 2004-03-17
ATE387669T1 (de) 2008-03-15
JP2004534438A (ja) 2004-11-11
MXPA03009181A (es) 2004-02-17
WO2002082781B1 (en) 2004-02-12
BR0208709A (pt) 2004-07-20
KR20030085102A (ko) 2003-11-01
WO2002082781A2 (en) 2002-10-17
CA2443690A1 (en) 2002-10-17
AU2002246300B2 (en) 2007-08-09
JP3901095B2 (ja) 2007-04-04
CN1502078A (zh) 2004-06-02
DE60225278D1 (de) 2008-04-10
KR100879811B1 (ko) 2009-01-22
WO2002082781A3 (en) 2003-12-24
ES2302799T3 (es) 2008-08-01

Similar Documents

Publication Publication Date Title
DE60225278T2 (de) Technik zur verbesserung von ansagen in anrufen mit mobilursprung
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE60130911T2 (de) Verfahren und gerät für die koordinierte verrechnung von diensten in einer multimedia-sitzung
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE602004009913T2 (de) Verfahren, system und netzwerkelement zur autorisierung einer datenübertragung
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
DE60107067T2 (de) Verfahren zum aufbau von anrufen in einem mobilen internet-protokoll-netzwerk
DE60209007T2 (de) Vergebührung in kommunikationssystemen
DE60112480T2 (de) Dienstqualität (QoS) für ein Universales Mobiltelekommunikationssystem (UMTS) mit Unterstützung einer Verhandlung einer einstellbaren Dienstqualität
DE60127815T2 (de) Verfahren zur rufkontrolle um verzögerungen beim starten von multimedia- oder sprachrufen in einem paketvermittelten funkkommunikationsnetz zu minimieren
DE60130114T2 (de) Anwendungsbeeinflusste richtlinie
DE60127869T2 (de) Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente
DE60211881T2 (de) Bindungsinformation für ip mediendatenströmen
DE602004010516T2 (de) Konversationsträgerverhandlung
DE60129347T2 (de) Überwachung der verbindung zu einem benutzerendgerät in einem telekommunikationssystem
DE60124087T2 (de) Verfahren zur überwachung von anrufen in einem ip-basierten netzwerk
DE60030858T2 (de) Verfahren und anordnung zur anzeige der speziellen verwendung eines pdp kontexts
DE69926799T2 (de) Verfahren und system zur begrenzung der dienstqualität einer datensübertragung
DE60125422T2 (de) Abbildung von paketen auf pdp-kontexte bei vielfach-verbindungen
DE102006022046B4 (de) Verfahren zum Ermöglichen einer Steuerung der Dienstqualität und/oder der Dienstvergebührung bei Telekommunikationsdiensten
WO2002087160A2 (de) Heterogenes mobilfunksystem
DE10105093A1 (de) Paging-Verfahren und -System für ein Funkzugriffsnetz
DE60100613T2 (de) Verfahren zur Bereitstellung von Mehrfachverbindungspunkten zu Nutzern von drahtlosen Kommunikationsnetzen
DE10133472A1 (de) Verfahren, Vorrichtungen und Software-Programme zur Nachrichtenübermittlung zwischen Telekommunikations-Netzwerkelementen
DE69933286T2 (de) Telekommunikationssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition