ES2302799T3

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

Info

Publication number: ES2302799T3
Application number: ES02714398T
Authority: ES
Inventors: Tuija Hurtta; Stefano Faccin; Nedko Ivanov; Bertenyl Balazs
Original assignee: Spyder Navigations LLC
Current assignee: Intellectual Ventures I LLC
Priority date: 2001-04-09
Filing date: 2002-04-09
Publication date: 2008-08-01
Anticipated expiration: 2022-04-09
Also published as: EP1397750A2; AU2002246300B2; RU2003132473A; BR0208709A; WO2002082781A3; US7054945B2; CN1502078A; RU2282312C2; EP1397750A4; JP3901095B2; ZA200307615B; DE60225278T2; EP1397750B1; CA2443690A1; KR20030085102A; ATE387669T1; US20020147824A1; CN1278250C; JP2004534438A; WO2002082781A2

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.

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).

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

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.