ES2597178T3

ES2597178T3 - Métodos y sistemas de comunicación IP en tiempo real avanzado en un terminal móvil

Info

Publication number: ES2597178T3
Application number: ES13167465.7T
Authority: ES
Inventors: David Lindsay; Steve Parrish; Christopher Garrido; Matthew Randmaa
Original assignee: D2 Technologies Inc; D2 Tech Inc
Current assignee: D2 Technologies Inc; D2 Tech Inc
Priority date: 2012-05-11
Filing date: 2013-05-13
Publication date: 2017-01-16
Anticipated expiration: 2033-05-13
Also published as: US9107049B2; JP2014241593A; US20150271445A1; EP2663054A3; EP2663054A2; JP2016028509A; JP2013240053A; EP2663054B1; US20130301529A1

Abstract

Un método para redirigir el tráfico del paquete Protocolo de Iniciación de Sesión en un terminal móvil (300, 400, 500, 600) a diferentes interfaces de red (315, 415, 515, 615) usando una única conexión registrada de Protocolo de Iniciación de Sesión, comprendiendo el terminal móvil (300, 400, 500, 600) un procesador de Evolución a Largo Plazo (360, 460, 560, 660) y un procesador de aplicación (310, 410, 510, 610), comprendiendo el procesador de Evolución a Largo Plazo (360, 460, 560, 660) un módulo de Protocolo de Iniciación de Sesión (388, 488, 588, 688) y un módulo redirector de paquete de red (395, 495, 595, 695), estando posicionado el módulo redirector de paquete de red (395, 495, 595, 695) entre el módulo de Protocolo de Iniciación de Sesión (388, 488, 588, 688) y las diferentes interfaces de red (315, 415, 515, 615) que se encuentran en el procesador de aplicación (310, 410, 510, 610), comprendiendo el método: - la provisión por el módulo redirector de paquete de red (395, 495, 959, 695) en el procesador de Evolución a Largo Plazo (360, 460, 560, 660) de una interfaz de red virtual; y - el reenvío por la interfaz de red virtual de todos los paquetes de Protocolo de Iniciación de Sesión normalmente transmitidos a través de un modem de Evolución a Largo Plazo del procesador de Evolución a Largo Plazo (360, 460, 560, 660) a una interfaz de red alternativa de diferentes interfaces de red (315, 415, 515, 615) del procesador de aplicación (310, 410, 510, 610) usando un mecanismo de comunicación de inter-procesador (350, 450, 550, 650) para enviar los paquetes de Protocolo de Iniciación de Sesión al procesador de aplicación (310, 410, 510, 610).

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Metodos y sistemas de comunicacion IP en tiempo real avanzado en un terminal movil Ambito de la invencion

(0001) Esta invencion hace referencia a una estructura y arquitectura para integrar funcionalidades de Servicios de Comunicacion Enriquecidos (en ingles: “Rich Communications Services”: RCS) en dispositivos de clientes, tales como, entre otros, telefonos inteligentes y tabletas, aprovechando los estandares RCS, lR.92, IR.94 y el Subsistema de Multimedia de Protocolo de Internet (en ingles: “Internet Protocol Multimedia Subsystem: IMS).

(0002) RCS es una iniciativa del Sistema Global para la Asociacion (GSMA) de Comunicaciones Moviles (GSMtm) para definir aplicaciones y servicios moviles proporcionando experiencias de comunicacion interoperables, convergentes, ricas, incluyendo voz, video, mensajeria, presencia, capacidades, contenidos compartidos y otras formas de comunicacion, mientras que se apoya la funcionalidad heredada, tales como voz y Servicio de SMS (en ingles: “Short Message Service”).

(0003) El Subsistema Multimedia IP o IMS es una arquitectura estandarizada de Interconexion de Proxima Generacion (en ingles: “Next Generation Networking”: NGN) para operadores de telecomunicaciones que desean proporcionar servicios moviles y servicios fijos de multimedia. Se usa la implementacion de Voz por IP (en ingles: “Voice-over-IP”: VoIP) basado en una implementacion estandarizada del Proyecto de Asociacion de 3a Generacion (“3rd Generation Partnership Project”: 3GPP) de Protocolo de Iniciacion de Sesion (en ingles: “Session Initation Protocol”: SIP), y funciona a traves del Protocolo de Internet (IP) estandar. Se da soporte a sistemas de telefonos existentes, tanto de bolsillo como conmutados).

(0004) La Asociacion GSM (en ingles: “GSM Association”: GSMA) ha definido el estandar industrial, IR.92, “IMS Perfil para Voz y SMS”, e IR.94 para anadir video.

Antecedentes de la invencion

(0005) El nucleo de un terminal de movil tipico (telefono, dispositivo) incluye un modem (Evolucion a Largo Plazo, en ingles: “Long Term Evolution”: LTE; Tercera Generacion, en ingles: “Third Generation”: (3G); o una combinacion de ambos LTE y 3G) y un procesador de la aplicacion. Un modem 3G incluye un modem de Sistema Global para Comunicaciones Moviles (GSMtm) o un modem de Codigo de Division de Acceso Multiple (en ingles: “Code Division Multiple Access”: CDMA). El control del usuario del terminal movil se proporciona por un software que funciona en el procesador de la aplicacion. El control del modem por el software en el procesador de la aplicacion se realiza tradicionalmente a traves de la secuencia de ordenes “AT”. Por ejemplo, para marcar el numero de telefono: 1-805555-1212, una aplicacion envia al modem la secuencia: “ATD 1805551212;”, la cual ordena al modem que inicie una llamada conmutada de circuito (Sistema Global para Comunicaciones Moviles (GSMtm) o Codigo de Division de Acceso Multiple (CDMA)).

(0006) Por favor, hagase referencia a la Fig. 1, que ilustra la arquitectura tipica de software en el procesador de la aplicacion (110) dentro de un terminal movil (100). La arquitectura del software ejecutada por el procesador de la aplicacion (110) puede incluir un Marcador Telefonico (120), una aplicacion (115) de Servicio de Mensaje Corto (SMS), un Gestor de Telefonia (130), un Gestor de SMS (125), un Nivel de Intefaz de Radio (en ingles: “Radio Interface Layer”: RIL) (101), y un controlador de modem (104) para hacer funcionar el modem (160).

(0007) Como ejemplo, cuando el usuario inicia una llamada o envia un SMS a traves del Marcador Telefonico (120) o del programa de la aplicacion de SMS (115), el Gestor de Telefonia (130) emite una orden al Nivel de Interfaz de Radio (101). El Nivel de Interfaz de Radio (101) convierte la orden en una orden AT. El RIL (101) puede pasar ese mensaje directamente al controlador de modem (104), o puede procesar la secuencia y proporcionar un mensaje diferente al controlador de modem (104), lo cual afectara a las funciones del modem (160) requeridas.

(0008) Un aparato de tecnologia de acceso multiple a la radio con movilidad “middleware” esta expuesto en el documento US 2007/0173283 A1. El aparato provee a un usuario de acceso a varias redes, tales como redes duplex de division de frecuencia y una red de area local inalambrica. La movilidad “middleware” hace referencia a una serie de funciones que posibilita una movilidad fluida dentro de redes heterogeneas y un apoyo para servicios multiples. Estas funciones pueden incluir la deteccion de redes, seleccion de redes, traspaso de inter-redes, conexion paralela, medida, acceso multiple QoS, seguridad y control de la potencia. La movilidad “middleware” no se encuentra en ningun nivel de protocolo especifico, sino que proporciona interaccion entre niveles. Las interacciones con las aplicaciones y los niveles de acceso se realizan a traves de un interfaz de programa de aplicacion.

Resumen de la invencion

(0009) La invencion esta definida en la reivindicacion 1a independiente. Configuraciones particulares estan expuestas es las reivindicaciones dependientes.

5

10

15

20

25

30

35

40

45

50

55

60

65

(0010) Se expone un metodo para hacer Voz a traves de llamadas de Protocolo de Internet (VoIP), llamadas de circuito heredadas y envfo/ recepcion de Servicio de Mensajes Cortos (SMS) mediante modem de Evolucion a Largo Plazo (LTE) o modem heredado, cambiando entre el LTE y el modem heredado en un terminal movil con ambos tipos de modems, y proporcionando todas las funciones de modem heredado usando aplicaciones existentes en el terminal movil. Un modulo de Protocolo de Iniciacion de Sesion (SIP) y un subsistema de Modulo de Estado de Control (CSM) hacen llamadas VoIP y envfan/reciben SMS a traves del Protocolo de Internet (SMSoIP) usando el modem LTE. Un modulo de Gestionador de Ordenes dirige los mensajes de voz y SMS desde un controlador de modem al SIP/CSM, y pasa todos los demas mensajes al modem heredado directamente. Basado en la polftica de radio establecida por una red o por el terminal movil, el modulo CSM determina si la llamada o el SMS se procesara por el modulo SIP y un Motor de Voz, como es requerido, o si se pasa al modem heredado. El modulo de Gestionador de Ordenes dirige los mensajes de voz y SMS desde el modem heredado al SIP/CSM, y todos los demas mensajes se pasan a traves del controlador de modem.

(0011) Se expone un metodo para la seleccion dinamica de radio en un terminal movil capaz de Servicios de Comunicacion Enriquecidos (RCS), Evolucion a Largo Plazo (LTE), modem heredado, y un interfaz de red alternativo. Un Gestor de Polftica de Radio (RPM) en un procesador LTE del terminal movil selecciona que radio o red se debe usar para cada funcion de comunicacion. El RPM es accesible para un operador de red o el terminal movil para establecer parametros o normas para hacer la determinacion.

(0012) Se expone un metodo para la pila del modulo de Protocolo de Iniciacion de Sesion (SIP) que funciona en un terminal movil para dirigirse a diferentes interfaces de red usando una conexion SIP unica autentificada. Un modulo Redirector de Puerto v (VPR), entre la pila SIP y un interfaz de red de Evolucion a Largo Plazo (LTE) o cualquier otro interfaz de red alternativo, provee un interfaz de red virtual que redirige todos los paquetes SIP segun una polftica de radio seleccionada por el terminal movil o por un operador de la correspondiente red de radio.

(0013) Se expone un metodo para redirigir el trafico del paquete de comunicacion del Protocolo de Internet (IP) a tiempo real en un terminal movil, que normalmente pasa a traves de un procesador LTE capacitado para la Evolucion a Largo Plazo a traves de Voz (VoLTE) a un interfaz de red alternativo sin que se duplique otra pila del modulo de Protocolo de Iniciacion de Sesion (SIP) ni el software relacionado fuera del procesador LTE. Un modulo Redirector de Puerto v (VPR) es insertado entre la pila SIP y el procesador LTE capacitado para VoLTE, que redirige todos los paquetes IP que normalmente son transmitidos a traves del modem LTE a un interfaz de red alternativo Daemon usando un mecanismo de comunicacion de inter-procesador. La interfaz de red alternativa Daemon interactua con un subsistema para mantener una conexion de red establecida por la interfaz de red alternativa Daemon, y transmite/ recibe el trafico del paquete IP mediante la conexion de red establecida por la interfaz de red alternativa Daemon. Todo el trafico del paquete SIP pasa a traves de una conexion SIP autentificada que es fundamentalmente igual que aquella usada para la transmision VoLTE.

(0014) Un metodo para redirigir los paquetes de video que son producidos y/o consumidos por un procesador de aplicacion que reproduce el codec de video funciona en una Evolucion a Largo Plazo (LTE).

(0015) Se expone el procesador LTE de un terminal movil cuando los paquetes de video deben ser transportados a traves del modem LTE. Un motor de video que se ejecuta en el procesador de la aplicacion envfa y recibe paquetes de video hacia/ desde el modem LTE. Un modulo Redirector de Puerto v (VPR) en el procesador LTE pide acceso a un canal de soporte de video LTE. Los paquetes de video son intercambiados entre el motor de video y el VPR usando un mecanismo de comunicacion de inter-procesador (IPC).

(0016) Se expone un metodo para sincronizar datos de video en un procesador de aplicacion de un terminal movil con datos de voz en un procesador de Evolucion a Largo Plazo (LTE) capacitado para el Protocolo de Internet a traves de Voz (VoIP) o Voz a traves de la Evolucion a Largo Plazo (VoLTE). La informacion de sincronizacion es intercambiada entre un motor de voz del procesador LTE y un motor de video del procesador de aplicacion usando un mecanismo de comunicacion de inter-procesador (IPC) entre el motor de video y el motor de voz, permitiendo al motor de video y al motor de voz que controlen sus respectivas velocidades de descodificacion, de manera que la voz y el video estan sincronizados.

(0017) Se expone un metodo para distribuir las funciones del Protocolo de Iniciacion de Sesion (SIP) a traves de diferentes procesadores mientras se mantiene una conexion SIP unica autentificada para un terminal movil. Un modulo Redirector de Puerto v (VPR) se proporciona en un procesador LTE del terminal movil. Un modulo SIP en el procesador LTE requiere al modulo VPR para que abra una conexion SIP al nucleo del Subsistema Multimedia del Protocolo de Internet (IMS). El modulo SIP registra al nucleo IMS usando la conexion del modulo VPR. El modulo VPR permite a otros modulos SIP en el terminal movil para que usen la conexion del modulo VPR al nucleo IMS.

(0018) Se expone un metodo para implementar las funciones de los Servicios de Comunicacion Enriquecidos (RCS) en un terminal movil con un procesador de Evolucion a Largo Plazo (LTE) usando una conexion de Protocolo de Internet (IP) establecida por un modulo de Protocolo de Iniciacion de Sesion (SIP) en el procesador LTE. Un acelerador del protocolo se implementa en un procesador de aplicacion del terminal movil que provee funciones SIP. Un modulo de Control/Estado (CSM) determina que funcion SIP debe ser reproducida por el modulo SIP en el procesador LTE y que funcion SIP debe ser implementada en el acelerador del protocolo, y envfa los datos RCS a traves del modulo Redirector del Puerto v en el procesador LTE al acelerador del protocolo o al modulo SIP en el

