ES2805149T3 - Activante de transición de estado o modo sobre la base de la transmisión de un mensaje de indicación de señalización de liberación de conexión - Google Patents

Abstract

Un metodo para procesar un mensaje de indicacion de transicion que indica un paquete conmutado, PS, Final de sesion de datos por un equipo de usuario, UE, (802), estando el UE en comunicacion con una UTRAN, Red Universal de Acceso de Radio Terrestre, el metodo comprende: en la UE (802): si un recuento de cuantos mensajes de indicacion de transicion se ha activado en el estado actual de control de recursos de radio, RRC, es menor que un numero maximo: incrementar el recuento de cuantos mensajes de indicacion de transicion se han activado en el estado actual de RRC; establecer un elemento de informacion de causa, IE, en un mensaje de indicacion de transicion; enviando el mensaje de indicacion de transicion a la UTRAN; y restablecer el recuento tras la satisfaccion de al menos una condicion de restablecimiento, la al menos una condicion de restablecimiento comprende un cambio de estado de RRC debido a una solicitud de transaccion de datos por parte del UE o la UTRAN, en el que el UE esta configurado para no enviar mensajes de indicacion de transicion posteriores mientras el El UE permanece en el estado de RRC actual si el recuento es mayor que el numero maximo, en el que la causa IE en el mensaje de indicacion de transicion indica una solicitud para el final de una sesion de PS Data.

Description

DESCRIPCIÓN

Activante de transición de estado o modo sobre la base de la transmisión de un mensaje de indicación de señalización de liberación de conexión

Campo de la divulgación

La presente divulgación se refiere al control de recursos de radio entre el Equipo de usuario (UE) u otro dispositivo inalámbrico o móvil y una red inalámbrica, y en particular a la transición entre estados y modos de operación en una red inalámbrica como, por ejemplo, una red del Sistema Universal de Telecomunicaciones Móviles (UMTS).

Antecedentes

Un Sistema Universal de Telecomunicaciones Móviles (UMTS) es un sistema de banda ancha basado en paquetes para la transmisión de texto, voz digitalizada, video y multimedia. Está altamente suscrito al estándar para la tercera generación y generalmente se basa en el acceso múltiple por división codificada de banda ancha (W-CDMA).

En una red UMTS, una parte del control de recursos de radio (RRC) de la pila de protocolos es responsable de la asignación, configuración y liberación de recursos de radio entre el UE y la UTRAN. Este protocolo RRC se describe en detalle en las especificaciones 3GPP TS 25.331. Dos modos básicos en los que puede estar el UE se definen como “modo inactivo” y “modo conectado UTRA RRC” (o simplemente “modo conectado”, como se usa aquí). UTRA son las siglas de Acceso de Radio Terrestre o UMTS. En modo inactivo, se requiere que el UE u otro dispositivo móvil solicite una conexión RRC cada vez que desee enviar datos de usuario o en respuesta a una notificación cada vez que la UTRAN o el Nodo de Soporte de Servicio de Radio por Paquetes Generales (GPRS) Servidor (SGSN) lo notifica para recibir datos de una red de datos externa, tal como un servidor push. Los comportamientos del modo inactivo y conectado se describen en detalle en las especificaciones TS 25.304 y TS 25.331 del Proyecto de asociación de tercera generación (3GPP).

Cuando está en un modo conectado UTRA RRC, el dispositivo puede estar en uno de cuatro estados. Estos son:

CELL-DCH: se asigna un canal dedicado al UE en enlace ascendente y enlace descendente en este estado para intercambiar datos. El UE debe realizar las acciones descritas en 3GPP 25.331.

CELL_FACH: no se asigna ningún canal dedicado al equipo del usuario en este estado. En cambio, los canales comunes se utilizan para intercambiar una pequeña cantidad de datos en ráfagas. El UE debe realizar acciones como se describe en 3GPP 25.331, que incluye el proceso de selección de celdas como se define en 3GPP TS 25.304.

CELL_PCH: el UE utiliza la recepción discontinua (DRX) para monitorizar mensajes de difusión y notificaciones a través de un canal indicador de notificaciones (PICH). No es posible la actividad de enlace ascendente. El UE debe realizar acciones como se describe en 3GPP 25.331, que incluye el proceso de selección de celdas como se define en 3GPP TS 25.304. El UE debe realizar el procedimiento de CELL UPDATE después de la reselección de celda.

URA_PCH: el UE utiliza la Recepción Discontinua (DRX) para monitorizar mensajes y notificaciones de difusión a través de un Canal Indicador de Notificaciones (PICH). No es posible la actividad de enlace ascendente. El UE debe realizar las acciones descritas en 3GPP 25.331, incluido el proceso de selección de celdas como se define en 3GPP TS 25.304. Este estado es similar a CELL_PCH, excepto que el procedimiento de URA UPDATE solo se activa a través de la reselección del Área de Registro UTRAN (URA).

La transición de un modo inactivo al modo conectado y viceversa es controlada por la UTRAN. Cuando un UE en modo inactivo solicita una conexión RRC, la red decide si mover el UE al estado CELL_DCH o CELL_FACH. Cuando el UE está en un modo conectado RRC, nuevamente es la red la que decide cuándo liberar la conexión RRC. La red también puede mover el UE de un estado RRC a otro antes de liberar la conexión o, en algunos casos, en lugar de liberar la conexión. Las transiciones de estado generalmente se activan por la actividad de datos o la inactividad entre el UE y la red. Dado que la red puede no saber cuándo el UE ha completado el intercambio de datos para una aplicación determinada, ésta normalmente mantiene la conexión RRC durante algún tiempo en previsión de más datos hacia/desde el UE. Esto normalmente se hace para reducir la latencia de la configuración de llamadas y la posterior configuración de recursos de radio. El mensaje de liberación de la conexión RRC solo puede ser enviado por la UTRAN. Este mensaje libera la conexión del enlace de señal y todos los recursos de radio entre el UE y la UTRAN. En general, el término “portador de radio” se refiere a los recursos de radio asignados entre el UE y la UTRAN. Y, el término “portador de acceso de radio” generalmente se refiere a recursos de radio asignados entre el UE y, por ejemplo, un SGSN (Nodo de Servicio GPRS Servidor). La presente divulgación, a veces, se referirá al término recurso de radio, y dicho término se referirá, de acuerdo con corresponda, a uno o ambos, el portador de radio y/o el portador de acceso de radio.

El problema con lo anterior es que incluso si una aplicación en el UE ha completado su transacción de datos y no espera ningún intercambio de datos adicional, aún espera a que la red la mueva al estado correcto. La red puede no tener conocimiento del hecho de que la aplicación en el UE ha completado su intercambio de datos. Por ejemplo, una aplicación en el UE puede usar su propio protocolo basado en reconocimiento para intercambiar datos con su servidor de aplicaciones, al que se accede a través de la red central UMTS. Ejemplos son las aplicaciones que se ejecutan sobre el Protocolo de datagramas de usuario/Protocolo de Internet (UDP/IP) que implementan su propia entrega garantizada. En tal caso, el UE sabe si el servidor de aplicaciones ha enviado o recibido todos los paquetes de datos o no y está en una mejor posición para determinar si se va a realizar un intercambio de datos adicional y, por lo tanto, decidir cuándo finalizar la conexión RRC asociada con Dominio del servicio de paquetes (PS). Dado que la UTRAN controla cuándo el estado conectado de RRC se cambia a un estado diferente o en un modo inactivo y la UTRAN no conoce el estado de la entrega de datos entre el UE y el servidor externo, el UE puede verse obligado a permanecer en un estado o modo de velocidad de dato más alto de lo que se requiere, lo que posiblemente reduzca la vida útil de la batería de la estación móvil y posiblemente también desperdicie recursos de red debido al hecho de que los recursos de radio se mantienen ocupados innecesariamente y, por lo tanto, no están disponibles para otro usuario.

Una solución a lo anterior es hacer que el UE envíe una indicación de liberación de señalización a la UTRAN cuando el UE se da cuenta de que ha terminado con una transacción de datos. De conformidad con la sección 8.1.14.3 de la especificación 3GPP TS 25.331, la UTRAN puede liberar la conexión de señalización al recibir la indicación de liberación de señalización del UE, haciendo que el UE pase a un modo inactivo o algún otro estado RRC. Un problema con la solución anterior es que la UTRAN podría inundarse con mensajes de indicación de liberación de señalización del UE y otros UE

El documento US 2009/129339 A1 describe un método y un elemento de red para enviar una indicación de transición para hacer la transición de un equipo de usuario a un estado o modo diferente, el método recibe un mensaje de configuración de una red; y transmitiendo una indicación de transición desde el equipo de usuario, la indicación de transición incluye una causa si el mensaje de configuración contiene una indicación de transición de inhibición.

El documento US 2008/253312 A1 describe que, en un sistema de comunicación móvil WCDMA, cuando la cantidad de tráfico de paquetes transmitidos o recibidos desde un UE disminuye durante un tiempo predeterminado en un estado CELL_DCH en el que se ha establecido una conexión de datos de paquetes WCDMA, el UE pasa a un estado CELL_FACH por un controlador de red de radio (RNC). Posteriormente, se determina si no hay tráfico de paquetes transmitido o recibido durante un cierto tiempo en el estado CELL_FACH (que es un estado RRC en el que se ha conectado una conexión RRC y se ha liberado el canal físico dedicado). Cuando se determina que no hay tráfico de paquetes transmitido o recibido durante el tiempo determinado, el UE solicita una red para liberar la conexión RRC utilizando un mensaje de indicación de liberación de conexión de señalización (SCRI)

Resumen

Una invención se expone en las reivindicaciones.

De acuerdo con un ejemplo, se proporciona un método para procesar un mensaje de indicación por un equipo de usuario, UE, (802), comprendiendo el método: en el UE (802): si las capas superiores indican que no hay más datos conmutados de paquetes, PS, durante un período prolongado; y si un recuento de cuántos mensajes de indicación se han activado en al menos un estado de control de recursos de radio, RRC, es menor que un número máximo: incrementar el recuento de cuántos mensajes de indicación se han activado en al menos un estado de RRC; estableciendo una causa en un mensaje de indicación; y enviando el mensaje de indicación.

De acuerdo con otro ejemplo, se proporciona un equipo de usuario, UE, (802), configurado para procesar mensajes de indicación, el UE (802) configurado para: si las capas superiores indican que no hay más datos conmutados de paquetes, PS, por un período prolongado; y si un recuento de cuántos mensajes de indicación se han activado en al menos un estado de control de recursos de radio, RRC, establezca si es menor que un número máximo: incremente el recuento de cuántos mensajes de indicación se han activado en al menos un estado de RRC; establezca una causa en un mensaje de indicación; y envíe el mensaje de indicación.

Breve divulgación de los dibujos

La presente divulgación se entenderá mejor con referencia a los dibujos en los que:

La figura 1 es un diagrama de bloques que muestra estados y transiciones de RRC;

La Figura 2 es un esquema de una red UMTS que muestra diversas celdas UMTS y una URA;

La Figura 3 es un diagrama de bloques que muestra las diversas etapas en una configuración de conexión RRC; La figura 4A es un diagrama de bloques de una transición de ejemplo entre un estado de modo conectado CELL_DCH y un modo inactivo iniciado por la UTRAN de acuerdo con el método actual;

La Figura 4B es un diagrama de bloques que muestra una transición de ejemplo entre una transición de modo conectado de estado CELL_DCH a un modo inactivo utilizando indicaciones de liberación de señalización;

La Figura 5A es un diagrama de bloques de una transición de ejemplo entre un estado de inactividad CELL_DCH a un estado de inactividad CELL_FACH a un modo inactivo iniciado por la UTRAN;

La Figura 5B es un diagrama de bloques de una transición de ejemplo entre el estado de inactividad CELL_DCH y un modo inactivo que utiliza indicaciones de liberación de señalización;

La Figura 6 es un diagrama de bloques de una pila de protocolos UMTS;

La Figura 7 es un UE de ejemplo que puede usarse en asociación con el presente método;

La figura 8 es una red de ejemplo para su uso en asociación con el presente método y sistema;

La Figura 9 es un diagrama de flujo que muestra los pasos de agregar una causa para una indicación de liberación de conexión de señalización en el UE;

La Figura 10 es un diagrama de flujo que muestra los pasos tomados por un UE al recibir una indicación de liberación de conexión de señalización que tiene una causa;

La Figura 11 ilustra una representación gráfica de la asignación de canales físicos y lógicos de ejemploes durante la operación de ejemplo de la red mostrada en la Figura 8 en la que se proporcionan múltiples sesiones simultáneas de servicios de comunicación de datos por paquetes con el UE;

La Figura 12 ilustra un diagrama de bloques funcional de UE y elementos de red que proporcionan la función de liberación de recursos de radio para liberar recursos de radio de servicios de datos en paquetes individuales de acuerdo con una realización de la presente divulgación;

La Figura 13 ilustra un diagrama de secuencia de mensajes representativo de la señalización generada de acuerdo con la operación de una realización de la presente divulgación por la cual liberar la asignación de recursos de radio a un contexto PDP;

La Figura 14 ilustra un diagrama de secuencia de mensajes, similar al mostrado en la Figura 13, también representativo de la señalización generada de acuerdo con la operación de una realización de la presente divulgación por la cual liberar la asignación de recursos de radio;

La Figura 15 ilustra un diagrama de proceso representativo del proceso de una realización de la presente divulgación;

La Figura 16 ilustra un diagrama de flujo del método que ilustra el método de operación de una realización de la presente divulgación;

La Figura 17 ilustra un diagrama de flujo del método, que también ilustra el método de operación de una realización de la presente divulgación;

La figura 18 ilustra un diagrama de flujo del método de una realización en la que se toman decisiones de transición basadas en un perfil de recursos de radio en un elemento de red;

La Figura 19 ilustra un diagrama de bloques simplificado de un elemento de red capaz de usarse con el método de la Figura 18;

La Figura 20 ilustra un diagrama de flujo de datos para el envío de una indicación de transición o mensaje de solicitud; y

La figura 21 ilustra un diagrama de flujo de datos para establecer un valor de temporizador de inhibición en un UE. Descripción detallada

