ES2390813T3 - Determinación de un tipo de canal para ser solicitado en caso de un procedimiento de cambio de circuito conmutado - Google Patents

Abstract

Un método implementado por un dispositivo inalámbrico (10) para cambiar a circuitos conmutados CS desde unaprimera red (12) que no proporciona servicios del dominio de CS de circuitos conmutados, comprendiendo elmétodo:recibir desde la primera red (12) un mensaje de localización (72) para cambio a circuitos conmutados a unared de circuitos conmutados (14, 74, 78);determinar un tipo de canal adecuado para un servicio indicado por la información en el mensaje delocalización (72);transmitir un mensaje de solicitud (76) para iniciar el establecimiento de una conexión de radio de circuitosconmutados, identificando el mensaje de información (76) el tipo de canal adecuado; y,utilizar el servicio en la red de circuitos conmutados (14, 74, 78).

Description

Determinación de un tipo de canal para ser solicitado en caso de un procedimiento de cambio de circuito conmutado.

ANTECEDENTES La presente descripción se refiere generalmente a sistemas y métodos para comunicaciones entre un dispositivo inalámbrico o un agente de usuario (UA – User Agent, en inglés) y una red y, más particularmente, a sistemas y métodos para coordinar recursos de comunicaciones entre dispositivos inalámbricos y redes que incluyen las redes de circuitos conmutados.

Tal como se utiliza en esta memoria, el término “agente de usuario” o UA (User Agent, en inglés) puede referirse a dispositivos inalámbricos tales como teléfonos móviles, asistentes digitales personales (PDAs – Personal Digital Assitants, en inglés), ordenadores de sujeción manual o portátiles de regazo, y dispositivos similares, incluyendo estaciones de telefonía móvil (MS – Mobile Stations, en inglés) o equipos de usuario (UE – User Equipment, en inglés) que tienen capacidades de telecomunicaciones. En algunas realizaciones, un UA puede referirse a un dispositivo inalámbrico de telefonía móvil. El término “UA” puede también referirse a dispositivos que tienen capacidades similares pero que no son generalmente transportables, tales como los ordenadores de sobremesa, cajas para encima del televisor o nodos de red.

Un UA puede operar en una red de comunicación inalámbrica que proporciona comunicaciones de datos y/o de voz de alta velocidad. Las redes de comunicación inalámbrica pueden implementar protocolos de comunicación de circuitos conmutados (CS – Circuit Switched, en inglés) y/o de paquetes conmutados (PS – Packet Switched, en inglés) para proporcionar varios servicios. Por ejemplo, el UA puede operar de acuerdo con una o más de una Red de Acceso por Radio Terrestre Universal Mejorada (E-UTRAN - Enhanced Universal Terrestrial Radio Access Network, en inglés), Red de Acceso por Radio Terrestre Universal (UTRAN – Universal Terrestrial Radio Access Network, en inglés), red de Sistema Global para Comunicaciones mediante Telefonía Móvil (GSM – Global System for Mobile Comunications, en inglés), Evolución – Datos Optimizados (EV-DO – Evolution-Data Optimizad, en inglés), Telecomunicaciones Inalámbricas Mejoradas digitales (DECT – Digital Enhanced Cordless Telecommunications, en inglés), AMPS Digital (IS-136/TDMA), Red Mejorada Digital Integrada (iDEN – Integrated Digital Enhanced Network, en inglés), Sistema de Telecomunicaciones mediante Telefonía Móvil Universal (UMTS – Universal Mobile Telecommunications System, en inglés), Tasas de Datos Mejoradas para Evolución de GSM (EDGE – Enhanced Data rates for GSM Evolución, en inglés), Red de Acceso por Radio de GPRS/EDGE (GERAN – Gprs/Edge Radio Access Network, en inglés) y tecnología de Servicio de Radio en paquetes General (GPRS – General Packet Radio Service, en inglés). Otras redes inalámbricas en las cuales pueden operar los UAs incluyen pero no están limitadas a Acceso Múltiple por División de Código (CDMA – Code Division Multiple Access, en inglés), cdma2000, cdma2000 1xRTT, cdma2000 HRPD, WLAN (por ejemplo IEEE 802.11) y WRAN (por ejemplo IEEE 802.22). Los UAs pueden también operar en entornos de red fijos tales como, por ejemplo, entornos de Línea de Abonado Digital (xDSL – xDigital Subscriber Line, en inglés), redes de cable de Especificación de Interfaz de Servicio de Datos Sobre Cable (DOCSIS – Data Over Cable Service Interface Specification, en inglés), Redes deÁrea Personales Inalámbricas (PAN – Wireless Personal Area Networks, en inglés), Bluetooth, ZigBee, Redes deÁrea Metropolitana (MAN – Metropolitan Area Networks, en inglés) Inalámbricas (por ejemplo, WiMAX, IEEE 802.20, IEEE 802.22 Ethernet) o redes ópticas. Algunos UAs pueden ser capaces de operación de multimodo, donde pueden operar en más de una tecnología de red de acceso bien en una única red de acceso de cada vez o en algunos dispositivos que utilizan múltiples tecnologías de acceso simultáneamente.

En los sistemas de telecomunicaciones inalámbricos, el equipo de transmisión en una estación de base transmite señales en una región geográfica conocida como celda. A medida que la tecnología ha evolucionado, se han introducido equipos más avanzados que pueden proporcionar servicios que no eran posibles previamente. Estos equipos avanzados podrían incluir, por ejemplo, un Nodo B (eNB) de red de acceso por radio terrestre universal evolucionado (E-UTRAN - Evolved Universal Terrestrial Radio Access Network, en inglés) en lugar de una estación de base o de otros sistemas y dispositivos que están más altamente evolucionados que los equipos equivalentes en un sistema de telecomunicaciones inalámbrico tradicional. Tal equipo avanzado o de siguiente generación puede ser denominado en esta memoria equipo de Evolución a Largo Plazo (LTE – Long Term Evolution, en inglés), y una red basada en paquetes que utiliza tal equipo puede denominarse un sistema de paquetes evolucionado (EPS – Evolved Packet System, en inglés). Tal como se utiliza en esta memoria, el término “dispositivo de acceso” se referirá a cualquier componente, tal como una estación de base tradicional, eNB, u otro dispositivo de acceso de LTE, que puede proporcionar a un UA acceso a otros componentes en un sistema de telecomunicaciones.

Las diferentes redes descritas anteriormente proporcionan diferentes servicios a los UAs conectados. Algunas redes, por ejemplo, proporcionan sólo servicios de PS y no pueden proporcionar voz de CS u otros servicios del dominio de CS. Así, un UA puede estar configurado para conectarse a múltiples tipos de redes para acceder a servicios tanto del dominio de PS como de CS. Por ejemplo, si un UA está conectado a una primera celda de red que no proporciona servicio del dominio de CS, el UA puede ser configurado para implementar un procedimiento de cambio a CS, lo que puede denominarse en esta memoria “cambio a CS”, para conectarse a una red accesible tal como una GERAN o una Red de Acceso por Radio Terrestre Universal (UTRAN – Universal Terrestrial Radio Access Network, en inglés) para acceder a servicios de voz u otros del dominio de CS proporcionados por esas redes, tal como se describe en el documento TS 23.272 del 3GPP. Así, el procedimiento de cambio a CS permite a un UA conectado a una red que utiliza una primera tecnología de acceso por radio (RAT – Radio Access Technology, en inglés) y que proporciona sólo servicios del dominio de PS, conectarse a otra red que proporciona servicios del dominio de CS. El cambio a CS puede ser utilizado cuando, en el momento de inicio de la llamada de voz, el UA estaba asociado a una celda de una red que sólo proporciona servicio del dominio de PS. El UA que inicia la llamada de voz puede estar en reposo o conectado (por ejemplo, activo) en la celda de la red que sólo proporciona servicios del dominio de PS. En el caso de que el UA esté en reposo, puede decirse que se encuentra en la celda y puede estar monitorizando el canal de localización para esa celda para localizar mensajes para sesiones o llamadas terminadas en un teléfono móvil.

En el caso de que el UA esté conectado, puede estar comunicándose con la celda y transfiriendo datos para un servicio del dominio de PS.

Volviendo a la Fig. 1, se ilustra un ejemplo del proceso de cambio a CS mediante el cual un UA 10 se mueve de una celda de la red E-UTRAN a una celda de la GERAN o la UTRAN 14 para acceder a servicios del dominio de CS para iniciar una llamada de voz. Como se describirá, para facilitar el cambio a CS, el UA 10 puede estar configurado para comunicarse con redes basadas tanto en PS como en CS. Por ejemplo, el UA 10 puede soportar procedimientos combinados para conexión a EPS / Identidad de Abonado de Telefonía Móvil de Internacional (IMSI – International Mobile Subscriber Identity, en inglés) y actualización de Área de Rastreo para registrarse en una Entidad de Gestión de Movilidad (MME – Mobility Management Entity, en inglés) para acceder a servicios del dominio de PS (por ejemplo, a través de una red de acceso E-UTRAN, UTRAN o GERAN) y para registrarse en un Centro de Conmutación de Telefonía Móvil (MSC – Mobile Switching Center, en inglés) para acceder a servicios del dominio de CS (por ejemplo, a través de la red de acceso UTRAN o GERAN o de otra red que soporta servicios del dominio de CS). Los procedimientos combinados permiten también al MSC y a la MME crear una asociación entre ellos de manera que cada uno esté enterado de que el UA 10 está simultáneamente registrado tanto en el MSC como en la MME y de que, por tanto, el UA 10 está registrado tanto en la red de PS como en la de CS.

