PROCEDIMIENTO DE GESTIÓN MENSAJES DE RED ENTRE OPERADORES DE TELEFONÍA MÓVIL.

Procedimiento de gestión mensajes de red entre operadores de telefonía móvil.

Se describe un procedimiento de gestión mensajes de red entre al menos dos operadores de telefonía móvil, que permite mediante la implementación de un habilitador (ENABLER) en un operador receptor a la escucha de mensajes entrantes provenientes de un operador emisor encargado de manipular dichos mensajes de red mediante manipulación de protocolo SIP para realizar una serie de transacciones dependientes del tipo respuestas y peticiones, haciendo innecesario el uso de servidores de presencia.

PROCEDIMIENTO DE GESTIÓN MENSAJES DE RED ENTRE OPERADORES DE TELEFONÍA MÓVIL

CAMPO DE LA INVENCIÓN

La invención se refiere a comunicación, y más específicamente a un sistema de comunicación inalámbrica.

Más concretamente el objeto de la invención se base en un método que permite traducir mensajes de red entre operadores evitando el uso de servidores de presencia.

ANTECEDENTES

La iniciativa RCS (Rich Communication Suite (colección de herramientas de comunicación enriquecida) es una GSMA (especificación que permite diferentes tipos de comunicaciones (características) entre usuarios en su agenda de direcciones. Podemos resumir estas características, que son Presencia (usuario disponible, no disponible, en una llamada, ...) , Mensajería instantánea, Compartición de vídeo y Transferencia de archivos. Todas basadas en IMS (Subsistema multimedia de IP) usando SIP (Protocolo de inicio de sesión) .

En la especificación RCS hay dos mecanismos para descubrir las capacidades de otros usuarios (qué características que están disponibles para compartirlas con ellos) . A veces un usuario, debido a falta de ancho de banda, cámara, memoria o que está usando otro servicio, no puede compartir algunas características RCS con otros usuarios.

Mecanismo entre iguales: durante una llamada de voz CS (con circuitos conmutados) un usuario puede enviar un mensaje de OPTIONS al otro usuario de la llamada para consultar sus capacidades en tiempo real. Cuando las OPTIONS llegan al otro usuario, este responderá con un mensaje 200OK que contiene sus capacidades. Por ejemplo, ahora el usuario A sabrá si el usuario B puede soportar una sesión de vídeo y, por lo tanto, empezarla o no.

Mecanismo de Servidor de presencia: cuando se añade un nuevo contacto a su agenda de direcciones (lista de recursos) se envía un SUBSCRIBE anónima al nuevo usuario. Este SUBSCRIBE llegará al Servidor de presencia de la red del otro usuario y basándose en las reglas de presencia de este usuario (si permite este tipo de procedimiento) el Servidor de presencia responderá a este SUBSCRIBE con un NOTIFY que informa de las capacidades de la RCS del usuario al remitente del SUBSCRIBE.

El problema radica en el Servidor de presencia. La presencia es un servicio caro debido al hardware, las licencias y la infraestructura de red. Así que parece deseable ofrecer un servicio compatible con RCS basado en el estándar evitando el servicio de presencia. De esta manera, los operadores pueden evitar la necesidad de Servidores de presencia y nodos de Servidores XDM (Gestión de documentos XML) en la arquitectura del servicio.

DESCRIPCIÓN DE LA INVENCIÓN

El objeto de la invención propone una solución al problema mencionado anteriormente, , haciendo innecesario el uso de servidores de presencia, por medio de la implementación de un habilitador (ENABLER) que traduce los mensajes de red tipo SUBSCRIBE enviados por otros operadores a la RCS local en un mensajes de red tipo OPTIONS. El usuario envía una respuesta 200OK a dichos mensajes de red tipo OPTIONS que luego se transforma en mensajes de red tipo NOTIFY que se envía como respuesta a los SUBSCRIBE del usuario del otro operador.

Por lo tanto, el operador puede implementar un servicio compatible con RCS que ofrece la mayoría de las características de RCS (excepto presencia) y que necesita menos recursos y complejidad ya que no hay necesidad de un Servidor de presencia ni un Servidor XDM, ya que la presencia no es un servicio crítico para los usuarios residenciales y aumenta en gran medida la complejidad del servicio RCS.

El método objeto de la invención abarca distintas realizaciones, para poder dar cobertura a las distintas posibilidades que se pueden dar en este tipo de situaciones.

En un primer tipo de realización, el método permite adaptar un operador RCS, es decir que cumple los requisitos RCS, envía un mensaje de red de subscripción (SUBSCRIBE) a un operador no-RCS OPRITONS) . El SUBSCRIBE llega al habilitador (ENABLER) de la siguiente manera, el usuario A (USER A) perteneciente al operador A (OPERATOR A) que es un operador

que cumple con los requisitos especificados en la RCS (RCS Compliant) añade como un contacto RCS un usuario B (USER B) de un operador B (OPERATOR B) que no cumple con los requisitos especificados en la RCS, no tiene servidor de presencia (Presence Server) ni XDMS pero tiene un habilitador de capacidad de descubrimiento de RCS (RCS Capability Discover y Enabler) .

El usuario A, más concretamente el equipo (UE del inglés “User Equipment”) envía un mensaje de red tipo SUBSCRIBE anónimo al Tel-URI del Usuario B (USER B) , mediante mecanismos estándar DNS el citado SUBSCRIBE llega a la red del operador B (OPERATOR B) , más concretamente al punto de entrada de la misma: el NNI-SBC.

La session iniciada por el SUBCRIBE llega al habilitador alojado en el (IMS Core) del operador B (OPERATOR B) , dado que el habilitador se encuentra en el en el interfaz de señalización de dicho operador y a la escucha de solicitudes de inicio de sesión SIP.

En este punto el operador B (OPERATOR B) opera de dos maneras

para enrutar la solicitud SUBSCRIBE del NNI-SBC hacia el hbailitador (ENABLER) :

-Directamante el NNI-SBC se encuentra configurado con una ruta por defecto que enrute todos los SUBSCRIBES anónimos procedentes del operador A al habilitador (ENABLER) .

-Basado en un iFC terminante para mensajes SUBCRIBE para todos los usuarios usando el habilitador (ENABLER) . Esto implica, que el habilitador (ENABLER) se enruta en un procedimiento estándar hacia el I-CSCF del operado B (OPERATOR B) y desde aquí al S-CSCFd el usuario B (USER B) . El perfil de servicios del usuario B ( USER B) en el HSS tiene un capacidad de lanzar procesos terminantes (iFC) para SUBSCRIBES y enruta todas las transacciones al puerto de señalización del habilitador (ENABLER) .

Tal y como se ha indicado anteriormente el habilitador (ENABLER) se encuentra realizando una escucha permanente del puerto y/o del interfaz de señalización a la espera de llegada de peticiones. Solo acepta peticiones y respuestas que provienen o vienen generadas en respuesta de mensajes de red tipo SUBSCRIBE y tipo OPTIONS, comportándose como un Back to back User Agent (B2BUA) .

Cuando el habilitador (ENABLER) escucha o detecta un mensaje en el interfaz de comunicación determina si se trata de un mensaje de red tipo SUBSCRIBE; si es así el habilitador (ENABLER) chequea la sintaxis del SUBSCRIBE basada en RFC3261, si determina que no es correcta genera y envía un mensaje “400 Bad Request” en respuesta a dicho mensaje, si es correcto genera y envía un mensaje “200 OK” en respuesta y almacena todo los parámetros relacionados con la sesión.

A continuación, el habilitador (ENABLER) genera un nevo diálogo OPTIONS, en adelante OPTIONS, S-CSCF del Operador B (el dominio o rango de IPs del S-CSCF está codificador en habilitador (ENABLER) de tal forma que es capaz de saber a qué dirección enviar la solicitud/es OPTIONS) .

El citado OPTIONS tiene el mismo origen y destino que el mensaje original SUBSCRIBE, esto implica que tiene la misma URI de petición, el mismo encabezamiento de destino (To header) y el mismo encabezamiento de origen (from header) .

El hablitador (ENABLER) añade su puerto de dirección IP The Enabler (IP:port) en los encabezamientos del contacto (Contact) y ruta (Via) , asegurando así la recepción de respuestas al OPTIONS, y envía la transacción al S-CSCF que se encuentra indicado en el encabezamiento de la ruta SIP (SIP Route header) .

Entonces se procede a esperar una respuesta a dicha solicitud de OPTIONS para continuar con esta transacción..

Si la respuesta a este nuevo diálogo OPTIONS se excede del tiempo de espera o es diferente de una respuesta “480 Calling User Not Registered” o “200 OK” se procederá al borrado de los diálogos SUBSCRIBE y el OPTIONS de la memoria dado que no se hace necesaria una respuesta en este caso (el “USUARIO/USER B” de destino se considera como un usuario no-RCS “non-RCS USER”) .

En el caso en el que el usuario recibe una respuesta que comprende un “480 Calling User Not Registered” o “200 OK, entonces se procede al borrado del diálogo OPTIONS de la memoria.

Si se da el caso de una respuesta “480 Calling User Not Registered”, esto implica que el usuario es un usuario RCS (“RCS USER”) del operador B, pero se encuentra inactivo en ese momento por lo que la respuesta tipo “480…” no contiene información sobre capacidades.

Si el usuario es un usuario RCS y... [Seguir leyendo]

1. Procedimiento de gestión mensajes de red entre al menos dos operadores de telefonía móvil caracterizado porque comprende:

-implementar en al menos uno de los operadores de red, un habilitador (ENABLER) que comprende al menos un interfaz de señalización encargado de permanecer a la escucha de mensajes entrantes en el operador en el que se encuentra implementado dicho habilitador (ENABLER) ,

-recibir mensajes de red entrantes en dicho operador en el cual se encuentra implementado habilitador (ENABLER) ,

-realizar una primera traducción de mensajes de red de dichos mensajes entrantes mediante manipulaciones del protocolo SIP haciendo uso de habilitador (ENABLER) ,

-enviar unos mensajes de red traducidos resultado del paso anterior desde el operador en el cual se encuentra implementado habilitador (ENABLER) hacia un operador generador del mensaje entrante,

-generar un primer mensaje de respuesta de recepción de mensaje entrante al operador generador del mensaje entrante donde dicha respuesta de recepción comprende al menos una respuesta SIP,

-enviar dicho primer mensaje de respuesta de recepción al operador generador del mensaje entrante desde el habilitador (ENABLER) manteniendo en el encabezamiento de dicho mensaje de respuesta de recepción el origen y destino, cambiando el tipo de mensaje mediante modificaciones de protocolo SIP,

-recibir en el operador generador del mensaje entrante primer mensaje de respuesta de recepción,

-enviar desde el operador generador un segundo mensaje de respuesta dependiente del primer mensaje de respuesta de recepción,

- recibir el segundo mensaje de respuesta en el operador en el cual se encuentra implementado el habilitador (ENABLER) a través de dicho habilitador (ENABLER) ,

-realizar una segunda traducción de mensajes de red del segundo mensaje de respuesta en el habilitador (ENABLER) mediante técnicas de manipulación de protocolo SIP, y

- hacer llegar al operador en el cual se encuentra alojado el habilitador (ENABLER) un mensaje traducción resultante del paso anterior. 5

2. Procedimiento según reivindicación 1 caracterizado porque la primera traducción de mensajes de red comprende convertir mensajes de red tipo SUBSCRIBE en mensajes de red tipo OPTIONS.

1.

3. Procedimiento según reivindicación 1 caracterizado porque la primera traducción de mensajes de red comprende convertir mensajes de red tipo OPTIONS en mensajes de red tipo SUBSCRIBE.

4. Procedimiento según reivindicación 2 caracterizado porque la 15 segunda traducción de mensajes de red comprende convertir unos mensajes de respuesta 2XX o 4XX a un mensaje de red NOTIFY

5. Procedimiento según reivindicación 3 caracterizado porque comprende adicionalmente generar un mensaje de red tipo NOTIFY en 20 respuesta al SUBSCRIBE convertido.

6. Procedimiento según reivindicación 5 caracterizado porque comprende realizar una tercera traducción mediante modificaciones de protocolo SIP del mensaje de red tipo NOTIFY a mensajes de red tipo 2XX.

2.

7. Procedimiento según reivindicaciones 4 y 6 caracterizado porque los mensajes de red tipo 2XX son de tipo 200 OK.

8. Procedimiento según reivindicación 5 caracterizado porque el 30 mensaje NOTIFY comprende una señalización SIP.

9. Procedimiento según reivindicación 5 caracterizado porque el mensaje NOTIFY comprende adicionalmente un fichero XML.