Los ejemplos y realizaciones proporcionados a continuación describen diversos métodos y sistemas para la transición de un equipo de usuario (UE) u otro dispositivo móvil entre diversos estados/modos de operación en una red inalámbrica tal como, por ejemplo, una red UMTS. Debe entenderse que también son posibles otras implementaciones en otros tipos de redes. Por ejemplo, las mismas enseñanzas también podrían aplicarse a una red de acceso múltiple por división de código (CDMA) (por ejemplo, 3GPP2 IS-2000), red de banda ancha-CDMA (W-CDMA) (por ejemplo, una red 3GPP UMTS/Acceso a paquetes de alta velocidad (HSPA); una red UTRAN Evolucionada (por ejemplo, LTE), o a modo de generalización, a cualquier red basada en tecnologías de acceso por radio que utilicen recursos de radio controlados por la red o que no mantengan ningún conocimiento del estado de los intercambios de datos a nivel de aplicación del dispositivo. Los ejemplos específicos y las implementaciones que se describen a continuación, aunque se presentan por simplicidad en relación con las redes UMTS, también son aplicables a estos otros entornos de red. Además, el elemento de red a veces se describe a continuación como la UTRAN. Sin embargo, si se utilizan otros tipos de red además de UMTS, el elemento de red se puede seleccionar adecuadamente en función del tipo de red. Además, el elemento de red puede ser la red central en un sistema UMTS o cualquier otro sistema de red apropiado, donde el elemento de red es la entidad que toma las decisiones de transición.

En un ejemplo particular, el presente sistema y método proporcionan la transición de un modo conectado RRC a un estado o modo más eficiente de batería o de recursos de radio mientras que proporciona capacidades de toma de decisiones en la red. En particular, el presente método y aparato proporcionan una transición basada en la recepción de una indicación de un UE que indica, implícita o explícitamente, que una transición del estado o modo RRC asociado con una conexión de señalización particular con recursos de radio a otro estado o modo debería ocurrir. Como se apreciará, dicha indicación o solicitud de transición podría utilizar una comunicación existente bajo los estándares actuales, por ejemplo, un mensaje de SIGNALING CONNECTION RELEASE INDICATION, o podría ser un nuevo mensaje dedicado para cambiar el estado del UE, como una “solicitud de estado RRC preferido” o un “mensaje de indicación de transferencia de datos completa”. Un mensaje de indicación de transferencia de datos completa es un mensaje que indica la finalización de la transferencia de datos de capa superior. Como se usa en este documento, una indicación podría referirse a cualquier escenario, y podría incorporar una solicitud.

La indicación de transición originada por el UE puede enviarse en algunas situaciones cuando una o más aplicaciones en el UE han completado un intercambio de datos y/o cuando se determina que no se espera que las aplicaciones del UE intercambien cualquier otro dato. El elemento de red puede usar la indicación y cualquier información provista en el mismo, así como otra información relacionada con el recurso de radio, como la calidad del servicio, el Nombre del punto de acceso (APN), el contexto del protocolo de datos en paquetes (PDP), la información histórica, entre otros, definidos aquí como un perfil de recursos de radio, para tomar una decisión específica de la red sobre si se debe hacer la transición del dispositivo móvil a otro modo o estado, o no hacer nada. La indicación de transición proporcionada por el UE o dispositivo móvil puede tomar diversas formas y puede enviarse en diferentes condiciones. En un primer ejemplo, la indicación de transición se puede enviar en función de un estado compuesto de todas las aplicaciones que residen en el UE. Específicamente, en un entorno UMTS, si una aplicación en el UE determina que se hace con el intercambio de datos, puede enviar una indicación de “hecho” a un componente de “administrador de conexión” del software del UE. El administrador de conexión puede, en una realización, realizar un seguimiento de todas las aplicaciones existentes (incluidas las que proporcionan un servicio a través de uno o múltiples protocolos), contextos de protocolo de datos de paquetes (PDP) asociados, recursos de radio de paquetes conmutados (PS) asociados y recursos de radio de circuitos conmutados (CS) asociados. Un contexto PDP es una asociación lógica entre un UE y una PDN (red pública de datos) que se ejecuta en una red central UMTS. Una o diversas aplicaciones (por ejemplo, una aplicación de correo electrónico y una aplicación de navegador) en el UE pueden estar asociadas con un contexto PDP. En algunos casos, una aplicación en el UE está asociada con un contexto PDP primario y múltiples aplicaciones pueden estar atadas con contextos PDP secundarios. El Administrador de conexión recibe indicaciones de “hecho” de diferentes aplicaciones en el UE que están activas simultáneamente. Por ejemplo, un usuario puede recibir un correo electrónico de un servidor push mientras navega por la web. Después de que la aplicación de correo electrónico haya enviado un acuse de recibo, puede indicar que ha completado su transacción de datos. La aplicación del navegador puede comportarse de manera diferente y, en su lugar, hacer una determinación predictiva (por ejemplo, utilizando un temporizador de inactividad) de cuándo enviar una indicación de “hecho” al administrador de conexión.

En base a un estado compuesto de tales indicaciones de aplicaciones activas, el software de UE puede decidir enviar una indicación de transición para indicar o solicitar a la red que se produzca una transición de un estado o modo a otro. Alternativamente, el software UE puede esperar antes de enviar la indicación de transición e introducir un retraso para garantizar que la aplicación haya terminado realmente con el intercambio de datos y no requiera mantenimiento en un estado o modo intensivo de recursos de batería o radio. El retraso puede ser dinámico de acuerdo con el historial de tráfico y/o los perfiles de la aplicación. Siempre que el administrador de conexión determine con cierta probabilidad que no se espera que ninguna aplicación intercambie datos, puede enviar una indicación de transición a la red para indicar que debería ocurrir una transición. En un ejemplo específico, la indicación de transición puede ser una indicación de liberación de conexión de señalización para el dominio apropiado (por ejemplo, dominio PS) para solicitar una transición a un modo inactivo. Alternativamente, la indicación de transición podría ser una solicitud de transición de estado dentro del modo conectado a la UTRAN.

Como se describe a continuación con más detalle, basándose en la recepción de una indicación de transición y, opcionalmente, un perfil de recursos de radio, un elemento de red como la UTRAN en un entorno UMTS puede decidir la transición del UE de un estado o modo a otro.

Otras indicaciones de transición son posibles. Por ejemplo, en lugar de confiar en un estado compuesto de todas las aplicaciones activas en el UE, el software del UE puede, en una realización alternativa, enviar una indicación de transición cada vez que una aplicación del UE ha completado un intercambio o datos y/o la aplicación no espera intercambiar más datos. En este caso, el elemento de red (por ejemplo, la UTRAN), basado en un perfil de recursos de radio opcional para el UE como se describe con referencia a la Figura 18 a continuación, puede utilizar la indicación para tomar una decisión de transición.

En otro ejemplo más, la indicación de transición podría simplemente indicar que una o más aplicaciones en el UE completaron un intercambio de datos y/o que no se espera que las aplicaciones del UE intercambien ningún otro dato. Sobre la base de esa indicación y un perfil de recursos de radio opcional para el UE, la red (por ejemplo, UTRAN), puede decidir si transita o no el UE a un estado, modo u operación más apropiados.

En otro ejemplo, la indicación de transición podría ser implícita en lugar de explícita. Por ejemplo, la indicación puede ser parte de un reporte de estado enviado periódicamente. Tal reporte de estado podría incluir información como si una memoria intermedia de enlace de radio tiene datos o podría incluir información sobre el tráfico saliente.

Cuando el UE envía una indicación de transición, puede incluir información adicional para ayudar al elemento de red a tomar la decisión de actuar sobre la indicación. Esta información adicional incluiría el motivo o la causa para que el UE envíe el mensaje. Esta causa o razón (explicada a continuación con mayor detalle) se basaría en que el UE determine la necesidad de un comportamiento similar a la “latencia rápida”. Dicha información adicional puede ser por medio de un nuevo elemento de información o un nuevo parámetro dentro del mensaje de indicación de transición.

En una realización adicional, podría existir un temporizador en el UE para garantizar que no se pueda enviar una indicación de transición hasta que haya transcurrido un tiempo (inhibir la duración) desde que se envió una indicación de transición previa. Este temporizador de inhibición restringe que el UE envíe el mensaje de indicación de transición con demasiada frecuencia y además permite que la red tome una decisión confiando en los mensajes que se activan solo con una frecuencia máxima dada. La duración del tiempo podría ser determinada por un temporizador cuyo valor esté preconfigurado o establecido por una red (indicada o señalada). Si el valor lo establece una red, podría transmitirse en mensajes nuevos o existentes, como Solicitud de conexión RRC, Liberación de conexión RRC, Configuración del portador de radio, Información de movilidad UTRAN o un Bloque de información del sistema, entre otros, y podría ser un elemento de información en esos mensajes. El valor podría transmitirse alternativamente en una porción de indicación de transición de inhibición de un mensaje de configuración de conexión RRC enviado por la UTRAN en respuesta a un mensaje de solicitud de conexión RRC recibido del UE, por ejemplo.

En una realización alternativa, el valor podría transmitirse a un UE en un mensaje cuyo tipo depende de un estado del UE. Por ejemplo, la red podría enviar el valor a todos los UE en una celda como una porción de un mensaje de información del sistema que el UE lee cuando está en un estado IDLE, URA_PCH, Cell_PCH o CELL_FACH.

En otra realización más, el valor podría enviarse como una porción de un mensaje de configuración de conexión RRC.

Los mensajes generados por la red también pueden transmitir un valor de temporizador de inhibición implícito a través de la no inclusión de un temporizador de inhibición en el mensaje o en un elemento de información dentro del mensaje. Por ejemplo, al determinar que se omite un temporizador de inhibición de un mensaje recibido, un UE aplica un valor predeterminado para su uso como un valor de temporizador de inhibición. Un uso de ejemplo de la omisión de inhibición del valor del temporizador es prohibir que el UE envíe un mensaje de indicación de transición. En tal situación, cuando un UE detecta la omisión de un valor de temporizador de inhibición esperado en un mensaje recibido, el UE puede, en función de la omisión, tener prohibido enviar cualquier mensaje de indicación de transición. Una manera de lograr esto es que el UE adopte un valor de temporizador de inhibición de infinito.

En otra realización, cuando el UE detecta la omisión de un valor de temporizador de inhibición (y, por ejemplo, adopta un valor de temporizador de inhibición de infinito), puede enviar indicaciones de transición, pero sin incluir ninguna información adicional, específicamente puede omitir la causa de activar el envío de la indicación de transición (se describe más detalladamente a continuación con mayor detalle). La omisión de un elemento de causa en un mensaje de indicación de transición puede garantizar la compatibilidad con versiones anteriores al permitir que los UE utilicen un mensaje de indicación de transición existente (por ejemplo, SIGNALING CONNECTION RELEASE INDICATION) para solicitar o indicar una transición.

La no inclusión de un temporizador de inhibición en el mensaje recibido se detalla adicionalmente con referencia a una realización de ejemplo en la que un bloque de información del sistema se transmite en una celda, o se envía a un UE y el bloque de información del sistema está configurado para transmitir un valor del temporizador de inhibición. En esta realización, si el UE recibe un bloque de información del sistema que no contiene un temporizador de inhibición, conocido como T3xx, en el mensaje o un elemento de información dentro del mensaje, en cuyo caso el UE puede determinar no permitir que el UE envíe el mensaje de indicación de transición, por ejemplo, configurando el temporizador de inhibición, T3xx, en infinito.

La no inclusión de un temporizador de inhibición se detalla adicionalmente con referencia a otra realización de ejemplo en la que se omite un temporizador de inhibición, T3xx, de un mensaje de información de movilidad UTRAN. En tal situación, un UE receptor puede continuar aplicando un valor de temporizador de inhibición almacenado previo. Alternativamente, el UE, al detectar la omisión del temporizador de inhibición T3xx, puede determinar no permitir que el UE envíe el mensaje de indicación de transición, por ejemplo, configurando el temporizador de inhibición, T3xx, en infinito.

En otra realización de ejemplo más, un UE, al detectar la omisión de un temporizador de inhibición en el mensaje recibido o en un elemento de información dentro del mensaje, establece el valor del temporizador de inhibición en otro valor predeterminado (por ejemplo, uno de 0 segundos, 5 segundos, 10 segundos, 15 segundos, 20 segundos, 30 segundos, 1 minuto, 1 minuto 30 segundos, 2 minutos). Alternativamente o, además, estos ejemplos pueden aplicarse a otros mensajes generados por la red.

En otras realizaciones, si el temporizador de inhibición (valor) no se envía o señaliza al UE en un mensaje o elemento de información, o el temporizador de inhibición no se lee de la información del sistema de difusión ni se recibe de otros mensajes UTRAN dedicados al hacer la transición desde de una celda a otra, el envío de una indicación de transición puede o no ocurrir.

Específicamente en una realización, el UE al detectar que no hay presente un temporizador de inhibición, no inicia una indicación de transición basada en una capa superior que determina que no tiene más datos PS para transmitir.

En una realización alternativa, el UE al detectar que no hay presente un temporizador de inhibición, puede iniciar una indicación de transición basada en la capa superior que determina que no tiene más datos PS para transmitir.

En otra realización más, si no se recibe ningún valor de temporizador de la UTRAN dentro de un mensaje, o dentro de un elemento de información en un mensaje (a través de difusión o de otro modo), en lugar de establecer el valor del temporizador en el UE en infinito, el UE puede establecer el temporizador de inhibición en cero o, alternativamente, eliminar cualquier configuración para el temporizador, y en su lugar se le permitirá enviar una indicación de transición. En este caso, el UE podría omitir o tener prohibido adjuntar una causa en el mensaje de indicación de transición. En una realización, se usa un mensaje SIGNALING CONNECTION RELEASE INDICATION como un ejemplo de una indicación de transición.

En una realización, la indicación de transición se transmite usando el procedimiento de indicación de liberación de conexión de señalización. El UE utiliza el procedimiento de indicación de liberación de la conexión de señalización para indicar a la UTRAN que se ha liberado una de sus conexiones de señalización.

Específicamente de acuerdo con TS 25.331 Sección 8.1.14.2, el UE, al recibir una solicitud para liberar la conexión de señalización desde las capas superiores para un dominio CN específico, verificará si existe la conexión de señalización en la variable “ESTABLISHED_SIGNALLING_CONNECTIONS para el dominio CN específico identificado en el elemento de información “identidad de dominio CN”. Si es así, el UE puede iniciar el procedimiento de indicación de liberación de conexión de señalización.

En el caso de que el valor del temporizador de inhibición no se señale o se transmita de otra forma al UE, no se especifica ninguna causa de indicación de liberación de conexión de señalización en el mensaje SIGNALING CONNECTION RELEASE INDICATION. Los expertos en la materia apreciarán que en esta realización alternativa la falta de un valor de temporizador no da como resultado que el valor del temporizador se establezca en infinito.

En el lado de la UTRAN, al recibir un mensaje de SIGNALING CONNECTION RELEASE INDICATION sin una causa, la UTRAN indica la liberación de la conexión de señalización para la identidad de dominio CN identificada a las capas superiores. Esto puede entonces iniciar la liberación de la conexión de control de recursos de radio establecida.

En otra realización alternativa, cuando la UTRAN señala o transmite un valor de temporizador al UE, por ejemplo, inhibe el temporizador T3xx en el elemento de información “temporizadores y constantes de UE en modo conectado” (o usando información del sistema, tal como SIB1, SIB3 o SIB4, o con un mensaje de información de movilidad UTRAN dedicado), el procedimiento de liberación se realiza de acuerdo con lo siguiente. Primero, el UE puede verificar si hay alguna conexión de dominio de circuitos conmutados indicada. Dichas conexiones pueden indicarse en la variable “ESTABLISHED_-SIGNALLING_CONNECTIONS”. Si no hay conexiones de dominio de circuitos conmutados, una segunda verificación para determinar si una capa superior indica que no habrá datos de dominio con conmutación de paquetes durante un período prolongado.

Si no hay conexiones de dominio de circuito conmutado y no se esperan datos de dominio de paquete conmutado durante un período prolongado, el UE puede verificar a continuación si el temporizador T3xx está funcionando.

Si el temporizador T3xx no está funcionando, el UE establece el elemento de información “Identidad de dominio CN” en el dominio de paquetes conmutados (PS). Además, el elemento de información “Causa de indicación de liberación de conexión de señalización” se establece en “Fin de sesión de datos de PS solicitada por el UE”. El mensaje SIGNALING CONNECTION RELEASE INDICATION se transmite en el DCCH utilizando AM RLC. Además, después de la transmisión, se inicia el temporizador T3xx.

El procedimiento anterior finaliza con la entrega exitosa del mensaje SIGNALING CONNECTION RELEASE INDICATION, de acuerdo con lo confirmado por el RLC en el procedimiento anterior. En esta realización, se inhibe que el UE envíe el mensaje SIGNALING CONNECTION RELEASE INDICATION con una causa de indicación de liberación de conexión de señalización establecida en “Finalización de sesión de datos de PS solicitada por el UE” mientras el temporizador T3xx está funcionando o hasta que el temporizador T3xx ha expirado.

Cuando el temporizador T3xx está funcionando, si el procedimiento de indicación de liberación de conexión de señalización se inicia debido a que no hay más datos de dominio conmutados por paquetes durante un período prolongado, el UE es responsable de implementar si se iniciará el procedimiento al expirar el temporizador T3xx. La decisión del UE puede basarse en determinar si tiene alguna indicación de liberación de conexión de señalización posterior o solicitar mensajes para enviar y, de ser así, la decisión del UE puede incluir volver a verificar algunas o todas las mismas comprobaciones para iniciar el procedimiento como se describe aquí.

En el lado de UTRAN, si el mensaje de SIGNALING CONNECTION RELEASE INDICATION recibido no incluye una causa de indicación de liberación de conexión de señalización, la UTRAN puede solicitar la liberación de la conexión de señalización desde una capa superior y la capa superior puede entonces iniciar la liberación de la conexión de señalización. Si, por otro lado, el mensaje SIGNALING CONNECTION RELEASE INDICATION recibido incluye una causa, la UTRAN puede liberar la conexión de señalización o iniciar una transición de estado a un estado más eficiente de la batería (por ejemplo, CELL_FACH, CELL_PCH, URA_PCH o IDLE_MODE).

La duración de inhibición anterior puede basarse en el estado al que el UE quisiera hacer la transición. Por ejemplo, la duración de la inhibición puede ser diferente, ya sea que el móvil indique su última preferencia para algunos Estados/modos de RRC frente a otros. Por ejemplo, podría ser diferente si el móvil indica una preferencia por el modo inactivo, frente a los estados Cell_FACH o frente a Cell_PCH/URA PCH. En el caso de que la red establezca la duración de inhibición, esto puede lograrse mediante la red que indica/envía dos (o más) conjuntos de valores al móvil, que se utilizarán de acuerdo con el escenario. Alternativamente, la indicación podría hacerse de tal manera que el valor de duración de inhibición apropiado solo se indique/señale al móvil: por ejemplo, si el UE desea hacer la transición a Cell_PCH, se podría establecer una duración de tiempo transcurrido diferente que si el UE quiere hacer la transición a inactivo.

La duración de inhibición de arriba puede ser diferente, dependiendo del estado/modo de RRC en el que se encuentre actualmente el móvil (por ejemplo, Cell_DCH/Cell_FACH versus Cell_PCH/URA_PCH, o en Cell_DCH versus Cell_FACH, o Cell_PCH/URA_PCH).

La duración de inhibición desde arriba puede ser diferente, dependiendo de si la red ya ha actuado sobre la información de estado de RRC de preferencia desde el móvil. Tal reconocimiento puede ocurrir en la red o en el lado móvil. En el primer caso, esto puede afectar los valores de inhibición indicados/señalados por la red al móvil. En este segundo caso, la red puede preconfigurar o indicar/señalar diferentes conjuntos de valores de duración de inhibición. Como un caso particular, la duración/funcionalidad de inhibición puede reducirse o cancelarse si la red ha actuado de acuerdo con la información de estado RRC de preferencia desde el móvil, p. ej. ha iniciado una transición de estado a un estado indicado por el UE.

La duración de inhibición anterior puede ser diferente, dependiendo, por ejemplo, de las preferencias, características, capacidades, cargas o capacidades de la red. Una red puede indicar una corta duración de inhibición si puede recibir mensajes frecuentes de indicación de transición. Una red puede indicar una larga duración de inhibición si no puede o no desea recibir mensajes frecuentes de indicación de transición. Una red puede indicar un período de tiempo específico durante el cual un UE no puede enviar mensajes de indicación de transición. El período de tiempo específico se puede indicar numéricamente (es decir, 0 segundos, 30 segundos, 1 minuto, 1 minuto 30 segundos, 2 minutos o infinito), por ejemplo. Un UE que recibe una duración de inhibición de 0 segundos puede enviar indicaciones de transición sin demora. Un UE que recibe una duración de inhibición de infinito no puede enviar indicaciones de transición.

Se puede usar/especificar un número máximo de mensajes por ventana de tiempo (por ejemplo, “no más de 15 mensajes cada 10 minutos”) en lugar de, o además de, la duración de la inhibición.

Las combinaciones de las duraciones de inhibición anteriores/mensajes máximos por ventana de tiempo son posibles.

A modo de ejemplo, la presente divulgación generalmente describe la recepción de un mensaje de RRC CONNECTION REQUEST por una UTRAN desde un UE. Al recibir un mensaje RRC CONNECTION REQUEST, la UTRAN debe, por ejemplo, aceptar la solicitud y enviar un mensaje de RRC CONNECTION SETUP al UE. El mensaje de RRC CONNECTION SETUP puede incluir una indicación de transición de inhibición, que se conoce como temporizador T3xx. Al recibir el mensaje de RRC CONNECTION SETUP por parte del UE, el UE debe, por ejemplo, almacenar el valor del Temporizador T3xx, reemplazando cualquier valor previamente almacenado o, si el Temporizador T3xx no está en el mensaje RRC CONNECTION SETUP, configurar el valor del temporizador hasta el infinito. En algunas realizaciones, el mensaje RRC CONNECTION SETUP debe incluir una indicación de transición de inhibición para garantizar que el UE sepa que la UTRAN admite la señalización de Indicación de transición de inhibición.

En una realización, se supone que durante la movilidad en un estado DCH, el UE mantendrá su valor almacenado actualmente para el temporizador de inhibición. En algunos casos donde el temporizador de inhibición se establece en infinito, esto puede significar que el UE debe esperar a que expiren los temporizadores de inactividad de datos de red y que la red mueva el UE a un estado RRC donde puede recibir o determinar un nuevo valor para el temporizador de inhibición. En otros casos en los que el temporizador de inhibición es un valor distinto del infinito antes de la transferencia, este otro valor se sigue utilizando hasta que el UE pueda actualizar el valor del temporizador al indicado en la nueva celda.

En algunos casos, el temporizador de inhibición y el mensaje de indicación de transición (por ejemplo, SIGNALING CONNECTION RELEASE INDICATION) pueden no implementarse en algunas redes o en algunas celdas dentro de una red. Para fines de movilidad, si no hay soporte disponible para la función de enviar una indicación de transición o un mensaje de solicitud (particularmente en el caso de que se use una causa), el UE debería por omisión no enviar el mensaje. Esto evita transmisiones innecesarias y el desperdicio asociado de recursos de red y recursos de batería.

Además, para fines de movilidad, los equipos de red de diferentes proveedores utilizados dentro de una red pueden conducir a celdas adyacentes que usan diferentes temporizadores de inhibición que deben actualizarse en el UE cuando el UE se mueve entre celdas.

En una realización alternativa, esto se maneja proporcionando que todos los mensajes de transferencia y control de portador relacionados incluyan un valor para un temporizador de inhibición T3xx. Dichos mensajes se denominan aquí como mensajes de movilidad. Esto permite que el UE reciba nuevos valores de temporizador de inhibición cuando se mueve entre celdas. También permite que el UE establezca un valor de temporizador predeterminado para el temporizador de inhibición si uno de estos mensajes de movilidad no contiene un valor de temporizador de inhibición. Como se apreciará, si no se recibe ningún valor de temporizador de inhibición en los mensajes de movilidad, esto indica que la celda no está habilitada para la latencia rápida.

Como otro ejemplo de un procedimiento de indicación de transición, el UE puede usar un procedimiento de Indicación Completa de Transferencia de Datos para indicar a la UTRAN que ha determinado que no necesita transferir más datos del dominio PS. En relación con el ejemplo descrito anteriormente, el UE no enviaría el mensaje de Indicación de transferencia de datos completa antes de que el temporizador T3xx haya expirado, si el temporizador T3xx estaba funcionando.

El procedimiento de Indicación Completa de Transferencia de Datos comienza con una indicación de que el RRC o las capas superiores no tendrán más datos del dominio PS durante un período prolongado. Si se indica una conexión de dominio CS en la variable ESTABLlSHED_SIGNALLING_CONNECTIONS o si el temporizador T3xx se establece en infinito, el procedimiento finaliza. De lo contrario, si el temporizador T3xx no está funcionando (es decir, ha expirado) o está configurado en 0 segundos, se envía un mensaje de DATA TRANSFER COMPLETE INDICATION a las capas inferiores para su transmisión utilizando AM RLC en DCCH, después de lo cual el temporizador T3xx se inicia o restablece cuando el mensaje ha sido entregado a las capas inferiores;

La UTRAN al recibir la DATA TRANSFER COMPLETE INDICATION puede decidir iniciar una transición de UE a un estado RRC más eficiente de batería o modo inactivo.

El UE no enviará el mensaje de Indicación Completa de Transferencia de Datos mientras el temporizador T3xx está funcionando.

La presente divulgación proporciona un método para controlar el uso de un mensaje de indicación de transición por un equipo de usuario, que comprende incluir una indicación de transición de inhibición en un mensaje de configuración; y enviar el mensaje de configuración con la indicación de transición de inhibición al equipo de usuario.

La presente divulgación proporciona además un elemento de red configurado para controlar el uso de un mensaje de indicación de transición por un equipo de usuario, el elemento de red configurado para: incluir una indicación de transición de inhibición en un mensaje de configuración; y enviar el mensaje de configuración con la indicación de transición de inhibición al equipo del usuario.

La presente divulgación proporciona además un método en un equipo de usuario (UE) para enviar una indicación de transición, comprendiendo el método establecer un temporizador de acuerdo con una indicación de transición de inhibición recibida de un elemento de red; detectar que se ha completado una transferencia de datos; y enviar la indicación de transición al detectar que el temporizador no está funcionando.

La presente divulgación proporciona además un equipo de usuario configurado para enviar una indicación de transición, el equipo de usuario configurado para: establecer un temporizador de acuerdo con una indicación de transición de inhibición recibida de un elemento de red; detectar que se ha completado una transferencia de datos; y enviar la indicación de transición al detectar que el temporizador no está funcionando.

Ahora se hace referencia a la Figura 1. La Figura 1 es un diagrama de bloques que muestra los diversos modos y estados para la porción de control de recursos de radio de una pila de protocolos en una red UMTS. En particular, el RRC puede estar en un modo 110 inactivo RRC o en un modo 120 conectado RRC.

Como apreciarán los expertos en la materia, una red UMTS consiste de dos segmentos de red basados en tierra. Estas son la Red Central (CN) y la Red de Acceso Radio Terrestre Universal (UTRAN) (como se ilustra en la Figura 8). La red núcleo es responsable de la conmutación y enrutamiento de llamadas de datos y conexiones de datos a las redes externas, mientras que la UTRAN maneja todas las funcionalidades relacionadas con la radio.

En el modo 110 inactivo, el UE debe solicitar una conexión RRC para configurar el recurso de radio cuando sea necesario intercambiar datos entre el UE y la red. Esto puede ser como resultado de una aplicación en el UE que requiere una conexión para enviar datos, o como resultado de que el UE supervise un canal de notificación para indicar si la UTRAN o SGSN ha llamado al UE para recibir datos de una red de datos externa como un servidor de push. Además, el UE también solicita una conexión RRC cada vez que necesita enviar mensajes de señalización de gestión de movilidad, como la actualización del área de ubicación.

Una vez que el UE ha enviado una solicitud a la UTRAN para establecer una conexión de radio, la UTRAN elige un estado para la conexión RRC. Específicamente, el modo 120 conectado a RRC incluye cuatro estados separados. Estos son Estado 122 CELL_DCH, estado 124 CELL_FACH, estado 126 CELL_PCH y Estado 128 URA_PCH.

Desde el modo 110 inactivo, el UE pasa de forma autónoma al estado 124 CELL_FACH, en el que realiza su transferencia de datos inicial, después de lo cual la red determina qué estado conectado RRC utilizará para la transferencia continua de datos. Esto puede incluir la red que mueve el UE al estado 122 del canal dedicado de celda (CELL_DCH) o manteniendo el UE en el estado 124 del canal de acceso directo a la celda (CELL_FACH).

En el estado 122 CELL_DCH, se asigna un canal dedicado al UE tanto para el enlace ascendente como para el enlace descendente para intercambiar datos. Este estado, dado que tiene un canal físico dedicado asignado al UE, generalmente requiere la mayor cantidad de energía de la batería del UE.

Como alternativa, la UTRAN puede mantener el UE en un estado 124 CELL_FACH. En un estado CELL_FACH no se asigna ningún canal dedicado al UE. En cambio, los canales comunes se utilizan para enviar señalización en una pequeña cantidad de datos en ráfaga. Sin embargo, el UE todavía tiene que monitorizar continuamente el FACH y, por lo tanto, consume más energía de la batería que en un estado CELL_PCH, un estado URA_PCH y en modo inactivo.

En el modo 120 conectado RRC, el estado RRC puede cambiarse a discreción de la UTRAN. Específicamente, si se detecta inactividad de datos durante un período de tiempo específico o se detecta un rendimiento de datos por debajo de cierto umbral, la UTRAN puede mover el estado RRC del estado 122 CELL_DCH al estado 124 CELL_FACH, el estado 126 CELL_PCH o el estado 128 URA_PCH. De manera similar, si se detecta que la carga útil está por encima de cierto umbral, entonces el estado RRC se puede mover del estado 124 CELL_FACH al estado 122 CELL_DCH.

Desde el estado 124 de CELL_FACH, si se detecta inactividad de datos durante un tiempo predeterminado en algunas redes, la UTRAN puede mover el estado RRC del estado 124 CELL_FACH a un estado de canal de notificación (PCH). Puede ser el estado 126 CELL_PCH o el estado 128 URA_PCH.

Desde el estado 126 CELL_PCH o el estado 128 URA_PCH, el UE debe pasar al estado 124 CELL_FACH para iniciar un procedimiento de actualización para solicitar un canal dedicado. Esta es la única transición de estado que controla el UE.

El modo 110 inactivo y el estado 126 CELL_PCH y el estado 128 URA_PCH usan un ciclo de recepción discontinuo (DRX) para monitorizar mensajes de difusión y notificaciones por un canal indicador de notificación (PICH). No es posible la actividad de enlace ascendente.

La diferencia entre el estado 126 CELL_PCH y el estado 128 URA_PCH es que el estado 128 URA_PCH solo activa un procedimiento de Actualización de URA si el área de registro de UTRAN (URA) actual del UE no está entre la lista de identidades de URA presentes en la celda actual. Específicamente, se hace referencia a la Figura 2. La Figura 2 muestra una ilustración de diversas celdas 210, 212 y 214 UMTS. Todas estas celdas requieren un procedimiento de actualización de celdas si se vuelven a seleccionar a un estado CELL_PCH. Sin embargo, en un área de registro de UTRAN, cada uno estará dentro de la misma área de registro de UTRAN (URA) 320 y, por lo tanto, no se activará un procedimiento de actualización de URA cuando se mueva entre 210, 212 y 214 cuando esté en modo URA_PCH.

Como se ve en la Figura 2, otras celdas 218 están fuera del URA 320, y pueden ser parte de un URA separado o ningún URA.

Como apreciarán los expertos en la materia, desde la perspectiva de la vida útil de la batería, el estado inactivo proporciona el uso de batería más bajo en comparación con los estados anteriores. Específicamente, debido a que se requiere que el UE monitorice el canal de notificación solo a intervalos, la radio no necesita estar continuamente encendida, sino que se activará periódicamente. La compensación para esto es la latencia para enviar datos. Sin embargo, si esta latencia no es demasiado grande, las ventajas de estar en modo inactivo y ahorrar batería superan las desventajas de la latencia de conexión.

Se hace referencia nuevamente a la Figura 1. Diversos proveedores de infraestructura UMTS se mueven entre los estados 122, 124, 126 y 128 en función de diversos criterios. Estos criterios podrían ser las preferencias del operador de red con respecto al ahorro de señalización o el ahorro de recursos de radio, entre otros. Infraestructuras de ejemploes se detallan a continuación.

En una primera infraestructura de ejemplo, el RRC se mueve entre un modo inactivo y un estado Cell_DCH directamente después de iniciar el acceso en un estado CELL_FACH. En el estado Cell_DCH, si se detectan dos segundos de inactividad, el estado RRC cambia al estado 124 CELL_FACH. Si, en el estado 124 CELL_FACH, se detectan diez segundos de inactividad, el estado RRC cambia al estado 126 CELL_PCH. Cuarenta y cinco minutos de la inactividad en el estado 126 CELL_PCH dará como resultado que el estado RRC regrese al modo 110 inactivo.

En una segunda infraestructura de ejemplo, la transición RRC puede ocurrir entre un modo 110 inactivo y el modo 120 conectado dependiendo de un umbral de carga útil. En la segunda infraestructura, si la carga útil está por debajo de cierto umbral, la UTRAN mueve el estado RRC al estado 124 CELL_FACH. Por el contrario, si la carga útil de datos está por encima de cierto umbral de carga útil, la UTRAN mueve el estado RRC a un estado 122 CELL_DCH. En la segunda infraestructura, si se detectan dos minutos de inactividad en el estado 122 CELL_DCH, la UTRAN mueve el estado RRC al estado 124 CELL_FACH. Después de cinco minutos de inactividad en el estado 124 CELL_FACH, la UTRAN mueve el estado RRC al estado 126 CELL_PCH. En el estado 126 CELL_PCH, se requieren dos horas de inactividad antes de volver al modo 110 inactivo.

En una tercera infraestructura de ejemplo, el movimiento entre el modo 110 inactivo y el modo 120 conectado siempre es al estado 122 CELL_DCH. Después de cinco segundos de inactividad en el estado 122 CELL_DCH, la UTRAN mueve el estado RRC al estado 124 CELL_FACH. Treinta segundos de inactividad en el estado 124 CELL_FACH da como resultado el movimiento de regreso al modo 110 inactivo.

En una cuarta infraestructura de ejemplo, el RRC pasa de un modo inactivo a un modo conectado directamente a un estado 122 CELL_DCH. En la cuarta infraestructura de ejemplo, el estado 122 CELL_DCH incluye dos configuraciones. El primero incluye una configuración que tiene una velocidad de datos alta y una segunda configuración incluye una velocidad de datos más baja, pero aún dentro del estado CELL_DCH. En la cuarta infraestructura de ejemplo, el RRC pasa del modo 110 inactivo directamente al subestado CELL_DCH de alta velocidad de datos. Después de 10 segundos de inactividad, el estado RRC pasa a un subestado CELL_DCH de baja velocidad de datos. Diecisiete segundos de inactividad del subestado de datos bajos del estado 122 CELL_DCH da como resultado que el estado RRC lo cambie al modo 110 inactivo.

Las cuatro infraestructuras de ejemploes anteriores muestran cómo diversos proveedores de infraestructura UMTS están implementando los estados. Como apreciarán los expertos en la materia, en cada caso, si el tiempo dedicado al intercambio de datos reales (tal como un correo electrónico) es significativamente corto en comparación con el tiempo requerido para permanecer en los estados CELL_DCH o CELL_FACH. Esto provoca una pérdida innecesaria de corriente, lo que hace que la experiencia del usuario en redes de nueva generación como UMTS sea peor que en redes de generaciones anteriores como GPRS.

Además, aunque el estado 126 CELL_PCH es más óptimo que el estado 124 CELL_FACH desde la perspectiva de la vida útil de la batería, el ciclo DRX en un estado 126 CELL_PCH se establece típicamente en un valor más bajo que el modo 110 inactivo. Como resultado, el UE se requiere para que se active más frecuentemente en el estado 126 CELL_PCH que en un modo 110 inactivo.

El estado 128 URA_PCH con un ciclo DRX similar al del estado 110 inactivo es probablemente el intercambio óptimo entre la duración de la batería y la latencia para la conexión. Sin embargo, el estado 128 URA_PCH no está implementado actualmente en la UTRAN. En algunos casos, por lo tanto, es deseable pasar rápidamente al modo inactivo lo más rápido posible después de que una aplicación haya finalizado el intercambio de datos, desde la perspectiva de la vida útil de la batería.

Ahora se hace referencia a la Figura 3. Cuando se pasa de un modo inactivo a un modo conectado, se deben hacer diversas conexiones de señalización y datos. En referencia a la Figura 3, el primer elemento a realizar es una configuración 310 de conexión RRC. Como se indicó anteriormente, esta configuración 310 de conexión RRC solo puede ser derribada por la UTRAN.

Una vez que se realiza la configuración 310 de conexión RRC, se inicia una configuración 312 de conexión de señalización.

Una vez que finaliza la configuración 312 de conexión de señalización, se inicia una configuración 314 de cifrado e integridad. Al finalizar esto, se realiza una configuración 316 de portador de radio. En este punto, los datos se pueden intercambiar entre el UE y UTRAN.

El derribo de una conexión se realiza de manera similar en el orden inverso, en general. La configuración 316 del portador de radio se desactiva y luego se desactiva la configuración 310 de conexión RRC. En este punto, el RRC se mueve al modo 110 inactivo como se ilustra en la Figura 1.

Aunque la especificación 3GPP actual no permite que el UE libere la conexión RRC o indique su preferencia por el estado RRC, el UE aún puede indicar la finalización de una conexión de señalización para un dominio de red central específico tal como el dominio de paquete conmutado (PS) utilizado por aplicaciones de paquetes conmutados. De acuerdo con la sección 8.1.14.1 de 3GPP TS 25.331, el UE utiliza el procedimiento de SIGNALING CONNECTION RELEASE INDICATION para indicar a la UTRAN que se ha liberado una de sus conexiones de señalización. Este procedimiento a su vez puede iniciar el procedimiento de liberación de la conexión RRC.

De este modo, manteniéndose dentro de las especificaciones 3GPP actuales, la liberación de la conexión de señalización puede iniciarse cuando se derriba la configuración 312 de conexión de señalización. Está dentro de la capacidad del UE derribar la configuración 312 de conexión de señalización, y esto a su vez de acuerdo con la especificación “puede” iniciar la liberación de la conexión RRC.

Como apreciarán los expertos en la materia, si la configuración 312 de conexión de señalización se derriba, la UTRAN también necesitará limpiar la configuración 314 de descifrado e integridad y la configuración 316 de portador de radio después de que la configuración 312 de conexión de señalización se haya derribado.

Si la configuración 312 de conexión de señalización se derriba, la red normalmente desactiva la configuración de conexión RRC para las infraestructuras del proveedor actual si no hay una conexión CS activa.

Utilizando esto para uno de los ejemplos de indicación de transición específicos mencionados anteriormente, si el UE determina que se hace con el intercambio de datos, por ejemplo, si un componente “administrador de conexión” del software del UE recibe una indicación de que el intercambio de datos se ha completado, entonces el administrador de conexión puede determinar si se debe eliminar o no la configuración 312 de señalización. Por ejemplo, una aplicación de correo electrónico en el dispositivo envía una indicación de que ha recibido un acuse de recibo del servidor de correo electrónico de inserción de que el correo electrónico fue de hecho recibido por el servidor push. El administrador de conexión puede, en una realización, realizar un seguimiento de todas las aplicaciones existentes, los contextos PDP asociados, los recursos de radio PS asociados y los portadores de radio de circuito conmutado (CS) asociados. En otras realizaciones, un elemento de red (por ejemplo, la UTRAN) puede realizar un seguimiento de aplicaciones existentes, contextos PDP asociados, QoS, recursos de radio PS asociados y portadores de radio CS asociados. Se puede introducir un retraso en el UE o en el elemento de red para garantizar que las aplicaciones hayan finalizado realmente con el intercambio de datos y ya no requieran una conexión RRC incluso después de que se hayan enviado las indicaciones “hechas”. Este retraso puede hacerse equivalente a un tiempo de inactividad asociado con la(s) aplicación(es) o el UE. Cada aplicación puede tener su propio tiempo de espera de inactividad y, por lo tanto, el retraso puede ser una combinación de todos los tiempos de espera de la aplicación. Por ejemplo, una aplicación de correo electrónico puede tener un tiempo de inactividad de cinco segundos, mientras que una aplicación de navegador activa puede tener un tiempo de espera de sesenta segundos. Un temporizador de inhibición de la duración puede retrasar aún más el envío de una indicación de transición. Basado en un estado compuesto de todas las indicaciones de las aplicaciones activas, así como un perfil de recursos de radio y/o inhibir la demora del temporizador de duración en algunas realizaciones, el software UE decide cuánto tiempo debe o tiene que esperar antes de enviar una indicación de transición (por ejemplo, una indicación de liberación de conexión de señalización o solicitud de cambio de estado) para la red central apropiada (por ejemplo, dominio PS). Si la demora se implementa en el elemento de red, el elemento determina si se debe hacer una transición del UE y cómo hacerlo, pero solo opera la transición después de que la demora ha seguido su curso.

El tiempo de espera de inactividad puede hacerse dinámico en función de un historial de patrón de tráfico y/o perfil de aplicación.

Si el elemento de red cambia el UE al modo 110 inactivo, lo que puede suceder en cualquier etapa del modo 120 conectado a RRC como se ilustra en la Figura 1, el elemento de red libera la conexión RRC y mueve el UE al modo 110 inactivo como se ilustra en la Figura 1. Esto también es aplicable cuando el UE está realizando cualquiera de los servicios de paquetes de datos durante una llamada de voz. En este caso, la red puede optar por liberar solo la conexión de señalización del dominio PS y mantener la conexión de señalización del dominio CS o, como alternativa, puede optar por no liberar nada y, en su lugar, mantener las conexiones de señalización a los dominios PS y CS.

En una realización adicional, se podría agregar una causa a la indicación de transición que indica a la UTRAN el motivo de la indicación. En una realización preferida, la causa podría ser una indicación de que un estado anormal causó la indicación o que la indicación fue iniciada por el UE como resultado de una transición solicitada. Otras transacciones normales (es decir, no anormales) también podrían provocar el envío de la indicación de transición.

En una realización preferida adicional, diversos tiempos de espera pueden hacer que se envíe una indicación de transición para una condición anormal. Los ejemplos de temporizadores a continuación no son exhaustivos, y son posibles otros temporizadores o condiciones anormales. Por ejemplo, 10.2.47 3GPP TS 24.008 especifica el temporizador T3310 como:

Temporizador T3310

Este temporizador se usa para indicar una falla de conexión. La falta de conexión podría ser el resultado de la red o podría ser un problema de radiofrecuencia (RF) como una colisión o una RF defectuosa.

El intento de adjunto podría ocurrir múltiples veces, y una falla del adjunto resulta de un número predeterminado de fallas o un rechazo explícito.

Un segundo temporizador de 10.2.47 de 3GPP es el temporizador T3330, que se especifica como:

Temporizador T3330

Este temporizador se usa para indicar una falla de actualización del área de enrutamiento. Al expirar el temporizador, una actualización del área de enrutamiento adicional se puede solicitar diversas veces y una falla de actualización del área de enrutamiento resulta de un número predeterminado

de fallas o un rechazo explícito.

Un tercer temporizador de 10.2.47 de 3GPP es el temporizador T3340, que se especifica como:

Temporizador T3340

Este temporizador se usa para indicar una falla de solicitud de servicio GMM. Al expirar el temporizador, otro servicio GMM podría iniciarse múltiples veces y una falla de solicitud de servicio de GMM resulta de un número predeterminado de fallas o de un rechazo explícito.

Por lo tanto, en lugar de una causa de indicación de transición limitada a una condición anormal y una liberación por parte del UE, la causa de la indicación de transición podría incluir además información sobre qué temporizador falló por una condición anormal en un ejemplo específico donde se usa una indicación de liberación de conexión de señalización como una indicación de transición, la indicación podría estructurarse como:

Indicación de liberación de conexión de señalización

Este mensaje es usado por el UE para indicar a la UTRAN una solicitud para liberar una conexión de señalización existente. La adición de la causa de indicación de liberación de conexión de señalización permite que la UTRAN u otro elemento de red reciba la causa de la indicación de liberación de conexión de señalización, si se debió a una condición anormal y cuál era la condición anormal. Basado en la recepción de la SIGNALING CONNECTION RELEASE INDICATION, a su vez, se permite iniciar un procedimiento de liberación de la conexión RRC en la UTRAN.

En una implementación de este ejemplo, el UE, al recibir una solicitud para liberar, o abortar, una conexión de señalización desde capas superiores para un dominio CN (red central) específico, inicia el procedimiento de indicación de liberación de conexión de señalización si una conexión de señalización se identifica en una variable por ejemplo, una variable ESTABLISHED_SIGNALING_CONNECTIONS, para el dominio CN específico identificado con el IE (elemento de información) “Identidad de dominio CN” existe. Si la variable no identifica ninguna conexión de señalización existente, cualquier establecimiento continuo de una conexión de señalización para ese dominio CN específico se aborta de otra manera. Al inicio de los procedimientos de indicación de liberación de la conexión de señalización en los estados Cell_PCH o URA_PCH, el UE realiza un procedimiento de actualización de la celda utilizando una causa de “transmisión de datos de enlace ascendente”. Cuando un procedimiento de actualización de celda se completa con éxito, el UE continúa con los procedimientos de indicación de liberación de conexión de señalización que siguen.

A saber, el UE establece el elemento de información (IE) “identidad de dominio CN” en el valor indicado por las capas lógicas superiores. El valor del IE indica el dominio CN cuya conexión de señalización asociada están marcando las capas superiores para liberar. Si la identidad del dominio CN se establece en el dominio PS, y si la capa superior indica la causa para iniciar esta solicitud, entonces se establece la IE “SIGNALING RELEASE INDICATION CAUSE de acuerdo con esto. El UE elimina además la conexión de señalización con la identidad indicada por las capas superiores de la variable “ESTABLISHED_SIGNALING_CONNECTIONS”. El UE transmite un mensaje de SIGNALING CONNECTION RELEASE INDICATION en, por ejemplo, el Canal de Control Dedicado (DCCH) usando el control de enlace de radio en modo reconocido (AM RLC). Una vez que el RLC confirma la entrega exitosa del mensaje de indicación de liberación, el procedimiento finaliza.

Una causa de indicación de liberación de conexión de señalización de IE también se usa de acuerdo con una realización de la presente divulgación. La causa de liberación está alineada, por ejemplo, con las definiciones de mensaje existentes. El mensaje de causa de liberación de capa superior está estructurado, por ejemplo, como:

En este ejemplo, los vencimientos de T3310, T330 y T3340 corresponden al vencimiento de temporizadores numerados correspondientemente, identificados previamente. Un valor de causa se puede configurar, en una implementación, como un “fin de sesión de datos PS solicitados por UE” en lugar de “transición inactiva solicitada por UE” para eliminar la indicación del UE de una preferencia por una transición inactiva y permitir que la UTRAN decida transición de estado, aunque el resultado esperado corresponde al identificado por el valor de la causa. La extensión a la indicación de liberación de la conexión de señalización es preferiblemente, pero no necesariamente, una extensión no crítica.

Ahora se hace referencia a la Figura 9. La Figura 9 es un diagrama de flujo de un UE de ejemplo que monitoriza sí o no enviar una indicación de liberación de conexión de señalización para diversos dominios (por ejemplo, PS o CS). El proceso comienza en el paso 910.

El UE pasa al paso 912 en el que verifica si existe una condición anormal. Tal condición anormal puede incluir, por ejemplo, el temporizador T3310, el temporizador T3320 o el temporizador T3340 que expira como se describe anteriormente. Si estos temporizadores expiran un cierto número predeterminado de veces o si se recibe un rechazo explícito basado en la expiración de cualquiera de estos temporizadores, el UE pasa al paso 914 en el que envía una indicación de liberación de conexión de señalización. El mensaje SIGNALING CONNECTION RELEASE INDICATION se adjunta con un campo de causa de indicación de liberación de señalización. El campo de causa de indicación de liberación de señalización incluye al menos que la indicación de liberación de señalización se basa en una condición o estado anormal y una realización incluye el temporizador específico que expiró para provocar la condición anormal.

Por el contrario, si en los pasos 912 el UE encuentra que no existe una condición anormal, el UE pasa al paso 920 en el que verifica si se esperan más datos en el UE. Esto puede, como se describió anteriormente, incluir cuándo se envía un correo electrónico y la confirmación del envío del correo electrónico se recibe de vuelta en el UE. Los expertos en la materia conocerán otros ejemplos de donde el UE determinará que no se esperan más datos.

Si en el paso 920 el UE determina que la transferencia de datos ha finalizado (o en el caso de un dominio de circuito conmutado que una llamada ha finalizado), el UE pasa al paso 922 en el que envía una indicación de liberación de conexión de señalización en el que el campo de causa de indicación de liberación de señalización se ha agregado e incluye el hecho de que el UE solicitó una transición inactiva o simplemente indica el final de la sesión de PS.

Desde el paso 920, si los datos no están terminados, el UE retrocede y continúa verificando si existe una condición anormal en el paso 912 y si los datos están terminados en el paso 920.

Una vez que se envía la indicación de liberación de la conexión de señalización en el paso 914 o el paso 922, el proceso continúa al paso 930 y finaliza.

El UE incluye elementos funcionales, implementables, por ejemplo, mediante aplicaciones o algoritmos llevados a cabo mediante la operación de un microprocesador de UE o mediante implementación de hardware, que forman un verificador y un emisor de indicación de transición. El verificador está configurado para verificar si se debe enviar una indicación de transición. Y, un remitente de indicación de transición está configurado para enviar una indicación de transición en respuesta a una indicación del verificador de que la indicación de transición debe enviarse. La indicación de transición puede incluir un campo de causa de indicación de transición.

En una implementación, la red se da cuenta, en cambio, implícitamente del tiempo de espera del temporizador, y el UE no necesita enviar un valor de causa que indique el tiempo de espera del temporizador. Es decir, el temporizador comienza a cronometrarse tras la autorización de la red. Los códigos de causa se definen y la red proporciona los códigos de causa al UE. Dichos códigos de causa son utilizados por el UE para iniciar el temporizador. La red está implícitamente enterada de la razón del tiempo de espera posterior del temporizador, ya que el código de causa enviado anteriormente por la red hace que el temporizador comience el tiempo. Como resultado, el UE no necesita enviar un valor de causa que indique el tiempo de espera del temporizador.

Como se sugiere en la Figura 9, así como en la divulgación anterior, una causa se puede incluir y enviar junto con una indicación de transición (por ejemplo, una SIGNALING CONNECTION RELEASE INDICATION) para indicar: 1.) una condición anormal, así como 2.) a condición normal (no es una condición anormal como, por ejemplo, una solicitud para el final de una sesión de datos PS y/o una transición a un modo inactivo)). En diversas implementaciones, por lo tanto, las operaciones en el UE proporcionan la adición de la causa a la indicación de transición para indicar una condición anormal o, alternativamente, para indicar una preferencia por una solicitud de una transición inactiva o un final de sesión de datos PS, es decir, funcionamiento normal. Tal operación, por supuesto, también incluye la operación de UE en la cual se agrega una causa a la indicación de transición solo cuando se debe hacer una indicación de una condición anormal. Y, por el contrario, dicha operación también incluye la operación de UE en la que se agrega una causa a una indicación de transición solo para indicar operaciones y transacciones normales, es decir, no anormales. Es decir, con respecto a la Figura 9, en dicha operación alternativa, si, en el paso 912, existe una condición anormal, la rama sí se lleva al paso 914 mientras que, si no existe una condición anormal, el UE continúa directamente al paso final 930. Por el contrario, en la otra operación alternativa, después del paso 912 inicial se toma una ruta directamente al paso 920 finalizado de datos. Si los datos están finalizados, la rama sí se lleva al paso 920 y, a partir de entonces, al paso 930. Si los datos no se finalizan en el paso 920, la rama no vuelve al mismo paso, es decir, el paso 920.

