ES2767879T3 - Determinar causas de establecimiento para sesiones de emergencia - Google Patents

Abstract

Método por un equipo de usuario, UE, incluyendo el método: generar, por el UE, un mensaje de petición de unión de estrato sin acceso, NAS, en el UE, teniendo el mensaje de petición de unión de NAS un tipo de unión asociado con el establecimiento de una llamada de emergencia a través de una red de paquetes conmutados, PS; determinar, por el UE, una causa de establecimiento de control de recursos de radio, RRC, basándose en el tipo de unión en el mensaje de petición de unión de NAS, en el que la causa de establecimiento de RRC indica que una capa de NAS está pidiendo el establecimiento de una conexión de RRC para la llamada de emergencia a través de la red de PS; y transmitir, por el UE, un mensaje (20) de petición de conexión de RRC a una estación base de nodo B evolucionado, eNB, para establecer la conexión de RRC, incluyendo el mensaje (20) de petición de conexión de RRC la causa de establecimiento de RRC, en el que la causa de establecimiento de RRC indica al menos una de sesión o llamada de emergencia de EPS, emergencia de PS y sesión o llamada de emergencia de IMS.

Description

DESCRIPCIÓN

Determinar causas de establecimiento para sesiones de emergencia

Antecedentes

La presente invención se refiere de manera general a determinar causas de establecimiento y más específicamente a métodos y a sistemas para determinar causas de establecimiento de control de recursos de radio (RRC) usando procedimientos de estrato sin acceso (NAS).

Tal como se usan en el presente documento, los términos “equipo de usuario” y “UE” pueden referirse a dispositivos inalámbricos tales como teléfonos móviles, asistentes personales digitales (PDA), ordenadores de mano o portátiles, y dispositivos similares u otros agentes de usuario (“UA”) que tienen capacidades de telecomunicaciones. En algunas realizaciones, un UE puede referirse a un dispositivo móvil inalámbrico. El término “UE” también puede referirse a dispositivos que tienen capacidades similares pero que no son generalmente transportables, tales como ordenadores de sobremesa, descodificadores o nodos de red.

En sistemas de telecomunicaciones inalámbricas tradicionales, el equipo de transmisión en una estación base u otro nodo de red transmite señales a través de una región geográfica conocida como célula. A medida que ha evolucionado la tecnología, se han introducido equipos más avanzados que pueden proporcionar servicios que no eran posibles anteriormente. Estos equipos avanzados pueden incluir, por ejemplo, un nodo B (eNB) de red de acceso de radio terrestre universal evolucionada (EUTRAN) en vez de una estación base u otros sistemas y dispositivos que están más altamente evolucionados que los equipos equivalentes en un sistema de telecomunicaciones inalámbricas tradicional. Tales equipos avanzados o de nueva generación pueden denominarse en el presente documento equipos de evolución a largo plazo (LTE), y una red basada en paquetes que usa tales equipos puede denominarse sistema de paquetes evolucionado (EPS). Mejoras adicionales en sistemas y equipos de LTE darán eventualmente como resultado un sistema avanzado de LTE (LTE-A). Tal como se usa en el presente documento, la frase “estación base” se referirán a cualquier componente, tal como una estación base tradicional o una estación base de LTE o LTE-A (incluyendo eNB), que puede proporcionar a un UE acceso de comunicación a otros componentes en un sistema de telecomunicaciones. En sistemas de comunicación móvil tales como la E-UTRAN, una estación base proporciona acceso de radio a uno o más UE. La estación base comprende un planificador de paquetes para planificar de manera dinámica transmisiones de paquetes de datos de tráfico de enlace descendente y asignar recursos de transmisión de paquetes de datos de tráfico de enlace ascendente entre todos los UE que se comunican con la estación base. Las funciones del planificador incluyen, entre otras, dividir la capacidad de interfaz aérea disponible entre los UE, decidir el canal de transporte que va a usarse para las transmisiones de datos de paquetes de cada UE, y monitorizar la asignación de paquetes y la carga de sistema. El planificador asigna de manera dinámica recursos para transmisiones de datos de canal compartido de enlace descendente físico (PDSCH) y canal compartido de enlace ascendente físico (PUSCH), y envía información de planificación a los UE a través de un canal de control.

En sistemas de telecomunicaciones existentes, los diversos controladores de señalización y protocolo que suministran servicios de telecomunicación se implementan en varias capas de protocolo. Diversas entidades entre homólogos pertenecientes a cada una de las capas se señalizan y comunican entre sí para permitir y realizar diversas funciones de modo que pueden proporcionarse servicios. Además, cada capa puede proporcionar uno o más servicios a las capas superiores. La figura 1 es una ilustración de algunas de las capas de protocolo encontradas dentro de sistemas de telecomunicaciones existentes e ilustra un protocolo en capas que puede usarse para comunicaciones entre un UE y una estación base. Tal como se muestra en la figura 1, las capas 12 de red residen por encima de las capas 14 de control de acceso. Las capas 12 de red y las capas 14 de control de acceso pueden comunicarse entre sí. Además, dado que residen por encima de las capas 14 de control de acceso, las capas 12 de control de red reciben servicios proporcionados por las capas 14 de control de acceso.

En una red de comunicaciones móviles, los controladores de protocolo y señalización de capa de red del UE y la red principal (CN) se comunican entre sí a través de enlaces de comunicaciones establecidos por los controladores de red de acceso de radio (RAN) subyacentes. En terminologías de UMTS y 3GPP, por ejemplo, la capa de red entre el UE y la CN se denomina estrato sin acceso (NAS). La capa de acceso de radio de la RAN se denomina estrato de acceso (AS). Dado que las capas subyacentes proporcionan servicios a las capas superiores, en el caso de las tecnologías de UMTS y 3GPP, por ejemplo, el AS proporciona servicios al NAS. Un servicio de este tipo proporcionado por el AS es establecer una conexión de señalización para el NAS de un UE de tal manera que el NAS del UE puede señalizar y comunicarse con un NAS de la red principal. En la evolución a largo plazo/evolución de arquitectura de servicios (LTE/SAE) este servicio puede denominarse obtener una conexión de señalización para acceder al núcleo de paquetes potenciado (EPC). Para obtener la conexión de señalización, el AS ejecuta un procedimiento de establecimiento de conexión de RRC. El procedimiento incluye enviar un mensaje de petición de conexión de RRC desde el AS del UE hasta el AS de la estación base.

La figura 2 es un diagrama de flujo que muestra un procedimiento de establecimiento de RRC a modo de ejemplo ejecutado por un UE en comunicación con una red de EUTRAN. En una primera etapa 20 el UE emite un mensaje de RRCConnectionRequest a la EUTRAN. En respuesta, la EUTRAN envía un mensaje de RRCConnectionSetup al UE en la etapa 22 y recibe un mensaje de RRCConnectionSetupComplete a partir del UE en la etapa 24. Puede encontrarse un procedimiento de señalización similar en UMTS.

El procedimiento de petición de conexión de RRC ilustrado en la figura 2 puede iniciarse mediante el RRC para sus propias necesidades, o el procedimiento puede iniciarse cuando el NAS transmite una petición de una conexión de red al As tal como para permitir que el NAS se comunique con la red. Como tal, el AS puede pedir y establecer recursos en nombre del NAS.

Como parte del establecimiento de la conexión de señalización (por ejemplo, tal como se ilustra en la figura 2), el RRC del UE transmite al AS de la estación base una indicación del motivo para pedir la conexión. Los motivos pueden incluir varios valores incluyendo emergencia, acceso de alta prioridad, acceso de mt, señalización de mo, datos de mo, adicional 3, adicional 2 y adicional 1. La tabla 1 Ilustra protocolos de señalización de RRC de ejemplo incluyendo una cláusula de establecimiento y una definición de valores válidos para la cláusula de establecimiento que pueden proporcionarse por el NAS al A^s para pedir una conexión de señalización.

- ASNI START

