ES2302799T3 - Tecnica para proporcionar anuncios en llamadas originadas por moviles. - Google Patents

Tecnica para proporcionar anuncios en llamadas originadas por moviles. Download PDF

Info

Publication number
ES2302799T3
ES2302799T3 ES02714398T ES02714398T ES2302799T3 ES 2302799 T3 ES2302799 T3 ES 2302799T3 ES 02714398 T ES02714398 T ES 02714398T ES 02714398 T ES02714398 T ES 02714398T ES 2302799 T3 ES2302799 T3 ES 2302799T3
Authority
ES
Spain
Prior art keywords
pdp
context
pdp context
sgsn
ggsn
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
ES02714398T
Other languages
English (en)
Inventor
Tuija Hurtta
Stefano 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 ES2302799T3 publication Critical patent/ES2302799T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Medicines Containing Plant Substances (AREA)

Abstract

Un método para proporcionar un anuncio en una red de comunicaciones, comprendiendo el método lo siguiente: - establecer un primer contexto PDP, Protocolo de Datos de Paquete, para un primer elemento de red; - determinar que el anuncio va a realizarse en el primer elemento de red; - enviar, empleando dicho primer contexto PDP, una identidad de un segundo elemento de red que va a realizar el anuncio; - establecer un segundo contexto PDP, donde los parámetros de dicho segundo contexto PDP se establecen de acuerdo con la identidad transmitida; y - realizar el anuncio al primer elemento de red usando dicho contexto secundario PDP.

Description