La Fig. 2 es un diagrama de flujo de datos que ilustra un flujo de datos de ejemplo para un procedimiento de cambio a CS terminado en un teléfono móvil donde el UA 10 en modo conectado es redirigido a la GERAN o a la UTRAN. En la Fig. 1, el UA 10 está inicialmente conectado a la celda de E-UTRAN 12. Debido a que la celda de E-UTRAN 12 no proporciona servicios del dominio de CS, el UA 10 implementa un cambio a CS para comunicarse con la celda de la GERAN o de la UTRAN 14 para acceder a servicios del dominio de CS proporcionados por ellas.

A modo de ejemplo, se describirá un cambio de celda asistido por la red (NACC – Network Assisted Cell Change, en inglés) relativo a una llamada de voz originada en un teléfono móvil. En referencia a las Figs. 1 y 2, el proceso de ejemplo empieza cuando un MSC 16 envía una localización para CS 18 a una MME 20, que a su vez solicita a la MME 20 que envía una localización 22 de notificación de servicio de CS al UA 10. En la Fig. 1 las comunicaciones desde la celda de la E-UTRAN 12 se indican mediante la flecha 23 y las comunicaciones desde el UA 10 a la celda de la E-UTRAN 12 se indican mediante la flecha 25. En respuesta a la localización 22 de notificación de servicio de CS, el UA 10 envía una solicitud de servicio Extendido 24 al eNB 26 de la celda de E-UTRAN 12. No obstante, la celda de E-UTRAN no está configurada para proporcionar servicios del dominio de CS. Así, la MME 20 envia un mensaje de protocolo de aplicación S1 (S1-AP – S1-Application Protocol, en inglés) con un indicador 30 de cambio a CS al eNB 26.

Para racionalizar el flujo de datos de ejemplo, la Fig. 2 indica algunos flujos de datos mediante cajas, tales como el informe de medida 32 opcional que puede ser proporcionado por el UA 10 para indicar información, tal como la potencia de señal y otros de las celdas vecinas a las cuales puede ser asignado. Eso es, cuando se lleva a cabo un cambio a CS, el UA 10 puede estar en la mejor posición para determinar qué celda o celdas son celdas candidatas a la cual o a las cuales cambiarse. De este modo, el UA 10 puede detectar qué celdas están muy cerca o tienen una potencia o calidad de señal recibida particularmente fuerte (u otros parámetros de ese tipo), y por ello, con qué celdas tendría probablemente el UA 10 una conexión correcta después del proceso de cambio a CS. De acuerdo con esto, durante el proceso de cambio a CS, el UA 10 puede llevar a cabo una etapa de medición para detectar e identificar las celdas accesibles al UA 10. En otras palabras, antes de cambiarse a una celda que proporciona servicio del dominio de CS, el UA 10 puede buscar celdas de red candidatas disponibles mediante un proceso de medida.

El eNodoB (eNB) puede activar una orden de cambio de celda inter-RAT, opcionalmente con la señal de NACC 34 que es enviada al UA 10; alternativamente se señala 36 una liberación de conexión con redireccionamiento. El eNB 26 indica, de acuerdo con el S1-AP, una solicitud de liberación de contexto 38 del UA a la MME 20. A continuación,tienen lugar la liberación de contexto del UA de S1 40, una actualización del área de ubicación (LA – Location Área, en inglés), una actualización combinada de área de encaminamiento (RA – Routing Area, en inglés) / LA, una actualización de la RA o una actualización de la LA y una actualización de la RA 42 en la nueva celda de GERAN o de UTRAN. Si la RAT de objetivo es GERAN, puede tener lugar una suspensión de los servicios de PS si la nueva celda o el UA no soportan servicios de CS y de PS simultáneos. En este caso, un mensaje de suspensión 44 es enviado desde el UA 10 hasta un sistema de estación de base (BSS – Base Station System, en inglés) usuario, que es a continuación comunicado desde el BSS 46 hasta un Nodo de Soporte de GPRS de Servicio (SGSN – Serving Gprs (Radio en paquetes General - General packet Radio Service, en inglés) Support Node, en inglés) 48. A continuación, se comunica una solicitud/respuesta de suspensión 50 entre el SGSN 48 y la MME 20 y tiene lugar una actualización del portador o portadores 52 entre la MME 20 y una puerta de enlace de servicio (S-GW – Serving

-

Gateway, en inglés) 54.

El UA 10 señala una respuesta de localización 56 al BSS/RNS 46, que a su vez envía esta respuesta de localización al MSC 16. Si el cambio a CS conlleva un cambio del MSC 16, pueden llevarse a cabo etapas adicionales, como se indica en la caja 58, tales como comunicar un rechazo de conexión 60 desde el MSC 16 al BSS/RNS 46, comunicar una liberación de conexión 62 desde el BSS/RNS 46 al UA 10, y una actualización de LA o actualización combinada de RA/LA 64. Finalmente, tiene lugar un procedimiento de establecimiento de llamada de CS 66, de manera que, como se indica en la Fig. 1, el UA 10 puede pasar, como se indica mediante la flecha 68, de comunicarse con la celda de E-UTRAN 12 a comunicarse, como se indica mediante la flecha 70, con la celda de la GERAN o de la UTRAN 14 sobre un canal de CS.

Cuando se implementa el cambio a CS, el retardo puede ser un problema. Si el UA 10 se encuentra inicialmente en la celda de la E-UTRAN 12 y desea acceder a servicios de voz CS en la celda de la GERAN o de la UTRAN 14, puede ejecutarse un proceso de cambio a CS. Aunque el procedimiento de establecimiento de conexión de control de recurso de radio (RRC – Radio Resource Control, en inglés) del proceso de cambio a CS puede ser relativamente corto (por ejemplo, aproximadamente 150 ms es un tiempo de objetivo para el diseño del sistema de E-UTRA), las etapas de medida y una etapa para seleccionar la celda de objetivo para los servicios de voz CS pueden potencialmente llevar una significativa cantidad de tiempo. De este modo, el cambio a CS puede ser retardado, lo que resulta en retardos en el establecimiento de los servicios de voz CS, posiblemente retardando el establecimiento de una conexión para el usuario o afectando negativamente a otros servicios a los que el UA 10 accede.

Además de esta posibilidad de que un usuario experimente un retardo perceptible en los servicios, el cambio a CS puede resultar en usos ineficientes o inapropiados de los recursos de la red. Por ejemplo, cuando un UA es localizado en una red GERAN o en una UTRAN para una llamada que finaliza en un teléfono móvil, algo de información es comunicada por la red en el mensaje de localización. Esto es, el mensaje de localización puede proporcionar una indicación de un servicio para el cual el UA está localizado, o una indicación del tipo de canal de radio apropiado para soportar el servicio. De manera similar, en el caso de una llamada originada en un teléfono móvil (MO – Mobile Oriented, en inglés), el UA está indicando a la red una causa de establecimiento que se refleja en el servicio o en el tipo de canal solicitado. Así, la red puede asignar razonablemente canales apropiados para la comunicación deseada.

No obstante, tal información no está disponible en las interfaces de la E-UTRAN correspondientes utilizadas cuando se inicia el procedimiento de cambio a CS, o bien está disponible pero no es evaluada para solicitar/asignar los canales de radio en la GERAN, la UTRAN o la E-UTRAN. En consecuencia, la red puede decidir asignar recursos no óptimos, tales como un canal de señalización para el servicio de una llamada de voz, que puede afectar al rendimiento del cambio a CS, o un canal de tráfico para proporcionar servicio a un procedimiento de señalización, provocando una pérdida del recurso de radio.

De este modo, los sistemas y métodos que solucionan los problemas listados anteriormente y permiten el establecimiento y el uso de recursos óptimos para el cambio a CS proporcionarían una mejora útil en la técnica.

La presente descripción proporciona un sistema y un método para cambio a Circuitos Conmutados (CS – Circuit Switched, en inglés) y, específicamente, para minimizar el retardo, optimizar la asignación del recurso de radio y mejorar la fiabilidad del cambio a CS.

La invención se refiere a un método para el cambio a CS de acuerdo con la reivindicación 1, a un dispositivo de comunicación de telefonía móvil de acuerdo con la reivindicación 9 y a un medio legible por ordenador de acuerdo con la reivindicación 10.