RRCConnectionRequest ::= SEQUENCE {

critical Extensions CHOICE {

rrcConnectionRequest-r8 RRCConnectionRequest-r8-IEs, criticalExtensionsFuture SEQUENCE {}

RRCConnectionRequest-r8-IEs SEQUENCE {

ue-Identity InitialUE-Identity,

establishmentCause EstablishmentCause,

spare BIT STRING (SIZE (1))

InitialUE-Identity ::= CHOICE {

s-TMSI S-TMSI,

randomValue BIT STRING (SIZE (40))

EstablishmentCause ::= ENUMERATED {

emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, spare3, spare2, sparel}

- ASNISTOP

Tabla 1

La causa de establecimiento puede indicar a los nodos de destino (por ejemplo, la estación base/E-UTRAN y posiblemente la CN/EPC) el motivo para un establecimiento de este tipo de modo que pueden asignarse recursos apropiados para la conexión de señalización y el posterior uso de la conexión de señalización o la conexión de plano de usuario. La causa de establecimiento también puede usarse para diferenciar/distinguir en cuanto a planes/tarifas de cobro. En UMTS y EPS, la causa de establecimiento que proporciona el RRC a la red en un mensaje de petición de conexión de RRC se toma a partir de la petición entre capas a partir del NAS. Como tal, la causa de establecimiento de RRC que usa el AS (por ejemplo, el RRC) en la petición de conexión de RRC se recibe a partir del NAS. Por consiguiente, es el NAS el que determina qué causa de establecimiento debe usarse. Por ejemplo, con referencia a la tabla 1, puede usarse “establishmentCause” para proporcionar la causa de establecimiento para la petición de conexión de RRC tal como se proporciona por las capas superiores. Con respecto a los nombres de valores de causa, acceso de alta prioridad se refiere a AC11..AC15, “mt” representa “terminación móvil” y “mo” representa “origen móvil”.

En el caso de una llamada de emergencia, el NAS que inicia una llamada de emergencia de este tipo en nombre de las capas superiores (por ejemplo, las aplicaciones de llamada) puede indicar que está realizándose una llamada de emergencia. Si es así, puede leerse la causa de establecimiento de RRC por la estación base y la CN, y, en respuesta, la estación base y la CN pueden estar configuradas para hacer todo lo que puedan para proporcionar y mantener recursos para la llamada de emergencia.

Sin embargo, en algunas configuraciones de red, el UE puede estar configurado para implementar una capa de IMS para comunicaciones de paquetes conmutados (PS) (incluyendo comunicaciones de voz y datos). Para la capa de IMS dentro del UE hay una capa de IMS homóloga en el lado de CN. La capa de IMS dentro de la estación base reside por encima de la capa de NAS. En el lado de UE, la subcapa de IMS del UE se encuentra a la par que aplicaciones. Como tal, la capa (o subcapa) de IMS está por encima del ⁿA^s , y por encima de las funciones de gestión de movilidad y las funciones de gestión de sesión. La figura 3a es una ilustración de la distribución en capas dentro de un UE que muestra la subcapa de IMS. Tal como se muestra, la subcapa 30 de IMS reside por encima tanto de la capa 32 de ⁿA^s como de la capa 34 de AS. La capa de IMS puede usarse para iniciar comunicaciones de voz de PS. En algunos casos, un usuario puede desear iniciar una comunicación de voz de emergencia usando servicios proporcionados por la capa de IMS.

Pueden requerirse diversas redes de comunicaciones, incluyendo redes públicas móviles terrestres (PLMN), para soportar a un usuario que realiza una llamada de emergencia. Sin embargo, generalmente esas redes no soportan llamadas de emergencia realizadas dentro del dominio de PS (por ejemplo, usando IMS). Como tales, los sistemas existentes pueden basarse en servicios de dominio de circuito conmutado (CS) para proporcionar la llamada de emergencia. Aunque el UE de un usuario puede estar configurado para proporcionar comunicación de voz usando IMS, en el caso especial de una llamada de emergencia, el UE no usa los servicios de dominio de PS proporcionados por IMS. En vez de eso, el UE conmuta al servicio de dominio de CS para realizar la llamada de emergencia. Cuando el UE está conectado a una red que no proporciona servicios de dominio de CS, por ejemplo LTE/SAE, el UE puede estar configurado para implementar degradado de CS (CSFB) para proporcionar llamadas de emergencia (véase, por ejemplo, TS 3GPP 23.272). En CSFB, en vez de usar el dominio de P^s , el UE se mueve de vuelta a un sistema 2G o 3G y usa el dominio de CS del sistema 2G/3G para realizar la llamada de emergencia.

Sin embargo, más adelante puede requerirse que el dominio de PS de 3GPP soporte llamadas de emergencia. En ese caso, dado que el dominio de PS de 3GPP usa IMS como capa para establecer, controlar y gestionar una llamada o sesión o transacción, será la capa de IMS la que realice la llamada de emergencia en el dominio de PS. Como tal, para establecer una sesión de emergencia, la subcapa de IMS puede activar la capa de NAS con una petición para establecer acceso al núcleo de EPC. En respuesta, el NAS puede establecer entonces una conexión de señalización de NAS y el AS puede establecer la conexión de RRC. A su vez, el EPC, tras responder a la petición de NAS de acceso a red, establece las portadoras necesarias para soportar el servicio pedido. Sin embargo, en las redes existentes, aunque la capa de IMS puede indicar que los recursos pedidos son para una llamada de emergencia, no hay ningún mecanismo existente para que tal indicación se pase a través del NAS hasta el AS y, por consiguiente, hasta la estación base o red. Como tal, tras recibir la petición de conexión de RRC, el AS de la estación base puede no poder determinar que una conexión de señalización pedida particular es para una sesión de IMS que se pide para una llamada de emergencia.

En algunos casos, puede usarse un UE que funciona en un estado de servicios limitados para iniciar una llamada de emergencia. Un estado de servicios limitados puede resultar cuando un UE no tiene ningún módulo de identidad de abonado (SIM), cuando un usuario no ha pagado su factura telefónica y tiene una cuenta suspendida, o cuando un usuario se desplaza a un país extranjero e intenta acceder a servicios móviles en una red que no tiene un acuerdo de itinerancia apropiado con el proveedor nacional del usuario. En esas circunstancias, cuando se enciende el UE, el UE puede intentar entrar en un estado en el que el UE puede soportar una llamada de emergencia, pero no puede proporcionar servicios adicionales. Como tal, el UE puede acampar en una célula disponible de la PLMN en un estado de servicios limitados con el único propósito de proporcionar llamadas de emergencia. Si, en ese estado de servicios limitados, el UE está configurado para iniciar servicios de voz en dominio de PS (por ejemplo, mediante IMS) con el fin de proporcionar una llamada de emergencia, en muchas configuraciones de red el AS de la estación base puede no poder determinar que una sesión de IMS particular pedida por el UE en el estado de servicios limitados es para una llamada de emergencia.

Como tal, es difícil para una estación base determinar que una petición de conexión de RRC recibida a partir de un UE se usará en última instancia para una llamada de emergencia de IMS. Si la estación base no puede determinar que la petición es para una llamada de emergencia de IMS, la estación base no puede establecer rápidamente la sesión de emergencia, por ejemplo, liberando con naturalidad recursos de menor prioridad si no hay recursos de radio disponibles en la estación base. Estos problemas se agravan en configuraciones de red implementadas usando una configuración de compartición de red en la que una RAN, estación de transceptor base (BTS) o estación base se comparte eficazmente entre dos o más redes principales o PLMN.

El documento WO 2009/082936 detalla un método para llamada de emergencia, que comprende: un equipo de usuario UE inicia una petición de unión de emergencia para una red de SAE de red evolucionada, dicha petición de unión de emergencia incluye una indicación de emergencia; tras recibir dicha indicación de emergencia, dicha red de SAE elige una entidad de servicio de llamada de emergencia para dicho UE; tras unirse con emergencia a dicha red de SAE, dicho UE transmite dicha petición de llamada de emergencia a dicha entidad de servicio de llamada de emergencia; dicha entidad de servicio de llamada de emergencia establece una portadora de voz de emergencia, dicho UE realiza una llamada de emergencia basándose en dicha portadora de voz de emergencia establecida. En las realizaciones de la presente invención se proporciona un método para lograr la llamada de emergencia en dominio de circuito simulado con la entidad de servicio de llamada de emergencia en la red evolucionada, de modo que se realiza el servicio de llamada de emergencia en una red de paquetes de SAE/LTE.

3GPP TR 23.869 v9.0.0, páginas 1-36, se refiere a soporte para llamadas de emergencia de subsistema de multimedia de IP (IMS) basadas en protocolo de Internet (IP) sobre servicio de radio de paquetes general (GPRS) y servicio de paquetes evolucionado (EPS).

El documento US2005/090224 se refiere a un método de realización de llamadas de emergencia usado en un equipo de usuario en modo inactivo acampado en una primera célula de una red de comunicación inalámbrica que tiene una primera tecnología de acceso de radio que incluye las etapas de pedir una conexión de control de recursos de radio usando “llamada de emergencia” como petición de establecimiento, cambiar a una nueva célula en una zona de encaminamiento o zona de ubicación diferente de la primera célula, y pedir de nuevo una conexión de control de recursos de radio usando “llamada de emergencia” como petición de establecimiento. Este método evita realizar una actualización de zona de ubicación o una actualización de zona de encaminamiento cuando el equipo de usuario cambia a una nueva célula durante una llamada de emergencia y por tanto puede acelerar la realización de la llamada de emergencia en varios segundos.

La norma de 3GPP; 3GPP TS 24.301, n.° V9.0.0, páginas 265-266, se refiere a “3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); stage 3 (Release 9)”.

En las reivindicaciones se expone una invención.

Breve descripción de los dibujos

Para una comprensión más completa de esta divulgación, ahora se hace referencia a la siguiente breve descripción, tomada en relación con los dibujos adjuntos y la descripción detallada, en los que números de referencia similares representan partes similares.

La figura 1 es una ilustración de algunas de las capas de protocolo encontradas dentro de sistemas de telecomunicaciones existentes e ilustra un protocolo en capas que puede usarse para comunicaciones entre un equipo de usuario (UE) y una estación base;

la figura 2 es un diagrama de flujo de secuencia de mensajes que muestra un procedimiento de establecimiento de control de recursos de radio (RRC) a modo de ejemplo ejecutado por un UE en comunicación con una red de red de acceso de radio terrestre universal evolucionada (EUTRAN);

la figura 3a es una ilustración de disposición en capas dentro de un UE que muestra la subcapa de subsistema de multimedia de protocolo de Internet (IP);

la figura 3b es una ilustración del procedimiento para que un estrato sin acceso (NAS) de un UE transmita una petición de servicio a un NAS de la red;

la figura 4 es un diagrama de flujo que muestra un procedimiento a modo de ejemplo para realizar una llamada de emergencia de IMS usando un UE que está registrado en NAS en modo inactivo de NAS o conectado de NAS;

la figura 5 es un diagrama de flujo que muestra un procedimiento a modo de ejemplo para realizar una llamada de emergencia de IMS usando un UE que está en un estado de servicios limitados;

la figura 6 es un diagrama de flujo que muestra un procedimiento a modo de ejemplo para realizar una llamada de emergencia de IMS usando un UE que está en un estado de servicios limitados en el que la red está funcionando en una configuración de compartición de red;

la figura 7 es un diagrama de un sistema de comunicaciones inalámbricas que incluye un UE que puede hacerse funcionar para algunas de las diversas realizaciones de la divulgación;

la figura 8 es un diagrama de bloques de un UE que puede hacerse funcionar para algunas de las diversas realizaciones de la divulgación;

la figura 9 es un diagrama de un entorno de software que puede implementarse en un UE que puede hacerse funcionar para algunas de las diversas realizaciones de la divulgación; y

la figura 10 es un sistema informático de propósito general ilustrativo adecuado para algunas de las diversas realizaciones de la divulgación.

Descripción detallada

La presente invención se refiere de manera general a determinar causas de establecimiento y más específicamente a métodos y a sistemas para determinar causas de establecimiento de control de recursos de radio (RRC) usando procedimientos de estrato sin acceso (NAS).

Para ello, algunas realizaciones incluyen un método para iniciar una llamada de emergencia de paquetes conmutados usando un equipo de usuario (UE). El UE incluye una pluralidad de capas de protocolo. La pluralidad de capas de protocolo incluyen una subcapa de IMS, una capa de estrato sin acceso (NAS) y una capa de estrato de acceso (AS). El método incluye generar una petición de unión usando el UE. La petición de unión tiene un tipo de unión. El método incluye recuperar el tipo de unión de la petición de unión usando la capa de NAS del UE, y generar una petición de conexión de RRC. La petición de conexión de RRC incluye una causa de establecimiento de RRC basada en el tipo de unión de la petición de unión.

Otra realización es un método para iniciar una llamada de emergencia de subsistema de multimedia (IMS) de protocolo de Internet (IP) usando un equipo de usuario (UE). El UE incluye una pluralidad de capas de protocolo. La pluralidad de capas de protocolo incluyen una subcapa de IMS, una capa de estrato sin acceso (NAS) y una capa de estrato de acceso (AS). El método incluye generar una petición de unión usando el UE. La petición de unión tiene un tipo de unión. El método incluye recuperar el tipo de unión de la petición de unión usando la capa de NAS del UE, y, cuando el tipo de unión es un primer valor, generar una petición de conexión de RRC. La petición de conexión de RRC incluye una causa de establecimiento de RRC que tiene un segundo valor.

Otra realización es un método para iniciar una llamada de emergencia de subsistema de multimedia (IMS) de protocolo de Internet (IP) usando un equipo de usuario (UE). El UE incluye una pluralidad de capas de protocolo. La pluralidad de capas de protocolo incluyen una subcapa de IMS, una capa de estrato sin acceso (NAS) y una capa de estrato de acceso (AS). El método incluye generar una petición de conectividad de PDN usando el UE, teniendo la petición de conectividad de PDN un tipo de petición, recuperar el tipo de petición de la petición de conectividad de PDN, y, cuando el tipo de petición es un primer valor, generar una petición de conexión de RRC, incluyendo la petición de conexión de RRC una causa de establecimiento de RRC que tiene un segundo valor.

Otra realización es un método para iniciar una llamada de emergencia de subsistema de multimedia (IMS) de protocolo de Internet (IP) usando un equipo de usuario (UE). El UE incluye una pluralidad de capas de protocolo. La pluralidad de capas de protocolo incluyen una subcapa de IMS, una capa de estrato sin acceso (NAS) y una capa de estrato de acceso (AS). El método incluye generar un tipo de llamada usando el UE, teniendo el tipo de llamada un primer valor, generar una petición de conexión de RRC usando la capa de NAS del UE, incluyendo la petición de conexión de RRC una causa de establecimiento de RRC que tiene un segundo valor, usar la capa de NAS del UE para proporcionar el tipo de llamada cuando se pide una conexión de RRC a la capa de AS del UE, y usar la capa de AS del UE para transmitir el tipo de llamada y la petición de conexión de RRC a una estación base.

Otras realizaciones incluyen un método para iniciar una llamada de emergencia de subsistema de multimedia (IMS) de protocolo de Internet (IP) usando un equipo de usuario (UE). El UE incluye una pluralidad de capas de protocolo. La pluralidad de capas de protocolo incluyen una subcapa de IMS, una capa de estrato sin acceso (NAS) y una capa de estrato de acceso (AS). El método incluye generar una petición de conectividad de PDN para la capa de NAS del UE, incluyendo la petición de conectividad de PDN un nombre de punto de acceso (APN), recuperar el ^a Pⁿ de la petición de conectividad de PDN, y, cuando el APN identifica un APN de emergencia, generar una petición de conexión de RRC, incluyendo la petición de conexión de RRC una causa de establecimiento de RRC que tiene un segundo valor.

Otras realizaciones incluyen proporcionar una estación base recursos de radio a un equipo de usuario (UE) para iniciar una llamada de emergencia de subsistema de multimedia (IMS) de protocolo de Internet (IP). La estación base incluye una pluralidad de capas de protocolo. La pluralidad de capas de protocolo incluyen una capa de estrato de acceso (AS). La estación base incluye un procesador configurado para recibir un tipo de llamada a partir de la capa de AS del UE, teniendo el tipo de llamada un primer valor, y recibir una petición de conexión de RRC a partir de la capa de AS del UE, incluyendo la petición de conexión de RRC una causa de establecimiento de RRC que tiene un segundo valor.

Otras realizaciones incluyen proporcionar una estación base recursos de radio a un equipo de usuario (UE) para iniciar una llamada de emergencia de subsistema de multimedia (IMS) de protocolo de Internet (IP). La estación base incluye una pluralidad de capas de protocolo. La pluralidad de capas de protocolo incluyen una capa de estrato de acceso (AS). La estación base incluye un procesador configurado para recibir una petición de conexión de RRC y, cuando la petición de conexión de RRC incluye una causa de establecimiento de RRC que tiene un valor de al menos una de sesión o llamada de emergencia de EPS, emergencia de PS, sesión o llamada de emergencia de IMS, servicios de emergencia, y llamada de emergencia, proporcionar recursos de radio necesarios para soportar una llamada de emergencia de IMS al UE.

Para lograr las finalidades anteriores y relacionadas, la invención comprende entonces las características descritas completamente a continuación en el presente documento. La siguiente descripción y los dibujos adjuntos exponen en detalle determinados aspectos ilustrativos de la invención. Sin embargo, estos aspectos son indicativos de tan sólo algunas de las diversas maneras en las que pueden emplearse los principios de la invención. Otros aspectos y características novedosas de la invención resultarán evidentes a partir de la siguiente descripción detallada de la invención cuando se tiene en cuenta junto con los dibujos.

Ahora se describen los diversos aspectos de la invención objeto con referencia a los dibujos adjuntos, en los que números similares se refieren a elementos similares o correspondientes en la totalidad de los mismos. Sin embargo, debe entenderse que no se pretende que los dibujos y la descripción detallada relacionada con los mismos limiten el objeto reivindicado a la forma particular dada a conocer. En vez de eso, se pretende cubrir todas las modificaciones y alternativas que se encuentren dentro del alcance del objeto reivindicado.

Tal como se usa en el presente documento, se pretende que los términos “componente”, “sistema” y similares se refieran a una entidad relacionada con ordenador, 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, una parte 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 el ordenador pueden ser un componente. Uno o más componentes pueden residir dentro de un proceso y/o hilo de ejecución y un componente puede estar ubicado en un ordenador y/o distribuido entre dos o más ordenadores.

El término “a modo de ejemplo” se usa en el presente documento para querer decir que sirve como ejemplo, caso o ilustración. No debe interpretarse necesariamente cualquier aspecto o diseño descrito en el presente documento como “a modo de ejemplo” como preferido o ventajoso con respecto a otros aspectos o diseños.

Además, el objeto dado a conocer puede implementarse como un sistema, método, aparato o artículo de fabricación que usa técnicas de programación y/o ingeniería convencionales para producir software, firmware, hardware o cualquier combinación de los mismos para controlar un ordenador o dispositivo basado en procesador para implementar aspectos detallados en el presente documento. Se pretende que el término “artículo de fabricación” (o alternativamente, “producto de programa informático”) tal como se usa en el presente documento abarque un programa informático accesible a partir de cualquier dispositivo, soporte o medios legibles por ordenador. Por ejemplo, los medios legibles por ordenador pueden incluir, pero no se limitan a, dispositivos de almacenamiento magnéticos (por ejemplo, disco duro, disco flexible, tiras magnéticas,...), discos ópticos (por ejemplo, disco compacto (CD), disco versátil digital (DVD),...), tarjetas inteligentes y dispositivos de memoria flash (por ejemplo, tarjeta, llave). Adicionalmente, debe apreciarse que puede emplearse una onda portadora para transportar datos electrónicos legibles por ordenador tales como los usados en la transmisión y recepción de correo electrónico o en el acceso a una red tal como Internet o una red de área local (LAN). Evidentemente, los expertos en la técnica reconocerán que pueden realizarse muchas modificaciones en esta configuración sin alejarse del alcance o espíritu del objeto reivindicado.

En una red de comunicaciones móviles, los controladores de protocolo y señalización de capa de red del UE y la CN se comunican entre sí a través de enlaces de comunicaciones establecidos por los controladores de red de acceso de radio subyacentes. En terminologías de UMTS y 3GPP, por ejemplo, la capa de red entre el UE y la CN se denomina NAS. La capa de acceso de radio de la red de acceso de radio (RAN) se denomina AS.

Dado que las capas subyacentes proporcionan servicios a las capas superiores, en el caso de tecnologías de UMTS y 3GPP, por ejemplo, el AS proporciona servicios al NAS. Un servicio de este tipo proporcionado por el AS es establecer una conexión de señalización para el NAS de un UE de tal manera que el NAS del UE puede señalizar y comunicar a un NAS de la red principal. Como tal, cuando el NAS del UE desea transmitir una petición de servicio al NAS de la red, el AS puede ejecutar un procedimiento de establecimiento de conexión de RRC para establecer una conexión de radio subyacente.

La figura 3b es una ilustración del procedimiento para que un NAS de un UE transmita una petición de servicio a un NAS de la red. Con referencia a la figura 3b, para transferir una petición de servicio desde un NAS de un UE hasta un NAS de la red, en la etapa 31 el NAS del UE transmite en primer lugar al AS del UE a) un bloque de datos y b) una causa de establecimiento. En la etapa 33, el AS de UE comienza un procedimiento de petición de conexión de RRC que envía una petición de conexión de RRC al AS de la RAN. La petición de conexión de RRC lleva con ella la causa de establecimiento que se proporcionó por el NAS del UE. En la etapa 35, el AS de la RAN comienza a asignar recursos para la conexión de radio y envía un mensaje de establecimiento de conexión de RRC al UE. En la etapa 37, el AS del UE acepta el recurso de radio y da acuse de recibo del establecimiento enviando un mensaje de establecimiento de conexión de RRC completado. Con el mensaje de establecimiento de conexión de RRC completado, el AS del UE también pasa el bloque de datos recibido a partir del NAS del UE. En este punto, el bloque de datos recibido a partir del NAS no se inspecciona por el AS del UE o la RAN.

En la etapa 39, el AS de la RAN pasa el bloque de datos a la función de interfuncionamiento de la RAN y en la etapa 41, la función de interfuncionamiento de la RAN realiza el interfuncionamiento del bloque de datos a través del lado de red y pasa el bloque de datos a los controladores de RAN-CN de la RAN. En la etapa 43, los controladores de RAN-CN establecen una conexión de red principal para la CN y pasan el bloque de datos a los controladores de CN-RAN de la CN. Finalmente, en la etapa 45, los controladores de CN-RAN reciben el bloque de datos y pasan el bloque de datos al NAS de la CN. En este punto, el NAS de la CN inspecciona el bloque de datos e identifica una petición de servicio proporcionada dentro del bloque de datos. Por consiguiente, sólo en la etapa 45 descubre la CN que el UE ha enviado una petición de servicio en la transmisión original desde el NAS del UE hasta el AS. Para realizar otros servicios tales como CSFB, puede sustituirse el mensaje de petición de servicio por un mensaje de petición de servicio extendido.

Por tanto, durante la ejecución de las etapas 33, 35, 37, 39, 41 y 43 ninguna de las entidades entre el NAS del UE y el NAS de la CN saben que el bloque de datos original transmitido por el NAS del UE es realmente un mensaje de petición de servicio. Durante la ejecución del procedimiento, cada componente entre el NAS del UE y el nAs de la CN simplemente pasa el bloque de datos entre ellos sin inspeccionar el contenido del bloque de datos. Como resultado, sólo en la etapa 45 la CN reconoce que el bloque de datos contiene una petición de servicio.

Por consiguiente, dado que lo datos no se inspeccionan hasta el final del procedimiento ilustrado en la figura 3b, es difícil para la red determinar que está pidiéndose un recurso particular. Por ejemplo, cuando se inicia una llamada de emergencia de IMS, la red no sabe hasta el final del procedimiento que está pidiéndose un recurso para una llamada de emergencia de IMS. Específicamente, una estación base puede no poder determinar que una petición de conexión de RRC recibida a partir de un UE se usará en última instancia para una llamada de emergencia de IMS. Si la estación base no puede determinar que la petición es para una llamada de emergencia de IMS, la estación base no puede establecer rápidamente la sesión de emergencia, por ejemplo, liberando con naturalidad recursos de menor prioridad si no hay recursos de radio disponibles en la estación base. Estos problemas se agravan en configuraciones de red implementadas usando una configuración de compartición de red en la que una RAN, BTS o estación base se comparte eficazmente entre dos o más redes principales o PLMN. Este problema no se limita a llamadas de emergencia, sino que puede aplicarse a cualquier servicio en el que un recurso debe recibir una manipulación especial.

La figura 4 es un diagrama de flujo que muestra un procedimiento 40 a modo de ejemplo para realizar una llamada de emergencia de IMS usando un U^e que está registrado en NAS en modo inactivo de ⁿA^s o conectado de NAS. El diagrama de flujo muestra un procedimiento que no permite que la estación base determine si el procedimiento se inicia mediante una petición de una llamada de emergencia de IMS.

Haciendo referencia a la figura 4, en la etapa 42, las aplicaciones y la pila de IMS determinan que el usuario desea iniciar una llamada de emergencia de IMS. Como tal, la capa de IMS pide que se use una nueva sesión de EPS para la llamada de emergencia de IMS. En la etapa 44, tras recibir la petición a partir de la capa de IMS, la entidad de gestión de sesión de EPS (ESM) inicia una petición de una conexión de red de datos en paquetes (PDN) de emergencia a través del NAS del UE. Como tal, la ESM emite una petición de conectividad de PDN. En la etapa 46, tras emitirse la petición de conectividad de PDN, se activa la gestión de movilidad de EPS (EMM) y, en la etapa 48, el sistema comprueba si el NAS del UE está registrado. Si está registrado, en la etapa 50 el UE envía un SERVICE_REQUEST al EPC para activar el AS dentro del UE para establecer una conexión de RRC. En esta etapa, la causa de establecimiento de RRC especifica datos originados en móvil (MO) y el tipo de llamada indica que hay una llamada de origen. En la etapa 52, el AS del UE pide la conexión de RRC. La causa de establecimiento de RRC recibida a partir el NAS del UE (por ejemplo, datos de MO) se pasa a la estación base. Sin embargo, es importante observar que en este procedimiento no se proporciona el tipo de llamada a la estación base, el tipo de llamada sólo se usa por el AS del UE para verificar comparando con los derechos de acceso de diferentes tipos de llamadas que pueden realizarse. Como tal, y tal como se indica mediante el recuadro 54, la estación base, tras inspeccionar la petición de conexión de RRC (sin el tipo de llamada asociado), no puede determinar si está pendiente una llamada de emergencia de IMS. Como resultado, no se realizará ninguna manipulación especial por la estación base.

Tras establecer la conexión de RRC, el NAS del UE envía una petición de servicio y pasa a modo conectado de NAS en la etapa 56. Tras entrar en modo conectado de NAS, el NAS envía una petición de conectividad de PDN con un tipo de petición de “emergencia” en la etapa 58. Tras recibir la petición de conectividad de PDN con un tipo de petición de “emergencia”, la CN reconoce que está pendiente una llamada de emergencia y pide que la estación base proporcione recursos de radio para iniciar la llamada de emergencia en la etapa 60. Por consiguiente, tal como se indica mediante el recuadro 62, sólo después de que la CN reconozca que está pendiente una llamada de emergencia y pida que la estación base proporcione recursos de radio necesarios, entonces la estación base puede tener constancia de que está pendiente una llamada de emergencia de IMS.

Sin embargo, si, en la etapa 48, el sistema determina que el UE ya está en modo conectado de NAS, el NAS procede a enviar una petición de conectividad de PDN con un tipo de petición de “emergencia” en la etapa 58 y continúa el mismo procedimiento.

Por consiguiente, cuando se implementa el procedimiento ilustrado en la figura 4, las causas de establecimiento de RRC existentes son insuficientes para indicar a la estación base que debe realizarse una llamada de emergencia de IMS. Además, en implementaciones de red convencionales, no se pasa el tipo de llamada a la estación base y no indica que esté realizándose una llamada de emergencia de IMS (por ejemplo, el tipo de llamada puede especificar únicamente una llamada de MO). De hecho, en implementaciones existentes, el tipo de llamada sólo puede usarse para comprobar derechos de acceso para el tipo particular de llamada identificada por el tipo de llamada. Estos problemas se agravan si el UE está en modo conectado cuando tiene que realizarse una llamada de emergencia de IMS porque entonces el NAS puede establecer simplemente la conexión de PDN para emergencia y el AS no recibirá ninguna indicación de que debe realizarse una llamada de emergencia.

Por consiguiente, usando el procedimiento ilustrado en la figura 4, la estación base, aunque inspeccione la causa de establecimiento de RRC, no puede determinar que la llamada pedida es una llamada de IMS de emergencia, o una llamada que requiere manipulación especial. No se proporciona el tipo de llamada a la estación base, y la estación base sólo llegará a saber que hay una llamada de emergencia después de la señalización de EMM de NAS y la señalización de ESM de NAS cuando el EPC pide la asignación de recursos. Aunque al final del procedimiento la estación base puede llegar a saber que tiene que realizarse una llamada de emergencia, para entonces la estación base puede haber asignado recursos esenciales a otros UE que pueden estar realizando llamadas de emergencia usando CSFB. Una llamada basada en paquetes, tal como la llamada de emergencia de IMS, puede realizarse por un usuario humano de alta prioridad (por ejemplo, personal de servicio civil o público en situaciones de emergencia) mientras que la emergencia de CSFB puede ser de cualquier usuario habitual.

La figura 5 es un diagrama de flujo que muestra un procedimiento 70 a modo de ejemplo para realizar una llamada de emergencia de IMS usando un UE que está en un estado de servicios limitados, tal como se describió anteriormente. El diagrama de flujo muestra un procedimiento que no permite que la estación base determine si el procedimiento se inicia mediante una petición de una llamada de emergencia de IMS.

Haciendo referencia a la figura 5, en la etapa 72, las aplicaciones y la pila de IMS de un UE en un estado de servicios limitados determinan que el usuario desea iniciar una llamada de emergencia de IMS. Como tal, la capa de IMS pide que se use una nueva sesión de EPS para la llamada de emergencia de IMS. En la etapa 74, tras recibir la petición a partir de la capa de IMS, la ESM inicia una petición de una conexión de PDN de emergencia a través del NAS del UE. Como tal, la ESM emite una petición de conectividad de PDN. En la etapa 76, tras emitirse la petición de conectividad de PDN, se activa la EMM y el sistema comprueba si el NAS del UE está registrado. En este ejemplo, dado que el UE está funcionando en un estado de servicios limitados el NAS no está registrado. Por consiguiente, en la etapa 78, el NAS determina que necesita enviar una petición de unión. En este caso, dado que el UE está iniciando una llamada de emergencia, la petición de unión incluye un tipo de unión de “unión de emergencia de EPS”. En esta etapa, el NAS también envía una petición de conectividad de PDN que tiene un tipo de petición de “emergencia”. En la etapa 80 el NAS activa el AS para una conexión de RRC. La causa de establecimiento de RRC se establece a señalización de MO y el tipo de llamada se establece a llamada de emergencia. En la etapa 82, el AS del UE pide la conexión de RRC. La causa de establecimiento de RRC recibida a partir del NAS del UE (por ejemplo, señalización de MO) se pasa a la estación base. Sin embargo, es importante observar que en este procedimiento no se proporciona el tipo de llamada a la estación base, el tipo de llamada sólo se usa por el AS del UE para verificar comparando con los derechos de acceso de diferentes tipos de llamadas que se permite realizar. Como tal, la estación base, tras inspeccionar la petición de conexión de RRC (sin el tipo de llamada asociado), no puede determinar si está pendiente una llamada de emergencia de IMS. Como resultado, no se realizará ninguna manipulación especial por la estación base.

Tras establecer la conexión de RRC, el NAS del UE envía la petición de unión en la etapa 84. Tras entrar en modo conectado de NAS, el NAS envía una petición de conectividad de PDN con un tipo de petición de “emergencia” en la etapa 86. Tras recibir la petición de conectividad de PDN con un tipo de petición de “emergencia”, la CN reconoce que está pendiente una llamada de emergencia y pide que la estación base proporcione recursos de radio para iniciar la llamada de emergencia. Por consiguiente, tal como se indica mediante el recuadro 88, sólo después de que la CN reconozca que está pendiente una llamada de emergencia y pida que la estación base proporcione recursos de radio necesarios, entonces la estación base puede tener constancia de que está pendiente una llamada de emergencia de IMS.

En un sistema de LTE/SAE, el sistema puede permitir la ejecución de las etapas 84 y 86 de una manera concatenada. Como tal, conceptualmente, la etapa 84 y la etapa 86 pueden ejecutarse como una pero ser, lógicamente, dos etapas. Esta ejecución conceptual de las etapas 84 y 86 de una manera concatenada no cambia el problema identificado.

La figura 6 es un diagrama de flujo que muestra un procedimiento 90 a modo de ejemplo para realizar una llamada de emergencia de IMS usando un UE que está en un estado de servicios limitados en el que la red está funcionando en una configuración de compartición de red. En una configuración de compartición de red, una RAN, BTS o estación base se comparte eficazmente entre dos o más redes principales o PLMN. Por consiguiente, la figura 6 muestra un UE que puede estar en comunicación con al menos uno de EPCa, EPCb y EPCc. El diagrama de flujo muestra un procedimiento que no permite que la estación base determine si el procedimiento se inicia mediante una petición de una llamada de emergencia de IMS.

Haciendo referencia a la figura 6, en la etapa 92, las aplicaciones y la pila de IMS determinan que el usuario desea iniciar una llamada de emergencia de IMS. Como tal, la capa de IMS pide que se use una nueva sesión de EPS para la llamada de emergencia de IMS. El bloque 92 puede implementarse según las etapas 74, 76 y 78 de la figura 5. En la etapa 94 el NAS activa el AS para una conexión de RRC. La causa de establecimiento de RRC se establece a señalización de MO y el tipo de llamada se establece a llamada de emergencia. En la etapa 96, el AS del UE pide la conexión de RRC. La causa de establecimiento de RRC recibida a partir del NAS del UE (por ejemplo, señalización de MO) se pasa a la estación base. Sin embargo, es importante observar que en este procedimiento no se proporciona el tipo de llamada a la estación base, el tipo de llamada sólo se usa por el AS del UE para verificar comparando con los derechos de acceso de diferentes tipos de llamadas que se permite realizar. Como tal, la estación base, tras inspeccionar la petición de conexión de RRC (sin el tipo de llamada asociado), no puede determinar si está pendiente una llamada de emergencia de IMS. Como resultado, no se realizará ninguna manipulación especial por la estación base.

Tras establecer la conexión de RRC, el NAS del UE envía la petición de unión en la etapa 98. Tras entrar en modo conectado de NAS, el NAS envía una petición de conectividad de PDN con un tipo de petición de “emergencia” en la etapa 100. Tras recibir la petición de conectividad de PDN con un tipo de petición de “emergencia”, la CN reconoce que está pendiente una llamada de emergencia y pide que la estación base proporcione recursos de radio para iniciar la llamada de emergencia. Por consiguiente, tal como se indica mediante el recuadro 102, sólo después de que la CN reconozca que está pendiente una llamada de emergencia y pida que la estación base proporcione recursos de radio necesarios, entonces la estación base puede tener constancia de que está pendiente una llamada de emergencia de IMS.

En un sistema de LTE/SAE, el sistema puede permitir la ejecución de las etapas 98 y 100 de una manera concatenada. Como tal, conceptualmente, la etapa 98 y la etapa 100 se ejecutan como una pero pueden ser, lógicamente, dos etapas. Esta ejecución conceptual de las etapas 98 y 100 de una manera concatenada no cambia el problema identificado.

Tal como se muestra en la figura 6, cuando la red está implementando compartición de red, surgen problemas adicionales. En el caso de compartición de red, no todas las PLMN a las que está dando servicio la estación base tienen que soportar llamadas de emergencia de IMS. Sin embargo, dado que la estación base sabe qué PLMN soportan llamadas de emergencia de IMS, la estación base puede poder seleccionar una PLMN apropiada para una llamada de emergencia de IMS. Para ello, la estación base debe detectar en primer lugar que el ^u E está intentando realizar una llamada de emergencia de IMS mientras está en un estado de servicios limitados y después seleccionar una de las PLMN que soportarán la llamada de emergencia de IMS. Por consiguiente, es importante que la estación base pueda detectar rápidamente que está realizándose una llamada de emergencia de IMS a partir de un UE en estado de servicios limitados para que pueda elegirse una PLMN apropiada.

Por consiguiente, los sistemas y procedimientos para iniciar una llamada de emergencia de IMS ilustrados en las figuras 4-6 no logran notificar de manera adecuada al AS que los recursos pedidos van a usarse para una llamada de emergencia de IMS. Como resultado, puede retrasarse el proporcionar los recursos necesarios, o puede que no se logre proporcionar los recursos en absoluto, con el posible resultado de que, incluso en circunstancias en las que los recursos necesarios estarían de otro modo disponibles, puede no lograrse la llamada de emergencia. Por ejemplo, pueden surgir problemas cuando un UE está acampado en una célula de red y está en un estado registrado en nAs . Cuando el UE está en modo conectado, el AS no conoce la información pasada entre el UE y la CN para establecer la llamada de emergencia de IMS. Como resultado, la estación base no puede detectar que está realizándose una llamada de emergencia de IMS hasta que la CN inicia una petición de recursos hacia la estación base y la petición de recursos indica que una llamada de emergencia de IMS es inminente. Véase, por ejemplo, la figura 4. De manera similar, cuando el UE está en modo inactivo, el AS del UE recibe una petición a partir del NAS del UE para establecer una conexión de RRC. Sin embargo, las causas de establecimiento de RRC existentes no son lo suficientemente precisas como para indicar al AS que está realizándose una llamada de emergencia de IMS. Estos problemas se aplican no sólo a llamadas de emergencia de IMS, sino a cualquier llamada basada en paquetes en la que puede evitarse el retraso de proporcionar recursos necesarios.

En una realización, el presente sistema permite que una estación base distinga llamadas que se piden en el dominio de CS (por ejemplo, mediante CSFB) de las pedidas en el dominio de PS, por ejemplo, IMS. Como resultado, la estación base puede estar configurada para proporcionar los servicios necesarios para la llamada de PS para minimizar cualquier retraso asociado con el inicio de la llamada y garantizar que se pone a disposición cualquier recurso necesario. Cuando el UE inicia un procedimiento de unión, se usa el tipo de unión para determinar la causa de establecimiento de RRC. Entonces el UE envía la causa de establecimiento de RRC en la petición de conexión de RRC de modo que puede producirse una provisión de recursos necesarios acelerada. En una implementación del presente sistema, cuando el UE inicia un procedimiento de unión, el tipo de unión se establece a “unión de emergencia de EPS”. El NAS del UE recibe y detecta el valor de tipo de unión y está configurado para establecer la causa de establecimiento de RRC a una de las siguientes cuando el tipo de unión es “unión de emergencia de EPS”: “sesión o llamada de emergencia de EPS”, “emergencia de PS”, “sesión o llamada de emergencia de IMS”, “servicios de emergencia” o “llamada de emergencia”. Cuando la estación base recibe un mensaje de petición de conexión de RRC que tiene una causa de establecimiento de RRC establecida a una de “sesión o llamada de emergencia de EPS”, “emergencia de PS”, “sesión o llamada de emergencia de IMS”, “servicios de emergencia” o “llamada de emergencia” la estación base puede estar configurada para reconocer que está realizándose una llamada de emergencia de IMS. Como resultado, la estación base puede atender a la llamada de emergencia proporcionando a la llamada una prioridad escalada e intentando garantizar que se pone a disposición cualquier recurso necesario.

Además, en el caso de un UE en estado de servicios limitados y una estación base configurada para soportar compartición de red, la incapacidad de la estación base para determinar que el UE está en estado de servicios limitados haciendo una llamada de emergencia puede conducir a que esa petición de llamada se distribuya a una red principal de la configuración de red compartida que puede que no pueda soportar una llamada de emergencia de IMS.

Por consiguiente, el presente sistema usa el valor de tipo de unión especificado durante el procedimiento de unión para determinar o mapear a la causa de establecimiento de RRC. Cuando el tipo de unión se establece a “unión de emergencia de EPS”, por ejemplo, la causa de establecimiento de RRC se establece por consiguiente a “sesión o llamada de emergencia de EPS”, “emergencia de PS”, “llamada de emergencia” u otro valor apropiado.

Los sistemas anteriores permiten una causa de establecimiento de RRC que indica “llamada de emergencia”. Aunque esa configuración permite que una estación base determine que está realizándose una llamada de emergencia, no permite que la estación base distinga entre una llamada de PS, tal como una llamada de emergencia de IMS, y una llamada de emergencia de CSFB.

Como alternativa, pueden introducirse valores de casos de establecimiento de RRC adicionales de “sesión o llamada de emergencia de EPS”, “emergencia de PS”, “sesión o llamada de emergencia de IMS” o “servicios de emergencia” y usarse para indicar que está estableciéndose una llamada de PS, tal como una llamada de emergencia de IMS. En esta realización, pueden usarse causas de establecimiento de RRC alternativas nombradas de manera apropiada para distinguir la llamada de emergencia como una llamada de PS, tal como una llamada de emergencia de IMS, en vez de una llamada de emergencia de CSFB.

En otra implementación, puede usarse el tipo de petición para determinar la causa de establecimiento de RRC. Por ejemplo, cuando el UE necesita iniciar una petición de conectividad de PDN para conseguir una PDN de emergencia el UE puede estar configurado para establecer el tipo de petición a “emergencia”. El tipo de petición de “emergencia” puede usarse entonces para mapear o determinar la causa de establecimiento de RRC haciendo, por ejemplo, que el valor de causa de establecimiento de RRC se establezca a “sesión o llamada de emergencia de EPS”, “P^s llamada de emergencia”, “sesión o llamada de emergencia de IMS”, “servicios de emergencia”, “llamada de emergencia” o alguna otra causa nombrada de manera apropiada. En esta implementación, cuando la estación base recibe un mensaje de petición de conexión de RRC que tiene una causa de establecimiento de RRC establecida a “sesión o llamada de emergencia de EPS”, “emergencia de PS”, “sesión o llamada de emergencia de IMS”, “servicios de emergencia” o “llamada de emergencia”, la estación base puede estar configurada para detectar que está realizándose una llamada de emergencia de IMS y puede intentar proporcionar cualquier recurso necesario. Si la causa de establecimiento de RRC sólo se estableciera a “llamada de emergencia”, la estación base, aunque puede que sepa que se producirá una llamada de emergencia, no puede distinguir una llamada de PS, tal como una llamada de emergencia de IMS, de una llamada de emergencia de CSFB.

Como tal, en una realización adicional, se usa el valor de tipo de petición para determinar o mapear a una causa de establecimiento de RRC particular. Por ejemplo, cuando el tipo de petición = “emergencia”, la causa de establecimiento de RRC se establece a “sesión o llamada de emergencia de EPS”, “emergencia de PS”, “sesión o llamada de emergencia de IMS”, “servicios de emergencia” o algún otro valor apropiado distinto de “llamada de emergencia”.

En algunas implementaciones del presente sistema, cuando el UE inicia el procedimiento de petición de servicio que activa la petición para la conexión de RRC, la causa de establecimiento de RRC puede mapearse a partir del (o determinarse mediante el) tipo de petición del procedimiento para el que está prevista la conexión de RRC (por ejemplo, el tipo de petición puede establecerse en la petición de conectividad de PDN). Dicho de otro modo, la causa de establecimiento de RRC puede determinarse mediante el uso final de la conexión de RRC y mediante el procedimiento que activa la conexión de RRC (es decir, el procedimiento de petición de servicio). Este establecimiento de la causa de establecimiento de RRC puede realizarse usando el tipo de petición de la petición de conectividad de PDN que apunta al uso final de la conexión de RRC.

En otra implementación del presente sistema, el tipo de llamada puede proporcionarse a la RAN/estación base (por ejemplo, un eNB). Por ejemplo, con referencia a la figura 4, en vez de usar sólo el tipo de llamada para verificar comparando con los derechos de acceso de diferentes tipos de llamadas que se permite realizar, el valor de tipo de llamada que se pasa desde el NAS hasta el AS es como parte de o además de la petición de conexión de RRC que puede comunicarse a la estación base.

En esta implementación, únicamente establecer un tipo de llamada de “llamada de emergencia” para el procedimiento de unión para servicios de emergencia de EPS, puede ser insuficiente ya que procedimientos de NAS adicionales que se ejecutan para soportar llamadas de emergencia de IMS deben tener igualmente el tipo de llamada establecido a “llamadas de emergencia”. Por ejemplo, los procedimientos pueden incluir una petición de conexión de PDN a un nombre de punto de acceso (APN) de emergencia, un procedimiento de petición de servicio que porta una conexión de PDN a un APN de emergencia, y un procedimiento de actualización de área de seguimiento que puede usarse para activar el conocimiento del UE por parte del EPC pero posteriormente el UE realizará una llamada de emergencia de IMS.

En esta implementación, cuando la estación base recibe la petición de conexión de RRC con un tipo de llamada establecido a llamada de emergencia, la estación base puede estar configurada para reconocer que se realizará una llamada de emergencia y puede atender a los recursos necesarios. Sin embargo, si el tipo de llamada sólo se establece a “llamadas de emergencia”, la estación base puede que no pueda distinguir entre llamadas de emergencia de CSFB o llamadas de PS, tales como llamadas de emergencia de IMS.

En este caso, el tipo de llamada puede transmitirse a la estación base como nuevo elemento de información (IE) o como nuevo campo de información dentro de un IE existente. Tras recibir el tipo de llamada, la estación base puede estar configurada para comprobar el tipo de llamada y actuar en consecuencia. Si el tipo de llamada indica que una llamada de emergencia es inminente, la estación base puede emprender las acciones apropiadas incluyendo reservar recursos de radio.

Dado que la estación base no puede distinguir entre llamadas de emergencia de CSFB y llamadas de PS, tales como llamadas de emergencia de IMS, usando un único valor de tipo de llamada = “llamadas de emergencia”, pueden definirse tipos de llamada diferenciados para llamadas de emergencia de CSFB y llamadas de emergencia de PS, tales como llamadas de emergencia de IMS. Por ejemplo, si va a realizarse una llamada de emergencia de PS, por ejemplo, llamada de emergencia de IMS, el tipo de llamada puede ser “sesión o llamada de emergencia de EPS”, “emergencia de PS”, “sesión o llamada de emergencia de IMS”, “servicios de emergencia” o algún otro tipo de llamada nombrado de manera apropiada. El tipo de llamada actual de “llamadas de emergencia” puede dejarse entonces para llamadas de emergencia de CSFB o puede renombrarse como “llamada de emergencia de CSFB” o algún otro tipo de llamada nombrado de manera apropiada pero distintiva. El tipo de llamada puede indicar los servicios pretendidos y por tanto la estación base puede proporcionar los recursos apropiados. El tipo de llamada puede expandirse para servicios de datos y puede indicar a una estación base que puede necesitarse una gran cantidad de ancho de banda para un servicio de datos de flujo continuo. El tipo de llamada considerado el nivel de prioridad de un usuario también puede usarse para determinar que se asigne un ancho de banda adecuado por la estación base.

En otras implementaciones del presente sistema, el APN de la petición de conectividad de PDN puede usarse para mapear a la causa de establecimiento de RRC. Si el APN de la petición de conectividad de PDN es un APN de emergencia, el NAS puede estar configurado para establecer la causa de establecimiento de RRC a “sesión o llamada de emergencia de EPS”, “PS llamada de emergencia”, “sesión o llamada de emergencia de IMS”, “servicios de emergencia”, “llamada de emergencia” o alguna otra causa nombrada de manera apropiada. En esta implementación, el UE sabe si un APN es un APN de emergencia a partir de datos de configuración que pueden almacenarse dentro del UE, recuperarse a partir de datos de SIM o proporcionarse de otro modo al UE por la operadora mediante cualquier método de provisión apropiado. Obsérvese que el uso de APN para mapear valores desde una capa hasta otra (por ejemplo, desde el NAS hasta el AS) puede incorporarse en, y complementar o sustituir a, otras metodologías de mapeo tal como se describió anteriormente.

La figura 7 ilustra un sistema de comunicaciones inalámbricas que incluye una realización del UA 10. El UA 10 puede hacerse funcionar para implementar aspectos de la divulgación, pero la divulgación no debe limitarse a estas implementaciones. Aunque se ilustra como teléfono móvil, el UA 10 puede adoptar diversas formas incluyendo un teléfono inalámbrico, un busca, un asistente personal digital (PDA), un ordenador transportable, un ordenador de tipo tableta, un ordenador portátil. Muchos dispositivos adecuados combinan algunas o todas de estas funciones. En algunas realizaciones de la divulgación, el UA 10 no es un dispositivo informático de propósito general tal como un ordenador transportable, portátil o de tipo tableta, sino que más bien es un dispositivo de comunicaciones de propósito especial dispositivo tal como un teléfono móvil, un teléfono inalámbrico, un busca, una PDA, o un dispositivo de telecomunicaciones instalado en un vehículo. El UA 10 también puede ser un dispositivo, incluir un dispositivo, o estar incluido en un dispositivo que tiene capacidades similares pero que no es transportable, tal como un ordenador de sobremesa, un decodificador, o un nodo de red. El UA 10 puede soportar actividades especializadas tales como funciones de juegos, control de inventario, control de trabajos y/o gestión de tareas, y así sucesivamente.

El UA 10 incluye un elemento 702 de visualización. El UA 10 también incluye una superficie sensible al tacto, un teclado u otras teclas de entrada a lo que se hace referencia generalmente como 704 para la entrada de un usuario. El teclado puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY, y tipos secuenciales, o un teclado portátil numérico tradicional con letras del alfabeto asociadas con un teclado portátil de teléfono. Las teclas de entrada pueden incluir una rueda de seguimiento, una tecla de salida o escape, una bola rastreadora, y otras teclas de navegación o funcionales, que pueden pulsarse hacia dentro para proporcionar una función de entrada adicional. El UA 10 puede presentar opciones para que seleccione el usuario, controles para que actúe el usuario, y/o cursores u otros indicadores para que dirija el usuario.

El UA 10 puede aceptar además la introducción de datos a partir del usuario, incluyendo números para marcar o diversos valores de parámetro para configurar el funcionamiento del UA 10. El UA 10 puede ejecutar además una o más aplicaciones de software o firmware en respuesta a comandos del usuario. Estas aplicaciones pueden configurar el UA 10 para realizar diversas funciones personalizadas en respuesta a interacción con el usuario. Adicionalmente, el UA 10 puede programarse y/o configurarse de manera inalámbrica, por ejemplo a partir de una estación base inalámbrica, un punto de acceso inalámbrico, o un UA 10 homólogo.

Entre las diversas aplicaciones ejecutables por el UA 10 se encuentran un navegador de web, que permite al elemento 702 de visualización mostrar una página web. La página web puede obtenerse mediante comunicaciones inalámbricas con un nodo de acceso a red inalámbrico, una torre celular, un UA 10 homólogo, o cualquier otro sistema 700 o red de comunicación inalámbrica. La red 700 está acoplada a una red 708 cableada, tal como Internet. A través del enlace inalámbrico y la red cableada, el UA 10 tiene acceso a información en diversos servidores, tales como un servidor 710. El servidor 710 puede proporcionar contenido que puede mostrarse en el elemento 702 de visualización. Alternativamente, el UA 10 puede acceder a la red 700 a través de un UA 10 homólogo que actúa como intermediario, en una conexión de tipo relé o tipo salto.

La figura 8 muestra un diagrama de bloques del UA 10. Aunque se representa una variedad de componentes conocidos de los UA 10, en una realización un subconjunto de los componentes indicados y/o componentes adicionales no indicados pueden incluirse en el UA 10. El UA 10 incluye un procesador 802 de señal digital (DSP) y una memoria 804. Tal como se muestra, el UA 10 puede incluir además una unidad 806 de extremo frontal y antena, un transceptor 808 de radiofrecuencia (RF), una unidad 810 de procesamiento de banda base analógica, un micrófono 812, un altavoz 814 de auricular, un puerto 816 de cascos, una interfaz 818 de entrada/salida, una tarjeta 820 de memoria extraíble, un puerto 822 de bus serie universal (USB), un subsistema 824 de comunicación inalámbrica de corto alcance, una alerta 826, un teclado 828 portátil, una pantalla de cristal líquido (LCD), que puede incluir una superficie 830 sensible al tacto, un controlador 832 de LCD, una cámara 835 de dispositivo de carga acoplada (CCD), un controlador 836 de cámara, y un sensor 838 de sistema de posicionamiento global (GPS). En una realización, el UA 10 puede incluir otra clase de elemento de visualización 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 818 de entrada/salida.

El DSP 802 o alguna otra forma de controlador o unidad de procesamiento central funciona para controlar los diversos componentes del UA 10 según software o firmware incorporado almacenado en la memoria 804 o almacenado en la memoria contenida dentro del propio DSP 802. Además del software o firmware incorporado, el DSP 802 puede ejecutar otras aplicaciones almacenadas en la memoria 804 o que se vuelven disponibles a través de medios de soporte de información tales como medios de almacenamiento de datos portátiles tales como la tarjeta 820 de memoria extraíble o a través de comunicaciones en red cableada o inalámbrica. El software de aplicación puede comprender un conjunto compilado de instrucciones legibles por máquina que configura el DSP 802 para proporcionar la funcionalidad deseada, o el software de aplicación puede ser instrucciones de software de alto nivel que van a procesarse por un intérprete o compilador para configurar indirectamente el DSP 802.

La unidad 806 de extremo frontal y antena puede proporcionarse para convertir entre señales inalámbricas y señales eléctricas, permitiendo que el UA 10 envíe y reciba información a partir de una red celular o alguna otra red de comunicaciones inalámbricas disponible o a partir de un UA 10 homólogo. En una realización, la unidad 806 de extremo frontal y antena puede incluir múltiples antenas para soportar conformación de haces y/u operaciones de múltiples entradas y múltiples salidas (MIMO). Tal como conocen los expertos en la técnica, las operaciones de MIMO pueden proporcionar diversidad espacial que puede usarse para superar condiciones de canal difíciles y/o aumentar el caudal de canal. La unidad 806 de extremo frontal y antena puede incluir componentes de sintonización de antena y/o coincidencia de impedancia, amplificadores de potencia de RF, y/o amplificadores de poco ruido.

El transceptor 808 de RF proporciona desplazamiento de frecuencia, convirtiendo señales de RF recibidas en banda base y convirtiendo señales transmitidas en banda base a RF. En algunas descripciones puede entenderse que un transceptor de radio o transceptor de RF incluye otra funcionalidad de procesamiento de señales tal como modulación/desmodulación, codificación/descodificación, entrelazado/desentrelazado, dispersión/recuperación de la dispersión, transformada rápida de Fourier inversa (IFFT)/transformada rápida de Fourier (FFT), adición/retirada de prefijo cíclico, y otras funciones de procesamiento de señales. Por fines de claridad, la descripción en este caso separa la descripción de este procesamiento de señales de la etapa de RF y/o radio y asigna conceptualmente ese procesamiento de señal a la unidad 810 de procesamiento de banda base analógica y/o el DSP 802 u otra unidad de procesamiento central. En algunas realizaciones, el transceptor 808 de RF, porciones del extremo 806 frontal y antena, y la unidad 810 de procesamiento de banda base analógica pueden combinarse en una o más unidades de procesamiento y/o circuitos integrados específicos de aplicación (ASIC).

La unidad 810 de procesamiento de banda base analógica puede proporcionar diversos procesamientos analógicos de entradas y salidas, por ejemplo procesamiento analógico de entradas a partir del micrófono 812 y los cascos 816 y salidas al auricular 814 y los cascos 816. Para eso, la unidad 810 de procesamiento de banda base analógica puede tener puertos para conectarse al micrófono 812 incorporado y al altavoz 814 de auricular para permitir usar el UA 10 como teléfono celular. La unidad 810 de procesamiento de banda base analógica puede incluir además un puerto para conectarse a unos cascos u otra configuración de micrófono y altavoz de manos libres. La unidad 810 de procesamiento de banda base analógica puede proporcionar conversión de digital a analógica en un sentido de señal y conversión de analógica a digital en el sentido de señal opuesto. En algunas realizaciones, al menos parte de la funcionalidad de la unidad 810 de procesamiento de banda base analógica puede proporcionarse por componentes de procesamiento digital, por ejemplo por el DSP 802 o por otras unidades de procesamiento central.

El DSP 802 puede realizar modulación/desmodulación, codificación/descodificación, entrelazado/desentrelazado, dispersión/recuperación de la dispersión, transformada rápida de Fourier inversa (IFFT)/transformada rápida de Fourier (FFT), adición/retirada de prefijo cíclico y otras funciones de procesamiento de señales asociadas con 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), para una función de transmisor el DSP 802 puede realizar modulación, codificación, entrelazado y dispersión, y para una función de receptor el DSP 802 puede realizar recuperación de la dispersión, desentrelazado, descodificación y desmodulación. En otra realización, por ejemplo en una aplicación de tecnología de acceso multiplex por división de frecuencia ortogonal (OFDMA), para la función de transmisor el DSP 802 puede realizar modulación, codificación, entrelazado, transformada rápida de Fourier inversa, y adición de prefijo cíclico, y para una función de receptor el DSP 802 puede realizar retirada de prefijo cíclico, transformada rápida de Fourier, desentrelazado, descodificación y desmodulación. En otras aplicaciones de tecnología inalámbrica, el DSP 802 puede realizar aún otras funciones de procesamiento de señales y combinaciones de funciones de procesamiento de señales.

