MX2011013985A - Sistema y metodo para servicio de voz en un sistema evolucionado de paquetes. - Google Patents

Abstract

Se proporciona un sistema y método para acceder a servicios de voz utilizando un equipo de usuario (UE) en un sistema de comunicación. El UE se configure para recibir un primer mensaje el cual puede incluir una indicación de sesión de audio. El método incluye la etapa de enviar un segundo mensaje en respuesta al primer mensaje, con el segundo mensaje basándose en uno o más indicadores de servicios de voz que comprenden por lo menos un valor. El segundo mensaje puede ser una respuesta que indica no seleccionar un dominio alternativo. El segundo mensaje también puede ser una respuesta no aceptable.

Description

SISTEMA Y MÉTODO PARA SERVICIO DE VOZ EN UN SISTEMA EVOLUCIONADO DE PAQUETES ANTECEDENTES DE LA INVENCIÓN La presente descripción se relaciona generalmente con un método para acceder a servicios de voz utilizando un equipo de usuario (UE) en un sistema de comunicación y más específicamente con un método para proporcionar servicios de voz en un Subsistema de Multimedia de Protocolo de Internet (IMS), y también con un elemento de red correspondiente.

Como se utiliza en la presente, el término "dispositivo" puede referirse a los términos "estación móvil" (MS) , "agente de usuario," o "equipo de usuario" (UE) el cual puede incluir dispositivos electrónicos tales como teléfonos fijos y móviles, asistentes personales digitales, computadoras portátiles o tipo laptop, teléfonos inteligentes, impresoras, máquinas de fax, televisiones, cajas de los convertidores-descodificadores, y otros dispositivos de despliegue de video, equipo de audio en casa y otros sistemas de entretenimiento en casa, sistemas de monitoreo y control caseros (por ejemplo, sistemas de monitoreo, alarma caseros y sistemas de control climático) , electrodomésticos mejorados tales como refrigeradores computarizados y dispositivos similares que tienen capacidades de comunicaciones de red. En algunas configuraciones, UE puede referirse a un dispositivo inalámbrico, móvil.

El UE también puede referirse a dispositivos que tienen capacidades similares pero que no son fácilmente transportables, tales como computadoras de escritorio, cajas de los convertidores-descodificadores , Televisores, IPTV o nodos de red.

El término dispositivo también puede referirse a un Agente de Usuario (UA) de Protocolo de Inicio de Sesión (SIP) que puede ser fijo o móvil. Cuando un UA es un nodo de red, el nodo de red puede actuar en nombre de otra función, tal como un UA o un dispositivo de linea fija, y simular o emular el UA o dispositivo de línea fija. Por ejemplo, para algunos UA, el cliente de SIP de Subsistema de Multimedia (IMS) de Protocolo de Internet (IP) que típicamente residiría en el dispositivo de hecho reside en la red y retransmite información de mensajes de SIP al dispositivo utilizando protocolos optimizados. En otras palabras, algunas funciones que tradicionalmente eran llevadas a cabo mediante un UA pueden distribuirse en la forma de un UA remoto, donde el UA remoto representa el UA en la red.

El término "UE" puede también referirse a cualquier componente de hardware o software que pueda terminar una sesión de comunicación que puede incluir, pero no se limita a, una sesión de SIP. También, los términos "agente de usuario", "UA" "equipo de usuario, "UE", y "nodo" pueden utilizarse como sinónimos en la presente. Aquellos con experiencia en la técnica podrán apreciar que estos términos pueden utilizarse indistintamente dentro de la solicitud.

Un UE puede operar en una red de comunicación inalámbrica que proporciona comunicaciones de datos a alta velocidad utilizando varias configuraciones de red y/o Tecnologías de Acceso por Radio (las RAT) . Por ejemplo, el UE puede operar de acuerdo con las tecnologías de Sistema Global para Comunicaciones Móviles (GSM) y Servicio de Radio Paquete General (GPRS) . Hoy en día, un UE puede además operar de acuerdo con Tasas de Datos Mejoradas para la Evolución de GSM (EDGE) , o GPRS Mejorado (EGPRS) o GPRS Mejorado Fase 2 (EGPRS2). Otras redes inalámbricas que los UE pueden operar incluyen pero no se limitan a CDMA, UMTS, E-UTRAN, WiMax, y WLA (por ejemplo, IEEE 802.11) . Los UE pueden también operar en entornos de red fijos tales como, redes de cable xDSL, DOCSIS, redes de Ethernet u ópticas. Algunos UE pueden ser capaces de realizar operaciones multimodo donde estos pueden operar en más de una tecnología de red de acceso ya sea en una sola tecnología de acceso de red a la vez o en algunos dispositivos utilizando múltiples tecnologías de acceso de red simultáneamente.

En sistemas de telecomunicaciones inalámbricas, el equipo de transmisión en una estación base transmite señales por toda una región geográfica conocida como una celda. A medida que la tecnología evoluciona, se ha introducido equipo más avanzado que puede proporcionar servicios que previamente no eran posibles. Este equipo avanzado puede incluir, por ejemplo, un nodo B (eNB) red de acceso de radio terrestre universal evolucionado (E-UTRAN) en lugar de una estación base u otros sistemas y dispositivos que son más altamente evolucionados que el equipo equivalente en un sistema de telecomunicaciones inalámbricas tradicional. Tal equipo avanzado o de siguiente generación puede referirse en la presente como equipo de evolución a largo plazo ( la LTE) , y una red basada en paquetes que utiliza tal equipo puede ser referida como un sistema de paquetes evolucionado (EPS) . Como se utiliza en la presente, el término "dispositivo de acceso" puede referirse a cualquier componente, tal como una estación base tradicional, eNB, u otro dispositivo de acceso de la LTE, que pueda proporcionar a un UE con acceso a otros componentes en un sistema de telecomunicaciones.

En sistemas de Proyecto de Asociación de Tercera Generación (3GPP), los servicios de voz pueden proporcionarse por un operador móvil mediante una serie de medios. Sobre la Red de Acceso por Radio GPRS/EDGE (GERAN) y la Red de Acceso por Radio Terrestre Universal (UTRAN) , por ejemplo, una infraestructura Conmutada por Circuito (de CS) puede utilizarse para proporcionar servicios de voz. De manera alternativa, sobre GERAN y UTRAN, el Subsistema de Multimedia de red central (CN) IMS- o IP puede utilizarse. En ese caso, voz sobre IP o comunicación de voz que utiliza IMS puede denominarse voz de IMS sobre PS. Además, una solución híbrida donde el CS se utiliza para proporcionar una portadora de voz y el IMS se utiliza para controlar la portadora de voz también puede soportarse, esto es conocido como Servicios Centralizados de IMS (ICS) y se define en TS 23.292 de 3GPP y TS 24.292 de 3GPP. Sobre (E-UTRAN) , el IMS puede utilizarse. En algunos casos, los servicios de voz obre red de la LTE (es decir, con el UE conectado activamente e intercambiando datos sobre una red de la LTE) puede proporcionarse utilizando un IMS .

Varios Indicadores de Servicio de Voz (VSI) se han definido para indicar bajo que circunstancias una red, área de red o celda de red en particular puede proporcionar servicios de voz. Los indicadores incluyen los siguientes valores: "Sesión de voz de IMS sobre PS soportada" (es decir, indicador de VoIMS) , "Centrado en Voz" o "Centrado en datos", y "solo voz de CS ", "solo voz de PS de IMS", ""voz de CS preferida, voz de IMS secundaria"" o "Voz de EMS preferida, voz de CS secundaria" . Los indicadores de VoIMS pueden proporcionarse por la red al UE en cada registro de ÑAS (por ejemplo, unión de EPS) y actualización de registro de ÑAS mientras que los indicadores "Centrado en Voz" o "Centrado en Datos" se encuentren dentro del UE. En algunos casos, una ausencia del indicador "Sesión de voz de IMS sobre PS soportada" puede sugerir que la red (por ejemplo un eNodoB) no se encuentra optimizada para voz. En algunos casos, sin embargo, la voz puede aún soportarse aunque puede no preferirse. La preferencia puede especificarse como una preferencia de operador, una preferencia de usuario, una preferencia de suscriptor o combinaciones de las mismas. El usuario, el suscriptor (por ejemplo, la empresa, y/o el operador pueden administrar las preferencias) . La preferencia puede aplicar por red de acceso, por ejemplo, una preferencia diferente puede existir para E-UTRAN cuando se compara a otra red de acceso tal como redes de acceso basadas en IEEE 802.11 o WIMAX. Tal preferencia puede no encontrarse asociada con cada una de las redes de acceso que el UE soporta. Los elementos de red del operador pueden percatarse de la preferencia de modo que las llamadas de voz no se entreguen o terminen utilizando una red de acceso menos preferida si alternativas preferidas existen.

En la presente descripción, los VSI pueden clasificarse de varias maneras, incluyendo: Indicadores de VoIMS proporcionados por la red (o indicadores de voz de IMS sobre PS (IMSVoPS)), los cuales son comparables con la indicación "Sesiones de voz de IMS sobre PS soportadas" anteriormente referenciada , y los ajustes de uso de un UE pueden ser iguales a los VSI "Centrado en voz" o "Centrado en Datos" anteriormente referenciados . Los UE Centrados en Voz pueden ser capaces de utilizar servicios de voz, y por lo tanto pueden intentar obtener servicios de voz independientemente de cómo los servicios puedan proporcionarse. En contraste, los UE Centrados en Datos pueden preferir tener los mejores servicios PS (Conmutados por Paquetes) posibles aun cuando los servicios de voz no se encuentren disponibles. Por ejemplo, los UE Centrados en Datos pueden preferir permanecer en E-UTRAN, aún cuando servicios de voz no se encuentren disponibles en la E-UTRAN. Los servicios de voz pueden proporcionarse para los UE Centrados en Datos dependiendo en el escenario de servicio del operador. Finalmente, los ajustes de voz de un UE pueden ser iguales a los VSI "Solo voz de CS ", "Solo voz de PS de IMS", voz de CS Preferida, Voz IMS Secundaria", o "voz de IMS Preferida, voz de CS Secundaria" . La siguiente tabla Tabla 1 resume estas convenciones de agrupamiento y nombramiento.

A medida que las redes de comunicación inalámbrica continúan evolucionando, en algunas implementaciones de red pueden existir islas de cobertura de redes tipo la LTE que residen dentro una cobertura de radio más completa proporcionada mediante GERAN y/o UTRAN. Como tal, varios mecanismos para entregar servicios de voz a un UE conectado a una red la LTE se han definido. Por ejemplo, un procedimiento de CS de reserva permite que un UE conectado a la red utilizando una primera RAT, donde la RAT proporciona solo servicios de dominio PS (Conmutado por Paquete) , para también registrarse simultáneamente con otra red que proporcione servicios de dominio de CS. El CS de reserva puede utilizarse, por ejemplo, para accionar al UE para moverse a una celda de una red que proporciona servicios de dominio de CS e iniciar llamadas de voz, cuando, al tiempo de iniciar la llamada de voz, el UE fue asociado con una celda de una red que solo proporciona servicios de dominio PS (es decir, sin servicios de dominio de CS) . El UE que inicia la llamada de voz puede encontrarse ya sea inactivo o activo en la celda de la red que solo proporciona servicios de dominio PS. El término "registrar" se ha utilizado en este documento para dos propósitos: (1) describir el acto de registrar un UA de SIP con un REGISTRADOR DE SIP, y (2) DESCRIBIR EL ACTO DE registrarse con la o las capas inferiores. En SIP, cuando un UA se registra, típicamente una petición de REGISTRO DE SIP fue transmitida mediante el UA y una respuesta de SIP 200 (OK) es recibida por el UA. De manera alternativa, el UA puede registrarse mediante otros medios. En este documento, utilizamos el término "registro de IMS" si el UA se registra con una función REGISTRADORA en un nodo o un elemento funcional que sea un nodo IMS de elemento funcional . Típicamente, el S-CSCF realiza la función de REGISTRADOR en IMS. En capas inferiores, por ejemplo, en capas de ÑAS o Estratos de Acceso, el UE se registra con la red para obtener conectividad ya sea al realizar un procedimiento de Unión a la red GPRS sobre UTRAN o GERAN, o una Unión con EPC sobre la LTE o E-UTRAN. El registro en la capa de AS también puede referirse al concepto de Actualización de Área de Enrutamiento, Actualización de Área de Rastreo (TAU) , Unión Combinada de ÑAS y TAU Combinada. Debe ser claro a partir del contexto que "registro" aplica, de principio a fin en este documento .

Específicamente, para el caso donde el operador despliega la LTE de manera incrementada y no ha desplegado IMS, los procedimientos de CS de reserva permiten a un UE: unirse simultáneamente a la red central PS (es decir, el Núcleo de Paquete Evolucionado (EPC) de 3GPP) y el dominio de CS (es decir, el Centro de Conmutación Móvil (MSC) ) , al realizar un procedimiento de Unión combinado en la unión inicial o un procedimiento de Actualización de Área de Rastreo combinado en caso de movilidad; intercambio de servicios de datos sobre la LTE mientras que es capaz de recibir notificaciones de llamada de CS entrantes para activar el UE para realizar una transferencia a otra RAT (GERAN o UTRAN) y continuar el establecimiento de la llamada de CS utilizando el dominio de CS; e intercambio de servicios de datos sobre la LTE a la vez que es capaz de establecer llamadas de CS salientes al transferirlas sobre otra RAT (GERAN o UTRAN) y realizar el establecimiento de la llamada de CS utilizando el dominio de CS .

Un UE puede configurarse para soportar servicio de voz en un número de maneras sobre una LTE. Por ejemplo, el UE puede soportar soluciones de voz sobre IP no proporcionado por el operador de red (por ejemplo, Skype, CS de reserva, IMS o Voz sobre la LTE mediante Acceso Genérico (VoLGA) ) . Como se describe en lo anterior, existe un número de etiquetas de mensaje para definir si el IMS se encuentra disponible sobre una LTE particular (por ejemplo, VoIMS, SRVCC) . Además, un UE puede configurarse para seleccionar una solución de voz inicial o preferida basándose en un árbol lógico predeterminado. Si la solución de voz inicial no se encuentra disponible, el UE puede configurarse para reaccionar basándose en reglas lógicas predeterminadas .