5

10

15

20

25

30

35

40

45

50

55

60

65

procesador LTE conforme a la determinacion. Todos los datos SIP son transmitidos a traves de una conexion unica autentificada establecida por el modulo SIP en el procesador LTE para el Protocolo de Internet a traves de Voz (VoIP) y el Servicio de Mensajes Cortos (SMS).

(0019) Se expone un metodo para evitar problemas de registro dual cuando las funciones de los Servicios de Comunicacion Enriquecidos (RCS) en un terminal movil que tienen un procesador de Evolucion a Largo Plazo (LTE) requiere funciones de protocolo del Protocolo de Iniciacion de Sesion (SIP) para que sean desarrolladas fuera de una pila SIP integrada en el procesador LTE. La pila SIP en el procesador LTe se registra con una red y establece una conexion SIP autentificada con un nucleo del Subsistema Multimedia del Protocolo de Internet (IMS) para el Protocolo de Internet a traves de Voz (VoIP) y el Servicio de Mensajes Cortos a traves del Protocolo de Internet (SMSoIP). Todos los paquetes del Protocolo de Internet (IP) para las funciones RCS subsecuentes que requieren funciones SIP que funcionan fuera del procesador LTE, y que estan destinadas para la transmision a traves del modem LTE, son enviadas a traves del Redirector de Puerto v (VPR) del procesador LTE que mantiene una conexion SIP unica autentificada con el nucleo IMS. Los paquetes entrantes desde el nucleo IMS, recibidos a traves del modem LTE por la conexion SIP autentificada, son enviados a traves del VPR a la pila SIP integrada en el procesador LTE o al acelerador de protocolo en un procesador de aplicacion del terminal movil cuando se requieren.

Breve descripcion de los dibujos

(0020) A continuacion, la invencion se ilustra ademas mediante ejemplo con referencia a los dibujos adjuntos.

Fig. 1 muestra una arquitectura de software de telefono movil tradicional

Fig. 2 es un diagrama de bloque funcional mostrando la incorporacion del VoIP al procesador LTE,

Fig. 3 es un diagrama de bloque funcional mostrando la incorporacion de la descarga del Wi-FiTM,

Fig. 4 es un diagrama de bloque funcional mostrando la incorporacion de la llamada de video con la descarga de Wi-FiTM,

Fig. 5 es un diagrama de bloque funcional mostrando la incorporacion de las funciones RCS, y

Fig. 6 es un diagrama de bloque funcional mostrando el reenvio del trafico desde el Acelerador de Protocolo para

la descarga Wi-FiTM

Descripcion detallada

(0021) Dentro del contexto de la presente invencion, el termino “modem heredado” se define como tecnologias tales como, entre otras, tecnologias de Segunda Generacion T2G), tecnologias de Tercera Generacion (3G), tecnologias de Sistema Global para Comunicaciones Moviles (GSMtm), tecnologias de Codigo de Division de Acceso Multiple (CDMA), y tecnologias de Codigo de Division de Acceso Multiple de Banda Ancha (W-CDMA). Los terminos “modem de Evolucion a Largo Plazo” y/ o “modem LTE” se definen como un modem configurado para ser capaz de una transmision de Evolucion a Largo Plazo (LTE) y/ o de tecnologias de recepcion. Los terminos “procesador de Evolucion a Largo Plazo” y/o “procesador LTE” se definen como una unidad de computacion que puede ser configurada como un modem LTE y puede ser configurado ademas para incluir un software de Evolucion la Largo Plazo a traves de Voz (VoLTE), y puede ser configurado ademas para incluir todas las versiones de las tecnologias de modem heredado, tales como, entre otras, tecnologias de Segunda Generacion (2G), tecnologias de Tercera Generacion (3G), tecnologias de Sistema Global para Comunicaciones Moviles (GSM™1), tecnologias de Codigo de Division de Acceso Multiple (CDMA), y tecnologias de Codigo de Division de Acceso Multiple de Banda Ancha (W- CDMA) y puede ser incorporada dentro del procesador LTE. Ademas, el termino “Interfaz de Red” se define como un punto de interconexion entre el terminal movil y una red privada o publica. Ademas, el termino “Interfaz de Red Alternativa” se define como un Interfaz de Red capaz de todas las versiones de tecnologias de transmision y/o recepcion, tales como, entre otras, tecnologias Wi-FiTM, DPRS (Servicios de Radio de Paquete DECT) y tecnologias Ethernet, y se ejecutan en el procesador de la aplicacion. Ademas, el termino “Interfaz de Red Alternativa Daemon” es un proceso que se ejecuta en el procesador de la aplicacion usada para controlar la conexion a Interfaces de Red Alternativas. A lo largo de este documento y en las reivindicaciones se presentan tecnologias particulares como ejemplos especificos de uso. Por ejemplo, una discusion de un Wi-FiTM Daemon deberia ser considerada una discusion de cualquiera y/o todas las versiones de un Interfaz de Red Alternativo Daemon, como se describe mas arriba, y una discusion de tecnologias de modem 3G deberia ser considerada una discusion de cualquiera y/o todas las versiones de un modem heredado, tambien como se describe mas arriba.

(0022) Este documento describe un sistema de software operacional para incorporar el Servicio de Mensajes Cortos (SMS) y Voz a traves de Evolucion a Largo Plazo (VoLTE), video, soporte de Servicios de Comunicacion Enriquecido (RCS), y descarga de Wi-FiTM a un terminal movil. Se comienza por incorporar funciones VoLTE a un procesador LTE. La seccion final (Fig. 6) describe un sistema completamente caracterizado que incluye voz y llamadas de video, SMS a traves del Protocolo de Internet (SM-SoIP), caracteristicas RCS (entre otras, mensajeria instantanea (IM), transferencia de archivos y compartir contenidos) y descarga de Wi-FiTM. A causa del enfoque modular aqui expuesto, es relativamente sencillo proveer subconjuntos de este sistema completamente

5

10

15

20

25

30

35

40

45

50

55

60

65

caracterizado usando el mismo diseno y bloques de software. Por ejemplo, la Fig. 2 es un producto para solo VoLTE, SMSoIP, y Continuidad de Llamada de Voz de Radio Unica (SRVCC), mientras que la Fig. 3 anade la descarga de Wi-FiTM y la Fig. 4 anade llamadas de video, etc.

Anadiendo VoIP (VoLTE) a la Arquitectura Heredada

(0023) Ha habido diferentes enfoques para anadir aplicaciones VoIP a terminales moviles. Un enfoque es crear una aplicacion completamente separada, junto a la pila de telefonia Android actual (ver Gestor de Telefonia (130) y Gestor de SMS (125), RIL (lOl) en la Fig. 1). Otro enfoque es hacer cambios a la pila de telefonia para permitir al Gestor de Telefonia (130) existente para determinar si la llamada debe ser una llamada VoIP (o una llamada de circuito heredada), y envia instrucciones a una pila de protocolo VoIP (o pila de voz heredada) para procesar la llamada.

(0024) Habida cuenta que todas las llamadas de voz a traves de un modem LTE son conducidas usando VoIP, es muy deseable para el procesador LTE presentar el mismo interfaz RIL que el telefono y la aplicacion SMS, de manera que las mismas ordenes para la llamada de voz heredada y SMS pueden ser aceptadas y tratadas, como se muestra en la Fig. 1.

(0025) Por ello, se expone una tecnica para posibilitar hacer llamadas VoIP, llamadas de circuito heredado y enviar/recibir SMS a traves del modem LTE o el modem heredado (2G, 3G), e intercambiar entre ellos (como se requiere por la especificacion IR.92) en un terminal movil tanto con modem LTE como con modem heredado, y proveer todas las funciones del modem heredado (tales como registro SIM, direccion SIM, etc.) usando aplicaciones existentes en el terminal movil para voz y SMS, y mantener todas las funciones de modem heredado. Ademas de anadir un subsistema de pila SIP y software de control para hacer llamadas VoIP y enviar/ recibir SMS provisto por el software SIP en el procesador LTE, un modulo de software de Gestionador de Ordenes dirige la voz y los mensajes SMS desde el controlador de modem al subsistema SIP/CSM, y pasa todos los demas mensajes directamente al modem heredado. El modulo CSM determinara, basado en la politica de radio por la red o el terminal movil, si la llamada o el SMS se procesara por la pila SIP y el Motor de Voz (si se requiere) o si se pasa a traves del modem heredado. El modulo de Gestionador de Ordenes tambien dirige voz y mensajes SMS desde el modem heredado a un subsistema SIP/CSM, y todos los demas mensajes se pasan a traves del controlador de modem.

(0026) Se expone el permitir que la politica de radio para voz, SMS y otras funciones de comunicacion, tales como IM, llamada de video, etc. (generalmente conocido como funciones RCS), sean seleccionadas en una base de funcion por el terminal movil o por el operador de red movil. Un modulo de software es accesible a la red o al terminal movil para establecer parametros o normas que determinan que interfaz de red usar para una llamada de voz o un mensaje SMS u otras funciones RCS.

(0027) Tambien se expone una tecnica para un terminal de movil que tiene una multitud de funciones de comunicacion (incluyendo voz, SMS, IM, llamada de video, compartir videos, compartir contenidos, localidad, libro de direcciones, sincronizacion, etc. generalmente conocido como RCS) para selectivamente conducir cada una de estas funciones en un interfaz de red a elegir (tales como LTE, 3G, Wi- FiTM, etc.), y para la seleccion de la interfaz de red para ser controlada dinamicamente por el operador de red movil o por el terminal movil para hacer esta seleccion. Se puede usar un modulo de software para proporcionar la seleccion de la interfaz de red y que sera examinada por TODAS las aplicaciones de comunicacion ejecutandose en el terminal movil para determinar que interfaz de red (por ejemplo, LTE, 3G, Wi- FiTM) usar para cada funcion de comunicacion (tales como voz, o IM, o video, etc.), y es accesible por el operador de red movil o el terminal movil para modificar la seleccion de la radio para diferentes funciones de comunicacion.

(0028) Para que el procesador LTE proporcione un interfaz RIL (101) (para la funcionalidad VoLTE) al telefono y a la aplicacion SMS, bloques adicionales VoLTE son anadidos bajo RIL (205) en el terminal movil (200) como se muestra en la Fig. 2. El procesador LTE (260) del terminal movil (200) comprende un Control de Modem Heredado y un modulo de Plano de Usuario (270), y los bloques VoLTE anadidos incluyendo un Gestionador de Ordenes (265), un modulo de Interfaz de Servicio de Internet (ISI) (282), un modulo de Motor de Voz (284), un modulo de Protocolo de Iniciacion de Sesion (SIP) (288), un Nivel de Abstraccion de Sistema Operativo (OSAL) (286), y un Modulo de Control/ Estado (CMS)(275). El CMS (275) incluye un Gestor de Politica de Radio (RPM) (280). La orden desde el RIL (mostrado en la Fig. 2 como 205) a los bloques VoLTE anadidos (265, 282, 284, 288, 286, 270 y 275) pueden ser ordenes AT estandares o un interfaz propio especificado por el proveedor del microprocesador del modem.

(0029) Con la arquitectura mostrada en la Fig. 2 para procesadores LTE que contienen un modem LTE y un modem heredado, las ordenes y los eventos son iguales respecto a si la llamada se ejecuta a traves de la red IP o a traves de la red de circuito heredada. Los componentes de software adicionales en esta arquitectura son:

- El Gestionador de Ordenes (265) - este modulo es responsable de las ordenes y eventos en curso. Todas

las llamadas de voz y ordenes SMS desde el RIL (a traves del controlador de modem) (205) se ejecutan en el modulo CSM (275). El resto de las ordenes se pasan a traves del modulo del modem heredado (270). Todas las llamadas sin voz, eventos sin SMS desde el controlador de modem (205) se pasen directamente al Gestionador de Ordenes (265) y despues al modem heredado (270). Los eventos de voz y SMS son interceptadas por el Gestionador de Ordenes (265) y se pasan al CSM (275).

- El Modulo de Ordenes/Estado (CSM) (275) es responsable de gestionar todas las llamadas de voz y sesiones de SMS.

- El Modulo ISI proporciona un interfaz independiente de protocolo para el modulo CSM (275) para comunicar con el modem heredado (270), SIP (288) y los modulos de Motor de Voz (284).

5 - El modulo SIP (288) ejecuta todas las operaciones SIP necesarias para gestionar llamadas y mensajeria

SMS.

- El Motor de Voz (284) esta controlado por el modulo CSM (275) usando ordenes ISI (282). El Motor de Voz (284) ejecuta todas las funciones de procesamiento de voz, incluidos pruebas de procesamiento de voz, codificacion/ descodificacion, cancelacion de eco acustico (AEC), bufer de datos, y compensacion de

10 perdida de paquetes (PLC). El Motor de Voz (284) tambien produce paquetes de Transporte a Tiempo Real

(RTP) para ser enviados a traves de la red, y procesa paquetes de voz RTP recibidos de la red.

- Modulo de Nivel de Adaptacion OS (OSAL) (286): El modulo OS-AL (286) se usa para operaciones especificas del sistema operativo abstracto para facilitar la portabilidad de componentes a diferentes sistemas operativos (por ejemplo, LINUX, RTOS, etc.). Los ejemplos incluyen la apertura y el cierre de

15 conectores de red.

- Gestor de Politica de Radio (RPM) (280): Para dar apoyo a la especificacion IR-92 (VoLTE) que permite que las llamadas de audio se intercambien entre VoIP y las tecnologias heredadas, el modulo CSM (275) tiene un submodulo RPM (280) que esta concebido para tomar decisiones inteligentemente sobre que interfaz de red usara para cada llamada o mensaje SMS. Para usos en los que la decision sobre la

20 seleccion de la interfaz de red se toma por el operador de red movil, el modulo RPM (280) cumplira con la

politica de radio establecida por el operador de red movil y la informacion del plano de control del modem LTE.

Ejemplo de uso: Aceptar llamada VoIP de entrada

25