El DSP 802 puede comunicarse con una red inalámbrica a través de la unidad 810 de procesamiento de banda base analógica. En algunas realizaciones, la comunicación puede proporcionar conectividad de Internet, permitiendo a un usuario obtener acceso a contenido en Internet y enviar y recibir correos electrónicos o mensajes de texto. La interfaz 818 de entrada/salida interconecta el DSP 802 y diversas memorias e interfaces. La memoria 804 y la tarjeta 820 de memoria extraíble pueden proporcionar software y datos para configurar el funcionamiento del DSP 802. Entre las interfaces pueden encontrarse la interfaz 822 de USB y el subsistema 824 de comunicación inalámbrica de corto alcance. La interfaz 822 de USB puede usarse para cargar el UA 10 y puede permitir que el UA 10 funcione como dispositivo periférico para intercambiar información con un ordenador personal u otro sistema informático. El subsistema 824 de comunicación inalámbrica de corto alcance puede incluir un puerto de infrarrojos, una interfaz de Bluetooth, una interfaz inalámbrica que cumple con IEEE 802.11, o cualquier otro subsistema de comunicación inalámbrica de corto alcance, que puede permitir que el UA 10 se comunique de manera inalámbrica con otros dispositivos móviles cercanos y/o estaciones base inalámbrica.