Cuando una sesión terminada móvil se presenta a la red de IMS (por ejemplo, incluyendo un nodo como el Servidor de Aplicación (AS) de IMS) , el nodo determina como elegir un dominio de destino para la entrega de llamada (es decir, dominio de CS o dominio de PS) . Un dominio de destino puede definirse como resultado del registro de IMS sobre la red de la LTE o la E-UTRA , o al configurarse con una dirección de destino de CS, donde la dirección de destino de CS se proporciona, por ejemplo, como resultado de un procedimiento de unión combinado. En algunos casos, al registrarse, si el UE descubre que el VoIMS o Continuidad de Llamada de Voz de Radio Única (SRVCC) no son soportados, el UE puede no incluir una indicación tal como una etiqueta de característica de "audio" o un Identificador de Servicio de Comunicación de IMS (ICSI) (por ejemplo, la Telefonía de Multimedia (MMTel ) ) en su información de registro. Sin embargo, debido a que una etiqueta de característica de "audio" puede describir más servicios que solo voz de duplexión completa bidireccional , la ausencia de la etiqueta de característica de "audio" puede negar al UE el acceso a muchos más servicios tales como transmisión continua de música o radio sobre IP. De manera similar, la ausencia de un MMTel del ICSI puede negar servicios particulares (por ejemplo, transferencia de archivos, de acuerdo con especificaciones MMTel. Tener en cuenta que el acrónimo "AS" se ha utilizado en este documento para dos propósitos: (1) identificar el nodo o elemento funcional "servidor de aplicación", y (2) identificar el "estrato de acceso". En SIP, cuando un UA solicita un servicio, y otro UA presenta o proporciona el servicio, típicamente un mensaje de petición de SIP se transmite mediante el UA a otro UA. El otro UA puede alojarse en un nodo o elemento funcional llamado "servidor de aplicación" en IMS. Típicamente, un I-CSCF o S-CSCF o E-CSCF enruta una petición a un servidor de aplicación. Debe ser claro a partir del contexto que el acrónimo "AS" aplica, de principio a fin en este documento.

Generalmente, el AS de IMS, después de recibir un mensaje de registro de IMS, no se encuentra al tanto de si el acceso de la LTE puede soportar o no los servicios de voz. El AS de IMS puede entonces depender en otra información en lugar de la información contenida en el mensaje de registro de IMS para determinar cómo la sesión (incluyendo voz) debe enrutarse o si se le debe dar al UE la opción de determinar cómo debe enrutarse la sesión (incluyendo voz). Si al UE se le da la opción de determinar cómo la sesión (incluyendo voz) debe enrutarse, el UE determina cómo responder al recibir una INVITACIÓN de SIP con una oferta para una llamada terminada móvil o una que incluya voz. En la presente descripción el AS de IMS puede ser un Servidor de Aplicación de Servicio de Centralización y Continuidad (SCC AS) .

En vista de los estándares cambiantes, un UE puede recibir una indicación de que ciertos servicios son soportados mientras se encuentra conectado a una RAT, por ejemplo, una indicación "Sesión de voz de IMS sobre PS soportada" cuando se conecta a GPRS o la LTE/EPC/E-UTRAN recibida al realizar la Unión, actualización de área de Rastreo, Actualización de Área de Enrutamiento o procedimientos de unión combinados. Debido a realizar un procedimiento de actualización de área de registro, la "indicación de que ciertos servicios son soportados" puede cambiar. Como resultado, si el UE recibe servicios (como se proporcionan para el suscriptor) del dominio IMS y también se ha registrado, el UE puede no ser capaz de obtener algunos servicios ofrecidos por el dominio IMS y autorizado como parte de la suscripción en la red de acceso dependiendo en el valor presente de la "indicación de que ciertos servicios son soportados " .

En algunas instancias, los problemas se relacionan a la entrega de servicios (por ejemplo, una llamada de voz Terminada Móvil) al UE dependiendo en como los servicios se proporcionen al UE, el valor del indicador de VoIMS, y el uso del UE y ajustes de voz. En particular, el problema puede aplicar a escenarios donde el UE puede recibir los servicios sobre una variedad de RAT y soluciones de voz, y la RAT que el UE prefiere (por ejemplo, la RAT determinada para ser preferible basándose en políticas en el UE) no soporta el servicio/característica requerida. Tener en cuenta que, en algunos casos, la RAT que el UE prefiere nunca se define.

Por ejemplo, un UE puede encontrarse registrado con IMS, sobre la LTE o utilizando E-UTRAN en un área donde el VoIMS no se encuentra disponible como se indica mediante el indicador de VoIMS. De manera similar, la SRVCC puede no encontrarse disponible; la bandera de SRVCC puede no encontrarse establecida. Si el indicador de VoIMS no es soportado, puede que ninguna indicación se haga disponible por la red o se haga disponible por capas inferiores en el UE. En ese caso, el UE puede ser incapaz para determinar antes de realizar el registro de IMS, o después del registro de IMS pero antes de establecer una sesión de voz de IMS (VoIMS) , si el VoIMS se soporta. La ausencia de los indicadores de VoIMS puede implicar por defecto que el VoIMS es o no soportado.

Como tal, en el registro de IMS, el UE puede ser incapaz para indicar a la infraestructura del IMS si el UE intenta utilizar el IMS para servicios de voz. Además, aunque asumiendo que el UE se establece para indicar al IMS (por ejemplo, en el registro) si este intenta utilizar el IMS para servicios de "voz" o solo para servicios "sin voz" (por ejemplo cuando el UE desea servicio de voz y sin voz pero el indicador de VoIMS no se encuentra presente o indica que el VoIMS no se encuentra disponible) , puede ser poco claro como las llamadas Terminadas Móvil entrantes al IMS son entregadas cuando el UE se encuentra reteniendo en una RAT de PS (por ejemplo, la LTE) , o cómo las llamadas pueden enrutarse al UE sobre el dominio de CS . Por consiguiente, puede ser poco claro en cuanto a si las llamadas se enrutan al UE utilizando el IMS sobre la RAT de PS en el dominio de PS o si las llamadas se enrutan a través del dominio de CS .

En un UE donde la pila del IMS o SIP del UE no tiene acceso a las indicaciones que fueron proporcionadas por el AS con respecto al valor del indicador de VoIMS, el UE no sabe si el UE puede recibir o iniciar voz de IMS en ciertas áreas. En algunos casos, la pila del IMS o SIP en el UE puede registrarse primero con IMS con la intención de utilizar el IMS para sesiones de VoIMS y después el AS puede realizar a través del indicador de VoIMS que el VoIMS no se encuentra disponible. En ese caso, puede ser difícil para la pila del IMS o SIP en el UE para indicar a la red que las llamadas no deben entregarse sobre el IMS, y la infraestructura de red central no puede distinguir entre estos dos casos. Como tal, cuando la capa de AS/NAS de un UE registrado al IMS sabe a través del indicador de VoIMS que las llamadas de voz del IMS no son posibles y existe una llamada entrante siendo dirigida al UE sobre el IMS, la pila de IMS en el UE puede aún aceptar la llamada de voz entrante, por ejemplo, debido a que la pila de IMS no se encuentra estrechamente integrada con la pila de AS/NAS y la pila de IMS no tiene la indicación de VoIMS. Este problema también puede surgir cuando el UE realiza una operación incorrecta en aceptar la llamada entrante sobre el IMS .

Un problema adicional puede surgir en casos donde un UE tiene más de una solución de voz en ejecución (es decir, diferentes aplicaciones: ejemplos son VoLGA e IMS). Una solución de voz puede proporcionarse por el operador (OpVoice) , y una o más soluciones pueden proporcionarse por otras entidades mediante el IMS (por ejemplo, voz empresarial proporcionada por la empresa), o AppVoice y AppIMS. En ese caso, para acceder a los servicios de OpVoice, el UE puede implementar soluciones actuales (por ejemplo, aquellas definidas en 3GPP) para la selección del IMS, CS de reserva, y cualesquier otras soluciones posibles (por ejemplo, VoLGA. Para acceder al AppVoice, el UE puede conectarse a la infraestructura de AppIMS. La decisión de si conectarse al AppIMS puede no encontrarse basada en las mismas reglas/mecanismos utilizados para el OpVoice, debido a que, si el UE decide conectarse al AppIMS solo cuando el indicador de VoIMS de la capa de transporte se encuentra disponible y la red indica que el IMS se encuentra disponible, entonces el UE puede no intentar el registro del IMS para otros servicios. Si el UE en cambio se registra para el AppVoice con el AppIMS, los problemas de enrutamiento en llamadas de AppVoice entrantes pueden necesitar resolverse debido a que el UE puede no encontrarse en un área donde el indicador de VoIMS declara que las llamadas de voz del IMS no son soportadas (por ejemplo, debido a QoS) .

En otras palabras, pueden surgir problemas cuando el UE 1) se conecta a la red y selecciona la solución de voz para el OpVoice como se especifica actualmente en 3GPP (es decir, basándose en el indicador de VoIMS, el éxito o el fallo del registro combinado de CS de reserva/TAU, etc., o 2) el UE se conecta al ApplMS para el AppVoice basándose, por ejemplo, en políticas proporcionadas al UE mediante el proveedor de AppVoice. Aún si el indicador de VoIMS se encuentra disponible e indica que no es posible una voz de IMS, o que el VoIMS no se encuentra disponible, el UE puede registrarse para el AppVoice con el ApplMS si las políticas indican que el UE deba hacerlo. El problema también puede surgir cuando el UE 3) se encuentra en un área donde el indicador de VoIMS declara que la voz de IMS no es soportada, o 4) cuando la solución de AppVoice no se encuentra integrada con otras soluciones de voz en el UE (por ejemplo, VoLGA, de CS de reserva, etc.), y por consiguiente el UE no puede "reservar" a otras soluciones para proporcionar el AppVoice al UE cuando la voz de IMS no se encuentra disponible. La pila de AppVoice puede encontrarse separada de la pila de OpVoice en el UE.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Para un entendimiento más completo de esta descripción, ahora se hace referencia a la siguiente descripción breve, tomada en relación con los dibujos anexos y descripción detallada, en donde los números de referencia similares representan partes similares.

La Figura 1 es un diagrama de flujo de un comportamiento del UE cuando realiza una unión de EPS/IMSI no combinada donde "voz de PS de IMS Preferida con voz de CS como secundaria" se especifica para el UE; la Figura 2 es un diagrama de flujo de un comportamiento de UE cuando realiza una unión de EPS/IMSI combinada, con un ajuste de "voz de PS de IMS Preferida, voz de CS Secundaria" se especifica para el UE; la Figura 3 es un diagrama de flujo de un comportamiento de UE con el ajuste de: "voz de CS Preferida, voz de PS de IMS Secundaria" se especifica para el UE; la Figura 4 es un diagrama de flujo de comportamiento de UE con el ajuste de "Solo voz de PS de IMS" se especifica para el UE; la Figura 5 es un diagrama de flujo del comportamiento de UE con el ajuste "Solo voz de CS" se especifica para el UE. la Figura 6 es una ilustración que muestra una arquitectura lógica de Control de Política y Control de Facturación (PCC) general en una configuración sin itinerancia ; la Figura 7 ilustra un flujo de mensajes ejemplar para realizar un procedimiento de unión que involucra la interacción con un PCC; la Figura 8 es una ilustración de un mapa de componente de red ejemplar que muestra componentes de una red de VoLGA; la Figura 9 ilustra un flujo de mensajes para un UE para registrarse con una red de VoLGA; la Figura 10 ilustra un flujo de mensajes para establecer una conexión entre un UE y una red de VoLGA para iniciar una llamada originada Móvil de VoLGA; la Figura 11 ilustra un flujo de mensajes para establecer una conexión entre el UE y una red de VoLGA para una llamada terminada Móvil; la Figura 12 es una ilustración de una secuencia de mensajes para notificar a una red de la capacidad del UE; la Figura 13 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, en donde la red no soporta un servicio o característica deseados por el UE y el UE se registra para servicios sin voz ; la Figura 14 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, donde el UE no toma en cuenta los indicadores del servicio o funcionamiento proporcionados por la red; la Figura 15 es un dibujo esquemático que muestra una vista diagramática de un Comparador (función de Selección de Dominio de Acceso Terminal (T-ADS) ) ; la Figura 16 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, en donde el UE incluye una etiqueta de característica utilizada para accionar el AS del IMS para incluir el SDP- de CS cuando y si el UE ha tenido un registro exitoso para el CS de reserva; la Figura 17 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, en donde el UE inspecciona el indicador de VolMS e indica que la entrega de llamada debe tomar lugar sobre una solución de OpVoice; la Figura 18 ilustra comunicaciones inalámbricas del sistema que incluye una modalidad del agente de usuario; la Figura 19 muestra un diagrama de bloque del agente de usuario incluyendo un procesador de señal digital (DSP) y una memoria; la Figura 20 ilustra un entorno de software que puede implementarse mediante un procesador de un agente de usuario; y la Figura 21 ilustra un ejemplo de un sistema que incluye un componente de procesamiento adecuado para implementar un método para proporcionar continuidad para sesiones que hacen la transición entre redes.

La presente descripción se relaciona generalmente con un método para acceder a servicios de voz utilizando un equipo de usuario (UE) en un sistema de comunicación y más específicamente con un método para proporcionar servicios de voz en un Subsistema de Multimedia de Protocolo de Internet (IMS) , y también con un elemento de red correspondiente.

Los diversos aspectos de la descripción ahora se describen con referencia a los dibujos anexos, en donde números similares se refieren a elementos similares o correspondientes de principio a fin. Debe entenderse, sin embargo, que los dibujos y la descripción detallada en relación con esto no se pretenden para limitar el tema reivindicado a la forma particular descrita. Más bien, la intención es cubrir todas las modificaciones, equivalentes, y alternativas que caen dentro del espíritu y alcance del tema reivindicado .

Como se utiliza en la presente, los términos "componente", "sistema" y similares se pretenden para referirse a una entidad relacionada con una computadora, ya sea hardware, una combinación de hardware y software, software o software en ejecución. Por ejemplo, un componente puede ser, pero no se limita a ser, un proceso que se ejecuta en un procesador, un procesador, un objeto, un ejecutable, una cadena de ejecución, un programa, y/o una computadora. A manera de ilustración, tanto una aplicación que se ejecuta en una computadora como la computadora pueden ser un componente. Uno o más componentes pueden residir dentro de un proceso y/o cadena de ejecución y un componente puede ubicarse en una computadora y/o distribuirse entre dos o más computadoras.

La palabra "ejemplar" se utiliza en la presente para significar servir como un ejemplo, instancia, o ilustración. Cualquier aspecto o diseño descrito en la presente como "ejemplar" no necesariamente debe interpretarse como preferido o ventajoso sobre otros aspectos o diseños.

Además, el tema descrito puede implementarse como un sistema, método, aparato, o artículo de fabricación utilizando programación estándar y/o técnicas de ingeniería para producir software, firmware, hardware, o cualquier combinación de los mismos para controlar una computadora o dispositivo basado en procesador para implementar aspectos detallados en la presente. El término "articulo de fabricación" (o de manera alternativa, "producto de programa de computadora") como se utiliza en la presente se pretende para abarcar un programa de computadora accesible desde cualquier dispositivo, portador, o medios legibles por computadora. Por ejemplo, medios legibles por computadora pueden incluir pero no se limitan a dispositivos de almacenamiento magnéticos (por ejemplo, disco duro, disco flexible, cintas magnéticas, y similares), discos ópticos (por ejemplo, disco compacto (CD) , disco versátil digital (DVD), y similares), tarjetas inteligentes, y dispositivos de memoria flash (por ejemplo, tarjeta, barra, y similares) . Adicionalmente, debe apreciarse que la onda portadora puede emplearse para portar datos electrónicos legibles por computadora tales como aquellos utilizados en transmitir y recibir correo electrónico o para acceder a una red tal como la Internet o una red de área local (LAN) . Por supuesto, aquellos con experiencia en la técnica reconocerán que muchas modificaciones pueden realizarse a esta configuración sin apartarse del alcance y espíritu del tema reclamado.

La presente invención proporciona un método para acceder a servicios de voz utilizando un equipo de usuario en un sistema de comunicación que soporta por lo menos uno de un dominio conmutado por paquete y un dominio conmutado por circuito. El método comprende recibir un primer mensaje en el UE, el primer mensaje incluye una indicación de sesión de audio. El método además comprende enviar un segundo mensaje en respuesta al primer mensaje, el segundo mensaje basándose en uno o más indicadores de servicios de voz que comprende por lo menos un valor. El primer y segundo mensajes pueden ser mensajes de SIP y pueden ser por lo menos un mensaje de petición de SIP y un mensaje de respuesta de SIP.

El presente sistema además proporciona un método para acceder servicios utilizando un equipo de usuario (UE) . El UE se establece para requerir un primer servicio. El método incluye las etapas de establecer una sesión para comunicar datos entre el UE y una red utilizando una primer celda de red, y recuperar un listado de por lo menos un segundo servicio soportado por la primera celda de red. Cuando por lo menos uno de los segundos servicios soportados por la primera celda de red no es igual a por lo menos uno de los primeros servicios requeridos por el UE, el método incluye transmitir un mensaje a la red indicando que el primer servicio requerido por el UE no es soportado.

En varios usos de red, los varios elementos de red pueden incluir una o más entidades de SIP. Una entidad de SIP puede incluir un Proxy de SIP o un Servidor de SIP, por ejemplo. Algunas entidades de SIP se proporcionan típicamente con un UA y pueden operar en dos formas: 1) como un Cliente de Agente de Usuario (UAC) que genera mensajes de petición hacia los servidores; y 2) como un Servidor de Agente de Usuario (UAS) que recibe mensajes de petición, los procesa y genera respuestas adecuadas. En algunos escenarios de aplicación, un solo UA puede funcionar tanto como una entidad de SIP (por ejemplo, un dispositivo UE) o como un nodo de red .

En una implementación, el SIP utiliza seis tipos de peticiones: INVITE: Indica que un usuario o servicio es invitado para participar en una sesión (nota: el término sesión y sesión de llamada en ocasiones se utilizan intercambiablemente) . ACK - Confirma que el cliente ha recibido una respuesta final a una petición INVITE. BYE -Termina una sesión y puede enviarse ya sea mediante el que llama o al que le llaman. CANCEL - Cancela una petición previa enviada por el UE . OPTIONS - Consulta las capacidades de los UE. REGISTER - Registra la dirección listada en el Para: campo de encabezado con un servidor de SIP. Debido a que el SIP se establece para evolucionar, un receptor puede en ocasiones recibir un método de petición que no reconoce. Tal petición puede designarse como un método o petición DESCONOCIDO.

En respuesta a las peticiones, el SIP utiliza las siguientes categorías de respuestas: Mensajes Informativos lxx, Respuesta Exitosa 2xx, Respuestas de Redirección 3xx, Respuestas de Fallo de Petición 4xx, Respuestas de Fallo de Servidor 5xx, y Respuesta de Fallo General 6xx.

Los mensajes de SIP se proporcionan generalmente utilizando una estructura de mensajes estandarizada. La estructura consiste de una porción de línea de comando que identifica la línea inicial (línea de petición en solicitudes y línea de estado en respuestas), una porción de encabezado que identifica uno o más campos de encabezado que transmite varias piezas de información, y uno o más cuerpos de mensaje que pueden proporcionarse en la porción de cuerpo de mensaje de un mensaje de SIP. Un cuerpo de mensaje es operable para mantener contenido tal como texto simple, imágenes codificadas, o cualquier información que pueda presentarse en un Lenguaje de Marcado tal como un Lenguaje de Marcado extensible (XML) , Lenguaje de Marcado de Hiper exto (HTML) , etc. Cada cuerpo de mensaje (parte) se describe utilizando campos de encabezado tales como Contenido-Disposición, Contenido-Codificación, y Contenido-Tipo, que cada uno proporciona información de los contenidos del mensaje de SIP. En algunas implementaciones , el valor de un campo de encabezado Contenido-Tipo es un tipo de Extensión de Correo de Internet Multi-Propósito (MIME) . IETF RFC 3261 proporciona descripción adicional de una implementación de un SIP, por ejemplo. En algunas implementaciones de sistema, una entidad de SIP se adhiere a varias especificaciones de 3GPP tales como TS 23.228 de 3GPP y TS 24.229 de 3GPP.

Uno o más nodos de red o elementos de red pueden comprender una infraestructura de núcleo o red central y pueden ser referidos como entidades de SIP. Por ejemplo, los nodos de red pueden ejemplificar nodos de Función de Control de Sesión de Proxy-Llamada (P-CSCF) , nodos CSCF de Servicio o S-CSCF, nodos de Interrogación CSCF o I-CSCF, nodos de Función de Control de Puerto de Enlace de separación (BGFC) , nodos de Función de Control de Puerto de Enlace de Medios (MGFC) , nodos de Servidor de Suscriptor Residencial (HSS) , nodos de AS de IMS o Servidor de Aplicación, y similares. Como se describe en lo anterior, los nodos así como también los dispositivos de UE extremos pueden emplear el SIP como un protocolo de comunicación para control de sesión, es decir, configurar y deshacer sesiones de comunicación. Por consiguiente, los nodos de red y los dispositivos de UE pueden colectivamente ser referidos como "entidades de SIP" , o más generalmente, "entidades de protocolo de comunicación", que se encargan de enviar y recibir mensajes de protocolo de comunicación adecuados (por ejemplo, mensajes de SIP) para efectuar varios servicios, por ejemplo, VCC, PTT, PoC, Servicios de Emergencia, ICS, etc.