Técnica para proporcionar anuncios en llamadas originadas por móviles.
Técnica del contexto
La presente invención se refiere a redes móviles y más en particular, la presente invención se refiere a una técnica para proporcionar anuncios para llamadas originadas por móviles en una red móvil que emplea un mecanismo de transporte de IP (Protocolo de Internet). En general, las redes inalámbricas de intercambio de paquetes proporcionan comunicaciones para terminales móviles sin que sea necesaria una conexión física para el acceso a la red. Tanto el Servicio General de Paquetes de Radio (GPRS) en el Sistema Global de Comunicaciones Móviles (GSM) como el Sistema Universal de Telecomunicaciones Móviles (UMTS) se han desarrollado para facilitar redes inalámbricas de comunicación con una sección para el intercambio de paquete y otra sección para el intercambio de circuito.
Tal y como se observa en su página web http://www.3gpp.org, el Proyecto Conjunto de Tercera Generación, normalmente conocido por su acrónimo 3GPP, es una organización cuyos socios se han puesto de acuerdo en cooperar en la producción de Especificaciones Técnicas e Informes Técnicos globalmente aplicables para un Sistema Móvil de 3ª Generación basado en redes con núcleo GSM y en la tecnología radial de acceso que estas redes soportan (es decir, el Acceso Universal por Radio Terrestre (UTRA) tanto el modo de División de Tiempo Dúplex (FDD) como el de División de Frecuencia Dúplex (TDD)).
Además, los socios de 3GPP han estado de acuerdo en cooperar con el mantenimiento y el desarrollo de un Sistema Global para Comunicaciones Móviles (GSM) creando Especificaciones Técnicas e Informes Técnicos que incluyen la evolución o desarrollo de tecnologías de acceso radial (por ejemplo, el Servicio General de Paquetes de Radio (GPRS) y los Datos Mejorados para la Evolución Global GSM (EDGE)).
Por consiguiente, 3GPP presenta varias Especificaciones Técnicas que posteriormente la industria de las telecomunicaciones emplea para producir terminales móviles y sistemas asociados que han sido estandarizados de tal modo que una terminal móvil de un fabricante pueda comunicarse con un sistema o una terminal móvil de otro fabricante. Estas Especificaciones Técnicas se revisan constantemente de acuerdo con los acuerdos a los que llegaron los socios de 3GPP para permitir cambios y mejoras en la tecnología.
La Especificación Técnica TS 23.060, Versión V3.3.0, se presentó en enero de 2001 por el 3GPP y define la descripción del paso 2 del servicio para el dominio del paquete, que incluye GPRS en GSMA y UMTS.
Un abonado a una red puede tener una o más direcciones (PDP). Cada dirección PDP se describe mediante uno o más contextos PDP en la Estación Móvil (MS), el Nodo de Soporte GPRS servidor (SGSN), y el Nodo de Soporte GPRS Pasarela. Cada contexto PDP puede tener información de mapeo y ruteo para dirigir la transferencia de datos a y desde su dirección PDP asociada y una Plantilla de Flujo de Tráfico (TFT) para revisar los datos transferidos.
Cada contexto PDP puede activarse, modificarse y desactivarse de manera selectiva e independiente. El estado de activación del contexto PDP indica si la transferencia de datos está habilitada para una dirección PDP y una TFT correspondiente. Si todos los contextos PDP asociados con la misma dirección PDP se encuentran inactivos o desactivados, se deshabilita toda la transferencia de datos para esa dirección PDP. Todos los contextos PDP de un abonado están asociados con el mismo contexto de Gestión de Movilidad (MM) para la Identidad Internacional del Abonado a un Móvil (IMSI) del abonado en cuestión. Establecer un contexto PDP significa establecer un canal de comunicación entre la MM y el GGSN.
La Fig. 1, únicamente presentada con fines ejemplares, muestra el procedimiento de activación del contexto PDP entre una MM y un GGSN en un sistema UMTS y corresponde a la Fig. 62 de la Especificación Técnica anteriormente mencionada. La siguiente descripción de los pasos de la Fig. 1 también están contenidos en ella.
1)
La MS envía un mensaje de Petición de Contexto PDP activado (NSAPI, TI, Tipo PDP, Dirección PDP, Nombre de Punto de Acceso, QoS Solicitada, Opciones de Configuración PDP) al SGNS. La MS puede emplear la Dirección PDP para indicar si necesita o no el uso de una dirección PDP estática o si necesita o no el uso de una dirección PDP dinámica. La MS puede dejar vacía la dirección PDP para solicitar una dirección PDP dinámica. La MS puede usar el Nombre de Punto de Acceso para seleccionar un punto de referencia para una red externa determinada y/o para seleccionar un servicio. El Nombre de Punto de Acceso es un nombre lógico que se refiere a la red externa de datos de paquete y/o al servicio al que el abonado desea conectarse. La QoS solicitada indica el perfil QoS deseado. Las Opciones de Configuración PDP pueden emplearse para solicitar parámetros opcionales PDP del GGSN (ver GSM 09.60). Las Opciones de Configuración PDP se envían de modo transparente a través del SGSN.
3)
En el UMTS, el sistema RAB se lleva a cabo mediante el procedimiento de Asignación RAB, ver la cláusula subsidiaria "Procedimiento de Asignación RAB".
5)
El SGSN valida la Petición del Contexto PDP Activado usando el Tipo PDP (opcional), la Dirección PDP (opcional), y el Nombre de Punto de Acceso (opcional) provistos por los registros de suscripción a la MS y al contexto PDP. Los criterios de validación, los criterios de selección de APN y el mapeo de APN a GGSN se describen en el Anexo A.
Si no se puede derivar ninguna dirección GGSN o si el SGSN ha determinado que la Petición del Contexto PDP Activado no es válida de acuerdo con las reglas descritas en el Anexo A, entonces el SGSN rechaza la petición de activación del contexto PDP.
Si se puede derivar una dirección GGSN, el SGSN crea un TEID para el contexto PDP solicitado. Si la MS solicita una dirección dinámica, entonces el SGSN permite que un GGSN asigne la dirección dinámica. El SGSN puede restringir los atributos solicitados de QoS debido a sus capacidades, a la carga actual, y al perfil QoS suscrito o abonado.
El SGSN envía un mensaje de Petición para Crear un Contexto PDP (Tipo PDP, Dirección PDP, Nombre de Punto de Acceso, QoS Negociada, TEID, NSAPI, MSISDN, Modo de Selección, Características de Carga, Referencia de Rastro, Tipo de Rastro, Activador Id, Identidad OMC, Opciones de Configuración PDP) al GGSN afectado. El Nombre de Punto de Acceso debe ser el identificador de Red APN del APN seleccionado de acuerdo con el procedimiento descrito en el Anexo A. La dirección PDP puede estar vacía si se solicita una dirección dinámica. El GGSN puede emplear un Nombre de Punto de Acceso para encontrar una red externa y opcionalmente puede activar el servicio para este APN. El Modo de Selección indica si se ha seleccionado un abonado APN, o si se ha seleccionado un APN no abonado enviado por MS o un APN no abonado elegido por SGSN. El Modo de Selección está establecido de acuerdo con el Anexo A. El GGSN puede emplear el Modo de Selección cuando se decide si acepta o rechaza la activación del contexto PDP. Por ejemplo, si un APN requiere una suscripción, en este caso el GGSN se configura para aceptar solamente la activación del contexto PDP que solicite un APN suscrito tal y como se indica por el SGSN con el Modo Selección. Las Características de Carga indican qué tipo de carga le corresponde al Contexto PDP. El SGSN puede copiar las Características de Carga de las Características de Carga Suscritas si las recibe del HLR. El SGSN debe incluir Referencia de Rastro, Tipo de Rastro, Activador Id, e Identidad OMC si se activa el rastro GGSN. El SGSN debe copiar la Referencia de Rastro, el Tipo de Rastro, el Activador Id, e Identidad OMC de la información de rastro recibida del HRL u OMC.
El GGSN crea una nueva entrada para su mesa de contexto PDP y genera una Carga Id. La nueva entrada permite que GGSN haga una ruta por PDP PDUs entre la red SGSN y la red externa PDP, y que empiece a cargarse. El GGSN puede además restringir la QoS Negociada debido a sus incapacidades o a su carga actual. Entonces, el GGSN vuelve al mensaje de Respuesta Creativa de Contexto PDP (TEID, Dirección PDP, Opciones de Configuración PDP, QoS Negociada, Carga Id, Causa) al SGSN. Se incluye una Dirección PDP en el caso de que GGSN asignara una dirección PDP. Si el GGSN ha sido configurado por el operador para usar Asignación Externa de Dirección PDP para el APN solicitado, entonces la dirección PDP debe negociarse por parte de la MS con el PDN externo después de haber completado el procedimiento de Activación del Contexto PDP. El GGSN puede transmitir, modificar y controlar esta negociaciones siempre y cuando el contexto PDP se encuentre en estado ACTIVO y puede emplear el procedimiento de Modificación de Contexto PDP Iniciado por SGSN para transferir la dirección PDP que se emplea actualmente al SGSN y a la MS. Las Opciones de Configuración PDP contienen parámetros opcionales PDP que el GGSN puede trasmitir a la MS. Estos parámetros opcionales PDP pueden ser solicitados por parte de la MS en el mensaje de Petición de Contexto PDP Activo, o pueden enviarse sin necesidad de ser solicitados por parte del GGSN. Las Opciones de Configuración de PDP se envían de modo transparente a través del SGSN. Los mensajes de Creación de Contexto PDP se envían a través de la red troncal.
Si la QoS Negociada recibida desde el SGSN es incompatible con el contexto PDP que está inactivado, en este caso el GGSN rechaza el mensaje de petición de creación de Contexto PDP. Los perfiles de QoS compatibles se configuran por parte del operador GGSN.
7)
El SNSG inserta el NSAPI junto con la dirección GGSN en su contexto PDP. Si la MS ha solicitado una dirección dinámica, la dirección PDP recibida del GGSN se inserta en el contexto PDP. El SGSN selecciona la Prioridad de Radio y el Flujo de Paquete Id en base a la QoS Negociada, y vuelve al mensaje de Aceptación del Contexto PDP Activo (Tipo PDP, Dirección PDP, TI, QoS Negociada, Prioridad de Radio, Flujo de Paquete Id, Opciones de Configuración PDP) a la MS. Ahora, el SGSN es capaz de establecer la ruta PDP PDUs entre el GGSN y la MS, para comenzar la carga.
De manera similar, la Fig. 2, también presentada con fines únicamente ejemplares, muestra el Procedimiento de Activación de Contexto Secundario PDP y se corresponde con la Fig. 64 de la Especificación Técnica anteriormente mencionada. La siguiente descripción de los pasos de la Fig. 2 también está contenida en ella.
El Procedimiento de Activación de Contexto Secundario PDP puede emplearse para activar un contexto PDP mientras se está volviendo a usar la dirección PDP y otra información del contexto PDP de un contexto PDP ya activo, pero con un perfil QoS diferente. Los procedimientos para la selección APN y la negociación de la dirección PDP no se ejecutan. Cada contexto PDP que comparte la misma dirección PDP y APN puede identificarse mediante una única TI y una única NSAPI.
El Procedimiento de Activación de Contexto Secundario PDP puede ejecutarse sin proporcionar una Plantilla de Flujo de Tráfico (TFT) al contexto PDP recién activado si el resto de contextos PDP activos para esta dirección PDP y APN ya tienen una TFT asociada. Si no se puede proporcionar una TFT. La TFT contiene atributos que especifican un filtro de compensación IP que se emplea para dirigir paquetes de datos recibidos desde la red externa de datos de paquetes interconectados al contexto PDP recién activado.
1)
La MS envía un mensaje de Petición de Contexto PDP Secundario Activado (TI enlazada, NSAPI, TI, QoS Solicitada, TFT) al SGSN. La TI Enlazada indica que el valor TI asignado a cada uno de los contextos PDP ya activados para esta dirección PDP y APN. La QoS solicitada indica el perfil QoS deseado. TFT se envía de manera transparente a través de SGSN al GGSN para permitir la clasificación de paquetes para la transferencia de datos de enlace descendente. TI y NSAPI contienen valores no empleados por otro contexto PDP activado.
2)
En UTMS, el sistema RAB se lleva a cabo mediante el procedimiento de Asignación RAB.
3)
El SGSN valida la Petición de Contexto PDP Secundario Activo usando la TI indicada por la TI Enlazada. Se emplea la misma dirección GGSN por el SGSN que para los contextos PDP ya activados para esa TI y dirección PDP.
El SGSN y el GGSN pueden restringir y negociar la QoS solicitada tal y como se especifica en la subcláusula "Procedimiento de activación de Contexto PDP". El SGSN envía un mensaje de Pericón de Creación de Contexto PDP (QoS Negociada, TEID, NSAI, NSAPI Primaria, TFT) al GGSN afectado. La NSAPI Primaria indica el valor NSAPI asignado a cada uno de los contextos PDP ya activados para esta dirección PDP y APN. La TFT se incluye únicamente si se recibe en el mensaje de Petición de Contexto Secundario PDP Activado. El GGSN emplea la misma red externa que la usada por los contextos PDP ya activados para esa dirección PDP, genera una nueva entrada en su tabla de contexto PDP, y almacena la TFT. La nueva entrada permite que el GGSN pueda establecer rutas PDP PDUs por medio de diferentes túneles GTP entre el SGSN y la red externa PDP. El GGSN vuelve al mensaje de Respuesta a la Creación de Contexto PDP (TEID, QoS Negociada, Causa) al SGSN.
6)
El SGSN selecciona una Prioridad de Radio y una Id de Flujo de Paquetes en base a la QoS Negociada, y regresa al mensaje de Aceptación de Contexto Secundario PDP Activado (TI, QoS Negociada, Prioridad de Radio, Id Flujo de Paquete) a la MS. Ahora, el SGSN es capaz de establecer rutas PDP PDUs entre el GGSN y la MS por medio de diferentes túneles GTP y posiblemente diferentes enlaces LLC.
La Fig. 3, también presentada únicamente con fines ejemplares, muestra el procedimiento de modificación de contexto PDP iniciado por SGSN y se corresponde con la Fig. 68 de la Especificación Técnica anteriormente mencionada. La siguiente descripción de los pasos en la Fig. 3 también está contenida en la misma.
Una MS o un GGSN puede solicitar, un SGSN puede decidir, posiblemente activado por el HLR tal y como se explica en la subcláusula "Procedimiento de Inserción de Datos del Abonado" o activado por el procedimiento de Liberación RAB iniciado por un RNC, o una MS y un SGSN puede decidir, tras la liberación iniciada por RNC, modificar los parámetros que se negociaron durante una procedimiento de activación para uno o varios contextos PDP. Se pueden modificar los siguientes parámetros:
-
QoS (Calidad de Servicio) Negociada;
-
Prioridad de Radio;
-
Id Flujo de Paquete;
-
Dirección PDP (en el caso de que procedimiento de modificación haya sido iniciado por GGSN); y
-
TFT (en el caso de que el procedimiento de modificación haya sido iniciado por MS).
El SGSN puede solicitar la modificación de parámetros enviando un mensaje de Petición de Modificación de Contexto PDP a la MS.
Un GGSN puede solicitar la modificación de parámetros enviando un mensaje de Petición de Actualización de Contexto PDP al SGSN.
Una MS puede solicitar la modificación de parámetros enviando un mensaje de Petición de Modificación de Contexto PDP al SGSN.
Un RNC puede solicitar una liberación enviando un mensaje de Petición de Liberación al SGSN. Tras la liberación la MS y el SGSN pueden modificar los contextos PDP de acuerdo con los principios establecidos en la subcláusula "Procedimiento de Modificación de Contexto PDP Iniciado por RNC".
Un RNC puede solicitar la liberación del portador de acceso de radio. Tras la liberación RAB la MS y el SGSN pueden modificar localmente el contexto PDP correspondiente de acuerdo con los principios establecidos en la subcláusula "Procedimiento de Modificación de Contexto Local PDP Iniciado por liberación RAB".
Puede activarse un rastro mientras el contexto PDP está activo. Para habilitar la activación del rastro en un GGSN, el SGSN puede enviar un mensaje de Petición de Actualización de Contexto PDP al GGSN. Si la modificación del contexto PDP se lleva a cabo únicamente para activar un rastro, entonces el SGSN puede no enviar un mensaje de Petición de Modificación de Contexto PDP a la MS.
1) El SGSN puede enviar un mensaje de Petición de Contexto PDP (TEID, NSAPI, QoS Negociada, Referencia de Rastro, Tipo de Rastro, Indicador Id, Identidad OMC) al GGSN. Si la QoS Negociada recibida es incompatible con el contexto PDP que se está modificando, en ese caso el GGSN rechaza la Petición de Actualización de Contexto PDP. Los perfiles QoS compatibles se configuran por medio del operador GGSN. El SGSN puede incluir una Referencia de Rastro, Tipo de Rastro, Indicador Id e Identidad OMC en el mensaje si el rastro GGSN se activa mientras el contexto PDP está activo. El SGSN puede copiar la Referencia de Rastro, el Tipo de Rastro, y la Identidad OMC a partir de la información de rastro recibida del HLR u OMC.
2) El GGSN puede restringir la QoS Negociada debido a sus incapacidades y a su carga actual. El GGSN almacena la QoS Negociada y devuelve un mensaje de Respuesta de Actualización de Contexto PDP (TEID, QoS Negociada, Causa).
3) El SGSN selecciona la Prioridad de Radio y el Id de Flujo de Paquetes sobre la QoS Negociada, y puede enviar un mensaje de Petición de Modificación de Contexto PDP (TI, QoS Negociada, Prioridad de Radio, Id Flujo de Paquetes) a la MS.
4) La MS lo admite devolviendo un mensaje de Aceptación de Contexto PDP Modificado. Si la MS no acepta la nueva QoS Negociada, tendrá que desactivar el contexto PDP con el Procedimiento MS Iniciado por la Desactivación del Contexto PDP.
5) En UMTS, la modificación del portador al acceso de radio puede llevarse a cabo mediante el Procedimiento de Asignación RAB.
6) Si el rastro BSS se activa mientras el contexto PDP está activo, en este caso el SGSN debe enviar un mensaje de Apelación de Rastro (Referencia de Rastro, Tipo de Rastro, Indicador Id, Identidad OMC) al BSS o UTRAN. La Referencia de Rastro y el Tipo de Rastro se copian a partir de la información de rastro que se recibe desde HLR u OMC.
1) El SGSN puede enviar un mensaje de Petición de Actualización de Contexto PDP (TEID, NSAPI, QoS Negociada, Referencia de Rastro, Tipo de Rastro, Indicador Id, Identidad OMC) al GGSN. Si la QoS Negociada recibida desde SGSN es incompatible con el contexto PDP que se está modificando, en este caso el GGSN rechaza la Petición de Actualización de Contexto PDP. Los perfiles QoS compatibles se configuran por medio del operador GGSN. El SGSN puede incluir una Referencia de Rastro, Tipo de Rastro, Indicador Id e Identidad OMC en el mensaje si el rastro GGSN se activa mientras el contexto PDP está activo. El SGSN puede copiar la Referencia de Rastro, el Tipo de Rastro, y la Identidad OMC a partir de la información de rastro recibida del HLR u OMC.
2) El GGSN puede restringir la QoS Negociada debido a sus incapacidades y a su carga actual. El GGSN almacena la QoS Negociada y devuelve un mensaje de Respuesta de Actualización de Contexto PDP (TEID, QoS Negociada, Causa).
3) El SGSN selecciona la Prioridad de Radio y el Id de Flujo de Paquetes sobre la QoS Negociada, y puede enviar un mensaje de Petición de Modificación de Contexto PDP (TI, QoS Negociada, Prioridad de Radio, Id Flujo de Paquetes) a la MS.
4) La MS lo admite devolviendo un mensaje de Aceptación de Contexto PDP Modificado. Si la MS no acepta la nueva QoS Negociada, tendrá que desactivar el contexto PDP con el Procedimiento MS Iniciado por la Desactivación del Contexto PDP.
5) En UMTS, la modificación del portador al acceso de radio puede llevarse a cabo mediante el Procedimiento de Asignación RAB.
6) Si el rastro BSS se activa mientras el contexto PDP está activo, en este caso el SGSN debe enviar un mensaje de Apelación de Rastro (Referencia de Rastro, Tipo de Rastro, Indicador Id, Identidad OMC) al BSS o UTRAN. La Referencia de Rastro y el Tipo de Rastro se copian a partir de la información de rastro que se recibe desde HLR u OMC.
La Fig. 4, también presentada únicamente con fines ejemplares, ilustra el procedimiento del Contexto PDP iniciado por el GGSN y corresponde con la Fig. 69 de la Especificación Técnica anteriormente mencionada. La siguiente descripción de los pasos de la Fig. 4 también están contenidos en ella.
1) El GGSN envía un mensaje de Petición de Actualización de Contexto PDP (TEID, NSAPI, Dirección PDP, QoS Solicitada) al SGSN. La QoS Solicitada indica el perfil de QoS deseado. La dirección PDP es opcional.
2) El SGSN puede restringir el perfil de QoS deseado debido a sus incapacidades, la carga actual, el perfil QoS actual, y el perfil QoS suscrito. El SGSN selecciona la Prioridad de Radio y la Id de Flujo de Paquetes en base a la QoS Negociada, y envía un mensaje de Petición de Modificación de Contexto PDP (TI, Dirección PDP, QoS Negociada, Prioridad de Radio, Id de Flujo de Paquetes) a la MS. La dirección PDP es opcional.
3) La MS lo admite devolviendo un mensaje de Aceptación de Contexto PDP Modificado. Si la MS no acepta la nueva QoS Negociada, tendrá que desactivar el contexto PDP con el Procedimiento MS Iniciado por la Desactivación del Contexto PDP.
4) En UMTS, la modificación del portador al acceso de radio puede llevarse a cabo mediante el Procedimiento de Asignación RAB.
5) Tras la recepción del mensaje de Aceptación de la Modificación de Contexto PDP, o tras la finalización del procedimiento de modificación RAB, el SGSN devuelve un mensaje de Respuesta de Actualización del Contexto PDP (TEID, QoS Negociada) al GGSN. Si el SGSN recibe un mensaje de Petición de Desactivación del Contexto PDP, tendrá que seguir el Procedimiento de Desactivación del Contexto PDP iniciado por la MS.
La Fig. 5, también presentada únicamente con fines ejemplares, muestra el procedimiento de modificación de contexto PDP iniciado por MS y se corresponde con la Fig. 70 de la Especificación Técnica anteriormente mencionada. La siguiente descripción de los pasos en la Fig. 5 también está contenida en la misma.
1) La MS envía un mensaje de Petición de Modificación de Contexto PDP (TI, QoS Negociada, TFT) al SGSN. O la QoS Solicitada, o TFT o ambos pueden incluirse. La QoS Solicitada indica el perfil QoS deseado, mientras que TFT indica el TFT que va a añadirse o modificarse o eliminarse del contexto PDP.
2) El SGSN puede restringir el perfil de QoS deseado debido a sus incapacidades, la carga actual, el perfil QoS actual, y el perfil QoS suscrito. El SGSN envía un mensaje de Petición de Actualización de Contexto PDP (TEID, NSAPI, QoS Negociada, TFT) al GGSN. Si la QoS Negociada y/o TFT recibido desde SGSN es incompatible con el contexto PDP que se está modificando (por ejemplo, si TFT contiene filtros de paquete inconsistentes), en este caso el GGSN rechaza la Petición de Actualización de Contexto PDP. Los perfiles QoS compatibles se configuran mediante el operador GGSN.
3) El GGSN puede además restringir la QoS Negociada debido a sus incapacidades y a la carga actual. El GGSN almacena la QoS Negociada, almacena, modifica o elimina TFT del contexto PDP tal y como se indica en TFT, y devuelve un mensaje de Respuesta de Actualización del Contexto PDP (TEID, QoS Negociada).
4) En UMTS, la modificación del portador al acceso de radio puede llevarse a cabo mediante el Procedimiento de Asignación RAB.
5) El SGSN selecciona la Prioridad de Radio y el Id de Flujo de Paquetes sobre la QoS Negociada, y puede enviar un mensaje de Petición de Modificación de Contexto PDP (TI, QoS Negociada, Prioridad de Radio, Id Flujo de Paquetes) a la MS.
NOTA: Si el SGSN no acepta la QoS Solicitada, en este caso los pasos 2 y 3 de este procedimiento se omiten y la QoS Negociada ya existente regresa a la MS en el paso 4.
A pesar de los numerosos detalles provistos en la Especificación Técnica anteriormente mencionada, no se han tratado muchas características asociadas con las redes móviles. Es decir, técnicas para proporcionar anuncios en llamadas originadas por móviles no se han incorporado aún a la especificación técnica anteriormente mencionada y es a estos detalles a los que la presente invención está dirigida.
Descripción de la invención
En la presente invención, la señalización intercambiada por la capa de aplicación en la MS se dispone de acuerdo con el procedimiento/mensajes que precisen llevarse a cabo por parte de los niveles de transporte en la MS y en la red con el fin de establecer las llamadas multimedia IP.
Cuando el nivel de aplicación en la MS envía un mensaje de inicio para establecer una llamada multimedia IP, antes o después de enviar dicho mensaje sobre una interfaz radiofónica, la MS lleva a cabo los procedimientos apropiados, dependiendo del tipo de acceso adoptado, para establecer los portadores apropiados sobre la interfaz radiofónica y en la red con el fin de satisfacer los requisitos de llamada especificados por el nivel de aplicación en el mensaje de inicio.
La técnica de la presente invención se aplica al caso de llamadas originadas por móviles, y consiste en que la MS lleva a cabo el nivel de transporte anteriormente mencionado antes o después de enviar el mensaje de establecimiento o antes de enviar un mensaje de confirmación o aceptación de llamada de vuelta a la parte llamada.
En la técnica de acuerdo con la presente invención, para una llamada originada por un móvil que pretende responderse mediante un anuncio, se informa a la MS de la dirección de transporte del nodo que realizará el anuncio y la MS en este momento inicia un procedimiento modificador del contexto PDP para establecer una Muestra de Flujo de Tráfico (TFT) de acuerdo con la Dirección de Transporte (TA) del nodo.
Breve descripción de los dibujos
Tanto lo ya mencionado como una mejor comprensión de la presente invención resultarán más claras y evidentes a partir de la siguiente descripción detallada de realizaciones ejemplares y de las reivindicaciones siempre y cuando se lean en relación con los dibujos acompañantes, formando todo ello parte de la descripción de la invención. A pesar de que todo lo anterior y la siguiente descripción escrita e ilustrada se centra en describir realizaciones ejemplares de la invención, debe entenderse claramente que se trata únicamente de un modo de ilustración y ejemplo y que la invención no se limita exclusivamente a ello. El alcance de la presente invención solamente se encuentra limitado por los términos de las reivindicaciones adjuntas.
Lo que sigue a continuación es una breve descripción de los dibujos, donde:
La Fig. 1 ilustra los pasos en un procedimiento de activación de contexto PDP.
La Fig. 2 ilustra los pasos en un procedimiento de activación de contexto secundario PDP.
Las Figs. 3-5 ilustran los pasos que de manera respectiva se dan en un procedimiento de modificación de contexto PDP iniciado por SGSN, iniciado por GGSN e iniciado por MS.
Las Figs. 6 y 7 también muestran con detalle los pasos que se dan en un procedimiento de establecimiento de llamada.
La Fig. 8 ilustra un ejemplo de los pasos que se dan en una técnica para proporcionar anuncios en llamadas originadas por móviles de acuerdo con la presente invención.
Modo más adecuado para realizar la invención
Antes de comenzar con una descripción detallada de la invención en cuestión, es importante la mención de lo siguiente en el orden adecuado. Cuando es apropiado, se emplean los mismos números referenciales y letras para designar componentes idénticos, correspondientes o similares en las diferentes figuras de los dibujos. Además, y se observa en la descripción detallada a continuación, se pueden dar tamaños/modelos/valores/rangos de los ejemplos, a pesar de que la presente invención no está limitada exclusivamente a ellos. Por último, los elementos bien conocidos puede que no se muestren dentro de las figuras de los dibujos con el fin de simplificar la ilustración y la descripción y para no confundir la invención.
Además de la Especificación Técnica anteriormente mencionada, la Especificación Técnica TS 23.228, Versión V1.5.0, presentada por 3GPP en marzo del 2001, define la descripción del servicio paso 2 para el Subsistema Multimedia (IM) IP, que incluye los elementos necesarios para soportar servicios de Multimedia (IM) IP en UMTS.
La Fig. 6, que corresponde con la Fig. 5.7 de la Especificación Técnica TS 23.228, ilustra con detalle los siguientes pasos que se dan en un procedimiento de establecimiento de llamada:
1.
UE (A) comienza un procedimiento de Iniciación de Sesión con UE (B) que incluye una propuesta SDS.
2.
El usuario en UE (B) es pre-alertado (opcional).
3.
Puede enviarse una indicación de pre-alarma hacia UE (A) (opcional).
4.
El usuario en UE (B) en este momento interactuará y expresará sus deseos con respecto a la sesión real.
5.
UE (B) genera SDP aceptado en base a las posiciones de terminal, a los perfiles de terminal configurados y, opcionalmente, en base a los deseos del usuario.
6.
El SDP aceptado se envía hacia UE (A) en la carga útil de una respuesta SIP fiable.
7.
Se lleva a cabo el procedimiento creativo de portador inicial.
Durante este paso de creación de portador, los recursos en la red de acceso de UE (A) y UE (B) se reservan junto con los procedimiento de contexto PDP. Los recursos del portador en las redes externas también pueden reservarse en este punto.
8.
La terminal en UE (B) comienza a sonar (opcional).
9.
La indicación de alerta se envía hacia UE (A) (opcional).
10.
El usuario en UE (B) puede interactuar y expresar sus deseos con respecto a la sesión real (opcional).
11.
UE (A) y UE (B) pueden llevar a cabo el procedimiento de modificación del portador en este punto si los portadores iniciales reservados en el paso 7 y los deseos del usuario en UE (B) son diferentes. Durante este paso de modificación de portadores, los recursos en la red de acceso de UE (A) y UE (B) pueden modificarse por medio de una modificación del contexto PDP, y la reserva de recursos en la red externa también puede modificarse.
12.
El procedimiento de inicio de sesión es reconocido o admitido.
Además, la Fig. 7 muestra los pasos que se dan en un procedimiento de establecimiento de llamada y corresponde con la Fig. 5.15 de la Sección 5.6.2 de la segunda Especificación Técnica citada. Los siguientes pasos también se describen en la misma.
1.
UE#1 envía la petición SIP INVITE, que contiene un SDP inicial, al P-CSCF predeterminado por medio de un mecanismo de descubrimiento CSCF. El SDP inicial puede representar uno o más medios para una sesión multimedia.
2.
P-CSCF recuerda (a partir del procedimiento de registro) el siguiente salto CSCF para este UE. En este caso envía INVITE al S-CNCF en la red base.
3.
CSCF valida el perfil del servicio, y lleva a cabo un control de servicio origen requerido para este abonado. Esto incluye una autorización del SDP requerido en base a la suscripción del usuario para los servicios multimedia.
4.
S-CSCF envía la petición, tal y como la especifican los procedimientos S-S.
5.
Las capacidades del flujo mediático del destino regresan a lo largo de la ruta de señal, en cuanto a los procedimientos S-S.
6.
S-CSCF envía el mensaje SDP a P-CSF.
7.
P-CSCF autoriza los recursos necesarios para esta sesión.
8.
P-CSCF envía el mensaje SDP al punto final que origina.
9.
UE decide el grupo final de corrientes mediáticas para esta sesión, y envía SDP Final al P-CSCF.
10.
P-CSCF envía este mensaje a S-CSCF.
11.
S-CSCF envía este mensaje al punto final de terminación, en cuanto al procedimiento S-S.
12.
Tras determinar la corriente mediática final en el paso #9, UE inicia los procedimientos de reserva para los recursos necesarios para esta sesión.
13.
Cuando la reserva de recursos se completa, UE envía el mensaje de "Reserva de Recursos Exitosa" al punto final de terminación, por medio de la ruta de señal establecida por el mensaje INVITE. El mensaje se envía en primer lugar a P-CSCF.
14.
P-CSCF envía este mensaje a S-CSCF.
15.
S-CSCF envía este mensaje al punto final de terminación, en cuanto al procedimiento S-S.
16.
El destino UE puede opcionalmente llevar a cabo una alerta. En este caso, da la señal oportuna a la parte de origen mediante un tono o timbre indicador que representa la respuesta provisional.
Este mensaje se envía a S-CSCF en cuanto al procedimiento S-S.
17.
S-CSCF envía este mensaje a P-CSCF.
18.
P-CSCF envía el mensaje con timbre a UE.
19.
UE indica al usuario origen que el destino está sonando.
20.
Cuando la parte destino contesta, el punto final de terminación envía una respuesta final SIP 200-OK, tal y como se especifica mediante los procedimientos de terminación y los procedimientos S-S, a S-CSCF.
21.
S-CSCF realiza cualquier control de servicio de origen requerido por parte de la finalización del inicio de sesión.
22.
S-CSCF pasa la respuesta 200-OK de vuelta a P-CSCF, siguiendo la ruta de la petición INVITE del paso (2) anterior.
23.
P-CSCF indica que los recursos reservados para esta sesión deberían emplearse en este momento.
24.
P-CSCF pasa la respuesta 200-OK de vuelta a UE.
25.
UE comienza el flujo o flujos de medios para esta sesión.
26.
UE responde a 200-OK con un mensaje de recepción ACK que se envía a P-CSCF.
27.
P-CSCF envía el mensaje final ACK a S-CSCF.
28.
S-CSCF envía el mensaje final ACK al punto final de terminación, en cuanto al procedimiento S-S. Sin embargo, en otras ocasiones es necesario que MS reciba un anuncio grabado desde la parte llamada en vez de conectar con la parte llamada para llevar a cabo una conversación. En tal circunstancias, el anuncio grabado sale desde un nodo en una dirección diferente a la de la parte llamada y la técnica de acuerdo con la presente invención facilita la iniciación del procedimiento de modificación de contexto PDP para establecer una Plantilla de Flujo de Tráfico (TFT) de acuerdo con la Dirección de Transporte (TA) del nodo.
En referencia a la Fig. 8, que ilustra un ejemplo de una técnica para proporcionar anuncios en llamadas originadas por móviles de acuerdo con la presente invención, en el paso #1 se envía un mensaje de establecimiento desde una MS una estación del mismo tipo.
Este mensaje de establecimiento es interceptado por la red que ha sido instruida para enviar un mensaje de anuncio en respuesta a un establecimiento de llamada a la parte llamada. La máquina que realizará el anuncio, referida en la figura del dibujo como CSCF Remoto/REP, en el paso #2, recibe el mensaje de establecimiento con un mensaje de conexión que incluye su dirección IP y un número de Puerto, que es, el Equipo Remoto TA, con el fin de permitir que la MS se conecte de manera adecuada con él.
Posteriormente, en los pasos #3, #4, #5, #6, y #7, la MS activa un contexto PDP secundario que incluye una TFT que permite que la máquina envíe tráfico a la MS. Es decir, TFT incluye el Equipo Remoto TA, esto es, su dirección IP y un número de Puerto).
En el paso #8, la MS reconoce la aceptación del contexto secundario PDP y en el paso #9, el Equipo Remoto realiza el anuncio a la MS.
Por lo tanto, de acuerdo con la presente invención, después de que una MS intente establecer una llamada con una parte llamada que desea responder con un anuncio, la máquina de Equipo Remoto diseñada por la parte llamada para realizar tal anuncio, proporciona su TA a la MS. La MS, a su vez, activa un contexto PDP secundario con una TFT del Equipo Remoto para permitir que la máquina de Equipo Remoto envíe su anuncio a la MS.
Esto concluye la descripción de las realizaciones ejemplares.
A pesar de que la presente invención se ha descrito con referencia a una realización ilustrativa de la misma, debe entenderse que pueden concebirse numerosas modificaciones y realizaciones por parte de aquellos expertos en la técnica siempre y cuando correspondan con el alcance de los principios de esta invención. Más en particular, son posibles razonables variaciones y modificaciones en las partes de los componentes y/o disposiciones de la disposición que combina el objeto contenida en el alcance de las reivindicaciones adjuntas. Además de las variaciones y modificaciones en las partes componentes y/o disposiciones, usos alternativos resultarán obvios para aquellos expertos en la técnica.