La interfaz 818 de entrada/salida puede conectar además el DSP 802 a la alerta 826 que, cuando se desencadena, hace que el UA 10 proporcione una notificación al usuario, por ejemplo, sonando, reproduciendo una melodía o vibrando. La alerta 826 puede servir como mecanismo para alertar al usuario de cualquiera de diversos acontecimientos tales como una llamada entrante, un nuevo mensaje de texto y un recordatorio de cita vibrando en silencio o reproduciendo una melodía específica previamente asignada para una persona que llama particular.

El teclado 828 portátil se acopla al DSP 802 a través de la interfaz 818 para proporcionar un mecanismo para que el usuario realice selecciones, introduzca información y proporcione de otro modo entradas al UA 10. El teclado 828 puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY y tipos secuenciales, o un teclado portátil numérico tradicional con letras del alfabeto asociadas con un teclado portátil de teléfono. Las teclas de entrada pueden incluir una rueda de seguimiento, una tecla de salida o escape, una bola rastreadora y otras teclas de navegación o funcionales, que pueden pulsarse hacia dentro para proporcionar una función de entrada adicional. Otro mecanismo de entrada puede ser la LCD 830, que puede incluir capacidad de pantalla táctil y también visualizar texto y/o gráficos al usuario. El controlador 832 de Lc D acopla el DSP 802 al LCD 830.