Los servicios centralizados de IMS (ICS) permiten a los servicios proporcionados a un usuario final ser alojados dentro de la red de IMS. Los servicios pueden ofrecerse a suscriptores que solo tienen PS disponible para señalización o en casos donde sea más deseable ofrecer voz sobre una portadora de CS . Para los ICS, la señalización de control de llamada y servicio puede realizarse mediante el canal de control de SIP sobre la parte de punto de referencia Gm desde el dominio PS mientras que, por ejemplo, la voz utiliza una parte portadora de CS tradicional del dominio de CS . Para proporcionar una gama completa de servicios, la red y el UE pueden ser capaces de realizar ambas transmisiones de voz y datos al mismo tiempo (de otra manera, el canal de control de SIP puede perderse) .

En algunos usos de red, los ICS incluyen un nodo SCC AS o SCC AS. El SCC AS puede configurarse para proporcionar la Selección de Dominio de Acceso a Terminal (TADS) descrito según TS 23.292 de 3GPP y TS 23.237 de 3GPP para seleccionar el destino correcto para una llamada terminada móvil . La selección del destino puede incluir una determinación del tipo de acceso que el UE se encuentra utilizando o requiere. Como tal, un UE que es capaz de ICS y de CS de reserva puede haberse registrado mediante IMS y también registrarse en el MSC El SCC AS puede elegir utilizar la información de destino asociada con cualquiera de estos registros como destinos a los cuales la llamada puede entregarse.