En referencia a la Figura 10, cuando un elemento de red recibe la indicación de transición en el paso 1010 (por ejemplo, una indicación de liberación de conexión de señalización como se muestra), el elemento de red examina el campo de causa de indicación de transición si está presente en el paso 1014 y en el paso 1016 verifica si la causa es una causa anormal o si se debe a que el UE solicita una transición inactiva y/o finaliza la sesión de datos PS. Si, en el paso 1016, la indicación de liberación de la conexión de señalización es de causa anormal, el nodo de la red continúa con el paso 1020 en el que puede notarse una alarma para fines de monitoreo de rendimiento y monitoreo de alarma. El indicador clave de rendimiento se puede actualizar adecuadamente.

Por el contrario, si en el paso 1016 la causa de la indicación de transición (por ejemplo, indicación de liberación de conexión de señalización) no es el resultado de una condición anormal, o en otras palabras, es el resultado de que el UE solicite un final de sesión de datos PS o una transición inactiva, el nodo de red continúa con el paso 1030 en el que no se genera ninguna alarma y la indicación se puede filtrar de las estadísticas de rendimiento, evitando así que las estadísticas de rendimiento se desvíen. Desde el paso 1020 o el paso 1030, el nodo de red pasa al paso 1040 en el que finaliza el proceso.

La recepción y el examen de la indicación de transición pueden dar como resultado que el elemento de red inicie la terminación de la conexión de datos con conmutación de paquetes o, alternativamente, una transición a otro estado más adecuado, por ejemplo, CELL_FACH, CELL_PCH, URA_PCH o IDLE_MODE.

Como se sugirió anteriormente, en algunas implementaciones, la ausencia de una causa en una indicación de transición también se puede usar para determinar si la indicación de transición es un resultado de una condición normal o anormal y si se debe generar una alarma. Por ejemplo, si se agrega una causa solo para denotar condiciones normales (es decir, no anormal, como, por ejemplo, una solicitud de finalización de la sesión de datos PS y/o transición al modo inactivo), y el elemento de red recibe una indicación de transición sin causa agregada, el elemento de red puede inferir de la ausencia de una causa que la indicación de transición es el resultado de una condición anormal y, opcionalmente, generar una alarma. Por el contrario, en otro ejemplo, si se agrega una causa solo para denotar condiciones anormales, y el elemento de red recibe una indicación de transición sin causa, el elemento de red puede inferir, en ausencia de una causa, que la indicación de transición es un resultado de una condición normal (por ejemplo, solicitud de finalización de sesión de datos de PS y/o transición al modo inactivo) y no generar una alarma.

Como apreciarán los expertos en la materia, el paso 1020 puede usarse para distinguir adicionalmente entre diversas condiciones de alarma. Por ejemplo, un tiempo de espera T3310 podría usarse para mantener un primer conjunto de estadísticas y un tiempo de espera T3330 podría usarse para mantener un segundo conjunto de estadísticas. El paso 1020 puede distinguir entre las causas de la condición anormal, lo que permite al operador de red rastrear el rendimiento de manera más eficiente.

La red incluye elementos funcionales, implementables, por ejemplo, mediante aplicaciones o algoritmos llevados a cabo mediante el funcionamiento de un procesador o mediante la implementación de hardware, que forman un examinador y un generador de alarma. El examinador está configurado para examinar un campo de causa de indicación de transición de la indicación de transición. El examinador verifica si el campo de causa de indicación de transición indica una condición anormal. El generador de alarma está configurado para generar una alarma seleccionable si el examen por parte del examinador determina que el campo de causa de indicación de liberación de conexión de señalización indica la condición anormal.

En una implementación, al recibir una indicación de liberación de conexión de señalización, la UTRAN reenvía la causa que se recibe y solicita, desde las capas superiores, la liberación de la conexión de señalización. Las capas superiores pueden iniciar la liberación de la conexión de señalización. La causa de indicación de liberación de señalización de IE indica que la capa superior del UE causa el activamiento del RRC del UE para enviar el mensaje. La causa es posiblemente el resultado de un procedimiento anormal de la capa superior. La diferenciación de la causa del mensaje está asegurada a través de la recepción exitosa del IE.

Un posible escenario incluye un escenario en el que, antes de la confirmación por parte del RLC de la entrega exitosa del mensaje SIGNALING CONNECTION RELEASE INDICATION, se produce el restablecimiento del lado transmisor de la entidad RLC en el portador de radio de señalización RB2. En el caso de tal ocurrencia, el UE retransmite el mensaje de SIGNALING CONNECTION RELEASE INDICATION, por ejemplo, en el DCCH de enlace ascendente usando AM RLC en el portador de radio de señalización RB2. En el evento de que se produzca una transferencia entre RAT (tecnología de acceso por radio) del procedimiento UTRAN antes de que el RLC confirme la entrega exitosa de la SIGNALING CONNECTION RELEASE INDICATION o mensaje de solicitud, el UE aborta la conexión de señalización cuando se encuentra en la nueva RAT.

En una realización adicional, en lugar de una “indicación de liberación de conexión de señalización” o solicitud, podría utilizarse una “indicación completa de transferencia de datos”. Una funcionalidad similar a la descrita en las Figuras 9 y 10 anteriores sería aplicable a esta indicación completa de transferencia de datos.

En una realización, el UE usa la indicación de transferencia completa de datos para informar a la UTRAN que el UE ha determinado que no hay transferencia de datos de dominio CS en curso, y ha completado su transferencia de datos PS. Tal mensaje se envía desde el UE a UTRAN en el DCCH usando AM RLC, por ejemplo. Un mensaje de ejemplo se muestra a continuación.

10.2.x DATA TRANSFER COMPLETE INDICATION

El UE usa este mensaje para informar a la UTRAN que el UE ha determinado que no hay transferencia de datos de dominio CS en curso, y ha completado su transferencia de datos PS.

RLC-SAP: AM

Canal lógico: DCCH

Dirección: UE ^ UTRAN

Indicación completa de transferencia de datos

Ahora se hace referencia a la Figura 20. La Figura 20 ilustra la realización dentro de la cual se envía una indicación o solicitud de transición (por ejemplo, una indicación de liberación de conexión de señalización o una indicación completa de transferencia de datos) desde el UE a la UTRAN. El proceso comienza en el paso 2010 y continúa al paso 2012 en el que se realiza una verificación en el UE para determinar si las condiciones en el UE son apropiadas para enviar un mensaje de indicación de transición. Dichas condiciones se describen en la presente divulgación, por ejemplo, con referencia a la Figura 11 a continuación, y podrían incluir una o más aplicaciones en el UE que determinan que han terminado con el intercambio de datos. Dichas condiciones también pueden incluir esperar durante un tiempo para que expire el temporizador T3xx si está funcionando.

En una realización adicional y alternativa, las condiciones pueden incluir impedir el envío de la indicación de transición si el temporizador T3xx se establece en infinito. Como se apreciará, T3xx podría incluir una serie de valores discretos, uno de los cuales representa un valor infinito.

Si, en el paso 2012, las condiciones no son apropiadas para enviar la indicación de transición o el mensaje de solicitud, el proceso se repite y continúa monitorizando hasta que las condiciones sean apropiadas para enviar la indicación de transición o el mensaje de solicitud.

Una vez que las condiciones son apropiadas, el proceso pasa al paso 2020 en el que se envía una indicación de transición a la UTRAN. Indicaciones de ejemploes se muestran en las tablas anteriores.

El proceso pasa luego al paso 2022 en el que se realiza una verificación para determinar si la indicación de transición fue exitosa. Como apreciarían los expertos en la materia, esto podría significar que la UTRAN ha recibido con éxito la indicación de transición y ha iniciado una transición de estado. En caso afirmativo, el proceso continúa con el paso 2030 y finaliza.

Por el contrario, si se determina en el paso 2022 que la indicación de transición no fue exitosa, el proceso continúa al paso 2024 y espera un período de tiempo. Tal espera podría implementarse utilizando una “duración de inhibición”, p. ej., T3xx, eso no permitiría que el móvil envíe otro mensaje de indicación de transición antes de que haya transcurrido una duración determinada. Alternativamente, el proceso podría limitar el número de mensajes de indicación de transición dentro de un período de tiempo determinado (por ejemplo, no más de 15 mensajes en 10 minutos). También es posible una combinación de la duración de la inhibición y limitar el número de mensajes dentro de un período de tiempo dado.

La duración podría estar predeterminada, como un valor definido en los estándares, podría ser establecido por un elemento de red, por ejemplo, como parte de una solicitud de conexión RRC, un mensaje de configuración de conexión RRC, una liberación de conexión RRC, una configuración del portador de radio, un mensaje de difusión de información del sistema, un mensaje de bloque de información del sistema, un mensaje de información de movilidad ACTIVE SET UPDATE, un CELL UPDATE CONFIRM, UTRAN, un comando de transferencia a UTRAN, un mensaje de reconfiguración de canal físico, un mensaje de reconfiguración de portador de radio, un Mensaje de liberación del portador de radio, un mensaje de reconfiguración del canal de transporte o cualquier mensaje de solicitud, configuración o reconfiguración. Además, la duración podría establecerse en función de un parámetro dentro del mensaje de indicación de transición. Por lo tanto, la duración podría ser mayor si el UE solicita una transición a Cell_PCH en lugar de inactivo.

La señalización o envío de la duración por un elemento de red podría tomar la forma de un elemento de información. Como se usa en este documento, la señalización o el envío podría incluir el envío directo de la información a un UE o la transmisión de la información. Del mismo modo, recibir en el UE podría incluir la recepción directa o la lectura de un canal de difusión. Un elemento de información de ejemplo incluye:

Indicación de transición de inhibición

Los valores de T3xx, en una realización, se definen como:

Definición de T3xx

En una realización, T3xx puede incluirse en el elemento de información UMTS existente “Temporizadores y constantes de UE en modo conectado”. Por lo tanto, esto puede transmitirse en una celda mediante la inclusión en el Tipo 1 de bloque de información del sistema. En una realización alternativa, el valor del temporizador también podría señalizarse utilizando otros mensajes de información del sistema, como SIB3 o SIB4, o alternativamente o adicionalmente podría señalizarse con un mensaje de información de movilidad UTRAN dedicado.

Como se indica en la Tabla anterior, el valor T3xx puede variar entre los valores establecidos e incluir un valor cero o un valor infinito. El valor cero se usa para indicar que no es necesario que ocurra ninguna inhibición. El valor infinito indica que nunca se debe enviar un mensaje de indicación de transición.

En una realización de movilidad, el UE restablece el valor T3xx cada vez que se hace una transición a una nueva red o celda. En este ejemplo, el valor se establece en infinito. Esto garantiza que, si un mensaje de transición o un mensaje de portador de radio no contiene un valor de inhibición del temporizador, por omisión, el UE no enviará el mensaje de indicación de transición. Así, por ejemplo, si la transición o los mensajes de portador de radio no contienen una “Indicación de transición de inhibición", el valor del temporizador se establece en infinito y, de lo contrario, el valor del temporizador recibido en la indicación reemplaza cualquier valor almacenado previamente.

En otra realización alternativa, los valores de T3xx se definen como sigue. La inclusión del temporizador T3xx es opcional, lo que garantiza que, si no se incluye, el UE no tendrá que soportar la configuración o el uso de este temporizador:

Una definición alternativa de T3xx

La recepción del temporizador de inhibición en una celda es, por lo tanto, una indicación al UE de que la celda reconoce el uso del mensaje de indicación de transición. El UE puede determinar, si es iniciado por el RRC o capas superiores debido a una determinación de no más datos del dominio PS durante un período prolongado, para señalar una indicación de transición utilizando un valor de causa. Cuando la red recibe un mensaje de indicación de transición (de cualquier forma, como se captura en este documento) con este valor de causa, puede determinar indicar al UE un cambio de transición de estado a un estado RRC más eficiente de la batería.

Mientras que en una realización alternativa cuando el temporizador de inhibición no se recibe o lee en una celda, el UE puede determinar que la causa para enviar el mensaje de indicación de transición no es compatible con la UTRAN. En este caso, el UE puede determinar no configurar un valor para T3xx y tampoco utilizar el T3xx en relación con el envío o la inhibición del envío del mensaje de indicación de transición.

Si el UE determina que se omite el temporizador de inhibición, entonces puede omitir incluir el valor de causa del mensaje de indicación de transición y simplemente enviar el mensaje de indicación de transición, basándose en la capa superior que determina que no tiene más datos PS para transmitir.

En una realización alternativa, el UE al determinar que se omite el temporizador de inhibición, el UE no iniciará una indicación de transición basada en la capa superior que determina que no tiene más datos PS para transmitir.

En una realización de este comportamiento descrito, el mensaje de indicación de transición es el mensaje SIGNALING CONNECTION RELEASE INDICATION.

En una primera realización alternativa, la recepción del temporizador de inhibición en una celda es, por lo tanto, una indicación de que la celda reconoce el uso de los mensajes de indicación de transición. Cuando se permite el envío de este mensaje cuando el T3xx no está configurado en valor infinito, entonces cuando la red recibe una indicación de transición, puede determinar indicarle al UE una transición de estado a un estado RRC más eficiente de la batería (por ejemplo, CELL_FACH, CELL_PCH, URA_PCH o IDLE_MODE).

En un ejemplo particular que utiliza el estándar 3GPP TSG-RAN2 25.331, se agrega lo siguiente a las secciones identificadas a continuación:

Indicación de transición de inhibición

Esto se agrega a las secciones:

10.2.48.8.6 Bloque de información del sistema tipo 3;

10.2.48.8.7 Bloque de información del sistema tipo 4;

10.2.1 Actualización de conjunto activo;

10.2.8 Confirmación de actualización de celda;

10.2.16a Transferencia al comando UTRAN;

10.2.22 Reconfiguración física de canales;

10.2.27 Reconfiguración del portador de radio;

10.2.30 Liberación del portador de radio;

10.2.33 Configuración del portador de radio;

10.2.40 Configuración de conexión RRC;

10.2.50 Reconfiguración del canal de transporte;

Los mensajes descritos anteriormente, además de los mensajes 10.2.48.8.6 Bloque de información del sistema tipo 3 y 10.2.48.8.7 Bloque de información del sistema tipo 4, son todos ejemplos de mensajes de información de movilidad.

Lo anterior cubre las conexiones y las operaciones del sistema, así como las transiciones entre diversas celdas, asegurando que un UE tenga un valor de inhibición del temporizador si esa celda soporta el mensaje de indicación de transición. Por ejemplo, el comando Transferencia a UTRAN asegura que una transición de otra Tecnología de acceso por radio, como una red de segunda generación a una red de tercera generación, proporcionará un valor de temporizador de inhibición si es compatible con la celda objetivo de la red de tercera generación.

En particular refiriéndose a la Figura 21, se ha producido una transición entre celdas como una precondición o durante otra operación del UE, como se muestra por el número de referencia 2110 como “Inicio”. El proceso continúa al bloque 2112 en el que se recibe un mensaje de configuración. Éste puede ser cualquiera de los mensajes identificados anteriormente e incluye tanto mensajes de movilidad como de no movilidad. El proceso luego pasa al bloque 2114 en el que se realiza una comprobación para ver si el mensaje de configuración incluye un valor de inhibición del temporizador.

Si no, el proceso pasa al bloque 2120 en el que el valor del temporizador de inhibición se establece en infinito. A la inversa, desde el bloque 2114 el proceso pasa al bloque 2130 si se determina que el mensaje de configuración incluye un valor de temporizador de inhibición. En el bloque 2130, el valor del temporizador de inhibición se almacena en el UE, reemplazando el valor anterior para el temporizador de inhibición. El proceso luego procede al bloque 2140 y termina. Como se apreciará, en una realización, el proceso de la Figura 21 se invoca cada vez que se produce un cambio en la red o la celda, o cada vez que se necesita enviar una indicación de transición.

Una vez que el proceso ha esperado un tiempo predeterminado en el paso 2024, el proceso vuelve al paso 2012 para determinar si todavía existen las condiciones para enviar una indicación de transición. En caso afirmativo, el proceso vuelve al paso 2020 y 2022.

Basado en lo anterior, el valor del temporizador de inhibición puede proporcionarse en diversas realizaciones. En una primera realización, se puede proporcionar solo usando un mensaje de configuración de conexión RRC para transmitir un valor de inhibición del temporizador.

En una segunda realización, la información del sistema se puede usar para transmitir el valor de inhibición del temporizador.

En una tercera realización, los mensajes de configuración del sistema de conexión RRC y de información del sistema pueden utilizarse para enviar el valor de inhibición del temporizador para garantizar que los UE en modo inactivo y los estados Cell_PCH/Cell_FACH y DCH tengan la información más reciente.

En una cuarta realización, el valor del temporizador de inhibición puede enviarse como en la tercera realización, con la adición de enviar un valor del temporizador de inhibición en una configuración de portador de radio de modo que cuando se establece un contexto PDP que no tiene portador de radio, cuando un portador de radio se establece posteriormente para enviar un mensaje de datos; el valor del temporizador de inhibición puede transmitirse en ese momento.

En una quinta realización, la cuarta realización se puede combinar con todos los mensajes relacionados con la movilidad como se describió anteriormente e incluye la reconfiguración, la confirmación de actualización de celda y un comando de Transferencia a UTRAN para transmitir el valor del temporizador de inhibición.

En las realizaciones primera a cuarta, durante la movilidad, el UE mantiene su valor de temporizador de inhibición almacenado actualmente. Como se indicó anteriormente, en algunos casos donde el temporizador de inhibición se establece en infinito, esto puede significar que el UE debe esperar a que expiren los temporizadores de red y que la red mueva el UE a un estado RRC donde pueda recibir o determinar un nuevo valor para el temporizador de inhibición. En otros casos en los que el temporizador de inhibición es un valor distinto del infinito antes de la transferencia, este otro valor se sigue utilizando hasta que el UE pueda actualizar el valor del temporizador al indicado en la nueva celda.

Para la quinta realización, el proceso de la Figura 21 se utiliza para garantizar que el valor del temporizador de inhibición se actualice durante la movilidad, y que los mensajes de indicación de transición no se envíen innecesariamente desde un UE.

Puede ocurrir una excepción en el restablecimiento de RLC o cambio interRAT. Si se produce un restablecimiento del lado de transmisión de la entidad RLC antes de que el RLC haya confirmado la entrega exitosa del mensaje de indicación de transición, en una realización, el UE retransmite el mensaje de indicación de transición en el DCCH de enlace ascendente usando AM RLC.

En una realización, si se produce una transferencia entre RAT desde el procedimiento UTRAN antes de que el RLC haya confirmado la entrega exitosa del mensaje de indicación de transición, el UE aborta la conexión de señalización mientras está en la nueva RAT.

En el lado de la red, el proceso se maneja de manera similar a la descrita con referencia a la Figura 18 a continuación.

Refiriéndose nuevamente a la Figura 1, en algunos casos puede ser más deseable estar en el modo 120 conectado en un estado como el estado 128 URA_PCH que en el modo 110 inactivo. Por ejemplo, si la latencia para la conexión al estado 122 CELL_DCH o se requiere que el estado 124 CELL_FACH en el modo 120 conectado sea más bajo, es preferible estar en un estado conectado del modo 120 PCH. Hay diversas maneras de lograr esto, por ejemplo, modificando los estándares para permitir que el UE solicite a la UTRAN que lo mueva a un estado específico (por ejemplo, en este caso, el estado 128 URA_PCH).

Alternativamente, el administrador de conexión puede tener en cuenta otros factores, como en qué estado se encuentra actualmente la conexión RRC. Si, por ejemplo, la conexión RRC está en el estado URA_PCH, puede decidir que no es necesario pasar al modo 110 inactivo y, por lo tanto, no se inicia ningún procedimiento de liberación de conexión de señalización.

En una alternativa adicional, el elemento de red (por ejemplo, la UTRAN) puede tener en cuenta otros factores tales como en qué estado se encuentra actualmente la conexión RRC y si, por ejemplo, la conexión RRC está en el estado URA_PCH, puede decidir que no es necesario pasar al modo 110 inactivo y, en cambio, simplemente hacer la transición del UE a un estado más adecuado en lugar de liberar la conexión.

Se hace referencia a la Figura 4. La Figura 4A muestra una implementación UMTS actual de acuerdo con el ejemplo de infraestructura “cuatro” anterior. Como se ilustra en la Figura 4, el tiempo es a través de los ejes horizontales.

El UE comienza en el estado 110 inactivo RRC y, en función de los datos generados localmente o móviles que necesitan ser transmitidos o una notificación recibida de la UTRAN, comienza a establecer una conexión RRC.

Como se ilustra en la Figura 4A, la configuración 310 de conexión RRC ocurre primero, y el estado RRC está en un estado 410 de conexión durante este tiempo.

A continuación, se produce la configuración de conexiones de señalización 312, la configuración 314 de cifrado e integridad, y la configuración 316 de portador de radio. El estado RRC es el estado 122 CELL_DCH durante estos procedimientos. Como se ilustra en la Figura 4A, el tiempo transcurrido para pasar de RRC inactivo al tiempo que el portador de radio está configurado es de aproximadamente dos segundos en este ejemplo.

Los datos se intercambian a continuación. En el ejemplo de la Figura 4A, esto se logra en aproximadamente dos a cuatro segundos y se ilustra en el paso 420.

Después de intercambiar datos en el paso 420, no se intercambian datos excepto por la PDU de señalización RLC intermitente según sea necesario y, por lo tanto, la red reconfigura el recurso de radio para pasar a una configuración DCH de velocidad de datos más baja después de aproximadamente diez segundos. Esto se ilustra en los pasos 422 y 424.

En la configuración DCH de velocidad de datos más baja, no se recibe nada durante diecisiete segundos, momento en el cual la red libera la conexión RRC en el paso 428.

Una vez que se inicia la liberación de la conexión RRC en el paso 428, el estado RRC pasa a un estado 430 de desconexión durante aproximadamente cuarenta milisegundos, después de lo cual el UE está en un estado 110 inactivo RRC.

También ilustrado en la Figura 4A, el consumo de corriente de UE se ilustra para el período en el que el RRC está en el estado 122 de CELL_DCH. Como se ve, el consumo de corriente es de aproximadamente 200 a 300 miliamperios durante toda la duración del estado de CELL_DCH. Durante la desconexión y la inactividad, se utilizan aproximadamente 3 miliamperios, suponiendo un ciclo DRX de 1.28 segundos. Sin embargo, los 35 segundos de consumo de corriente de 200 a 300 miliamperios están agotando la batería.

Ahora se hace referencia a la Figura 4B. La Figura 4B utiliza la misma infraestructura de ejemplo “cuatro” de arriba, solo que ahora implementa la liberación de la conexión de señalización

Como se ilustra en la Figura 4B, ocurren los mismos pasos 310, 312, 314 y 316 de configuración y esto lleva la misma cantidad de tiempo cuando se mueve entre el estado 110 inactivo RRC y el estado 122 CELL_DCH RRC.

Además, el intercambio de PDU de datos de RRC para el correo electrónico de ejemplo en el paso 420 de la Figura 4A también se realiza en la Figura 4B y esto lleva aproximadamente de dos a cuatro segundos.

El UE en el ejemplo de la Figura 4B tiene un tiempo de espera de inactividad específico de la aplicación, que en el ejemplo de la Figura 4B es de dos segundos y se ilustra en el paso 440. Después de que el administrador de conexión haya determinado que hay inactividad para la cantidad específica de tiempo, el UE envía una indicación de transición, que en este caso es una indicación de liberación de conexión de señalización en el paso 442 y en el paso 448, la red continúa, en función de la recepción de la indicación y en un perfil de recursos de radio para el UE, para liberar la conexión RRC.

Como se ilustra en la Figura 4B, el consumo de corriente durante el paso 122 de CELL_DCH todavía es de aproximadamente 200 a 300 miliamperios. Sin embargo, el tiempo de conexión es de solo unos ocho segundos. Como apreciarán los expertos en la técnica, la cantidad de tiempo considerablemente más corta que el móvil permanece en el estado 122 de DCH de la celda da como resultado ahorros significativos de batería para el dispositivo UE.

Ahora se hace referencia a la Figura 5. La Figura 5 muestra un segundo ejemplo usando la infraestructura indicada anteriormente como Infraestructura “tres”. Al igual que con las Figuras 4A y 4B, se produce una configuración de conexión que demora aproximadamente dos segundos. Esto requiere la configuración 310 de conexión RRC, la configuración 312 de conexión de señalización, la configuración 314 de cifrado e integridad y la configuración 316 de portador de radio.

Durante esta configuración, el UE se mueve desde el modo 110 inactivo RRC a un estado 122 CELL_DCH con un estado RRC que conecta el paso 410 en el medio.

Al igual que con la Figura 4A, en la Figura 5A el intercambio de PDU de datos RLC ocurre en el paso 420, y en el ejemplo de la Figura 5A toma de dos a cuatro segundos.