La cámara 834 de CCD, si está equipada, permite que el UA 10 tome fotografías digitales. El DSP 802 se comunica con la Cámara 834 de CCD a través del controlador 836 de cámara. En otra realización, puede emplearse una cámara que funciona según una tecnología distinta de cámaras de dispositivo de carga acoplada. El sensor 838 de GPS está acoplado al DSP 802 para descodificar señales de sistema de posicionamiento global, permitiendo así que el UA 10 determine su posición. También pueden incluirse varios otros periféricos para proporcionar funciones adicionales, por ejemplo, recepción de radio y televisión.

La figura 9 ilustra un entorno 902 de software que puede implementarse por el DSP 802. El DSP 802 ejecuta controladores 904 de sistema operativo que proporcionan una plataforma a partir de la cual funciona el resto del software. Los controladores 904 de sistema operativo proporcionan controladores para el hardware de UA con interfaces normalizadas que están accesibles para el software de aplicación. Los controladores 904 de sistema operativo incluyen servicios 906 de gestión de aplicaciones (AMS) que transfieren control entre aplicaciones que se ejecutan en el UA 10. En la figura 9 también se muestran una aplicación 908 de navegador de web, una aplicación 910 de reproductor de medios, y applets 912 de Java. La aplicación 908 de navegador de web configura el UA 10 para que funcione como un navegador de web, permitiendo a un usuario introducir información en formularios y seleccionar enlaces para recuperar y visualizar páginas web. La aplicación 910 de reproductor de medios configura el UA 10 para recuperar y reproducir medios de audio o audiovisuales. Los applets 912 de Java configuran el UA 10 para proporcionar juegos, utilidades y otra funcionalidad. Un componente 914 puede proporcionar funcionalidad descrita en el presente documento.