En algunos usos de red, los ICS no se incluyen y una Desviación de Comunicación (CDIV) AS o Servicio de Aplicación de Telecomunicación (TAS) se incluye. La CDIV AS puede configurarse para proporcionar una desviación de comunicación basada en reglas como se describe según TS 24.604 de 3GPP para seleccionar el destino correcto para una llamada terminada móvil. La selección del destino puede incluir una determinación del tipo de acceso que el UE se encuentra utilizando o requiere. Como tal, un UE que es capaz de una CDIV puede haberse registrado mediante el IMS y también registrarse en el MSC. La CDIV AS puede destinar la comunicación o componentes de comunicación (por ejemplo, solo el componente de voz) al UE que utiliza cualquiera de estos destinos. Una CDIV AS puede no ser capaz de destinar solo componentes de la comunicación, en cuyo caso uno o más nodos en la red de comunicación se hacen cargo de transmitir solo medios adecuados para transportar sobre el CS (por ejemplo, voz, mensajería) sobre el dominio de CS. La CDIV AS se encuentra basada en reglas y las reglas pueden configurarse. Las reglas se expresan en una Política Común XML, por ejemplo según IETF RFC 4745 u OMA XDM o TS 24.623 de 3GPP. Las reglas pueden administrarse utilizando la interfaz Ut y el protocolo XCAP. Cuando se establece la CDIV AS con reglas que identifican el destino en ciertas condiciones se cumplen, una comunicación puede redirigirse como se especifica en TS 24.604 de 3GPP. 1) Para redirigir una comunicación a, por ejemplo, una dirección servida por el dominio de CS si la última red de acceso conocida que el UE ha utilizado para comunicaciones coincide con una red de acceso indicada en una regla, tal regla tendría que proporcionarse. 2) Para redirigir una comunicación a, por ejemplo, una dirección servida por el dominio de CS si la red (por ejemplo, nodos en la red de comunicación que soportan PCC) indica que el UE se encuentra unido a una red de acceso que coincide con una red de acceso indicada en una regla, tal regla tendría que proporcionarse. 3) Para redirigir una comunicación a, por ejemplo, una dirección servida por el dominio de CD si la (última conocida o determinada por PCC) red de acceso indica que el UE se encuentra unido a una red de acceso la cual no es capaz de soportar la voz de IMS y una regla indica que en tal caso la comunicación necesita redirigirse a una dirección servida por una red de acceso que soporte los medios de voz (por ejemplo, un dominio de CS) , tal regla tendría que proporcionarse. 4) Para redirigir una comunicación, por ejemplo, una dirección servida por el dominio de CS si el UE indica que no es capaz de recibir una voz de IMS o PS sobre la red de acceso presente (por ejemplo, al indicar medios de voz de CS en el SDP (véase ietd draft-ietf-mmusic-sdp-cs ) o un mensaje de SIP, por ejemplo, un mensaje de SIP en respuesta a una petición de INVITE, y una regla indica que en tal caso la comunicación necesita redirigirse a una dirección servida por una red de acceso capaz de voz IMS o capaz de medios de voz de CS (como se indica en el SDP (por ejemplo, dominio de CS) , tal regla tendría que proporcionarse. Las porciones de condición de las reglas e emplificadas anteriormente pueden combinarse en varias formas, junto con otras condiciones (por ejemplo, otras condiciones como se especifica en TS 24.604 de 3GPP) . Una ventaja adicional de este procedimiento es que una CDIV AS puede proporcionarse con una preferencia, por ejemplo, la preferencia donde los medios de voz se entregan.

En situaciones donde la red no soporte la capacidad de tener ambas interfaces de CS y Gm activas al mismo tiempo, II puede utilizarse. II es una interfaz o punto de referencia entre el UE y la red, y puede utilizarse en casos donde algunas restricciones (por ejemplo, la ausencia de un punto de referencia Gm o falta de soporte para el Modo de Transferencia Dual (DTM) previene el uso del canal de control de SIP con la portadora de SC de manera concurrente.

En algunas redes, una funcionalidad PCC se ha introducido para varias redes incluyendo redes de Núcleo de Paquetes Evolucionado (EPC) y GPRS (que incluyen, por ejemplo, GERAN/UTRAN) . La funcionalidad de PCC puede incluir una Función de Aplicación de Política y Facturación (PCEF), una Función de Vinculación de Portadora y de Reporte de Eventos (BBERF) , una Función de Reglas de Política y Facturación (PCRF) , una Función de Aplicación (AF) , un Sistema de Facturación en Línea (OCS) , un Sistema de Facturación Fuera de Línea (OFCS) y un Repositorio de Perfil de Suscripción (SPR) . La arquitectura de PCC puede extender la arquitectura de la CAN de IP (por ejemplo, la red central de GPRS o de EPC) , donde la Función de Aplicación de Política y Facturación es una entidad funcional en el nodo de Puerto de Enlace que implementa el acceso de IP a la PDN.

Las Figuras 1 a 5 son ilustraciones de varios casos de uso que muestran las acciones de UE requeridas para diferentes combinaciones de un indicador de VoIMS de la red y los ajustes de uso del UE.

La Figura 1 es un diagrama de flujo de un comportamiento de UE cuando se realiza una unión de EPS/IMSI no combinada donde "Voz de PS de IMS preferida con Voz de CS como secundaria" se especifica para el UE. En la etapa 10 el UE se establece en Voz de IMS preferida, con voz de CS secundaria. En la etapa 12 el UE inicia una procedimiento unido de EPS (como se muestra, el procedimiento de unión es no combinado) y en la etapa 14 el UE verifica en busca de una indicación de soporte de voz de IMS de la red. Si se soporta, el UE utiliza la voz de IMS en la etapa 16 y puede regresar a la etapa 14 después de realizar una Actualización de Área de Rastreo (TAU) . Sin embargo, si la voz de IMS no se soporta, el UE realiza una TAU combinada para el CS de reserva en la etapa 18. Si es exitosa, el UE utiliza los servicios de voz puestos a disposición como resultado del CS de reserva en la etapa 20. Sin embargo, si el CS de reserva falla, el UE verifica sus propios ajustes para determinar si es centrado en voz o centrado en datos en la etapa 22. Si es centrado en datos, el UE permanece en la RAT actual en la etapa 24. Sin embargo, si el UE es centrado en voz, este vuelve a seleccionar una RAT alternativa en la etapa 26.

La Figura 2 es un diagrama de flujo de un comportamiento de UE cuando realiza una unión de EPS/IMSI combinada, con un ajuste de "voz de PS de IMS preferida, voz de CS Secundaria" especificada para el UE. En la etapa 30, el UE se establece para preferir la voz de PS de IMS con la Voz de CS como secundaria. En la etapa 32, el UE inicia un procedimiento de unión de EPS/IMSI combinado y verifica para una Indicación soportada de sesión de Voz de IMS sobre PS de la Red. En la etapa 34, si la unión combinada es aceptada y la voz de PS de IMS no es soportada, el UE utiliza un CS de reserva para establecer una conexión de voz. Sin embargo, si la Voz de PS de IMS es soportada (sin importar si la unión combinada falló o fue aceptada) , el UE utiliza el servicio de voz de IMS en la etapa 36. Si la unión combinada falló y la Voz de PS de IMS no es soportada, el UE verifica sus ajustes para una preferencia para comunicaciones centradas en voz o centradas en datos en la etapa 38. Si es centrado en datos, el UE permanece en la RAT actual en la etapa 40. Sin embargo, si es centrada en voz, el UE vuelve a seleccionar a otra RAT para acceder a servicios de voz en la etapa 42.

La Figura 3 es un diagrama de flujo de un comportamiento de UE con el ajuste de "Voz de CS Preferida, Voz de PS de IMS Secundaria" especificada para el UE. En la etapa 50, el UE se establece en Voz de CS preferida, Voz de PS de IMS secundaria. En la etapa 52, el UE inicia un procedimiento de unión de EPS/IMSI combinado. Si es exitoso, el UE utiliza un CS de reserva en la etapa 54. Si no es exitoso, el UE verifica para una Indicación Soportada por Voz de IMS de la red en la etapa 56. Si son soportados, el UE utiliza servicios de voz de IMS en la etapa 58 y realiza una TAU. Si no son soportados, el UE verifica sus ajustes para determinar si es centrado en voz o en datos en la etapa 60. Si es centrado en datos, el UE permanece en la RAT actual en la etapa 62. Si es centrado en voz, el UE vuelve a seleccionar otra RAT en la etapa 64.

La Figura 4 es un diagrama de flujo de un comportamiento del UE con el ajuste de "Solo Voz de PS de IMS" especificada para el UE. En la etapa 70, el UE se establece en solo voz de PS de IMS. En la etapa 72 el UE inicia el procedimiento de unión de EPS y en la etapa 74 el UE verifica para una indicación de soporte de voz de IMS de la red. Si se soporta, el UE utiliza la voz de IMS en la etapa 76 y puede regresar a la etapa 74 después de realizar una Actualización de Área de Rastreo (TAU) . Sin embargo, si la voz de IMS no se soporta, el UE verifica sus propios ajustes para determinar si es centrado en voz o centrado en datos en la etapa 78. Si es centrado en datos, el UE permanece en la RAT actual en la etapa 80. Sin embargo, si el UE es centrado en voz, este vuelve a seleccionar una RAT alternativa en la etapa 82.

La Figura 5 es un diagrama de flujo del comportamiento de UE con el ajuste de "Solo Voz de CS" especificada para el UE. En la etapa 90, el UE se establece en solo Voz de CS. En la etapa 92, el UE inicia un procedimiento de unión de EPS/IMSI combinado. Si es exitoso, el UE utiliza un CS de reserva en la etapa 94. Si no es exitoso, el UE verifica sus ajustes para determinar si es centrado en voz o en datos en la etapa 96. Si es centrado en datos, el UE permanece en la RAT actual en la etapa 98. Si es centrado en voz, el UE vuelve a seleccionar otra RAT en la etapa 100.

La Figura 6 es una ilustración que muestra una arquitectura lógica de PCC general en una configuración sin itinerancia. La PCRF 102 se encuentra en comunicación con el SPR 104, la AF 106, la BBERF 108 y el Puerto de Enlace 110 (incluyendo la PCEF 112). El Puerto de Enlace 110 se encuentra en comunicación tanto con el OCS 116 como el OFCS 114. El OCS 116 proporciona un Control 118 de Crédito Basado en Flujo de Datos de Servicio. En la arquitectura de PCC ejemplar, la AF 106 proporciona servicios a los UE (por ejemplo, la AF 106 puede ser un servidor de IMS) .

Al unirse a un EPC a través de la LTE, puede existir una interacción con el PCC como se ilustra en la Figura 7. La Figura 7 ilustra un flujo de mensajes ejemplar para realizar un procedimiento de unión que implica interacción con un PCC. En particular, las etapas indicadas por los elementos 130, 132, y 134 todos involucran una interacción con la PCRF en la arquitectura de PCC. El PCC puede interactuar con la red central durante la unión a GERA /UTRAN y la red central puede interactuar con el PCC para vigilar las portadoras en la TAU de la LTE, y el PCC puede interactuar con la red central de GPRS en la actualización de área de enrutamiento .

Cuando una aplicación en la red requiere portadoras específicas con QoS para proporcionar un servicio (por ejemplo, IMS que requiere una portadora capaz de portar voz para proporcionar al VolMS) , el IMS interactúa con el PCC para solicitar tal portadora. A su vez, el PCC interactúa con el EPC (para la LTE) o la red central de GPRS (para GERA /UTRA ) para establecer las portadoras apropiadas.

En voz sobre la LTE mediante un Acceso Genérico (VoLGA) , un operador puede reutilizar las entidades de dominio de CS existentes (por ejemplo, MSC/VLR) que controlan el establecimiento de servicios de CS bajo cobertura de E-UTRA para proporcionar al IMS. El Controlador de Red de Acceso de VoLGA (VA C) habilita al UE para acceder al MSC/VLR utilizando conectividad de IP genérica proporcionada mediante el EPS. El VANC puede conectarse al MSC/VLR utilizando una interfaz-A ("VoLGA modo-A") o la interfaz Iu- de CS ("VoLGA modo-Iu"). Desde el punto de vista del EPS, el VANC se observa como una Función de Aplicación.

La Figura 8 es una ilustración de un mapa de componente de red ejemplar que muestra componentes de la red de VoLGA. En la arquitectura de VoLGA modo-A, el VANC en la Red Móvil Terrestre Publica Residencial (HPLMN) se conecta al MSC/VLR utilizando la interfaz-A ("VoLGA modo-A") como se muestra mediante la conexión 140 en la Figura 8. En la arquitectura de VoLGA modo Iu, sin embargo, el VANC en la HPLMN puede encontrarse conectado al MSC/VLR utilizando la interfaz Iu- de CS ("VoLGA modo-Iu") reemplazando la interfaz-A 140 de la Figura 8.

La Figura 9 ilustra un flujo de mensajes para un UE para registrarse con una red de VoLGA. Para obtener conectividad, el UE primero descubre un VANC en las etapas indicadas mediante el elemento 150. Si el UE ha completado exitosamente el procedimiento de descubrimiento del VANC (es decir, tiene la dirección de un SeGW y un VANC) , el UE puede intentar un registro de VoLGA en la etapa indicada mediante el elemento 152. El VANC puede aceptar el registro en la etapa indicada mediante el elemento 154, rechazar el registro en la etapa indicada mediante el elemento 156, o redirigir el UE a otro VANC (por ejemplo, dependiendo de la ubicación del UE, equilibrio de carga o condiciones de itinerancia) , como se ilustra por la etapa indicada mediante el elemento 158.

Un UE que realiza una llamada originada Móvil de VoLGA puede seguir las etapas ilustradas en la Figura 10. La Figura 10 ilustra un flujo de mensajes para establecer una conexión entre un UE y una red de VoLGA para iniciar una llamada originada Móvil de VoLGA. El UE establece la señalización para una llamada originada Móvil con el dominio de CS (mediante el MSC) y entonces una portadora sobre la LTE y el túnel de VoLGA son establecidos. De manera alternativa, la Figura 11 ilustra un flujo de mensajes para establecer una conexión entre un UE y una red de VoLGA para una llamada terminada móvil .

En general, un UE puede requerir acceso a un servicio, característica o grupo de servicios y/o características. El UE puede configurarse para acceder a múltiples RAT y decidir si obtiene conectividad, servicio, o características de una o más de las RAT. En la presente descripción, puede que la conectividad no quiera decir que el UE pueda obtener acceso a cada uno de los servicios o características. En cambio, la conectividad puede querer decir que el UE es autenticado y se autoriza para acceder a esa RAT. Como parte de este proceso, el UE puede descubrir que el servicio o característica deseados no se encuentran disponibles en la RAT. Los servicios o características deseadas pueden incluir obtener información, solicitar información, y solicitar varios mensajes de punto a punto que incluyen peticiones de Protocolo de Configuración de Anfitrión Dinámico, (DHCP) , peticiones de Servicio de Autenticación Remota para Usuarios de Marcación Entrante (RADIUS) , peticiones de Diámetro, aceptación de Unión, peticiones, etc., de la red. Los servicios o características deseados pueden también incluir los que se proporcionan por ciertos mensajes de punto a punto de la red incluyendo respuestas de DHCP, respuestas de RADIUS, respuestas de Diámetro, aceptar unión, indicaciones OK, detectar información tal como en mensajes de difusión, y buscar información .

El UE hace una determinación de cómo obtendrá los servicios o características deseados. Aunque la determinación puede realizarse en el nivel de AS/ÑAS, una vez que se hace la selección de NAS/AS, el UE puede necesitar informar a la infraestructura que proporciona los servicios (por ejemplo, el IMS) de cómo obtendrá los servicios deseados. Por ejemplo, en el caso de que la selección basada en el AS/NAS resulte en el UE retenido en una célula de red de la LTE sin servicios de voz, el UE puede informar al IMS después de un registro exitoso para servicios sin voz de que las llamadas de voz no pueden enrutarse a través del IMS.

En algunos casos , el UE puede informar a la red que los servicios o características que este requiere no se encuentran disponibles y que una RAT alternativa debe utilizarse para entregar esos servicios o características. El UE puede enviar un mensaje a la red para indicar ya sea que una RAT específica debe utilizarse para un servicio o característica, o que la RAT identificada no soporta el servicio o características requeridas. Cuando el UE recibe una petición de la red para entregar el servicio o característica, el UE puede realizar lo siguiente: Si la red propone una RAT alternativa para soportar un servicio o característica, el UE puede indicar de vuelta a la red el deseo de utilizar la RAT alternativa para parte de o para todos los servicios o características que se ofrecen; o el UE puede enviar una causa de error apropiada de vuelta a la red que accionará la red para intentar la entrega del servicio o característica sobre la RAT alternativa.

De manera alternativa, al descubrir que un servicio o característica no se encuentra disponible basándose en el Indicador de VoIMS o el Indicador de SR-VCC, el UE puede señalar a la red que una RAT alternativa debe utilizarse para ciertos servicios o características. En el ejemplo presente, la red puede configurarse para soportar el CS de reserva, y el UE puede no incluir la etiqueta de característica de ICS cuando se registre con una red de IMS (por ejemplo, debido a que no implementa la funcionalidad de CS de SDP (como se define en ietf draft-ietf-mmusic-sdp-cs ) ) . Como tal, puede ser la red que la red sea requerida para determinar cómo enrutar la llamada basándose en si el UE tiene acceso al IMS.

La Figura 12 es una ilustración de una secuencia de mensajes para notificar a una red de la capacidad del UE. En las etapas 200 de la Figura 12, el UE realiza un procedimiento de Unión al AS o procedimiento de Unión al ÑAS combinado y se une al EPC en la MME, o realiza un procedimiento de TAU (Actualización de Área de Rastreo) de AS o TAU de ÑAS combinada cuando se mueve a la LTE desde otro acceso o cuando se mueve a un área de rastreo diferente. Como se muestra en la Figura 12, la MME puede señalizar de vuelta según estándares existentes en por lo menos una bandera que indique si el IMS es soportado o si la SRVCC es soportada. En el caso de una unión combinada o TAU, la MME interactúa con el MSC para registrar el UE con el MSC en las etapas 202. A la recepción de esta información, en la etapa 204, el UE puede entonces informar a un nodo de red (por ejemplo, un AS de IMS o AS de SCC) de las preferencias del UE para determinar cómo las sesiones terminales deben entregarse basándose en el conocimiento del UE de la falta de soporte del servicio o característica deseados. Por ejemplo, el UE puede transmitir sus preferencias a un AS de IMS o AS de SCC si la bandera de Voz sobre IMS (VolMS) se encuentra con una indicación negativa o no se recibe de la MME, o la SRVCC no se soporta y el UE requiere SRVCC para operar. Otro ejemplo es que el UE puede siempre señalar sus preferencias deseadas con respecto a cómo una sesión terminal debe entregarse basándose en el conocimiento de la falta de soporte del servicio o característica deseada (por ejemplo, los ajustes de la bandera, indicador, o identificador de VolMS y SRVCC) .

Las preferencias del UE pueden ser enviar todos los servicios al dominio A (por ejemplo, dominio de CS, independientemente de la RAT especifica - es decir, GERAN o UTRA ) o un segundo dominio B. De manera alternativa, las preferencias pueden proporcionar una indicación estructurada que especifique que ciertas peticiones de servicio deben enviarse sobre ciertos dominios. En algunos casos, las preferencias pueden especificarse en paralelo con las etapas 202 de registro como se muestra en la Figura 12, o después. Por ejemplo, basándose en los ajustes de la bandera, indicador, o identificador de VolMS y SRVCC, el UE puede decidir qué servicios específicos se envíen sobre la LTE, por ejemplo S SoverlP, Video, etc., y que la voz deba enviarse sobre GERAN/UTRAN.'* Varias interfaces o puntos de referencia pueden utilizarse para implementar una o más de las etapas ilustradas en la Figura 12. Una de tales interfaces o puntos de referencia es la interfaz Ut (generalmente, entre el UE y un Servidor de Aplicación de SIP, el protocolo Suscribir/Notificar de XCAP y SIP puede utilizarse como parte de la interfaz Ut) . Otra interfaz o punto de referencia potencial puede incluir II, si II se encontrara mejorado para interactuar con, por ejemplo, Suscribir/Notificar de XCAP y/o SIP. II es un punto de referencia entre el UE y el AS de IMS y utiliza el Servicio de Mensajes Cortos (SMS) o Servicio Suplementario no Estructurado (USSD) como un transporte base para portar un protocolo tipo SIP.

De manera alternativa, el UE puede utilizar una forma diferente de señalización para notificar a la red de una o más capacidades del UE. En una configuración de red, el AS de IMS se encuentra en la trayectoria de los mensajes de SIP que se dirigieron al UE y se envían desde el UE, y para los cuales el AS de IMS incluye su URI en el campo de encabezado de Registro de Ruta. La S-CSCF puede dirigir un mensaje de SIP al AS de IMS como se instruye en el Criterio de Filtro inicial (iFC) aplicable. Como tal el UE puede incluir en varios mensajes de SIP, información acerca del estado de una capa inferior (por ejemplo, si la Voz de IMS es o no soportada, como se muestra a continuación mediante la Definición de Etiqueta de Característica de Medios y campo de encabezado P-Access-Network-Info) . Esto puede actuar como un indicador o bandera que puede ser explícito como se ilustra en los siguientes Métodos de SIP ejemplares. El indicador puede definirse mediante un campo de encabezado a. P-Access-Network-Info en los mensajes SIP como se muestra mediante el siguiente campo de encabezado o b. P-Access-Network-Info , una etiqueta de característica como se describe en la presente.

Definición de Etiqueta de Característica de Medios Lo siguiente es una ilustración de las definiciones de etiqueta de característica de medios ejemplares.

A.l Definición de la etiqueta de característica de medios g .3gp . novoice Nombre de etiqueta de característica de medios: g .3gpp . novoice Identificador ASN.1: 1.3.6.1.8.2.x El resumen de la característica de medios se indica mediante esta etiqueta: Esta etiqueta de característica indica que el dispositivo no puede soportar voz de duplexión completa .

Los valores apropiados para utilizarse con esta etiqueta de característica: Booleanos.

La etiqueta de característica se pretende principalmente para utilizarse en las siguientes aplicaciones, protocolos, servicios, o mecanismos de negociación: Esta etiqueta de característica es más útil en una aplicación de comunicaciones, para describir las capacidades de un dispositivo, tales como un teléfono o PDA.

Ejemplos de uso típico: Indica que un teléfono móvil no soporta voz de duplexión completa. Otras formas de hablar pueden soportarse tal como radio de transmisión continua, etc.

A.2 Definición de etiqueta de característica de medios g.3gpp.CSFB Nombre de etiqueta de característica de medios: g.3gpp.CSFB Identificador ASN.l: 1.3.6.1.8.2. y El resumen de la característica de medios se indica mediante esta etiqueta: Esta etiqueta de característica indica que el dispositivo ha realizado una conexión combinada exitosa (registro CSFB) .

Los valores apropiados para utilizarse con esta etiqueta de característica: Booleanos.

La etiqueta de característica se pretende principalmente para utilizarse en las siguientes aplicaciones, protocolos, servicios, o mecanismos de negociación: Esta etiqueta de característica es más útil en una aplicación de comunicaciones, para describir las capacidades de un dispositivo, tales como un teléfono o PDA.

Ejemplos de uso típico: Indica que un teléfono móvil ha realizado una conexión combinada exitosa sobre una interfaz SGs .

El campo de encabezado P-Access-Network-lnfo (se muestran cambiados en el texto subrayado) 7.2A.4 campo de encabezado P-Access-Network-Info 7.2A.4.1 Introducción El campo de encabezado P-Access-Network-Info se extiende para incluir información específica con relación a tecnologías de acceso particulares. 7.2A.4.2 Sintaxis La sintaxis del campo de encabezado P-Access-Network-Info se describe en RFC 3455. Existen reglas de codificación adicionales para este campo de encabezado dependiendo del tipo de EP-CAN, de acuerdo con las descripciones especificas de tecnología de acceso.

La siguiente Tabla 2 describe la sintaxis extendida específica de 3GPP del campo de encabezado P-Access-Network-Info definido en RFC 3455.

P-Access-Network-Info = "P-Access-Net ork-Info" HCOLON access-net-spec *(COMMA access-net-spec) access-net-spec = (access-type / access-class. *(SEMI access-info) access-type = "IEEE-802.1 1 " / "IEEE-802. l i a" / "IEEE-802. 1 1 b" / "IEEE-802. 1 lg" / "IEEE-802.1 1 n" / "3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP- UTRAN-TDD" / "3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" / "ADSL" / "ADSL2" / "ADSL2+" / "RADSL" / "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" / "VDSL" / IDSL" / "3GPP2- I X" / "3GPP2- 1 X-HRPD" / "3GPP2-UMB" / "DOCSIS" / "IEEE-802.37 · IEEE-802.3a" / "ffiEE-802.3e" / "EEE-802.3Í7 "EEE-802.3j" / "EEE- 802.3u" / "EEEE-802.3ab'7 "IEEE-802.3ae7"EEE-802.3ak71EEE-802.3aq7 " IEEE- 802.3an" / "IEEE-802.3y7 "IEEE-802.3z7 "IEEE-802.3y"/ token ...access-class = "3GPP-GERAN" / "3GPP-UTRAN" / "3GPP-E-UTRAN" / "3GPP-WLAN" / "3GPP-GAN" / "3GPP-HSPA" / token np = "network-provided" access-info = cgi-3gpp / utran-cell-id-3gpp / dsl-location / i- lan-node-id / ci-3gpp2 / eth-location / np/ e»utran»voice-3gpp / extension-access-info extension-access-info = gen-value cgi-3gpp = "cg¡-3gpp" EQUAL (token / quoted-string) utran-cell-¡d-3gpp = "utran-cell-¡d-3gpp" EQUAL (token / quoted-string) i-wlan-node-id = "i-wlan-node-id" EQUAL (token / quoted-string) dsl-location = "dsl-location" EQUAL (token / quoted-string) eth-location = "eth-location" EQUAL (token / quoted-string) ci-3gpp2 = "ci-3gpp2" EQUAL (token / quoted-string) e-utran-voice-3gpp = " NW -prov d á-VolMS-inclicator " Tabla 2 La presencia del parámetro "np" indica que un campo de encabezado P-Access-Network-Info se proporciona mediante la P-CSCF. El contenido puede variar a partir de un campo de encabezado P-Access-Network-Info sin este parámetro el cual se proporciona por el UE.

El parámetro "np" puede utilizarse con ambas formas "access-type" y "access-class " . La forma "access-type" se proporciona para utilizarse donde el valor no es conocido específico para un valor "access-value" particular, por ejemplo, en el caso de algunos valores entregados de la PCRF. 7.2A.4.3 Reglas de codificación adicionales para el campo de encabezado P-Access-Network-Info El campo de encabezado P-Access-Network-Info se encuentra poblado con los siguientes contenidos: 1) el campo access-type se establece a uno de "3GPP-GERAN" , " 3GPP-UTRAN-FDD" , " 3GPP-UTRAN-TDD" , "3GPP2-1X", " 3GPP2 -1X-HRPD" , " 3GPP2-UMB" , " IEEE-802.11 " , " IEEE-802. lia" , "IEEE-802.11b" , " IEEE-802. llg" , " IEEE-802. lln" , "ADSL", "ADSL2 " , "ADSL2+ ", "RADSL" , "SDSL", "HDSL" , "HDSL2", "G . SHDSL" , "VDSL", "IDSL", O "DOCSIS", " IEEE-802.3 " , " IEEE-802.3a", "IEEE-802.3e" , " IEEE-802.3i " , " IEEE-802.3J" , "IEEE-802.3u", o "IEEE-802.3ab" , " IEEE-802.3ae" , IEEE-802.3ak" , IEEE-802.3aq" , IEEE-802.3an" , " IEEE-802.3y" , " IEEE-802.3z " o " IEEE-802.3y" como sea apropiado para la tecnología de acceso en uso. 2) Si el campo access type se establece a "3GPP-GERAN", un parámetro cgi-3gpp se establece a la Identidad Global Celular obtenida de las capas inferiores del UE. La Identidad Global Celular es una concatenación de MCC, MNC , LAC, y CI (como se describe en TS 23.003 de 3GPP) . El valor del parámetro "cgi-3gpp" por consiguiente se codifica como una cadena de texto como lo siguiente: Se comienza con el bit más significativo, MMC (3 dígitos) , MNC (2 ó 3 dígitos dependiendo del valor MMC) , LAC (código de longitud fija de 16 bits que utiliza una representación hexadecimal completa) y CI (código de longitud fija de 16 bits que utiliza una representación hexadecimal completa) ; 3) si el campo access type es igual a "3GPP-UTRAN-FDD", o " 3GPP-UTRAN-TDD" , un parámetro "utran-cell-id-3gpp" se establece para una concatenación de MCC, MNC, LAC (como se describe en TS 23.003 de 3GPP) y la Identidad Celular de UMTS (como se describe en TS 25.331 de 3GPP) , obtenido de las capas inferiores del UE, y se codifica como una cadena de texto como sigue: Se comienza con el bit más significativo, MCC (3 dígitos) , MNC (2 ó 3 dígitos dependiendo del valor MCC, LAC (código de longitud fija de 16 bits que utiliza una representación hexadecimal completa, e Identidad Celular de UMTS (código de longitud fija de 28 bits que utiliza una representación hexadecimal completa) ; 4) si el campo access-class se establece, el parámetro "np" access-info" es el único parámetro access-info insertado. Esta liberación de esta especificación no define valores para utilizar en este parámetro. El campo access-class puede establecerse solo mediante la P-CSCF; 5) Si el campo access type se establece a "3GPP2-IX" , un parámetro ci-3gpp2 se establece a la representación ASCII del valor hexadecimal de la cadena obtenida por la concatenación de SID (16 bits), NID (16 bits), PZID (8 bits), y BASE-ID (16 bits) (véase C.S0005-D [85] de 3GPP2 ) en el orden especificado. La longitud del parámetro ci-3gpp2 debe ser de 14 caracteres hexadecimales . Los caracteres hexadecimales (de A hasta F) deben codificarse utilizando los caracteres ASCII en mayúscula. Si la MS no conoce los valores para ninguno de los parámetros anteriores, la MS debe utilizar el valor de 0 para ese parámetro. Por ejemplo, si el SID es desconocido, la MS debe representar el SID como 0x0000; NOTA 1: El valor de SID se representa utilizando 16 bits a diferencia de 15 bits como se especifica en C.S0005-D [85] de 3GPP2.

EJEMPLO: Si SID = 0x1234, NID = 0x5678, PZID = 0x12, BASE_ID = OxFFFF, el valor ci-3gpp2 se establece a la cadena " 1234567812FFFF" . 6) si el campo access type se establece a "3GPP2-1X-HRPD" , un parámetro ci-3gpp2 se establece a la representación ASCII del valor hexadecimal de la cadena obtenida por la concatenación de la ID de Sector (128 bits) y longitud de Subred (8 bits) (véase C.S0024-A [86] de 3GPP2) e ID de Portadora, si se encuentra disponible, (véase X.S0060 [86B] de 3GPP2) en el orden especificado. La longitud del parámetro ci-3gpp2 debe ser de 34 a 40 caracteres hexadecimales dependiendo de si la ID de Portadora se incluye. Los caracteres hexadecimales (de A hasta F) deben codificarse utilizando los caracteres ASCII en mayúscula.

EJEMPLO: Si la ID de Sector 0x12341234123412341234123412341234, longitud de Subred = 0x11, y la ID de Portadora = 0x555444, el valor de ci-3gpp2 se establece a la cadena "1234123412341234123412341234123411555444" . 7) si el campo access type se establece a "3GPP2-UMB" C.S0084-000 [86A] de 3GPP2 , un parámetro ci-3gpp2 se establece a la representación ASCII del valor hexadecimal de la ID de Sector (128 bits) que se define en C.S0084-000 [86A] de 3GPP2. La longitud del parámetro ci-3gpp2 debe ser de 32 caracteres hexadecimales. Los caracteres hexadecimales (de A hasta F) deben codificarse utilizando los caracteres ASCII en mayúscula .