Claims (9)

1. Un método para proporcionar un anuncio en una red de comunicaciones, comprendiendo el método lo siguiente:
-
establecer un primer contexto PDP, Protocolo de Datos de Paquete, para un primer elemento de red;
-
determinar que el anuncio va a realizarse en el primer elemento de red;
-
enviar, empleando dicho primer contexto PDP, una identidad de un segundo elemento de red que va a realizar el anuncio;
-
establecer un segundo contexto PDP, donde los parámetros de dicho segundo contexto PDP se establecen de acuerdo con la identidad transmitida; y
-
realizar el anuncio al primer elemento de red usando dicho contexto secundario PDP.
2. El método de la reivindicación 1, donde la identidad transmitida comprende una dirección IP, Protocolo de Internet.
3. El método de la reivindicación 1, donde la identidad transmitida comprende un número de puerto.
4. El método de la reivindicación 1, donde la identidad transmitida comprende una TA, Dirección de Transporte.
5. El método de la reivindicación 1, donde el primer elemento de red comprende una estación móvil, MS.
6. El método de la reivindicación 1, donde dichos parámetros comprenden información de filtro.
7. El método de la reivindicación 6, donde dicha información de filtro comprende una Plantilla de Flujo de Tráfico, TFT.
8. El método de la reivindicación 1, donde establecer dicho contexto secundario PDP comprende incluir una TA, Dirección de Transporte, en una TFT, Plantilla de Flujo de Tráfico.
9. Dispositivo de almacenamiento de programas leíbles por una máquina que está formado por un programa de instrucciones que instruyen una máquina para que lleve a cabo todos los pasos de un método de acuerdo con las reivindicaciones 1 a 8 cuando se ejecutan por dicha la máquina.
ES02714398T 2001-04-09 2002-04-09 Tecnica para proporcionar anuncios en llamadas originadas por moviles. Expired - Lifetime ES2302799T3 (es)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
ES2302799T3 true ES2302799T3 (es) 2008-08-01