BREVE DESCRIPCIÓN DE LOS DIBUJOS En los dibujos que se acompañan, números de referencia iguales representan partes u operaciones iguales.

La Fig. 1 es una ilustración de un proceso de cambio a CS de ejemplo en el que un UE se desplaza desde una celda de la E-UTRAN hasta una celda de la GERAN o de la UTRAN para acceder a servicios del dominio de CS para iniciar una llamada de voz;

la Fig. 2 es un diagrama de flujo de datos que ilustra un flujo de datos de ejemplo para un procedimiento de cambio a CS que finaliza en un Teléfono Móvil donde un UA en modo conectado es redirigido a la GERAN o a la UTRAN sin Transferencia de PS; la Fig. 3 es un diagrama de flujo de datos que ilustra una iniciación de llamada que finaliza en un Teléfono Móvil en una red GERAN donde el UA está en modo de reposo; la Fig. 4 es un diagrama de flujo de datos que ilustra una iniciación de llamada que finaliza en un Teléfono Móvil de ejemplo en una red UTRAN donde el UA está en modo de reposo; la Fig. 5 es un diagrama de flujo de datos que ilustra un procedimiento de cambio a CS que se origina en un Teléfono Móvil con Transferencia de Paquetes Conmutados iniciada en una red E-UTRAN, la Fig. 6 es una ilustración de un flujo de datos para implementar un cambio a CS que finaliza en un Teléfono Móvil donde la información relativa a un servicio es pasada al UA en modo de reposo dentro de un mensaje de localización; la Fig. 7 muestra un diagrama de bloques del equipo de usuario (UE – User Equipment, en inglés); la Fig. 8 ilustra un entorno de software que puede ser implementado mediante un procesador de un equipo de usuario; y la Fig. 9 ilustra un ejemplo de un sistema que incluye un componente de procedimiento adecuado para implementar un método para proporcionar continuidad para sesiones que se están moviendo de una red a otra.

DESCRIPCIÓN DETALLADA Los diferentes aspectos de la descripción se describen ahora con referencia a los dibujos adjuntos, en los que números iguales se refieren a elementos iguales o correspondientes en este documento.

Como se utiliza en esta memoria, los términos “componente”, “sistema” y otros pretenden referirse a una entidad relacionada con un ordenador de hardware, de una combinación de hardware y software, de software o de software en ejecución. Por ejemplo, un componente puede ser, pero no está limitado a ser, un proceso que se ejecuta en un procesador, un procesador, un objeto, un ejecutable, un hilo de ejecución, un programa y/o un ordenador. A modo de ilustración, tanto una aplicación que se ejecuta en un ordenador como un ordenador pueden ser un componente. Uno o más componentes puede o pueden residir dentro de un proceso y/o hilo de ejecución y un componente puede estar localizado en un ordenador y/o distribuido entre dos o más ordenadores.

El término “de ejemplo” se utiliza en esta memoria con el significado de servir como ejemplo, instancia o ilustración. Cualquier aspecto o diseño descrito en esta memoria como “de ejemplo” no necesariamente debe ser interpretado como preferido o ventajoso en otros aspectos o diseños.