EJEMPLO: Si la ID de Sector 0x12341234123412341234123412341234, el valor ci-3gpp2 se establece a la cadena "12341234123412341234123412341234". 8) si el campo access-type se establece a uno de "IEEE-802.11 ", " IEEE-802. lia" , " IEEE-802.11b" o " IEEE-802. llg", o " IEEE-802. lln" , un parámetro " i-wlan-node-id" se establece a la representación ASCII del valor hexadecimal de la dirección MAC del AP sin ningunos caracteres delimitantes; EJEMPLO: Si la dirección MAC del AP = 00-OC-F1-12-60-28, entonces i-wlan-node-id se establece a la cadena "OOOcf 1126028" . 9) si el campo access-type se establece a uno de "ADSL" , "ADSL2 " , "ADSL2+ " , "RADSL" , "SDSL", "HDSL" , " HDSL2 " , "G . SHDSL" , "VDSL", "IDSL", el campo access-info debe contener un parámetro dsl-location obtenido de CLF (véase la arquitectura funcional NASS) ; 10) si el campo access-type se establece a "DOCSIS", el parámetro access info no se inserta. Esta liberación de esta especificación no define valores para utilizar en este parámetro; 11) si el campo access type es igual a " 3GPP-E- UTRAN-FDD" o " 3GPP-E-UTRAN-TDD" , un parámetro "utran-cell-id-3gpp" se establece para una concatenación de MCC, MNC, TAC (como se describe en TS 23.003 de 3GPP) y la Identidad Global Celular Evolucionada (como se describe en TS 23.401 [7B] de 3GPP) , obtenido de las capas inferiores del UE, y se codifica como una cadena de texto como lo siguiente: Se comienza con el bit más significativo, MCC (3 dígitos), MNC (2 ó 3 dígitos dependiendo del valor MCC, TAC (código de longitud fija de 16 bits que utiliza una representación hexadecimal completa, e Identidad Global Celular Evolucionada (código de longitud fija de 28 bits que utiliza una representación hexadecimal completa) ; y lia) si el campo access type es igual a " 3GPP-E-UTRAN-FDD" o " 3GPP-E-UTRAN-TDD" , un parámetro "NW-provided-VoIMS-indicator " se incluye si NW-provided-VoIMS-indicator se obtiene de capas inferiores del UE; 12) si el campo access-type se establece a uno de "IEEE-802.3 " , " IEEE-802.3a" , " IEEE-802.3e" , " IEEE-802.3 i " , "IEEE-802.3 j " , " IEEE-802.3u" , " IEEE-802.3ab" , " IEEE-802.3ae" , " IEEE-802.3ak" , " IEEE-802.3aq" , " IEEE-802.3an" , " IEEE-802.3y", "IEEE-802.3z" o " IEEE-802.3y" y se utiliza un subsistema NASS, el campo access-info debe contener un parámetro eth-location obtenido de CLF (véase arquitectura funcional NASS) .

NOTA 2: El "cgi-3gpp", el "utran-cell-id-3gpp" , el "ci-3gpp2", el " i-wlan-node-id" , eth-location, y los parámetros "dsl-location" descritos en lo anterior entre otros usos también constituyen los identificadores de ubicación que se utilizan para servicios de emergencia.

En otra modalidad, un UE indica un cambio de preferencia. Por ejemplo, un usuario puede cambiar su preferencia para recibir voz sobre PS a recibir voz sobre el CS. Un AS de SCC o TADS puede realizar continuidad de servicio en el evento de que la preferencia cambie y las sesiones con medios de voz salen hacia el UE. Un cambio de preferencia puede indicarse utilizando la interfaz Ut y XCAP o utilizando un mensaje de SIP. Por ejemplo, el UE puede volver a registrarse utilizando una petición SIP REGISTER o el UE puede transmitir un mensaje de SIP (solo si una sesión particular necesita recibir continuidad de servicio (por ejemplo, transferirse al dominio de CS)) tal como una petición SIP UPDATE o petición SIP INVITE. El mensaje de SIP puede incluir un indicador que indica la preferencia. El indicador puede codificarse como un valor de campo de encabezado o una parte de cuerpo tal como una parte de cuerpo XML. Tal indicador puede asumir valores incluyendo "Centrado en Voz" o "Centrado en Datos", y "Solo Voz de CS", "Solo voz de PS de IMS", "Voz de CS Preferida, Voz de IMS secundaria" o "Voz de IMS Preferida, Voz de CS secundaria" . En particular, el campo de encabezado P-Access-Network-Info puede incluir un indicador. El indicador no aplica necesariamente solo a E-UTRAN. El indicador también puede aplicar a otros tipos de acceso y clases de acceso indicadas en la Tabla 2.

En otra implementación, el indicador puede definirse implícitamente por el UE omitiendo uno o más indicadores o banderas. Por ejemplo, el UE puede omitir ciertas etiquetas de característica en el método de SIP, por ejemplo, la etiqueta de característica "sip.audio" [RFC 3840 Indicando Capacidades de Agente de Usuario en el Protocolo de Inicio de Sesión (SIP) ] . Cuando el nodo de red (por ejemplo, AS de SCC) recibe la falta de la etiqueta de característica, el nodo de red tendrá conocimiento de que cuando una sesión deba terminarse en ese UE la función de TADS tomará esto en cuenta .

Tanto en los casos anteriores (señalización explícita e implícita) , el campo de encabezado P-Access-Network-Info puede extenderse para incluir información específica con relación a tecnologías de acceso particulares.

Para ciertas tecnologías de acceso, el campo de encabezado P-Access-Network-Info puede además extenderse para incluir un indicador "Voz de IMS sobre sesión de PS soportada" . La información posible que se transporta por tal indicador puede ser Booleana (por ejemplo, la presencia del indicador significa soporte, la ausencia significa soporte desconocido o falta de soporte) ; o pueden existir 3 tipos de información: la presencia del indicador establecida a un valor positivo significa soporte, su ausencia significa soporte desconocido, y la presencia del indicador establecida a un valor negativo significa falta de soporte.

Si el UE se configura para Voz sobre IMS, la funcionalidad del UE y la Selección de Dominio de Servicio (SDS) en la red debe tomar la "indicación de sesión de Voz de IMS sobre PS soportada" en cuenta. Las llamadas de voz de IMS (con la portadora de voz en el dominio PS) deben entregarse utilizando solo la RAT donde la "indicación de sesión de Voz de IMS sobre PS soportada" aplique e indique soporte.

Para los UE configurados para utilizar el IMS para llamadas de voz siempre que el IMS es soportado por la RAT, los servicios de usuario deben soportarse por el subsistema IM CN y las llamadas terminadas móvil deben enrutarse al subsistema de Red Central (CN) Multimedia de IP (IM) .

A medida que el AS de IMS detecta información o un cambio en la información que describe el soporte de capa inferior (por ejemplo, capa de ÑAS) (por ejemplo la indicación del UE acerca de la "indicación de sesión de Voz de IMS sobre PS soportada" que se encuentra disponible en el nivel de ÑAS e indica soporte) en un mensaje de SIP, el AS de IMS puede almacenar una indicación relacionada, efectuando un cambio en los procedimientos. Por ejemplo, dependiendo de la información recibida con respecto al indicador "sesión de Voz de IMS sobre PS soportada", un AS de IMS puede destinar llamadas de SIP terminadas móvil que incluyan · un componente de medios de voz al dominio de CS. En algunas implementaciones , la función de TADS típicamente proporciona esta función.

La Selección de Dominio de Acceso a Terminal (TADS) selecciona el acceso de CS y/o una o más redes de acceso de PS a utilizarse para entregar una sesión terminal al UE. La TADS es una funcionalidad ubicada en el IMS y, opcionalmente, en el UE.

Para sesiones terminales, la TADS siempre se realiza después de servicios terminales. La TADS puede tomar los siguientes factores (pero no se limita a) en cuenta para la decisión de selección: 1) El estado del UE en el dominio conmutado por circuito (CS) (esta información de estado debe incluirse) : No unido, Unido; 2) El estado del UE en el IMS (la información de estado debe incluir) : Registrado, No registrado; 3) las capacidades del UE; 4) opcionalmente, la indicación de UE acerca de la "indicación de sesión de voz de IMS sobre PS soportada" que se encuentra disponible en el nivel de ÑAS e indica soporte; 5) la indicación de UE del soporte de ICS; 6) las capacidades de red de acceso; 7) los dominios /tipos de acceso utilizados por una sesión existente; 8) los componentes de medios incluidos en la sesión entrante; y 9) preferencias de Usuario y política de operador.

Además, el campo de encabezado P-Access-Network-Info u otro campo de encabezado puede extenderse para indicar preferencias incluyendo "Centrado en Voz", o "Centrado en Datos", y "Solo Voz de CS", "Solo voz de PS de IMS", "Voz de CS Preferida, Voz de IMS secundaria" o "Voz de IMS Preferida, Voz de CS secundaria" . El campo de encabezado puede incluirse en un mensaje de SIP cuando un cambio de preferencia ocurre. Tal mensaje de SIP puede transmitirse cuando el usuario prefiere recibir los medios de voz sobre un acceso particular (por ejemplo CS) solo para una sesión de SIP particular (por la duración de la política o preferencia) . De manera alternativa, el cambio de preferencia puede indicarse en otro mensaje, por ejemplo, como parte del protocolo XCAP.

La Figura 13 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, en donde la red no soporta un servicio o característica deseada por el UE y el UE se registra para servicios sin voz. En la Figura 13 el UE se conecta al dominio PS utilizando una RAT de la LTE (es decir, sobre PS de GERAN/UTRAN o EPC/LTE) . En las etapas 210, el UE realiza un procedimiento de Unión de ÑAS o procedimiento de Unión Combinado de ÑAS cuando se une a la LTE, o realiza un procedimiento de TAU de AS (Actualización de Área de Rastreo) o TAU Combinada de AS cuando se mueve a la LTE desde otro acceso o cuando se mueve a un área de rastreo diferente. Como parte de ganar conectividad al dominio PS, el UE descubre que un servicio o funcionalidad que el UE requiere no se soporta mediante una bandera o indicador que pueda difundirse, o proporcionarse en un mensaje de punto a punto (por ejemplo, un mensaje de red a dispositivo inalámbrico que contiene los ajustes de bandera, indicador, o identificador de VoIMS y SRVCC .

En una implementación, el UE puede descubrir la falta de servicio o funcionalidad al solicitar conectividad ya sea con un procedimiento de Unión de AS, procedimiento de Unión Combinada de AS, procedimiento de actualización de Área de Rastreo (TAU) o procedimiento de Actualización de Área de Enrutamiento . En respuesta, ciertos mensajes que el UE recibe de vuelta de la red al concluir exitosamente el procedimiento pueden incluir una bandera que indique que el VoIMS no es soportado.

El UE puede entonces registrarse con la red de IMS incluyendo la bandera/indicador como se identifica en lo anterior en las etapas 212. El indicador puede pasarse al nodo de red que es responsable de seleccionar cómo entregar sesiones terminadas móviles (por ejemplo, la función de Selección de Dominio de Acceso a Terminal (TADS) en el AS de IMS .

Si el UE se involucra en cualquier otro método de SIP, el UE puede actualizar cualquier indicador asociado si las propiedades de la red cambian utilizando un mecanismo como se describe en lo anterior.

Cuando una sesión terminada Móvil llega, la sesión se entrega al nodo de red responsable de decidir como enrutar el servicio. La TADS puede encontrarse al tanto de que el UE registrado sobre el dominio PS no soporta el servicio deseado. La falta de soporte de servicio puede identificarse mediante uno o más de a) la bandera o indicador que se registró con el sistema de IMS, b) el ajuste de datos de configuración opcional en la TADS, y c) criterio adicional que también puede utilizarse para realizar una decisión de como enrutar la llamada.

La TADS puede entonces elegir una dirección de destino alternativa que puede incluir la identidad del dispositivo inalámbrico en el dominio del CS (por ejemplo, MSISDN para GERAN/UTRAN del CS) . Esto puede requerir que el AS de IMS consulte el HSS para obtener el Número de Enrutamiento de Estación Móvil (MSRN) /Número de Enrutamiento de CS (CSRN) para ubicar el MSC correcto. La sesión puede entonces entregarse al dispositivo móvil utilizando procedimientos de CS de reserva tradicionales al enrutar la llamada al MSC que entonces llamará al UE sobre la ínterfaz SGs .

En los presentes ejemplos, aunque la descripción se dirige principalmente a la LTE y GERAN/UTRAN, las diversas RAT pueden incluir, y no limitarse a, uno o más de lo siguiente : access-type "IEEE-802. ? 1" / "IEEE-802. 1 la" / "IEEE-802.1 1 b" / "1EEE-802.1 lg" / "IEEE-802.1 ln" / "3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP- UTRAN-TDD" / "3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" / "ADSL" / "ADSL2" / "ADSL2+" / "RADSL" / "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" / "VDSL" / "IDSL" / "3GPP2-1X" / "3GPP2-1X- HRPD" / "3GPP2-UMB" / "DOCSIS" / "IEEE-802.37 "EEEE-802.3a" / "IEEE-802.3e" / "IEEE-802.3Í "DEEE-802.3j" / "IEEE-802.3u" / "IEEE- 802.3ab7 "IEEE-802.3ae'7"IEEE-802.3ak7IEEE-802.3aq7 "EEEE- 802.3an" / "IEEE-802.3y "IEEE-802.3z7 "CEEE-802.3y7 ficha Tabla 3 Debido a que el PCC interactúa con la red de EPC durante procedimientos de unión de ÑAS a la LTE y GERAN/UTRAN, Actualización de Área de Rastreo, Actualización de Área de Rastreo Combinada y Actualizaciones de Área de Enrutamiento respectivamente, el PCC puede proporcionarse con el Indicador de VoIMS que aplica al TA o RA, respectivamente. Por ejemplo, 1) si el TA al que el UE se une soporta el VoIMS, la MME establece el Indicador de VoIMS para "soportarse". Si este no soporta el VoIMS, la MME establece el indicador de VoIMS para "no soportarse". 2) Si el TA en el que el UE establece la conectividad de PDN soporta el VoIMS, la MME establece el indicador de VoIMS para "soportarse". Si este no soporta el VoIMS, la MME establece el Indicador de VoIMS para "no soportarse". 3) Si el TA o RA al que el UE se mueve soporta el VoIMS, la MME establece el Indicador de VoIMS para "soportarse". Si este no soporta el VoIMS, establece el Indicador de VoIMS para "no soportarse" . 4) Si el RA al que el UE se mueve soporta el VoIMS, la SGSN establece el Indicador de VoIMS para "soportarse". Si este no soporta el VoIMS, la SGSN establece el Indicador de VoIMS para "no soportarse". 5) Si el RA en el que el UE se encuentra retenido actualmente soporta el VoIMS, la SGSN establece el indicador de VolMS para "soportarse". Si este no soporta el VoIMS, la SGSN establece el Indicador de VoIMS para "no soportarse". Como tal, el PCC puede siempre encontrarse informado de soportar para el VoIMS en la RAT especifica y el área en la cual el UE se ubica.

Por consiguiente, en una implementación del presente sistema, la información que describe soporte de VoIMS por el dominio PS que se envía mediante el UE a la infraestructura de IMS puede vigilarse, afirmarse, o ser anexada por un servidor de SIP o proxy de SIP en la red (por ejemplo, para verificar si es correcta) . Por ejemplo, una P-CSCF puede interactuar con el PCC. Basándose en la respuesta recibida de los elementos funcionales capaces de PCC, una P-CSCF puede vigilar, afirmar o anexar el valor de campo de encabezado P-Access-Network-Info . Como tal, la red puede encontrarse al tanto de cómo entregar llamadas apropiadamente. Tener en cuenta que esta implementación del sistema puede implementarse junto con o por separado a partir de una o más de las diferentes implementaciones descritas durante el transcurso de la presente descripción.

En algunas implementaciones del presente sistema, puede existir una situación de carrera. Una petición de SIP Terminada Móvil con un componente de medios de voz o conversación puede recibirse mediante el AS de IMS mientras que la información del UE acerca del soporte de las capas inferiores (por ejemplo, que indica el indicador "sesión de Voz de IMS sobre PS soportada") aún no se ha actualizado en la indicación relacionada de AS de IMS (es decir, la información que el UE ha proporcionado al AS de IMS) . Como resultado, los procedimientos aplicados a la petición de SIP Terminada Móvil con un componente de medios de voz o conversación pueden ser inapropiados .

Requerir que un UE envíe un mensaje de SIP en cuanto la información del UE acerca del soporte de capa inferior cambie reduce una ventana horaria durante la cual los procedimientos pueden ser inapropiados. Como un ejemplo, un mensaje de SIP puede generar una regeneración del registro de SIP, por ejemplo, utilizando una petición de SIP REGISTER. Un UE puede también aplicar IUT o redireccionar y reenviar la petición con una indicación de voz conversacional a una interfaz que soporte la capacidad requerida. De manera alternativa, el elemento funcional de PCC puede señalar la incapacidad para soportar el servicio debido a la falta de disponibilidad de recursos .

Como se describe en lo anterior, los elementos funcionales de IMS de una implementación de red particular pueden no siempre tener la información más actualizada que describa los servicios soportados por la red de acceso. Como tal, en una implementación de sistema donde el UE es un UE capaz de ICS, es el UE el que realiza la determinación final en cuanto a si las llamadas Terminadas Móvil (MT) deben entregarse sobre IMS o sobre CS. Durante el registro de IMS, el UE señala al IMS que el UE tiene la capacidad para soportar ICS .

Después de registrarse, cuando una llamada terminada móvil llega al IMS, el AS de SCC puede enviar una petición de SIP al UE que puede incluir un componente de medios de SDP para la entrega de medios sobre una RAT de IP (EPC o GERAN/UTRAN de PS) y/o un indicador para la entrega de medios sobre el dominio de CS . En este ejemplo, el AS de SCC siempre incluye el componente de medios de SDP adicional para la entrega de medios sobre el dominio de CS. Es entonces cuando el UE que finalmente decide qué dominio utilizar para recibir la sesión Terminada Móvil basándose en información que el UE tiene en la disponibilidad de soluciones de voz (por ejemplo Bandera VoIMS y una capacidad para acceder a GERAN o UTRAN) . En casos donde el UE no incluye una indicación para soportar ICS mediante la inclusión de una etiqueta de medios de ICS, el AS de IMS no necesita insertar el SDP que permite que el CS se utilice para portadora de voz .

Tener en cuenta que este procedimiento puede requerir un intercambio de mensaje de SIP adicional comparado con el caso donde la red se encontraba al tanto del valor del indicador "sesión de Voz de IMS sobre PS soportada" para el UE destinado.