(0030) Despues de que el terminal movil (200) se ha registrado por el proveedor de servicio, esta disponible para recibir llamadas de voz. Una vez que una llamada ha sido iniciada o recibida, el modulo RIL (205) consulta al controlador de modem en intervalos fijos sobre el estado de todas las llamadas desde la red. El modulo SIP (288) atiende a nuevas ordenes desde la red a traves del modulo OSAL (286).

30

(0031) Abajo se expone un listado con la secuencia de acciones que ocurren para una llamada VoIP de entrada.

1. Cuando hay una llamada de entrada, el modulo OSAL (286) recibe una invitacion para una nueva sesion VoIP.

2. El modulo SIP (288) recibe esta peticion y envia un mensaje al modulo CSM (275) a traves del modulo ISI (282).

31 . 3. El modulo CSM (275) crea un evento para el Gestionador de Ordenes (265) por la peticion de una nueva llamada,

que se pasa a la aplicacion del Marcador (120) a traves del controlador del modem (y RIL) (205).

4. El modulo CSM (275) ordena al modulo SIP (288) que acuse recibo de la peticion a la red.

5. La red envia un acuse de que el mensaje ha sido recibido.

6. Mientras que la llamada esta esperando a ser contestada, el modulo RIL (205) sigue consultando al controlador 40 de modem (205) a intervalos fijos sobre el estado de la llamada entrante.

7. El controlador de modem (205) envia la orden al Gestionador de Ordenes (265) que pasa la orden al modulo CSM (275).

8. El modulo CSM (275) responde con el estado actual de la llamada.

9. Cuando el usuario responde a la llamada, la aplicacion del Marcador (120) envia una orden al controlador de 45 modem (205) para responder a la llamada.

10. El controlador de modem (205) pasa la orden al Gestionador de Ordenes (265) que pasa la orden al modulo CSM (275).

11. El modulo CSM (275) ordena al modulo SIP (288) que acepte la llamada.

12. El modulo SIP (288) le comunica a la red que la llamada ha sido respondida.

50 13. La red responde con un acuse de que la llamada ha sido aceptada.

14. El modulo CSM (275) ordena al Motor de Voz (284) que comience a transmitir audio entre las interfaces de audio y una conexion RTP en la interfaz IP a traves de modulo OSAL (286) a la parte que llama.

15. La llamada ahora esta activa (conectada).

16. El modulo CSM (275) sigue informando el estado al controlador de modem (205) en el siguiente intervalo de 55 consulta RIL (206).

Ejemplo de uso: Llamada VoIP saliente

(0032) Despues de que el terminal movil (200) ha sido registrado por el proveedor de servicio, esta disponible para 60 iniciar llamadas de voz. Abajo se expone un listado con la secuencia de acciones que ocurren para una llamada

VoIP saliente.

1. El usuario inicia una llamada en la aplicacion del Marcador (120). El controlador de modem (205) recibe una orden para iniciar una llamada.

65 2. El controlador de modem (205) pasa la orden al Gestionador de Ordenes (265) que pasa la orden al modulo CSM

(275).

3. El modulo CSM (275) pide al modulo RPM (280) que determine la interfaz de red adecuada a ser usada. En este caso, se selecciona LTE VoIP.

5

10

15

20

25

30

35

40

45

50

55

60

65

4. El modulo CSM (275) le dice al modulo SIP (288) que inicie la llamada.

5. La red responde con un mensaje “de intento”, que se pasa al modulo SIP (288) a traves del modulo OSAL (286).

6. El modulo SIP (288) notifica al modulo CSM (275) de un nuevo mensaje. El modulo CSM (275) responde enviando un mensaje al Gestionador de Ordenes (265) de que ha recibido el mensaje “de intento”.

7. El Gestionador de Ordenes (265) pasa el mensaje al controlador de modem (205).

8. La red envia un mensaje de “acuse”, que se pasa al modulo SIP (288) a traves del modulo OSAL (286).

9. El modulo SIP (288) pasa la informacion al modulo CSM (275).

10. A intervalos de consulta fijos, el controlador de modem (205) recibe la orden desde el RIL (205) para el estado de todas las llamadas.

11. El controlador de modem (205) envia la orden al Gestinador de Ordenes (265) que pasa la orden al modulo CSM (275).

12. El modulo CSM (275) responde con el estado actual de la llamada.

13. Cuando la parte remota responde, el modulo SIP (288) recibe un mensaje desde la red (a traves del modulo OSAL (286)) de que la parte remota ha “aceptado” (contestado).

14. El modulo SIP (288) envia el mensaje al modulo CSM (275).

15. El modulo CSM (275) ordena al Motor de Voz (284) que comience a transmitir audio entre las interfaces de audio y una conexion RTP en la interfaz IP a traves del modulo OSAL (286) a la parte llamada.

16. En el siguiente intervalo de consulta, una nueva peticion del estado de la llamada se pasa desde el controlador de modem (205) al Gestionador de Ordenes (265) al modulo CSM (275).

17. Esta vez, el modulo CSM (275) informa de que la llamada ha sido contestada. Este mensaje se pasa al Gestionador de Ordenes (265) y al controlador de modem (205).

18. La llamada ahora esta activa (conectada).

Ejemplo de uso: Llamada CS entrante

(0033) Cuando una red de conmutacion de circuito (CS) heredado esta disponible, el proveedor de servicio puede dirigir las llamadas entrantes a traves de la red CS heredado. Abajo se expone un listado de una secuencia de acciones que ocurren en la respuesta a una llamada CS entrante.

1. Un usuario remoto llama al terminal movil (200) a traves de la red CS heredado.

2. El modem heredado (270) recibe una orden desde la red.

3. El modem heredado (270) genera un evento asincrono de que una llamada entrante ha sido solicitada.

4. El Gestionador de Ordenes (265) pasa este evento al modulo CSM (275). El modulo CSM (275) es iniciado para gestionar la llamada.

5. El modulo CSM (275) genera un evento para el Gestionador de Ordenes (265) que pasa este evento al controlador de modem (205), y a la aplicacion del Marcador (120).

6. El controlador de modem (205) recibe ordenes preguntando por el estado actual de la llamada a intervalos fijos.

7. Las ordenes en el evento (6) se pasan al modulo CSM (275) usando el Gestionador de Ordenes (265).

8. Cuando el usuario responde a la llamada, el controlador de modem (205) recibe una orden para responder a la llamada. Esta orden se pasa al modulo CSM (275) a traves del Gestionador de Ordenes (265).

9. Habida cuenta que el modulo CSM (275) sabe que esta es una llamada de conmutacion de circuito (CS) heredado, el modulo CSM (275) envia la orden al modulo del modem heredado (270) (y subsecuentemente la red) a traves del Gestionador de Ordenes (265).

10. El modulo del modem heredado (270) responde con un evento de “llamada aceptada”.

11. El modulo CSM (275) recibe este evento desde el modulo del modem heredado (270) a traves del Gestionador de Ordenes (265).

12. El modulo CSM (275) pasa el evento de la “llamada aceptada” al controlador de modem (205) usando el Gestionador de Ordenes (265).

13. La llamada ahora esta activa.

14. La proxima vez, que el controlador de modem (205) es consultado sobre el estado de la llamada, recibira un informe desde el modulo CSM (275) de que la llamada esta activada.

Ejemplo de uso: Llamada CS saliente

(0034) Cuando una red CS heredado es usada, la llamada saliente se dirige al modulo del modem heredado (270). Abajo se expone un listado de una secuencia de acciones para hacer una llamada CS saliente.

1. Cuando un usuario inicia una llamada, el controlador de modem (205) recibe una orden para iniciar una llamada.

2. El controlador de modem (205) pasa la orden al Gestionador de Ordenes (265) que pasa la orden al modulo CSM (275).

3. El modulo CSM (275) solicita al modulo RPM (280) que determine la interfaz apropiada a ser usada. En este caso, se selecciona la interfaz de modem heredado.

4. El modulo CSM (275) le indica al modulo del modem heredado (270) que inicie una llamada.

5. En intervalos de consulta fijos, el controlador del modem (205) recibe una orden RIL (205) solicitando el estado de todas las llamadas.

6. El controlador de modem (205) envia la orden al Gestionador de Ordenes (265) que pasa la orden al modulo CSM (275).

5

10

15

20

25

30

35

40

45

50

55

60

65

7. El modulo CSM (275) solicita al modulo del modem heredado (270) el estado actual de la llamada enviando una orden al modulo del modem heredado (270) a traves del Gestionador de Ordenes (265).

8. El modulo del modem heredado (270) responde con el estado actual de la llamada, y esta informacion se manda al modulo CSM (275) a traves del Gestionador de Ordenes (265).

9. El modulo CSM (275) responde al controlador de modem (205) con el estado actual de la llamada a traves del Gestionador de Ordenes (265).

10. Despues de un numero de intervalos de consulta, la parte remota contesta.

11. En el siguiente intervalo de consulta, una nueva solicitud del estado de la llamada se pasa desde el controlador de modem (205) al Gestionador de Ordenes (265) y luego al modulo CSM (275).

12. El modulo CSM (275) solicita al modulo de modem heredado (270) el estado actual de la llamada enviando una orden a traves del Gestionador de Ordenes (265).

13. El modulo del modem heredado (270) responde con el estado actual de la llamada, que ha cambiado a “activa”. Este estado se envia al modulo CSM (275) a traves del Gestionador de Ordenes (265).

14. El modulo CSM (275) responde al controlador de modem (consulta RIL) (205) con el estado actual de la llamada (“activa”) a traves del Gestionador de Ordenes (265).

15. La llamada esta ahora activa.

Ejemplo de uso: Apoyo USSD

(0035) Los proveedores de servicio GSMtm utilizan un protocolo llamado Datos de Servicio Suplementario no Estructurado (en ingles: “Unstructured Supplementary Service Data” (USSD)) para proporcionar algunos servicios simples sin voz. Los modems LTE proporcionan servicios similares.

(0036) Abajo se expone un listado de la secuencia de acciones que dan apoyo al USSD a traves del GSMtm.

1. El usuario inicia una peticion de un servicio USSD (a traves de una aplicacion en el terminal movil (200)). Esto se hace marcando un codigo especial.

2. El controlador de modem (205) recibe esta peticion de marcado y lo pasa al Gestionador de Ordenes (265), el cual a su vez lo pasa al modulo CSM (275).

3. El modulo CSM (275) gestiona esta secuencia como una llamada CS saliente. El modulo CSM (275) solicita al modulo RPM (280) que determine la interfaz de red apropiada a ser usada. En este caso, se selecciona GSMTM.

4. El modulo CSM (275) pasa la orden de marcado al modulo del modem heredado (270) a traves del Gestionador de Ordenes (265).

5. El modulo del modem heredado (270) provee una respuesta que se pasa al modulo CSM (275) (a traves del Gestionador de Ordenes (265)), y hace llegar el codigo a la red.

6. El modulo CSM (275) pasa la respuesta de vuelta al controlador de modem (205) a traves del Gestionador de Ordenes (265).

7. Despues de que el proveedor de servicio ha procesado el codigo, una respuesta no solicitada seran enviada al modulo de modem heredado (270) a traves de la red.

8. El modulo de modem heredado (270) pasara la respuesta al Gestionador de Ordenes (265) que a su vez la pasa al controlador de modem (205).

(0037) La peticion de servicios USSD a traves del modem LTE (red) sigue una secuencia similar.

Adicion de descarca Wi-FiTM

(0038) Una de las caracteristicas que requieren algunos operadores de red movil (MNO) es que VoIP y SMSolP sean descargados a traves de Wi-FiTM. Esto reduce el trafico de red inalambrico en la red LTE. Un enfoque preferible a proporcionar esta caracteristica al terminal movil es anadir un redirector de mensaje y otros modulos de software al procesador LTE, como muestra la Fig. 3. A traves de esta manifestacion, la marca Wi-FiTM esta concebida para suponer un sistema de radio inalambrico certificado como Wi-FiTM conforme al “Wi-FiTM Alliance”, mas que para suponer la fuente de la tecnologia o certificacion.

(0039) Se expone una tecnica para redirigir la comunicacion IP a tiempo real (tales como VoIP o SMSolP o video a traves de IP) trafico de paquete IP en un terminal movil, que normalmente va a traves del modem LTE a la radio WiFi™ sin duplicar otra pila SIP y software relacionado fuera del procesador LTE (en el procesador de aplicacion del terminal movil). Un modulo de software (o funcion software) es insertado entre la pila SIP y el modem LTE, que redirige todos los paquetes IP que normalmente son transmitidos a traves del modem LTE, al Wi-FiTM Daemon usando un mecanismo de comunicacion de inter procesador (IPC). El Wi-FiTM Daemon interactuara con el subsistema Wi-FiTM para mantener la conexion con la red Wi-FiTM y transmitir dicho trafico IP a traves de la red de radio Wi-FiTM, usando la pila SIP incorporada en el procesador LTE, todo semejante trafico SIP pasara a traves de una conexion de red SIP autentificada similar a aquella de la transmision LTE.

(0040) El procesador LTE (360) del terminal movil (300) comprende un Control de Modem Heredado y un modulo de Plano de Usuario (370), un Gestionador de Ordenes (365), un modulo de Interfaz de Servicio de Internet (382), un modulo de Motor de Voz (384), un modulo de Protocolo de Iniciacion de Sesion (SIP) (388), un Nivel de Abstraccion del Sistema Operativo (OSAL) (386), y un Modulo de Control/ Estado (CSM) (375). El CSM (375) incluye un Gestor de Politica de Radio (RPM) (380). Para permitir al VoIP y al SMSoIP que sean descargados a traves de Wi-FiTM, el

5

10

15

20

25

30

35

40

45

50

55

60

65

procesador LTE (360) difiere del procesador LTE (260) en que el procesador LTE (360) ademas comprende un Redirector de Puerto v (VPR) (395) y un Dispositivo Modem de Puerto v (VPMD) (390). El terminal movil (300) ademas incluye el RIL y el Controlador de Modem (305), e incorpora un Interfaz Daemon de Red Alternativa (315) y un Dispositivo de Aplicacion de Puerto v (VPAD) (320) ejecutandose en el procesador de aplicacion. El Dispositivo de Modem de Puerto v (VPMD) (390) y el Dispositivo de Aplicacion de Puerto v (VPAD) (320) pueden considerarse funcionalmente juntos como un mecanismo de Comunicacion de Inter-procesador (IPC) (350).