Family

ID=25250475

Family Applications (1)

Application Number Title Priority Date Filing Date
ES02714398T Expired - Lifetime ES2302799T3 (es) 2001-04-09 2002-04-09 Tecnica para proporcionar anuncios en llamadas originadas por moviles.

Country Status (15)

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

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 (en) * 2001-04-11 2002-10-16 Alcatel Provision of subscriber QoS guarantees to roaming subscribers
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
AU2001272428B2 (en) * 2001-05-28 2007-01-04 Nokia Corporation 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 삼성전자주식회사 부호분할다중접속 이동통신시스템에서 패킷 데이터 전송방법
WO2003007544A2 (en) * 2001-07-10 2003-01-23 Telefonaktiebolaget Lm Ericsson (Publ) 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
AU2002308135A1 (en) * 2002-04-10 2003-10-20 Telefonaktiebolaget Lm Ericsson (Publ) Data preservation
KR101009819B1 (ko) * 2002-06-06 2011-01-19 톰슨 라이센싱 Ｗｌａｎ과 이동 통신 시스템 간의 상호 연동시하이브리드 결합을 위한 논리 지원 노드인 ｗｌａｎ
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
JP4426451B2 (ja) 2002-09-24 2010-03-03 オレンジュ・エスエー 電気通信
KR100554799B1 (ko) 2002-11-19 2006-02-22 엘지전자 주식회사 Ｇｓｍ이동통신 시스템의 전송 데이타 암호화 및 암호화 해제 방법
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
DE60321607D1 (de) 2003-12-05 2008-07-24 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
US7620057B1 (en) * 2004-10-19 2009-11-17 Broadcom Corporation Cache line replacement with zero latency
US8139739B2 (en) * 2005-05-06 2012-03-20 At&T Mobility Ii Llc Enhanced alerting system
EP1917817B1 (en) * 2005-08-22 2013-05-08 Telefonaktiebolaget LM Ericsson (publ) A method and arrangement for establishing a communication session for multimedia
WO2007029593A1 (ja) * 2005-09-07 2007-03-15 Matsushita Electric Industrial Co., Ltd. 携帯電話装置およびその制御方法
RU2407193C2 (ru) * 2006-05-03 2010-12-20 Интердиджитал Текнолоджи Корпорейшн Способ беспроводной связи и система для активации множественных однонаправленных каналов услуг посредством эффективных процедур активации контекста протокола пакетных данных
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
US20080235185A1 (en) * 2007-03-21 2008-09-25 Motorola, Inc. Communication system and method of accessing therefor
US20080235778A1 (en) * 2007-03-21 2008-09-25 Motorola, Inc. Communication network, an access network element and a method of operation therefor
US8077685B2 (en) * 2007-04-24 2011-12-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for avoiding hanging PDP contexts
US8438257B2 (en) * 2007-07-10 2013-05-07 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
JPH11163947A (ja) 1997-09-22 1999-06-18 Toshiba Corp ゲートウェイ装置、無線端末装置、ルータ装置および通信ネットワークのゲートウェイ制御方法
JP3949288B2 (ja) 1997-09-22 2007-07-25 株式会社東芝 ゲートウェイ装置及び無線端末装置
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
WO2000078328A2 (de) * 1999-06-17 2000-12-28 Armin Johannes Becker VERWENDUNG VON WACHSTUMSHORMON (hGH) ZUR THERAPIE SEXUELLER FUNKTIONSSTÖRUNGEN
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
EP1397750A4 (en) 2005-09-14
WO2002082781A2 (en) 2002-10-17
US20020147824A1 (en) 2002-10-10
MXPA03009181A (es) 2004-02-17
RU2282312C2 (ru) 2006-08-20
BR0208709A (pt) 2004-07-20
AU2002246300B2 (en) 2007-08-09
CA2443690A1 (en) 2002-10-17
ATE387669T1 (de) 2008-03-15
EP1397750A2 (en) 2004-03-17
WO2002082781B1 (en) 2004-02-12
JP2004534438A (ja) 2004-11-11
RU2003132473A (ru) 2005-05-27
CN1502078A (zh) 2004-06-02
DE60225278D1 (de) 2008-04-10
ZA200307615B (en) 2004-06-03
WO2002082781A3 (en) 2003-12-24
KR100879811B1 (ko) 2009-01-22
EP1397750B1 (en) 2008-02-27
DE60225278T2 (de) 2009-03-26
CN1278250C (zh) 2006-10-04
JP3901095B2 (ja) 2007-04-04
KR20030085102A (ko) 2003-11-01
US7054945B2 (en) 2006-05-30