De acuerdo con la infraestructura tres, el intercambio de PDU de señalización RLC no recibe datos y, por lo tanto, está inactivo durante un período de cinco segundos en el paso 422, excepto la PDU de señalización RLC intermitente según sea necesario, momento en el cual el recurso de radio reconfigura el UE para moverse hacia un estado 124 CELL_FACH del estado 122 CELL_DCH. Esto se hace en el paso 450.

En el estado 124 CELL_FACH, el intercambio de PDU de señalización de RLC encuentra que no hay datos, excepto la PDU de señalización de RLC intermitente según sea necesario durante un período de tiempo predeterminado, en este caso treinta segundos, momento en el cual se libera una conexión RRC por red se realiza en el paso 428.

Como se ve en la Figura 5A, esto mueve el estado RRC al modo 110 inactivo.

Como se ve adicionalmente en la Figura 5A, el consumo de corriente durante el modo DCH está entre 200 y 300 miliamperios. Al pasar al estado 124 CELL_FACH, el consumo de corriente disminuye a aproximadamente 120 a 180 miliamperios. Después de que se libera el conector RRC y el RRC pasa al modo 110 inactivo, el consumo de energía es de aproximadamente 3 miliamperios.

El estado del modo conectado UTRA RRC que es el estado 122 CELL_DCH o el estado 124 CELL_FACH dura aproximadamente cuarenta segundos en el ejemplo de la Figura 5A.

Ahora se hace referencia a la Figura 5B. La Figura 5B ilustra la misma infraestructura “tres” que la Figura 5A con el mismo tiempo de conexión de aproximadamente dos segundos para obtener la configuración 310 de conexión RRC, la configuración 312 de conexión de señalización, la configuración 314 de integridad de cifrado y la configuración 316 de portador de radio. Además, el intercambio 420 de PDU de datos RLC toma aproximadamente dos a cuatro segundos.

Al igual que con la Figura 4B, una aplicación de UE detecta un tiempo de espera de inactividad específico en el paso 440, momento en el cual el UE envía la indicación de transición (por ejemplo, indicación 442 de liberación de conexión de señalización) y, como consecuencia, la red libera la conexión RRC en el paso 448.

Como se puede ver más adelante en la Figura 5B, el RRC comienza en un modo 110 inactivo, se mueve a un estado 122 CELL_DCH sin pasar al estado CELL_FACH.

Como se verá más adelante en la Figura 5B, el consumo de corriente es de aproximadamente 200 a 300 miliamperios en el tiempo en que la etapa RRC está en el estado 122 CELL_DCH que, de acuerdo con el ejemplo de la Figura 5, es de aproximadamente ocho segundos.

Por lo tanto, una comparación entre las Figuras 4A y 4B, y las Figuras 5A y 5B muestra que se elimina una cantidad significativa de consumo de corriente, extendiendo así la vida útil de la batería del UE. Como apreciarán los expertos en la materia, lo anterior se puede usar adicionalmente en el contexto de las especificaciones 3GPP actuales.

Ahora se hace referencia a la Figura 6. La Figura 6 ilustra una pila de protocolos para una red UMTS.

Como se ve en la Figura 6, el UMTS incluye un plano 610 de control CS, un plano 611 de control PS y un plano 630 de usuario PS

Dentro de estos tres planos, existe una porción 614 de estrato sin acceso (NAS) y una porción 616 de estrato de acceso.

La porción 614 NAS en el plano 610 de control CS incluye un control de llamada (CC) 618, servicios suplementarios (SS) 620 y servicio de mensajes cortos (SMS) 622.

La porción 614 NAS en el plano 611 de control PS incluye tanto la gestión de movilidad (MM) como la gestión de movilidad GPRS (GMM) 626. Ésta Incluye además gestión de sesión/gestión de portador de acceso de radio SM/RABM 624 y GSMS 628.

CC 618 proporciona señalización de gestión de llamadas para servicios de circuitos conmutados. La porción de gestión de sesión de SM/RABM 624 proporciona la activación, desactivación y modificación del contexto PDP. SM/RABM 624 también proporciona calidad de negociación de servicio.

La función principal de la porción RABM del SM/RABM 624 es conectar un contexto PDP a un portador de acceso de radio. Por lo tanto, SM/RABM 624 es responsable por la configuración, modificación y liberación de los recursos de radio.

El plano 610 de control CS y el plano 611 de control PS, en el estrato 616 de acceso se sientan en el control de recursos de radio (RRC) 617.

La porción 614 NAS en el plano 630 de usuario PS incluye una capa 638 de aplicación, la capa 636 TCP/UDP y la capa 634 PDP. La capa 634 PDP puede, por ejemplo, incluir el Protocolo de Internet (IP).

El estrato 616 de acceso, en el plano 630 de usuario PS incluye el protocolo de convergencia de datos por paquetes (PDCP) 632. PDCP 632 está diseñado para hacer que el protocolo WCDMA sea adecuado para transportar el protocolo TCP/IP entre UE y RNC (como se ve en la Figura 8), y es opcional para la compresión y descompresión del encabezado del protocolo de flujo de tráfico IP.

Las capas 640 de Control de enlace de radio UMTS (RLC) y Control de acceso medio (MAC) 650 forman las subcapas de enlace de datos de la interfaz de radio UMTS y residen en el nodo RNC y el equipo de usuario.

La capa UMTS de capa 1 (L1) (capa 660 física) está debajo de las capas 640 y 650 RLC/MAC. Esta capa es la capa física para las comunicaciones.

Si bien lo anterior se puede implementar en una variedad de dispositivos móviles o inalámbricos, a continuación, se describe un ejemplo de un dispositivo móvil con respecto a la Figura 7. Ahora se hace referencia a la Figura 7.

El UE 700 es preferiblemente un dispositivo de comunicación inalámbrica bidireccional que tiene al menos capacidades de comunicación de voz y datos. El UE 700 tiene preferiblemente la capacidad de comunicarse con otros sistemas informáticos en Internet. Dependiendo de la funcionalidad exacta proporcionada, el dispositivo inalámbrico puede ser denominado dispositivo de mensajería de datos, buscapersonas bidireccional, dispositivo de correo electrónico inalámbrico, teléfono de celda con capacidad de mensajería de datos, dispositivo inalámbrico de Internet o dispositivo de comunicación de datos, como ejemplos.

Cuando el UE 700 está habilitado para comunicación bidireccional, incorporará un subsistema 711 de comunicación, que incluye tanto un receptor 712 como un transmisor 714, así como componentes asociados tales como uno o más preferiblemente integrados o internos, elementos 716 y 718 de antena, osciladores locales (LO) 713 y un módulo de procesamiento como un procesador de señal digital (DSP) 720. Como será evidente para los expertos en el campo de las comunicaciones, el diseño particular del subsistema 711 de comunicación dependerá de la red de comunicación en la cual el dispositivo está destinado a operar. Por ejemplo, UE 700 puede incluir un subsistema 711 de comunicación diseñado para operar dentro de la red GPRS o la red UMTS.

Los requisitos de acceso a la red también variarán dependiendo del tipo de red 719. Por ejemplo, en las redes UMTS y GPRS, el acceso a la red está asociado con un suscriptor o usuario de UE 700. Por ejemplo, un dispositivo móvil GPRS requiere una tarjeta de módulo de identidad de suscriptor (SIM) para operar en una red GPRS. En UMTS se requiere un módulo USIM o SIM. En CDMA se requiere una tarjeta o módulo RUIM. Estos se denominarán una interfaz UIM en este documento. Sin una interfaz UIM válida, un dispositivo móvil puede no ser completamente funcional. Pueden estar disponibles funciones de comunicación local o no de red, así como funciones requeridas legalmente (si las hay) como llamadas de emergencia, pero el dispositivo 700 móvil no podrá llevar a cabo ninguna otra función que implique comunicaciones a través de la red 700. La interfaz 744 UIM es normalmente similar a una ranura para tarjetas en la que se puede insertar y expulsar una tarjeta como un disquete o tarjeta PCMCIA. La tarjeta UIM puede tener aproximadamente 64K de memoria y contener muchas configuraciones 751 clave y otra información 753, como identificación e información relacionada con el suscriptor.

Cuando se han completado los procedimientos requeridos de registro o activación de la red, el UE 700 puede enviar y recibir señales de comunicación a través de la red 719. Las señales recibidas por la antena 716 a través de la red 719 de comunicación se introducen en el receptor 712, que puede realizar funciones comunes del receptor como amplificación de señal, conversión de reducción de frecuencia, filtrado, selección de canales y similares, y en el sistema de ejemplo que se muestra en la Figura 7, conversión de analógico a digital (A/D). La conversión A/D de una señal recibida permite que se realicen funciones de comunicación más complejas, como la demodulación y la decodificación en el DSP 720. De manera similar, las señales a transmitir se procesan, incluida la modulación y codificación, por ejemplo, por DSP 720 y entrada al transmisor 714 para conversión digital a analógica, conversión de frecuencia ascendente, filtrado, amplificación y transmisión a través de la red 719 de comunicación a través de la antena 718. DSP 720 no solo procesa las señales de comunicación, sino que también proporciona el control del receptor y el transmisor. Por ejemplo, las ganancias aplicadas a las señales de comunicación en el receptor 712 y el transmisor 714 pueden controlarse de forma adaptativa a través de algoritmos de control de ganancia automático implementados en DSP 720.

La red 719 puede comunicarse además con múltiples sistemas, incluido un servidor 760 y otros elementos (no mostrados). Por ejemplo, la red 719 puede comunicarse tanto con un sistema empresarial como con un sistema de cliente web para acomodar a diversos clientes con diversos niveles de servicio.

El UE 700 incluye preferiblemente un microprocesador 738, que controla el funcionamiento global del dispositivo. Las funciones de comunicación, incluidas al menos las comunicaciones de datos, se realizan a través del subsistema 711 de comunicación. El microprocesador 738 también interactúa con subsistemas de dispositivos adicionales tales como la pantalla 722, memoria flash 724, memoria de acceso aleatorio (RAM) 726, subsistemas 728 entrada/salida (I/O) auxiliares, puerto 730 serial, teclado 732, altavoz 734, micrófono 736, un subsistema 740 de comunicaciones de corto alcance y cualquier otro subsistema de dispositivos generalmente designado como 742.

Algunos de los subsistemas mostrados en la Figura 7 realizan funciones relacionadas con la comunicación, mientras que otros subsistemas pueden proporcionar funciones “residentes” o en el dispositivo. En particular, algunos subsistemas, como el teclado 732 y la pantalla 722, por ejemplo, se pueden usar para funciones relacionadas con la comunicación, como ingresar un mensaje de texto para su transmisión a través de una red de comunicación, y funciones residentes en el dispositivo, como una calculadora o lista de tarea.

El software del sistema operativo utilizado por el microprocesador 738 se almacena preferiblemente en un almacén persistente tal como la memoria flash 724, que en su lugar puede ser una memoria de solo lectura (ROM) o un elemento de almacenamiento similar (no mostrado). Los expertos en la materia apreciarán que el sistema operativo, las aplicaciones específicas del dispositivo, o partes del mismo, pueden cargarse temporalmente en una memoria volátil como RAM 726. Las señales de comunicación recibidas también pueden almacenarse en RAM 726. Además, un identificador único es también preferiblemente almacenado en memoria de solo lectura.

Como se muestra, la memoria flash 724 puede segregarse en diferentes áreas tanto para los programas 758 informáticos como para el almacenamiento 750, 752, 754 y 756 de datos de programa. Estos diferentes tipos de almacenamiento indican que cada programa puede asignar una parte de la memoria flash 724 para sus requisitos de almacenamiento de datos propios. El microprocesador 738, además de las funciones de su sistema operativo, permite preferiblemente la ejecución de aplicaciones de software en el dispositivo móvil. Un conjunto predeterminado de aplicaciones que controlan las operaciones básicas, que incluyen al menos aplicaciones de comunicación de datos y voz, por ejemplo, normalmente se instalarán en el UE 700 durante la fabricación. Una aplicación de software preferida puede ser una aplicación de gestión de información personal (PIM) que tenga la capacidad de organizar y administrar elementos de datos relacionados con el usuario del dispositivo móvil, tales como, pero no limitados a, correo electrónico, eventos de calendario, correos de voz, citas y elementos de tarea. Naturalmente, uno o más almacenes de memoria estarían disponibles en el dispositivo móvil para facilitar el almacenamiento de ítem de datos PIM. Dicha aplicación PIM preferiblemente tendría la capacidad de enviar y recibir ítem de datos, a través de la red 719 inalámbrica. En una realización preferida, los ítems de datos PIM están perfectamente integrados, sincronizados y actualizados, a través de la red 719 inalámbrica, con los ítems de datos correspondientes del usuario del dispositivo móvil almacenados o asociados con un sistema informático huésped. Otras aplicaciones también pueden cargarse en el dispositivo 700 móvil a través de la red 719, un subsistema 728 de I/O auxiliar, un puerto 730 serial, un subsistema 740 de comunicaciones de corto alcance o cualquier otro subsistema 742 adecuado, y un usuario puede instalarlo en la RAM 726 o preferiblemente un almacén no volátil (no mostrado) para ejecución por el microprocesador 738. Tal flexibilidad en la instalación de la aplicación aumenta la funcionalidad del dispositivo y puede proporcionar funciones mejoradas en el dispositivo, funciones relacionadas con la comunicación, o ambas. Por ejemplo, las aplicaciones de comunicación segura pueden permitir que las funciones de comercio electrónico y otras transacciones financieras se realicen utilizando el UE 700. Sin embargo, estas aplicaciones, de acuerdo con lo anterior, en muchos casos deben ser aprobadas por un operador.

En un modo de comunicación de datos, el subsistema 711 de comunicación procesará una señal recibida tal como un mensaje de texto o descarga de notificación web y la ingresará al microprocesador 738, que preferiblemente procesa adicionalmente la señal recibida para enviarla a la pantalla 722, o alternativamente a un dispositivo 728 I/O auxiliar. Un usuario de UE 700 también puede componer elementos de datos tales como mensajes de correo electrónico, por ejemplo, usando el teclado 732, que es preferiblemente un teclado alfanumérico completo o un teclado de tipo telefónico, junto con la pantalla 722 y posiblemente un dispositivo 728 I/O auxiliar. Dichos elementos compuestos pueden transmitirse a través de una red de comunicación a través del subsistema 711 de comunicación.

Para las comunicaciones de voz, el funcionamiento general del UE 700 es similar, excepto que las señales recibidas se enviarían preferiblemente a un altavoz 734 y las señales para la transmisión serían generadas por un micrófono 736. Subsistemas de I/O de voz o audio alternativos, tales como un subsistema de grabación de mensajes de voz, también puede implementarse en el UE 700. Aunque la salida de señal de voz o audio se realiza preferiblemente principalmente a través del altavoz 734, la pantalla 722 también puede usarse para proporcionar una indicación de la identidad de una parte llamante, la duración de una llamada de voz u otra información relacionada con la llamada de voz, por ejemplo.

El puerto 730 serial en la Figura 7 se implementaría normalmente en un dispositivo móvil de tipo asistente personal digital (PDA) para el cual puede ser deseable la sincronización con el ordenador de escritorio de un usuario (no mostrado). Tal puerto 730 permitiría a un usuario establecer preferencias a través de un dispositivo externo o aplicación de software y ampliaría las capacidades del dispositivo 700 móvil al proporcionar información o descargas de software al UE 700 que no sea a través de una red de comunicación inalámbrica. La ruta de descarga alternativa se puede usar, por ejemplo, para cargar una clave de cifrado en el dispositivo a través de una conexión directa y, por lo tanto, confiable y segura para permitir así la comunicación segura del dispositivo.

Alternativamente, el puerto 730 serial podría usarse para otras comunicaciones, y podría incluirse como un puerto de bus serial universal (USB). Una interfaz está asociada con el puerto 730 serial.

Otros subsistemas 740 de comunicaciones, tales como un subsistema de comunicaciones de corto alcance, es un componente opcional adicional que puede proporcionar comunicación entre UE 700 y diferentes sistemas o dispositivos, que no necesariamente tienen que ser dispositivos similares. Por ejemplo, el subsistema 740 puede incluir un dispositivo infrarrojo y circuitos y componentes asociados o un módulo de comunicación Bluetooth™ para proporcionar comunicación con sistemas y dispositivos habilitados de manera similar.

Ahora se hace referencia a la Figura 8. La Figura 8 es un diagrama de bloques de un sistema 800 de comunicación que incluye un UE 802 que se comunica a través de la red de comunicación inalámbrica.

UE 802 se comunica de forma inalámbrica con uno o diversos nodos B 806. Cada nodo B 806 es responsable del procesamiento de la interfaz aérea y de algunas funciones de gestión de recursos de radio. El Nodo B 806 proporciona una funcionalidad similar a una Estación Transceptora Base en redes GSM/GPRS.

El enlace inalámbrico que se muestra en el sistema 800 de comunicación de la Figura 8 representa uno o más canales diferentes, típicamente diferentes canales de radiofrecuencia (RF), y protocolos asociados utilizados entre la red inalámbrica y el UE 802. Se utiliza una interfaz 804 aérea Uu entre UE 802 y Nodo B 806.

Un canal de RF es un recurso limitado que debe conservarse, típicamente debido a los límites en el ancho de banda general y a una potencia de batería limitada de UE 802. Los expertos en la materia apreciarán que una red inalámbrica en la práctica real puede incluir cientos de celdas dependiendo sobre la extensión total deseada de la cobertura de la red. Todos los componentes pertinentes pueden conectarse mediante múltiples conmutadores y enrutadores (no mostrados), controlados por múltiples controladores de red.

Cada Nodo B 806 se comunica con un controlador de red de radio (RNC) 810. El RNC 810 es responsable del control de los recursos de radio en su área. Un RNC 810 controla múltiples nodos B 806.

El RNC 810 en redes UMTS proporciona funciones equivalentes a las funciones del Controlador de estación base (BSC) en redes GSM/GPRS. Sin embargo, un RNC 810 incluye más inteligencia, incluida, por ejemplo, la gestión de transferencias autónomas sin involucrar a MSC y SGSN.

La interfaz utilizada entre el Nodo B 806 y RNC 810 es una interfaz lub 808. Se utiliza principalmente un protocolo de señalización NBAP (parte de aplicación del Nodo B), como se define en 3GPP TS 25.433 V3.11.0 (2002-09) y 3GPP TS 25.433 V5.7.0 (2004-01).

La Red de Acceso Radio Terrestre Universal (UTRAN) 820 comprende el RNC 810, el nodo B 806 y la interfaz 804 aérea Uu.

El tráfico de circuito conmutado se enruta al Centro de Conmutación Móvil (MSC) 830. MSC 830 es el ordenador que realiza las llamadas y toma y recibe datos del suscriptor o de la PSTN (no mostrada).

El tráfico entre RNC 810 y MSC 830 usa la interfaz 828 lu-CS. La interfaz 828 lu-CS es la conexión de circuito conmutado para transportar (típicamente) tráfico de voz y señalización entre UTRAN 820 y la red de voz central. El protocolo de señalización principal utilizado es RANAP (Parte de aplicación de red de acceso de radio). El protocolo RANAP se usa en la señalización UMTS entre la red 821 central, que puede ser un MSC 830 o SGSN 850 (definido con más detalle a continuación) y UTRAN 820. El protocolo RANAP se define en 3GPP TS 25.413 V3.11.1 (2002­ 09) y TS 25.413 V5.7.0 (2004-01).

Para todos los UE 802 registrados con un operador de red, los datos permanentes (como el perfil del usuario UE 802) así como los datos temporales (como la ubicación actual 802 del UE) se almacenan en un registro de ubicación de origen (HLR) 838. En caso de una llamada de voz al UE 802, HLR 838 se consulta para determinar la ubicación actual del UE 802. Un Registro de ubicación de visitantes (VLR) 836 del MSC 830 es responsable de un grupo de áreas de ubicación y almacena los datos de esas estaciones móviles que están actualmente en su área de responsabilidad. Esto incluye partes de los datos permanentes de la estación móvil que se han transmitido desde el HLR 838 al VLR 836 para un acceso más rápido. Sin embargo, el VLR 836 de MSC 830 también puede asignar y almacenar datos locales, como identificaciones temporales. UE 802 también se autentica en el acceso al sistema por HLR 838.

Los datos de paquete se enrutan a través del Nodo de Soporte de Servicio GPRS (SGSN) 850. SGSN 850 es la puerta de enlace entre el RNC y la red central en una red GPRS/UMTS y es responsable de la entrega de paquetes de datos desde y hacia los UE dentro de su área de servicio geográfico. La interfaz 848 lu-PS se usa entre el RNC 810 y el SGSN 850, y es la conexión de conmutación de paquetes para transportar (típicamente) tráfico de datos y señalización entre el UTRAN 820 y la red de datos central. El protocolo de señalización principal utilizado es RANAP (descrito anteriormente).

El SGSN 850 se comunica con el Nodo de Soporte GPRS de puerta de acceso (GGSN) 860. GGSN 860 es la interfaz entre la red UMTS/GPRS y otras redes tales como Internet o redes privadas. GGSN 860 está conectado a una red pública de datos PDN 870 a través de una interfaz Gi.

Los expertos en la materia apreciarán que la red inalámbrica puede estar conectada a otros sistemas, posiblemente incluyendo otras redes, que no se muestran explícitamente en la Figura 8. Una red normalmente transmitirá al menos algún tipo de notificaciones e información del sistema sobre una base continua incluso si no se intercambian datos de paquetes reales. Aunque la red consiste de muchas partes, todas estas partes trabajan juntas para generar ciertos comportamientos en el enlace inalámbrico.

La figura 11 ilustra una representación, mostrada generalmente en 1102, representativa de la operación del UE de acuerdo con múltiples sesiones simultáneas de servicios de comunicación de datos por paquetes. Aquí, dos servicios de paquetes de datos, cada uno asociado con un contexto PDP particular designado como PDP1 y PDP2, están activos simultáneamente. El gráfico 1104 representa el contexto PDP activado para el primer servicio de paquete de datos, y el gráfico 1106 representa el recurso de radio asignado al primer servicio de paquete de datos. Y, el gráfico 1108 representa el contexto PDP activado para el segundo servicio de paquete de datos, y el gráfico 1112 representa el recurso de radio asignado al segundo servicio de paquete de datos. El UE solicita la asignación de portador de acceso de radio mediante una solicitud de servicio, indicada por los segmentos 1114. Y, el UE también solicita la liberación del servicio de portador de radio, indicado por los segmentos 1116 de acuerdo con una realización de la presente divulgación. Las solicitudes de servicio y las versiones de servicio para los servicios separados son independientes entre sí, es decir, se generan de forma independiente. En la ilustración de ejemplo de la Figura 11, el contexto PDP y el recurso de radio para el contexto PDP asociado se asignan en momentos sustancialmente concurrentes. Y, la liberación del recurso de radio se otorga a solicitud del UE, como se muestra, o cuando el RNC (Controlador de Red de Radio) decide liberar el recurso de radio.

En respuesta a una solicitud de liberación de recursos de radio, u otra decisión de liberar el recurso de radio, la red derriba de manera selectiva el recurso de radio asociado con el servicio de paquetes de datos. Las solicitudes de liberación de radio se realizan sobre la base de un portador de acceso de radio por portador de acceso de radio y no sobre una base de conexión de señalización completa, lo que permite un control de granularidad mejorado de la asignación de recursos.

En la implementación a modo de ejemplo, un único servicio de paquete de datos se puede formar como servicio primario y uno o más servicios secundarios, como se indica en las designaciones 1118 y 1122. La liberación de recursos de radio permite además identificar cuál de uno o más servicios primarios y secundarios cuyas asignaciones de recursos de radio ya no son necesarias, o de lo contrario se desean liberar. De este modo se proporciona una asignación eficiente de recursos de radio. Además, se proporciona una utilización óptima del procesador en el UE, ya que la potencia del procesador que se habría asignado a un procesamiento innecesario ahora se puede utilizar mejor para otros fines.

240 La Figura 12 ilustra partes del sistema 800 de comunicación, a saber, el UE 802 y el controlador de red de radio (RNC)/SGSN 810/850 que operan de acuerdo con una realización de la presente divulgación perteneciente a las sesiones múltiples del servicio de datos de paquete contiguo. El UE incluye el aparato 1126 y el RNC/SGSN incluye el aparato 1128 de una realización de la presente divulgación. Los elementos que forman el aparato 1126 y 1128 están representados funcionalmente, implementables de cualquier manera deseada, incluso mediante algoritmos ejecutables mediante circuitos de procesamiento, así como implementaciones de hardware o firmware. Los elementos del aparato 1128, aunque se representan para ser incorporados en el RNC/SGSN, se forman, en otras implementaciones, en otros lugares en otras ubicaciones de red, o se distribuyen en más de una ubicación de red.

El aparato 1126 incluye un detector 1132 y un emisor 1134 de indicación de transición. En una implementación de ejemplo, los elementos 1132 y 1134 están incorporados en una capa de gestión de sesión, por ejemplo, la capa de Estrato Sin Acceso (NAS) definida en UMTS, de la UE.

En otra implementación de ejemplo, los elementos están incorporados en una subcapa de Estrato de Acceso (AS). Cuando se implementan en la subcapa AS, los elementos se implementan como parte de un administrador de conexión, que se muestra en 1136. Cuando se implementan de esta manera, los elementos no necesitan estar conscientes del comportamiento del contexto PDP o del comportamiento de la capa de aplicación.

El detector detecta cuando se hace una determinación para enviar una indicación de transición asociada con un servicio de comunicación por paquetes. La determinación se realiza, por ejemplo, en una capa de aplicación u otra capa lógica, y se proporciona a la capa de gestión de sesión y al detector incorporado allí. Las indicaciones de las detecciones realizadas por el detector se proporcionan al emisor de la indicación de liberación de recursos de radio. El emisor genera y hace que el UE envíe una indicación de transición que forma la solicitud 1116 de liberación del servicio, que se muestra en la Figura 11.

En una implementación adicional, la indicación de transición incluye un campo de causa que contiene una causa, tal como cualquiera de las causas antes mencionadas descritas aquí y arriba, según corresponda o el campo de causa identifica un estado preferido en el que el UE prefiere que la red cause la transición del UE.

El aparato 1128 incorporado en la red incluye un examinador 1142 y un otorgante 1144. El examinador examina la indicación de transición, cuando se recibe allí. Y, el otorgante 1144 de transición opera selectivamente para hacer la transición del UE como se solicita en la indicación de transición.

En una implementación en la que la señalización se realiza en una capa de control de recursos de radio (RRC), el controlador de red de radio (RNC), en lugar del SGSN, realiza el examen y la transición del UE. Y, correspondientemente, el aparato incorporado en el UE se forma en la capa RRC, o el aparato de otro modo hace que la indicación generada se envíe al nivel RRC.

En un flujo de control de ejemplo, una capa superior informa a la capa NAS/RRC, según corresponda, que el recurso de radio está asignado a un contexto PDP particular ya no es necesario. Se envía un mensaje de indicación de capa RRC a la red. El mensaje incluye una RAB ID o RB ID que, por ejemplo, identifica el servicio de paquete de datos, al controlador de la red de radio. Y, en respuesta, la operación del controlador de red de radio activa un procedimiento para resolver la finalización de la liberación de recursos de radio, la reconfiguración de recursos de radio o el mensaje de liberación de conexión de control de recursos de radio (RRC) que se devolverá al UE. El procedimiento RNC es, por ejemplo, similar o equivalente al procedimiento establecido en el documento 3GPP TS 23.060, Sección 9.2.5. La ID de RAB se utiliza, por ejemplo, de manera ventajosa, ya que la ID es la misma que el Identificador de punto de acceso al servicio de red (NSAPI) que identifica el contexto PDP asociado, y las capas de aplicación son generalmente enteradas de la NSAPI.

En un ejemplo específico, una indicación de liberación de recursos de radio formada en, o proporcionada de otro modo a la capa RRC, y enviada en la capa RRC se representa, junto con la información asociada, a continuación. La indicación cuando se realiza en la capa RRC también se denomina, por ejemplo, una indicación de liberación de recursos de radio.

La Figura 13 ilustra un diagrama de secuencia de mensajes, que se muestra generalmente en 1137, que representa la señalización de ejemplo generada de acuerdo con la liberación de recursos de radio asociados con un contexto PDP, como el que se muestra gráficamente en parte de la representación gráfica que se muestra en la Figura 11. La liberación es iniciada por el UE o en el RNC u otra entidad UTRAN. Cuando se inicia en el UE, por ejemplo, el UE envía una indicación de liberación de recursos de radio a la UTRAN.

Al iniciarse, se genera una solicitud de liberación de portador de acceso de radio (RAB) y se envía, indicada por el segmento 1138 por el RNC/UTRAN y entregada al SGSN. En respuesta, se devuelve una solicitud de asignación RAB, indicada por el segmento 1140, al RNC/UTRAN. Y, entonces, como lo indica el segmento 1142, se liberan los recursos de radio que se extienden entre el UE 802 y la UTRAN. Luego se envía una respuesta, como lo indica el segmento 1144.

La figura 14 ilustra un diagrama de secuencia de mensajes mostrado generalmente en 1147, similar al diagrama de secuencia de mensajes mostrado en la figura 13, pero aquí en el que se liberan recursos de un contexto PDP final. Al iniciarse, el RNC genera una solicitud 1150 de liberación de lu se comunica al SGSN y, en respuesta a esto, el SGSN devuelve una orden de liberación de lu, indicada por el segmento 1152. Posteriormente, y de acuerdo con lo indicado por los segmentos 1154, el portador de radio formado entre el UE y el UTRAN se libera. Y, como lo indica el segmento 1156, el RNC/UTRAN devuelve una liberación lu completa al SGSN.

La Figura 15 ilustra un diagrama de flujo del método, que se muestra generalmente en 1162, representativo del proceso de una realización de la presente divulgación para liberar recursos de radio asignados de acuerdo con un contexto PDP.

Después del inicio del proceso, indicado por el bloque 1164, se realiza una determinación, indicada por el bloque de decisión 1166 en cuanto a si se ha recibido una indicación de liberación de recursos de radio. Si no, la rama no se lleva al bloque final 1168.