El UA 10, la estación 120 base y otros componentes descritos anteriormente pueden incluir un componente de procesamiento que puede ejecutar instrucciones relacionadas con las acciones descritas anteriormente. La figura 10 ilustra un ejemplo de un sistema 1000 que incluye un componente 1010 de procesamiento adecuado para implementar una o más realizaciones dadas a conocer en el presente documento. Además del procesador 1010 (que puede denominarse unidad de procesador central (CPU o DSP)), el sistema 1000 puede incluir dispositivos 1020 de conectividad de red, memoria 1030 de acceso aleatorio (RAM), memoria 1040 de sólo lectura (ROM), almacenamiento 1050 secundario, y dispositivos 1060 de entrada/salida (I/O). En algunos casos, algunos de estos componentes pueden no estar presentes o pueden combinarse en diversas combinaciones entre sí o con otros componentes no mostrados. Estos componentes pueden estar ubicados en una única entidad física o en más de una entidad física. Cualquier acción descrita en el presente documento como que la emprende el procesador 1010 puede emprenderse por el procesador 1010 solo o por el procesador 1010 junto con uno o más componentes mostrados o no mostrados en los dibujos.

El procesador 1010 ejecuta instrucciones, códigos, programas informáticos o secuencias de comandos a los que puede acceder a partir de los dispositivos 1020 de conectividad de red, RAM 1030, ROM 1040 o almacenamiento 1050 secundario (que puede incluir diversos sistemas basados en discos tales como disco duro, disco flexible o disco óptico). Aunque sólo se muestra un procesador 1010, pueden estar presentes múltiples procesadores. Por tanto, aunque pueden comentarse instrucciones como que se ejecutan por un procesador, las instrucciones pueden ejecutarse de manera simultánea, en serie o de otro modo 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 adoptar la forma de módems, bancos de módems, dispositivos de Ethernet, dispositivos de interfaz de bus serie universal (USB), interfaces en serie, dispositivos de anillo de testigo, dispositivos de interfaz de datos distribuidos por fibra (FDDI), dispositivos de red de área local inalámbrica (WLAN), dispositivos de transceptor de radio tales como dispositivos de acceso múltiple por división de código (CDMA), dispositivos de transceptor 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 permitir que el procesador 1010 se comunique con Internet o una o más redes de telecomunicaciones u otras redes a partir de las cuales el procesador 1010 puede recibir información o a las que el procesador 1010 puede emitir información.