Similar Documents

Publication Publication Date Title
ES2302799T3 (es) Tecnica para proporcionar anuncios en llamadas originadas por moviles.
ES2231471T3 (es) Tecnica para establecimiento de llamadas en una red movil con protocolo internet.
JP7208411B2 (ja) データ伝送の保障方法及び通信機器
ES2288519T3 (es) Monitorizacion del estado de una conexion con un terminal de usuario en un sistema de telecomunicaciones.
ES2360110T3 (es) Método y dispositivos para instalar filtros de paquetes en una transmisión de datos.
ES2327096T3 (es) Un sistema y un metodo para comunicar capacidades de funcionamiento en una red telecomunicaciones.
ES2584455T3 (es) Sistema, aparato y método para establecer comunicaciones de conmutación de circuitos mediante señalización de red de conmutación de paquetes
AU2002246300A1 (en) Technique for providing announcements in mobile-originated calls
US7406057B2 (en) Method for handling of messages between a terminal and a data network
ES2333801T3 (es) Sistema de telecomunicaciones.
ES2445753T3 (es) Métodos de establecimiento de la existencia de condiciones previas de calidad de servicio para el establecimiento de una sesión de SIP
ES2313963T3 (es) Red de control de llamada, servidor de control de acceso y metodo de control de llamada.
US20040127237A1 (en) Connection establishment for PDP contexts
ES2262356T3 (es) Metodo y sistema de encaminamiento de llamadas en funcion de la posicion de la persona que realiza la llamada en una red ip movil.
BRPI0608525B1 (pt) Método e aparelho para iniciar uma troca de serviço no sistema sem fio
MXPA06006328A (es) Metodos y aparatos para roaming de cdms2000/gprs.
ES2368716T3 (es) Método para distribución de capacidad de smm.
MXPA02007213A (es) Metodo y aparato para optimizacion de canal durante requisiciones de sesion de protocolo de punto a punto (ppp).
US20070249357A1 (en) Method for Switching Between Two Telephone Services
US8004972B2 (en) Quality of service in communication systems
ES2289586T3 (es) Metodo y dispositivo para servicio pulsar para hablar.
ES2340607T3 (es) Procedimiento y dispositivo para la activacion de un contexto de un protocolo de paquetes de datos en el establecimiento de una conexion de paquetes de datos en una red de comunicaciones.
US8295269B1 (en) Technique for informing network of voice traffic
WO2022027448A1 (en) Nr sidelink relay communication method and apparatus
ES2972345T3 (es) Procedimiento para agrupar y priorizar sesiones de PDU diferentes en un sistema de telecomunicaciones y sistema del mismo.