Si, por el contrario, se ha solicitado una liberación del portador de acceso de radio, la rama sí se lleva al bloque 1172 de decisión. En el bloque 1172 de decisión, se determina si el portador de acceso de radio que se va a liberar es el portador de acceso de radio que se va a liberar. Si no, la rama no se lleva al bloque 1178 y se establece el estado preferido. Luego se realizan los procedimientos de liberación del portador de acceso de radio, como el que se muestra en la Figura 13 o el descrito en la Sección 23.060 del documento 3GPP, subcláusula 9.2.5.1.1.

Por el contrario, si se toma una determinación en el bloque 1172 de decisión de que el RAB es el último en ser liberado, la rama sí se lleva al bloque 1186, un procedimiento de liberación de lu, como el que se muestra en la Figura 14 o tal como que se describe en la sección 23.060 del documento 3GPP, se realiza la subcláusula 9.2.5.1.2.

La Figura 16 ilustra un diagrama de flujo del método, que se muestra generalmente en 1192, representativo del proceso de una realización de la presente divulgación para liberar recursos de radio asignados de acuerdo con un contexto PDP.

Después del inicio del proceso, indicado por el bloque 1194, se realiza una determinación, indicada por el bloque de decisión 1196 en cuanto a si hay un RAB (Portador de Acceso de Radio) para liberar. Si no, la rama no se lleva al bloque final 1198.

Si, por el contrario, se ha solicitado una liberación del portador de acceso de radio, la rama sí se lleva al bloque 1202 de decisión. En el bloque 1202 de decisión, se determina si el portador de acceso de radio que se va a liberar es el portador de acceso de radio final que se liberará. Si no, la rama no se lleva al bloque 1204, donde se establece la lista RAB, el bloque 1206 donde se establece el estado preferido y el bloque 1208 donde se realizan los procedimientos de liberación del portador de acceso de radio, como el que se muestra en la Figura 13 o tal como se describe en el documento 3GPP Sección 23.060, subcláusula 9.2.5.1.1.

Por el contrario, si se toma una determinación en el bloque 1202 de decisión de que el RAB es el último en liberarse, la rama sí se lleva al bloque 1212, y el dominio se establece en PS (paquete conmutado). Luego, como lo indica el bloque 1214, se establece una causa de liberación. Y, como lo indica el bloque 1216, se envía una SIGNALING CONNECTION RELEASE INDICATION en un DCCH. Se realiza un procedimiento de liberación de lu, como el que se muestra en la Figura 14 o el descrito en la sección 23.060 del documento 3GPP, subcláusula 9.2.5.1.2.

La figura 17 ilustra un método, mostrado generalmente en 1224, representativo del método de operación de una realización de la presente divulgación. El método facilita la utilización eficiente de los recursos de radio en un sistema de comunicación por radio que permite la ejecución concurrente de un primer servicio de paquetes y un segundo servicio de paquetes. Primero, y como lo indica el bloque 1226, la detección se realiza mediante selección para liberar un recurso de radio asociado con un servicio de paquetes seleccionado del primer servicio de paquetes y el segundo servicio de paquetes. Entonces, y como lo indica el bloque 1228, se envía una indicación de liberación de recursos de radio en respuesta a la detección de la selección para liberar el recurso de radio.

Luego, en el bloque 1212 se examina la indicación de liberación de recursos de radio y luego en el bloque 1214 el otorgamiento de la liberación del portador de radio se otorga de manera selectiva.

En una realización adicional, la red puede iniciar una transición basada tanto en la recepción de una indicación del equipo de usuario u otro elemento de red como en un perfil de recursos de radio para el equipo de usuario.

Una indicación recibida del equipo de usuario u otro elemento de red podría ser cualquiera de las diferentes indicaciones de transición descritas anteriormente. La indicación puede ser pasiva y, por lo tanto, ser simplemente una indicación en blanco de que se debe ingresar un estado de radio con menos consumo de batería. Alternativamente, la indicación podría ser parte de las indicaciones regulares enviadas desde el UE que la red determina, posiblemente con el tiempo o una cantidad de indicaciones recibidas, y el perfil de recursos de radio del UE de que se debe ingresar un estado de radio con menos batería o recursos de radio intensivos. Alternativamente, la indicación podría ser dinámica y proporcionar información al elemento de red sobre un estado o modo preferido en el que realizar la transición. Al igual que con lo anterior, la indicación podría contener una causa para la indicación (por ejemplo, normal o anormal). En una realización adicional, la indicación podría proporcionar otra información sobre un perfil de recurso de radio, tal como una probabilidad de que el equipo de usuario sea correcto acerca de la capacidad de transición a un estado o modo diferente, o información sobre las aplicaciones que activaron la indicación.

Una indicación de otro elemento de red podría incluir, por ejemplo, una indicación de un medio o entidad de red de pulsar para hablar. En este ejemplo, la indicación se envía a la entidad de red responsable de la transición (por ejemplo, la UTRAN) cuando las condiciones del tráfico lo permiten. Esta segunda entidad de red podría observar el tráfico a nivel de protocolo de Internet (IP) para determinar si enviar una indicación de transición y cuándo enviarla.

En una realización adicional, la indicación del UE o del segundo elemento de red podría ser implícita en lugar de explícita. Por ejemplo, una indicación de transición puede estar implicada por el elemento de red responsable de la transición (por ejemplo, la UTRAN) de los reportes de estado del dispositivo en las mediciones de tráfico saliente. Específicamente, el reporte de estado podría incluir un estado de memoria intermedia de enlace de radio donde, si no existen datos salientes, podría interpretarse como una indicación implícita. Tal reporte de estado podría ser una medida que puede enviarse repetidamente desde el UE que, por sí misma, no solicita ni indica nada.

Por lo tanto, la indicación podría ser cualquier señal y podría estar basada en la aplicación, en los recursos de radio o en una indicación compuesta que proporcione información sobre todas las aplicaciones y recursos de radio del equipo de usuario. Lo anterior no pretende limitar a ninguna indicación particular, y un experto en la materia apreciaría que cualquier indicación podría usarse con el presente método y divulgación.

Ahora se hace referencia a la Figura 18. El proceso comienza en el paso 1801 y continúa al paso 1810 en el que un elemento de red recibe la indicación.

Una vez que la red recibe la indicación en el paso 1810, el proceso pasa al paso 1820 en el que opcionalmente se verifica un perfil de recursos de radio para el equipo de usuario.

El término “perfil de recursos de radio”, como se usa en el presente documento, pretende ser un término amplio que podría aplicarse a una variedad de situaciones, dependiendo de los requisitos de un elemento de red. En términos generales, el perfil de recursos de radio incluye información sobre los recursos de radio utilizados por el equipo del usuario.

El perfil de recursos de radio podría incluir uno o ambos elementos de perfil estáticos y elementos de perfil dinámicos o negociados. Dichos elementos podrían incluir un valor de “inhibición de la duración y/o mensajes máximos de indicación/solicitud por ventana de tiempo”, que podría ser parte del perfil de recursos de radio, dentro o fuera del perfil de transición, y podría ser negociado o estático.

Los elementos de perfil estático pueden incluir una o más de la calidad de servicio para un recurso de radio (por ejemplo, RAB o RB), un contexto PDP, un APN del que la red tiene conocimiento y un perfil de suscriptor.

Como apreciarán los expertos en la materia, podrían existir diversos niveles de servicio de calidad para un recurso de radio y el nivel de calidad de servicio podría proporcionar información a una red sobre si hacer la transición a un estado o modo diferente. Por lo tanto, si la calidad del servicio es de fondo, el elemento de red puede considerar la transición a inactivo más fácilmente que si la calidad del servicio se establece en interactiva. Además, si múltiples recursos de radio tienen la misma calidad de servicio, esto podría proporcionar una indicación a la red sobre si se debe hacer la transición del dispositivo móvil a un estado o modo más adecuado o derribar los recursos de radio. En algunas realizaciones, un contexto PDP primario y secundario podría tener una calidad de servicio diferente, lo que también podría afectar la decisión sobre si realizar una transición de estado/modo.

Además, el APN podría proporcionar a la red información sobre los servicios típicos que utiliza el contexto PDP. Por ejemplo, si el APN es xyz.com, donde xyz.com se usa típicamente para la provisión de servicios de datos como el correo electrónico, esto podría proporcionar una indicación a la red sobre si se debe realizar la transición a un estado o modo diferente. Esto podría indicar además características de enrutamiento.

En particular, el presente método y aparato pueden utilizar el nombre del punto de acceso (APN) especificado por el UE para establecer el perfil de transición entre diversos estados. Esta puede ser otra forma de describir la suscripción del UE. Como se apreciará, el Home Location Register (HLR) puede almacenar información relevante sobre los suscriptores y podría proporcionar al controlador de red de radio (RNC) la suscripción del UE. Otras entidades de red también podrían usarse para almacenar información de suscripción centralmente. Ya sea que use el HLR u otra entidad de red, la información se envía preferiblemente a otros componentes de la red, como el RNC y el SGSN, que mapean la información de suscripción a los parámetros físicos relevantes utilizados durante el intercambio de datos.

La UTRAN podría incluir o tener acceso a una base de datos o tabla en la que diversos parámetros APN o QoS podrían estar vinculados a un perfil de transición específico. Por lo tanto, si el UE es un dispositivo siempre encendido, esto será evidente a partir de la APN y un perfil de transición apropiado para esa APN podría almacenarse en la UTRAN como parte del perfil de recursos de radio o ser accesible remotamente por la UTRAN. De manera similar, si se usa la QoS o una parte del parámetro de QoS, o se envía un mensaje dedicado con un perfil, esto podría significar para la UTRAN que se desea un perfil de transición en particular basado en una consulta de base de datos o una búsqueda en una tabla. Además, se puede especificar una multiplicidad de comportamientos más allá del perfil de transición de estado conectado RRC por este medio. Estos incluyen, pero no se limitan a:

algoritmos de adaptación de velocidad (periodicidad del paso/tamaño del paso);

portador de radio inicial otorgado;

portador de radio máximo otorgado;

minimizar el tiempo de configuración de la llamada (evitar pasos innecesarios, como mediciones de volumen de tráfico); y

la interfaz aérea (GPRS/EDGE/UMTS/HSDPA/HSUPA/LTE, etc.).

Además, si hay múltiples contextos PDP que tienen diferentes requisitos de QoS pero comparten la misma dirección IP APN, como un contexto primario, un contexto secundario, etc., se puede usar un perfil de transición diferente para cada contexto. Esto se puede indicar a la UTRAN a través de QoS o mensajes dedicados.

Si se utilizan simultáneamente múltiples contextos PDP activos, se puede usar el mínimo común denominador entre los contextos. Para la transición de estado RRC, si una aplicación tiene un primer contexto PDP que está asociado con un perfil de transición en el que el sistema se mueve del estado CELL_DCH a un estado CELL_PCH o inactivo rápidamente, y un segundo contexto PDP está asociado con un perfil de transición en el que el sistema debe permanecer en el estado CELL_DCH por más tiempo, el segundo perfil en el que se mantiene el estado CELL_DCH anulará el primer perfil.

Como apreciarán los expertos en la materia, el mínimo común denominador se puede considerar de dos maneras diferentes. El mínimo común denominador, como se usa en este documento, implica un tiempo más largo requerido antes de la transición a un estado diferente. En una primera realización, el mínimo común denominador puede ser el más bajo de los PDP activados. En una realización alternativa, el mínimo común denominador puede ser el más bajo de los PDP que realmente tienen recursos de radio activos. Los recursos de radio podrían multiplexarse de diferentes maneras, pero el resultado final es el mismo.

Se puede extraer un caso de ejemplo para tales métodos para siempre en dispositivos. Como se describe, diversos parámetros APN o QoS se pueden vincular a un comportamiento específico para siempre activado. Considere los recursos de radio inicialmente otorgados que pueden ser deseables en función de un perfil “siempre activo”. La red ahora tiene un medio para “saber” que las ráfagas de datos son cortas y explosivas para aplicaciones siempre activas, como el correo electrónico. Para los expertos en la materia, se ve claramente que, dada esta información, no existe ningún incentivo para ahorrar espacio en el código para la eficiencia del enlace troncal en la red. Por lo tanto, se puede asignar una tasa máxima a un dispositivo siempre encendido con poco riesgo de no reservar suficiente espacio de código para otros usuarios. Además, el UE se beneficia al recibir datos más rápidamente y también ahorra batería debido a un “tiempo” más corto. Nuevamente, para los expertos en la materia, las altas velocidades de datos tienen muy poco efecto en el consumo de corriente, ya que los amplificadores de potencia están totalmente sesgados, independientemente de la velocidad de datos.

En la realización anterior, la UTRAN puede usar una tabla de búsqueda para determinar el perfil de control de recursos para los recursos de radio que se asignarán para diferentes aplicaciones para una conexión RRC dada para el UE. El perfil puede basarse en la suscripción del usuario y almacenarse en el lado de la red en una entidad de red como HLR o, alternativamente, en el RNC, ya que el RNC tendrá recursos de tráfico más actualizados disponibles (es decir, tasas de datos que se pueden otorgar). Si se pueden lograr velocidades de datos más altas, es posible que existan tiempos de espera más cortos.

En lugar de APN, se pueden usar otras alternativas tales como los parámetros de calidad de servicio (QoS) establecidos en una activación de contexto de protocolo de datos de paquete (PDP) o contexto de PDP modificado. El campo QoS puede incluir además la “prioridad de retención de asignación de QoS (la unidad de datos de servicio podría usarse para inferir volúmenes de datos de tráfico)” en caso de que múltiples contextos PDP compartan la misma dirección APN o un perfil de suscripción para establecer el perfil de transición. Otras alternativas incluyen mensajes dedicados como el mensaje de indicación anterior para señalar un perfil de control de recursos e información como inhibir la duración y/o mensajes de indicación/solicitud máximos por valor de ventana de tiempo.

El perfil de transición incluido en el perfil de recursos de radio podría incluir además si el estado del UE debería ser transición en función del tipo de aplicación. Específicamente, si el equipo de usuario se está utilizando como módem de datos, se puede establecer una preferencia en el equipo de usuario para que no se envíen indicaciones de transición o si se mantiene el conocimiento de la preferencia en la red, que cualquier indicación de transición recibida del UE mientras se usa como módem de datos debe ignorarse. Por lo tanto, la naturaleza de las aplicaciones que se ejecutan en el equipo del usuario podría utilizarse como parte del perfil de recursos de radio.

Un parámetro adicional de un perfil de transición podría implicar el tipo de transición. Específicamente, en una red UMTS, el equipo del usuario puede preferir ingresar un estado Cell_PCH en lugar de ingresar un estado inactivo por diversas razones. Una razón podría ser que el UE necesita conectarse a un estado Cell_DCH más rápidamente si los datos necesitan ser enviados o recibidos, y así pasar a un estado Cell_PCH ahorrará algo de señalización de red y recursos de batería al tiempo que proporciona una transición rápida al estado Cell_DCH. Lo anterior es igualmente aplicable en redes no UMTS y puede proporcionar un perfil de transición entre diversos estados conectados e inactivos.

El perfil de transición también puede incluir diversos temporizadores que incluyen, pero no se limitan a, inhibir la duración y/ o mensajes de indicación/solicitud máximos por ventana de tiempo, temporizadores de retardo y temporizadores de inactividad. Los temporizadores de retardo proporcionan un período que el elemento de red esperará antes de pasar a un nuevo estado o modo. Como se apreciará, incluso si la aplicación ha estado inactiva durante un período de tiempo particular, un retraso puede ser beneficioso para garantizar que no se reciban ni transmitan más datos de la aplicación. Un temporizador de inactividad podría medir un período de tiempo predeterminado en el que una aplicación no recibe ni envía datos. Si se reciben datos antes de que expire el temporizador de inactividad, normalmente el temporizador de inactividad se reiniciará. Una vez que expira el temporizador de inactividad, el equipo de usuario puede enviar la indicación del paso 1810 a la red. Alternativamente, el equipo de usuario puede esperar un cierto período, tal como el definido para el temporizador de retraso, antes de enviar la indicación del paso 1810.

Además, el temporizador de retraso o la duración de inhibición y/o los mensajes de indicación/solicitud máximos por ventana de tiempo podrían variar en función de un perfil que se proporciona al elemento de red. Por lo tanto, si la aplicación que ha solicitado una transición a un modo o estado diferente es un primer tipo de aplicación, como una aplicación de correo electrónico, el temporizador de retraso en el elemento de red se puede configurar en un primer tiempo de retraso, mientras que, si la aplicación es de un segundo tipo, como una aplicación de mensajería instantánea, el temporizador de retraso puede establecerse en un segundo valor. Los valores de la duración de inhibición y/o los mensajes de indicación/solicitud máximos por ventana de tiempo, temporizador de retardo o temporizador de inactividad también podrían derivarse por la red en función del APN utilizado para un PDP particular.

Como apreciarán los expertos en la materia, el temporizador de inactividad podría variar de manera similar en función de la aplicación utilizada. Por lo tanto, una aplicación de correo electrónico puede tener un temporizador de inactividad más corto que una aplicación de navegador, ya que la aplicación de correo electrónico espera un mensaje discreto después del cual puede no recibir datos. Por el contrario, la aplicación del navegador puede utilizar datos incluso después de un retraso mayor y, por lo tanto, requiere un temporizador de inactividad más largo.

El perfil de transición puede incluir además una probabilidad de que un equipo de usuario sea correcto solicitando una transición. Esto podría basarse en estadísticas compiladas sobre la tasa de precisión de un equipo de usuario particular o aplicación en el equipo de usuario.

El perfil de transición puede incluir además diversos valores de tiempo de recepción discontinua (DRX). Además, se podría proporcionar un perfil de progresión para tiempos DRX en un perfil de transición.

El perfil de transición podría definirse sobre una base de aplicación por aplicación o ser un compuesto de las diversas aplicaciones en el equipo de usuario.

Como apreciarán los expertos en la materia, el perfil de transición podría crearse o modificarse dinámicamente cuando se asigna un recurso de radio y podría realizarse mediante suscripción, registro de PS, activación de PDP, activación de RAB o RB o cambio sobre la marcha para el PDP o RAB/RB. El perfil de transición también podría ser parte de la indicación del paso 1810. En este caso, la red puede considerar la indicación de estado RRC preferida para determinar si se permite la transición y a qué estado/modo. La modificación podría ocurrir en función de los recursos de red disponibles, patrones de tráfico, entre otros.

El perfil de recursos de radio por lo tanto está comprendido de campos estáticos y/o dinámicos. El perfil de recursos de radio utilizado por una red particular puede variar de otras redes y la divulgación anterior no pretende limitar el presente método y sistema. En particular, el perfil de recursos de radio podría incluir y excluir diversos elementos descritos anteriormente. Por ejemplo, en algunos casos, el perfil del recurso de radio simplemente incluirá la calidad del servicio para un recurso de radio en particular y no incluirá ninguna otra información. En otros casos, el perfil de recursos de radio incluirá solo el perfil de transición. Aún en otros casos, el perfil de recursos de radio incluirá toda la calidad del servicio, APN, contexto PDP, perfil de transición, entre otros.

Opcionalmente, además de un perfil de recursos de radio, el elemento de red también podría utilizar salvaguardas para evitar transiciones innecesarias. Dichas salvaguardas podrían incluir, entre otras, la cantidad de indicaciones recibidas en un período de tiempo predeterminado, la cantidad total de indicaciones recibidas, los patrones de tráfico y los datos históricos.

El número de indicaciones recibidas en un período de tiempo predeterminado podría indicar a la red que no debería producirse una transición. Por lo tanto, si el equipo del usuario ha enviado, por ejemplo, cinco indicaciones dentro de un período de tiempo de treinta segundos, la red puede considerar que debe ignorar las indicaciones y no realizar ninguna transición. Alternativamente, la red puede determinar indicar al UE que no debe enviar ninguna otra indicación, ya sea indefinidamente o durante un período de tiempo configurado o predefinido. Esto podría ser independiente de cualquier “duración de inhibición y/o mensajes máximos de indicación/solicitud por ventana de tiempo” en el UE.

Además, el UE podría configurarse para no enviar más indicaciones durante un período de tiempo configurado, predefinido o negociado. La configuración de UE podría ser exclusiva de las salvaguardas en el lado de la red descritas anteriormente.

Los patrones de tráfico y los datos históricos podrían proporcionar una indicación a la red de que no debería ocurrir una transición. Por ejemplo, si el usuario ha recibido una cantidad significativa de datos en el pasado entre las 8:30 y las 8:35 am de lunes a viernes, si la indicación se recibe a las 8:32 am del jueves, la red puede decidir que no debería hacer transición al equipo de usuario ya que es probable que haya más datos antes de las 8:35 a.m.

Si se asignan múltiples recursos de radio para el equipo de usuario, la red puede necesitar considerar el perfil completo de recursos de radio para el equipo de usuario. En este caso, se pueden examinar los perfiles de recursos de radio para cada recurso de radio y tomar una decisión de transición compuesta. De acuerdo con el perfil de recursos de radio de uno o múltiples recursos de radio, la red puede decidir si se debe hacer una transición o no.

Una limitación adicional en las indicaciones de transición

Como se describió anteriormente, hay diversos mecanismos por los cuales un UE puede haber hecho la transición a su estado RRC actual. El inicio de la transición puede haber sido impulsado completamente por la red, por ejemplo, como resultado de la inactividad observada. En este ejemplo, la red mantiene temporizadores de inactividad para cada uno de los estados de RRC. Si el temporizador de inactividad para el estado RRC actual del UE caduca, la red enviará un mensaje de reconfiguración RRC para hacer la transición del UE a un estado diferente. Alternativamente, el inicio de la transición puede haber sido impulsado por el UE utilizando un mecanismo de indicación de transición como se describe anteriormente (por ejemplo, con el uso de un mensaje de indicación de transición). Dado que la red tiene el control de la máquina de estado RRC, en este caso, el UE puede enviar una indicación a la red de que no necesita mantenerse en el estado RRC actual y está solicitando una transición a un estado RRC de menor consumo de batería.

En una realización, se pone una limitación a la capacidad del UE para transmitir una indicación de transición que es una función de si el UE experimentó o no la transición más reciente a su estado actual como resultado de una indicación de transición transmitida previamente por el UE.

En otra realización, el número de indicaciones de transición que el UE puede enviar en su estado actual es una función de si el UE experimentó o no la transición más reciente a su estado actual como resultado de una indicación de transición transmitida previamente por el UE.

En otra realización, el número de indicaciones de transición que el UE puede enviar en estados específicos está limitado independientemente de la manera en que el UE experimentó la transición más reciente a su estado actual donde el estado actual es uno de los estados específicos que esta limitación se aplica.

Inhibir cualquier otra indicación de transición después de un cambio de estado RRC de una indicación de transmisión transmitida previamente

En algunas realizaciones, si el UE está en su estado actual como resultado de haber transmitido previamente una indicación de transición, se inhibe que el UE transmita cualquier otra indicación de transición mientras está en este estado actual.

El UE puede mantener una bandera, señal de bit token u otro indicador que indique si el UE puede enviar indicaciones de transición a la red mientras permanece en su estado actual. Si la red reconfigura el UE a un nuevo estado RRC (por ejemplo, la red envía un mensaje de reconfiguración al UE para efectuar una transición al nuevo estado RRC) después de haber enviado una indicación de transición a la red, entonces esta bandera, bit token, u otro indicador se establece (o se borra alternativamente), lo que indica que el UE no tiene permitido enviar más indicaciones de transición mientras permanezca en este estado actual. Si el UE cambia el estado de RRC debido a una solicitud de transacción de datos por parte del UE (por ejemplo, porque su memoria intermedia muestra que tiene datos para enviar) o por la red (por ejemplo, porque la red ha notificado al UE), entonces este indicador se borra (o alternativamente configurado) para indicar que el UE puede nuevamente enviar una indicación de transición a la red.

Inhibir más de un número predeterminado de indicaciones de transición después de un cambio de estado RRC de una indicación de transición transmitida previamente

En algunas realizaciones, si el UE está en su estado actual como resultado de haber transmitido previamente una indicación de transición, se inhibe que el UE transmita más de un número máximo predeterminado de indicaciones de transición adicionales mientras la red mantiene el UE en este mismo estado actual. En algunas realizaciones, el número predeterminado está codificado en el UE. En otras realizaciones, la red configura el número predeterminado y está sujeto a cambios a medida que el UE se mueve entre diferentes redes. La configuración de la red puede tener lugar, por ejemplo, utilizando un mensaje de señalización directamente a la estación móvil, o como parte de un mensaje de difusión.

El UE mantiene una bandera, bit token, u otro indicador que indica si el UE puede enviar un número fijo de indicaciones de transición a la red mientras permanece en su estado actual. Si el UE ha realizado la transición a este estado actual como resultado de haber enviado una indicación de transición en un estado anterior, entonces se establecerá esta bandera, bit token u otro indicador. Si el UE ha realizado la transición a este estado actual como resultado de transiciones normales impulsadas por la red basada en temporizadores de inactividad, por ejemplo, entonces esta bandera, bit token, u otro indicador no se establecerá y no habrá restricciones en el número de indicaciones de transición que el UE puede enviar en su estado actual.

En el caso de que la bandera, bit token, o el indicador se establezca indicando que el UE solo puede enviar un número fijo de indicadores de transición a la red mientras permanece en este estado actual, el UE puede, además, mantener un contador que cuenta el número de indicaciones de transición que envía el UE después de haber determinado que acaba de pasar a su estado actual como resultado de una indicación de transición transmitida previamente.

En este ejemplo, si una vez en el estado actual, el UE posteriormente desea transmitir una indicación de transición desde este estado actual, primero mira la bandera, el bit token, u otro indicador para ver si tiene una limitación en el número de indicaciones de transición que puede enviar a la red mientras permanece en su estado actual. Si es limitado, el UE mantiene el recuento del número de indicaciones de transición que envía, siempre que la respuesta de la red al indicador de transición sea mover el UE a su estado RRC actual (en el caso en que el UE necesite hacer la transición a otro estado RRC enviar el mensaje de indicación de transición) o dejar el UE en su estado actual (en el caso en que el UE pueda enviar el indicador de transición en su estado actual).

Si cuando el UE compara el valor de su contador de indicación de transición con el número máximo predeterminado de otras indicaciones de transición permitidas (posiblemente indicadas por una bandera, bit token, u otro indicador), el valor del contador de indicación de transición es mayor que este número máximo predeterminado, entonces el UE no enviará posteriormente más indicaciones de transición a la red.

Si el resultado de una indicación de transición enviada por el UE es que el UE pasa a un estado RRC diferente de su estado actual (por ejemplo, un mensaje de reconfiguración enviado por la red) antes de enviar la indicación de transición, es decir más batería que el estado actual, el contador se reinicia y el proceso comienza nuevamente en el nuevo estado actual. Este sería el caso, por ejemplo, si el resultado final es que el UE se reconfigura de una PCH a CELL_FACH.

Si el UE cambia el estado de RRC debido a una solicitud de transacción de datos por parte del UE (por ejemplo, porque su memoria intermedia muestra que tiene datos para ser enviados) o por la red (por ejemplo, porque la red ha notificado el UE), entonces este indicador se borra (o se establece alternativamente) para indicar que una vez más se permite al UE enviar una indicación de transición a la red y se reinicia el contador.

Inhibir más de un número predeterminado de indicaciones de transición

En algunas realizaciones, se inhibe que el UE transmita más de un número predeterminado de indicaciones de transición mientras la red mantiene el UE en su mismo estado actual. En algunas realizaciones, el número predeterminado está codificado fijo en el UE. En otras realizaciones, la red configura el número predeterminado y está sujeto a cambios a medida que la estación móvil se mueve entre diferentes redes. La configuración de la red puede tener lugar, por ejemplo, utilizando un mensaje de señalización directamente a la estación móvil, o como parte de un mensaje de difusión.

El UE mantiene un contador que cuenta el número de indicaciones de transición que envía el UE después de su estado actual. Por lo tanto, al realizar la transición al estado actual, y el UE posteriormente desea transmitir una indicación de transición desde este estado actual, el UE mantiene el recuento del número de indicaciones de transición que envía, siempre que la respuesta de la red al indicador de transición sea devolver el UE a su estado actual de RRC (en el caso en que el UE necesita hacer la transición a otro estado de RRC para enviar el mensaje de indicación de transición) o dejar el UE en su estado actual (en el caso en que el UE pueda enviar el indicador de transición en su estado actual)

Si cuando el UE compara el valor de su contador de indicación de transición con el número máximo predeterminado de otras indicaciones de transición, el valor del contador de indicación de transición es mayor que este número máximo predeterminado, entonces el UE no enviará posteriormente más indicaciones de transición a la red.

Si el resultado de una indicación de transición enviada por el UE es que el UE se reconfigura a un estado RRC diferente de su estado actual antes de enviar la indicación de transición, y el estado RRC diferente consume más batería que el estado actual, entonces el contador se reinicia y el proceso comienza nuevamente en el nuevo estado actual.

Si el UE cambia el estado de RRC debido a una solicitud de transacción de datos por parte del UE (por ejemplo, porque su memoria intermedia muestra que tiene datos para ser enviados) o por la red (por ejemplo, porque la red ha notificado al UE), entonces este indicador se borra (o se establece alternativamente) para indicar que una vez más se permite al UE enviar una indicación de transición a la red y se reinicia el contador.

Si existe o no una transición de estado que resultó de haber transmitido previamente una indicación de transición se puede usar para habilitar/deshabilitar o limitar la transmisión adicional de indicaciones de transición de diversas maneras:

1) un prerrequisito para permitir la transmisión de una indicación de transición es que la transición de estado anterior no debe haber sido el resultado de que el UE haya transmitido previamente una indicación de transición. Este prerrequisito se puede combinar con otros prerrequisitos o inhibiciones de manera que la satisfacción del prerrequisito por sí solo no necesariamente permita que el UE transmita una indicación de transición

2) un prerrequisito para permitir la transmisión de una indicación de transición es que, si la transición de estado anterior fue el resultado de que el UE haya transmitido previamente una indicación de transición, el UE no ha transmitido más de un número definido de indicaciones de transición. Este prerrequisito se puede combinar con otros prerrequisitos o inhibiciones de manera que la satisfacción del prerrequisito por sí solo no necesariamente permita que el UE transmita una indicación de transición

3) si la transición de estado anterior fue el resultado de que el UE haya transmitido previamente una indicación de transición, inhibir la transmisión de una indicación de transición. Esto es lógicamente equivalente a 1) anterior. Esta inhibición puede combinarse con otros prerrequisitos o inhibiciones, como si la inhibición no se activara, eso por sí solo no necesariamente permite que el UE transmita una indicación de transición.