Los dispositivos 1020 de conectividad de red también pueden incluir uno o más componentes 1025 de transceptor que pueden transmitir y/o 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. Alternativamente, los datos pueden propagarse en o sobre la superficie de conductores eléctricos, en cables coaxiales, en guías de ondas, en medios ópticos tales como fibra óptica, o en otros medios. El componente 1025 de tansceptor puede incluir unidades de recepción y transmisión independientes o un único tansceptor. La información transmitida o recibida por el tansceptor 1025 puede incluir datos que se han procesado por el procesador 1010 o instrucciones que van a ejecutarse por el procesador 1010. Tal información puede recibirse a partir de y emitirse hacia una red en forma, por ejemplo, de una señal de banda base de datos informáticos o señal implementada en una onda portadora. Los datos pueden ordenarse según diferentes secuencias según pueda ser deseable o bien para procesar o bien para generar los datos o transmitir o recibir los datos. La señal de banda base, la señal implementada en la onda portadora, u otros tipos de señales actualmente usados o desarrollados con posterioridad pueden denominarse medio de transmisión y pueden generarse según diversos métodos bien conocidos por un experto en la técnica.

La RAM 1030 puede usarse para almacenar datos volátiles y quizás para almacenar instrucciones que se ejecutan por el procesador 1010. La ROM 1040 es un dispositivo de memoria no volátil que normalmente tiene una capacidad de memoria menor que la capacidad de memoria del almacenamiento 1050 secundario. La ROM 1040 puede usarse para almacenar instrucciones y quizás datos que se leen durante la ejecución de las instrucciones. El acceso tanto a la RAM 1030 como a la ROM 1040 es normalmente más rápido que al almacenamiento 1050 secundario. El almacenamiento 1050 secundario está compuesto normalmente por una o más unidades de disco o unidades de cinta y puede usarse para almacenamiento no volátil de datos o como dispositivo de almacenamiento de datos de desbordamiento si la RAM 1030 no es lo suficientemente grande como para contener todos los datos de trabajo. El almacenamiento 1050 secundario puede usarse para almacenar programas que se cargan en la RAM 1030 cuando se seleccionan tales programas para su ejecución.