(0041) Los nuevos modulos de software de procesador LTE (390, 395, 315 y 320) anadidos para proporcionar la descarga Wi-FiTM mostrados en la Fig. 3 son:

- Redirector de Puerto v (VPR) (395) es un modulo que dirige los paquetes de red al interfaz de red apropiado. Cada paquete SIP, rTp y RTCP se presenta al modulo VPR (395). Si se preve para un interfaz de red en el procesador LTE (360), se envia al modulo OSAL (386). Si se preve para Wi-FiTM (u otras interfaces accesibles por el procesador de aplicacion), se envia al modulo VPMD (390). El VPR (395) aparece como una conexion de red virtual del modulo SIP (388), de manera que dicho modulo SIP (388) no necesita estar informado sobre que interfaz de radio esta siendo usado.

- El Dispositivo de Modem de Puerto v (VPMD) (390). Este modulo provee servicios de comunicacion entre el modulo VPR (395) (en el procesador LTE) y el modulo VPAD (320) en el procesador de aplicacion (310).

(0042) Los nuevos modulos en el procesador de aplicacion (310) son:

- El controlador del Dispositivo de Aplicacion Puerto v (VPAD) (320) comunica con el modulo VPMD (390) en el procesador LTE (360).

- Wi-FiTM Daemon (315): Cuando un paquete se recibe por la interfaz Wi-FiTM, el Wi-FiTM Daemon escribe los datos al modulo VPAD (320). El modulo VPAD (320) pasa los datos al modulo VPMD (390). El modulo VPMD (390) pasa los datos al modulo VPR (395), el cual pasa entonces los datos al modulo SIP (388) o al Motor de Voz (384), dependiendo del tipo de datos recibidos. Similarmente, el Wi-FiTM Daemon espera los datos del modulo VpAD (320). Cualquier nuevo mensaje SIP o RTP del modulo VPAD (320) sera enviado a traves del Wi-FiTM tan pronto como llegan al Wi-FiTM Daemon (315).

Como funciona el Wi-FiTM Daemon

(0043) El Wi-FiTM Daemon gestiona la conexion de red Wi-FiTM en representacion de los modulos que se ejecutan en el procesador LTE (360). Cuando el modulo SIP (388) necesita usar un interfaz Wi-FiTM, el modulo SIP (388) solicita una conexion Wi-FiTM del modulo VPR (395). El modulo VPR (395) contacta con el Wi-FiTM Daemon (315) (a traves del mecanismo IPC VPMD (390) y VPAD (320)) para abrir una conexion de red. El modulo SIP (388) usa la conexion del modulo VPR (395) para registrarse con el nucleo del Subsistema Multimedia IP (IMS). Despues de que el registro ha sido completado exitosamente, el modulo SIP (388) puede usar la interfaz Wi-Fi™ para iniciar o recibir llamadas VoIP y mensajes SMSoIP. Cuando el Motor de Voz (384) necesita usar la interfaz Wi-Fi™ (por ejemplo, para paquetes RTP o RTCP), el Motor de Voz (384) solicita a la conexion Wi-FiTM del modulo VPR (395).

Ejemplo de uso: Llamada Wi-FiTM saliente

(0044) Antes de iniciar una llamada Wi-Fi™, el radio Wi-Fi™ tiene que recibir la radio usada por la llamada de voz. Al modulo CSM (375) se le dice que se registre con la radio Wi-Fi™ por un evento RPM. Despues del evento, el modulo CSM (375) se registra con el proveedor de servicio a traves del Wi-Fi™.

(0045) En este ejemplo, el evento RPM es activado cuando un punto de acceso Wi-Fi™ esta disponible, y alli no hay llamadas activas. Despues de que el terminal movi! (300) esta registrado con el proveedor de servicio, esta disponible para iniciar llamadas de voz a traves Wi-Fi™. Abajo se expone un listado de la secuencia de acciones para una llamada VoIP saliente.

1. Cuando el usuario inicia una llamada, el controlador de modem (305) recibe una orden para iniciar una llamada.

2. El controlador de modem (305) pasa la orden al Gestionador de Ordenes (365) que pasa la orden al modulo CSM (375).

3. El modulo CSM (375) solicita al modulo RPM (380) que determine la interfaz de red apropiada para ser usada. En este caso, se selecciona el Wi-Fi™ VoIP.

4. El modulo CSM (375) le dice al modulo SIP (388) (a traves del ISI (382)) que inicie la llamada a traves del Wi-Fi™.

5. El modulo SIP (388) crea una sesion SIP y pasa los paquetes al modulo VPR (395).

6. Habida cuenta que al modulo VPR (395) se le ha comunicado que la sesion SIP va a traves de Wi-Fi™, el modulo VPR (395) pasa el paquete al modulo VPMD (390).

7. El modulo VPMD (390) pasa los paquetes al modulo VPAD (320).

8. El Wi-Fi™ Daemon (315) atiende al modulo VPAD (320) para la actividad. Cuando un nuevo paquete esta disponible, se manda a traves del conector Wi-Fi™.

9. La red responde con un "mensaje de intento". Este mensajes pasa de vuelta al modulo SIP (388) a traves del WiFi™ Daemon (315)/ VPDA (320)/ VPMD (390)/ ruta VPR (395).

10. El modulo SIP (388) notifica al modulo CSM (375) del nuevo mensaje. El modulo CSM (375) responde enviando un mensaje al Gestionador de Ordenes (365) de que ha recibido el mensaje “de intento”.

5

10

15

20

25

30

35

40

45

50

55

60

65

11. El Gestionador de Ordenes (365) pasa el mensaje al controlador de modem (305).

12. La red envfa un acuse. Este mensaje se pasa al modulo SIP (388) a traves del Wi-FiTM Daemon (315) / VPAD (320) / VPMD (390) / ruta VPR (395).

13. El modulo SIP (388) pasa la informacion al modulo CSM (375).

14. A intervalos fijos de consulta, el controlador de modem (305) recibe una orden RIL (305) que pasa pide el estado de todas las llamadas.

15. El controlador de modem (305) envfa la solicitud al Gestionador de Ordenes (365) que pasa la orden al modulo CSM (375).

16. El modulo CSM (375) responde con el estado actual de la llamada.

17. Cuando la parte remota responde a la llamada, el modulo SIP (388) recibe un mensaje de la red (desde el WiFi™ Daemon (315) a traves del modulo VPR (395)) de que la parte remota ha contestado.

18. El modulo SIP (388) envfa el nuevo estado al modulo CSM (375).

19. El modulo CSM (375) ordena al Motor de Voz (384) que comience a transmitir audio entre las interfaces de audio y la conexion RTP en la interfaz Wi-FiTM a traves del VPR (395)/VPMD (390)/VPAD (320)/ruta Wi-FiTM Daemon (315).

20. En el proximo intervalo de consulta, en respuesta a una nueva solicitud sobre el estado de la llamada desde el controlador de modem (305) (a traves del Gestionador de Ordenes (365)), el modulo CSM (375) informa de que la llamada ha sido contestada.

21. Este mensaje de que la “llamada ha sido contestada” se pasa al Gestionador de Ordenes (365) y despues al controlador de modem (305).

22. La llamada ahora esta activa.

(0046) Un experto en la materia puede entender facilmente que la descripcion de arriba de descarga de una llamada saliente por Wi-FiTM puede ser modificada sencillamente a una descarga de una llamada saliente por otra forma de una Interfaz Daemon de Red Alternativa, e incluyendo cualquier cambio de hardware necesario.

Ejemplo de uso: Llamada Wi-FiTM entrante

(0047) Antes de recibir una llamada Wi-FiTM, el dispositivo tiene que ser registrado con el proveedor de servicio a traves de la radio Wi-FiTM. El ejemplo de uso anterior provee un escenario de como puede suceder esto. Se expone abajo un listado de la secuencia de acciones para una llamada VoIP entrante, suponiendo que el dispositivo esta registrado a traves de Wi-FiTM.

1. El Wi-Fi™ Daemon (315) atiende al conector de red apropiado para los mensajes.

2. El Wi-FiTM Daemon T315) recibe una invitacion para una nueva sesion VoIP cuando una peticion para una llamada llega a traves de Wi-FiTM.

3. El Wi-FiTM Daemon (315) envfa esta invitacion al modulo SIP (388) a traves del VPDA (320)/ VPMD (390)/ ruta

VPR (395).

4. Despues de que el modulo SIP (388) recibe esta peticion, envfa un mensaje al modulo CSM (375) (a traves del modulo ISI (382)).

5. El modulo CSM (375) envfa una peticion de una nueva llamada al controlador de modem (305) a traves del Gestionador de Ordenes (365).

6. El modulo CSM (375) ordena al modulo SIP (388) que acuse recibo de la solicitud a la red. Esta solicitud se dirige por el modulo VPR (395) al Wi-FiTM Daemon (315).

7. La red envfa un acuse de que el mensaje fue recibido. Este mensaje es recibido por el Wi-FiTM Daemon (315) y dirigido al modulo SIP (388) usando la ruta VPAD (320)/ VPMD (390)/ VPR (395).

8. A intervalos de consulta fijos, el controlador de modem (305) recibe una orden que solicita el estado de todas las llamadas.

9. El controlador de modem (305) envfa la orden al Gestionador de Ordenes (365) que pasa la orden al modulo CSM (375).

10. El modulo CSM (375) responde con el estado actual de la llamada.

11. Cuando el usuario contesta a la llamada, la aplicacion del Marcador (120) envfa una orden al controlador de modem (305) para responder la llamada.

12. El controlador de modem (305) pasa la orden al Gestionador de Ordenes (365) que pasa la orden al modulo

CSM (375).

13. El modulo CSM (375) ordena al modulo SIP (388) que acepte la llamada.

14. El modulo SIP (388) informa a la red de que la llamada ha sido contestada. Esto se hace enviando un mensaje al modulo VPR (395) que es dirigido al VPMD (390)/ VPAD (320) y finalmente a la red que usa el Wi-FiTM Daemon (315).

15. El modulo CSM (375) ordena al Motor de Voz (384) que empiece a transmitir audio a traves de las interfaces de audio y una conexion RTP en la interfaz Wi-FiTM a traves de la ruta VPR (395)/ VPMD (390)/ VPAD (320)/ Wi-FiTM Daemon (315).

16. La red responde con un acuse de que la llamada ha sido aceptada.

17. La llamada esta ahora activa.

18. El modulo CSM (375) informa del nuevo estado en el siguiente intervalo de consulta.

(0048) Un experto en la materia puede entender facilmente que la descripcion de mas arriba de recibir una llamada a traves de Wi-FiTM puede ser modificada sencillamente a recibir una llamada a traves de otra forma de Interfaz de

5

10

15

20

25

30

35

40

45

50

55

60

65

Red Alternativa sustituyendo el Wi-FiTM Daemon por otra forma de Interfaz Daemon de Red Alternativa, e incluyendo cualquier cambio de hardware necesario.

Anadir una Llamada de Video

(0049) Para anadir una llamada de video al terminal movil, un Motor de Video tiene que ser anadido primeramente. La aceleracion de hardware para el codec de video normalmente se provee como un subsistema de hardware que es controlado por el procesador de la aplicacion. Aunque la llamada de video tambien puede ser implementada en software que se ejecuta en el procesador de aplicacion CPU, el ahorro energetico y las eficiencias de memoria demandan que se use un acelerador de hardware independiente para procesar el video. Los codec de video no estan incluidos en el procesador LTE, a causa de la memoria limitada y el CPU en el hardware del procesador LTE. Semejantes procesadores son muy optimizados en el coste, habida cuenta que pueden ser usados en una variedad de aplicaciones, tales como dongles o telefonos de bajo coste, que no requieren procesar video.

(0050) El primer reto para proporcionar la capacidad de llamada de video se presenta con un enfoque para la aplicacion de video (tal como marcador de video) para iniciar y gestionar una llamada de video. Las ordenes AT estandar no proporcionan capacidades tales como crear una llamada de video, anadir un video a una llamada de voz activa, terminar la parte del video de la llamada, e informar el estado de la llamada de video. El conjunto de ordenes AT puede extenderse para proveer estas capacidades segun la arquitectura de software expuesta. Sin embargo, este enfoque no es el preferible, porque la industria se esta apartando del conjunto de ordenes AT. Muchos proveedores de chip de modem estan proponiendo ahora interfaces propietarios bajo la interfaz RIL. El enfoque que se toma en el diseno expuesto es el de aprovechar la arquitectura de descarga Wi-FiTM para proporcionar un metodo para controlar, gestionar, y pasar los datos necesarios para la llamada de video.

(0051) El segundo reto para anadir una llamada de video al terminal movil es minimizar los gastos generales y las restricciones para anadir el Motor de Voz. Ello requiere que el Motor de Voz este localizado y sea ejecutado DENTRO del software de la aplicacion de video. Ello permite al Motor de Video que acceda a la seccion deseada de la pantalla sin problemas de permiso u otros gastos adicionales.