4) si la transición de estado anterior fue el resultado de que el UE haya transmitido previamente una indicación de transición, inhiba la transmisión de más de un número definido de indicaciones de transición. Esto es lógicamente equivalente a 2) anterior. Esta inhibición puede combinarse con otros prerrequisitos o inhibiciones, como si la inhibición no se activara, eso por sí solo no necesariamente permite que el UE transmita una indicación de transición.

5) si la transición de estado anterior no fue impulsada por UE, permitir la transmisión de una indicación de transición.

6) si la transición de estado anterior fue el resultado de que el UE haya transmitido previamente una indicación de transición, permitir la transmisión de solo hasta un número definido de indicaciones de transición.

7) para ciertos estados RRC, permitir la transmisión de solo hasta un número definido de indicaciones de transición. Interacción con el temporizador de inhibición

Como se indicó anteriormente, el prerrequisito o inhibición basado en la transición de estado puede combinarse con otros prerrequisitos o inhibiciones. Se han descrito anteriormente realizaciones que inhiben que un UE envíe una indicación de transición durante algún período de tiempo después de enviar previamente una indicación de transición. En algunas realizaciones, esta inhibición se combina con la inhibición/prerrequisito basado en la transición de estado descrito anteriormente.

Por ejemplo, el uso de un temporizador de inhibición se ha descrito previamente como un mecanismo para inhibir que el UE envíe una indicación de transición durante un período de tiempo después de enviar previamente una indicación de transición, en la que se inicia un temporizador de inhibición después de transmitir una indicación de transición, y al UE se le permite enviar una indicación de transición adicional solo si el temporizador de inhibición no está funcionando. En algunas realizaciones, el uso de este temporizador de inhibición se combina con la inhibición basada en la transición de estado de la siguiente manera:

¿transición de estado anterior el resultado de que el UE haya transmitido previamente una indicación de transición? inhibir la transmisión de la indicación de transición, o inhibir la transmisión de más de un número definido de indicaciones de transición posteriores a una transición previa que fue el resultado de que el UE haya transmitido previamente una indicación de transición; y

¿Está funcionando el temporizador de inhibición? inhibir la transmisión de la indicación de transición.

En algunas realizaciones, estas son las dos únicas inhibiciones en su lugar, en cuyo caso, el comportamiento se puede resumir de la siguiente manera:

permitir la transmisión de una indicación de transición si el temporizador de inhibición no está funcionando, y el estado actual no fue el resultado de una indicación de transición previa transmitida por el UE, o

permitir la transmisión de una indicación de transición si el temporizador de inhibición no está funcionando, y si se han transmitido menos de un número definido de indicaciones de transición posteriores a una transición de estado que fue el resultado de que el UE haya transmitido previamente una indicación de transición.

Mantenimiento de la causa de transición de estado previo

El UE tiene un mecanismo para mantener una indicación de si el estado actual es el resultado de la transmisión previa de una indicación de transición por parte del UE. Esta indicación puede ser un valor de causa de transición de estado anterior almacenado en una memoria en el UE al que puede acceder un procesador que forma parte del UE, o un interruptor implementado en hardware para nombrar algunos ejemplos. En un ejemplo específico, la causa de transición de estado anterior es un solo bit que es un primer valor (“1” o “0”) para indicar que la transición de estado anterior es el resultado de que el UE haya transmitido previamente una indicación de transición, y de lo contrario un segundo valor (“0” o “1”).

Evaluación de la causa de transición de estado previa

El UE tiene un mecanismo para determinar si el estado actual es el resultado de la transmisión previa de una indicación de transición por parte del UE.

Si el UE ha enviado la indicación de transición, y esto ha sido reconocido por la red para que el UE sepa que la red la recibió, entonces el UE puede saber que, si recibe un mensaje de reconfiguración de RRC dentro de un período de tiempo fijo, que este mensaje de configuración de RRC es el resultado del envío de la indicación de transición.

Si el UE recibe una reconfiguración de RRC y no ha enviado (y había reconocido) una indicación de transición dentro de un período predeterminado de tiempo que conduce hasta la reconfiguración, entonces el UE puede asumir que la transición de estado no fue en respuesta a la transmisión de una indicación de transición por el UE.

En un primer ejemplo, cada vez que ocurre una transición de estado como resultado de una reconfiguración por la red, el UE evalúa si la transición de estado fue el resultado de que el UE haya transmitido previamente una indicación de transición. Si este fuera el caso, el UE actualiza la causa de la transición de estado anterior para indicar que la transición de estado anterior fue impulsada por el UE. Si la transición de estado fue diferente al resultado de que el UE haya transmitido previamente una indicación de transición, entonces la causa de transición de estado anterior se actualiza en consecuencia.

En algunas realizaciones, donde se admite una transición con valor de causa, el UE determina si había enviado previamente una indicación de transición con un valor de causa para el cual este mecanismo debe implementarse antes de recibir esta reconfiguración.

En algunas realizaciones, el UE realiza los siguientes pasos para determinar si una transición de estado es el resultado de que el UE haya transmitido previamente una indicación de transición:

1) transmitir una indicación de transición (o una indicación de transición con un valor de causa particular);

2) si una transición de estado que es consistente con la indicación de transición se produce dentro de un intervalo de tiempo definido de transmisión de la indicación de transición, evaluar la transición de estado como el resultado de que el UE haya transmitido previamente una indicación de transición y, de lo contrario, evaluar la transición de estado a ser distinto del resultado de que el UE haya transmitido previamente una indicación de transición.

En algunas realizaciones, al transmitir una indicación de transición, se inicia un temporizador que comienza a contar en conteo regresivo en un valor de tiempo de espera, o equivalente que cuenta hasta un valor de tiempo de espera. Si el temporizador sigue funcionando cuando se produce la transición de estado, entonces se evalúa como el resultado de que el UE haya transmitido previamente una indicación de transición.

En algunas realizaciones, cualquiera de estas realizaciones se implementa usando una indicación de transición que incluye un código de causa para permitir que el UE especifique una causa para la indicación de transición (por ejemplo, para indicar que una transferencia de datos o llamada está completa, o que no se esperan más datos para un período prolongado). Un ejemplo específico es la SIGNALLING CONNECTION RELEASE INDICATION definida en 3GPP TS 25.331 Sección 8.1.14 donde el código de causa es la “Causa de indicación de liberación de conexión de señalización” de IE establecida en “Fin de sesión de datos de PS solicitada por el UE”.

En algunas realizaciones, cualquiera de estas realizaciones se implementa usando una indicación de transición que no incluye un código de causa. Un ejemplo específico es la SIGNALLING CONNECTION RELEASE INDICATION definida en 3GPP TS 25.331 Sección 8.1.14.

Ejemplo adicional de determinación del mecanismo para la transición de estado de RRC

Si el UE recibe un mensaje de reconfiguración RRC de la red, puede determinar si ha enviado un mensaje SCRI con el valor de causa “Fin de sesión de datos de PS solicitada por el UE” antes de recibir esta reconfiguración.

Si el UE ha enviado este mensaje, y el mensaje ha sido reconocido por la red para que el UE sepa que la red lo recibió, entonces el UE puede saber que, si recibe un mensaje de reconfiguración de RRC dentro de un período de tiempo fijo, que este mensaje de configuración de RRC es el resultado del envío del SCRI.

Si el UE está en el estado CELL_DCH o CELL_FACH RRC y ha enviado un SCRI que ha sido reconocido pero la red no envía una reconfiguración RRC dentro de un período de tiempo fijo, entonces el UE puede asumir que está actualmente en el estado que la red quiere que permanezca y el UE puede considerar que el mecanismo por el cual permanece en ese estado es para fines de latencia rápida.

Si el UE recibe una reconfiguración RRC y no ha enviado (y ha reconocido) un mensaje SCRI durante el período de tiempo fijo que condujo a la reconfiguración, entonces el UE puede asumir que la transición de estado no fue para fines de latencia rápida.

Ejemplos específicos

Con referencia al diagrama de estado de la Figura 1, suponga que un UE está inicialmente en el estado 122 Cell_DCH. Después de eso, el UE transmite una indicación de transición, por ejemplo, al determinar que no tiene más datos para enviar. En respuesta, la red reconoce la indicación de transición y hace la transición del UE a URA_PCH. En algunas realizaciones, esta es una transición de estado directo. En otras realizaciones, esta es una transición de estado indirecto a través del estado cell_FACH. Después de eso, el UE no puede enviar otra indicación de transición.

Tenga en cuenta que, en general, la descripción de las realizaciones y el comportamiento que pertenecen al estado URA_PCH también se aplican al estado CELL_PCH.

Si, por otro lado, la red decide por sí sola hacer la transición del UE a URA_PCH, por ejemplo, debido a la expiración de un temporizador de inactividad, el UE puede enviar una indicación de transición. En este punto, el UE busca pasar al modo IDLE desde URA_PCH. Sin embargo, el UE debe hacer la transición a CELL_FACH para enviar la indicación de transición. Recuerde que el propósito de la indicación de transición es que el UE se mueva a un estado con menos consumo de batería. Si la red deja el UE en CELL_FACH, esto no es una transición a un estado más eficiente de la batería (el único estado más eficiente de la batería de URA_PCH es inactivo) y, por lo tanto, el estado CELL_FACH no se considera como el resultado de una transmisión previa de una indicación de transición. Si la red transita el UE al modo URA_PCH o IDLE dentro de un período definido, entonces la transición de estado se considera como resultado de una transmisión previa de una indicación de transición.

Otra inhibición

En algunas realizaciones, si el UE ha enviado una indicación de transición que ha sido reconocida pero la red no envía una reconfiguración de RRC dentro de un período de tiempo fijo, entonces el UE supone que se encuentra actualmente en el estado en que la red desea que permanezca. En algunas realizaciones, cuando se produce esta secuencia de eventos, se inhibe que el UE transmita una indicación de transición, aunque el estado actual puede no ser necesariamente el resultado de que el UE haya transmitido previamente una indicación de transición.

En algunas realizaciones, la inhibición descrita anteriormente solo se implementa si el estado en el que permanece el UE es el estado CELL_DCH o CELL_FACH RRC.