Si la Centralización y Continuidad de Servicio de IMS no se utiliza y si un suscriptor se encuentra suscrito tanto al dominio de CS y el IMS , el UE se une al dominio de CS, y el dominio de PS se selecciona para entregar la sesión terminada Móvil al UE pero la entrega falla debido a cualquiera de las siguientes razones: 1) El UE rechaza la entrega de las llamadas de voz de IMS (con la portadora de voz en el dominio PS) debido a que en la RAT en uso por el UE la "indicación de sesión de Voz de IMS sobre PS soportada" no indica soporte o no se encuentra disponible; o 2) El EPC rechaza el establecimiento de las portadoras requeridas para las llamadas de voz de IMS debido a que en la RAT la "indicación de sesión de Voz de IMS sobre PS soportada" no indica soporte o no se encuentra disponible entonces la sesión que llegó en el IMS puede necesitar ser enrutada al dominio de CS como se describe en la presente.

La Figura 14 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, donde el UE toma en cuenta los indicadores del servicio o funcionamiento proporcionados por la red (por ejemplo, el Indicador de VolMS que se ha obtenido de la red cuando se encuentra Unido a la RAT) .

En las etapas 220, el UE realiza un procedimiento de Unión de ÑAS o procedimiento de Unión Combinada de ÑAS. El UE se registra con el sistema de IMS que incluye etiquetas de característica típicas y no indicaciones relacionadas al Indicador de VoIMS en las etapas 222. Una de las etiquetas de característica o indicadores puede ser una etiqueta de característica de ICS. Cuando el modo de red, por ejemplo AS de SCC recibe el mensaje REGISTER el AS de SCC almacena la información recibida en el registro de terceros (por ejemplo, la etiqueta de característica de ICS) . Cuando el AS de SCC recibe una llamada entrante este puede encontrarse al tanto de que el UE que recibe la llamada entrante se encuentra registrado en la LTE, a medida que el UE o P-CSCF pueden tener el encabezado P-ACCESS-NETWORK-INFO incluido indicando una RAT de tipo LTE. Sin embargo, a menos que el AS de SCC reciba la información de dominio de configuración opcional como se describe en lo anterior, el AS de SCC puede que no conozca si la red de la LTE soporta voz de IMS. Como resultado, la TADS puede elegir un destino de UE de la LTE. Si la LTE (o el dominio PS en general) se elige para entregar la llamada entrante, debido a que el UE no ha proporcionado ninguna información de configuración de dominio y el UE se registra con el IMS, el AS de IMS construirá una oferta de SDP que contiene líneas de Medios que soportan tanto a CS como a la LTE para acceso de voz asumiendo que la etiqueta de característica de ICS se incluye. De otra manera, la parte de CS de la oferta de SDP puede omitirse. Como ejemplo de INVITE que contiene la parte de CS de la oferta se ilustra a continuación en la Tabla 4.

INVITE sip:user2_publ¡[email protected] SIP/2.0 Via: SIP/2.0/UDP sccas.homel.net;branch=z9hG4bKnas34r5 Max-Forwards: 65 Route: <sip:cb03a0s09a2sdfglkj490333@scscfl .homel.net;lr>;orig-dialog- id=' :739357 l 8_926451 10-712786jd246395302d-z E Record-Route:<sccas.homel.net;lr> P-Access-Network-Info: P-Asserted-Ident¡ty: P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22); ecf=[5555:: lff:2ee:3dd:4ee]; ecf=[5555::6aa:7bb:8cc:9dd] P-Charging- Vector: P-Asserted-Serv¡ce: Accept-Contact: *;+g.3gpp.ics¡-ref="urn%3Aurn-7%3gpp-service.¡ms.icsi.mmteI" Accept-Contact: *;;+g.3gpp.ics="server;explicit;requ¡re" Privacy: From: <sip:user2_public l @home2.net>;tag= I7l828 To: Call-ID: Cseq: Supported: Accept: Contact: Allow: Content-Type: Content-Length: v=0 o=29879336 !5 2987933615 ?? IP6 5555::eee:ccc:aaa:bbb s=- c=IN IP6 5555::eee:fff:aaa:bbb t=00 m=audio 4 170 RTP/AVP 97 3 98 a=creq:med-vO,ccap-vO a=mcap: l 97 a=mcap:2 GSM/8000/1 a=mcap:3 98 a=mcap:4 - a=tcap: 1 RTP/AVP RTP/AVPF PSTN a=ccap: 1 I ??6 5555::eee:fff:aaa:bbb a=ccap:2 PSTN E164 + 12125556666 a=acap: l setup:actpass a=acap:2 connection.new a=acap:3 rtpmap:97 AMR a=acap:4 fmtp:97 mode-set=0,2,5,7; maxframes=2 a=acap:5 rtpmap:98 telephone-evenl a=pcfg. l t=l m=l,2,3 c= l a=3,4,5 a=pcfg:2 t=2 m= l,2,3 c=l a=3,4,5 a=pcfg:3 t=3 m=4 c=2 a=l,2 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos opcional remote sendrecv Tabla 4 A la recepción de SIP INVITE, el UE analiza las opciones de SDP recibidas contra las opciones de UE para soportar el servicio deseado sobre el dominio PS y el dominio del CS tomando en cuenta los ajustes de voz del UE y los ajustes de uso del UE (por ejemplo, a la recepción de INVITE con SDP para voz que soporta el CS e IP (sobre la LTE) el UE compara esto con los ajustes de la bandera de VolMS y bandera de SRVCC y realiza una determinación de cómo procesar la llamada - ya sea aceptar la llamada sobre la red de la LTE o realiza una llamada sobre el CS para recuperar la llamada) .

La Figura 15 es un dibujo esquemático que muestra una vista diagramática de la funcionalidad de un Comparador (función de TADS) . El comparador 230 incluye entradas A 232 y B 234. En una implementación, la entrada A 232 se atribuye a los ajustes de voz de UE, y la entrada B 234 se atribuye a los ajustes de uso de UE. Entradas adicionales se definen para mensajes SIP INVITE (SDP contiene la capacidad para utilizar la RAT actual y la RAT alternativa para servicio) (entrada 236), mensajes de RAT 2 para soportar servicios como el Modo de Transferencia Dual (DTM. , IMS, etc.), (entrada 238), e Indicadores de RAT 1 (el servicio no se encuentra disponible en esta RAT, por ejemplo, sin VolMS) (entrada 240). Basándose en las entradas, el Comparador 230 se configura para producir una Respuesta 242 de SIP. Aunque la Figura 15 ilustra una implementación específica del Comparador 230, varias capacidades del Comparador pueden incluir la recepción de información recuperada mediante información de difusión o a partir de mensajes de punto a punto. La información de difusión puede ser, pero no se limita al soporte para DTM, GPRS, EDGE, etc. La información de punto a punto podría ser pero no se limita a "Soporte de VoIMS", "Soporte de SRVCC" etc.

En una implementación del presente sistema, el siguiente seudo código puede utilizarse para describir que el UE hace cuando la bandera de VoIMS se establece en una manera negativa pero igualmente podría aplicar si el UE quiere SRVCC y esto no es soportado.

IF Voz de UE - CS o IMS preferido THEN IF INVITE SDP con oferta de CS THEN IF UE es centrado en datos THEN Envía respuesta de SIP, por ejemplo, Respuesta de SDP 183 con CS o Si el SDP contiene componentes de voz, la línea de medios asociada con el puerto de oferta de CS (componente de voz) debe establecerse a cero o a=inactivo y las otras líneas SDP M deben aceptarse de acuerdo con estándares existentes .

ELSE IF el UE es centrado en voz THEN Envía respuesta de SIP, por ejemplo, Respuesta de SDP 183 con CS ELSE IF INVITE SDP no es oferta de CS THEN IF UE es centrado en datos THEN IF solo se ofrece voz THEN Envía Error de SIP (el mensaje necesita ser selección de dominio alternativa no activo, es decir, sin un 488) oferta ELSE IF SDP contiene otros medios THEN Envía la respuesta de SIP, por ejemplo, 183 con líneas de medios que contienen voz con puertos establecidos a 0.

ELSE IF UE centrado en voz THEN Envía Error de SIP 488 que activa la selección en dominio alternativo según TS 24.292 de 3GPP sub-clausula 10.2.4 Tabla 5 En el seudo código de la Tabla 5, la causa del error puede indicar que ninguno de los SDP se encuentra bien. Si es así, el UE puede entonces incluir una lista de los SDP que el UE aceptaría incluyendo, por lo menos, el SDP- de CS . El AS de IMS, al recibir un mensaje de error, puede regresar el SDP- de CS al UE.

El siguiente seudo código es un ejemplo de una serie de etapas que el UE puede implementar cuando la bandera de VolMS se establece en una manera positiva.

IF UE es de Voz - CS es preferido THEN IF INVITE SDP con oferta de CS THEN IF UE es centrado en datos THEN Envía respuesta de SIP, por ejemplo, Respuesta de SDP 183 con CS ELSE IF UE es centrado en voz THEN Envía Respuesta de SIP, por ejemplo, Respuesta de SDP 183 con CS ELSE IF INVITE SDP sin oferta de CS THEN Envía respuesta de SIP, por ejemplo, Respuesta de SDP 183 con voz de IMS o envía de vuelta error de SIP, por ejemplo, 488. En respuesta a recibir dicho error de SIP, el nodo de red o AS de IMS se activa para seleccionar el dominio alternativo o RAT ELSE IF UE es de Voz - IMS preferida THEN IF INVITE SDP con oferta de CS THEN IF UE es centrado en datos THEN Envía respuesta de SIP, por ejemplo, Respuesta de SDP 183 con voz de IMS ELSE IF UE es centrado de voz THEN Envía respuesta de SIP, por ejemplo, Respuesta de SDP 183 con voz de IMS ELSE IF INVITE SDP sin oferta de CS THEN Envía respuesta de SIP, por ejemplo, Respuesta de SDP 183 con voz de IMS Tabla 6 Un ejemplo de lo anterior como se implementa en TS 24.292 de 3GPP se muestra a continuación: Cuando el UE de ICS recibe, dentro de una petición de SIP INVITE inicial, una oferta de SDP la cual permite al UE seleccionar entre utilizar una portadora de IP basada en RTP o una portadora de CS para una sesión de audio, es decir, en la cual para la línea de medios de audio lo siguiente se establece : - el protocolo de transporte dentro de la línea de medios a la portadora IP basada en RTP; la línea de conexión relacionada con una dirección de IP; y líneas-a adicionales como se define en draft-ietf-mmusic-sdp-capability-negotiation [40] , draft-garcia-mmusic-sdp-misc-cap [39] , draft-ietf-mmusic-sdp-cs [36] y draf -ietf-mmusic-sdp-media-capabilities [41] que indican lo siguiente : - el atributo de capacidad de medios "mcap" se establece a " - " ; - el atributo de capacidad de protocolo de transporte "tcap" se establece a "PSTN"; y - el atributo de capacidad de datos de conexión "ccap" se establece a "PSTN", que indica a "E.164" como un tipo de dirección y la dirección se establece a SCC AS PSI DN; y el UE de ICS soporta la ejecución de TADS, el UE de ICS debe, a) si el UE se encuentra en la LTE y el UE es a. solo CS y ha realizado una unión combinada exitosa entonces el UE debe utilizar la portadora de CS b. solo CS y no ha realizado una unión combinada exitosa el UE de ICS debe enviar de vuelta un 606 (No Aceptable) . i. Alternativa - Si el VoIMS sobre bandera se encuentra establecido en el UE debe utilizar portadora de IP basada en RTP . ii. Alternativa - si el VoIMS sobre bandera no se encuentra establecido entonces el UE de ICS debe enviar de vuelta un 606 (No Aceptable) . c . CS es preferida y se ha realizado una unión combinada exitosa entonces el UE debe utilizar la portadora de CS i. Alternativa - CS es preferida, se ha realizado una unión combinada exitosa, el VoIMS sobre bandera se encuentra establecido sin embargo el SDP contiene otros medios así como también voz, entonces el UE debe utilizar portadora de IP basada en RTP d. CS es preferida y no se realiza una unión combinada exitosa y el Indicador de VoIMS se encuentra establecido y i. Si el UE indica que quiere el SRVCC en la Unión de EPC como se describe en TS 24.301 de 3GPP y el SRVCC se encuentra disponible el UE debe utilizar portadora de IP basada en RTP. ii. Si el UE indica que quiere el SRVCC en el EPC Unido como se describe en TS 24.301 de 3GPP y el SRVCC no se encuentra disponible el UE de ICS debe enviar de vuelta un 606 (No Aceptable) . iii Si el UE indica que no quiere el SRVCC como se describe en TS 24.301 de 3GPP entones el UE debe utilizar portadora IP basada en RTP. e. CS es preferido y no se realiza una unión combinada exitosa y el Indicador de VoIMS no se encuentra establecido el UE de ICS debe enviar de vuelta un 606 (No Aceptable) , f . Solo el IMS y el indicador VoIMS se establecen y i . Si el UE indica que quiere el SRVCC en la Unión de EPC como se describe en TS 24.301 de 3GPP y el SRVCC se encuentra disponible el UE debe utilizar portadora de IP basada en RTP. ii. Si el UE indica que quiere el SRVCC en el EPC Unido como se describe en TS 24.301 de 3GPP y el SRVCC no se encuentra disponible el UE de ICS debe enviar de vuelta un 606 (No Aceptable) . iii Si el UE indica que no quiere el SRVCC como se describe en TS 24.301 de 3GPP entones el UE debe utilizar portadora IP basada en RTP. g. Solo el IMS y el Indicador de VoIMS no se encuentran establecidos el UE de ICS debe enviar de vuelta un 606 (No Aceptable) . h. IMS preferido y el Indicador de VoIMS se encuentran establecidos y i. Si el UE indica que quiere el SRVCC en la Unión de EPC como se describe en TS 24.301 de 3GPP y el SRVCC se encuentra disponible el UE debe utilizar portadora de IP basada en RTP. ii. Si el UE indica que quiere el SRVCC en el EPC Unido como se describe en TS 24.301 de 3GPP y el SRVCC no se encuentra disponible y 1. El UE realiza una unión combinada exitosa debe utilizar portadora de CS. 2. El UE no realiza una unión combinada exitosa el UE de ICS debe enviar de vuelta un 606 (No Aceptable) . iii Si el UE indica que no quiere el SRVCC como se describe en TS 24.301 de 3GPP entones el UE debe utilizar portadora IP basada en RTP. i. IMS es preferido y el Indicador de VoIMS no se encuentra establecido y se ha realizado una unión combinada exitosa el UE debe utiliza portadora de CS. b) si el UE se encuentra en GERAN/UTRAN basándose en configuración local y condiciones de red, decide si utiliza una portadora de IP basada en RTP o una portadora de CS para la transmisión continua de medios de audio relacionados .

Si el UE de ICS decide utilizar una portadora de IP basada en RTP, el UE de ICS debe proceder como se describe en la sub-clausula 10.2.2.2 y en adición indicar que la portadora de IP basada en RTP se utiliza dentro de la respuesta de SDP de acuerdo con draft-ietf-mmusic-sdp-capability-negotiation [40] .

Si el UE de ICS decide utilizar una portadora de CS, el UE de ICS debe proceder como se describe en la sub-clausula 10.2.2.3 y en adición indicar que la portadora de CS se utiliza dentro de la respuesta de SDP de acuerdo con draft-ietf-mmusic-sdp-capability-negotiation [40] .

La Figura 16 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, en donde el UE incluye una etiqueta de característica que se utiliza para activar el AS de IMS para incluir el CS de SDP cuando y si el UE ha tenido un registro exitoso para el CS de Reserva. Si el CS de reserva no fue exitoso puede que la etiqueta de característica no se incluya.

La etiqueta de característica puede transportarse en el registro de SIP al AS de IMS. En esta instancia, el comportamiento de AS de SCC puede cambiarse mediante la inclusión de la etiqueta. Si la etiqueta se ha incluido y una etiqueta capaz de ICS se encuentra presente, el AS de IMS puede construir mensajes de SIP hacia el UE que contiene SDP con porción de CS (véase draft-ietf-mmusic-sdp-cs ) . Sin embargo, si la etiqueta de CS de reserva no se incluye, el SDP con porción de CS no necesita incluirse.

En muchas implementaciones de red, el Indicador de VoIMS se le concede al UE por la MME o SGSN durante la unión inicial y/o TAU y/o TAU Combinada y/o actualización de RA respectivamente. Como resultado, cuando el VoIMS se proporciona por la MME y SGSN al UE, la MME y el SGSN se encuentran al tanto de si la voz de IMS puede soportarse sobre un TA o RA especifico respectivamente.

Cuando una llamada terminada móvil llega al IMS y el UE se registra con el IMS, la llamada puede enrutarse al UE. Cuando el UE acepta la llamada a enrutarse utilizando el IMS/sobre el dominio PS, el IMS puede necesitar establece las portadoras de radio necesarias para la activación de la portadora, y el IMS puede interactuar con el PCC para realizar eso.

En una implementación del presente sistema, debido a que el PCC interactúa con el EPC durante la Unión de ÑAS, Actualización de Área de Rastreo, Actualizaciones de Área de Enrutamiento, y Activación de Contexto de PDP en GERAN/UTRAN respectivamente, el PCC puede proporcionarse con el Indicador de VoIMS que aplica al TA o RA respectivamente. Como resultado, el PCC puede siempre ser informado del soporte para VoIMS en la RAT específica y área en la cual el UE se ubica .

Cuando el IMS interactúa con el PCC para establecer las portadoras para el servicio después de que el UE acepta la llamada para enrutarse utilizando el IMS/sobre el dominio de PS, basándose en la petición entrante de IMS, el PCC puede determinar si el servicio puede soportarse (por ejemplo, dependiendo del valor del Indicador de VoIMS almacenado el PCC) y aceptar o rechazar la petición de IMS. El IMS puede además proporcionar una razón o explicación para el rechazo. En respuesta a cualquier razón o explicación para el rechazo, el IMS puede decidir enrutar la llamada terminada móvil para el UE sobre el dominio de CS. Tener en cuenta que en muchos casos, si un dominio o RAT no se encuentra disponible, la sesión o llamada puede enrutarse a, por ejemplo, correo de voz .