(0052) Se expone una tecnica para redirigir paquetes de video que son producidos y consumidos por un procesador que desarrolla funciones de codec de video en el procesador LTE, de manera que los paquetes de video pueden ser transportados a traves del modem LTE (para beneficiarse del canal de soporte apoyado por el modem). Un procesador LTE atipico ha limitado el CPU y el hardware de memoria y no puede desarrollar funciones de codec de video, de manera que las funciones de codec de video tienen que ser implementadas en un procesador de aplicacion adjunto. Para que los paquetes de video puedan ser transportados sobre el canal de soporte LTE a traves del modem LTE, el motor de video que esta siendo ejecutado en el procesador de aplicacion envia y recibe paquetes de video hacia/desde el modem LTE. El flujo de los datos de video entre el motor de video (en el procesador de aplicacion) y el procesador LTE es gestionado por un mecanismo de comunicacion del inter- procesador (IPC). Un modulo redirector de paquetes de red en el procesador LTE abre el acceso al canal de soporte usando las funciones de control de modem LTE, y los datos son intercambiados entre el Motor de Video y el modulo redirector de video, usando el mecanismo IPC. Si existen otras opciones de interfaz de red alternativas, entonces un modulo redirector de paquete de video es necesario en el procesador de aplicacion para redirigir los datos de video a dicha interfaz de red alternativa, tal como Wi-FiTM, en lugar del modem LTE. Un modulo de control en el procesador LTE es responsable de seleccionar la interfaz de red a ser usada por los datos de video y los paquetes de control. Dirigiendo todos los paquetes de video a traves del modulo redirector de paquetes de video, la interfaz de red apropiada para el trafico de video puede ser Montrolada. Los paquetes de video que deben ser transmitidos a traves del canal Wi-FiTM son redirigidos al Wi-FiTM Daemon por el modulo redirector de paquetes de video. Este modo de redirigir los paquetes es mas eficiente durante una llamada Wi-FiTM que directamente intercambiando paquetes entre el motor de voz y el modulo redirector de paquetes de red (en el procesador LTE) y entonces haciendo que el modulo redirector de paquetes de red dirija los paquetes de video de vuelta al Wi-FiTM Daemon (en el procesador de aplicacion).

(0053) Se expone tambien una tecnica para sincronizar los datos de video en un procesador de aplicacion en un terminal movil con los datos de voz en el procesador LTE (que esta capacitado para VoIP o VoLTE). Para que los paquetes de voz y de video sean sincronizados, la informacion tiene que ser intercambiada entre los motores de voz y de video. Los motores de voz y video intercambian informacion (por ejemplo, el tiempo de absolucion del paquete siendo actualmente oido o reproducido) usando un mecanismo de comunicacion de inter-procesador (IPC) logicamente situado entre el Motor de Video y el Motor de Voz. Este enfoque permite a los motores de voz y video para gestionar sus respectivas velocidades de descodificacion, de manera que la voz y el video esten sincronizados.

(0054) Por favor, hacemos referencia a la Fig. 4. El procesador LTE (460) del terminal movil (400) comprende un Control de Modem Heredado y un modulo de Plano de Usuario (470), un Gestionador de Ordenes (465), un modulo de Interfaz de Servicio de Internet (ISI) (482), un modulo de Motor de Voz (484), un modulo de Protocolo de Iniciacion de Sesion (SIP) (488), un Nivel de Abstraccion del Sistema Operativo (OSAL) (486), un Redirector de Puerto v (VPR) (495), un Dispositivo de Modem del Puerto v (VPMD) (490), y un Modulo de Control/ Estado (CSM) (475). El modulo CSM (475) incluye un Gestor de Politica de Radio (RPM) (480).

(0055) Para anadir una llamada de video, el terminal movil (400) difiere del terminal movil (300) en que el procesador

5

10

15

20

25

30

35

40

45

50

55

60

65

de aplicacion (410) del terminal movil (400) ademas comprende una Aplicacion de Video (425) que incluye un Motor de Video (430), un Redirector de Paquete de Video (440), y una Interfaz de Control/ Estado (CSI) (435). El terminal movil (400) ademas incluye un RIL y un Controlador de Modem (405), el Wi-FiTM Daemon (415), y el Dispositivo de Aplicacion del Puerto v (VPAD) (420) funcionan por el procesador de aplicacion (410). El Dispositivo de Modem de Puerto v (VPMD) (490) y el Dispositivo de Aplicacion de Puerto v (VpAD) (420) juntos pueden ser considerados funcionalmente como un mecanismo de Comunicacion de Inter-Procesador (IPC) (450).

(0056) Los modulos de software (425, 430 y 440) del nuevo procesador de aplicacion (410) anadidos para anadir el apoyo de llamada de video mostrados en la Fig. 3 son:

- El modulo CSI (435) proporciona los servicios requeridos por la aplicacion de video (425) para crear y controlar una llamada de video.

- El Motor de Video (430) comparte un proceso con la aplicacion de video (425). El Motor de Video (430) es responsable de codificar y descodificar transmisiones de video. Adicionalmente, el Motor de Video (430) contiene un bufer de datos.

(0057) Tanto el modulo CSI (435) como el Motor de Video (430) comunican con el modulo VPMD (490) a traves del modulo VPAD (420). Esta ruta de comunicacion permite al modulo CSM (475) que controle las funciones de la llamada de video provistas por el modulo CSI (435) y el Motor de Video (430), de manera que las funciones de video sean coordinadas con funciones de voz (controladas por el modulo CSM (475)). Adicionalmente, la arquitectura permite a los datos de video que se intercambien con el procesador LTE (460), de forma que pueden ser situados en el canal de soporte de video.

- El modulo Redirector de Paquetes de Video (440) permite que los datos de video sean llevados a traves de la red movil (o canal de soporte), o situados a traves de Wi-Fi™' Ello permite que los datos de video sean transportados a traves de Wi-FiTM mas eficientemente, y tambien que los datos de video sean transportados a traves de una red diferente desde los datos de audio en la misma llamada de video.

Ejemplo de uso: Llamada de Video estandar a traves de LTE

(0058) La principal diferencia entre una llamada de video y una llamada de voz es que las ordenes ya no pueden venir de un controlador de modem, a menos que haya sido extendido a las llamadas de video de soporte. Abajo se expone una secuencia de acciones para establecer una llamada de video.

1. El usuario inicia una llamada de video (dentro de la Aplicacion de Video (425))

2. La Aplicacion de Video (425) interactua con el modulo CSI (435) para crear la llamada de video.

(0059) Adicionalmente, ello inicia el Motor de Video (430).

3. El modulo CSI (435) envia una orden al modulo CSM (475) a traves del modulo VPAD (420) y del modulo VPMD (490) para que se inicie la llamada.

4. El modulo CSM (475) envia las ordenes necesarias al modulo SIP (488) (a traves de ISI (482)) para establecer una llamada de video.

5. El modulo CSM (475) informa entonces del progreso al modulo CSI (435) a traves de la ruta VPMD (490)/ VPAD (420).

6. Cuando la llamada es respondida, el modulo CSM (475) envia una actualizacion del estado (desde el modulo SIP (488)) al modulo CSI (435). Adicionalmente, el modulo CSM (475) inicia la transmision de voz y video. La transmision de voz permanece dentro del procesador LTE (460). El modulo VPR (495) se usa para dirigir paquetes entre el Motor de Voz (430) y el canal de soporte LTE. Las acciones siguientes se requieren para iniciar la transmision de video.

a. Existe un codigo de control en el Motor de Voz (484) que envia una orden para iniciar el Motor de Video (430). Esta orden se pasa al Motor de Video (430) a traves del modulo VPMD (490) y el modulo VPAD (420). Desde el momento en que el Motor de Video (430) ha sido iniciado por la Aplicacion de Video (425) (en el paso 2 arriba), el Motor de Video (430) esta atendiendo a dichas ordenes desde el modulo VPAD (420).

b. Cuando el Motor de Video (430) recibe la orden de inicio desde el modulo VPAD (420), el Motor de Video (430) comienza a enviara paquetes de video.

c. Los paquetes de video se envian al modulo VPR (495) a traves del VPAD (420)/ VPMD (490). El (495) dirige entonces los paquetes al canal de soporte de video apropiado.

d. Cuando el modulo VPR (495) recibe un paquete de video (desde el canal de soporte apropiado), el (495) envia el paquete de video al Motor de Video (430) a traves del VPMD (490)/ VPAD (420).

7. La llamada de video esta ahora activa.

Ejemplo de uso: Llamada de Video Wi-FiTM con Redirector de Paquete de Video

(0060) La funcion de audio de una llamada de video a traves de Wi-FiTM se comporta asi como una llamada VoIP a traves de Wi-FiTM, como se describio mas arriba. Sin embargo, usando la misma ruta de datos dentro del terminal

modulo VPR modulo VPR

5

10

15

20

25

30

35

40

45

50

55

60

65

movil para llamada de video a traves de la red LTE (descrito en el ejemplo de uso anterior), los datos de video recibidos por el Wi-FiTM Daemon (415) tendrian que ser pasados al modulo VPR (495) en el procesador LTE, y entonces ser redirigidos de vuelta desde el modulo VPR (495) al Motor de Video (430) (a traves de VPMD (490)/ VPAD (420)). Similarmente, todos los paquetes de video salientes deberian ser enviados desde el Motor de Video (430) al modulo VPR (495) en el procesador LTE (460) y entonces de vuelta al Wi-FiTM Daemon a traves del VPMD (490)/VPAD (420). Este proceso de dirigir los datos de video a traves del procesador LTE (460) es muy ineficiente. El Redirector de Paquetes de Voz (440) se incorpora para mitigar esta ineficacia.

(0061) Con el Redirector de Paquete de Video (440), el transporte de datos de audio y video tambien puede ser dividido a traves de diferentes interfaces de red (radio). Por ejemplo, es posible enviar datos de audio a traves del canal de soporte de audio LTE, mientras se descarga el video a la red Wi-FiTM.

(0062) Despues de que el terminal movil (400) se ha registrado en el proveedor de servicio a traves de Wi-FiTM, el terminal movil (400) esta listo para enviar y recibir llamadas a traves de Wi-FiTM. Se expone abajo un listado de una secuencia de acciones necesarias para establecer una llamada de video a traves de Wi-FiTM.

1. El usuario inicia una llamada de video.

2. La Aplicacion de Video (425) interactua con el modulo CSI (435) para crear una llamada de video, e inicia el Motor de Video (430).

3. El modulo CSI (435) envia una orden al modulo CSM (475) a traves del modulo VPAD (420) y el modulo VPMD (490) para iniciar la llamada.

4. El modulo CSM (475) envia las ordenes SIP necesarias al modulo SIP (488) para establecer una llamada de video.

5. Las ordenes SIP en 4. son redirigidas por el modulo VPR (495) al Wi-FiTM Daemon (415) a traves del modulo VPMD (490) y del modulo VPAD (420).

6. Cuando los eventos SIP desde el nucleo IMS son recibidos por el Wi-FiTM Daemon (415), estos son dirigidos al modulo SIP (488) a traves de la ruta VPAD (420)/ VPMD (490)/ VPR (495).

7. El modulo CSM (475) informa del progreso de la llamada de video al modulo CSI (435) a traves del modulo VPMD (490) y del modulo VPAD (420).

8. Cuando la llamada es contestada, el modulo CSM (475) envia una actualizacion del estado al modulo CSI (435). Adicionalmente, el modulo CSM (475) inicia la transmision de voz y video. El Wi-FiTM Daemon es notificado de que los conectores de red especificos tienen que ser abiertos, de forma que tanto la transmision de voz como de video sean transportadas a traves de Wi-FiTM.

9. Las siguientes acciones establecen la transmision de voz.

a. Cuando el Motor de Voz (484) crea un paquete de voz para la transmision, el Motor de Voz (484) envia el paquete al Wi-FiTM Daemon a traves del modulo VPMD (490), el modulo VPAD (420), y el modulo VPR

(495). TM TM

b. Cuando el Wi-FiTM Daemon (415) recibe un paquete de voz, el Wi-FiTM Daemon (415) envia el paquete de

voz al Motor de Voz (484) a traves de la ruta VPAD (420)/ VPMD (490)/ VPR (495).

10. Las siguientes acciones establecen la transmision de video.

a. El Motor de Voz (484) envia una orden al Motor de Video (430) para comenzar la transmision. Esta orden se pasa al Motor de Video (430) a traves del modulo VPMD (490) y del modulo VPAD (420). Desde el momento en que el Motor de Video (430) ha sido iniciado por la aplicacion de video (425) (en el paso 2 de arriba), el Motor de Video (430) atiende a semejantes ordenes.

b. Cuando el Motor de Video (430) recibe la orden del modulo VPAD (420) para iniciar la transmision, el Motor de Video (430) comienza a mandar paquetes de video.