Los dispositivos 1060 de I/O pueden incluir pantallas de cristal líquido (LCD), dispositivos de visualización de pantalla táctil, teclados, teclados portátiles, interruptores, diales, ratones, bolas rastreadoras, dispositivos de reconocimiento de voz, lectores de tarjetas, lectores de cinta de papel, impresoras, monitores de vídeo, u otros dispositivos de entrada/salida bien conocidos. Además, puede considerarse que el tansceptor 1025 es un componente de los dispositivos 1060 de I/O en vez de, o además de, ser un componente de los dispositivos 1020 de conectividad de red. Algunos o la totalidad de los dispositivos 1060 de I/O pueden ser sustancialmente similares a diversos componentes representados en el dibujo anteriormente descrito del uA 10, tal como el elemento 702 de visualización y la entrada 704. Aunque se han proporcionado varias realizaciones en la presente divulgación, debe entenderse que los sistemas y métodos dados a conocer pueden implementarse de muchas otras formas específicas sin alejarse del espíritu o alcance de la presente divulgación. Los presentes ejemplos deben considerarse como ilustrativos y no restrictivos, y la intención es no limitarse a los detalles facilitados en el presente documento. Por ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otro sistema o pueden omitirse o no implementarse determinadas características. Además, técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas realizaciones como diferenciados o independientes pueden combinarse o integrarse con otros sistemas, módulos, técnicas o métodos sin alejarse del alcance de la presente divulgación. Otros elementos mostrados o comentados como acoplados o que se acoplan o que se comunican directamente entre sí pueden acoplarse o comunicarse de manera indirecta a través de alguna interfaz, dispositivo o componente intermedio, ya sea de manera eléctrica, mecánica o de otro modo. Otros ejemplos de cambios y alteraciones puede determinarlos un experto en la técnica y pueden realizarse sin alejarse del alcance divulgado en el presente documento.

Para informar al público sobre el alcance de esta invención, se realizan las siguientes reivindicaciones:

Claims (6)

REIVINDICACIONES

1. Método por un equipo de usuario, UE, incluyendo el método:

generar, por el UE, un mensaje de petición de unión de estrato sin acceso, NAS, en el UE, teniendo el mensaje de petición de unión de NAS un tipo de unión asociado con el establecimiento de una llamada de emergencia a través de una red de paquetes conmutados, PS;

determinar, por el UE, una causa de establecimiento de control de recursos de radio, RRC, basándose en el tipo de unión en el mensaje de petición de unión de NAS, en el que la causa de establecimiento de RRC indica que una capa de NAS está pidiendo el establecimiento de una conexión de RRC para la llamada de emergencia a través de la red de PS; y

transmitir, por el UE, un mensaje (20) de petición de conexión de RRC a una estación base de nodo B evolucionado, eNB, para establecer la conexión de RRC, incluyendo el mensaje (20) de petición de conexión de RRC la causa de establecimiento de RRC, en el que la causa de establecimiento de RRC indica al menos una de sesión o llamada de emergencia de EPS, emergencia de PS y sesión o llamada de emergencia de IMS.

2. Método según la reivindicación 1, en el que generar el mensaje de petición de unión de NAS comprende además generar un mensaje de petición de conectividad de red de datos en paquetes, PDN, comprendiendo el mensaje de petición de conectividad de PDN un tipo de petición de “emergencia”.

3. Método según la reivindicación 1, en el que el tipo de unión indica que el mensaje de petición de unión de NAS es para unión de emergencia de EPS.

4. Equipo de usuario, UE, que comprende:

un procesador configurado para generar un mensaje de petición de unión de estrato sin acceso, NAS, en el UE, teniendo el mensaje de petición de unión de NAS un tipo de unión asociado con establecer una llamada de emergencia a través de una red de paquetes conmutados, PS;

estando el procesador configurado además para determinar una causa de establecimiento de control de recursos de radio, RRC, basándose en el tipo de unión en el mensaje de petición de unión de NAS, en el que la causa de establecimiento de RRC indica que la capa de NAS está pidiendo el establecimiento de una conexión de RRC para la llamada de emergencia a través de la red de PS; y

estando el procesador configurado además para transmitir un mensaje (20) de petición de conexión de RRC a una estación base de nodo B evolucionado, eNB, para establecer la conexión de RRC, incluyendo el mensaje (20) de petición de conexión de RRC la causa de establecimiento de RRC, en el que la causa de establecimiento de RRC indica al menos una de sesión o llamada de emergencia de EPS, emergencia de PS y sesión o llamada de emergencia de IMS.

5. UE según la reivindicación 4, en el que estar el procesador configurado para generar el mensaje de petición de unión de NAS comprende además estar el procesador configurado para generar un mensaje de petición de conectividad de red de datos en paquetes, PDN, comprendiendo el mensaje de petición de conectividad de PDN un tipo de petición de “emergencia”.

6. UE según la reivindicación 4, en el que el tipo de unión indica que el mensaje de petición de unión de NAS es para unión de emergencia de EPS.