Para establecer portadoras para el UE, el EPC puede interactuar con el PCC para realizar la vigilancia de QoS de la portadora. Un procedimiento de establecimiento de portadora puede tomar lugar sobre el UE que realiza una Unión de ÑAS a la LTE, un procedimiento de Petición de Contexto de PDP sobre GERAN/UTRAN, y/o un procedimiento de Conectividad de PDN Solicitada por el UE. Durante tal interacción, puede que se le proporcione al PCC el valor del indicador de VoIMS.

Después de que el ' IMS interactúa con el PCC para establece las portadoras para el servicio después de que el UE acepta la llamada para enrutarse sobre un Dominio de IMS/PS, el PCC puede interactuar con el EPC o la red central de GPRS para establecer las portadoras necesarias o modificar las portadoras existentes . Si el UE se ubica en un área donde el servicio no es soportado (por ejemplo, el Indicador de VoI S para TA o RA indica que el VolMS no es soportado) , entonces el UE puede rechazar la petición e informar al PCC de la razón para el rechazo. El PCC puede entonces rechazar la petición de IMS y puede opcionalmente proporcionar una razón para el rechazo. En respuesta a la razón para el rechazo, el IMS puede decidir enrutar la llamada terminada móvil para el UE sobre el dominio de CS .

La Figura 17 es una ilustración de un flujo de mensajes para establecer una conexión entre un UE y una red, en donde el UE inspecciona el indicador de VoIMS e indica que la entrega de llamada debe tomar lugar sobre una solución de OpVoice. En algunas implementaciones del presente sistema, el UE ha realizado una Unión de ÑAS o una Unión Combinada de AS. Después de eso, el UE realiza el registro de OpVoice y el registro de AppIMS en las etapas 272 y 274, respectivamente. Si el UE ha realizado exitosamente una Unión Combinada de AS, el CS de reserva puede utilizarse para entregar una sesión de OpVoice a través de la infraestructura de OpVoice en la etapa 276. De manera alternativa, si el UE ha realizado una Unión de ÑAS, el UE puede realizar un registro con la solución de OpVoice (por ejemplo VoLGA) mientras se conectado a la LTE. Las llamadas de OpVoice Terminadas Móvil pueden entregarse a la infraestructura de OpVoice y enrutarse al UE (por ejemplo, utilizando VoLGA sobre la LTE o activando procedimientos de CS de reserva) . Las llamadas de AppVoice Terminadas Móvil se entregan a la infraestructura de AppIMS y se enrutan al UE. Cuando el UE decide, basándose en el indicador de VoIMS en la etapa 278, que la llamada no puede entregarse sobre IMS, el UE puede indicar a AppIMS para entregar la llamada al reenviarla a la solución de OpVoice en la etapa 280 (que puede basarse en de CS de reserva, llamadas de CS o, por ejemplo, VoLGA. La indicación puede lograrse mediante el UE que recibe un Método de SIP, por ejemplo, un INVITE y respondiendo de vuelta con la respuesta apropiada, por ejemplo, respuesta 3xx o en particular la respuesta 302 (Movida Temporalmente) , como se ilustra en la Tabla 7. 21.3.3 302 Movida Temporalmente El cliente solicitante DEBE reintentar la petición en la o las nuevas direcciones dadas por el campo de encabezado Contact (sección 20.10). La URI solicitada de la nueva petición utiliza el valor de campo de encabezado Contact en la respuesta.

Tabla 7 En una implementación, un mensaje 302 se utiliza debido a que el UE puede encontrarse temporalmente no disponible para soportar el servicio en esta ubicación. Como tal, el mensaje 302 puede proporcionar la ubicación del servicio de OpVoice (es decir, la dirección de contacto de la entidad que proporciona el servicio de OpVoice, por ejemplo, un MSC en caso de CS de reserva o VoLGA o servicios de CS) . Los mensajes 300 y 380 pueden también utilizarse. En el evento que un UE no se encuentre configurado con la dirección de contacto de la entidad que proporciona el servicio de OpVoice, el UE puede incluir un indicador alternativo en la respuesta (por ejemplo, un cuerpo XML) . Un cuerpo XML ejemplar puede basarse en application/3gpp-ims+xml de TS 24.229 de 3GPP: <3gpp-ims version="l"> <alternati e-service> <type> <volga/> </type> <reason/> </alternative-service> </3gpp-ims> En el cuerpo XML anterior, el indicador <volga/> puede incluirse en un documento XML el cual es de aplicación tipo MIME/3gpp-ims+xml cuando se incluye en un mensaje de SIP como cuerpo de SIP (parte) . Es posible que el parámetro de tipo MDME versión esquema y el atributo de versión en el elemento 3gpp-ims se establezcan a un valor diferente de "1".

En ese caso, la inclusión del indicador <volga/> puede informar a la red que el UE desea manejar la llamada según procedimientos de volga.

Cuando el AS de IMS recibe la respuesta (por ejemplo, una respuesta 302 con el indicador <volga/>) el AS de IMS puede entonces enviar una petición de llamada terminada móvil tal como una petición SIP INVITE para la entidad considerada en el encabezado de contacto (por ejemplo el MSC el cual se encuentra conectado a la entidad VoLGA como VANC) . Entonces el VANC puede seguir los procedimientos para una llamada terminada móvil de VoLGA.

Con referencia ahora a la Figura 18, se ilustra un sistema de comunicaciones inalámbrico que incluye una modalidad de un UE 800 ejemplar. El UE es operable para implementar aspectos de esta descripción, pero la descripción no debe limitarse a estas implementaciones . Aunque se ilustra como un teléfono móvil, el UE puede tomar varias formas incluyendo un microteléfono inalámbrico, un buscapersonas , un asistente digital personal (PDA), una computadora portátil, una computadora tablet, una computadora tipo laptop, teléfonos inteligentes, impresoras, máquinas de fax, televisiones, cajas de los convertidores-descodificadores , y otros dispositivos de despliegue de video, equipo de audio en casa y otros sistema de entretenimiento en casa, sistemas de control y monitoreo casero (por ejemplo, monitoreo casero, sistemas de alarma y sistemas de control climático) , y electrodomésticos mejorados tales como refrigeradores computarizados . Muchos dispositivos adecuados combinan algunas o todas estas funciones . En algunas modalidades de esta descripción, el UE 800 no es un dispositivo de cómputo de propósito general como una computadora portátil, tipo laptop o tablet, sino que es un dispositivo de comunicaciones de propósito especial tal como un teléfono móvil, un microteléfono inalámbrico, un buscapersonas , un PDA, o un dispositivo de telecomunicaciones instalado en un vehículo. El UE 800 puede también ser un dispositivo, incluir un dispositivo, o ser incluido en un dispositivo que tiene capacidades similares pero que no es transportable, tal como una computadora de escritorio, una caja del convertidor-descodificador, o un nodo de red. El UE 800 puede soportar actividades especializadas tales como video juegos, control de inventario, control de trabajo, y/o funciones de administración de tareas, y demás.

El UE 800 incluye una pantalla 702. El UE 800 también incluye una superficie sensible al tacto, un teclado u otras teclas de entrada generalmente referidas como 704 para la entrada por un usuario. El teclado puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY, y escrituras secuenciales , o teclado numérico tradicional con letras del alfabeto asociadas con una tecla de teléfono. Las teclas de entrada pueden incluir una rueda de tracción, una tecla de salida o escape, un puntero de bola, y otras teclas de navegación o funcionales, las cuales pueden apretarse hacia dentro para proporcionar función de entrada adicional. El UE 800 puede presentar opciones para que el usuario seleccione, controles para que el usuario accione, y/o cursores u otros indicadores para que el usuario diri a .

El UE 800 puede además aceptar entradas de datos del usuario, incluyendo números para marcar o varios valores de parámetro para configurar la operación del UE 800. El UE 800 puede además ejecutar una o más aplicaciones de software o firmware en respuesta a comandos de usuario. Estas aplicaciones pueden configurar el UE 800 para realizar varias funciones personalizadas en respuesta a la interacción del usuario. Adicionalmente, el UE 800 puede programarse y/o configurarse por aire, por ejemplo desde una estación base inalámbrica, un punto de acceso inalámbrico, o un UE 800 semejante .

Entre las diversas aplicaciones ejecutables por el UE 800 existe un navegador web, el cual habilita a la pantalla 702 para mostrar una página web. La página web puede obtenerse mediante comunicaciones inalámbricas con un nodo de acceso de red inalámbrica, una torre celular, un UE 800 semejante, o cualquier otra red a sistema 700 de comunicación inalámbrica. La red 700 se acopla a una red alámbrica 708, tal como la Internet. Mediante el enlace inalámbrico y la red alámbrica, el UE 800 tiene acceso a información en varios servidores, tales como el servidor 710. El servidor 710 puede proporcionar contenido que puede mostrarse en la pantalla 702. De manera alternativa, el UE 800 puede acceder a la red 700 a través de un UE 800 semejante que actúa como un intermediario, en una conexión de tipo retransmisión o tipo salto .

La Figura 19 muestra un diagrama de bloque del UE 800. Aunque una variedad de componentes conocidos de los UA 10 se representan, en una modalidad un subconjunto de los componentes listados y/o componentes adicionales no listados pueden incluirse en el UE 800. El UE 800 incluye un procesador de señal digital (DSP) 802 y una memoria 804. Como se muestra, el UE 800 puede además incluir una antena y unidad 806 de extremo frontal, un transceptor 808 de radio frecuencia ( F) , una unidad 810 de procesamiento de banda base análoga, un micrófono 812, una bocina 814 de audífono, un puerto 816 de auricular, una interfaz 818 de entrada/salida, una tarjeta 820 de memoria removible, un puerto 822 de bus serial universal (USB) , un subsistema 824 de comunicación inalámbrica de corto alcance, una alerta 826, un teclado 828, una pantalla de cristal líquida (LCD) , la cual puede incluir una superficie 830 sensible al tacto, un controlador 832 de LCD, una cámara 834 de dispositivo de carga acoplada (CCD) , un controlador 836 de cámara, y un sensor 838 de sistema de posicionamiento global (GPS) . En una modalidad, el UE 800 puede incluir otro tipo de pantalla que no proporcione una pantalla sensible al tacto. En una modalidad, el DSP 802 puede comunicarse directamente con la memoria 804 sin pasar a través de la interfaz 818 de entrada/salida .

El DSP 802 o alguna otra forma de controlador o unidad de procesamiento central operan para controlar los diversos componentes del UE 800 de acuerdo con el software integrado o firmware almacenado en la memoria 804 o almacenado en la memoria contenida dentro del mismo DSP 802. Además al software o firmware integrado, el DSP 802 puede ejecutar otras aplicaciones almacenadas en la memoria 804 o hechas disponibles mediante medios de portadora de información tales como medios de almacenamiento de datos portátiles como la tarjeta 820 de memoria removible o mediante comunicaciones de red alámbricas o inalámbricas. El software de aplicación puede comprende un conjunto compilado de instrucciones legibles por máquinas que configuran el DSP 802 para proporcionar la funcionalidad deseada, o el software de aplicación puede ser instrucciones de software de alto nivel para procesarse mediante un intérprete o compilador para configurar indirectamente el DSP 802.

La antena y unidad 806 de extremo frontal pueden proporcionarse para convertir entre señales inalámbricas y señales eléctricas, que habilitan al UE 800 para enviar y recibir información de una red celular o alguna otra red de comunicaciones inalámbricas disponible o desde un UE 800 semejante. En una modalidad, la antena y la unidad 806 de extremo frontal pueden incluir múltiples antenas para soportar la formación de haces y/o operaciones de múltiple entrada múltiple salida (MIMO) . Como es conocido por aquellos con experiencia en la técnica, las operaciones MIMO pueden proporcionar diversidad espacial la cual puede utilizarse para superar condiciones de canal difíciles y/o incrementar la productividad de canal. La antena y unidad 806 de extremo frontal pueden incluir componentes de sintonización de antena y/o de concordancia de impedancia, amplificadores de potencia de RF, y/o amplificadores de bajo ruido.

El transceptor 808 de RF proporciona el cambio de frecuencia, convirtiendo la señales de RF recibidas en banda base y convirtiendo señales de transmisión de banda base a RF . En algunas descripciones un transceptor de radio o transceptor RF puede entenderse para incluir otra funcionalidad de procesamiento de señal tal como modulación/desmodulación, codificación/descodificación, entrelazado/desentrelazado , propagación/despropagación, transformación rápida de Fourier inversa ( IFFT) /transformación rápida de Fourier (FFT) , adición/remoción de prefijo cíclico, y otras funciones de procesamiento de señal. Para los propósitos de claridad, la descripción aquí separa la descripción de este procesamiento de señal del RF y/o etapa de radio y atribuye conceptualmente ese procesamiento de señal a la unidad 810 de procesamiento de banda base análoga y/o el DSP 802 u otra unidad de procesamiento central. En algunas modalidades, el transceptor 808 de RF, porciones de la antena y extremo 806 frontal, y la unidad 810 de procesamiento de banda base análoga pueden combinarse en una o más unidades de procesamiento y/o circuitos integrados de aplicación específica (ASIO .

La unidad 810 de procesamiento de banda base análoga puede proporcionar varios procesamientos análogos de entradas y salidas, por ejemplo procesamiento análogo de entradas a partir del micrófono 812 y el auricular 816 y se produce al audífono 814 y al auricular 816. Con este fin, la unidad 810 de procesamiento de banda base análoga puede tener puertos para conectarse al micrófono 812 incorporado y la bocina 814 de audífono que habilita al UE 800 para utilizarse como un teléfono celular. La unidad 810 de procesamiento de banda base análoga puede además incluir un puerto para conectarse a un auricular u otro micrófono manos libres y configuración de bocina. La unidad 810 de procesamiento de banda base análoga puede proporcionar conversión digital a análoga en una dirección de señal y conversión análoga a digital en la dirección de señal opuesta. En algunas modalidades, por lo menos algunas de las funcionalidades de la unidad 810 de procesamiento de banda base análoga puede proporcionarse mediante componentes de procesamiento digital, por ejemplo mediante el DSP 802 o mediante otras unidades de procesamiento central.

El DSP 802 puede realizar modulación/desmodulación, codificación/descodificación, entrelazado/desentrelazado, propagación/despropagación, transformación rápida de Fourier inversa ( IFFT) /transformación rápida de Fourier (FFT) , adición/remoción de prefijo cíclico, y otras funciones de procesamiento de señal asociadas con comunicaciones inalámbricas. En una modalidad, por ejemplo, en una aplicación de tecnología de acceso múltiple de división de código (CDMA) , para una función de transmisor el DSP 802 puede realizar modulación, codificación, entrelazado, y propagación y para la función de receptor el DSP 802 puede realizar despropagación desentrelazado, descodificación y desmodulación. En otra modalidad, por ejemplo, en una aplicación de tecnología de acceso múltiple de división de frecuencia ortogonal (OFDMA) , para la función de transmisor el DSP 802 puede realizar modulación, codificación, entrelazado, transformación rápida de Fourier inversa, y adición de prefijo cíclico, y para la función de receptor el DSP 802 puede realizar remoción de prefijo cíclico, transformación rápida de Fourier, desentrelazado, descodificación y desmodulación. En otras aplicaciones de tecnología inalámbrica, aún otras funciones de procesamiento de señal y combinaciones de funciones de procesamiento de señal pueden realizarse mediante el. DSP 802.

El DSP 802 puede comunicarse con una red inalámbrica mediante la unidad 810 de procesamiento de banda base análoga. En algunas modalidades, la comunicación puede proporcionar conectividad a Internet, habilitando al usuario ganar acceso a contenido en la Internet y para enviar y recibir correo electrónico o mensajes de texto. La interfaz 818 de entrada/salida interconecta el DSP 802 y varias memorias e interfaces. La memoria 804 y la tarjeta 820 de memoria removible pueden proporcionar software y datos para configurar la operación del DSP 802. Entre las interfaces puede encontrarse la interfaz 822 de USB y el subsistema 824 de comunicación inalámbrica de corto alcance. La interfaz 822 de USB puede utilizarse para cargar el UE 800 y puede también habilitar al UE 800 para funcionar como un dispositivo periférico para intercambiar información con una computadora personal u otro sistema de computadora. El subsistema 824 de comunicación inalámbrica de corto alcance puede incluir un puerto infrarrojo, una interfaz Bluetooth, una interfaz inalámbrica que cumple con IEEE 802.11, o cualquier otro subsistema de comunicación inalámbrica de corto alcance, el cual puede habilitar al UE 800 para comunicarse inalámbricamente con otros dispositivos móviles cercanos y/o estaciones base inalámbricas.

La interfaz 818 de entrada/salida puede además conectar el DSP 802 a la alerta 826 que, cuando se activa, causa que el UE 800 proporcione una noticia al usuario, por ejemplo, al sonar, tocar una melodía, o vibrar. La alerta 826 puede servir como un mecanismo para alertar al usuario para cualquiera de varios eventos tales como una llamada entrante, un nuevo mensaje de texto, y un recordatorio de compromiso al vibrar silenciosamente, o al tocar una melodía pre-asignada específica para una persona particular que realiza una llamada .

El teclado 828 se acopla al DSP 802 mediante la interfaz 818 para proporcionar un mecanismo para que el usuario realice selecciones, ingrese información, y de otra manera proporcione entrada al UE 800. El teclado 828 puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY, y escrituras secuenciales , o teclado numérico tradicional con letras del alfabeto asociadas con una tecla de teléfono. Las teclas de entrada pueden incluir una rueda de tracción, una tecla de salida o escape, un puntero de bola, y otras teclas de navegación o funcionales, las cuales pueden apretarse hacia dentro para proporcionar función de entrada adicional. Otro mecanismo de entrada puede ser la LCD 830, la cual puede incluir capacidad de pantalla táctil y también desplegar texto y/o gráficos al usuario. El controlador 832 de LCD acopla el DSP 802 al LCD 830.

La cámara 834 de CCD, si se encuentra equipada, habilita al UE 800 para tomar fotos digitales. El DSP 802 se comunica con la cámara 834 de CCD mediante el controlador 836 de cámara. En otra modalidad, una cámara que opera de acuerdo con una tecnología diferente a cámaras de Dispositivo de Carga Acoplada puede emplearse. El sensor 838 de GPS se acopla al DSP 802 para descodificar las señales del sistema de posicionamiento global, por consiguiente habilitando al UE 800 para determinar su posición. Diversos periféricos diferentes pueden también incluirse para proporcionar funciones adicionales, por ejemplo, recepción de radio y televisión .

La Figura 20 ilustra un entorno 902 de software que puede implementarse mediante el DSP 802. El DSP 802 ejecuta los controladores 904 de sistema operativo que proporcionan una plataforma a partir de la cual el resto del software opera. Los controladores 904 de sistema operativo proporcionan controladores para el hardware del UA con interfaces es andarizadas que son accesibles para el software de aplicación. Los controladores 904 de sistema operativo incluyen servicios de administración de aplicación ( "AMS " ) 906 que transfieren el control entre aplicaciones en ejecución en el UE 800. También mostrados en la Figura 20 se encuentra una aplicación 908 de navegador web, una aplicación 910 de reproductor de medios, y applets 912 Java. La aplicación 908 de navegador web se configura al UE 800 para operar como un navegador web, permitiendo al usuario ingresar información dentro de formas y seleccionar enlaces para recuperar y observar páginas web. La aplicación 910 de reproductor de medios configura al UE 800 para recuperar y reproducir medios de audio o audiovisuales. Las applets 912 Java configuran el UE 800 para proporcionar juegos, utilidades, y otras funcionalidades, un componente 914 puede proporcionar la funcionalidad descrita en la presente.

El UE 800, dispositivo 120 de acceso, y otros componentes descritos en lo anterior pueden incluir un componente de procesamiento que es capaz de ejecutar instrucciones relacionadas a las acciones descritas en lo anterior. La Figura 21 ilustra un ejemplo del sistema 1000 que incluye un componente 1010 de procesamiento adecuado para implementar una o más modalidades descritas en la presente. Además al procesador 1010 (el cual puede ser referido como una unidad de procesador central (CPU o DSP) , el sistema 1000 puede incluir dispositivos 1020 de conectividad de red, memoria de acceso aleatorio (RAM) 1030, memoria de solo lectura (ROM) 1040, almacenamiento 1050 secundario, y dispositivos 1060 de entrada/salida (I/O) . En algunas modalidades, un programa para implementar la determinación de un número mínimo de ID de proceso HARQ pueden almacenarse en la ROM 1040. En algunos casos, algunos de estos componentes pueden no encontrarse presentes o pueden encontrarse combinados en varias combinaciones uno con el otro o con otros componentes no mostrados. Estos componentes pueden encontrarse ubicados en una sola entidad física o en más de una entidad física. Cualesquier acciones descritas en la presente como se toman por el procesador 1010 pueden tomarse por el procesador 1010 por si solo o por el procesador 1010 junto con uno o más componentes mostrados o no mostrados en el dibujo.

El procesador 1010 ejecuta instrucciones, códigos, programas de computadora, o conjuntos de instrucciones a las que puede acceder desde los dispositivos 1020 de conectividad de red, RAM 1030, ROM 1040, o almacenamiento 1050 secundario (el cual puede incluir varios sistema basados en disco tales como disco duro, disco flexible, o disco óptico. Aunque solo se muestra un procesador 1010, múltiples procesadores pueden encontrarse presentes. De este modo, aunque las instrucciones pueden discutirse como ejecutadas por un procesador, las instrucciones pueden ejecutarse de manera simultánea, en serie, o de otra manera por uno o múltiples procesadores. El procesador 1010 puede implementarse como uno o más chips de CPU.

Los dispositivos 1020 de conectividad de red pueden tomar la forma de módems, bancos de módem, dispositivos de Ethernet, dispositivos de interfaz de bus serial universal (USB) , interfaces seriales, dispositivos de anillo de control por prenda, dispositivos de interfaz de datos distribuidos por fibra (FDDI) , dispositivos de red de área local inalámbrica (WLA ) , dispositivos transceptores de radio tales como dispositivos de acceso múltiple de división de código (CDMA) , dispositivos transceptores de radio de sistema global para comunicaciones móviles (GSM) , dispositivos de interoperabilidad mundial para acceso por microondas (WiMAX) , y/u otros dispositivos bien conocidos para conectarse a redes. Estos dispositivos 1020 de conectividad de red pueden habilitar al procesador 1010 para comunicarse con la Internet o una o más redes de telecomunicaciones u otras redes desde las cuales el procesador 1010 puede recibir información o para las cuales el procesador 1010 puede producir información .

Los dispositivos 1020 de conectividad de red pueden también incluir uno o más componentes 1025 de transceptor capaces de transmitir y/o recibir datos inalámbricamente en la forma de ondas electromagnéticas, tales como señales de radiofrecuencia o señales de frecuencia de microonda. De manera alternativa, los datos pueden propagarse dentro o en la superficie de conductores eléctricos, en cables coaxiales, en guías de onda, en medios ópticos tales como fibra óptica, o en otros medios. El componente 1025 transceptor puede incluir unidades de recepción y transmisión separadas o un solo transceptor. La información transmitida o recibida por el transceptor 1025 puede incluir datos que se han procesado por el procesador 1010 o instrucciones que deben ejecutarse por el procesador 1010. Tal información puede recibirse de y producirse a una red en la forma de, por ejemplo, una señal de banda base de datos de computadora o señal integrada en una onda portadora. Los datos pueden ordenarse de acuerdo con diferentes secuencias como sean deseables para ya sea procesar o generar los datos o transmitir o recibir los datos. La señal de banda base, la señal integrada en la onda portadora, u otros tipos de señales actualmente utilizadas o desarrolladas de aquí en adelante pueden ser referidas como el medio de transmisión y pueden generarse de acuerdo con muchos métodos conocidos por aquel con experiencia en la técnica .

La RAM 1030 puede utilizarse para almacenar datos volátiles y quizás para almacenar instrucciones que son ejecutadas por el procesador 1010. La ROM 1040 es un dispositivo de memoria no volátil que típicamente tiene una menor capacidad de memoria que la capacidad de memoria del almacenamiento 1050 secundario. La ROM 1040 puede utilizarse para almacenar instrucciones y quizás datos que son leídos durante la ejecución de las instrucciones. El acceso tanto a la RAM 1030 como la ROM 1040 es típicamente más rápido que el del almacenamiento 1050 secundario. El almacenamiento 1050 secundario típicamente comprende una o más unidades de disco o unidades de cinta y puede utilizarse para el almacenamiento no volátil de datos o como un dispositivo de almacenamiento de datos de desbordamiento si la RAM 1030 no es lo suficientemente grande para mantener todos los datos funcionales. El almacenamiento 1050 secundario puede utilizarse para almacenar programas que se cargan dentro de la RAM 1030 cuando tales programas son seleccionados para e ecución.

Los dispositivos 1060 I/O pueden incluir pantallas de cristal líquido (LCD) , pantallas táctiles, teclados, teclados numéricos, interruptores, cuadrante giratorio, ratones, punteros de bola, reconocedores de voz, lectores de tarjetas, lectores de cinta de papel, impresoras, monitores de video, u otros dispositivos de entrada bien conocidos. También, el transceptor 1025 puede considerarse como un componente de los dispositivos 1060 I/O en vez de o en adición a ser un componente de los dispositivos 1020 de conectividad de red. Algunos o todos los dispositivos 1060 I/O pueden ser sustancialmente similares a varios componentes representados en el dibujo previamente descrito del UE 800, tal como la pantalla 702 y la entrada 704.

Aunque se han proporcionado varias modalidades en la presente descripción, debe entenderse que los sistemas y métodos descritos pueden representarse en muchas otras formas específicas sin apartarse del espíritu o alcance de la presente descripción. Los presentes ejemplos deben considerarse como ilustrativos y no restrictivos, y la intención es no limitarse a los detalles dados en la presente. Por ejemplo, los varios elementos o componentes pueden combinarse o se integrados en otro sistema o ciertas características pueden omitirse, o no ser implementadas .

También, técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las varias modalidades como discretos o separados pueden combinarse o ser integrados con otros sistemas, módulos, técnicas, o métodos sin apartarse del alcance de la presente descripción. Otros artículos mostrados o descritos como acoplados o directamente acoplados o en comunicación uno con otro pueden acoplarse indirectamente o de manera comunicativa a través de alguna interfaz, dispositivo, o componente intermedio, ya sea eléctricamente, de manera mecánica, o de otra manera. Otros ejemplos de cambios, sustituciones, y alteraciones pueden comprobarse por alguien con experiencia en la técnica y se pueden realizar sin apartarse del espíritu y alcance descrito en la presente.

Claims (30)

REIVINDICACIONES

1. Un método para acceder a servicios de voz utilizando un equipo de usuario en un sistema de comunicación que soporta por lo menos un dominio conmutado por paquete y un dominio conmutado por circuito, el método caracterizado porque comprende : recibir un primer mensaje en el equipo de usuario, el primer mensaje incluye una indicación de sesión de audio; y enviar un segundo mensaje en respuesta al primer mensaje, el segundo mensaje basado en uno o más indicadores de servicio de voz que comprenden por lo menos un valor.

2. El método de conformidad con la reivindicación 1, caracterizado porque el primer y segundo mensajes son mensajes de SIP, los mensajes de SIP son por lo menos un mensaje de petición de SIP y un mensaje de respuesta de SIP, en donde los mensajes de SIP comprenden una porción de línea de comando, una porción de encabezado y una porción de cuerpo de mensaje, la porción de cuerpo de mensaje contiene protocolos de descripción de sesión que indican medios de voz; la porción de cuerpo de mensaje incluye medios de voz para por lo menos un dominio conmutado por circuito y dominio conmutado de paquete sobre Protocolo de Internet.

3. El método de conformidad con la reivindicación 1, caracterizado porque al recibir el primer mensaje, el equipo de usuario analiza las opciones de protocolo de descripción de sesión recibidas contra las opciones de equipo de usuario para soportar el servicio deseado sobre por lo menos un dominio conmutado por paquete y el dominio conmutado por circuito.

4. El método de conformidad con la reivindicación 1, caracterizado porque por lo menos un valor se establece a cualquiera de: solo voz conmutada por circuito; solo voz conmutada por paquete de Subsistema de Multimedia de IP; voz conmutada por circuito preferida, voz de Subsistema de Multimedia de IP secundaria; y voz de Subsistema de Multimedia de IP preferida, voz conmutada por circuito secundaria.

5. El método de conformidad con la reivindicación 1, caracterizado porque uno o más indicadores de servicios de voz incluyen por lo menos uno de: ajustes de voz de equipo de usuario; ajustes de uso de equipo de usuario; voz de Subsistema de Multimedia de IP sobre indicadores conmutados por paquete; ajuste de continuidad de llamada de voz de radio sencilla; y una preferencia.

6. El método de conformidad con la reivindicación 5, caracterizado porque el valor de los ajustes de uso del equipo de usuario comprenden uno de centrado en voz o centrado en datos

7. El método de conformidad con la reivindicación 5, caracterizado porque la preferencia aplica a una red de acceso, la preferencia es una preferencia de operador.

8. El método de conformidad con la reivindicación 2, caracterizado porque al recibir el mensaje de petición de SIP con el protocolo de descripción de sesión, el equipo de usuario compara el protocolo de descripción de sesión con por lo menos un valor de los indicadores de servicio de voz para decidir cómo procesar el mensaje de petición de SIP.

9. El método de conformidad con la reivindicación 8, caracterizado porque la decisión de cómo procesar la petición comprende aceptar una llamada sobre un dominio conmutado por paquete o realizar una llamada terminada móvil sobre el dominio conmutado por circuito.

10. El método de conformidad con la reivindicación 1, caracterizado porque enviar el segundo mensaje además comprende: enviar una respuesta que indica no seleccionar un dominio alternativo.

11. El método de conformidad con la reivindicación 1, caracterizado porque enviar el segundo mensaje además comprende: enviar una respuesta no aceptable.

12. El método de conformidad con la reivindicación 1, antes de enviar un segundo mensaje en respuesta al primer mensaje, caracterizado además porque comprende: detectar si un procedimiento de unión combinado es exitoso.

13. El método de conformidad con la reivindicación 12, caracterizado porque si el procedimiento de unión combinado es exitoso, entonces envía el segundo mensaje que además comprende incluir un componente de medios de protocolo de descripción de sesión para la entrega de medios sobre un dominio conmutado por circuito.

14. El método de conformidad con la reivindicación 12, caracterizado porque un procedimiento de unión combinado exitoso puede incluir un registro para CS de Reserva

15. El método de conformidad con la reivindicación 12, caracterizado porque si el procedimiento de unión combinado no es exitoso, entonces envía el segundo mensaje que además comprende por lo menos enviar una respuesta no aceptable y enviar un segundo mensaje que indica no seleccionar un dominio alternativo.

16. El método de conformidad con la reivindicación 2, caracterizado porque la respuesta de SIP es por lo menos una de; una respuesta de SIP de información lxx, una respuesta de SIP Exitosa 2xx, una respuesta de SIP de Redirección 3xx, una respuesta de SIP de Petición Fallida 4xx y una respuesta de SIP de Fallo General 6xx.

17. El método de conformidad con la reivindicación 1, antes de enviar un segundo mensaje en respuesta al primer mensaje, caracterizado además porque comprende: detectar si un procedimiento de actualización de área de rastreo combinado es exitoso.

18. El método de conformidad con la reivindicación 17, caracterizado porque si el procedimiento de actualización de área de rastreo combinado es exitoso, entonces envía el segundo mensaje que además comprende incluir un componente de medios de SDP para la entrega de medios sobre un dominio conmutado por circuito.

19. El método de conformidad con la reivindicación 17, caracterizado porque un procedimiento de actualización de área de rastreo combinado exitoso puede incluir un registro para el procedimiento de reserva conmutado por circuito.

20. El método de conformidad con la reivindicación 17, caracterizado porque si el procedimiento de actualización de área de rastreo no es exitoso, entonces envía el segundo mensaje que además comprende por lo menos enviar una respuesta no aceptable y enviar un segundo mensaje que indica no seleccionar un dominio alternativo.

21. El método de conformidad con la reivindicación 4, caracterizado porque los indicadores de servicio de voz se proporcionan al UE mediante la MME o SGSN durante una o más de las uniones iniciales, actualizaciones de área de rastreo, actualizaciones de área de rastreo combinadas y actualizaciones de Área de Enrutamiento (RA) .

22. El método de conformidad con la reivindicación 1, caracterizado porque los servicios de voz pueden proporcionarse por uno o más de: Red de Acceso de Radio GPRS/EDGE (GERA ) , Red de Acceso de Radio Terrestre Universal (UTRAN) , Conmutado por Circuito (CS) , Subsistema de Multimedia de Protocolo de Internet (IMS), una solución híbrida donde CS se utiliza para proporcionar la portadora de voz y el IMS se utiliza para controlar la portadora de voz de Servicios Centralizados de IMS (ICS) , UTRAN Mejorada (E-UTRAN) , y red de Evolución a Largo Plazo (LTE) .

23. El método de conformidad con la reivindicación 1, caracterizado además porque comprende detectar si las interfaces de CS y Gm pueden encontrarse activas al mismo tiempo, en donde si las interfaces conmutadas por circuito y Gm no pueden encontrarse activas al mismo tiempo, entonces utiliza un II entre el equipo de usuario y una red sobre circuito conmutado.

24. El método de conformidad con la reivindicación 1, caracterizado además porque comprende detectar si el canal de control de SIP y portadora de CS pueden utilizarse concurrentemente, en donde si el canal de control de SIP y portadora conmutada por circuito no pueden utilizarse concurrentemente, entonces utiliza un II entre el equipo de usuario y una red sobre circuito conmutado.

25. El método de conformidad con la reivindicación 1, caracterizado además porque comprende detectar si el modo de transferencia dual es soportado, en donde si el modo de transferencia dual no es soportado, entonces utiliza un II entre el equipo de usuario y una red sobre circuito conmutado.

26. Un método para acceder a servicios de voz utilizando un equipo de usuario en un sistema de comunicación que soporta por lo menos un dominio conmutado por paquete y un dominio conmutado por circuito, el método caracterizado porque com rende: recibir un primer mensaje para los servicios de voz en el equipo de usuario; detectar si un procedimiento de unión combinado es exitoso; enviar un segundo mensaje en respuesta al primer mensaje, el segundo mensaje se basa en la detección de si el procedimiento de unión combinada es o no exitoso.

27. Un sistema para acceder a servicios de voz en un sistema de comunicación que soporta por lo menos un dominio conmutado por paquete y un dominio conmutado por circuito, el sistema caracterizado porque comprende: un equipo de usuario, el equipo de usuario se configura para recibir un primer mensaje y enviar un segundo mensaje en respuesta al primer mensaje.

28. El sistema de conformidad con la reivindicación 27, caracterizado porque el primer mensaje incluye una indicación de sesión de audio.

29. El sistema de conformidad con la reivindicación 27, caracterizado porque el segundo mensaje se basa en uno o más indicadores de servicio de voz que comprenden por lo menos un valor .

30. El sistema de conformidad con la reivindicación 27, caracterizado porque el equipo de usuario además se configura para soportar un procedimiento de reserva conmutado por circuito.