c. Los paquetes de video salientes son enviados al Redirector de Paquetes de Voz (440). Habida cuenta que la llamada usa la interfaz Wi-FiTM, el Redirector de Paquetes de Video (440) envia los paquetes al Wi-FiTM Daemon (415). (Si la llamada fue a traves de LTE, los paquetes de video serian dirigidos al modulo VPR (495) a traves de la ruta VPAD (420)/ VPMD (490).

d. Cuando Wi-FiTM Daemon (415) recibe un paquete video entrante, el Wi-FiTM Daemon (415) envia el paquete al Motor de Video (430) a traves del Redirector Paquete de Video (440).

11. La llamada de video esta ahora activa.

(0063) Un experto en la materia puede facilmente entender que la descripcion de arriba sobre el establecimiento de una llamada de video a traves de Wi-FiTM puede ser sencillamente modificada estableciendo una llamada de video usando otra forma de una Interfaz de Red Alternativa sustituyendo el Wi-FiTM Daemon por otra forma de Interfaz Daemon de Red Alternativa, e incluyendo cualquier cambio de hardware necesario.

Anadir IM y otras caracteristicas RCS

Problema de Registro Dual

(0064) Un problema bien conocido al proporcionar Servicios de Comunicaciones Enriquecidos (RCS) en dispositivos

5

10

15

20

25

30

35

40

45

50

55

60

65

moviles es el problema del registro dual. Si un usuario descarga multiples aplicaciones RCS en el dispositivo movil, cada aplicacion tiene su propia pila de Subsistema Multimedia IP (IMS). Cada pila tiene que registrarse en el nucleo IMS para conseguir el acceso a las caracteristicas RCS. El nucleo IMS esta configurado para permitir solamente un registro por dispositivo movil. Cuando una segunda aplicacion intenta registrarse en el proveedor de servicio, se produce un problema de registro dual. Habida cuenta que cada proveedor de servicio (y su nucleo IMS) gestiona esta situacion de modos diferentes, el usuario puede encontrarse con que una, la otra o ambas aplicaciones no funcionan.

(0065) Este problema es especialmente pronunciado cuando el dispositivo tiene un procesador LTE que esta capacitado para VoLTE. El procesador LTE intentara registrarse en el proveedor de servicio (y su nucleo IMS) al recibir energia. Ello ocurrira antes de que cualquier otra aplicacion tenga la oportunidad de registrarse. Habida cuenta que un tipico procesador LTE no proporciona una funcionalidad RCS completa, las aplicaciones adicionales son requeridas necesariamente para acceder a las caracteristicas RCS que faltan, y estas aplicaciones no podran registrarse en el nucleo IMS.

(0066) Otro factor que causa el problema de registro dual es la memoria limitada y las fuentes CPU disponibles en un procesador LTE tipico. La falta de espacio de memoria limita el numero de sesiones SIP que pueden ser implementadas en el procesador LTE al mismo tiempo. Las sesiones SIP que usan el Protocolo de Transmision de Sesion de Mensaje (MSRP) son particularmente de memoria intensiva. Semejantes funciones de memoria intensiva tienen que ser implementadas en el procesador de la aplicacion que tiene disponible un espacio de memoria mucho mayor. Ejemplos de semejantes sesiones son funciones RCS como IM y Transferencia de Archivos. Se expone una tecnica para anadir un Acelerador de Protocolo en el procesador de aplicacion para permitir un mayor numero de sesiones SIP y sesiones SIP de memoria intensiva para ser implementadas en el dispositivo movil. Sin embargo, cuando una segunda pila SIP (el Acelerador de Protocolo) es implementada en el procesador de aplicacion, aparece el problema de registro dual descrito mas arriba.

(0067) Se expone una tecnica para evitar los problemas de registro dual cuando las funciones RCS en un dispositivo movil requiere funciones de protocolo SIP para ser desarrolladas fuera de la pila SIP incorporada en el procesador LTE. Para evitar este problema, todas las operaciones de protocolo SIP (por ejemplo, voz, SMS, IM, etc.) tienen que compartir la misma conexion SIP autentificada. Ello puede conseguirse dirigiendo todos los paquetes SIP (desde cualquier pila SIP en el dispositivo movil) a traves de un modulo redirector de paquete de red que mantiene una unica conexion SIP autentificada con el nucleo IMS. El redirector de paquetes de red tambien dirige apropiadamente los paquetes entrantes desde el nucleo IMS a la pila SIP prevista en el dispositivo movil, como es requerido.

(0068) Los paquetes RCS pueden necesitar ser descargados a la red Wi-FiTM en un dispositivo movil que tiene las funciones RCS y un procesador LTE con un subsistema SIP incorporado (como VoLTE preparado procesador LTE). Cuando los paquetes RCS deben ser transmitidos a traves de Wi-FiTM (o cualquier interfaz de red alternativa aparte de la radio LTE), el modulo redirector de paquetes de red redirige los datos al Wi-FiTM Daemon en el procesador de aplicacion (a traves del mecanismo de comunicacion del inter-procesador (IPC), de forma que los mismos pueden ser transmitidos a traves de Wi-FiTM, mientras se mantiene la misma conexion SIP autentificada. En vez de redirigir los datos de protocolo SIP a un modulo redirector de paquetes de red en un procesador LTE, como se describio, todos los mensajes SIP pueden ser procesados en el procesador de aplicacion usando el ace lerador de protocolo, como muestra la Fig. 6. Todos los paquetes RCS procesados son transmitidos por Wi-FiTM a traves de Wi-FiTM Daemon, evitandose que se intercambien datos extras con el procesador LTE.

(0069) Para capacitar a las aplicaciones RCS en el dispositivo movil y para solucionar los problemas de arriba, la siguiente arquitectura es usada, como muestra la Fig. 5.

(0070) El procesador LTE (560) del terminal movil (500) comprende un Control de Modem Heredado y un modulo de Plano de Usuario (570), un Gestionador de Ordenes (565), un modulo de Interfaz de Servicios de Internet (ISI) (582), un modulo de Motor de Voz (584), un modulo de Protocolo de Iniciacion de Sesion (SIP) (588), un Nivel de Abstraccion de Sistema Operativo (OSAL) (586), un modulo Redirector de Puerto v modificado (VPR) (595), un Dispositivo de Modem de Puerto v (VPMD) (590), y un Modulo de Control/ Estado (CSM) (575). El modulo CSM (575) incluye un Gestor de Politica de Radio (RpM) (580).

(0071) El procesador de aplicacion (510) del terminal movil (500) comprende una Aplicacion de Video (525) que incluye un Motor de Video (530), un Redirector de Paquetes de Video (540), el RIL y Controlador de Modem (505), el Wi-FiTM Daemon (515), y el Dispositivo de Aplicacion de Puerto v (VpAD) (520). El terminal movil (500) difiere del terminal movil (400) en que el terminal movil (500) tambien incluye una Interfaz de Control/ Estado (CSI) (535) modificada, un modulo Acelerador de Protocolo (542), y Aplicaciones RCS, incluyendo llamadas de video (527), y un modulo VPR modificado (595). El Dispositivo de Modem de Puerto v (VPMD) (590) y el Dispositivo de Aplicacion de Puerto v (VPAD) (520) juntos pueden ser considerados funcionalmente como un mecanismo de Comunicacion de Inter-procesador (IPC) (550).

(0072) El soporte para las caracteristicas RCS no varian demasiado el diseno de la arquitectura, sino que las modificaciones se hacen a algunos de los modulos de software.

- El modulo CSI (535) se modifica para proveer IM, compartir contenidos, transferir archivos, etc. Los

5

10

15

20

25

30

35

40

45

50

55

60

65

mensajes para estas nuevas caracteristicas se pasan al modulo CSM (575). Las rutas de datos se mantienen inalteradas. Por ello, las aplicaciones RCS siguen usando los mismos modulos de software VoIP y SMSoIP en el procesador LTE.

- Modulo Acelerador de Protocolo (542): para solucionar los problemas de la memoria y del CPU para las aplicaciones tales como la transferencia IM o de archivos, algunos trabajos de protocolo necesitan ser trasladados al procesador de aplicacion. Un enfoque es mover el Protocolo de Transmision de Sesion de Mensaje (MSRP) (el protocolo usado para la mensajeria IM y la transferencia de archivos) al procesador de aplicacion. Otro enfoque es crear una segunda pila SIP en el procesador de aplicacion junto con MRSP. Este segundo enfoque tiene la ventaja de que permite un mayor numero de sesiones SIP de lo que la memoria en el procesador LTE permite. El nuevo modulo anadido al diseno para dar apoyo a la descarga es el Acelerador de Protocolo (542), mostrado en la Fig. 5. El modulo Acelerador de Protocolo (542) esta adjunto a la placa base (582), de manera que aparece en el modulo CSM (575) como un motor de protocolo independiente que da soporte al IM, transferencia de archivos, etc.

- VPR (595): Como se discutio en secciones previas, el modulo VPR (595) dirige la voz, y el video y los mensajes de protocolo SMS al motor SIP (588) en el procesador LTE (560). El modulo VPR (595) esta actualizado de manera que dirige los paquetes SIP al motor SIP (588) en el procesador de aplicacion o al Acelerador de Protocolo (542) en el procesador de aplicacion, segun la politica y la disponibilidad de la memoria en el procesador de aplicacion y en el procesador LTE. Semejante politica consiste en dirigir todos los mensajes de voz y mensaje SMS SIP al motor SIP en el procesador lTe, y dirigir todos los restantes mensajes (mensajes que no estan asociados con la voz, video o transacciones SMS) al modulo Acelerador de Protocolo (542). Dirigiendo todos los mensajes SIP a traves del modulo VPR (595), todos los mensajes SIP (tanto si se usa el motor SIP (588) o el Acelerador de Protocolo (520)) usara la misma conexion SIP autentificada.

Como funciona VPR

(0073) Con la finalidad de que el terminal movil provea una red basada en servicios de comunicacion a tiempo real, el agente del usuario SIP en un terminal movil (500) tiene que registrarse en el nucleo IMS. En lugar de que el modulo SIP (588) abra directamente una conexion con la red, el modulo SIP (588) abre la conexion pidiendo al modulo VPR (595) que abra la conexion a la red. El modulo SIP (588) se registra en el nucleo IMS usando esta conexion de modulo VPR (595). Una vez que esta conexion de modulo VPR (595) ha sido registrada en el nucleo IMS, el modulo VPR (595) permite a otros modulos SIP en el sistema (como al del Acelerador de Protocolo (542)) que usen esta conexion al nucleo IMS.

(0074) Ademas de permitir a los multiples modulos SIP que envien mensajes al nucleo IMS, el modulo VPR (595) tiene que dirigir los paquetes desde el nucleo IMS a la pila SIP apropiada. El modulo VPR (595) realiza esto inspeccionando los paquetes entrantes. El modulo VPR (595) puede estar programado para dar soporte a diferentes politicas para gestionar los paquetes entrantes. Una politica tipica de la arquitectura descrita en la Fig. 5 es la de que el modulo VPR (595) dirija los paquetes SIP asociados con sesiones de llamadas de voz y video al modulo SIP (588) y todos los demas paquetes al modulo acelerador de protocolo (542).

(0075) El uso de esta politica significa que un paquete IM entrante podria ser dirigido al modulo acelerador de protocolo (542), mientras que las llamadas de video entrantes podrian ser dirigidas al modulo SIP (588).

(0076) El modulo VPR (595) permite a un terminal movil con un procesador LTE, que solo tiene memoria y fuentes CPU para dar soporte a llamadas de voz y video, que de soporte a otras caracteristicas RCS, usando una segunda pila SIP (como la del acelerador de protocolo (542)) sin encontrarse con el problema del registro dual.

Ejemplo de uso: IM a traves de LTE

(0077) RCS IM (mensajeria instantanea) requiere tanto protocolos SIP, como protocolos MSRP para enviar y recibir mensajes. Se expone abajo un listado de las acciones necesarias para enviar un mensaje desde un usuario a otro a traves de LTE.

1. El terminal movil (500) esta autentificado por el nucleo IMS (del proveedor de servicio) y esta preparado para enviar y recibir mensajes IM. Esta autentificacion se ejecuta por el modulo SIP (588) a traves del modulo VPR (595) a traves de la red de radio LTE.

2. Cuando el usuario desea enviar un mensaje, una aplicacion RCS (527) en el terminal movil (500) ordena al modulo CSI (535) que inicie el proceso de conexion.

3. El modulo CSI (535) contacta con el modulo CSM (575) (a traves de la ruta VPAD (520)/ VPMD (590)) para iniciar una sesion de mensajeria SIP con la parte remota enviando una invitacion a la sesion de mensajes. La invitacion tambien incluye el primer mensaje IM.

4. El modulo CSM (575) comprueba el modulo RPM (580) y averigua que el mensaje deberia ser enviado a traves de LTE.

5. Habida cuenta que la sesion SIP es para mensajeria, el modulo CSM (575) contacta con el modulo Acelerador de Protocolo (542) (a traves de la ruta VpMd (590)/ vPaD (520)) para iniciar una nueva sesion SIP a traves de LTE.

6. El modulo Acelerador de Protocolo (542) crea el mensaje de invitacion SIP y lo envia al modulo VPR (595) a traves de la ruta VPAD (520)/ VPMD (590).

5

10

15

20

25

30

35

40

45

50

55

60

65

7. El modulo VPR (595) envfa dicho mensaje de invitacion SIP a la red LTE. Usando el modulo VPR (595), el mensaje SIP es capaz de compartir la conexion SIP autentificada con el nucleo IMS ya establecido por el modulo SIP (588) en el paso 1 de arriba.

8. El nucleo IMS envfa la respuesta a la invitacion (en este caso, una aceptacion). El modulo VPR (595) determina que esto es parte de la misma sesion de mensajes iniciada en el paso 6, y lo pasa el modulo Acelerador de Protocolo (542) para el procesamiento.

9. El modulo Acelerador de Protocolo (542) notifica al modulo CSM (575) de que la invitacion ha sido aceptada.

10. El modulo CSM (575) pasa la notificacion de aceptacion al modulo CSI (535), el cual responde diciendo al modulo CSM (575) que envie un acuse.

11. El modulo CSM (575) dice al modulo Acelerador de Protocolo (542) que acuse recibo de la aceptacion.

12. El modulo Acelerador de Protocolo (542) envfa un mensaje de acuse al nucleo IMS a traves del modulo VPR (595).

13. La sesion IM esta ahora activa. El modulo CSI (535) sigue el mensaje de acuse con el mensaje IM (cuerpo).

14. Este mensaje IM se pasa al modulo CSM (575).

15. El modulo CSM (575) envfa el mensaje IM al Acelerador de Protocolo (542).

16. El modulo Acelerador de Protocolo (542) envfa el mensaje IM a la red lTe usando MSRP a traves del modulo VPR (595) (usando el mecanismo VPAD/VpMd IPC).

17. Cuando el nucleo IMS recibe el mensaje IM, lo envfa al usuario remoto.

Ejemplo de Uso: Compartir Contenido de Video

(0078) El compartir contenido de video requiere exactamente las mismas acciones que una llamada de video a traves de LTE, ejemplo de uso descrito arriba sin una transmision de voz.

Ejemplo de Uso: Transferencia de Archivo

(0079) La transferencia de archivo y la transferencia de imagen son muy similares al IM a traves LTE, ejemplo de uso descrito arriba. La principal diferencia es que MSRP rompe una unica transferencia de archivo en multiples mensajes MSRP.

Optimizacion para la descarga Wi-FiTM

(0080) Junto con el modulo Acelerador de Protocolo (542) descrito arriba en la Fig. 5, la descarga Wi-FiTM para voz, SMS, video y funciones RCS puede ser optimizado ademas mediante la adicion de un bloque de software Redirector de Protocolo, como se muestra en la Fig. 6.

(0081) El procesador LTE (660) en el terminal movil (600) comiprende un modulo de Control de Modem Heredado y un modulo de Plano de Usuario (670), un Gestionador de Ordenes (665), un modulo de Interfaz de Servicio de Internet (ISI) (682), un modulo de Motor de Voz (684), un modulo de Protocolo de Iniciacion de Sesion (SIP) (688), un Nivel de Abstraccion del Sistema Operativo (OsaL) (686), un Redirector de Puerto v (VPR) (695) modificado, un Dispositivo de Modem de Puerto v (VPMD) (690), y un Modulo de Control/ Estado (CSM) (675). El modulo CSM (675) incluye un Gestor de Politica de Radio (RpM) (680).

(0082) El procesador de aplicacion (610) en el terminal movil (600) comprende una Aplicacion de Video (625) que incluye un Motor de Video (630), Aplicaciones RCS incluyendo llamadas de video (627), un Redirector de Paquete de Video (640), el RIL y el Controlador de Modem (605), el Wi-FiTM Daemon (615), el Dispositivo de la Aplicacion de Puerto v (VpAd) (620), la Interfaz de Control/ Estado (CSI) modificada (635), y un modulo de Acelerador de Protocolo (642). El terminal movil (600) difiere del terminal movil (500) en que el terminal movil (600) tambien incluye un modulo Redirector de Protocolo (642). El Dispositivo de Modem de Puerto v (VPAD) (690) y el Dispositivo de Aplicacion de Puerto v (VPAD) (620) juntos pueden ser considerados funcionalmente como mecanismo de Comunicacion de Inter-procesador (IPC) (650).

- Modulo Redirector de Protocolo (645): cuando una llamada de voz o video o una funcion RCS se situa a traves de Wi-FiTM, todo el trafico SIP puede ser redirigido por el modulo Redirector de Protocolo (645) para ser gestionado por el modulo Acelerador de Protocolo (642) en el procesador de aplicacion (610).

(0083) Los siguientes modulos han sido modificados:

- Wi-FiTM Daemon (615): Todo el trafico SIP se dirige a traves del modulo Redirector de Protocolo (645) al modulo Acelerador de Protocolo (642). Habida cuenta que solo hay una pila SIP activa conectada al nucleo IMS, se elimina el problema de registro dual.

- Modulo VPR (695): Este modulo ya no necesita dirigir el trafico SIP al Wi-FiTM Daemon, porque todas las sesiones SIP Wi-FiTM son gestionadas por el modulo Acelerador de Protocolo (642). Sin embargo, el modulo VPR (695) aun es necesario para dirigir el trafico de voz (procesado por el Motor de Voz (684)) al Wi-FiTM Daemon.

(0084) La Fig. 6 muestra un sistema operacional que puede redirigir el trafico de protocolo al Wi-FiTM Daemon. Una llamada de voz es iniciada del modo usual (a traves de una orden AT o una orden CSI (635)). La llamada se

5

10

15

20

25

30

35

40

45

50

55

60

establece usando la pila SIP en el modulo de Acelerador de Protocolo (642), en lugar de la pila SIP en el procesador LTE (660). Sin embargo, el trafico de voz RTP aun se origina y termina en el procesador LTE, usando el Motor de Voz (684). El paquete RTP para voz es redirigido a la interfaz Wi-FiTM a traves del modulo VPR (695). Para una llamada de video a traves de Wi-FiTM, los paquetes de video son redirigidos al Wi-FiTM Daemon (615) a traves del modulo Redirector de Paquetes de Video (640).

Ejemplo de Uso: IM a traves de Wi-FiTM con Acelerador de Protocolo

(0085) Se exponen abajo las acciones necesarias para enviar un mensaje de un usuario a otro a traves de Wi-FiTM.

1. Despues de que el terminal movil (600) es autentificado por el nucleo IMS, esta preparado para enviar y recibir mensajes IM.

2. Cuando un usuario desea enviar un mensaje, la aplicacion RCS (627) ordena al modulo CSI (635) que inicie el proceso de conexion.

3. El modulo CSI (635) contacta con el modulo CSM (675) (a traves de la ruta VPAD (620)/ VPMD (690)) para iniciar una sesion de mensajeria SIP con la parte remota enviando una invitacion a la sesion de mensajes. Incluida con la invitacion va el primer mensaje IM.

4. El modulo CSM (675) comprueba el modulo RPM (680) y averigua que el mensaje deberia ser enviado a traves de Wi-FiTM.

5. Habida cuenta que la sesion SIP es para mensajeria, el modulo CSM (675) contacta con el modulo Acelerador de Protocolo (642) (a traves de la ruta VpMd (690)/VPAD (620)) para iniciar una nueva sesion a traves de Wi-FiTM.

6. El modulo Acelerador de Protocolo (642) crea el mensaje de invitacion SIP y lo envia al modulo Redirector de

Protocolo (645). TM TM

7. El modulo Redirector de Protocolo (645) envia el mensaje SIP al Wi-FiTM Daemon (615). Usando el Wi-FiTM

Daemon (615) con el modulo Redirector de Protocolo (645), el mensaje SIP es capaz de compartir la conexion SIP autentificada con el nucleo IMS.

8. El nucleo IMS envia de vuelta la respuesta a la invitacion (en este caso, una aceptacion). El Wi-FiTM Daemon (615) determina que esto es parte de la sesion de mensajes iniciada en el paso 6 y lo pasa al modulo Redirector de Protocolo (645).

9. El modulo Redirector de Protocolo (645) pasa el mensaje al modulo Acelerador de Protocolo (642) para el procesamiento.

10. El modulo Acelerador de Protocolo (642) notifica el modulo CSM (675) de que la invitacion ha sido aceptada.

11. El modulo CSM (675) lo pasa al modulo CSI (635).

12. El modulo Acelerador de Protocolo (642) envia el mensaje de acuse al nucleo IMS usando el modulo Redirector de Protocolo (645). El modulo Redirector de Protocolo (645) envia el mensaje IM al Wi-FiTM Daemon (615) para la transmision a la red.

13. La sesion IM esta ahora activa. El modulo CSI (535) sigue al mensaje de acuse con el mensaje IM (cuerpo).

14. El mensaje IM se pasa al modulo CSM (675).

15. El modulo CSM (675) envia el mensaje IM al modulo Acelerador de Protocolo (642).

16. El modulo Acelerador de Protocolo (642) envia el mensaiie IM usando MSRP.

17. El mensaje MSRP se envia a la red a traves del Wi-Fi™ Daemon (615) (al que se accede a traves del modulo Redirector de Protocolo (645)).

18. Cuando el nucleo IMS recibe el mensaje, lo pasa al usuario remoto.

(0086) Un experto en la materia puede entender facilmente que la descripcion de arriba de optimizar y anadir mensajes IM usando Wi-FiTM puede ser modificada sencillamente para optimizar y anadir mensajes IM usando otra forma de Interfaz de Red Alternativa sustituyendo el Wi-FiTM Daemon por otra forma de la Interfaz Daemon de Red Alternativa, e incluyendo cualquier cambio de hardware necesario.

Resumen

(0087) Este documento describe un sistema de software operacional para anadir VoLTE, video, soporte RCS, y descarga Wi-FiTM en un terminal movil. Cada una de las configuraciones se basa en los componentes fisicos y funcionales mostrados en la Fig. 2. Los mismos comienzan por anadir VoLTE a un procesador LTE. La seccion final (Fig. 6) describe un sistema completamente caracterizado que incluye llamada de voz y videoT SMS a traves de IP, caracteristicas RCS (IM, transferencia de archivo, compartir contenidos, etc.) y descarga Wi-FiTM. Debido al enfoque modular, es relativamente facil proveer subconjuntos de este sistema completamente caracterizado usando los mismos bloques de disenos y software. Por ejemplo, la Fig. 2 es un producto basico solo para VoLTE y SMSoIP y SRVCC, en tanto que la Fig. 3 anade la descarga Wi-FiTM, y la Fig. 4 anade llamada de Video, etc.

Claims

5

10

15

20

25

30

35

40

45

50

55

60

65

REIVINDICACIONES
18.- Un metodo para redirigir el trafico del paquete Protocolo de Iniciacion de Sesion en un terminal movil (300, 400, 500, 600) a diferentes interfaces de red (315, 415, 515, 615) usando una unica conexion registrada de Protocolo de Iniciacion de Sesion, comprendiendo el terminal movil (300, 400, 500, 600) un procesador de Evolucion a Largo Plazo (360, 460, 560, 660) y un procesador de aplicacion (310, 410, 510, 610), comprendiendo el procesador de Evolucion a Largo Plazo (360, 460, 560, 660) un modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) y un modulo redirector de paquete de red (395, 495, 595, 695), estando posicionado el modulo redirector de paquete de red (395, 495, 595, 695) entre el modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) y las diferentes interfaces de red (315, 415, 515, 615) que se encuentran en el procesador de aplicacion (310, 410, 510, 610), comprendiendo el metodo:

- la provision por el modulo redirector de paquete de red (395, 495, 959, 695) en el procesador de Evolucion a Largo Plazo (360, 460, 560, 660) de una interfaz de red virtual; y

- el reenvio por la interfaz de red virtual de todos los paquetes de Protocolo de Iniciacion de Sesion normalmente transmitidos a traves de un modem de Evolucion a Largo Plazo del procesador de Evolucion a Largo Plazo (360, 460, 560, 660) a una interfaz de red alternativa de diferentes interfaces de red (315, 415, 515, 615) del procesador de aplicacion (310, 410, 510, 610) usando un mecanismo de comunicacion de inter-procesador (350, 450, 550, 650) para enviar los paquetes de Protocolo de Iniciacion de Sesion al procesador de aplicacion (310, 410, 510, 610).
28.- El metodo de la reivindicacion 1a, en el cual el procesador de Evolucion a Largo Plazo (360, 460, 560, 660) es un procesador de Evolucion a Largo Plazo a traves de Voz, comprendiendo el metodo ademas:

- el reenvio por el modulo redirector de paquete de red (395, 495, 595, 695) de todo el trafico del paquete del Protocolo de Internet que de otro modo es transmitido a traves del procesador de Evolucion a Largo Plazo a traves de Voz (360, 460, 560, 660) a un Daemon para la interfaz de red alternativa (315, 415, 515, 615) en el procesador de aplicacion (310, 410, 510, 610) usando el mecanismo de comunicacion del inter-procesador (350, 450, 550, 650); y

- la interactuacion por la interfaz Daemon de red alternativa (315, 415, 515, 615) con un subsistema en el terminal movil (300, 400, 500, 600) para mantener una conexion de red establecida por la interfaz Daemon de red alternativa (315, 415, 515, 615) y la transmision/ recepcion del trafico de paquete de Protocolo de Internet a traves de la conexion de red establecida por la interfaz Daemon de red alternativa (315, 415, 515, 615);

- y todo el trafico de paquete del Protocolo de Internet va a traves de una conexion de Protocolo de Iniciacion de Sesion autentificada que es fundamentalmente la misma que se usa para la transmision de la Evolucion a Largo Plazo a traves de Voz.
38.- El metodo de la reivindicacion 18, en el cual el procesador de aplicacion (410, 510, 610) del terminal movil (400, 500, 600) ejecuta funciones de codec de video, y el procesador de aplicacion (410, 510, 610) produce y/o usa paquetes de video y los paquetes de video deben ser transmitidos a traves del procesador de Evolucion a Largo Plazo (460, 560, 660), comprendiendo el metodo ademas:

- el envio y la recepcion por un motor de video (430, 530, 630) que se ejecuta en el procesador de aplicacion (410, 510, 610), de los paquetes hacia/ desde el modulo redirector de paquetes de red (495, 595, 695);

- la peticion por el modulo redirector de paquetes de red (495, 595, 695) de acceso al canal de soporte de video de Evolucion a Largo Plazo a traves del procesador de Evolucion a Largo Plazo (460, 560, 660); y el intercambio de los paquetes de video entre el motor de video (430, 530, 630) en el procesador de aplicacion (310, 410, 510, 610) y el modulo redirector de paquetes de red (495, 595, 695) usando el mecanismo de comunicacion del inter-procesador (450, 550, 650).
48.- El metodo de la reivindicacion 38, en el cual cuando los paquetes de video deben ser transportados a traves de la interfaz de red alternativa (415, 515, 615) en el procesador de aplicacion (410, 510, 610), comprendiendo el metodo ademas:

- la seleccion por el modulo de Control/ Estado (475, 575, 675), usando un Gestor de Politica de Radio (480, 580, 680), de que interfaz de red (415, 515, 615) esta siendo usada para enviar/recibir los paquetes de video y los paquetes de control;

- el envio de los paquetes de video a traves del modulo redirector de paquetes de red (495, 595, 695) con el modulo de Control/ Estado (475, 575, 675) controlando que interfaz de red (415’’, 515, 615) esta siendo usada por los paquetes de video; y

- el reenvio por el modulo redirector de paquetes de red (495, 595, 695) los paquetes de video a un Daemon para dicha interfaz de red alternativa (415, 515, 615) cuando los paquetes de video deben ser transmitidos a traves de una red correspondiente a dicha interfaz de red alternativa (415, 515, 615).
58.- El metodo de la reivindicacion 38, que comprende ademas:

- el reenvio por el Redirector de Paquete de Video (440, 540, 640) de los paquetes de video al procesador de Evolucion a Largo Plazo (460, 560, 660) o a un Daemon para una interfaz de red alternativa (415, 515, 615) en el procesador de aplicacion (410, 510, 610) aparte del procesador de Evolucion a Largo Plazo (460, 560, 660) como es

5

10

15

20

25

30

35

40

45

50

55

60

65

determinado por un modulo de Control/ Estado (475, 575, 675) usando un Gestor de Politica de Radio (480, 580, 680).
68.- El metodo de la reivindicacion 3a, en el cual cuando el procesador de Evolucion a Largo Plazo (460, 560, 660) esta configurado para el Protocolo de Internet a traves de Voz o Voz a traves de la Evolucion a Largo Plazo, comprendiendo el metodo ademas:

- la sincronizacion de datos de video en el procesador de aplicacion (410, 510, 610) del terminal movil (400, 500, 600) con datos de voz en dicho procesador de Evolucion a Largo Plazo (460, 560, 660) intercambiando informacion de sincronizacion entre un motor de voz (484, 584, 684) del procesador de Evolucion a Largo Plazo (460, 560, 660) y el motor de video (430, 530, 630) del procesador de aplicacion (410, 510, 610) usando el mecanismo de comunicacion del inter-procesador (450, 550, 650) entre el motor de video (430, 530, 630) y el motor de voz (484, 584, 684), permitiendo el motor de video (430, 530, 630) y el motor de voz (484, 584, 684) que se gestionen sus respectivas velocidades de descodificacion, de manera que la voz y el video esten sincronizados.
78.- El metodo de la reivindicacion 18, que comprende ademas:

- la distribucion de funciones de Protocolo de Iniciacion de Sesion a traves de diferentes procesadores del terminal movil (300, 400, 500, 600) mientras se mantiene una unica conexion de Protocolo de Iniciacion de Sesion para el terminal movil (300, 400, 500, 600) mediante:

- la peticion por el modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) al modulo redirector de paquetes de red (395, 495, 595, 695) para que abra una conexion de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) al nucleo del Subsistema Multimedia de Protocolo de Internet;

- el registro del modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) con el nucleo de Subsistema Multimedia de Protocolo de Internet, usando el modulo redirector de paquetes de red (395, 495, 595, 695) la conexion de Protocolo de Iniciacion de Sesion abierta; y

- el permiso por el modulo redirector de paquetes de red (395, 495, 595, 695) a otros modulos del Protocolo de Iniciacion de Sesion en el terminal movil (300, 400, 500, 600) para que usen la misma conexion del Protocolo de Iniciacion de Sesion al nucleo del Subsistema Multimedia de Protocolo de Internet que ya esta registrada por el modulo redirector de paquetes de red (395, 495, 595, 695).
88.- El metodo de la reivindicacion 78, que comprende ademas:

- la inspeccion por el modulo redirector de paquetes de red (395, 495, 595, 695) de cada uno de los paquetes del Protocolo de Iniciacion de Sesion que vienen desde el nucleo del Subsistema Multimedia de Protocolo de Internet para determinar un correspondiente modulo de Protocolo de Iniciacion (388, 488, 588, 688) para procesar dicho paquete de Protocolo de Iniciacion de Sesion; y

- el envio por el modulo redirector de paquetes de red (395, 495, 595, 695) de los paquetes del Protocolo de Iniciacion de Sesion al correspondiente modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688).
98.- El metodo de la reivindicacion 88, que comprende ademas:

- el envio por el modulo redirector de paquetes de red (595, 695) de los paquetes de Protocolo de Iniciacion de Sesion asociados con sesiones de llamadas de voz y Servicio de Mensajes Cortos al modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660) y todos los demas paquetes de Protocolo de Iniciacion de Sesion a un modulo acelerador de protocolo (542, 642) que se ejecutan en el procesador de aplicacion (510, 610) del terminal movil (500, 600).
108.- ei metodo de la reivindicacion 88, que comprende ademas:

- el envio por el modulo redirector de paquetes de red (395, 495, 595, 695) de todos los mensajes que requieren un procesamiento del Protocolo de Transmision de Sesion de Mensaje a una pila de Protocolo de Transmision de Sesion de Mensaje en un procesador, y todos los demas mensajes de Protocolo de Iniciacion de Sesion a la pila de Protocolo de Iniciacion de Sesion en un procesador diferente.
118.- ei metodo de la reivindicacion 78, en el cual el terminal movil (500, 600) usando la conexion de Protocolo de Iniciacion de Sesion al nucleo del Subsistema Multimedia de Protocolo de Internet establecida por el modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion de Largo Plazo (560, 660) del terminal movil (500, 600) tiene funciones de Servicios de Comunicacion Enriquecidos implementadas en el mismo, comprendiendo el metodo ademas:

- la implementacion de un modulo acelerador de protocolo (542, 642) en el procesador de aplicacion (510, 610) del terminal movil (500, 600) proporcionando funciones del Protocolo de Iniciacion de Sesion;

- la determinacion por un Modulo de Control/ Estado (575, 675) de que funcion del Protocolo de Iniciacion de Sesion debe ser ejecutada por el modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660) y que funcion del Protocolo de Iniciacion de Sesion esta implementada en el modulo acelerador de protocolo (542, 642); y

5

10

15

20

25

30

35

40

45

50

55

60

65

- el envfo de datos de Servicios de Comunicaciones Enriquecidos a traves del modulo redirector de paquetes de red (595, 695) al modulo acelerador de protocolo (542, 642) o al modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660) segun la determinacion;

- y todos los datos de Servicios de Comunicaciones Enriquecidos son transmitidos a traves de la conexion de Protocolo de Iniciacion de Sesion registrada establecida por el modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660) para el Protocolo de Internet a traves de Voz y el Servicio de Mensajes Cortos.
128.- El metodo de la reivindicacion 11s, que comprende ademas:

- la determinacion por el Modulo de Control/ Estado (575, 675) de que funcion del Protocolo de Iniciacion de Sesion debe ser ejecutada por el modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660) y que funcion del Protocolo de Iniciacion de Sesion esta implementada en el modulo acelerador de protocolo (542, 642) segun cualquiera o segun cualquier combinacion de una cantidad de memoria requerida por la funcion del Protocolo de Iniciacion de Sesion, cantidad de memoria disponible en el procesador de aplicacion (510, 610) o en el procesador de Evolucion a Largo Plazo (560, 660), y/o disponible potencia de procesamiento del procesador de aplicacion (510, 610) del terminal movil (500, 600).

13s.- El metodo de la reivindicacion 11s, en el cual solo las funciones de Protocolo de Transmision de Sesion de Mensaje son implementadas en el modulo acelerador de protocolo (542, 642) en el procesador de aplicacion (510, 610), comprendiendo el metodo ademas:

- el envfo por el modulo redirector de paquetes de red (595, 695) en el procesador de Evolucion a Largo Plazo (560, 660) de todos los mensajes que requieren funciones de Protocolo de Transmision de Sesion de Mensaje al modulo acelerador de protocolo (542, 642) y de todos los demas mensajes del Protocolo de Iniciacion de Sesion al modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660).

14s.- El metodo de la reivindicacion 11s, en el cual las funciones de Servicios de Comunicacion Enriquecidos en el terminal movil (500, 600) que tienen el procesador de Evolucion a Largo Plazo (560, 660) requieren funciones de Protocolo de Iniciacion de Sesion que deben ser ejecutadas por el modulo acelerador de protocolo (542, 642) en el procesador de aplicacion (510, 610), aparte de la pila del modulo de Protocolo de Iniciacion de Sesion (588, 688) incorporada en el procesador de Evolucion a Largo Plazo (560, 660), comprendiendo el metodo ademas:

- evitar los problemas de registro dual mediante:

- el registro, por el modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660), en una red y el establecimiento de una unica conexion de Protocolo de Iniciacion de Sesion autentificada con el nucleo del Subsistema Multimedia de Protocolo de Internet para el Protocolo de Internet a traves de Voz y el Servicio de Mensajes Cortos a traves del Protocolo de Internet;

- el envfo de todos los paquetes de Protocolo de Internet para subsecuentes funciones de Servicios de Comunicacion Enriquecidos que requieren funciones de Protocolo de Iniciacion de Sesion que deben ser ejecutadas por el modulo acelerador de protocolo (542, 642), y que estan destinadas para la transmision a traves del procesador de Evolucion a Largo Plazo (560, 660), a traves del modulo redirector de paquetes de red (595, 695) incorporado en el procesador de Evolucion a Largo Plazo (560, 660);

- el mantenimiento, por el modulo redirector de paquetes de red (595, 695), de la unica conexion de Protocolo de Iniciacion de Sesion autentificada con el nucleo del Subsistema Multimedia de Internet; y

- el envfo de paquetes entrantes desde el nucleo del Subsistema Multimedia de Protocolo de Internet, recibidos a traves del procesador de Evolucion a Largo Plazo (560, 660) mediante la unica conexion de Protocolo de Iniciacion de Sesion autentificada, a traves del modulo redirector de paquetes de red (595, 695) a la pila del modulo de Protocolo de Iniciacion de Sesion (588, 688) incorporada en el procesador de Evolucion a Largo Plazo (560, 660) o al modulo acelerador de protocolo (542, 642) en el procesador de aplicacion (510, 610) del terminal movil (500, 600), como es requerido.

15s.- El metodo de la reivindicacion 11a, en el cual cuando el procesador de Evolucion a Largo Plazo (560, 660) esta preparado como Evolucion a Largo Plazo a traves de Voz e incluye un subsistema de Protocolo de Iniciacion de Sesion incorporado, comprendiendo el metodo ademas:

- cuando los paquetes de Servicios de Comunicacion Enriquecidos deben ser transmitidos a traves de la interfaz de red alternativa (515, 615) en el procesador de aplicacion (510, 610), el reenvio, por el modulo redirector de paquetes de red (595, 695), a traves del mecanismo de comunicacion del inter-procesador (550, 650), de los paquetes de Servicios de Comunicacion Enriquecidos al Daemon para la interfaz de red alternativa (515, 615) en el procesador de aplicacion (510, 610); y

- la transmision de los paquetes de Servicios de Comunicacion Enriquecidos usando el Daemon de la interfaz de red alternativa (515, 615), mientras se mantiene un unico canal autentificado.

16s.- El metodo de la reivindicacion 15s, en el cual cuando los paquetes de Servicios de Comunicacion Enriquecidos deben ser transmitidos a traves de la interfaz de red alternativa (515, 615) en el procesador de aplicacion (510, 610), comprendiendo el metodo ademas:

5

10

15

20

25

30

35

40

45

- el procesamiento de todos los mensajes del Protocolo de Iniciacion de Sesion en el procesador de aplicacion (510, 610) usando el modulo acelerador de protocolo (542, 642) del procesador de aplicacion (510, 610); y

- el envio de los paquetes de Servicios de Comunicacion Enriquecidos a un Daemon para dicha interfaz de red alternativa (515, 615) en el procesador de aplicacion (510, 610), de manera que los paquetes de Servicios de Comunicacion Enriquecidos se pueden transmitir a traves de dicha red alternativa (515, 615), a traves de la misma conexion de Protocolo de Iniciacion de Sesion autentificada establecida por la pila del modulo de Protocolo de Iniciacion de Sesion (588, 688) en el procesador de Evolucion a Largo Plazo (560, 660) y sin intercambio de datos extra entre el procesador de aplicacion (310, 410, 510, 610) y el procesador de Evolucion a Largo Plazo (560, 660).

17s.- El metodo de la reivindicacion 1a, comprendiendo ademas:

- la realizacion de llamadas de Voz a traves del Protocolo de Internet y enviar/ recibir Servicio de Mensajes Cortos a traves del Protocolo de Internet por el modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) y un subsistema del Modulo de Control/ Estado (375, 475, 575, 675) en el procesador de Evolucion a Largo Plazo (360, 460, 560, 660);

- el direccionamiento por un modulo Gestionador de Ordenes (365, 465, 565, 665), de llamadas de voz y de mensajes de Servicio de Mensajes Cortos desde un controlador de modem (305, 405, 505, 605) al modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) y/o al Modulo de Control/ Estado (375, 475, 575, 675) y los demas mensajes se pasan directamente al procesador de Evolucion a Largo Plazo (360, 460, 560, 660);

- la determinacion, por el modulo de Control/ Estado (375, 475, 575, 675), basado en la politica de radio establecida por una red o por el terminal movil (300, 400, 500, 600), de si la llamada de voz o el Servicio de Mensaje Corto se procesara por el modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) y un Motor de Voz (384, 484, 584, 684) como es requerido, o si se pasara a un modem heredado (370, 470, 570, 670) del terminal movil (300, 400, 500, 600) y se procesa por algoritmos de voz incluidos en el modem heredado (370, 470, 570, 670); y

- el direccionamiento, por el modulo Gestionador de Ordenes (365, 465, 565, 665), de la llamada de voz y los mensajes del Servicio de Mensaje Corto desde el modem heredado (370, 470, 570, 670) al modulo de Protocolo de Iniciacion de Sesion (388, 488, 588, 688) y/o al modulo de Control/ Estado (375, 475, 575, 675), y todos los demas mensajes se pasan a traves del controlador de modem (305, 405, 505, 605).
188.- El metodo de la reivindicacion 17a, comprendiendo ademas:

- la seleccion de la politica de radio para los Servicios de Comunicaciones Enriquecidos en el terminal movil (300, 400, 500, 600) en una base a una funcion por el terminal movil (300, 400, 500, 600) o por un operador de la red; y

- la determinacion de que interfaz de red (315, 415, 515, 615) usar para la funcion de Servicios de Comunicacion Enriquecidos haciendo accesible a la red o al terminal movil (300, 400, 500, 600) un Gestor de Politica de Radio (380, 480, 580, 680) para establecer los parametros o reglas para hacer la determinacion.
198.- El metodo de la reivindicacion 18, en el cual el terminal movil (300, 400, 500, 600) esta configurado para Servicios de Comunicaciones Enriquecidos, radio de Evolucion a Largo Plazo, radio heredada, y al menos una interfaz de red alternativa (315, 415, 515, 615), y para la seleccion dinamica de radio o interfaz de red (315, 360, 415, 460, 515, 560, 615, 660), comprendiendo el metodo ademas:

- la seleccion, por el Gestor de Politica de Radio (380, 480, 580, 680) de que interfaz de red (315, 415, 515, 615) usar para cada funcion de comunicacion, estando el Gestor de Politica de Radio (380, 480, 580, 680) en el procesador de Evolucion a Largo Plazo (360, 460, 560, 660) en el terminal movil (300, 400, 500, 600); y

- hacer accesible el Gestor de Politica de Radio (380, 480, 580, 680) a un operador de red o al terminal movil (300, 400, 500, 600) para establecer parametros o reglas para realizar la determinacion.