Estado debido a (latencia rápida

En algunas realizaciones, cuando el UE está en un estado que es el resultado de una indicación de transición transmitida previamente, se dice que el UE está en un estado debido a la invocación de latencia rápida. En algunas realizaciones, cuando el UE ha transmitido una indicación de transición que se reconoce, pero el UE no sufre un cambio de estado, también se dice que el UE está en un estado debido a la invocación de latencia rápida.

Si el UE pasa a un estado RRC (que no es IDLE) y esto no fue debido a una indicación de transición (también conocida como una indicación de transición para fines de latencia rápida), entonces el UE usa el temporizador de inhibición para determinar cuándo está permitido enviar un indicador de transición para fines de latencia rápida. Este comportamiento se describe actualmente en 3GPP TS 25.331.

Si el UE pasa a un estado RRC (que no es IDLE) y esto se debió a una indicación de transición, entonces el UE tendrá diferentes restricciones en su comportamiento. El UE establecerá algún tipo de bandera o indicación internamente cuando sepa que está en esta situación. Esto se puede denominar, por ejemplo, el indicador FDM (Mecanismo de latencia rápida).

En un caso, el UE puede ser inhibido de enviar una indicación de transición adicional. Alternativamente, se puede permitir que el UE envíe solicitudes adicionales para una transición de estado, pero el número de solicitudes adicionales se limita a algún número definido, por ejemplo, uno o más. El período entre el envío de estas solicitudes está controlado por el temporizador de inhibición.

Si cuando el UE solicita una transición de estado utilizando la indicación de transición (y esto ha sido reconocido) la red deja el UE en su estado actual de RRC (por ejemplo, para CELL_FACH) o lo mueve de nuevo al estado de RRC desde el que envió el indicador de transición desde (por ejemplo, el UE estaba en CELL_PCH, se movió a CELL_FACH para enviar el SCRI, luego la red movió el UE de nuevo a CELL_PCH) y luego el UE disminuye el número de solicitudes de indicación de transición restantes que se le permite enviar.

Si el UE se mueve a un estado RRC diferente porque se inicia una transacción de datos (por ejemplo, recibe una notificación y está respondiendo a esto, o solicita recursos para una transacción de datos), entonces el UE borra la bandera FDM y el procedimiento se reinicia.

Si el UE hace una transición al estado CELL_FACH para transmitir un mensaje CELL_UPDATE o un mensaje URA_UPDATE y en el acuse de recibo de la red, el UE vuelve al estado CELL_PCH o URA_PCH, esto no borra la bandera FDM.

Sin embargo, si el UE realiza una transición al estado CELL_FACH para transmitir un mensaje CELL_UPDATE o un mensaje URA_UPDATE o un mensaje de indicación de transición, y la red posteriormente deja al UE en el estado CELL_FACH, entonces el UE borra la bandera FDM y el procedimiento reinicia

En algunos casos, se evita que el UE envíe por completo el mensaje SCR1 después de que el UE se transita a un estado RRC diferente en respuesta a una solicitud de latencia rápida usando el mensaje SCRI con el valor de causa “Fin de sesión de datos de PS solicitada por el UE”. En este caso, el UE establece la bandera FDM y solo borra esta bandera cuando se mueve a un estado RRC diferente para una transacción de datos iniciada por el UE o por la red.

En algunos casos, el UE solo tiene permitido un número máximo predefinido de mensajes de indicación de transición en ciertos estados predefinidos. El número puede ser diferente para diferentes estados. Por ejemplo, al UE solo se le puede permitir transmitir mensajes de indicación de transición “n” (con o sin el código de causa como se describe anteriormente) cuando se encuentra en los Estados CELL_PCH o URA_PCH RRC.

En algunas realizaciones, se proporcionan métodos y dispositivos que cumplen con el 3GPP TS 25.331 Sistema Universal de Telecomunicaciones Móviles (UMTS); Control de recursos de radio (RRC); la especificación de protocolo, Versión 8, o una evolución de la misma, con enmiendas para facilitar o implementar una o más de las realizaciones descritas en este documento. Se proporcionan ejemplos de esto en el Apéndice A, el Apéndice B y el Apéndice C. Todos estos ejemplos se refieren al uso del SCRI, pero en general se contempla el uso de cualquier indicación de transición.

En algunas realizaciones (véase el Apéndice A para una implementación de ejemplo), se define una variable de estado interno de UE que establece la primera vez que el UE desencadenó FD desde dentro del estado de PCH. Si se establece que el UE no puede activar FD nuevamente desde el estado PCH, la variable se restablece cuando llegan nuevos datos PS para la transmisión.

En algunas realizaciones (véase el Apéndice B para una implementación de ejemplo), se define un contador V316 y se establece inicialmente en cero. El UE en estado PCH se le permite activar el envío de una indicación de transición (como un SCRI) con causa si V316 <N316 (N316 es el valor máximo). Si el UE activa el envío de una indicación de transición (como un SCRI con valor de causa) en estado PCH, entonces se incrementa V316. V316 se restablece a cero si el UE es notificado en estado PCH o si el UE tiene datos PS de enlace ascendente disponibles para la transición.

Si N316 se fija en 1, entonces el comportamiento es equivalente a que V316 sea una variable de estado booleana. Tenga en cuenta que el UE que tiene datos PS disponibles para la transmisión excluye específicamente el envío de una indicación de transición (como SCRI con causa) y hace que el contador V316 se reinicie. En este contexto, el PS que tiene datos disponibles puede, por ejemplo, significar que el usuario tiene datos para transmitir en RB3 (portador de radio 3) o hacia arriba (el mensaje SCRI se envía en RB2).

Tenga en cuenta que la propuesta de texto en 8.3.1.2 (procedimiento de actualización de celda) y el párrafo final de 8.1.14.2 son formas alternativas de capturar la condición para restablecer V316.

En algunas realizaciones (véase el apéndice C para una implementación de ejemplo), se inhibe que el UE transmita una indicación de transición (tal como un SCRI con causa) si la red mueve el UE al estado PCH en respuesta a una indicación de transición (tal como SCRI con causa) transmitido por el UE mientras está en estado DCH o FACH. Para inhibir la indicación de transición (como el SCRI con causa) se puede configurar V316 en N316. El UE evalúa si el movimiento es instruido por la red “en respuesta” a la indicación de transición. Los mecanismos descritos anteriormente pueden usarse para esto; por ejemplo, el UE puede juzgar que este es el caso si la reconfiguración se recibe dentro de un cierto tiempo de envío de la indicación de transición.

En algunas realizaciones, se puede agregar una nueva bandera al mensaje de reconfiguración que se puede establecer en TRUE si el mensaje de reconfiguración se activa en la red al recibir un SCRI con causa, permitiendo así que el UE sepa con certeza la reconfiguración es en respuesta a la SCRI con causa. Un ejemplo de esto se representa en el Apéndice D.

Se han descrito muchas realizaciones diferentes para inhibir la transmisión de una indicación de transición, ya sea completamente, o hasta cierto número máximo de indicaciones de transición. Muchos de estos son una función de uno o más de:

si el estado actual del UE es el resultado de una transición de estado previa;

si el estado actual es el mismo que el estado del UE antes de enviar una transición de estado, si el estado actual consume más batería que el estado del UE antes de enviar una transición de estado.

En algunas realizaciones, un mecanismo para inhibir la transmisión de una indicación de transición se implementa, o no, por estado; en algunas realizaciones, para ciertos estados no se implementa ningún mecanismo. En otras realizaciones, se usa un mecanismo diferente para cada uno de al menos dos estados.

En una realización, la red tiene una pluralidad de opciones sobre cómo proceder cuando ha recibido una indicación en el paso 1810 y opcionalmente examinó el perfil o perfiles de recursos de radio en el paso 1820.

Una primera opción es no hacer nada. La red puede decidir que una transición no está garantizada y, por lo tanto, no aceptar la indicación del equipo del usuario para realizar la transición. Como apreciarán los expertos en la materia, no hacer nada ahorra señalización de red ya que el estado no cambia y, en particular, porque no se activa una transición.

Una segunda opción es cambiar el estado del dispositivo. Por ejemplo, en una red UMTS, el estado del dispositivo puede cambiar de Cell_DCH a Cell_PCH. En redes no UMTS, la transición de estado puede ocurrir entre estados conectados. Como apreciarán los expertos en la materia, los estados cambiantes reducen la cantidad de señalización de red central en comparación con una transición al modo inactivo. Cambiar el estado también puede ahorrar recursos de radio ya que el estado Cell_PCH no requiere un canal dedicado. Además, Cell_PCH tiene menos batería y permite que el UE conserve la energía de la batería.

Una tercera opción para la red es mantener el UE en el mismo estado, pero liberar los recursos de radio asociados con un contexto APN o PDP particular. Este enfoque ahorra recursos de radio y señalización ya que la conexión se mantiene en su estado actual y no es necesario restablecerla. Sin embargo, puede ser menos adecuado para situaciones en las que la vida útil de la batería del UE es una preocupación.

Una cuarta opción para la red es hacer la transición del UE a un modo inactivo. En particular, tanto en UMTS como no UMTS, la red puede pasar de un modo conectado a un modo inactivo. Como se apreciará, esto ahorra recursos de radio ya que no se mantiene ninguna conexión. Ésta ahorra aún más la vida de la batería en el equipo del usuario. Sin embargo, se requiere una mayor cantidad de señalización de red central para restablecer la conexión.

Una quinta opción para la red es cambiar una asignación de velocidad de datos, lo que ahorrará recursos de radio, permitiendo típicamente que más usuarios usen la red.

Otras opciones serían evidentes para los expertos en la materia.

La decisión de la red sobre cuál de las cinco o más opciones a utilizar variará de una red a otra. Algunas redes sobrecargadas pueden preferir preservar los recursos de radio y, por lo tanto, elegirían la tercera, cuarta o quinta opciones anteriores. Otras redes prefieren minimizar la señalización y, por lo tanto, pueden elegir la primera o segunda opción anterior.

La decisión se muestra en la Figura 18 en el paso 1830 y puede basarse en las preferencias de red junto con el perfil de recursos de radio para el equipo de usuario. La decisión se activa cuando la red recibe una indicación del equipo del usuario de que el equipo del usuario desea realizar la transición a otro estado, p. ej., en un estado menos intensivo de batería.

Ahora se hace referencia a la Figura 19. La Figura 19 ilustra el elemento de red simplificado adaptado para tomar las decisiones mostradas en la Figura 18 anterior. El elemento 1910 de red incluye un subsistema 1920 de comunicaciones adaptado para comunicarse con el equipo de usuario. Como apreciarán los expertos en la materia, el subsistema 1920 de comunicaciones no necesita comunicarse directamente con el equipo del usuario, pero podría ser parte de una ruta de comunicaciones para las comunicaciones hacia y desde el equipo del usuario.

El elemento 1910 de red incluye además un procesador 1930 y un almacenamiento 1940. El almacenamiento 1940 está adaptado para almacenar perfiles de recursos de radio preconfigurados o estáticos para cada equipo de usuario que recibe servicio del elemento 1910 de red. El procesador 1930 se adapta a, al recibir una indicación por el subsistema 1920 de comunicaciones, considerar el perfil de recursos de radio para el equipo del usuario y decidir una acción de red con respecto a la transición del equipo del usuario. Como apreciarán los expertos en la materia, la indicación recibida por el subsistema 1920 de comunicaciones podría incluir además una porción o la totalidad del perfil de recursos de radio para el equipo de usuario que luego sería utilizado por el procesador 1930 para tomar la decisión de red con respecto a cualquier transición.

Basado en lo anterior, un elemento de red por lo tanto recibe una indicación del equipo de usuario de que una transición podría estar en orden (como por ejemplo cuando se completa un intercambio de datos y/o que no se esperan más datos en el UE). De acuerdo con esta indicación, el elemento de red opcionalmente verifica el perfil de recursos de radio del equipo de usuario, que podría incluir elementos de perfiles tanto estáticos como dinámicos. El elemento de red puede verificar además las salvaguardas para garantizar que no se produzcan transiciones innecesarias. El elemento de red podría decidir no hacer nada o hacer la transición a un modo o estado diferente, o derribar un recurso de radio. Como se apreciará, esto proporciona a la red un mayor control de sus recursos de radio y permite que la red configure decisiones de transición basadas en las preferencias de la red en lugar de simplemente las preferencias del equipo del usuario. Además, en algunos casos, la red tiene más información que el dispositivo sobre la transición. Por ejemplo, el equipo del usuario tiene conocimiento de las comunicaciones en sentido ascendente y, en función de esto, puede decidir que la conexión se puede cortar. Sin embargo, la red puede haber recibido comunicaciones posteriores para el equipo del usuario y, por lo tanto, se dio cuenta de que no puede cortar la conexión. En este caso, también se puede introducir una demora utilizando el temporizador de demora para proporcionar a la red más certeza de que no se recibirán datos para el equipo del usuario en el futuro cercano.

Las realizaciones descritas en el presente documento son ejemplos de estructuras, sistemas o métodos que tienen elementos correspondientes a elementos de las técnicas de esta divulgación. Esta divulgación escrita puede permitir a los expertos en la materia hacer y usar realizaciones que tengan elementos alternativos que se correspondan igualmente con los elementos de las técnicas de esta divulgación. El alcance previsto de las técnicas de esta divulgación incluye, por lo tanto, otras estructuras, sistemas o métodos que no difieren de las técnicas de esta divulgación como se describe en este documento, e incluye además otras estructuras, sistemas o métodos con diferencias insustanciales de las técnicas de esta divulgación como se describen aquí.

Apéndice A

8.1.14 Procedimiento de indicación de liberación de conexión de señalización

Figura 8.1.14-1: Procedimiento de indicación de liberación de conexión de señalización, caso normal

8.1.14.1 General

El UE utiliza el procedimiento de indicación de liberación de la conexión de señalización para indicar a la UTRAN que se ha liberado una de sus conexiones de señalización. El procedimiento a su vez puede iniciar el procedimiento de liberación de la conexión de RRC.

8.1.14.2 Iniciación

El UE, al recibir una solicitud para liberar (abortar) la conexión de señalización de las capas superiores para un dominio CN específico:

1> if a signalling connection in tlie variable ESTABLISHEDSIGNALLINGCONNECTIONS for the specific CN domain identiñed with the IE "CN domain identity" exists:

2> initiate the signalling connection release indication procedure.

1> otherwise:

2> abort any ongoing establishment o f signalling connection for that spccific CN domain as specified in

8.1.3.5a. " ’

Al iniciar el procedimiento de indicación de liberación de la conexión de señalización en el estado CELL_PCH o URA_PCH, el UE deberá:

1> i f variable READY_FOR_COMMON_EDCH is set to TRUE:

2> move to CELL_FACH State;

2> restartthe timer T305 using its initial valué if periodical cell update has been configured by T305 in the IE

"UE Timers and constants in connected mode" set to any other valué than "infinity".

1> else:

2> if variable H RNT1 and variable C_RNTI are set:

3> continué with the signalling connection release indication procedure as below.

2> else:

3> perform a cell update procedure, according to subclause 8.3.1, using the cause "uplink data transmission";

3> when the cell update procedure completed successfully:

4> continué with the signalling connection release indication procedure as below.

El UE deberá:

1> set the IE "CN Domain Identity" to the valué indicated by the upper layers. The valué o f the IE indicates the CN domain whose associated signalling connection the upper layers are indicating to be released;

1> remove the signalling connection with the identity indicated by upper layers ffom the variable ESTABLISHED_SIGN ALLÍN G_CONNECTION S;

1> transmit a SIGNALLING CONNECTION RELEASE INDICATION message on DCCH using AM RLC.

Cuando el RLC confirma la entrega exitosa del mensaje SIGNALLING CONNECTION RELEASE INDICATION, el procedimiento finaliza.

Además, si el valor del temporizador T323 se almacena en el “Temporizadores y Constantes de UE en el Modo Conectado” del IE en la variable TIMERS_AND_CONSTANTS, y si no hay una conexión de dominio CS indicada en la variable ESTABLISHED_SIGNALLING_CONNECTIONS, el UE puede:

> if the upper layers indícate that there is no more PS data for a prolonged period:

2> if timer T323 is not running:

3> if the UE is in CELL DCH state or CELL FACH state; or

3> if the UE is in CELL PCH state or URA PCH state and "Triggered" in the variable TRIGGERED_SCRI_IN_PCH_STATE is FALSE:

4> if the UE is in CELL_PCH or URA_PCH state, set "Triggered" in the variable TRIGGERED_SCRI_IN_PCH_STATE to TRUE;

4> set the IE "CN Domain Identity" to PS domain;

4 set the IE "Signalling Connection Release Indication Cause" to "UE Requested PS Data session end";

4> transmit a SIGNALLINGCONNECTIONRELEASE INDICATIONmessage onDCCH

using AM RLC;

4> start the timer T323.

Cuando la entrega exitosa del mensaje SIGNALLING CONNECTION RELEASE INDICATION ha sido confirmada por RLC, el procedimiento finaliza.

Se impedirá que el UE envíe el mensaje SIGNALLING CONNECTION RELEASE INDICATION con la “Causa de Indicación de Liberación de Conexión de Señalización” del IE establecida en “Fin de Sesión de Datos de PS Solicitados por el UE” mientras el temporizador T323 está en funcionamiento.

Después de enviar el mensaje SIGNALLING CONNECTIO

CATION con el “Causa de Indicación de Liberación de Conexión de Señalización” del IE configurado en Finalizaci n de Sesión de Datos de PS Solicitada por el UE”, si los datos de PS están disponibles para transmisión, el UE establecerá “activado” en la variable TRIGGERED SCRI IN PCH STATE un FALSE.

8.1.14.2a Restablecimiento de RLC o cambio inter-RAT

Si se produce un restablecimiento del lado transmisor de la entidad RLC en la señalización del portador de radio RB2 antes de que el RLC haya confirmado con éxito la entrega del mensaje SIGNALLING CONN^eC^t ION RELEASE INDICATION, el UE deberá:

> retransmit the SIGNALLINGCONNECTIONRELEASE INDICATIONmessage onthe uplink DCCH using AM RLC on signalling radio bearer RB2.

Si se produce una transferencia Inter RAT del procedimiento UTRAN antes de que el RLC haya confirmado con éxito la entrega del mensaje SIGNALLING CONNECTION RELEASE INDICATION, el UE deberá:

1> abort the signalling connection while in the newRAT.

8.1.14.3 Recepción de la SIGNALLING CONNECTION RELEASE INDICATION por parte de la UTRAN

Al recibir un mensaje de SIGNALLING CONNECTION RELEASE INDICATION, si la “Causa de Indicación de Liberación de Conexión de Señalización” del IE no está incluida, la UTRAN solicita la liberación de la conexión de señalización desde las capas superiores. Las capas superiores pueden entonces iniciar la liberación de la conexión de señalización.

Si la “Causa de indicación de liberación de conexión de señalización” del IE se incluye en el mensaje SIGNALLING CONNECTION RELEASE INDICATION, la UTRAN puede iniciar una transición de estado al consumo de batería eficiente IDLE, CELL_PCH, URA_PCH o CELL_FACH.

8.1.14.4 Vencimiento del temporizador T323

Cuando expira el temporizador T323:

1> the UE may determine whelhcr any subsequent indications from upper layers ihat there is no more PS data for a prolonged period in whieh case it triggers the transmission o f a single SIGNALLING CONNECTION RELEASE INDICATION message according with clause 8,1.14.2;

1> the procedure ends.

13.4.27x TRIGGERED SCRI IN PCH STATE

Esta variable contiene información sobre si se ha activado un mensaje SIGNALLING CONNECTION RELEASE INDICATION en los estados CELL PCH o URA PCH. Hay una de esas variables en el UE.

Apéndice B

8.1.14 Procedimiento de indicación de liberación de conexión de señalización

Figura 8.1.14-1: Procedimiento de indicación de liberación de conexión de señalización, caso normal 8.1.14.1 General

El procedimiento de indicación de liberación de conexión de señalización es utilizado por el UE para indicar a la UTRAN que una de sus conexiones de señalización ha sido liberada. El procedimiento a su vez puede iniciar el procedimiento de liberación de la conexión de RRC.

8.1.14.2 Iniciación

El UE, al recibir una solicitud para liberar (abortar) la conexión de señalización de las capas superiores para un dominio CN específico:

1> i f a signalling connection in the variable ESTABLISHED SIGNALLlNG_CONNECTIONS for the specifíc CN domain identified with the IE "CN domain identity" exists:

2> initiate the signalling connection release indication procedure.

1> otherwise:

2> abort any ongoing establishment o f signalling connection for that specifíc CN domain as specifíed in

8.1.3.5a.

Al iniciarse el procedimiento de indicación de liberación de conexión de señalización en estado CELL_PCH o URA_PCH, el UE deberá:

1> i f variable READY_FOR_COMMON_EDCII is set to TRUE:

2> move to CELL_FACH State;

2> restart the timer T305 using its initial valué i f periodical cell updatc has been configured by T305 in tire IE

"UE Timers and constants in connected mode" set to any olher valué than "infinity".

1> else:

2> if variable H RNTI and variable C_RNTI are set:

3> continué with the signalling connection release indication procedure as below.

2> clse:

3> perform a cell update procedure, according to subclause 8.3.1, using the cause "uplink data transmission";

3> when the cell update procedure completed successfully:

4> continué with the signalling connection release indication procedure as below.

El UE deberá:

1> set the IE "CN Domain Identity’1 to the valué indicated by the upper layers. The valué o f the IE indicates the CN domain whose associated signalling connection the upper layers are indicating to be released;

1> remove the signalling connection with the identity indicated by upper layers frora the variable ESTABLISHED_SIGNALLING_CONNECTIONS;

1> transmit a SIGNALLING CONNECTION RELEASE INDICATION message on DCCH using AM RLC.

Cuando la entrega exitosa del mensaje SIGNALLING CONNECTION RELEASE INDICATION ha sido confirmada por RLC, el procedimiento finaliza.

Además, si el valor del temporizador T323 se almacena en los “Temporizadores y constantes de UE en modo conectado” del IE en la variable TIMERS_AND_CONSTANTS, y si no hay una conexión de dominio CS indicada en la variable ESTABLISHED_SIGNALLING_CONNECTIONS, el UE puede:

1> if the upper layers indícate that there is no more PS data for a prolonged period: 2> if timer T323 is not running:

3> if the

state

state: or

3> if the

state

state andV316<N316:

4> if the

state

6by1:

4> set the IE "CNDomain Identity" to PS domain;

4> set the IE "Signalling Connection Release Indication Cause" to "UE Requested PS Data

session end";

4> transmit a SIGNALLING CONNECTION RELEASE INDICATIONmessage onDCCH

using AM RLC;

4> start the timer T323.

Cuando la entrega exitosa del mensaje SIGNALLING CONNECTION RELEASE INDICATION ha sido confirmada por RLC, el procedimiento finaliza.

Se impedirá que el UE envíe el mensaje SIGNALLING CONNECTION RELEASE INDICATION con la “Causa de Indicación de Liberación de Conexión de Señalización” del IE establecido en la “Finalización de Sesión de Datos de PS solicitados por el UE” mientras el temporizador T323 está en funcionamiento.

Si los datos de PS están disponibles para la transmisión o el UE recibe un mensaje de búsqueda que activa el procedimiento de actualización de la celda, entonces el UE pasará V316 a cero.

8.1.14.2a Restablecimiento de RLC o cambio inter-RAT

Si se produce un restablecimiento del lado transmisor de la entidad de RLC en la señalización del portador de radio RB2 antes de que el RLC haya confirmado la entrega exitosa del mensaje SIGNALLING CONNECTION RELEASE INDICATION, el UE deberá:

> retransmit the SIGNALLING CONNECTION RELEASE INDICATIONmessage on theuplink DCCH using AM RLC on signalling radio bearer RB2.

Si se produce un traspaso inter-RAT desde el procedimiento UTRAN antes de que el RLC haya confirmado con éxito la entrega del mensaje SIGNALLING CONNECTION RELEASE INDICATION, el UE deberá:

1> abort the signalling connection while en el newRAT.

8.1.14.3 Recepción de la SIGNALLING CONNECTION RELEASE INDICATION por parte de la UTRAN

Al recibir un mensaje de SIGNALLING CONNECTION RELEASE INDICATION, si la “Causa de Indicación de Liberación de Conexión de Señalización” del IE no está incluida, la UTRAN solicita la liberación de la conexión de señalización desde las capas superiores. Las capas superiores pueden entonces iniciar la liberación de la conexión de señalización.

Si la “Causa de Indicación de Liberación de Conexión de Señalización” del IE se incluye en el mensaje SIGNALLING CONNECTION RELEASE INDICATION, la UTRAN puede iniciar una transición de estado al consumo de batería eficiente IDLE, CELL_PCH, URA_PCH o CELL_FACH.

8.1.14.4 Vencimiento del temporizador T323

Cuando caduca el temporizador T323:

1> the UE may determine whether any subsequent indications from upper layers that there is no more PS dala for a prolonged period in which case it triggers the transmission o f a single SIGNALLING CONNECTION RELEASE INDICATION message according with clause 8.1.142;

1> the procedure ends.

8.3 Procedimientos de movilidad de conexión RRC

8.3.1 Procedimientos de actualización de celda y URA

Figura 8.3.1-2: procedimiento de actualización de celda con actualización de información de movilidad de UTRAN

Figura 8.3.1-3: Procedimiento de actualización de Celda con reconfiguración de canal físico

Figura 8.3.1-4: procedimiento de actualización de celda con reconfiguración de canal de transporte

Figura 8.3.1-5: Procedimiento de actualización de celdas con liberación de portador de radio

Figura 8.3.1-6: Procedimiento de actualización celular con reconfiguración de portador de radio

Figura 8.3.1-6a: Procedimiento de actualización celular con configuración de portador de radio

Figura 8.3.1-8: Procedimiento de actualización de URA, flujo básico

Figura 8.3.1-9: Procedimiento de actualización de URA con actualización de información de movilidad de UTRAN

8.3.1.1 General

Los procedimientos de actualización de celdas y actualización de URA sirven para varios propósitos principales: - notificar a UTRAN después de volver a ingresar al área de servicio en el estado URA_PCH o CELL_PCH;

- notificar a UTRAN de un error irrecuperable de RLC [16] en una entidad RLC AM;

- ser utilizado como mecanismo de supervisión en el estado CELL_FACH, CELL_PCH o URA_PCH mediante actualización periódica.

Además, el procedimiento de actualización de URA también sirve para el siguiente propósito:

- recuperar una nueva identidad de URA después de la reselección de celda a una celda que no pertenece a la URA actual asignada al UE en estado URA_PCH.

Además, el procedimiento de actualización celular también sirve para los siguientes propósitos:

- actualizar UTRAN con la celda actual en la que el UE está conectando después de la reselección de la celda; - actuar sobre un fallo de enlace de radio en el estado CELL_DCH;

- actuar sobre el fallo de transmisión del mensaje de UE CAPABILITY INFORMATION;

- para FDD y 1.28 Mcps TDD, si la variable H_RNTI no está establecida, y para 3.84 Mcps TDD y 7.68 Mcps TDD: cuando se activa en el estado URA_PCH o CELL_PCH, para notificar a UTRAN de una transición al estado CELL_FACH debido a la recepción de Paginación originada por UTRAN o debido a una solicitud para transmitir datos de enlace ascendente;

- contar el número de UE en URA_PCH, CELL_PCH y CELL_FACH que están interesados en recibir una transmisión MBMS;

- cuando se activa en el estado URA_PCH, CELL_PCH y CELL_FACH, notificar a UTRAN del interés del UE para recibir un servicio MBMS;

- solicitar la configuración MBMS P-T-P RB por el UE en los estados CELL_PCH, URA_PCH y CELL_FACH.

La actualización de URA y los procedimientos de actualización celular pueden:

1> inelude an updatc o f mobiíity related information in the UE;

1> cause a State transition from the CELLJFACH State to the C E L L D C H , C EL L PC H or URA_PCH States or idle mode.

El procedimiento de actualización celular también puede incluir:

- un restablecimiento de las entidades AM RLC;

- liberación de portador de radio, reconfiguración de portador de radio, reconfiguración de canal de transporte o reconfiguración de canal físico.

8.3.1.2 Iniciación

Un UE iniciará el procedimiento de actualización celular en los siguientes casos:

1> Uplink data transmission:

2> for FDD and 1.28 Mcps TDD, if the variable H_RNTI is not set, and for 3.84 Mcps TDD and 7.68 Mcps TDD:

3> if the UE is in URA PCH or CELL PCH State; and

3> i f timer T320 is not running:

4> if the UE has uplink RLC data PDU or uplink RLC control PDU on RB1 or upwards to transmit: 5> perform cell update using the cause "uplink data tr ansmission''.

3> else:

4> i f the variable ESTABLISHMENT.CAUSE is set:

5> perform cell update using the cause "uplink data transmission”.

1> Paging response:

2> if the criteria for performing cell update with the cause specifíed above in the current subclause are not met;

and

2> if the UF, in IJRA_PCH or CELL_PCH State, receives a PAGINO TYPE 1 message fulfilling the condítions for initiating a cell update procedure spccified in subclause 8.1.2.3:

3> perform cell update using the cause "paging response'1.

> Radio link failure:

2> i f none o f the criteria for performing cell update with the causes specified above in the current subclause is met:

3> i f the UE is in CELL_DCH state and the criteria for radio link failure are met as specified in subclause 8.5.6; or

3> if the transmission o f the UE CAPABILITY INFORMATION message fails as specified in subclause 8^.1^.6^.6^:

4> perform cell update using the cause "radio link failure".

> MBMS ptp RB requcst:

2> i f none o f the criteria for performing cell update with the causes specified above in the current subclause is met; and

2> if the UE is in URA_PCH, Cell_PCH or Cell_FACH State; and

2> i f limer T320 is not running; and

2> i f the UE should perform cell update for MBMS ptp radio bearer request as specified in subclause 8.6.9.6:

3> perform cell update using the cause "MBMS ptp RB request".

> Re-entering scrvice area:

2> if none o f the criteria for performing cell update with the causes specified above in lhc current subclause is met; and

2> i f lhc UE is in CELL_FACH or CELL_PCH state; and

2> i f the UE has been out o f service area and rc-cnters Service area before T307 or T 317 expires:

3> perform cell update using the cause "re-entering Service area".

> RLC unrecoverable error:

2> i f none o f the criteria for performing cell update with the causes specified above in the current subclause is met; and

2> if the UE deteets RLC unrecoverable error [16] in an AM RLC entity:

3> perform cell update using the cause "RLC unrecoverable error",

> Cell reselection:

2> i f none o f the criteria for performing cell update with the causes specified above in the current subclause is met:

3> if the UE is in CELL_FACI I or CELL PCH state and the UE performs cell re-selection; or

3> i f the UE is in CELL_FACH state and the variable C_RNTI is empty:

4> perform cell update using the cause "cell reselection".

> Periodical cell update:

2> if noce o f the criteria for perfonning cell update with the causes specifíed above ín the currcnt subclause is met; and

2> if the UE is in CELL_FACH or CELL PCII State; and

2> if tlie timer T305 expires; and

2> i f the criteria for "in Service area" as specifíed in subclause 8.5.5.2 are fulfillcd; and

2> if periodic updating has been configurad by T305 in the IE "UE Timers and constants in connected raode" set to any other valué than "infinity":

3> for FDD:

4> if the variable C O M M O N _E _D C H .T R A N SM ISIO N is set lo FALSE:

5> perform cell update using the cause "periodieal cell update".

4> else:

5> restart the timer T305;

5> and end the procedure.

3> for 1.28 Mcps TDD and 3.84/7.68 Mcps TDD:

4> perform cell update using the cause "periodieal cell update".

1> MBMS reception;

2> if none o f the criteria for performing cell update with the causes specifíed above in the current subclause is met; and

2> if the UE is in U R A P C II, Cell_PCH or Ccll_FACH state; and

2> if the UE should perform cell update for MBMS counting as specifíed in subclause 8.7.4:

3> perform cell update using the cause "MBMS reception".

Un UE en estado URA_PCH iniciará el procedimiento de actualización de URA en los siguientes casos:

1> URA reselection:

2> if the UE deteets that the current URA assigned to the UE, stored in the variable URAIDEN TITY , is not present in the list o f URA identities in system information block type 2; or

2> if the list o f URA identities in system information block type 2 is empty; or

2> i f the system information block type 2 can not be found:

3> perform URA update using the cause "change o f URA".

i> Periodic URA update:

2> if the criteria for performing URA update with the causes as specifíed above in the current subclause are not met:

3> i f the timer T305 expires and if periodic updating has been confígured by T305 in the IE "UE Timers and constants in connected mode" set to any other valué than "infinity"; or

3> i f the condilions for initiating an URA update procedure specifíed in subclause 8.1.1.6.5 are fullfilled: 4> perform URA update using the cause "periodic URA update".

Al iniciar el procedimiento de actualización de celda o actualización de URA, el UE deberá:

1> if the UE has uplink RLC data PDU or uplink RLC control PDU on RB3 or unvvards to transmití or > if tlie UE received a PAGINO TYPE 1 messaue fulfilling the conditions for initiating a cell updalc procedure snecified in subclause 8,1.2.3:

2> set the counter V 316 to zero.

> if timer T320 is running:

2> stop timer T320;

2 > ifthe UE has uplink RLC data PDU or uplink RLC control PDU on RD1 or upwards to transmit:

3> perform cell update using the cause "uplink data transmission".

2> else:

3> ifthe cell update procedure is not triggered due to Paging response or Radio link failure; and

3> if the UE should perform cell update for MBMS ptp radio bearer request as specitíed in subclause 8.6.9.6: 4> perform cell update using the cause "MBMS ptp RB request".

> stop timer T319 if it is running;

> stop timer T305;

> for FDD and 1.28 Mcps TDD:

2> if the UE is in CELL FACH State; and

2> ifthe IF. "HS-DSCH common system information" is included in System Information Blocktype 5 or System Information Block type 5bis; and

2> for 1.28 Mcps TDD, if IE "Common E-DCH system info" in System Information Block type 5; and 2> if the UE does support HS-DSCH reception in CELL_FACH State:

3> if variable H_RNTI is not set or variable C RNT1 is not set:

4> clear variable H_RNTI;

4> clear variable C_RNTI;

4> clear any stored IEs "HARQ info";

4> set variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED to TRUE;

4> and start receiving the HS-DSCII transport channels mapped physical channel(s) o f type FIS-SCCH and HS-PDSCH, by using parameters given by the IE(s) "IIS-DSCH common system information" according to the procedure in subclause 8.5.37.

3> else:

4> receive the HS-DSCH transport channels mapped physical channel(s) o f type IIS-SCCH and HS-PDSCH, by using parameters given by the IE(s) "HS-DSCH common system information" according tothe procedure in subclause 8.5.36;

4> determine the valué for the IISPA_RNTT_STORED_CELL PCII variable and take the corresponding actions as described in subclause 8.5.56;

4> determine the valué for the READY_FOR_COMMON_EDCH variable and take the corresponding actions as described in subclause 8.5.47;

4> determ ine the va lu é for the C O M M O N _E _D C H _T R A N SM ISS IO N variable and take the corresponding actions as described in subclause 8.5.46;

4> ¡f variable READY_FOR COMMON_EDCH is set to TRÜE:

5> configure the Enhanced Uplink in CELLFACH State and Idle modc as specified in subclause 8.5.45 for FDD and 8.5.45a for 1.28 Meps TDD.

> if the UE is in CELL_DCH State:

2> in the variable RB TIMHR INDICATOR, set the IE "T314 expired" and the IE "T315 expired" to FALSE; 2> if the stored valúes o f the timer T314 and timer T 315 are both equal to zero; or

2> if tile stored valué o f the timer T 314 is equal to zero and there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHEDJRABS the valué o f the IE "Re-establishment timer" is set to "useT315" and signalling connection exists only to the CS domain:

3> release all its radio resources;

3> indícate release (abort) o f the established signalling connections (as stored in the variable ESTABLISHED_SIGNALL1NG CONNECTIONS) and established radio access bearers (as stored in the variable ESTABLISHEDRABS) to uppcr layers;

3> clearthe variable ESTABLISHEDSIGNALLINGCONNECTIONS;

3> clear the variable ESTABLISHED_RABS;

3> enter idle mode;

3> perform other actions when entering idle mode from connected modc as specified in subclause 8.5.2; 3> and the proccdure ends.

2> if the stored valué o f the timer T 314 is equal to zero:

3> release all radio bearers, associated with any radio access bearers for which in the variable ESTABLISHED RABS the valué ofthe IE "Re-establishment timer" is setto "useT314";

3> in the variable RB TIMER_1NDÍCAT0R set the IE "T314 expired" to TRUE;

3> if all radio access bearers associated with a CN domain are released:

4> release the signalling connection for that CN domain;

4> remove the signalling connection for that CN domain from the variable ESTABLISHED_SIGNALLING_CONNBCTIONS;

4> indícate release (abort) o f the signalling connection to upper layers;

2> if the stored valué o f the timer T 315 is equal to zero:

3> release all radio bearers associated with any radio access bearers for which in the variable ESTABLISHED RABS the valué ofthe IE "Re-establishmenttimer" is setto "useT315";

3> in the variable RB_TIMER_INDICATOR set the IE "T315 expired" to TRUE.

3> if all radio access bearers associated with a CN domain are released:

4> release the signalling connection for that CN domain;

4> remove the signalling connection for that CN domain from the variable F.STABLISHED_SIGNALLING_CONNECTIONS;

4> indícate release (abort) o f the signalling connection to upper layers;

2> if the stored valué o f the timer T 314 is greater than zero:

3> i f there are radio bearers associated witii any radio access bearers for which in the variable ESTABL1SHED_RABS the valué o f the IE "Re-establishment timer1' is set to "useT314":

4> start timer T 314.

3> i f there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED RABS the valué o f the IE "Re-cstablishment timer" is sel to "useT314" or "useT315" and the signalling connection exists to the CS domain:

4> start timer T 314.

> if the stored valué o f the timer T 315 is greater than zero:

3> i f there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the valué o f the IE "Re-establishment timer" is set to "useT315"; or

3> if the signalling connection exists to the PS domain:

4> start timer T 315.

> for the released radio bearer(s):

3> delete the information about the radio bearer from the variable ESTABI,1SHED_RABS;

3> when all radio bearers belonging to the same radio access bearer have been released:

4> indícate local end release o f the radio access bearer to upper layers using the CN domain identity together with the RAB identity stored in the variable ESTABLISHED RABS;

4> delete all information about the radio access bearer from the variable ESTABLISHED_RABS. > if the variable EJDC H TR AN SM ISSIO N is set to TRUE:

3> set tire variable E_DCH_TRANSMISSION to FALSE;

3> stop any E-AGCH and E-HICH reception procedures;

3> for FDD, stop any E-RGCH reception procedures.

3> for FDD, stop any E-DPCCH and E-DPDCH transmission procedures.

3> for 1.28 Mcps TDD, stop any E-PUCH transmission procedure.

3> clcar the variable E RNTI;

3> act as i f the IE "MAC-es/e reset indicator" was received and set to TRUE;

3> release all E-DCH HARQ resources;

3> no longer consider any radio link to be the serving E-DCH radio link.

> move to CELL_FACH State;

> select a suitable UTRA cell on the current ffequeney accordmg to [4];

> clear variable E_RNTI and:

3> determine the valué for the HSPA_RNTI_STORED_CELL_PCH variable and take the coiresponding aetions as described in subclause 8.5.56;

3> determine the valué for the READY_FOR_COMMOM_EDCH variable and take the corresponding aetions as described in subclause 8.5.47;

3 > determ ine the v a lú e for th e C O M M O N E _ D C H _ T R A N S M IS S 1 O N variab le and take the corresp on d in g aetion s as descr ib ed in su b c la u se 8.5.46.

2> for 3.84 Mcps TDD and 7.68Mcps TDD; or

2> for FDD and 1.28 Mcps TDD, if'the UE does not support HS-DSCH reception in CELLJFACH State; or 2> i f the IE "HS-DSCH common system information" is not included in System Information Block type 5 or System Information Block type 5bis; or

2> for 1.28 Mcps TDD, if the IE "Common E-DCH system info" is not included in System Information Block type 5:

3> select PRACH accordingto subclause 8.5.17;

3> select Secondary CCPCH according to subclause 8.5.19;

3> use the transport format set given in system information as specified in subclause 8.6.5.1;

3> take the actions related to the HS_DSCH RECEPTION_G ENERAL variable as described in subclause 8.5.37a.

2> else:

3> if variable READY_FOR_COMMON_EDCH is set to TRUE:

4> configure the Enhanced Uplink in CELL_FACH State and Idle mode as specified in subclause 8.5.45.

3> else:

4> select PRACH according to subclause 8,5.17 and;

5> use for the PRACH the transport format set given in system information as specified in subclause 8.6.5,1. "

3> clear variable H_RNTI;

3> clear any stored lEs "HARQ info";

3> reset the MAC-ehs entity [15];

3> set variable IIS_DSCII_RECEPTION_ OF_ CCCH_ENABLED to TRUE;

3> and start receiving the HS-DSCH according to the procedure in subclause 8.5.37.

2> set the variable ORDEREDRECONFIGURATION to FALSE.

> set the variables PROTOCOL_ERROR INDICATOR, FAILURE_INDICATOR, UNSUPPORTED_CONFIGURATION and INVALID_CONFIGURATION to FALSE;

> set the variable CELL_UPDATE_STARTED to TRUE;

> if any IEs releated to HS-DSCHare stored in the UE:

2> clear any stored IE "Downlink HS-PDSCH information";

2> clear any stored IE "Downlink Secondaiy Cell Info FDD";

2> clear all the entries from the variable TARGET_CELL_PRECONFIGURATION;

2> for 1.28Mcps TDD, clear the IE "HS-PDSCH Midamble Configuradon" and the IE "HS-SCCII Set Configuration" in the IE "DL Multi Carrier Information";

2> determine the valué for the HS _DSCH_RECEPTION variable and take the corresponding actions as described in subclause 8.5.25;

2 > determ ine the va lu é for the S E C O N D A R Y C E L L _H S _D SC H _R E C E P T IO N variab le and take the correspon d ing actions as describ ed in su bclau se 8.5.51.

> if any IEs related to E-DCH are stored iii the UE:

2> clear any stored IE "E-DCH info";

2> determine the valué for the E D C H TR A N SM ISSIO N variable and take the corresponding actions as described in subclause 8.5.28.

> if any o f the IEs "DTX-DRX timing information" or "DTX-DRX information'1 are stored in the UE:

2> determine the valúe for the DTX_DRX_STATUS variable and take the corresponding actions as described in subclause 8.5.34.

> if the IE "HS-SCCII less information" is stored in the UE:

2> determine the valué for the HS_SCCH_LESS_STATUS variable and take the corresponding actions as described in subclause 8.5.35.

> if any IEs related to MIMO are stored in the UE:

2> determine the valué for the MIMOJSTATUS variable and take the corresponding actions as described in subclause 8,5.33.

> for 1.28 Mcps TDD, if the IEs "Control Channel DRX Information" is stored in the UE:

2> determine the valué for the CONTROL_CHANNEL_DRX_STATUS variable and take the corresponding actions as described in subclause 8.5.53.

> for 1.28 Mcps TDD, if the IE "SPS information" is stored in the UE:

2> determine the valué for the E_DCH_SPS_STATUS variable and take the corresponding actions as described in subclause 8.5.54;

2> determine the valué for the HS_DSCH_SPS_ STATUS variable and take the corresponding actions as described in subclause 8.5.55.

> if the UE is not already in CELL FACH State:

2> move to CELL_FACH State;

2> determine the valué for the HSPA_RNTI_STORED_CELL_PCH variable and take the corresponding actions as described in subclause 8.5.56;

2> determine the valué for the READY_FOR_COMMON_EDCH variable and take the corresponding actions as described in subclause 8.5.47; ' 2> detennine the valué for the COMMON_E_DCH_TRANSMISSION variable and take the corresponding actions as described in subclause 8.5.46;

2> for 3.84 Mcps TDD and 7.68 Mcps TDD; or

2> for FDD and 1.28 Mcps TDD, if the UE does not support HS-DSCH reception in CELL_FACH State; or 2> i f the IE "HS-DSCH common System information" is not included in System Information Block type 5 or System Information Block type 5bis; or

2> for 1.28 Mcps TDD, if the IE "Common E-DCH system info” is not included in System Information Block type 5:

3> select PRACH according to subclause 8.5.17;

3> select Secondary CCPCH according to subclause 8.5.19;

3 > use the transport form at set g iv en in system inform ation as sp ec iñ ed in subclause 8.6.5.1 ;

3> take the actions related to the HS_DSCH_RECEPTION_GENERAL variable as described in subclause 8.5.37a.

2> else:

3> if variable READY_FOR_COMMON_EDCH is set to TRUE:

4> configure the Enhanced Uplink in CELL FACII State and Idle mode as specified in subclause 8.5.45.

3> else:

4> select PRACH according to subclause 8.5.17 and:

5> use for the PRACH the transport format sel given in system informalion as specified in subclause 8.6.5.1. ^ ’

3> if variable H_RNTI is not set or variable C_RNTI is not set:

4> clear variable C RNTI;

4> clear variable H_RNTI;

4> clear any stored IEs "HARQ info";

4> set variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED to TRUE;

4> and start receiving the HS-DSCII according to the procedure in subclause 8.5.37.

3> else:

4> receive the HS-DSCH according to the procedure in subclause 8.5.36.

> if the UE perfonns cell re-selection:

2> clear the variable CJRNTI; and

2> stop using that C RNTI just cleared from the variable C RNTI in MAC;

2> for FDD and 1.28 Mcps TDD, if the variable H_RNTI is set:

3> clear the variable H RNTI; and

3> stop using that H_RNTI just cleared from the variable H_RNT1 in MAC;

3> clear any stored IEs "HARQ info";

2> for FDD and 1.28 Mcps TDD, if the variable E RNT1 is set:

3> clear the variable E_ RNTI.

2> determine the valué for the HSPA_RNTI_STORED_CELL_PCH variable and take the corresponding actions as described in subclause 8.5.56;

2> determine the valué for the RBADY_FOR_COMMON_EDCH variable and take the corresponding actions as described in subclause 8.5.47;

2> determine the valué for the C O M M O N E D C H T R A N SM ISSIO N variable and take the corresponding actions as described in subclause 8.5.46;

2> for FDD and 1.28 Mcps TDD, if the UE does support HS-DSCH reception in CELL_FACII State and IE "HS-DSCH corrunon system information" is included in System Information Block type 5 or System Information Block type 5bis:

3> reset the MAC-ehs entity [15j.

3> set variable HS_ DSCH_RECEPTION_OF_CCCH_ENABLED to TRUE;

3> and start receiving the HS-DSCH according to thc procedure in subclause 8,5.37.

2> else:

3> take the actions related to the HS_DSCH_RECEPTION_GENERAL variable as described in subclause 8.5.37a.

1> set CFN in relationto SFN o f current cell according to subclause 8.5.15;

1> in case o f a cell update procedure:

2> set the contents o f the CELL UPDATE message according to subclause 8.3.1.3;

2> submit the CELL UPDATE message for transmission on the uplink CCCH.

1> in case o f a URA update procedure:

2> set the contents o f the URA UPDATE message according to subclause 8.3.1.3;

2> submit the URA UPDATE message for transmission on the uplink CCCFI.

1> set counter V302 to 1;

1> start timer T302 when the MAC layer indicates success or failure in transmitting the message,

10.3.3.43 Temporizadores y constantes de UE en modo conectado

Este elemento de información especifica los valores constantes y de temporizador utilizados por el UE en modo conectado.

13.4.27xTRIGGERED SCRI IN PCH STATE

Esta variable contiene información sobre si un mensaje SIGNALLING CONNECTION RELEASE INDICATION se ha activado en estados CELL PCH o URA PCH. Hay una de esas variables en el UE.

13.2 Contadores para UE

13.3 Constantes y parámetros de UE

13.2 Contadores para UE

13.3 Constantes y parámetros de UE

Apéndice C

8.1.14 Procedimiento de indicación de liberación de conexión de señalización

Figura 8.1.14-1: Procedimiento de liberación de conexión de señalización, caso normal 8.1.14.1 General

El UE utiliza el procedimiento de indicación de liberación de conexión de señalización para indicar a la UTRAN que una de sus conexiones de señalización ha sido liberada. El procedimiento a su vez puede iniciar el procedimiento de liberación de la conexión RRC.

8.1.14.2 Iniciación

Al recibir una solicitud para liberar (abortar) la conexión de señalización desde las capas superiores para un dominio CN específico, el UE deberá:

1> if a signalling connection in the variable ESTABLISHED_SIGNALLlNG_CONNECTIONS for the specific CN domain identified with the IE "CN domain identity" exists:

2> initiate the signalling connection relcase indication procedure,

1> otherwise:

2> abort any ongoing establishment o f signalling connection for that specific CN domain as specified in

8.1.3.5a. ' ’

Al iniciarse el procedimiento de indicación de liberación de conexión de señalización en estado CELL_PCH o URA_PCH, el UE deberá:

1> if variable READY_FOR_COMMON_EDCH is set to TRUE:

2> m ove to CELL_FACH State;

2> restart the timer T305 using its initial valué if periodical cell update has been configured by T305 in the IE

"UE Timers and constants in connccted mode" set to any oihcr valué than "infínity’'.

1> else:

2> i f variable H_RNTI and variable C_RNTI are set:

3> continué with the signalling connection release indication procedure as below.

2> else:

3> perform a cell update procedure, according to subclause 8.3.1, using the cause "uplink data transmission";

3> when the cell update procedure completed successñilly:

4> continué with the signalling connection release indication procedure as below.

El UE deberá:

1> set the IE "CN Domain Identity" to the valué indicated by the upper layers. The valué o f the IE indicates the CN domain whose associated signalling connection the upper layers are indicating to be released;

1> remove the signalling connection with the identity indicated by upper layers ffom the variable ESTABLISHED_SIGNALLING_CONNECTIONS;

1> transmit a SIGNALLING CONNECTION RELEASE INDICATION message on DCCH using AM RLC.

Cuando la entrega exitosa del mensaje SIGNALLING CONNECTION RELEASE INDICATION ha sido confirmada por RLC, el procedimiento finaliza.

Además, si el valor del temporizador T323 se almacena en el IE “Temporizadores y constantes de UE en modo conectado” en la variable TIMERS_AND_CONSTANTS, y si no hay una conexión de dominio CS indicada en la variable ESTABLISHED_SIGNALLING_CONNECTIONS, el UE puede:

1> if the upper layers indícate that there is no more PS data for a prolonged period: > if timer T323 is not running:

3> if the UE is in CELL DCH state or CELL FACH state: or

3> if the UE is in CELL PCH state or URA PCH state and V316 <N316:

4> if the UE is in CELL_PCH or URA_PCH state increment V316 by 1:

4> set the IE "CN Domain Identity" to PS domain;

4> set the IE "Signalling Connection Release Indication Cause" to "UE Requested PS Data

session end";

4> transmit a SIGNALLING CONNECTION RELEASE INDICATION message on DCCH

using AM RLC;

4> start the timer T323.

Cuando la entrega exitosa del mensaje SIGNALLING CONNECTION RELEASE INDICATION ha sido confirmada por RLC, el procedimiento finaliza.

Se impedirá que el UE envíe el mensaje SIGNALLING CONNECTION RELEASE INDICATION con la “Causa de indicación de liberación de conexión de señalización” del IE establecido en “Fin de sesión de datos de PS solicitada por el UE” mientras el temporizador T323 está en funcionamiento.

Si los datos de PS están disponibles para la transmisión o el UE recibe un mensaje de búsqueda que activa el procedimiento de actualización de la celda, entonces el UE V316 irá a cero.

Si el UE envía el mensaje SIGNALLING CONNECTION RELEASE INDICATION con el IE “Causa de indicación de liberación de conexión de señalización” establecido en “Finalización de sesión de datos PS solicitados por el UE” en estado CELL DCH o CELL FACH y en respuesta el UE recibe un mensaje de reconfiguración que hace transición al UE al estado CELL PCH o URA PCH, entonces el UE establecerá V316 en N316. El UE considerará que el mensaje de reconfiguración responde al mensaje SIGNALLING CONNECTION RELEASE INDICATION si se recibe dentro de los 500 ms.

8.1.14.2a Restablecimiento de RLC o cambio inter-RAT

Si se produce un restablecimiento del lado transmisor de la entidad RLC en la señalización del portador de radio RB2 antes de que el RLC haya confirmado con éxito la entrega del mensaje SIGNALLING CONNECTION RELEASE INDICATION, el UE deberá:

1> retransmit the SIGNALLINGCONNECTION RELEASE INDICATIONmessage onthe uplink DCCH using AM RLC on signalling radio bearer RB2.

Si se produce un traspaso entre RAT desde el procedimiento UTRAN antes de que el RLC haya confirmado con éxito la entrega del mensaje SIGNALLING CONNECTION RELEASE INDICATION message, el UE deberá:

1> abort the signalling connection while in the newRAT.

8.1.14.3 Recepción de la SIGNALLING CONNECTION RELEASE INDICATION por parte de la UTRAN

Al recibir un mensaje de SIGNALLING CONNECTION RELEASE INDICATION, si la “Causa de indicación de liberación de conexión de señalización” del IE no está incluida, la UTRAN solicita la liberación de la conexión de señalización desde las capas superiores. Las capas superiores pueden entonces iniciar la liberación de la conexión de señalización.

Si la “Causa de indicación de liberación de conexión de señalización” del IE se incluye en el mensaje SIGNALLING CONNECTION RELEASE INDICATION, la UTRAN puede iniciar una transición de estado al consumo de batería eficiente IDLE, CELL_PCH, URA_PCH o CELL_FACH.

8.1.14.4 Vencimiento del temporizador T323

Cuando caduca el temporizador T323:

1> the UE may determine whether any subscquent indications from upper layers that there is no more PS data for a prolongad pcriod in which case it tríggers the transmission o f a single SIGNALLING CONNECTION

RELEASE INDICATION message according with clause 8.1.14.2;

1> the procedure ends.

8.3 Procedimientos de movilidad de conexión RRC

8.3.1 Procedimientos de actualización de celda y URA

Figura 8.3.1-1: Procedimiento de actualización de celda, flujo básico

Figura 8.3.1-2: Procedimiento de actualización de celda con actualización de información de movilidad de UTRAN

Figura 8.3.1-3: Procedimiento de actualización de celda con reconfiguración de canal físico

Figura 8.3.1-4: Procedimiento de actualización de celda con reconfiguración de canal de transporte

Figura 8.3.1-5: Procedimiento de actualización de celda con liberación de portador de radio

Figura 8.3.1-6: Procedimiento de actualización de celda con reconfiguración de portador de radio

Figura 8.3.1-6a: Procedimiento de actualización de celda con configuración de portador de radio

Figura 8.3.1-8: Procedimiento de actualización de URA, flujo básico

MOBILITY INFORMATION

CONFIRM

Figura 8.3.1-9: Procedimiento de actualización de URA con actualización de información de movilidad de UTRAN

Figura 8.3.1-10: Procedimiento de actualización de URA, caso de fallo 8.3.1.1 General

Los procedimientos de actualización de celda y actualización de URA sirven para varios propósitos principales: - notificar a UTRAN después de volver a ingresar al área de servicio en el estado URA_PCH o CELL_PCH;

- notificar a UTRAN de un error irrecuperable [16] RLC en una entidad RLC AM;

- ser utilizado como mecanismo de supervisión en el estado CELL_FACH, CELL_PCH o URA_PCH mediante actualización periódica.

Además, el procedimiento de actualización de URA también sirve para el siguiente propósito:

- recuperar una nueva identidad de URA después de la reselección de celda a una celda que no pertenece a la URA actual asignada al UE en estado URA_PCH.

Además, el procedimiento de actualización de celda también sirve para los siguientes propósitos:

- actualizar UTRAN con la celda actual en la que el UE está conectando después de la reselección de la celda; - actuar sobre un fallo de enlace de radio en el estado CELL_DCH;

- actuar sobre el fallo de transmisión del mensaje de UE CAPABILITY INFORMATION;

- para FDD y 1.28 Mcps TDD, si la variable H_RNTI no está configurada, y para 3.84 Mcps TDD y 7.68 Mcps TDD: cuando se activa en el estado URA_PCH o CELL_PCH, para notificar a UTRAN de una transición al estado CELL_FACH debido a la recepción de notificación originada por UTRAN o debido a una solicitud para transmitir datos de enlace ascendente;

- contar el número de UE en URA_PCH, CELL_PCH y CELL_FACH que están interesados en recibir una transmisión MBMS;

- cuando se activa en el estado URA_PCH, CELL_PCH y CELL_FACH, para notificar a UTRAN del interés del UE para recibir un servicio MBMS;

- solicitar la configuración MBMS P-T-PRB por el UE en los estados CELL_PCH, URA_PCH y CELL_FACH.

La actualización de URA y los procedimientos de actualización celular pueden:

1> inelude an update o f mobility related Information in the UE;

1> cause a State transition from the CELL FACH state to the CELL_DCH, CELL_PCH or URAJPCH States or idle mode.

El procedimiento de actualización celular también puede incluir:

- un restablecimiento de las entidades AM RLC;

- una liberación de portador de radio, reconfiguración de portador de radio, reconfiguración de canal de transporte o reconfiguración de canal físico.

8.3.1.2 Iniciación

Un UE iniciará el procedimiento de actualización celular en los siguientes casos:

1> Uplink data transmission;

2> for FDD and 1.28 Mcps TDD, if the variable H_RNTI is not set, and for 3.84 Mcps TDD and 7.68 Mcps TDD:

3> if the UE is in URA_PCII or CELL_PCH State; and

3> if timer T320 is not running:

4> if the UE has upünk RLC data PDU or uplink RLC eontrol PDU on RB1 or upwards to transmit: 5> perform cell updatc using the cause "upiink data transmission".

3> else:

4> if the variable ESTABLISHMENT_CAUSE is set:

5> perform cell update using the cause "uplink data transmission".

> Paging response:

2> if the criteria for performing cell update with the cause spccified above in the current subclause are not met; and

2> if the UE in URA_PCH or CELL_PCIi State, receives a PAGING TYPE 1 message fulfilling the conditions for initiating a cell updatc procedure specified in subclause 8.1.2.3:

3> perform cell update using the cause "paging response".

> Radio link failure:

2> if none o f the criteria for performing cell update with the causes speci licd above in the current subclause is met:

3> if the UE is in CELL_DCII state and the criteria for radio link failure are met as specified in subclause 8.5.6;or

3> i f the transmission ofthe UE CAPABILITY INFORMATION message fails as specified in subclause 8 ^. 1 ^. 6 ^. 6 ^:

4> perform cell update using the cause "radio link failure".

> MBMS ptp RB request:

2> if none o f the criteria for performing cell update with the causes specified above in the current subclause is met; and

2> if the UE is in URA_PCH, Cell_PCH or Cell_FACH state; and

2> if timer T320 is not running; and

2> i f the UE should perform cell update for MBMS ptp radio bearer request as specified in subclause 8.6.9.6:

3> perform cell update using the cause "MBMS ptp RB request".

> Re-entering Service area:

2> if none ofthe criteria for performing cell update with the causes specified above in the current subclause is met; and

2> if the UE is in CELL_FACH or CELL_PCH state; and

2> if the UE has been out o f Service area and re-enlcrs Service area before T307 or T 317 expires:

3> perform cell update using the cause "re-entering service area".

> RLC unrecoverable error:

2> if none o f the criteria for performing cell update with the causes specified above in the current subclause is mct; and

2> if the U F detects RLC unrecoverable error [16] in an AM RLC entity:

3> perform cell update using the cause "RLC unrecoverable error".

1> Cell reselection:

2> if none o f the criteria for performing cell update with the causes specified above in the current subclause is met:

3> i f the UE is in CELL_FACH or CELL_PCH State and the UE performs cell re-selection; or

3> i f the UE is in CELL_FACH State and the variable C R N T I is empty:

4> perform cell update using the cause "cell reselection'1.

1> Periodical cell update:

2> i f none o f the criteria for performing cell update with the causes specified above in the current subclause is met; and

2> if the UE is in CELL_FACH or CELL_PCH State; and

2> if the timer T305 expires; and

2> if the criteria for ”in Service area" as specified in subclause 8.5.5.2 are fulfilled; and

2> if periodic updating has been configured by T305 in the IE "UF, Timcrs and constants in connected mode” set to any other valué than "infinity":

3> for FDD:

4> if the variable C0M M 0N_E_DCII_TRANSM ISS10N is set to FALSE:

5> perform cell update using the cause "periodical cell update",

4> eisc:

5> restart the timer T305;

5> and end the procedure.

3> for 1.28 Mcps TDD and 3.84/7.68 Mcps TDD:

4> perform cell update using the cause "periodical cell update".

1> MBMS reception:

2> if none o f the criteria for performing cell update with the causes specified above in the current subclause is met; and

2> if the UE is in URA_PCH, Cell_PCH or CellJFACH State; and

2> i f the UE should perform cell update for MBMS counting as specified in subclause 8.7.4:

3> perform cell update using the cause "MBMS reception".

Un UE en estado URA_PCH iniciará el procedimiento de actualización de URA en los siguientes casos: 1> URA reselection:

2> i f the UE detects that the current URA assigned to the UE, stored in the variable URA_IDENTITY, is not present in the list o f URA identities in system information block type 2; or

2> i f the list o f URA identities in system information block type 2 is empty; or

2> if the system information block type 2 can not be found:

3> perform URA update using the cause "change o f URA".

1> Periodic URA update:

2> if the criteria for perform ing URA update with the causes as specified above in the current subclause are not met:

3> if the timer T305 expires and if periodic updatinghas been configured by T305 in the EE "UE Timers and constants in connected mode" set to any other valué than "infínity"; or

3> i f the conditions for ¡nitiating an URA update procedure specified in subclause 8.1.1.6.3 are fullfilled: 4> perform URA update using the cause "periodic URA update".

Al iniciar la actualización de URA o el procedimiento de actualización de celda, el UE deberá:

1 > if the UE lias unlink RLC data PDU or unlink RLC control PDU on RB3 or upwards to transmit: or

1> if the UE received a PAGINO TYPE 1 message fulfílling the conditions for initiating a celi update procedure specified in subclause 8.1.2.3:

2> set the counter V 316 to zero.

1> if timer T320 is running:

2> stop timer T320;

2> if the UE has uplink RLC data PDU or uplink RLC contro! PDU on RB1 or upwards to transmit:

3> perform cell update using the cause "uplink data transmission",

2> else:

3> if the cell update procedure is not triggered due to Paging response or Radio link failure; and

3> if tire UE should perform cell update for MBMS ptp radio bearer request as specified in subclause 8.6.9.6: 4> perform cell update using the cause "MBMS ptp RB request".

1> stop timer T319 if it is running;

1> stop timer T305;

1> for FDD and 1.28 Mcps TDD:

2> ifthe UE is in CELL_FACH State; and

2> if the IE "HS-DSCH common system information" is included in System Information Block type 5 or System Information Block type Sbis; and

2> for 1.28 Mcps TDD, if IE "Common E-DCII system info" in System Information Block type 5; and 2> ifthe UE does support HS-DSCII reception in CELL FACH State:

3> if variable H_KNTI is not set or variable C_RNTI is not set:

4> clear variable II RNTI;

4> clear variable C RNTI;

4> clear any stored lEs "HARQ info";

4 > set variable H S _D S C H _R E C E P l'IO N _O F _C C C H _E N A B L E D to TRU E;

4> and start receivíng the HS-DSCH transport channels mapped physica! channel(s) o f type HS-SCCH and HS-PDSCH, by using parameters given by the IE(s) "HS-DSCH coramon systera information" according to the procedure in subclause 8.5.37.

3> else:

4> rcceive the HS-DSCH transport channels mapped physieal channel(s) o f type IIS-SCCH and HS-PDSCH, by using parameters given by the IE(s) "HS-DSCH common system information" according to the procedure in subclause 8.5.36;

4> determine the valué for the H SP A R N T IS T O R E D C E L L P C H variable and take the corresponding actions as described in subclause 8.5.56;

4> determine the valué for the READY_FOR_COMMON EDCH variable and take the corresponding actions as described in subclause 8.5.47;

4> determine the valué for the COMMONJE_DCH_TRANSMISSION variable and take the corresponding actions as described in subclause 8.5.46;

4> if variable READY_FOR_COMMON_EDCH is set to TRUE:

5> configure the Enhanced Uplink in C ELLFA C H State and Idle mode as specified in subclause 8.5.45 for FDD and 8.5.45a for 1.28 Mcps TDD.

> if the UE is in C EL L D C H State:

2> in the variable RB TIMER INDICATOR, set the IE "T314 expired" and the IE "T315 expired1 to FALSE; 2> if the stored valúes o f the timer T 314 and timer T315 are both equal to zero; or

2> if the stored valué o f the timer T 314 is equal to zero and there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the valué o f the IE "Re-establishment timer" is set to "useT315" and signalling connection exists only to the CS domain:

3> release all its radio resources;

3> indícate release (abort) o f the established signalling connections (as stored in the variable ESTABLISHED SIGNALLING CONNECTIONS) and established radio access bearers (as stored in the variable ESTABLlSHEDJRABSj to upper layers;

3> clearthe variable ESTABLISHED_SIGNALLING_CONNECTIONS;

3> clear the variable ESTABLISHED_RABS;

3> enler idle mode;

3> perform other actions when entering idle mode írom connected mode as specified in subclause 8.5.2; 3> and the procedure ends.

2> if the stored valué o f the timer T 314 is equal to zero:

3> release all radio bearers, associated with any radio access bearers for which in the variable ESTABLISHED_RABS the valué o f the IE "Re-establishment timer" is set to "useT314";

3> in the variable RB TIMER INDICATOR set the IE "T314 expired" to TRUE;

3> if all radio access bearers associated with a CN domain are released:

4> release the signalling connection for that CN domain;

4> remove the signalling connection for that CN domain from the variable ESTABLISHED_SIGNALLING_CONNECTIONS;

4> indícate release (abort) o f the signalling connection to upper layers;

> if the stored valué o f the timer T 315 is equal to zero:

3> release all radio bcarers associated with any radio access bearers for which in the variable ESTA BLISH EDR ABS the valué o f the IE "Re-establishment timer” is set to "useT315”;

3> in the variable RB_TIMER_INDICATOR set the 1E "T315 expired" to TRUE.

3> i f all radio access bearers associated with a CN domain are released:

4> release the signallíng connection for that CN domain;

4> remove the signalling connection for that CN domain from the variable ESTABLISHED_SIGNALLlNG_CONNECTIONS;

4> indicate release (abort) o f the signalling connection to upper layers;

> if the stored valué o f the timer T 314 is greaíer than zero:

3> i f there are radio bearers associated with any radio access bearers for which in the variable ESTABLISH EDRABS the valué o f the IE "Re-eslablishmcnt timer" is set to "useT314":

4> start timer T 314.

3> i f there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED RABS the valué o fth e IE "Re-establishment timer" is set to "useT314" or "uscT315" and the signalling connection exists to the CS domain:

4> start timer T 314.

> if the stored valué o f the timer T315 is greater than zero:

3> i f there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the valué o f the IE "Re-establishment timer" is set to "useT315"; or 3> i f the signalling connection exists to the PS domain:

4> start timer T 315.

> for the released radio bearer(s):

3> delete the information about the radio bearer from the variable ESTABLISHED RABS;

3> when all radio bearers belonging to the same radio access bearer have been released:

4> indícate local end release o f the radio access bearer to upper layers using the CN domain identity togetber with the RAB identity stored in the variable ESTABLISHED_RABS;

4> delete all information about the radio access bearer from the variable ESTABLISHED_RABS. > if the variable EJDCHJTRANSMISSION is set to TRUE:

3> set the variable E_DCH_TRANSMISSION to FALSO;

3> stop any E-AGCH and E-HICH reception procedures;

3> for FDD, stop any E-RGCII reception procedures.

3> for FDD, stop any E-DPCCH and E-DPDCH transmission procedures.

3> for 1,28 Mcps TDD, stop any E-PUCH transmission proccdurc.

3> clear the variable E_RNTI;

3> act as if the IE "MAC-es/e reset indicator" was received and set to TRUE;

3> release all E-DCIIHARQ resources;

3> no longer consider any radio link to be the serving H-DCH radio link.

2> move to CELL_FACH State;

2> select a suitable UTRA ccll on the ciirrent frequency according to [4];

2> olear variable E_RNTI and:

3> determine the valué for the HSPA_RNTI_STORED_CELL_PCH variable and take the corresponding actions as described in subclause 8.5.56;

3> determine the valué for the READY_FOR_COMMON__EDCH variable and take the corresponding actions as described in subclause 8.5.47;

3> determine the valué for the COMMON J2_DCH_TRANSMISSION variable and take the corresponding actions as described in subclause 8.5.46.

2> for 3.84 Mcps TDD and 7.68Mcps TDD; or

2> for FDD and 1.28 Mcps TDD, i f the UE does not support HS-DSCH reception in CELL_FACH State; or 2> if the 1E "HS-DSCF1 common system information" is not included in System Information Block type 5 or System Information Block type 5bis; or

2> for 1.28 Mcps TDD, ifthe IE "Common E-DCH system info" is not included in System Information Block type 5:

3> select PRACH according to subclause 8.5.17;

3> select Secondary CCPCII according to subclause 8.5.19;

3> use the transport formal setgiven in system information as specified in subclause 8.6.5.1;

3> take the actions related to the FlS_DSCH_RECEPTION_GENERAL variable as described in subclause 8.5.37a.

2> else:

3> i f variable READY_FOR_CO MMON EDCII is set to TRUE;

4> configure the Enhanced Uplink in CELL_FACH State and Idle mode as specified in subclause 8.5.45 3> else:

4> select PRACH according to subclause 8,5.17 and:

5> use for the PRACH the transport formal set given in system information as specified in subclause 8 ^. 6 ^. 5 ^. 1 ^{. '}

3> clear variable H_RNTI;

3> clear any stored IHs "HARQ info";

3> reset the MAC-ehs entity [15];

3> set variable HSJ>SCH_RECEPTION_OF_CCCH_ENABLED to TRUE;

3> and start receiving the HS-DSCH according to the procedure in subclause 8.5.37.

2> set the variable ORDERED_RECONFIGURATION to FALSE.

> set the variables PROTOCOL_ERROR_INDICATOR, FAILUREJNDICATOR,

UNSUPPORTED CONFIGURATION and INVALID CONFIGURATION to FALSE;

> se t th e variab le C E L L _U P D A T F ,_S T A R T E D to T R U E ;

> if any lEs releated to HS-DSCHare stored in the UE:

2> clear any stored IE "Downlink HS-PDSCH information";

2> clear any stored IE "Downlink Secondary Cell Info FDD";

2> clear all the entries ftom the variable TARGET_CF,LL_PRECONFIGURATION;

2> for 1.28Mcps TDD, clear the IE "HS-PDSCH Midamble Configuration" and the IE "HS-SCCH Set Configuration" in the IE "DL Multi Carricr Information";

2 > determine the valué for the HS_DSCH_RECEPTION variable and takc the corresponding actions as described in subclause 8.5.25;

2> determine the valué for the SECONDARY_CELL_IIS JDSCHRECEPTION variable and take the corresponding actions as described in subclause 8.5.51.

> if any IEs related to E-DCH are stored in the UE:

2> clear any stored IE "E-DCH info";

2> determine the valué for the E_DCH_TRANSMISSION variable and take the correspunding actions as described in subclause 8.5.28.

> i f any o f the IEs "DTX-DRX timing information" or "DTX-DRX information" are stored in the UE:

2> determine the valué for the DTX_DRX_STATUS variable and take the corresponding actions as described in subclause 8.5.34.

> if the IE "HS-SCCH less information" is stored in the UE:

2> determine the valué for the HS_SCCH_LESS_STATUS variable and take the corresponding actions as described in subclause 8.5.35.

> if any IEs related to MIMO are stored in the UE:

2> determine the valué for the MIMO_STATUS variable and take the corresponding actions as described in subclause 8.5.33.

> for 1.28 Mcps TDD, if the IEs "Control Channel DRX Information" is stored in the UE:

2> determine the valué for the CONTROL CHANNEL_DRX_ STATUS variable and take the corresponding actions as described in subclause 8.5.53.

> for 1.28 Mcps TDD, if the IE "SPS information" is stored in the UE:

2> determine the valué for the E_DCH SPS_STATUS variable and take the corresponding actions as described in subclause 8.5,54;

2> determine the valué for the HS_DSCH_SPS STATUS variable and take the corresponding actions as described in subclause 8.5.55.

> if the UE is not already in CELL_FACH State:

2 > move to CELL_FACH State;

2> determine the valué for the IISPA _RNTI_STORED CELL_PCH variable and take the corresponding actions as described in subclause 8.5.56;

2> determine the valué for the READY_FOR COMMON_EDCH variable and take the corresponding actions as described in subclause 8.5.47;

2> determine the valué for the COMMON E_DCH TRANSMISSION variable and take the corresponding actions as described in subclause 8.5.46;

2> for 3.84 Mcps TDD and 7.68 Mcps TDD; or

2> for FDD and 1.28 Mcps TDD, if tlie UE does not support IIS-DSCH reception in CELLFACH State; or 2> ifthe IE "HS-DSCH common syslem information" is not included in System Information Block type 5 or System Information Block type 5bis; or

2> for 1.28 Mcps TDD, if the IE "Common E-DCH system info" is not included in System Information Block type 5:

3> selectPRACH accordingto subclause 8.5.17;

3> select Secondary CCPCH according to subclause 8.5.19;

3> use the transport format set givcn in system information as specified in subclause 8.6.5.1;

3> take the actions related to the IIS DSCH RECEPTION_GENERAL variable as described in subclause 8.5.37a.

2> elsc:

3> if variable READY_l-OR_COMMON_EDCH is setto TRUE:

4> configure the Enltanced Uplink in CELL FACH statc and Idle mode as specified in subclause 8.5.45, 3> else:

4> select PRACH according to subclause 8.5.17 and:

5> use for the PRACH the transport format set givcn in system Information as specified in subclause 8 ^. 6 ^. 5 ^. 1 ^{. ' '}

3> if variable HJRNTI is not set or variable C_RNTI is not set:

4> clear variable C R N TI;

4> clear variable H_RNTI;

4> clear any stored IEs "HARQ info";

4> set variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED to TRUE;

4> and start receiving the HS-DSCH according to the procedure in subclause 8.5.37.

3> else:

4> receive the HS-DSCH according to the procedure in subclause 8.5.36.

> ifthe UE performs cell re-sclection:

2> clear the variable C_RNTI; and

2> stop using that C_RNTI just cleared ffom the variable C_RNTI in MAC;

2> for FDD and 1.28 Mcps TDD, if the variable H RNTI is set:

3> clear the variable I-I RNTI; and

3> stop using that H RNTI just cleared ffom the variable H_RNT1 in MAC;

3> clear any stored IEs "IIARQ info";

2> for FDD and 1.28 Mcps IDD, ifthe variable E_RNT1 is set:

3 > clear the variable E R N T I.

2> determine the valué for the HSPA_Rl\TTI_STORED_CELL_PCH variable and take the corresponding actions as described in subclause 8,5.56;

2> determine the valué for the READY_FOR_COMMON_EDCH variable and take the corresponding actions as described in subclause 8.5.47;

2> determine the valué for the COMMON_E_DCH_TRANSM1SSION variable and take the corresponding

actions as described in subclause 8.5.46;

2> for FDD and 1.28 Mcps TDD, if the UE does support HS-DSCH reception in CELL_FACH State and 1E

"HS-DSCH common system information" is included in System Information Block type 5 or System

Information Block type 5bis:

3> reset the MAC-ehs entity [15].

3> set variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED to TRUE;

3> and start receiving the IIS-DSCH according to the procedure in subclause 8.5.37.

2> else:

3> take the actions related to the HS_DSCH_RECEPTION_GENERAL variable as described in subclause 8.5.37a.

1> set CFN in relation to SFN o f current cell according to subclause 8.5.15;

1> in case o f a cell update procedure:

2> set the contents o f the CELL UPDATE message according to subclause 8.3.1.3;

2> submil the CELL UPDATE message for transmission on the uplink CCCII.

1 > in case o f a URA update procedure:

2> set the contents o f the URA UPDATE message according to subclause 8.3.1.3;

2> submit the URA UPDATE message for transmission on the uplink CCCH.

1> set countcr V302 to 1;

1> start timer T302 when the MAC layer indicates success or failure in transmitting the message.

10.3.3.43 UE Timers and Constants in connected mode

Este elemento de información especifica valores de temporizador y constantes utilizados por el UE en modo conectado.

13.4.27x SCRI TRIGGERED SCRI IN PCH STATE

Esta variable contiene información sobre si se ha activado un mensaje de SIGNALLING CONNECTION RELEASE INDICATION en los estados CELL PCH o URA PCH. Hay una de esas variables en el UE.

13.2 Contadores para UE

13.3 Constantes y parámetros de UE

Apéndice D

De 25.331 sección 8.2.2, Figura 8.2.2-3: representa una reconfiguración de portador de radio, flujo normal.

El mensaje se describe aquí, con la adición propuesta en cursiva y negrita:

10.2.27 RADIO BEARER RECONFIGURATION

Este mensaje se envía desde UTRAN para reconfigurar parámetros relacionados con un cambio de QoS o para liberar y configurar un portador de radio utilizado para la transmisión ptp de servicios MBMS del tipo de difusión. Este procedimiento también puede cambiar la multiplexación de MAC, reconfigurar canales de transporte y canales físicos. Este mensaje también se utiliza para realizar una transferencia del modo GERAN ^lu a UTRAN.

RLC-SAP: AM o UM o enviado a través del modo GERAN ^lu

Canal lógico: DCCH o enviado a través del modo GERAN ^lu

Dirección: UTRAN ^ UE

Claims (12)

REIVINDICACIONES

1. Un método para procesar un mensaje de indicación de transición que indica un paquete conmutado, PS, Final de sesión de datos por un equipo de usuario, UE, (802), estando el UE en comunicación con una UTRAN, Red Universal de Acceso de Radio Terrestre, el método comprende:

en la UE (802):

si un recuento de cuántos mensajes de indicación de transición se ha activado en el estado actual de control de recursos de radio, RRC, es menor que un número máximo:

incrementar el recuento de cuántos mensajes de indicación de transición se han activado en el estado actual de RRC; establecer un elemento de información de causa, IE, en un mensaje de indicación de transición; enviando el mensaje de indicación de transición a la UTRAN; y

restablecer el recuento tras la satisfacción de al menos una condición de restablecimiento, la al menos una condición de restablecimiento comprende un cambio de estado de RRC debido a una solicitud de transacción de datos por parte del UE o la UTRAN, en el que el UE está configurado para no enviar mensajes de indicación de transición posteriores mientras el El UE permanece en el estado de RRC actual si el recuento es mayor que el número máximo, en el que la causa IE en el mensaje de indicación de transición indica una solicitud para el final de una sesión de PS Data.

2. El método de la reivindicación 1, en el que los mensajes de indicación de transición contados en el recuento tienen un elemento de información de causa establecido al final de la sesión de datos de PS solicitada por el UE.

3. El método de cualquiera de las reivindicaciones 1 a 2, en el que el elemento de información de causa se establece en el final de la sesión de datos de PS solicitada por el UE.

4. El método de cualquiera de las reivindicaciones 1 a 3, en el que el mensaje de indicación de transición es un mensaje de indicación de liberación de conexión de señalización.

5. El método de cualquiera de las reivindicaciones 1 a 4, en el que el estado RRC actual comprende un estado CELL_PCH (126) o un estado URA_PCH (128).

6. El método de cualquiera de las reivindicaciones 1 a 5, en el que el equipo de usuario está en un estado CELL_PCH (126) o en un estado URA_PCH (128).

7. El método de la reivindicación 6, que comprende además la transición a un estado CELL_FACH (124) para enviar el mensaje de indicación de transición si el equipo de usuario está en el estado URA_PCH (128).

8. El método de cualquiera de las reivindicaciones 1 a 7, que comprende además inhibir el envío del mensaje de indicación de transición mientras se está ejecutando un temporizador de inhibición.

9. El método de cualquiera de las reivindicaciones 1 a 8, en el que el número máximo es 1.

10. El método de cualquiera de las reivindicaciones 1 a 9, que comprende además que el UE determine si las capas lógicas superiores indican que no hay más datos de PS durante un período.

11. El método de cualquiera de las reivindicaciones 1 a 10, que comprende además que el UE determine si el recuento de cuántos mensajes de indicación de transición se ha activado mientras está en el estado RRC actual es menor que el número máximo.

12. Un equipo de usuario, UE, (802) configurado para comunicarse con una UTRAN, red universal de acceso de radio terrestre y procesar mensajes de indicación de transición, el UE (802) configurado para realizar el método de cualquiera de las reivindicaciones 1 a 11.