Además, el asunto descrito puede ser implementado como un sistema, método, aparato o artículo de fabricación utilizando técnicas de programación y/o de ingeniería estándares para producir software, firmware, hardware o cualquier combinación de los mismos para controlar un dispositivo basado en un ordenador o en un procesador para implementar los aspectos detallados en esta memoria. El término “artículo de fabricación” (o alternativamente, “producto de programa de ordenador”) tal como se utiliza en esta memoria pretende abarcar un programa de ordenador accesible desde cualquier dispositivo, soporte o medios legibles por ordenador. Por ejemplo, los medios legibles por ordenador pueden incluir, pero no están limitados a dispositivos de almacenamiento magnético (por ejemplo, disco duro, disco flexible, cintas magnéticas y otros), discos ópticos (por ejemplo, disco compacto (CD – Compact Disk, en inglés), disco versátil digital (DVD – Digital Versatile Disk, en inglés) y otros, tarjetas inteligentes y dispositivos de memoria rápida (por ejemplo, tarjeta, pincho y otros). Adicionalmente, resultará evidente que puede emplearse una onda portadora para transportar datos electrónicos legibles por ordenador, tales como los utilizados en transmitir y recibir correo electrónico o en acceder a una red tal como la Internet o una red de área local (LAN – Local Area Network, en inglés). Por supuesto, los expertos en la materia reconocerán que pueden realizarse muchas modificaciones a esta configuración.

Como se ha indicado anteriormente, existe la posibilidad de que el cambio a CS provoque la asignación de recursos no óptimos tales como un canal de señalización para proporcionar servicio a una llamada de voz, lo que puede crear situaciones que afectan al rendimiento del cambio a CS, o un canal de tráfico para proporcionar servicio a un procedimiento de señalización, provocando una pérdida de recursos de radio. Por ejemplo, volviendo a la Fig. 3, en el caso de la iniciación de una llamada que finaliza en un teléfono móvil en la GERAN, al UA 10 típicamente se le proporciona la indicación de “Necesidad de Canal” en un mensaje de localización 72 enviado por la red GERAN 74, que es información que señala el canal de radio más adecuado para soportar el servicio para el cual el UA es localizado, por ejemplo, el canal de señalización Canal de Control Dedicado Independiente (SDCCH – Stand-Alone Dedicated Channel, en inglés), el canal de tráfico (TCH – Traffic Channel, en inglés) / completo (F – Full, en inglés). El UA 10 envía a continuación una solicitud de canal 76 apropiada a la red GERAN 74 teniendo en cuenta la “Indicación de localización” del elemento de “Necesidad de Canal” recibido en el mensaje de localización 72 y en la propia capacidad del UA 10 (sólo velocidad máxima, velocidad dual, sólo SDCCH), que permite al BSS proporcionar el canal más deseable. Por ejemplo, la Tabla 1 que aparece a continuación lista los mensajes de solicitud de canal cuando responden a una localización para el establecimiento de la conexión RR.

Indicación de Localización de Capacidad de MS

Sólo Velocidad máxima Velocidad Dual Sólo SDCCH

Cualquier canal

100xxxxx 100xxxxx 100xxxxx

SDCCH

0001xxxx 0001xxxx 0001xxxx

TCH/F

100xxxxx 0010xxxx 0001xxxx

TCH/H o bien TCH&F

100xxxxx 0011xxxx 0001xxxx

Tabla 1

No obstante, en el caso de localización de un UA en la E-UTRAN para la sesión de terminación de cambio a CS, la localización (notificación de servicio de CS) enviada por la MME 20, como se ha descrito con respecto a la Fig. 2, al UA 10 en modo conectado en la red de fuente (sólo paquetes) no contiene ninguna información de “Indicación de Localización”. Esta notificación de localización puede incluir información acerca del servicio para el cual la estación de telefonía móvil está localizada (por ejemplo código de Servicio Suplementario, indicador de servicio de ubicación (LCS – LoCationService, en inglés)). En el caso de que la localización se haya hecho para llegar al UA 10 en modo de reposo, (véase, por ejemplo, la Fig. 6), los mensajes de localización enviados sobre la interfaz S1 y sobre la interfaz de radio no contienen incluso ninguna indicación del servicio para el cual la estación de telefonía móvil está localizada. Además, el protocolo de RR de la GERAN no especifica cómo debería el UA construir la Solicitud de Canal cuando responde a la localización cuando es activada por el procedimiento de cambio a CS. Esto significa que el procedimiento de solicitud de canal existente definido para la GERAN no es aplicable de esa manera para el cambio a CS (falta de “Indicación de Localización” para determinar la correcta y óptima información en el mensaje de solicitud de canal que puede ser enviado en la red de objetivo.

Como resultado, un cambio a CS a la GERAN podría llevar a implementaciones del UA inconsistentes, por ejemplo, solicitando un tipo de canal inapropiado al servicio que se está activando, lo que resulta en la pérdida de los recursos asignados o en un tiempo de establecimiento más largo. En particular, la solicitud y la asignación inicial de un SDCCH en el caso de un establecimiento de llamada de voz retardará el establecimiento de la ruta de voz en comparación con el caso en el que un canal de tráfico (TCH – Traffic CHannel, en inglés) es solicitado y asignado sólo en modo de señalización (mayor latencia del SDCCH en comparación con el TCH, mayor tiempo para la asignación del TCH en el modo de conversación si un SDCCH ha sido asignado en comparación con un procedimiento de modificación de modo de canal mientras que sigue estando en el mismo canal TCH). En otros escenarios, la solicitud y la asignación inicial de un TCH en modo sólo de señalización desperdiciaría recurso de radio si el servicio, por ejemplo, servicio de ubicación o servicio suplementario, puede ser soportado en un SDCCH.

Volviendo a otro problema identificado de ejemplo, la Fig. 4 ilustra una llamada de CS que termina en un teléfono móvil en la red UTRAN 78, con el UA 10 en modo de reposo. En este caso, al UA 10 se le proporciona típicamente una información de “causa de localización” en el mensaje de localización enviado por la red UTRAN 78, que es información que señala el tipo de servicio para el cual el UA está localizado, por ejemplo, Llamada de Conversación de Terminación, Señalización de Alta Prioridad de Terminación, Señalización de Baja Prioridad de Terminación, como se indica mediante “localización para tipo 1” 80. Esta información es enviada por el protocolo de RRC en el UA 10 a las capas superiores, que a su vez solicitan el establecimiento de la conexión de RRC y mapean la causa de establecimiento de RRC a la causa de localización recibida, que será incluida en la Solicitud de Conexión de RRC 82 enviada a la red UTRAN 78.

No obstante en el caso de la localización de un UA en E-UTRAN para una sesión de terminación de cambio a CS, la localización (notificación de servicio de CS) enviada por la MME al UA en modo conectado en la red de fuente, sólo de paquetes (por ejemplo, PS) no contienen ninguna información de “causa de localización”. Esta notificación de localización puede incluir información acerca del servicio para el cual está localizada la estación de telefonía móvil.

En el caso de que la localización se realice alcanzando al UA en modo de reposo, el mensaje de localización enviado sobre la interfaz S1 y sobre la interfaz de radio no contiene ninguna indicación del servicio para el cual el UA está localizado. Además, las capas superiores no especifican qué información debe ser pasada al protocolo de RRC para su inclusión en la Solicitud de Conexión de RRC en respuesta a una localización que tiene lugar en la E-UTRAN para el caso del procedimiento de cambio a CS. De nuevo, en UTRAN, esto podría llevar a implementaciones de UA inconsistentes y resultar en asignación de recurso o rendimientos por debajo de los óptimos.

En el caso de una llamada que se origina en un teléfono móvil en la GERAN o en la UTRAN, el UA incluye en la solicitud de canal/Solicitud de Conexión de RRC enviada a la red alguna información adicional, tal como tipo de canal, causa del establecimiento y otros, permitiendo a la red asignar un recurso apropiado dependiendo del servicio que se solicita. Volviendo ahora a la Fig. 5, que es una variación de la Fig. 2 pero que muestra un flujo de datos para una llamada originada en un teléfono móvil sujeta a cambio a CS, el flujo de datos incluye la operación 24 para manejar una solicitud de servicio desde el UA 10 a la red. El elemento de información de tipo de servicio se incluye en el mensaje de Solicitud de Servicio Extendido enviado a la red. Los elementos de información del tipo de servicio son como se muestra en la Tabla 2:

Valor de tipo de Servicio (octeto 1) Valor de tipo de servicio

Bits

4

3 2 1

0

0

0

0

Cambio a CS de origen en teléfono móvil ó 1xcambio a CS

0

0

0

1 Cambio a CS de terminación en teléfono móvil ó 1xcambio a CS

0

0

1 0 Llamada de emergencia de cambio a CS de origen en teléfono móvil o 1xllamada de

emergencia de cambio a CS

Todos los demás valores están reservados.

Tabla 2

No obstante, este elemento de información no proporciona ninguna información a la red de fuente acerca del servicio de CS solicitado, lo que, así, no permite a la red dimensionar adecuadamente los recursos que deben ser asignados de acuerdo con el servicio solicitado y determinar condiciones óptimas para transmitir el UA a la red de CS de objetivo, por ejemplo, dependiendo de los canales disponibles y la información de carga, para el caso de que se soporten transferencia de inter-RAT u orden de cambio de celda.

En general, el presente sistema y métodos han sido desarrollados para reducir el retardo y mejorar la fiabilidad de un proceso de cambio a CS. El cambio a CS puede ser implementado para pasar de una E-UTRAN a una GERAN, específicamente, o, de manera más general, desde una primera red que no proporciona servicios del dominio de CS a una segunda red que proporciona servicio del dominio de CS. Por ejemplo, el cambio a CS puede ser implementado para permitir el cambio de redes del tipo de E-UTRAN a redes del tipo de GERAN, UTRAN o CDMA2000. Con este fin, el presente sistema y método facilita el cambio a CS permitiendo que un UA identifique los recursos más apropiados para proporcionar el servicio solicitado y a continuación solicite esos recursos cuando se pase a una red de CS durante a un cambio a CS. En una implementación del presente sistema, en UA es configurado para analizar la información de localización disponible recibida desde la red para determinar el canal de comunicación más apropiado o el recurso de radio para solicitar un rendimiento de cambio a CS óptimo.

Para iniciar el cambio a CS, un UA puede recibir en primer lugar un mensaje de localización desde una red de PS de fuente (por ejemplo, una red de E-UTRAN). El mensaje de localización instruye al UA para que implemente un cambio a CS a una red de CS (por ejemplo, una red tráfico) para acceder a un servicio. Si el servicio correspondiente puede ser determinado utilizando la información transportada en el mensaje de localización, el UA es configurado para enviar un mensaje de solicitud de canal solicitando un tipo de canal adecuado para ese servicio en la red de CS. De esta manera, basándose en una o más partes de información contenida en el mensaje de localización, el UA es configurado para solicitar tipos de canal particulares cuando implementa un cambio a CS.

Por ejemplo, cuando el mensaje de localización es para una llamada de conversación o para cualquier llamada que requiera un canal de tráfico, el UA puede ser configurado para solicitar un “TCH/H o TCH/F”, o bien un canal de “TCH/F”. Alternativamente, cuando el mensaje de localización es para activar un servicio suplementario independiente de la llamada, o un servicio de ubicación, por ejemplo, el UA puede solicitar un SDCCH. En estos ejemplos, la selección de un canal “TCCH/H o TCH/F” puede no requerir ninguna preferencia particular para la selección de un canal de media velocidad (H – Half, en inglés) o de velocidad máxima (F – Full, en inglés). La red puede tomar la determinación de un canal de máxima o de media velocidad de manera autónoma, dependiendo de las condiciones locales (estado de carga de la red, preferencias de calidad de servicio (QoS – Quality of Service, en inglés), etc). La selección de un canal TCH/F, no obstante, puede influir en la decisión de la red acerca de si seleccionar un canal de velocidad máxima o media.

En algunas circunstancias, el mensaje de localización contendrá insuficiente información para que el US determine el servicio para el cual el UA ha sido localizado. En ese caso, el UA puede ser configurado para construir y enviar una información de canal que refleja un tipo de canal “por defecto”, por ejemplo utilizando el valor “cualquier Canal” o algún otro indicador que identifique el canal por defecto.

De acuerdo con esto, en una implementación de ejemplo del presente sistema, en el caso de una SOLICITUD DE CANAL activada por un procedimiento de cambio a CS, tal como el descrito en el documento TS 23.272 del 3GPP, el contenido del mensaje de SOLICITUD DE CANAL puede ser determinado dependiendo de la información que puede ser obtenida a partir de la notificación de localización recibida en la tecnología de acceso por radio (RAT – Radio Access Technology, en inglés) de fuente acerca del servicio para el cual está localizada la estación de telefonía móvil. Si no puede obtenerse ninguna información específica a partir de la notificación de localización, el contenido del mensaje de SOLICITUD DE CANAL puede ser establecido para un valor de indicación de Localización que indica “Cualquier Canal”. Por ejemplo, el contenido del mensaje de SOLICITUD DE CANAL puede ser codificado de acuerdo con la Tabla 3, siendo la entrada de “Indicación de Localización” seleccionada de acuerdo con la descripción anterior para indicar el servicio correspondiente.

Indicación de Localización de Capacidad de MS (nota 3)

Sólo Velocidad máxima Velocidad Dual (nota 5) Sólo SDCCH

Cualquier canal

100xxxxx 100xxxxx 100xxxxx

SDCCH

0001xxxx 0001xxxx 0001xxxx

TCH/F

100xxxxx 0010xxxx 0001xxxx

TCH/H o bien TCH&F

100xxxxx 0011xxxx 0001xxxx

Tabla 3

Alternativamente, el UA puede ser configurado para seleccionar un canal de “TCH/H o TCH/F”, dependiendo de si se prefiere un establecimiento rápido o un ahorro de recurso de radio (la preferencia puede ser almacenada como preferencias de usuario, o determinada sólo por la política del operador de red, por ejemplo), o de algún otro factor que pueda requerir un canal por defecto particular.

Dependiendo de la implementación del sistema, el UA puede ser configurado con un mapeo explícito entre el servicio indicado por el mensaje de localización y un tipo de canal para ser solicitado durante el cambio. En otros casos, no obstante, tras determinar el servicio indicado en el mensaje de localización, el UA puede determinar el tipo de canal que se va a solicitar independientemente basándose en otra información disponible para el UA. Si no hay un mapeo explícito, y el UA puede determinar de manera independiente el tipo de canal para ser solicitado, el UA puede tener más flexibilidad y puede basarse en otras partes de información disponibles cuando identifica el tipo de canal que se va a solicitar. En contraste, un mapeo explicito puede excluir diferentes interpolaciones y asegurar la consistencia en el canal seleccionado por un UA en respuesta a un mensaje de localización particular.

En un ejemplo del presente sistema, varios elementos de información presentes en un mensaje de Notificación de Servicio de CS transmitido entre la MME y el UA pueden ser inspeccionados para determinar el servicio para el cual está localizado el UA y pueden, por lo tanto, permitir que el UA solicite el tipo de canal más apropiado para proporcionar ese servicio. La línea llamante (CLI – Calling LIne, en inglés), el Código de Servicio Suplementario (Supplementary Service, en inglés), el indicador de LCS y los elementos de canal de identidad del cliente de LCS, por ejemplo, pueden estar incluidos dentro de un Mensaje de Notificación de Servicio de CS y su presencia o ausencia pueden ser indicativas del servicio que se está seleccionando. En general, la CLI contiene la identificación de la línea llamante para la llamada de terminación en teléfono móvil en el dominio de CS que activó la localización a través de la SGs. El elemento de información de Código de SS contiene información acerca de la transacción de servicio suplementaria en el dominio de CS que activó la localización a través de las SGs. El indicador de LCS indica que la localización fue activada terminando la solicitud de LCS en el dominio de CS. La identidad de cliente de LCS contiene información relativa al solicitante de la solicitud de LCS de terminación en el dominio de CS. Cada uno de los elementos de información es enviados por la red si son originariamente recibidos a través de SGs.

La Tabla 4 ilustra un contenido de mensaje de NOTIFICACIÓN DE SERVICIO DE CS.

IEI

Elemento de Información Tipo/Referencia Presencia Formato Longitud

Discriminador de protocolo

Discriminador de protocolo 9.2 M V 1/2

Tipo de cabecera de seguridad

Tipo de cabecera de seguridad 9.3.1 M V 1/2

Identidad de mensaje de notificación de servicio de CS

Tipo de mensaje 9.8 M V 1

Identidad de Localización

Identidad de Localización 9.9.3.25A M V 1

60

CLI CLI 9.9.3.38 O TLV 3-14

61

Código de SS Código de SS 9.9.3.39 O TV 2

62

Indicador de LCS Indicador de LCS 9.9.3.40 O TV 2

63

Identidad de cliente de LCS Identidad de cliente de LCS 9.9.3.41 O TLV 3-257

Tabla 4

Estos elementos de información pueden ser originariamente recibidos desde el MSC/Registro de Ubicación Visitante (VLR – Visitor Location Register, en inglés) en un mensaje de SOLICITUD DE LOCALIZACIÓN DE SGsAP y transferidos en el mensaje de NOTIFICACIÓN DE SERVICIO DE CS. La presencia o ausencia de los elementos de información en el mensaje de SOLICITUD DE LOCALIZACIÓN DE SGsAP es gobernada por varios conjuntos de reglas y es indicativa del tipo de servicio para el cual se ha solicitado el cambio a CS. Por ejemplo, si la localización es debida a un procedimiento de SS Independiente de la Llamada iniciada en la red tal como se define en el

documento TS 24.010 del 3GPP, el VLR incluye el código de SS en el mensaje de SOLICITUD DE LOCALIZACIÓN DE SGsAP tal como se define en el documento TS 29.002 del 3GPP. Si, no obstante, la localización es debida a una Solicitud de Ubicación Terminada en un Teléfono Móvil tal como se define en el documento TS 24.030 del 3GPP, el VLR puede incluir la identidad de cliente de LCS y el indicador de LCS tal como se define en el documento TS

29.002 del 3GPP en la SOLICITUD DE LOCALIZACIÓN DE SGsAP. De acuerdo con estas reglas, los diferentes elementos de información están incluidos en la SOLICITUD DE LOCALIZACIÓN DE SGsAP y son transmitidos al UAen el contenido del mensaje de NOTIFICACIÓN DE SERVICIO DE CS. De esta manera, la presencia o la ausencia de uno o de varios de estos elementos de información permite que el UA tome una determinación acerca del servicio para el cual el UA ha sido localizado.

La Tabla 5 ilustra un contenido de mensaje de SOLICITUD DE LOCALIZACIÓN DE SGsAP DE ejemplo.

Elemento de información

Tipo/Referencia Presencia Formato Longitud

Tipo de mensaje

Tipo de mensaje 9.2 M V 1

IMSI

IMSI 9.4.6 M TLV 6-10

Nombre de VLR

Nombre de VLR 9.4.22 M TLV 3-n

Indicador de servicio

Indicador de servicio 9.4.17 M TLV 3

TMSI

TMSI 9.4.20 O TLV 6

CLI

CLI 9.4.1 O TLV 3-14

Identificador de área de ubicación

Identificador de área de ubicación 9.4.11 O TLV 7

Id de CN Global

Id de CN Global 9.4.4 O TLV 7

Código de SS

Código de SS 9.4.19 O TLV 3

Indicador de LCS

Indicador de LCS 9.4.10 O TLV 3

Identidad de cliente de LCS

Identidad de cliente de LCS 9.4.9 O TLV 3-n

Canal necesitado

Canal necesitado 9.4.23 O TLV 3

Prioridad de eMLPP

Prioridad de eMLPP 9.4.24 O TLV 3

Tabla 5

Como se muestra en la Tabla 5, el código de SS es incluido si la localización es debida un procedimiento de SS Independiente de la Llamada iniciada en la red (véase el documento TS 24.010 del 3GPP). El indicador de LCS se incluye si la localización es debida a una Solicitud de Ubicación de Terminación en un Teléfono Móvil (véase el documento TS 24.030 del 3GPP). La identidad del cliente de LCS se incluye si la localización es debida a una Solicitud de Ubicación de Terminación en un Teléfono Móvil (véase el documento TS 24.030 del 3GPP). El elemento de información necesaria para el canal está incluido si el VLR pretende indicar qué canal debe usar el UA.

El UA puede estar también configurado para inspeccionar información adicional para determinar los servicios indicados por una solicitud de localización particular. La información adicional puede incluir otros elementos de información que pueden ser añadidos en el futuro, incluyendo los identificados a continuación.

El presente sistema puede estar también configurado para incluir información relativa a un servicio disponible en la MME en mensajes de localización utilizados para localizar a un UA en modo de reposo. Por ejemplo, la información relativa a un servicio puede incluir elementos de información del “código de SS”, indicador de LCS” e “identidad de cliente de LCS” descritos anteriormente. La información relativa a un servicio puede ser comunicada a la MME por elMSC/VLR sobre la interfaz de SGs en el mensaje de SOLICITUD DE LOCALIZACIÓN DE SGsAP. En algunos casos, estos elementos de información están ya presentes en el mensaje de Notificación de Servicio de CS utilizado para localizar a un UA en modo conectado y puede, por lo tanto, ser añadido al mensaje de Localización de interfaz de S1 por la MME y el mensaje de Localización de interfaz de radio de RRC en la E-UTRAN mediante el protocolo de RRC de E-UTRAN. La información adicional presentada en los mensajes de localización puede entonces ser utilizada cuando el UA es localizado en modo de reposo además del caso en el que el UA es localizado en modo conectado.

La Tabla 6 ilustra un mensaje de localización de una interfaz de S1 que se modifica para incluir el Código de SS, el indicador de LCS y elementos de información de identidad de cliente de LCS.

IE Nombre del Grupo

Presencia Intervalo Tipo y referencia de IE Descripción Semántica Criticalidad Criticalidad Asignada

Tipo de mensaje

M 9.2.1.1 SÍ Ignorar

Valor de Índice de Identidad de UE

M 9.2.3.10 SÍ Ignorar

Identidad de Localización de UE

M 9.2.3.13 SÍ Ignorar

DRX de Localización

O 9.2.1.16 SÍ Ignorar

Dominio de CN

M 9.2.3.22 SÍ Ignorar

Lista de IAIs

M SÍ Ignorar

>Ítem de la lista de TAI

1 a < maxnoofTAISs> EACH Ignorar

>>TAI

M 9.2.3.16 -

Lista de ID de CSG

1 a < maxnoofCSGId> GLOBAL Ignorar

>Id de CSG

M 9.2.1.62

Código de SS

O 9.2.x.y -

Indicador de LCS

O 9.2.x.y -

Identidad de cliente de LCS

O 9.2.x.y -

Tabla 6

La Tabla 7 ilustra un mensaje de localización de protocolo de RRC de la E-UTRAN que está modificada para incluir el Código de SS, el Indicador de LCS y los elementos de información de identidad de cliente de LCS.

Tabla 7

En referencia a la Tabla 7, el código de ss (ss-Code, en inglés) transporta información relativa a una solicitud de servicio suplementaria iniciada en la red. El Indicador de Ics (Ics-Indicator, en inglés) indica que el origen del mensaje es debido a una solicitud de LCS y el tipo de esta solicitud. La codificación del Indicador de Ics viene dada por la parte de valor del elemento de información del indicador de LCS en TS 24.301. La identidad de Cliente de Ics (Ics-Client-Identity, en inglés) transporta información relativa al cliente de una solicitud de LCS. La codificación de la identidad de cliente de LCS viene dada en el subapartado 17.7.13 del documento TS 29.002 del 3GPP.

La Fig. 6 es una ilustración de un flujo de mensajes para implementar un cambio a CS en el que información relativa es pasada al UA 10 dentro de un mensaje de localización. En las etapas 100, 102 y 104 una llamada terminada en un UA llega al MSC/VLR 140. En la etapa 106, un mensaje de Solicitud de Localización de SGsAP es transmitido a la MME 20. La solicitud de Localización de SGsAP puede incluir uno o más elementos de información indicativos del tipo de servicio solicitado. En las etapas 108 y 110 la MME 20 envía un mensaje de localización al UA 10. El mensaje De localización es modificado para incluir uno o más de los elementos de información descritos anteriormente. La presencia o la ausencia de uno o más de los elementos de información permite al UA identificar el tipo de servicio para el cual se ha enviado el mensaje de localización. Como resultado, en la etapa 112 el UA puede solicitar un recurso apropiado para el servicio. En la etapa 114, en respuesta a la solicitud de servicio, la MME 20 envía un mensaje de establecimiento de contexto de UA inicial. En la etapa 116, 118 y 120, una transferencia de PS o, alternativamente, un cambio de celda asistido por una estación de base, o una liberación de RRC con redireccionamiento, posiblemente seguido por una actualización del área de ubicación son completados. En la etapa 122 la respuesta de localización es transmitida al RNC/BSC 142 desde el UA 10 y la respuesta de localización es emitida hacia el MSC/VLR 140 en la etapa 124. Si el MSC no ha cambiado, la conexión de CS es establecida en la etapa 126 y el proceso de cambio a CS se completa. Si el MSC ha cambiado, no obstante, en la etapa 128 el MSC/VLR 140 transmite un rechazo de conexión al RNC/BSC 142. En respuesta, el RNC/BSC 142 transmite una liberación de conexión de señalización al UA 10 en la etapa 130. En ese punto, una actualización del área de ubicación y un reintento de itinerantica es iniciado frente al intento de cambio a CS en la etapa 132.

Alternativamente, para facilitar el cambio a CS, un elemento de información con Necesidad de Canal, cuando es conocido para la MME, puede ser añadido a mensajes de Localización enviados a un UA para localizar al UA en modo de reposo o conectado. Por ejemplo, un elementos de información con Necesidad de Canal puede ser añadido al mensaje de NAS de Notificación de Servicio de CS (descrito anteriormente) transmitido entre la MME y el UA, el mensaje de Localización de interfaz de S1 descrito anteriormente o el protocolo de interfaz de radio de RRC descrito anteriormente. En algunos casos, los datos utilizados para ser incluidos en el elemento de información con Necesidad de Canal son comunicados a la MME mediante el MSC/VLR sobre la interfaz de SGs en el mensaje deSOLICITUD DE LOCALIZACIÓN DE SGsAP, tal como se ha descrito anteriormente. La información con Necesidad de Canal, cuando existe dentro de un mensaje de localización, permite al UA crear de manera eficiente un mensaje de solicitud de canal apropiado cuando el UA responde a la localización de cambio a CS en la GERAN, puesto que la misma información existiría en el mensaje de localización de la GERAN (si ha sido transmitido por el MSC/VLR).

Para habilitar al UA localizado en la E-UTRAN para una llamada de CS de Terminación en un Teléfono Móvil con cambio para enviar una causa de establecimiento apropiada cuando responde en una red UTRAN, pueden introducirse nuevas entradas de mapeo. Esto permitiría al UA comunicar a la red las causas de establecimiento apropiadas que reflejen el servicio para el cual el UA es localizado, si el servicio correspondiente puede ser evaluado a partir de la información transportada en el mensaje de localización. En ese caso, el UA, cuando responde en la UTRAN a una localización recibida en la red de paquetes de fuente (por ejemplo la E-UTRAN), puede incluir la causa de establecimiento de mapeo comunicada por las capas superiores en el mensaje de Solicitud de Conexión de RRC.

Como ejemplo, la causa de establecimiento puede ser determinada como sigue: La causa de establecimiento puede 5 ser “Llamada de conversación de Terminación” cuando la localización recibida es para una llamada de conversación

o para cualquier otra llamada de CS de conversación, o “Señalización de Alta Prioridad de Terminación” cuando la localización recibida es para activar un servicio suplementario independiente de llamada, o un servicio de ubicación.

Si el servicio para el cual es localizado el UA no puede ser evaluado a partir de la información disponible en la red, el 10 UA puede utilizar “Terminación – cauda desconocida” como causa del establecimiento.

La Tabla 8 ilustra un mapeo de ejemplo del procedimiento de NAS de CS a una causa de establecimiento.

Procedimiento de NAS de CS

Causa de Establecimiento de RRC (de acuerdo con 3GPP TS 25.331 [23c]

Llamada de conversación de CS de origen

Llamada de Conversación de Origen

Llamada de datos de CS de origen

Llamada de Conversación de Origen

Llamada de emergencia de CS

Llamada de emergencia

Re-establecimiento de llamada

Re-establecimiento de llamada

Actualización de Ubicación

Registro

Separación de IMSI

Separación

SMS de MO a través de dominio

Señalización de Baja Prioridad de Origen

Servicios suplementarios

Señalización de Alta Prioridad de Origen

Respuesta a localización de circuitos conmutados

Hacer igual al valor de la causa de localización utilizado en la recepción de la localización en la capa de RRC

Parte de SS de servicios de Localización

Señalización de Alta Prioridad de Origen

Respuesta a localización de circuitos conmutados en el caso de cambio a CS de Terminación:

- conversación de CS de Terminación / llamada de datos

Llamada de Conversación de Terminación

- Servicios Suplementarios

Señalización de Alta Prioridad de Terminación

- Servicios de Ubicación

Señalización de Alta Prioridad de Terminación

- No determinado

Terminación – causa desconocida

Tabla 8

15 Varios elementos de información, cuando existen en un mensaje de Notificación de Servicio de CS entre la MME y el UA, pueden proporcionar una indicación del servicio para el cual está localizado el teléfono móvil, incluyendo los elementos de información de “Código de SS”, el “indicador de LCS” y la “identidad de cliente de LCS”. Los diferentes elementos de información pueden ser recibidos desde el MSC/VLR en un mensaje de SOLICITUD DE

20 LOCALIZACIÓN DE SGsAP tal como se ha descrito anteriormente. La presencia o la ausencia de uno de los diferentes elementos de información puede o pueden por lo tanto permitir que el UA tome una determinación acerca del servicio para el cual está el UA localizado. Cualquier otra información a la que el UA podría acceder o ser rechazada por el UA a partir de mensajes recibidos desde la red o desde otras fuentes puede ser utilizada para determinar el servicio para el cual el UA ha sido localizado. Esto puede incluir nuevos elementos de información

25 añadidos en el futuro, incluyendo los descritos anteriormente.

Cuando inicia una llamada de Origen en un Teléfono Móvil (MO – Mobile Originating, en inglés), el UA puede ser configurado para proporcionar información adicional a la red de PS describiendo el servicio de CS solicitado para el cual puede ser activado el cambio a CS. En una implementación, el UA incluye información adicional en el mensaje

30 de Solicitud de Servicio Extendido transmitido a la MME de la red de PS que describe el servicio de CS que es solicitado. De manera similar, la información adicional puede ser incluida en mensajes de SOLICITUD DEESTABLECIMIENTO DE CONTEXTO INICIAL, o de SOLICITUD DE MODIFICACIÓN DE CONTEXTO DEL UA transmitidos desde la MME al eNodoB utilizando la interfaz de S1 (véase el documento TS 36.413 del 3GPP).

35 La Tabla 9 y la Tabla 10 ilustran un mensaje de Solicitud de Servicio Extendido modificado que incluye información adicional que describe el servicio de CS solicitado por un UA que inicia una llamada de MO que resulta en un cambio a CS.

IEI

Elemento de Información Tipo/Referencia Presencia Formato Longitud

Discriminador de protocolo

Discriminador de protocolo 9.2 M V 1/2

Tipo de cabecera de seguridad

Tipo de cabecera de seguridad 9.3.1 M V 1/2

Identidad de mensaje de solicitud de servicio extendido

Tipo de mensaje 9.8 M V 1

Tipo de servicio

Tipo de Servicio 9.9.3.27 M V 1/2

Identificador de conjunto de claves de NAS

Identificador de conjunto de claves de NAS 9.9.3.21 M V 1/2

M-TMSI

Identidad de teléfono móvil 9.9.2.3 M LV 6

B-

Respuesta de CSFB Respuesta de CSFB 9.9.3.5 C TV 1

C-

Causa de solicitud de servicio extendido Causa de solicitud de servicio extendido 9.9.x.y C TV 1

Tabla 9

Como se muestra en la Tabla 9 y la Tabla 10, el mensaje de Solicitud de Servicio Extendido mostrado en la Tabla 9 incluye un elemento adicional llamado “Causa de solicitud de servicio extendido”. El detalle del elemento de información de causa de solicitud de servicio extendido se muestra en la Tabla 10. El elemento de causa de solicitud de servicio extendido está configurado para almacenar un valor de identificador en el octeto 1 que describe el servicio de CS solicitado. Por ejemplo, el identificador puede ser utilizado para referirse a los servicios de CS tales como Llamada de Conversación de Origen, Señalización de Alta Prioridad de Origen o Señalización de Baja Prioridad de Origen. La Tabla 11 ilustra una configuración de ejemplo del octeto 1 del elemento de información de causa de solicitud de servicio extendido.

Valor de causa de solicitud de servicio extendido (octeto 1) Bits

3

2 1

0

0

0

Llamada de Conversación de Origen

0

0

1 Señalización de Alta Prioridad de Origen

0

1 0 Señalización de Baja Prioridad de Origen

Todos los demás valores están reservados.

Tabla 11

En algunos casos, el elemento de información de tipo de Servicio existente presente en los mensajes de Solicitud de Servicio Extendido puede ser modificado y utilizado para identificar el servicio de CS que está siendo solicitado. Alternativamente, elementos de información adicionales que indican el servicio de origen, tal como el “Código de SS”

o el “Indicador de LCS” definidos por el mensaje de Notificación de Servicio pueden ser incluidos en el mensaje cuando el UA inicia una llamada de Origen en un Teléfono Móvil. En otro ejemplo, la información de servicio de CS puede ser incluida en el mensaje de SolicituddeConexióndeRRC (véase el documento TS 36.331 del 3GPP) que puede ser utilizado para pasar al UA del modo de reposo al modo conectado cuando inicia una llamada de Origen en un Teléfono Móvil sujeta a cambio a CS.

La Fig. 7 muestra un diagrama de bloques de ejemplo del UA 10. Aunque se muestran una variedad de componentes conocidos de UAs 10, en una realización un subconjunto de los componentes listados y/o de componentes adicionales no listados puede ser incluido en el UA 10. El UA 10 incluye un procesador tal como un procesador de señal digital (DSP – Digital Signal Processor, en inglés) 802 y una memoria 804. Como se muestra, el UA 10 puede también incluir una antena y una unidad de extremo frontal 806, un transceptor de radiofrecuencia (RF

– Radio Frequency, en inglés) 808 y una unidad de procesamiento de banda de base analógica 810. En varias configuraciones, el UA 10 puede incluir componentes opcionales adicionales como se ilustra en la Fig. 7. Los componentes adicionales pueden incluir, por ejemplo, un micrófono 812, un altavoz de oreja 814, un puerto de cascos 816, una interfaz de entrada/salida 818, una tarjeta de memoria extraíble 820, un puerto de bus de serie universal (USB – Universal Serial Bus, en inglés) 822, un subsistema de comunicación inalámbrica de corto alcance 824, una alerta 826, un teclado numérico 828, un visualizador de cristal líquido (Liquid Crystal Display, en inglés), que puede incluir una superficie sensible al tacto 830, un controlador de LCD 832, una cámara de dispositivo de carga acoplada (CCD – Charge Coupled Device, en inglés), un controlador de cámara 836 y un sensor de sistema de posicionamiento global (GPS – Global Positioning System, en inglés) 838. En una realización, el UA 10 puede incluir otro tipo de visualizador que no proporciona una pantalla sensible al tacto. En una realización, el DSP 802 puede comunicarse directamente con la memoria 804 sin pasar a través de la interfaz de entrada/salida 818.

El DSP 802 ó alguna otra forma de controlador o de unidad de procesamiento central opera para controlar los diferentes componentes del UA 10 de acuerdo con software embebido o firmware almacenado en la memoria 804 ó almacenado en una memoria contenida dentro del propio DSP 802. Además del software o firmware embebidos, el DSP 802 puede ejecutar otras aplicaciones almacenadas en la memoria 804 ó que se encuentran disponibles por medio de medios portadores de información tal como medios de almacenamiento de datos portátiles como la tarjeta de memoria extraíble 820 ó por medio de comunicaciones de red por cable o inalámbricas. El software de aplicación puede comprender un conjunto compilado de instrucciones legibles mediante una máquina que configuran el DSP 802 para proporcionar la funcionalidad deseada, o el software de aplicación puede pueden ser instrucciones de software de alto nivel para ser procesadas por un interpretador o compilador para configurar indirectamente el DSP

802.

La antena y la unidad de extremo frontal 806 pueden ser proporcionadas para convertir entre las señales inalámbricas y las señales eléctricas, permitiendo al UA 10 enviar y recibir información de una red celular o alguna otra red de comunicaciones inalámbrica disponible o de un UA 10 correspondiente. En una realización, la antena y la unidad de extremo frontal 806 pueden incluir antenas para soportar operaciones de formación de haz y/o de múltiple entrada múltiple salida (MIMO – Multiple Input Multiple Output, en inglés). Como es conocido para los expertos en la materia, las operaciones de MIMO pueden proporcionar diversidad espacial que puede ser utilizada para solucionar condiciones de canal difíciles y/o aumentar el rendimiento del canal. La antena y la unidad de extremo frontal 806 pueden incluir componentes de sintonización de antena y/o componentes de concordancia de impedancia, amplificadores de potencia de RF y/o amplificadores de bajo ruido.

El transceptor de RF 808 proporciona desviación de frecuencia, convirtiendo señales de RF recibidas a banda de base y convirtiendo señales de transmisión de banda de base a RD. En algunas descripciones puede entenderse que un transceptor de radio o un transceptor de RF incluyen otra funcionalidad de procesamiento de señal tal como modulación / desmodulación, codificación / descodificación, intercalado / desintercalado, difusión / concentración, transformada de Fourier rápida inversa (IFFT – Inverse Fast Fourier Transforming, en inglés) / transformada de Fourier rápida (FFT – Fast Fourier Transforming, en inglés), asignación / eliminación de prefijo cíclico y otras funciones de procesamiento de señal. Con el propósito de claridad, la descripción aquí separa la descripción de este procesamiento de señal desde la etapa de RF y/o de radio y conceptualmente asigna el procesamiento de señal a la unidad de procesamiento de banda de base analógica 810 y/o el DSP 802 u otra unidad de procesamiento central. En algunas realizaciones, el transceptor de RF 808, porciones de la antena y del extremo frontal 806, y la unidad de procesamiento de banda de base analógica 810 pueden ser combinados en una o más unidades de procesamiento y/o circuitos integrados específicos para una aplicación (ASICs – Application Specific Integrated Circuits, en inglés). La unidad de procesamiento de banda de base analógica 810 puede proporcionar varios procesamientos analógicos de entradas y salidas, por ejemplo, procesamiento analógico de entradas del micrófono 812 y los cascos 810 y salidas al auricular 814 y a los cascos 816.

El DSP 802 puede llevar a cabo modulación/desmodulación, codificación/ descodificación, intercalado / desintercalado, difusión / concentración, transformada de Fourier rápida inversa (IFFT – Inverse Fast Fourier Transforming, en inglés) / transformada de Fourier rápida (FFT – Fast Fourier Transforming, en inglés), asignación / eliminación de prefijo cíclico y otras funciones de procesamiento de señal asociadas con las comunicaciones inalámbricas. En una realización, por ejemplo en una aplicación de tecnología de acceso múltiple por división de código (CDMA – Code Division Multiple Access, en inglés), para una función de transmisión el DSP 802 puede llevar a cabo modulación, codificación, intercalado y difusión, y para una función de recepción el DSP 802 puede llevar a cabo concentración, desintercalado, descodificación y desmodulación. En otra realización, por ejemplo en una aplicación de tecnología de acceso múltiple por división de frecuencia ortogonal (OFDMA – Orthogonal Frequency Division Multiple Access, en inglés), para la función de transmisión del DSP 802 puede llevar a cabo modulación, codificación, intercalado, transformada de Fourier Rápida Inversa e asingación de prefijo cíclico y para una función de recepción el DSP 802 puede llevar a cabo eliminación de prefijo cíclico, transformada de Fourier rápida, desintercalado, descodificación y desmodulación. En otras aplicaciones de tecnología inalámbricas, otras funciones de procesamiento de señal y combinaciones de las funciones de procesamiento de señal pueden ser llevadas a cabo por el DSP 802. El DSP 802 puede comunicar con una red inalámbrica por medio de la unidad de procesamiento de banda de base analógica 810.

La Fig. 8 ilustra un entorno de software 902 que puede ser implementado por un procesador o controlador del UA

10. El entorno de software 902 incluye activadores de sistema operativo 904 que son ejecutados por el procesador o controlador del UA 10 para proporcionar una plataforma desde la cual opera el resto del software. Los activadores del sistema operativo 904 proporcionan activadores para el hardware del UA con interfaces estandarizadas que son accesibles para el software de la aplicación. Los activadores del sistema operativo 904 incluyen servicios de gestión de aplicación (“AMS” – “Application Management Services”) 906 que transfieren el control entre aplicaciones que se ejecutan en el UA 10. Mostrados también en la Fig. 8 están una aplicación de navegación de Red 908, una aplicación de ejecución de medios 910 y programas del tipo applet de Java 912.

El UA 10 incluye un componente de procesamiento tal como un DSP que es capaz de ejecutar instrucciones relativas a las acciones descritas anteriormente. La Fig. 9 ilustra un ejemplo de un sistema 1000 que incluye uno o más de los componentes que proporciona la funcionalidad del UA 10. El sistema 1000 incluye un componente de procesamiento 1010 adecuado para implementar una o más realizaciones descritas en esta memoria. Además del procesador 1010 (que puede denominarse una unidad de procesador central (CPU – Central Processor Unit, o DSP), el sistema 1000 podría incluir dispositivos de conectividad de red 1020, una memoria de acceso aleatorio (RAM – Random Access Memory, en inglés) 1030, una memoria sólo de lectura (ROM – Read Only Memory, en inglés) 1040, un almacén secundario 1050 y dispositivos de entrada/salida (I/O) 1060. En algunos casos, algunos de estos componentes pueden no estar presentes o pueden estar combinados en varias combinaciones con otro o con otros componentes no mostrados. Cualquier acción descrita en esta memoria como tomada por el procesador 1010 podría ser tomada por el procesador 1010 sólo 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 ordenador, o rutinas a las que podría acceder desde dispositivos de conectividad de red 1020, RAM 1030, ROM 1040, o almacén secundario 1050 (que podría incluir varios sistemas basados en disco, tales como disco duro, disco flexible o disco óptico). Aunque sólo se muestra un procesador 1010, pueden existir múltiples procesadores. Así, aunque las instrucciones pueden ser explicadas como ejecutadas por un procesador, las instrucciones pueden ser ejecutadas simultáneamente, en serie

o si no por uno o por múltiples procesadores. El procesador 1010 puede ser implementado como uno o más microprocesadores de CPU.

Los dispositivos de conectividad de red 1020 pueden incluir uno o más componentes transceptores 1025 capaces de transmitir y/o de recibir datos de manera inalámbrica en forma de ondas electromagnéticas, tales como señales de radiofrecuencia o señales de frecuencia de microondas. El componente transceptor 1025 podría incluir unidades de recepción y de transmisión separadas o un solo transceptor. La información transmitida o recibida por el transceptor 1025 puede incluir datos que han sido procesados por el procesador 1010 ó instrucciones que deben ser ejecutadas por el procesador 1010. Tal información puede ser recibida desde y enviada desde una red en forma, por ejemplo, de una señal de banda de base de ordenador o señal realizada en la onda portadora. Los datos pueden ser ordenados de acuerdo con diferentes secuencias como puede ser deseable bien para procesar o para generar los datos o transmitir o recibir los datos. La señal de banda de base, la señal embebida en la onda portadora, u otros tipos de señales actualmente utilizadas o desarrolladas en lo que sigue pueden denominarse medio de transmisión y pueden ser generadas de acuerdo con varios métodos bien conocidos para un experto en la materia.

La RAM 1030 podría ser utilizada para almacenar datos volátiles y quizás para almacenar instrucciones que son ejecutadas por el procesador 1010. El ROM 1040 es un dispositivo de memoria volátil que típicamente tiene una menor capacidad de memoria que la capacidad de memoria del almacenamiento secundario 1050. La ROM 1040 podría ser utilizada 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 a la ROM 1040 es típicamente más rápido que al almacenamiento secundario 1050.

Los dispositivos de I/O 1060 pueden incluir visualizadores de cristal líquido (LCDs – Liquid Crystal Displays, en inglés), visualizadores de pantalla táctil, teclados, teclados numéricos, conmutadores, marcadores, ratones, bolas de rastreo, reconocedores de voz, lectores de tarjeta, lectores de cinta de papel, impresoras, monitores de video u otros dispositivos de entrada/salida bien conocidos. También, el transceptor 1025 podría ser considerado como un componente de los dispositivos de I/O 1060 en lugar de o además de ser un componente de los dispositivos de conectividad de red 1020. Algunos o todos los dispositivos de I/O 1060 pueden ser substancialmente similares a varios componentes representativos en el dibujo descrito previamente del UA 10, tal como el dispositivo 702 y la entrada 704.

Aunque se han proporcionado varias realizaciones en la presente descripción, resultará evidente que los sistemas y métodos descritos pueden ser realizados de muchas otras formas específicas. Los ejemplos presentes deben ser considerados como ilustrativos y no restrictivos. Por ejemplo, los diferentes elementos o componentes pueden ser combinados o integrados en otros sistemas o ciertas características pueden ser omitidas o no implementadas.

También, técnicas, sistemas, subsistemas y métodos descritos e ilustrados como discretos o separados pueden ser combinados o integrados con otros sistemas, módulos, técnicas o métodos. Otros elementos mostrados o explicados como acoplados o directamente acoplados o que se comunican entre sí pueden ser indirectamente acoplados o comunicados a través de alguna interfaz, o de otro modo. Otros ejemplos de cambios, sustituciones y alteraciones son establecidos por un experto en la materia.

Claims (10)

1. REIVINDICACIONES

   1.

   Un método implementado por un dispositivo inalámbrico (10) para cambiar a circuitos conmutados CS desde una primera red (12) que no proporciona servicios del dominio de CS de circuitos conmutados, comprendiendo el método:

   recibir desde la primera red (12) un mensaje de localización (72) para cambio a circuitos conmutados a una red de circuitos conmutados (14, 74, 78); determinar un tipo de canal adecuado para un servicio indicado por la información en el mensaje de localización (72); transmitir un mensaje de solicitud (76) para iniciar el establecimiento de una conexión de radio de circuitos conmutados, identificando el mensaje de información (76) el tipo de canal adecuado; y, utilizar el servicio en la red de circuitos conmutados (14, 74, 78).

2. 2.

   El método de la reivindicación 1, en el que el servicio es uno de una primera categoría de servicios, incluyendo la primera categoría de servicios llamadas de conversación de CS y servicios de CS que requieren un canal de tráfico

   o recursos de conversación, una segunda categoría de servicios, incluyendo la segunda categoría de servicios solicitudes de ubicación terminadas en un teléfono móvil o una tercera categoría de servicios, incluyendo la tercera categoría de servicios servicios suplementarios.

3. 3.

   El método de la reivindicación 2, en el que, si el servicio está en la primera categoría de servicios, el tipo de canal adecuado para el servicio es al menos uno de un canal de tráfico de velocidad media TCH/H (Traffic CHannel/Half, en inglés) o un canal de tráfico de velocidad máxima TCH/F (Traffic CHannel/Full, en inglés).

4. 4.

   El método de la reivindicación 2, en el que, si el servicio está en al menos una de las categorías segunda o tercera de servicios, el tipo de canal adecuado para el servicio es un canal de control dedicado SDCCH (Standalone Dedicated Control CHannel, en inglés) independiente.

5. 5.

   El método de la reivindicación 1 ó la reivindicación 2, en el que, cuando el servicio es indefinido, se determina que el tipo de canal adecuado para el servicio es un canal por defecto.

6. 6.

   El método de las reivindicaciones precedentes, en el que determinar comprende:

   detectar al menos uno de un elemento de información de código de SS de servicio suplementario, un elemento indicador de LCS de servicio de ubicación, y un elemento de información de identidad de cliente de LCS dentro del mensaje de localización (72); y en el que cuando el mensaje de localización (72) incluye el elemento de información de código de SS, el tipo de canal adecuado para el servicio es seleccionado para un servicio suplementario independiente de llamada; y cuando el mensaje de localización (72) incluye al menos un elemento de información indicador de LCS y el elemento de información de identidad de cliente de LCS, el tipo de canal adecuado para el servicio es seleccionado para una solicitud de ubicación terminada en un teléfono móvil.

7. 7.

   El método de cualquiera de las reivindicaciones precedentes, en el que el mensaje de localización (72) incluye unMENSAJE DE NOTIFICACIÓN DE SERVICIO DE CS.

8. 8.

   El método de cualquiera de las reivindicaciones precedentes, en el que el mensaje de localización (72) incluye un mensaje de localización de protocolo de RRC de E-UTRAN recibido después de un procedimiento preliminar implementado utilizando una interfaz de S1.

9. 9.

   Un dispositivo de comunicación mediante telefonía móvil (10) adaptado para llevar a cabo el método de cualquiera de las reivindicaciones 1 a 8.

10. 10.

    Un medio legible por ordenador que comprende un código ejecutable en un ordenador para llevar a cabo el método de cualquiera de las reivindicaciones 1 a 8.