MX2012005871A - Metodo y aparato para transicion de estado/modo. - Google Patents

Abstract

Un equipo de usuario implementa un método para procesar mensajes de indicación, tales como mensajes de SCRI (indicación de liberación de conexión de señalización) El equipo de usuario (UE) mantiene un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentran en al menos un estado de control de recursos de radio (RRC). Se proporcionan varias condiciones para restablecer el conteo. Éstas incluyen recibir datos conmutados por paquetes (PS) por el UE y transmitir datos conmutados por paquetes (PS).

Description

MÉTODO Y APARATO PARA TRANSICIÓN DE ESTADO/MODO DESCRIPCIÓN DE LA INVENCIÓN La presente descripción se refiere al control de recursos de radio entre Equipo de Usuario (UE) u otro dispositivo inalámbrico o móvil y una red inalámbrica, y en particular a transiciones entre estados y modos de operación en una red inalámbrica tal como por ejemplo, una red de Sistema Universal de Telecomunicación Móvil (UMTS) .

Un Sistema Universal de Telecomunicación Móvil (UMTS) es un sistema basado en paquetes, de banda ancha, para la transmisión de texto, voz digitalizada, video y multimedia. Se encuentra muy aceptado como estándar para la tercera generación y se basa generalmente en Acceso Múltiple por División de Código de Banda Ancha (W-CDMA) .

En una red de UMTS, una parte de Control de Recursos de Radio (RRC) de la pila de protocolo es responsable de la asignación, configuración y liberación de recursos de radio entre el UE y la UTRAN. Este protocolo de RRC se describe en detalle en las especificaciones de la TS 25.331 del 3GPP. Dos modos básicos en los que puede encontrarse el UE se definen como "modo inactivo" y "modo conectado de RRC de UTRA" (o simplemente "modo conectado", como se utiliza en la presente) . UTRA es sinónimo de Acceso por Radio Terrestre de UMTS. En el modo inactivo, se requiere que el UE u otro dispositivo móvil solicite una conexión de RRC siempre que quiera enviar cualesquier datos de usuario o en respuesta a una búsqueda siempre que la UTRAN o el Nodo de Soporte de Servicio de Radio Paquete General (GPRS) de Servicio (SGSN) lo busque para recibir datos desde una red de datos externa tal como un servidor de inserción. Los comportamientos de modo Inactivo y Conectado se describen en detalle en las especificaciones de la TS 25.304 y de la TS 25.331 del Proyecto de Sociedad de Tercera Generación (3GPP) .

Cuando se encuentra en un modo conectado de RRC de UTRA, el dispositivo puede encontrarse en uno de cuatro estados. Estos son: CELL-DCH: En este estado se asigna un canal dedicado al UE en enlace ascendente y enlace descendente para intercambiar datos. El UE debe realizar acciones como se describe en 25.331 del 3GPP.

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

CELL_PCH: El UE utiliza la Recepción Discontinua (DRX) para monitorear mensajes de difusión y búsquedas mediante un Canal Indicador de Búsqueda (PICH) . No es posible actividad de enlace ascendente. El UE debe realizar acciones como se describe en 25.331 del 3GPP que incluye el proceso de selección de celda como se define en la TS 25.304 del 3GPP. El UE debe realizar el procedimiento de ACTUALIZACIÓN DE CELDA después de la reselección de celda.

URA_PCH: El UE utiliza la Recepción Discontinua (DRX) para monitorear mensajes de difusión y búsquedas mediante un Canal Indicador de Búsqueda (PICH) . No es posible actividad de enlace ascendente. El UE debe realizar acciones como se describe en 25.331 del 3GPP que incluye el proceso de selección de celda como se define en la TS 25.304 del 3GPP. Este estado es similar a CELL_PCH, excepto que el procedimiento de ACTUALIZACIÓN de URA sólo se activa mediante la reselección de Área de Registro de UTRAN (URA) .

La transición de un modo inactivo al modo conectado y viceversa se controla por la UTRAN. Cuando un UE en modo inactivo solicita una conexión de RRC, la red decide si mueve el UE al estado de CELL_DCH o CELL_FACH. Cuando el UE se encuentra en un modo conectado de RRC, nuevamente es la red la que decide cuándo liberar la conexión de RRC. La red también puede mover el UE de un estado de RRC a otro antes de liberar la conexión o en algunos cados en lugar de liberar la conexión. Las transiciones de estado típicamente se activan por actividad o inactividad de datos entre el UE y la red. Puesto que la red puede no saber cuándo el UE ha completado el intercambio de datos para una aplicación determinada, típicamente mantiene la conexión de RRC durante cierto tiempo a la espera de más datos hasta/desde el UE. Normalmente esto se hace para reducir la latencia del establecimiento de llamada y el establecimiento subsiguiente de recursos de radio. El mensaje de liberación de conexión de RRC sólo puede enviarse por la UTRA . Este mensaje libera la conexión de enlace de señal y todos los recursos de radio entre el UE y la UTRAN. Generalmente, el término "portadora de radio" se refiere a recursos de radio asignados entre el UE y la UTRAN. Y el término "portadora de acceso por radio" generalmente se refiere a recursos de radio asignados entre el UE y, por ejemplo, un SGSN (Nodo de Servicio de GPRS de Servicio) . La presente descripción siempre mencionará al término recurso de radio, y tal término se referirá, según aplique, a cualquiera o ambas de portadora de radio y/o portadora de acceso por 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 se espera ningún intercambio de datos adicional, aún espera que la red la mueva al estado correcto. La red puede no encontrarse al tanto todavía 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 utilizar su propio protocolo basado en confirmación para intercambiar datos con su servidor de aplicación, el cual se accede a través de la red central de UMTS. Las aplicaciones son ejemplos que se ejecutan sobre Protocolo de Datagrama de Usuario/Protocolo de internet (UDP/IP) que implementan su propia entrega garantizada. En tal caso, el UE sabe si el servidor de aplicación ha enviado o recibido todos los paquetes de datos o no, y se encuentra en una mejor posición para determinar si algún intercambio de datos adicional tendrá lugar y en consecuencia decidir cuándo terminar la conexión de RRC asociada con el dominio de Servicio de Paquetes (PS) . Puesto que la UTRAN controla cuando se cambia el estado conectado de RRC a un estado diferente o a un modo inactivo, y la UTRAN no se encuentra al tanto del estado de la entrega de datos entre el UE y el servidor externo, el UE puede verse forzado a permanecer en un estado o modo de mayor proporción de datos de la que se requiere, resultando posiblemente en una vida de batería disminuida para la estación móvil e incluso posiblemente resultando en recursos de red desperdiciados debido al hecho de que los recursos de radio se mantienen ocupados de manera innecesaria y de esta manera no se encuentran 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 comprenda que ha terminado con una transacción de datos. Conforme a la sección 8.1.14.3 de la especificación de la TS 25.331 del 3GPP, la UTRAN puede liberar la conexión de señalización con la recepción de indicación de liberación de señalización del UE, provocando que el UE haga transición a un modo inactivo o algún otro estado de RRC . Un problema con la solución anterior es que la UTRAN puede verse inundada con mensajes de indicación de liberación de señalización del UE y otros UE.

De acuerdo con un aspecto de la presente solicitud, se proporciona un método realizado por un equipo de usuario (UE) , el método comprende: en el UE, mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; recibir datos conmutados por paquetes (PS) por el UE; restablecer el conteo por el UE en respuesta a recibir los datos de PS.

De acuerdo con otro aspecto de la presente solicitud, se proporciona un equipo de usuario (UE) configurado para: mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; recibir los datos conmutados por paquetes (PS) ; restablecer el conteo en respuesta a recibir los datos de PS .

De acuerdo con otro aspecto de la presente solicitud, se proporciona un método realizado por un equipo de usuario (UE) , el método comprende: en el UE, mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; transmitir los datos conmutados por paquetes (PS) ; restablecer el conteo por el UE en respuesta a transmitir los datos de PS.

De acuerdo con otro aspecto de la presente invención, se proporciona un equipo de usuario (UE) configurado para: mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; transmitir los datos conmutados por paquetes (PS) ; restablecer el conteo para el UE en respuesta a la transmisión de los datos de PS UE.

De acuerdo con otro aspecto de la presente invención, se proporciona un método realizado por un equipo de usuario (UE) , el método comprende: en el UE, mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; transmitir la señalización por el UE en la portadora de radio 3 (RB3) o superior; restablecer el conteo por el UE en respuesta a la transmisión de la señalización.

De acuerdo con otro aspecto de la presente invención, se proporciona un equipo de usuario (UE) configurado para: mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; transmitir la señalización en la portadora de radio 3 (RB3) o superior; restablecer el conteo en respuesta a la transmisión de la señalización.

De acuerdo con otro aspecto de la presente invención, se proporciona un método realizado por un equipo de usuario (UE) , el método comprende: en el UE, mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; entrar al modo conectado de RRC; restablecer el conteo en respuesta a entrar al modo conectado de RRC.

De acuerdo con otro aspecto de la presente invención, se proporciona un equipo de usuario (UE) configurado para: mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; entrar al modo conectado de RRC; restablecer el conteo en respuesta a entrar al modo conectado de RRC.

De acuerdo con otro aspecto de la presente solicitud, se proporciona un método realizado por un equipo de usuario (UE) , el método comprende: en el UE, mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; recibir un mensaje de búsqueda que activa un procedimiento de actualización de celda; restablecer el conteo por el UE en respuesta a recibir a un mensaje de búsqueda .

En algunas modalidades de cualquiera de los aspectos antes resumidos, la señalización comprende unidad de datos de protocolo (PDU) de control de enlace de radio (RLC) de enlace ascendente.

En algunas modalidades de cualquiera de los aspectos antes resumidos, los mensajes de indicación comprenden mensajes de indicación de liberación de conexión de señalización.

En algunas modalidades de cualquiera de los aspectos antes resumidos, los mensajes de indicación en el conteo cada uno tienen una causa establecida en "finalización de sesión de datos de PS solicitada por UE" .

En algunas modalidades de cualquiera de los aspectos antes resumidos, la causa se establece en "finalización de sesión de datos de PS solicitada por UE" .

En algunas modalidades de cualquiera de los aspectos antes resumidos, por lo menos un estado de RRC comprende un estado de CELL_PCH o un estado de URA_PCH.

En algunas modalidades de cualquiera de los aspectos antes resumidos, mantener un conteo comprende utilizar un contador.

En algunas modalidades, la recepción de un mensaje de búsqueda comprende: recibir un mensaje TIPO BÚSQUEDA 1 que cumpla con las condiciones de iniciar un procedimiento de actualización de celda.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La presente descripción se entenderá mejor con referencia a los dibujos en los cuales: La Figura 1 es un diagrama de bloque que muestra ¿ estados y transiciones de RRC; u la Figura 2 es un diagrama esquemático de una red de UMTS que muestra varias celdas de UMTS y una URA; la Figura 3 es un diagrama de bloque que muestra las diversas fases en un establecimiento de conexión de RRC; la Figura 4A es un diagrama de bloque de una transición ejemplar entre un estado en modo conectado de CELL_DCH y un modo inactivo iniciado por la UTRA de acuerdo con el presente método; la Figura 4B es un diagrama de bloque que muestra una transición ejemplar entre una transición de modo conectado de estado de CELL_DCH a un modo inactivo utilizando indicaciones de liberación de señalización; la Figura 5A es un diagrama de bloque de una transición ejemplar entre un estado de inactividad de CELL_DCH y un estado de inactividad en CELL_FACH a un modo inactivo iniciado por la UTRAN; la Figura 5B es un diagrama de bloque de una transición ejemplar entre un estado de inactividad de CELL_DCH y un modo inactivo utilizando indicaciones de liberación de señalización; la Figura 6 es un diagrama de bloque de una pila de protocolo de UMTS; la Figura 7 es un UE ejemplar que puede utilizarse junto con el presente método; la Figura 8 es una red ejemplar para su uso junto con el presente método y sistema; la Figura 9 es un diagrama de flujo que muestra las etapas para 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 las etapas tomadas por un UE con la recepción de 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 ejemplar de canal lógico y físico durante la operación ejemplar de la red mostrada en la Figura 8 en la cual se proporcionan múltiples sesiones de servicio de comunicación de datos por paquetes concurrentes con el UE; la Figura 12 ilustra un diagrama de bloque funcional del UE y elementos de red que proporcionan una función de liberación de recursos de radio para liberar los recursos de radio de servicios de datos por paquetes individuales conforme una modalidad de la presente descripción; la Figura 13 ilustra un diagrama de secuencia de mensajes representativo de la señalización generada conforme la operación de una modalidad de la presente descripción por la cual se libera la asignación de recursos de radio a un contexto de 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 conforme a la operación de una modalidad de la presente descripción por la cual se libera la asignación de recursos de radio; la Figura 15 ilustra un diagrama de proceso representativo del proceso de una modalidad de la presente descripción; la Figura 16 ilustra un diagrama de flujo de método que ilustra el método de operación de una modalidad de la presente descripción; la Figura 17 ilustra un diagrama de flujo de método, que también ilustra el método de operación de una modalidad de la presente descripción; la Figura 18 ilustra un diagrama de flujo de método de una modalidad en la cual se toman las decisiones de transición basándose en un Perfil de Recursos de Radio en un elemento de red; la Figura 19 ilustra un diagrama de bloque simplificado de un elemento de red capaz de utilizarse 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 el establecimiento de un valor del cronómetro de inhibición en un UE; Los ejemplos y modalidades proporcionados a continuación describen varios métodos y sistemas para hacer transición de un Equipo de Usuario (UE) u otro dispositivo móvil entre varios estados/modos de operación en una red inalámbrica, tal como, por ejemplo, una red de UM S . Se entenderá que otras implementaciones en otros tipos de redes también son posibles. Por ejemplo, las mismas enseñanzas también podrían aplicarse a una red de Acceso Múltiple de División por Código (CDMA) (por ejemplo, IS-2000 del 3GPP2), red de banda ancha-CDMA (W-CDMA) (por ejemplo, UMTS /Acceso por Paquetes a Alta Velocidad (HSPA) de 3GPP) una red de UTRAN Evolucionada (por ejemplo, LTE) , o por medio de la generalización a cualquier red basándose en tecnologías de acceso por radio que utilizan recursos de radio controlados por red o que no mantienen ningún conocimiento de los estados de intercambios de datos de nivel de aplicación de dispositivo. Los ejemplos específicos e implementaciones descritos a continuación aunque presentados para simplicidad con respecto a las redes de UMTS también se pueden aplicar a estos otros ambientes de red. Además, el elemento de red algunas veces se describe a continuación como la UTRAN. Sin embargo, si otros tipos de redes además de UMTS se utilizan, el elemento de red puede seleccionarse de manera adecuada basándose en el tipo de red. Además, el elemento de red puede ser la red central en un sistema de UM S o cualquier otro sistema de red adecuado, 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 desde un modo conectado de RRC hasta un estado o modo más eficiente de batería o eficiente de recursos de radio mientras proporciona las capacidades de toma de decisión en la red. En particular, el presente método y aparato proporcionan la transición basándose en la recepción de una indicación desde un UE que indica, ya sea de manera implícita o explícita, que una transición del estado o modo de RRC asociado con una conexión de señalización particular con recursos de radio a otro estado o modo debe presentarse. Como se apreciará, tal indicación de transición o solicitud podrían utilizar una comunicación . existente bajo estándares actuales, por ejemplo un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, o podría ser un nuevo mensaje dedicado para cambiar el estado del UE, tal como una "solicitud de estado de RRC preferida" o "un mensaje de transferencia completa de datos". Un mensaje de indicación de transferencia completa de datos es un mensaje que indica la finalización de la transferencia de datos de capa superior. Como se utiliza en la presente, una indicación podría referirse a otro escenario, y podría incorporar una solicitud.

La indicación de transición originada por el UE puede enviarse en ciertas situaciones cuando una o más aplicaciones en el UE han completa un intercambio de datos y/o cuando se realiza una determinación de que no se espera que las aplicaciones de UE intercambien datos adicionales. El elemento de red entonces puede utilizar la indicación en cualquier información proporcionada en la misma, así como otra información relacionada con el recurso de radio, tal como calidad de servicio, Nombre de Punto de Acceso (APN) , contexto de Protocolo de Datos por Paquete (PDP) , información histórica, entre otros, definidos en la presente como perfil de recursos de radio, para tomar una decisión específica de red sobre si hacer 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 el dispositivo móvil puede tener varias formas y puede enviarse bajo diferentes condiciones. En un primer ejemplo, la indicación de transición puede enviarse basándose en un estado compuesto de todas las aplicaciones que residen en el UE. Específicamente, en un ambiente de UMTS, si una aplicación en el UE determina que se realice con el intercambio de datos, puede enviarse una indicación de "realizado" a un componente "administrador de conexión" del software de UE. El administrador de conexión en una modalidad, puede estar al tanto de todas las aplicaciones existentes (incluyendo aquellas que proporcionan un servicio sobre uno o múltiples protocolos), contextos asociados de Protocolo de Datos por Paquetes (PDP) , recursos de radio conmutados por paquetes (PS) asociados y recursos de radio conmutados por circuitos (CS) asociados. Un contexto de PDP es una asociación lógica entre el UE y la PDN (Red de Datos Pública) que se ejecuta a través de una red central de UMTS. Una o múltiples aplicaciones (por ejemplo, una aplicación de correo electrónico y una aplicación de explorador) en el UE pueden asociarse con un contexto de PDP. En algunos casos, una aplicación en el UE se asocia con un contexto de PDP primario y múltiples aplicaciones pueden conectarse con contextos de PDP secundarios. El Administrador de Conexión recibe indicaciones "realizado" de diferentes aplicaciones en el UE que se encuentran simultáneamente activas. Por ejemplo, un usuario puede recibir un correo electrónico de un servidor de inserción mientras explora la red. Después de que la aplicación de correo electrónico ha enviado una confirmación, puede indicar que ha completado su transacción de datos. La aplicación de explorador puede comportarse de manera diferente y de hecho realizar una determinación predictiva (por ejemplo, utilizando un cronómetro de inactividad) de cuándo enviar una indicación de "realizado" al administrador de conexión.

Basándose en un estado compuesto de algunas indicaciones de aplicaciones activas, el software de UE puede decidir enviar una indicación de transición para indicar o solicitar de la red que una transición de un estado o modo a otro debe presentarse. De manera alternativa, el software de UE puede esperar de hecho antes de que envíe la indicación de transición e introducir un retardo para asegurar que la aplicación se termine verdaderamente con el intercambio de datos y no requiera que se mantenga en un estado o modo de batería o intenso de recursos de radio. El retardo puede ser dinámico basándose en un historial de tráfico y/o perfiles de aplicación. Siempre que el administrador de conexión determine con cierta probabilidad de que ninguna aplicación se espera a intercambiar datos, puede enviar una indicación de transición a la red para indicar que una transición debe presentarse. 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 adecuado (por ejemplo, dominio de 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 UTRA .

Como se describe en lo anterior en detalle adicional, 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 tal como la UTRAN en un ambiente de UMTS puede decir hacer transición del UE desde un estado o modo a otro .

Otras indicaciones de transición son posibles. Por ejemplo, en lugar de basarse en un estado compuesto de todas las aplicaciones activas en el UE, el software de UE en una modalidad ejemplar, puede enviar una indicación de transición cada vez que una aplicación de UE ha completado un intercambio o datos y/o la aplicación no se espera que intercambie datos adicionales. En este caso, el elemento de red (por ejemplo, la UTRAN) basándose 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 aún otro ejemplo, la indicación de transición podría indicar simplemente que una o más aplicaciones en el UE complementaron un intercambio de datos y/o que las aplicaciones de UE no se espera que intercambien datos adicionales. Basándose en esta indicación de un perfil de recursos de radio opcional para el UE, la red (por ejemplo, UTRAN) , puede decidir si hace transición o no del UE a un estado o modo adecuado u operación.

En un ejemplo adicional, 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 informe de estado enviado periódicamente. Tal informe de estado podría incluir información tal como si una memoria intermedia de enlace de radio tiene datos o podría incluir información o 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 una decisión para actuar sobre la indicación. Esta información adicional puede incluir la razón o causa de que el UE envíe el mensaje. Esta causa o razón (explicada a continuación en mayor detalle) puede basarse en el UE que determina la necesidad de comportamiento similar a "estado rápido de latencia" . Tal 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 modalidad adicional, un cronómetro podría existir en el UE para asegurar que una indicación de transición pueda no enviarse hasta que haya transcurrido una duración de tiempo (duración de inhibición) puesto que se envío una indicación de transición previa. Este cronómetro de inhibición evita que el UE envíe el mensaje de indicación de transición con demasiada frecuencia y además permite a la red tomar una decisión al basarse en mensajes que se activan sólo con una frecuencia máxima determinada. La duración de tiempo podría determinarse por un cronómetro cuyo valor se preconfigura, o se establece por una red (indicada o señalada) . Si el valor se establece por una red, podría transportarse en mensajes nuevos o existentes, tales como - Solicitud de Conexión de RRC, Liberación de Conexión de RRC, Establecimiento de Portadora de Radio, Información de Movilidad de UTRAN o un Bloque de Información de Sistema, entre otros, y podría ser un elemento de información en estos mensajes. El valor podría transportarse alternativamente en una porción de indicación de transición de inhibición de un mensaje de establecimiento de conexión de RRC enviado por la UTRAN en respuesta a un mensaje de Solicitud de Conexión de RRC recibido desde el UE, por ejemplo.

En una modalidad alternativa, el valor podría transportarse 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 célula como una porción de un mensaje de información del sistema el cual se lee por el UE cuando se encuentra en un estado de INACTIVO, URA_PCH, Cell_PCH o CELL_FACH .

En aún otra modalidad, el valor podría enviarse como una porción de un mensaje de establecimiento de conexión de RRC.

Los mensajes generados por red también pueden transportar un valor del cronómetro de inhibición implicado a través de la no inclusión de un cronómetro de inhibición en el mensaje o en un elemento de información dentro del mensaje. Por ejemplo, al determinar que un cronómetro de inhibición se omite de un mensaje recibido, un UE aplica un valor pre-determinado para su uso como valor del cronómetro de inhibición. Un uso ejemplar de la omisión de valor del cronómetro de inhibición es evitar 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 del cronómetro de inhibición esperado en un mensaje recibido, el UE, basándose en la omisión, se le impide enviar cualquier mensaje de indicación de transición. Una forma de lograr esto es que el UE adopte un valor del cronómetro de inhibición de infinidad.

En otra modalidad, cuando el UE detecta la omisión de un valor del cronómetro de inhibición (y, por ejemplo, adopta un valor del cronómetro de inhibición de infinidad) , 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 (descrita adicionalmente a continuación en mayor detalle) . La omisión de un elemento de causa en un mensaje de indicación de transición puede asegurar una retro-compatibilidad al permitir que los UE utilicen, un mensaje de indicación de transición existente (por ejemplo INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN) para solicitar o indicar una transición .

La no inclusión de un cronómetro de inhibición en el mensaje recibido además se detalla con referencia a una modalidad ejemplar en donde se difunde un Bloque de Información de Sistema en una celda, o se envía a un UE y el Bloque de Información de Sistema se configura para transportar un valor del cronómetro de inhibición. En esta modalidad, si el UE recibe un Bloque de Información de Sistema que no contiene un cronómetro 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, al establecer el cronómetro de inhibición, T3xx, en infinidad.

La no inclusión de un cronómetro de inhibición además se detallada con referencia a otra modalidad ejemplar en donde un cronómetro de inhibición, T3xx, se omite de un mensaje de información de Movilidad de UTRA . En tal situación, un UE receptor puede continuar aplicando un valor del cronómetro de inhibición almacenado previamente. Alternativamente, el UE, al detectar la omisión del cronómetro de inhibición T3xx, puede determinar no permitir que el UE envíe el mensaje de indicación de transición, por ejemplo, al establecer el cronómetro de inhibición, T3xx, en infinidad.

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

En otras modalidades, si el cronómetro de inhibición (valor) no se envía o se señala al UE en un mensaje o elemento de información, o el cronómetro de inhibición no se lee de la información del sistema de difusión o se recibe de otros mensajes de UTRAN dedicados al hacer transición de una célula a otra, el envío de una indicación de transición puede o no presentarse.

Específicamente, en una modalidad el UE al detectar que no existe ningún cronómetro de inhibición presente, no inicia una indicación de transición basándose en una mayor capa que determina que no tiene más datos de PS que transmitir .

En una modalidad alternativa, el UE al detectar que no existe ningún cronómetro de inhibición presente, puede iniciar una indicación de transición basándose en la capa mayor que determina que no tiene más datos de PS que transmitir .

En aún otra modalidad, si ningún valor del cronómetro se recibe desde la UTRAN dentro de un mensaje, o dentro de un elemento de información en un mensaje (mediante difusión u otra) , en lugar de establecer el valor del cronómetro en el UE en infinidad, el UE puede establecer el cronómetro de inhibición en cero o alternativamente borrar cualquier configuración para el cronómetro, y en su lugar permitir que envíe una indicación de transición. En este caso, el UE podría omitir o verse forzado a no anexar una causa en el mensaje de indicación de transición. En una modalidad, un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se utiliza como un ejemplo de una indicación de transición.

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

Específicamente, de acuerdo con la 25.331 Sección 8.1.14.2, el UE debe, al recibir una solicitud para liberar la conexión de señalización desde las capas superiores para un dominio de CN específico, comprobar si la conexión de señalización en la variable " ESTABLISHED_SIGNALLING_CONNECTIONS para el dominio de CN específico identificado en el elemento de información "identidad de dominio de CN" existe. 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 del valor del cronómetro de inhibición que no se señala o se transporta de otra manera al UE, ninguna causa de indicación de liberación de conexión de señalización se especifica en el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN. Aquellos con experiencia en la técnica apreciarán que en esta modalidad alternativa, la falta de un valor del cronómetro no resulta en que el valor del cronómetro se establezca en infinidad.

En el lado de la UTRAN, con la recepción de un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN sin una causa, la UTRAN indica la liberación de la conexión de señalización para la identidad de dominio de CN identificada en las capas superiores. Entonces esto puede iniciar la liberación de la conexión de control de recursos de radio establecida.

Bajo otra modalidad alternativa, cuando la UTRA señala o transporta un valor del cronómetro al UE, por ejemplo, el cronómetro de inhibición T3xx en el elemento de información "los cronómetros de UE y las constantes en el modo conectado" (o utilizando información del sistema, tal como SIBl, SIB3 o SIB4, o con un mensaje de información movilidad de UTRAN dedicado) , el procedimiento de liberación se presenta de acuerdo con lo siguiente. En primer lugar, el UE puede comprobar si existe alguna conexión de dominio conmutada por circuitos indicada. Tales conexiones pueden indicarse en la variable "ESTABLISHED_SIGNALLING_CONNECTIONS" . Si no existe ninguna conexión de dominio conmutada por circuitos, una segunda comprobación para determinar si una capa superior indica que no existirán datos de dominio conmutados por paquetes durante un período prolongado, podrían presentarse.

Si no existen conexiones de dominio conmutadas por circuitos y no se esperan datos de dominio conmutados por paquetes durante un período prolongado, el UE puede comprobar después si el cronómetro T3xx funciona.

Si el cronómetro T3xx no funciona, el UE establece el elemento de información "identidad de dominio de CN" en el dominio conmutado por paquetes (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 "finalización de sesión de datos de PS solicitada por UE" . El mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se transmite al DCCH utilizando AM RLC . Además, después de la transmisión, se inicia el cronómetro T3xx.

El procedimiento anterior finaliza con la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONE IÓN DE SEÑALIZACIÓN, cuando se confirma por el RLC en el procedimiento anterior. En esta modalidad, se evita que el UE envíe el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN con una causa de indicación de liberación de conexión de señalización establecida "Finalización de sesión de datos de PS solicitada por UE", mientras que el cronómetro T3xx funciona o hasta que haya terminado el cronómetro T3xx.

Cuando el cronómetro T3xx funciona, si el procedimiento de indicación de liberación de conexión de señalización se inicia debido a que no existen datos de dominio conmutados por paquetes adicionales por una duración prolongada, el UE es responsable de implementar si inicia el procedimiento con la finalización del cronómetro 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 subsiguiente o mensajes de solicitud que enviar y si es así, la decisión del UE puede incluir volver a comprobar parte o todas las mismas comprobaciones para iniciar el procedimiento como se describe en la presente.

En el lado de UTRAN, si el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN 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 entonces puede iniciar la liberación de la conexión de señalización. Si por otro lado el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN 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 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 en que el UE puede necesitar hacer transición. Por ejemplo, la duración de inhibición puede ser diferente, si la unidad móvil indicó su última preferencia para algunos Estados/modos de RRC contra otros. Por ejemplo, podría ser diferente si la unidad móvil indicó una preferencia para el modo inactivo, versus Estados de Cell_FACH, o contra Cell_PCH/URA PCH. En el caso donde la duración de inhibición se establece por la red, esto puede lograrse por la red que indica/envía dos conjuntos (o más) de valores a la unidad móvil, que se utiliza dependiendo del escenario. Alternativamente, la indicación podría realizarse de tal manera que el valor de duración de inhibición adecuado sólo se indica/señala en la unidad móvil: por ejemplo, si el UE desea hacer transición a Cell_PCH, podría establecerse una duración de tiempo transcurrida diferente a si el usuario desea transición al modo inactivo La duración de inhibición de lo anterior puede ser diferente, dependiendo de en cuál modo/Estado de RRC se encuentra actualmente la unidad móvil (por ejemplo, Cell_DCH/Cell_FACH contra Cell_PCH/URA_PCH, o en Cell_DCH contra Cell_FACH o Cell_PCH/URA_PCH) .

La duración de inhibición de lo anterior puede ser diferente, dependiendo de si la red ya ha actuado sobre la información de Estado de RRC de preferencia desde la unidad móvil. Tal reconocimiento puede suceder en la red, o en el lado de la unidad móvil. En el primer caso, esto puede afectar los valores de inhibición indicados/señalados por la red a la unidad móvil. En este segundo caso, diferentes conjuntos de valores de duración de inhibición pueden pre-configurarse o indicarse/señalarse por la red. Como caso particular, la duración/funcionalidad de inhibición puede reducirse o cancelarse si la red ha actuado sobre la información de Estado de RRC de preferencia desde la unidad móvil, por ejemplo, ha iniciado una transición de estado a un estado indicado por el UE.

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

Un número máximo de mensajes por ventana de tiempo (por ejemplo, "no más de 15 mensajes cada 10 minutos") puede utilizarse/especificarse en lugar de, o además de, la inhibición de duración.

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

A manera de ejemplo, la presente descripción generalmente describe la recepción de un mensaje de SOLICITUD DE CONEXIÓN DE RRC por una UTRAN a partir de un UE. Al recibir un mensaje de SOLICITUD DE CONEXIÓN DE RRC, la UTRAN debe, por ejemplo, aceptar la solicitud y enviar un mensaje de ESTABLECIMIENTO DE CONEXIÓN DE RRC al UE . El mensaje de ESTABLECIMIENTO DE CONEXIÓN DE RRC puede incluir una indicación de transición de inhibición, que se conoce como Cronómetro T3xx. Con la recepción del mensaje de ESTABLECIMIENTO DE CONEXIÓN DE RRC por el UE, el UE debe, por ejemplo, almacenar el valor del cronómetro T3xx, reemplazando cualquier valor previamente almacenado, o, si el cronómetro T3xx no se encuentra en el mensaje de ESTABLECIMIENTO DE CONEXIÓN DE RRC, establecer el valor del cronómetro en infinidad. En algunas modalidades, el mensaje de ESTABLECIMIENTO DE CONEXIÓN DE RRC debe incluir una Indicación de Transición de Inhibición para asegurar que el UE conozca que la UTRAN soporta la señalización de INDICACIÓN DE TRANSICIÓN DE INHIBICIÓN.

En una modalidad, se supone que durante la movilidad de un estado de DCH, el UE mantendrá su valor actualmente almacenado para el cronómetro de inhibición. En algunos casos, donde el cronómetro de inhibición se establece en infinidad, esto puede significar que el UE debe esperar que los cronómetros de inactividad de datos de red finalicen y que la red mueva al UE a un estado de RRC donde pueda recibir o determinar un nuevo valor para el cronómetro de inhibición. En otros casos donde el cronómetro de inhibición es cierto valor diferente a infinidad antes de la transferencia, este otro valor se continúa utilizando hasta que el UE es capaz de actualizar el valor del cronómetro a aquel indicado en la nueva celda.

En algunos casos, el cronómetro de inhibición y el mensaje de indicación de transición (por ejemplo, INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN) pueden no implementarse en algunas redes o en algunas celdas dentro de una red. Para propósitos de movilidad, si no existe ningún soporte disponible para la característica de enviar una indicación de transición o mensaje de solicitud (particularmente en el caso donde se utiliza una causa) , el UE debe establecer por defecto no enviar el mensaje. Esto evita transmisiones innecesarias y el desperdicio asociado de recursos de red y recursos de batería.

Además, para propósitos de movilidad, un equipo de red de vendedor diferente es utiliza dentro de una red puede llevar a celdas adyacentes que utilizan diferentes cronómetros de inhibición que necesitan actualizarse en el UE cuando el UE se mueve entre celdas .

En una modalidad alternativa, esto se maneja al estipular que toda la transferencia y mensajes de control de portadora relacionados incluyen un valor para un cronómetro de inhibición T3xx. Tales mensajes se denominan en la presente como mensajes de movilidad. Esto permite al UE recibir nuevos valor del cronómetro de inhibición cuando se mueve entre celdas. También permite que el UE establezca un valor del cronómetro por defecto para el cronómetro de inhibición si uno de estos mensajes de movilidad no contiene un valor del cronómetro de inhibición. Como se apreciará, si ningún valor del cronómetro de inhibición se recibe en los mensajes de movilidad, esto indica que la celda no se habilita para estado de latencia rápido.

Como otro ejemplo de un procedimiento de indicación de transición, un procedimiento de Indicación de Transferencia Completa de Datos puede utilizarse por el UE para indicar a la UTRAN que ha determinado que no necesita transferir más datos de dominio de PS. Junto con el ejemplo antes descrito, el UE puede no enviar el mensaje de Indicación de Transferencia Completa de Datos antes de que el cronómetro T3xx haya terminado, si el cronómetro T3xx se encontraba funcionando .

El procedimiento de Indicación de Transferencia Completa de Datos comienza con una indicación de que el RRC o capas superiores no tendrán más datos de dominio de PS por una duración prolongada. Si una conexión de dominio de CS se indica en la variable ESTABLISHED_SIGNALLING_CON ECTIONS o si el cronómetro T3xx se establece en infinidad, el procedimiento finaliza. De otra manera, si el cronómetro T3xx no funciona (es decir, ha finalizado) o se establece en 0 segundos, un mensaje de INDICACIÓN DE TRANSFERENCIA COMPLETA DE DATOS se envía a las capas inferiores para la transmisión utilizando un AM RLC en DCCH después de que se inicia el cronómetro T3xx o se restablece cuando el mensaje se ha entregado a las capas inferiores .

La UTRAN con la recepción de la INDICACIÓN DE TRANSFERENCIA COMPLETA DE DATOS puede decidir iniciar una transición de UE a un estado de RRC de batería más eficiente o modo inactivo.

El UE no debe enviar el mensaje de Indicación de Transferencia Completa de Datos mientras funciona el cronómetro T3xx.

La presente descripción permite que el método controle 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 descripción además proporciona 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 de usuario.

La presente descripción además proporciona un método en un equipo de usuario (UE) para enviar una indicación de transición, el método comprende establecer un cronómetro de acuerdo con una indicación de transición de inhibición recibida desde un elemento de red; detectar que una transferencia de datos se encuentra completa; y enviar la indicación de transición al detectar que el cronómetro no se encuentra funcionando.

La presente descripción aún proporciona equipo de usuario configurado para enviar una indicación de transición, el equipo de usuario configurado para: establecer un cronómetro de acuerdo con una indicación de transición de inhibición recibida desde un elemento de red; detectar que una transferencia de datos se encuentra completa; y enviar la indicación de transición al detectar que el cronómetro no se encuentra funcionando.

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

Como se apreciará por aquellos con experiencia en la técnica, una red de UMTS consiste de dos segmentos de red con base terrestre. Estos son la Red Central (CN) y la Red de Acceso por Radio Terrestre Universal (UTRA ) (como se ilustra en la Figura 8) . La Red Central es responsable de la conmutación y enrutamiento de las llamadas de datos y las conexiones de datos a las redes externas, mientras la UTRAN maneja todas las funcionalidades relacionadas con radio.

En modo 110 inactivo, el UE debe solicitar una conexión de RRC para establecer el recurso de radio siempre que los datos necesiten intercambiarse entre el UE y la red. Esto puede ser como resultado de una aplicación en el UE que requiere que una conexión envíe datos, o como resultado del UE que monitorea un canal de búsqueda para indicar si la UTRAN o SGSN han buscado el UE para recibir ' datos desde una red de datos externa tal como un servidor de inserción. Además, el UE solicita una conexión de RRC siempre que necesita enviar mensajes de señalización de Manejo de Movilidad, tal como Actualización de Á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 en que estado quiere estar para la conexión de RRC. De manera específica, el modo 120 conectado de RRC incluye cuatro estados separados. Estos son estado 122 CELL_DCH, estado 124 CELL_FACH, estado 126 CELL_PCH y estado 128 URA_PCH.

A partir del modo 110 inactivo, el UE hace transición de manera autónoma al estado 124 CELL_FACH, en el cual hace su transferencia de datos inicial, subsiguiente a cuál red determina qué estado conectado de RRC utilizar para la transferencia de datos continua. Esta puede incluir la red que mueve el UE hacia el estado 122 de Canal Dedicado de Celda (CELL_DCH) o mantiene el UE en el estado 124 de Canal de Acceso sin Retorno de Celda (CELL_FACH) .

Un estado 122 de CELL_DCH, un canal dedicado se asigna al UE para el enlace ascendente y enlace descendente para intercambiar datos. Este estado, puesto que tiene un canal físico dedicado asignado al UE, típicamente requiere mayor energía de batería del UE .

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

Dentro del modo 120 conectado de RRC, el estado de RRC puede cambiarse a discreción de la UTRAN. De manera específica, si la inactividad de datos se detecta por una cantidad de tiempo específica o se detecta una producción de datos por debajo de un cierto umbral, la UTRAN puede mover el estado de RRC desde el estado 122 de CELL_DCH hasta el estado 124 de CELL_FACH, el estado 126 de CELL_PCH o el estado 128 DE URA_PCH. De manera similar, si se detecta que la carga útil se encuentra por encima de un cierto umbral, entonces el estado de RRC puede moverse del estado 124 de CELL_FACH al estado 122 de CELL_DCH.

A partir del estado 124 de CELL_FACH, si la inactividad de datos se detecta por un tiempo predeterminado en algunas redes, la UTRA puede mover el estado de RRC desde el estado 124 de CELL_FACH hasta un estado de canal de búsqueda (PCH) . Éste puede ser el estado 126 de CELL_PCH o el estado 128 DE URA_PCH.

A partir del estado 126 de CELL_PCH o el estado 128 de URA_PCH, el UE debe mover el estado 124 de CELL_FACH para iniciar un procedimiento de actualización para solicitar un canal dedicado. Ésta es la única transición de estado que controla el UE.

El modo 110 inactivo y el estado 126 de CELL_PCH y el estado 128 de URA_PCH utilizan un ciclo de recepción discontinua (DRX) para monitorear mensajes de difusión y búsqueda por un Canal Indicador de Búsqueda (PICH) . No es posible actividad de enlace ascendente.

La diferencia entre el estado 126 de CELL_PCH y el estado 128 de URA_PCH, es que el estado 128 de URA_PCH solo activa un procedimiento de Actualización de URA si el área de registro de UTRAN (URA) actual del UE no se encuentra entre la lista de identidades de URA presentes en la celda actual. De manera específica, se hace referencia a la Figura 2. La Figura 2 muestra una ilustración de varias celdas 210, 212 y 214 de UMTS . Todas estas celdas requieren un procedimiento de actualización de celda si se re-selecciona un estado de CELL_PCH. Sin embargo, en un área de registro de UTRAN, cada una se encontrará dentro de la misma área 320 de registro de UTRAN (URA) , y de este modo un procedimiento de actualización de URA no se activa cuando se mueve entre 210, 212 y 214 cuando se encuentra en un modo de URA_PCH.

Como se ve en la Figura 2, otras celdas 218 se encuentran fuera de la URA 320, y pueden ser parte de una URA separada o ninguna URA.

Como se apreciará por aquellos con experiencia en la técnica a partir de una perspectiva de vida de batería, el estado inactivo proporciona el uso de batería más bajo en comparación con los estados anteriores. De manera específica, debido a que se requiere que el UE monitoree el canal de búsqueda solo en intervalos, la radio no necesita encontrarse continuamente encendida, pero de hecho se activará periódicamente. El intercambio para esto es la latencia para enviar datos. Sin embargo, si esta latencia no es demasiado grande, las ventajas de encontrarse en el modo inactivo y ahorrar energía de batería superan las desventajas de la latericia de conexión.

Nuevamente se hace referencia a la Figura 1. Varios vendedores de infraestructura de UMTS se mueven entre estados 122, 124, 126 y 128 basándose en diversos criterios. Estos criterios podrían ser en las referencias del operador de red con respecto al ahorro de señal o al ahorro de los recursos de radio, en otros. Infraestructuras ejemplarse se describen a continuación.

En una primera infraestructura ejemplar, el RRC se mueve entre un modo inactivo y un estado de CELL_DCH directamente después de iniciar el acceso en un estado de CELL_FACH. En el estado de CELL_DCH, si dos segundos de inactividad se detectan, el estado de RRC cambia a un estado 124 de CELL_FACH. Si en se detectan diez segundos de inactividad en el estado 124 de CELL_FACH, entonces el estado de RRC cambia el estado 126 de CELL-PCH. Cuarenta y cinco minutos de inactividad en el estado 126 de CELL_PCH resultará en que el estado de RRC regrese al modo 110 inactivo.

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

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

En una cuarta infraestructura ejemplar, el RRC hace transición de un modo inactivo a un modo conectado directamente en un estado 122 de CELL_DCH. En la cuarta infraestructura ejemplar, el estado 122 de CELL_DCH incluye dos configuraciones. La primera incluye una configuración la cual tiene una tasa de datos elevada y una segunda configuración incluye una tasa de datos más baja, pero aún se encuentra dentro del estado de CELL_DCH . En la cuarta infraestructura ejemplar, el RRC hace transición del modo 110 inactivo directamente al sub-estado de CELL_DCH de alta tasa de datos. Después de 10 segundos de inactividad, el estado de RRC hace transición a un sub-estado de CELL_DCH de baja tasa de datos. Diecisiete segundos de inactividad desde el sub-estado de baja tasa de datos del estado 122 de CELL_DCH resultan en un estado de RRC que lo cambia al modo 110 inactivo .

Las cuatro infraestructuras ejemplares anteriores muestran cómo varios vendedores de infraestructura de UMTS que implementan los estados. Como se apreciará por aquellos con experiencia en la técnica, en cada caso, si el tiempo gastado en intercambiar datos actuales (tal como un correo electrónico) es significativamente corto en comparación con el tiempo que se requiere para permanecer en los estados de CELL_DCH o de CELL_FACH. Esto provoca un consumo de corriente innecesario, haciendo de la experiencia de usuario en redes de generación más nueva tales como UMTS, peor que en las redes de generación previa tales como GPRS .

Además, aunque el estado 126 de CELL_PCH es más óptimo que el estado 124 de CELL_FACH a partir de una perspectiva de vida de batería, el ciclo de DRX en un estado 126 de CELL_PCH típicamente se establece en un valor menor que el modo 110 inactivo. Como resultado, se requiere que UE se active con mayor frecuencia en el estado 126 de CELL_PCH que en el modo 110 inactivo.

El estado 128 de URA_PCH con un ciclo de DRX similar aquel del estado 110 inactivo es probable el intercambio óptimo entre la vida de batería y la latencia para conexión. Sin embargo, el estado 128 de URA_PCH actualmente no se implementa en la UTRAN. En algunos casos, por lo tanto es deseable hacer transición rápidamente al modo inactivo tan rápido como sea posible después de que se termina una aplicación con el intercambio de datos, a partir de una perspectiva de vida de batería.

Ahora se hace referencia a la Figura 3. Cuando se hace transición de un modo inactivo a un modo conectado, varias conexiones de señalización y datos necesitan hacerse. Con referencia a la Figura 3, el primer elemento que va a realizarse es una configuración 310 de conexión de RRC. Como se indica en lo anterior, esta configuración 310 de conexión de RRC sólo puede desmantelarse por la UTRAN.

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

Una vez que se termina la configuración 312 de conexión de señalización, se inicia una configuración 314 de cifrado e integridad. Con la finalización de esto, se logra una configuración 316 de portadora de radio. En este punto, los datos pueden intercambiarse entre el UE y la UTRAN.

La desmantelación de una conexión se logra de manera similar en el orden inverso, en general. La configuración 316 de portadora de radio se desconecta y después la configuración 310 de conexión de RRC se desconecta. En este punto, el RRC se mueve al modo 110 inactivo como se ilustra en la Figura 1.

Aunque la especificación del 3GPP actual no permite al UE liberar la conexión de RRC o indicar su preferencia por el estado de 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 Conmutado por Paquetes (PS) utilizado por las aplicaciones conmutadas por paquetes. De acuerdo con la sección 8.1.14.1 de la TS 25.331 del 3GPP, el procedimiento de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se utiliza por el UE para indicar a la UTRAN que una de sus conexiones de señalización se ha liberado. Este procedimiento puede iniciar a su vez el procedimiento de liberación de conexión de RRC.

De este modo, permanecer dentro de las especificaciones del 3GPP actuales, la liberación de conexión de señalización puede iniciarse con el desmantelamiento de la configuración 312 de conexión de señalización. Se encuentra dentro de la capacidad del UE desmantelar la configuración 312 de conexión de señalización, y éste a su vez de acuerdo con la especificación "puede" iniciar la liberación de conexión de RRC.

Como se apreciará por aquellos con experiencia en la técnica, la configuración 312 de conexión de señalización se desmantela, la UTRAN también necesitará limpiar la configuración 314 de descifrado e integridad y la configuración 316 de portadoras de radio después de que se ha desmantelado la configuración 312 de conexión de señalización .

Si se desmantela la configuración 312 de conexión de señalización la configuración de conexión de RRC típicamente se desmantela por la red para las infraestructuras de vendedor actuales si no se encuentra activa la conexión de CS .

Al utilizar esto para uno de los ejemplos de indicación de transición específicos mencionados en lo anterior, si el UE determina, por ejemplo, que se realiza con el intercambio de datos, si se proporciona un componente de "administrador de conexión" del software de UE con una indicación de que el intercambio de datos se completa, entonces el administrador de conexión puede determinar si desmantela 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 una confirmación del servidor de inserción de correo electrónico de que el correo electrónico de hecho se recibió por el servidor de inserción. El administrador de conexión en una modalidad, puede estar al tanto de todas las aplicaciones existentes, contextos de PDP asociados, recursos de radio de PS asociados y portadoras de radio conmutadas por circuitos (CS) asociadas. En otras modalidades, un elemento de red (por ejemplo, la UTRAN) puede estar al tanto de las aplicaciones existentes, contextos de PDP asociados, QoS, recursos de radio PS asociados y portadoras de radio CS asociadas . Puede introducirse un retardo en el UE o elemento de red para asegurar que las aplicaciones se terminen verdaderamente con el intercambio de datos y no se requiera más una conexión de RRC incluso después de que se ha enviado las indicaciones "realizada". Este retardo puede hacerse equivalente a un tiempo fuera de inactividad asociado con las aplicaciones o el UE. Cada aplicación puede tener su propio tiempo fuera de inactividad y de este modo el retardo puede ser un compuesto de todos los tiempos fuera de aplicación. Por ejemplo, una aplicación de correo electrónico puede tener un tiempo fuera de inactividad de cinco segundos, mientras que una aplicación tipo explorador activo puede tener un tiempo fuera de sesenta segundos. Un cronómetro de duración de inhibición además puede retardar el envío de una indicación de transición. Basándose en un estado compuesto de todas las indicaciones de aplicaciones activas, así como un perfil de recursos de radio y/o un retardo de cronómetro de duración de inhibición en algunas modalidades, el software de UE decide cuánto tiempo debería o debe 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 adecuada (por ejemplo, dominio de PS) . Si el retardo se implementa en el elemento de red, el elemento hace una determinación en cuando a si y cómo hacer transición al UE, pero sólo opera la transición después de que haya recorrido su curso el retardo.

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

Si el elemento de red hace transición al UE al modo 110 inactivo, lo cual puede suceder en cualquier fase del modo 120 conectado de RRC, como se ilustra en la Figura 1, el elemento de red libera la conexión de RRC y mueve el UE al modo 110 inactivo como se ilustra en la Figura 1. Esto también se puede aplicar cuando el UE realiza cualquiera de los servicios de datos por paquete durante una llamada de voz. En este caso, la red puede elegir liberar sólo la conexión de señalización de dominio de PS, y mantener la conexión de señalización de dominio de CS o alternativamente puede elegir no liberar nada y en su lugar mantener las conexiones de señalización en ambos dominios de PS y CS .

En una modalidad adicional, un caso podría agregarse a la indicación de transición que índica a la UTRAJXI la razón de la indicación. En una modalidad preferida, el caso puede hacer una indicación que un estado anormal provocó la indicación o que la indicación se inicio por el UE como resultado de una transición solicitada. Otras transacciones normales (es decir, no anormales) también podrían resultar en el envío de la indicación de transición.

En una modalidad preferida adicional, varios tiempos fuera pueden provocar que una indicación de transición se envíe para una condición anómala. Los ejemplos de los cronómetros siguientes no son exhaustivos, y otros cronómetros o condiciones anormales son posibles. Por ejemplo, 10.2.47 de la TS 24.008 del 3GPP especifica el cronómetro T3310 como: CRONOMETRO T3310 Este cronómetro se utiliza para indicar una falla de conexión. La falla de conexión podría ser un resultado de la red o podría ser un problema de radiofrecuencia (RF) tal como colisión o RF mala.

El intento de conexión podría presentarse varias veces, y una falla de conexión resulta de un número predeterminado de fallas o un rechazo explícito.

Un segundo cronómetro de 10.2.47 del 3GPP es el cronómetro T3330, el cual se especifica como: CRONÓMETRO T3330 Este cronómetro se utiliza para indicar una falla de actualización de área de enrutamiento . Con la expiración del cronómetro, una actualización de área de enrutamiento adicional podría solicitarse varias veces y una falla de actualización de área de enrutamiento resulta de un número predeterminado de fallas o un rechazo explícito.

Un tercer cronómetro de 10.2.47 del 3GPP es el cronómetro T3340, el cual se especifica como: CRONOMETRO T Este cronómetro se utiliza para indicar una falla de solicitud de servicio de GMM. Tras la finalización del cronómetro, una solicitud de servicio de GMM adicional podría iniciarse varias veces y una falla de solicitud de servicio de GMM resulta de un número predeterminado de fallas o un rechazo explícito.

De este modo, en lugar de una causa de indicación de transición limitada a una condición anormal y una liberación por el UE, la causa de indicación de transición podría incluir además información sobre cuál cronómetro falló para una condición anormal. En un ejemplo específico donde una indicación de liberación de conexión de señalización se utiliza como una indicación de transición, la indicación podría estructurarse como: INDICACION DE LIBERACION DE CONEXION DE SEÑALIZACION Este mensaje se utiliza 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 a la UTRAN o a otro elemento de red recibir la causa de la indicación de liberación de conexión de señalización, si fue debió a una condición anormal, y cuál fue la condición anormal. Basándose en la recepción de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, un procedimiento de liberación de conexión de RRC se permite a su vez iniciar 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 de capas superiores para un dominio de CN específico ( red central), inicia el procedimiento de indicación de liberación de conexión de señalización si se identifica una conexión de señalización en una variable, por ejemplo una variable ESTABLISHED_SIGNALING_CO ECTIONS para el dominio de CN especifico identificado con el IE (elemento de información) existe "identidad del dominio de CN" . Si la variable no identifica ninguna conexión de señalización existente, cualquier establecimiento en proceso de una conexión de señalización para este dominio CN específico se aborta entre otra manera. Con el inicio de los procedimientos de indicación de liberación de conexión de señalización en los estados de CELL_PCH o URA_PCH, el UE realiza un procedimiento de actualización de celda utilizando una causa "transmisión de datos de enlace ascendente". Cuando se completa un procedimiento de actualización de celda con éxito, el UE continúa con los procedimientos de indicación de liberación de conexión de señalización que siguen.

Particularmente, el UE establece el elemento de información (IE) "identidad de dominio DE CN" en el valor indicado por las capas lógicas superiores . El valor del IE indica el dominio de CN cuya conexión de señalización asociada en las capas superiores hace que se liberen. Si la identidad de dominio de CN se establece en el dominio de PS , y si la capa superior indica la causa de iniciar esta solicitud, entonces el IE "CAUSA DE INDICACIÓN DE LIBERACIÓN DE SEÑALIZACIÓN" se establece por consiguiente. El UE además remueve 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 INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en, por ejemplo, el Canal de Control Dedicado (DCCH) utilizando el control de enlace de radio del modo confirmado (AM RLC) . Con la confirmación de una entrega éxitos del mensaje de indicación de liberación por el RLC, el procedimiento finaliza.

Una "Causa de Indicación de Liberación de Conexión de Señalización" de IE también se utiliza conforme a una modalidad de la presente descripción. La causa de liberación se alinea, por ejemplo, con las definiciones de mensajes existentes. El mensaje de causa de liberación de capa superior se estructura, por ejemplo, como: En este ejemplo, las expiraciones de T3310, T330 y T3340 corresponden con la expiración de los cronómetros enumerados por consiguiente, identificados previamente. Un valor de causa se puede establecer, en una implementación, como una "finalización de sesión de Datos de PS Solicitada por UE" en lugar de una "transición inactiva Solicitada por UE" para suprimir una indicación de UE de una preferencia de una transición inactiva y proporcionar a la UTRA para decidir sobre la transición de estado, aunque el resultado esperado corresponde con uno identificado por el valor de causa. La extensión a la indicación de liberación de conexión de señalización de preferencia, aunque no necesariamente, es 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 ejemplar que monitorea si envía o no una indicación de liberación de conexión de señalización para varios dominios (por ejemplo, PS o CS) . El proceso inicia en la etapa 910.

El UE hace transición a la etapa 912 en la cual comprueba para ver si existe una condición anormal. Tal condición anormal puede incluir, por ejemplo, el cronómetro T3310, el cronómetro T3320 o el cronómetro T3340 que termina como se describe en lo anterior. Si estos cronómetros expiran un cierto número predeterminado de veces o si se recibe un rechazo explícito basándose en la finalización de cualquiera de estos cronómetros, el UE procede a la etapa 914 en la cual envía una indicación de liberación de conexión de señalización. El mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se anexa 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 por lo menos que la indicación de liberación de señalización se basa en una condición anormal o estado y una modalidad incluye el cronómetro específico que termina o para dar como resultado en la condición anormal.

Inversamente, si en las etapas 912 el UE no encuentra que existe alguna condición anormal, el UE procede a la etapa 920 en la cual comprueba si datos adicionales se esperan en el UE . Esto, como se describe en lo anterior, puede incluir cuando un correo electrónico se envía y la confirmación del envío del correo electrónico se recibe nuevamente en el UE. Otros ejemplos de donde el UE determinará que no se esperan datos adicionales puede conocerse por aquellos de experiencia en la técnica.

Si en la etapa 920 el UE determina que la transferencia de datos se termina (o en el caso de un dominio conmutado por circuitos que se termina una llamada) , el UE procede a la etapa 922 en la cual envía una indicación de liberación de conexión de señalización en la cual el campo causa la 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 una finalización en la sesión de PS .

A partir de la etapa 920, si no se terminan los datos, el UE regresa y continua comprobando si existe una condición anormal en la etapa 912 y si los datos se terminan en la etapa 920.

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

El UE incluye elementos funcionales, y se pueden implementar , por ejemplo, por aplicaciones o algoritmos llevadas a cabo a través de la operación de un microprocesador de UE o por implementación de hardware, que forman un comprobador y un emisor de indicación de transición. El comprobador se configura para comprobar si una indicación de transición debe enviarse. Y, un emisor de indicación de transición se configura para enviar una indicación de transición en respuesta a una indicación por el comprobador 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 de hecho se pone al tanto implícitamente del tiempo fuera de un cronómetro, y el UE no necesita enviar un valor de causa que indique el tiempo fuera del cronómetro. Es decir, el cronómetro comienza la sincronización, de la autorización de la red. Los códigos de causa se definen, y los códigos de causa se proporcionan por la red al UE. Tales códigos de causa se utilizan por el UE para iniciar el cronómetro. La red se encuentra implícitamente al tanto de la razón del tiempo fuera subsiguiente del cronómetro, ya que el código de causa enviado posteriormente por la red provoca que el cronómetro inicie la sincronización. Como resultado, el UE no necesita enviar un valor de causa que indique el tiempo fuera del cronómetro .

Como se sugiere por la Figura 9 así como la descripción anterior, una causa se puede incluir y se envía junto con una indicación de transición (por ejemplo, una INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN) para indicar: 1), una condición anormal así como 2.) una condición normal (no una condición anormal tal como por ejemplo una solicitud de finalización de sesión de datos de PS y/o una transición a un modo inactivo)). En varias 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 de una solicitud de una transición inactiva o una finalización de sesión de datos de PS, es decir, operación normal. Tal operación desde luego, también incluye operación de UE en la cual se agrega una causa a la indicación de transición sólo cuando una indicación de condición normal va a hacerse. Y, inversamente, tal operación también incluye operación de UE en la cual se agrega una causa a una indicación de transición sólo para indicar operaciones normales, es decir, no anormales y transacciones. Es decir, con respecto a la Figura 9, en tal operación alternativa, si en la etapa 912, existe una condición anormal, la ramificación sí se lleva a la etapa 914 aunque, si no existe una condición anormal, entonces el UE procede directamente la etapa 930 de finalización. Inversamente, en la otra operación alternativa, subsiguiente a la etapa 912 de inicio, una trayectoria se lleva directamente a la etapa 920 de finalización de datos. Si los datos se terminan, la ramificación sí se lleva a la etapa 920 y, después de esto a la etapa 930. Si no se termina los datos e la etapa 920, la ramificación no se lleva nuevamente a la misma etapa, es decir, etapa 920.

. Con referencia a la Figura 10, cuando un elemento de red recibe una indicación de transición en la etapa 1010, (por ejemplo, como se muestra una indicación de liberación de conexión de señalización) , el elemento de red examina el campo de causa de indicación de transición si se encuentra presente en la etapa 1014, y en la etapa 1016 comprueba si la causa es una causa anormal o si es debido al UE que solicita una transición inactiva y/o finalización de sesión de datos de PS . Si en la etapa 1016, la indicación de liberación de conexión de señalización es de causa anormal, el nodo de red procede en la etapa 1020 en la cual puede agregarse una alarma para monitoreo de rendimiento y propósitos de monitoreo de alarma. El indicador de rendimiento de claves puede actualizarse adecuadamente.

Inversamente, si en la etapa 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 resultado de una condicional anormal, o en otras palabras es el resultado del UE que solicitud una finalización de sesión de datos de PS o transición inactiva, el nodo de red procede a la etapa 1030 en la cual ninguna alarma se inicia y la indicación puede filtrarse de las estadísticas de rendimiento, por lo que se evita que se desvíen de las estadísticas de rendimiento. A partir de la etapa 1020 o la etapa 1030, el nodo de red procede a la etapa 1040 en la cual finaliza el proceso .

La recepción y examen de la indicación de transición puede resultar en el inicio por el elemento de red de la finalización de conexión de datos conmutados por 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 sugiere en lo anterior, en algunas implementaciones , la ausencia de una causa en una indicación de transición también puede utilizarse para determinar si la indicación de transición es resultado de una condición normal o una anormal y si debe iniciarse una alarma. Por ejemplo, si una causa se agrega sólo para denotar condiciones normales (es decir, no anormal tal como por ejemplo, una solicitud de finalización de sesión de datos de PS y/o transición a modo inactivo) y el elemento de red recibe una indicación de transición con una causa agregada, el elemento de red puede inferir a partir de la ausencia de una causa que la indicación de transición es un resultado de una condición anormal y opcionalmente iniciar una alarma. Inversamente, en otro ejemplo, si se agrega una causa sólo para denotar condiciones anormales, y el elemento de red recibe una indicación de transición sin causa, el elemento de red puede inferir a partir de la ausencia de una causa que la indicación de transición es resultado de una condición normal (por ejemplo, solicitud de finalización de sesión de datos de PS y/o una transición al modo inactivo) y no se inicia una alarma .

Como se apreciará por aquellos de experiencia en la técnica, la etapa 1020 puede utilizarse para distinguir adicionalmente entre varias condiciones de alarma. Por ejemplo, un tiempo fuera T3310 podría utilizarse para mantener un primer conjunto de estadísticas y un tiempo fuera de T3330 podría utilizarse para mantener un segundo conjunto de estadísticas. La etapa 1020 puede distinguir entre las causas de condición normal, por lo que permite al operador de red seguir el rendimiento de manera más eficiente.

La red incluye elementos funcionales, que se pueden implementar, por ejemplo, por aplicaciones o algoritmos llevados a cabo a través de la operación de un procesador o por implementación de hardware, que forman un examinador y un generador de alarma. El examinador se configura para examinar un campo de causa de indicación de transición de la indicación de transición. El examinador comprueba si el campo de la causa de indicación de transición indica una condición anormal . El generador de alarma se configura para genera de manera seleccionable una alarma si el examen por el 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, con la recepción de una indicación de liberación de conexión de señalización, la UTRAN reenvía la causa que se recibe y solicita, de capas superiores, la liberación de la conexión de señalización. Las capas superiores entonces son capaces de 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 la causa de capa superior del UE para activar el RRC del UE para enviar el mensaje. La causa es posiblemente el resultado de un procedimiento de capa superior anormal. La diferenciación de la causa del mensaje se asume a través de la recepción exitosa del IE.

Un escenario posible incluye un escenario en el cual, antes de la confirmación por el RLC de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, el restablecimiento del lado de transmisión de la entidad RLC en portadora RB2 de radio de señalización se presenta. En caso de tal aparición, el UE retransmite el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, por ejemplo, en el DCCH de enlace ascendente utilizando AM RLC en la portadora RB2 de radio de señalización. En caso de que se presente una transferencia inter-RAT (tecnología de acceso por radio) desde el procedimiento de UTRAN antes de la confirmación por el RLC de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN o de solicitud, el UE aborta la conexión de señalización cuando se encuentra en la nueva RA .

En una modalidad 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 de transferencia completa de datos". La funcionalidad similar a aquella descrita en las Figuras 9 y 10 anteriores se puede aplicar a esta indicación de transferencia completa de datos.

En una modalidad, la indicación de transferencia completa de datos se utiliza por el UE para informar a la UTRAN que el UE ha determinado de que no existe una transferencia de datos de dominio de CS en proceso, y ha completado su transferencia de datos de PS . Tal mensaje, por ejemplo, se envía desde el UE hasta la UTRAN en el DCCH utilizando AM RLC . Un mensaje ejemplar se muestra a continuación . 10.2.x INDICACIÓN DE TRANSFERENCIA COMPLETA DE DATOS Este mensaje se utiliza por el UE para informar a la UTRAN que el UE ha determinado de que no existe ninguna transferencia de datos de dominio de CS en proceso, y ha completado su transferencia de datos de PS .

RLC-SAP: AM Canal lógico: DCCH Dirección: UE-UTRAN Ahora se hace referencia a la Figura 20. La Figura 20 ilustra la modalidad dentro de la cual una indicación de transición o solicitud (por ejemplo, una indicación de liberación de conexión de señalización o una indicación de transferencia completa de datos) se envía desde el UE hasta la UTRAN. El proceso inicia en la etapa 2010 y procede a la etapa 2012 en la cual se hace una comprobación en el UE para determinar si las condiciones en el UE son adecuadas para enviar un mensaje de indicación de transición. Tales condiciones se describen en la presente descripción, por ejemplo, con referencia a la Figura 11 a continuación, y podría incluir una o más aplicaciones en el UE que determinan que se terminan con intercambio de datos . Tales condiciones también pueden incluir esperar cierta duración de tiempo para que el cronómetro T3xx expire si se encuentra funcionando.

En una modalidad adicional y alternativa, las condiciones pueden incluir evitar el envío de la indicación de transición si el cronómetro T3xx se establece en infinidad. Como se apreciará, T3xx podría incluir un número de valores discretos, de los cuales uno representa un valor de infinidad.

Si, en la etapa 2012, las condiciones no son adecuadas para enviar la indicación de transición o mensaje de solicitud, el proceso cicla en sí mismo y continua monitoreando hasta que las condiciones sean adecuadas para enviar la indicación de transición o mensaje de solicitud.

Una vez que las condiciones son adecuadas para procesar procede a la etapa 2020 en la cual una indicación de transición se envía a la UTRAN. Indicaciones ejemplares se muestran en las tablas anteriores.

El proceso entonces procede a la etapa 2022 en la cual se hace una comprobación para determinar si la indicación de transición tuvo éxito. Como puede apreciarse por aquellos de experiencia en la técnica 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. Si es sí, el proceso procede a la etapa 2030 y finaliza.

Inversamente, si se determina en la etapa 2022 que la indicación de transición no tuvo éxito, el proceso procede a la etapa 2024 y espera un período de tiempo. Tal espera podría implementarse utilizando una "duración de inhibición", por ejemplo T3xx, que puede no permitir a la unidad móvil enviar 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) . Una combinación de la duración de inhibición y el límite del número de mensajes dentro de un período de tiempo determinado también es posible.

La duración podría determinarse, tal como un valor definido en los estándares, y podría establecerse por un elemento de red, por ejemplo, como parte de una solicitud de conexión de RRC, un mensaje de establecimiento de conexión de RRC, una liberación de conexión de RRC, un establecimiento de portadora de radio, un mensaje de difusión de información de sistema, un mensaje de bloque de información de sistema, una ACTUALIZACIÓN DE CONJUNTO ACTIVO, una CONFIRMACIÓN DE ACTUALIZACIÓN DE CELDA, Mensaje de Información de Movilidad de UTRAN, una Transferencia al Comando de UTRAN, un Mensaje de Reconfiguración de Canal Físico, un Mensaje de Reconfiguración de Portadora de Radio, un Mensaje de Liberación de Portadora de Radio, un Mensaje de Reconfiguración de Canal de Transporte, o cualquier solicitud, configuración o mensaje de reconfiguración. Además, la duración podría establecerse basándose en un parámetro dentro del mensaje de indicación de transición. De este modo, la duración podría ser mayor si el UE solicita una transición a Cell_PCH en lugar de una inactiva.

La señalización o envío de la duración por un elemento de red podría tener la forma de un elemento de información. Como se utiliza en la presente, la señalización o el envío podrían incluir directamente enviar la información a un UE, o difundir la información. Similarmente, recibir en el UE podría incluir recepción directa o lectura de un canal de difusión. Un elemento de información ejemplar incluye: Los valores de T3xx, en una modalidad se definen como : En una modalidad, T3xx puede incluirse en Elemento de Información de UMTS existente "Cronómetros de UE y Constantes en el modo conectado". Por lo tanto, esto puede difundirse en una celda por la inclusión en el Tipo de Bloque de Información de Sistema 1. En una modalidad alternativa, el valor del cronómetro también podría señalarse utilizando otros mensajes de información del sistema, tales como SIB3 o SIB4, o alternativa o adicionalmente podrían señalarse con un mensaje de información de movilidad de UTRAN dedicado.

Como se indica en la tabla anterior, el valor de T3xx puede variar entre valores establecidos e incluye un valor cero o un valor infinito. El valor cero se utiliza para indicar que la inhibición no necesita presentarse. El valor de infinidad indica que un mensaje de indicación de transición nunca debe enviarse.

En una modalidad de movilidad, el UE restablece el valor de T3xx siempre que una nueva red o celda se hace transición. En este ejemplo, el valor se establece en infinidad. Esto asegura que si mensajes de transición o Mensajes de Portadora de Radio no contienen un valor del cronómetro de inhibición, entonces por defecto el UE no enviará el mensaje de indicación de transición. De este modo, por ejemplo, si los mensajes de transición o de portadora de radio no contienen una "Indicación de Transición de Inhibición", el valor del cronómetro se establece en infinidad y de otra manera el valor del cronómetro recibido en la indicación reemplaza cualquier valor previamente almacenado .

En otra modalidad alternativa, los valores de T3xx, se definen como sigue. La inclusión del cronómetro T3xx es opcional por lo que asegura que si no se incluye, el UE no necesita tener que soportar la configuración o utilizar este cronómetro : La recepción del cronómetro de inhibición en una celda de este modo es una indicación para el UE de que la celda reconoce el uso del mensaje de indicación de transición. El UE puede determinar, si se inicia por RRC o mayores capas debidas a una determinación de no más datos de dominio de PS por una duración prolongada, 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 capturado en este documento) con este valor de causa puede determinar señalar al UE un cambio de transición de estado a un estado de RRC de batería más eficiente .

Mientas en una modalidad alternativa cuando el cronómetro de inhibición no se recibe o se lee en una celda, el UE puede determinar que la causa para enviar el mensaje de indicación de transición, no se soporta por la UTRA . En este caso el UE puede determinar no configurar un valor para T3xx y tampoco utilizar el T3xx con respecto a enviar o inhibir el envío del mensaje de indicación de transición.

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

En una modalidad alternativa, el UE al determinar que el cronómetro de inhibición se omite, el UE no debe iniciar una indicación de transición basándose en la capa más alta que determina que no tiene más datos de PS que transmitir .

En una modalidad de este comportamiento descrito, el mensaje de indicación de transición es el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN.

En una primera modalidad alternativa, la recepción del cronómetro de inhibición en una celda es una indicación de que la celda reconoce el uso de los mensajes de indicación de transición. Donde el envío de este mensaje se permite cuando T3xx no se establece en el valor de infinidad, entonces cuando la red recibe una indicación de transición puede determinar señalar al UE una transición de estado a un estado de RRC de batería más eficiente (por ejemplo, CELL_FACH , CELL_PCH, URA_PCH O IDLE_MODE) .

En un ejemplo particular, que utiliza el estándar TSG-Ran2 25.331 del 3GPP, lo siguiente se agrega a las secciones identificadas a continuación: Esto se agrega a las secciones: 10.2.48.8.6 Tipo de Bloque de Información de Sistema 3 ; 10.2.48.8.7 Tipo de Bloque de Información de Sistema 4 ; 10.2.1 Actualización De Conjunto Actívelo.2.8 Confirmación de Actualización de Celda; 10.2.16a Trasferencia al Comando de UTRAN; 10.2.22 Reconfiguración de Canal Físico; 10.02.27 Reconfiguración de Portadora de Radio; 10.2.30 Liberación de Portadora de Radio; 10.2.33 Establecimiento de Portadora de Radíelos.40 Establecimiento de Conexión de RRC; 10.2.50 Reconfiguración de Canal de Transporte; Los mensajes descritos en lo anterior, además de los mensajes 10.2.48.8.6 en el Tipo de Bloques de Información de Sistema 3 y 10.2.48.8.7 Tipo de Bloque de Información de Sistema 4, todos son ejemplos de mensajes de información de movilidad.

Lo anterior cubre conexiones y operaciones del sistema, así como transiciones entre las diversas celdas, asegurando que un UE tenga un valor del cronómetro de inhibición si esa celda soporta el mensaje de indicación de transición. Por ejemplo, la transferencia al Comando de UTRAN asegura que una transición de otra tecnología de acceso por radio tal como una red de segunda generación a una red de tercera generación proporcionaría un valor del cronómetro de inhibición si se soporta por la celda objetivo de la red de tercera generación.

En particular con referencia a la Figura 21, una transición entre celdas se ha presentado como una precondición o durante otra operación del UE, como se muestra por el número 2110 de referencia como "Iniciar". El proceso procede al bloque 2112 en el cual se recibe un mensaje de configuración. Este puede ser cualquiera de los mensajes identificados en lo anterior, e incluye ambos mensajes de movilidad y sin movilidad. El proceso entonces procede al bloque 2114 en el cual se hace una comprobación para ver si el mensaje de configuración incluye un valor del cronómetro de inhibición.

Si no es así, el proceso procede al bloque 2120 en el cual el valor del cronómetro de inhibición se establece en infinidad. Inversamente, a partir del bloque 2114 el proceso procede al bloque 2130, si se determinan que el mensaje de configuración si incluye un valor del cronómetro de inhibición. En el bloque 2130, el valor del cronómetro de inhibición se almacena en el UE, reemplazando el valor previo para el cronómetro de inhibición. El proceso entonces procede al bloque 2140 y finaliza. Como se apreciará, en una modalidad del proceso de la Figura 21 se invoca siempre que un cambio en la red o celda se presenta, o siempre que una indicación de transición necesita enviarse.

Una vez que el proceso ha esperado un tiempo predeterminado en la etapa 2024, el proceso procede nuevamente a la etapa 2012 para determinar si las condiciones para enviar una indicación de transición aún existen. Si es sí, el proceso cicla nuevamente a la etapa 2020 y 2022.

Basándose en lo anterior, el valor del cronómetro de inhibición puede proporcionarse en varias modalidades . En una primera modalidad, puede proporcionarse sólo utilizando un mensaje de establecimiento de conexión de RRC para transportar un valor del cronómetro de inhibición.

En una segunda modalidad, la información del sistema puede utilizarse para transportar el valor del cronómetro de inhibición.

En una tercera modalidad, los Mensajes de Establecimiento de Conexión de RRC y la Información del Sistema ambos pueden utilizarse para enviar el valor del cronómetro de inhibición para asegurar que los UE en el modo inactivo y los estados de Cell_PCH/Cell_FACH y DCH tengan la última información.

En una cuarta modalidad el valor del cronómetro de inhibición puede enviarse como en la tercera modalidad, con la adición del envío de un valor del cronómetro de inhibición en un establecimiento de portador de radio de manera que cuando se establezca un contexto de PDP que no tenga ninguna portadora de radio, cuando una portadora de radio se establezca de manera subsiguiente para enviar un mensaje de datos el valor del cronómetro de inhibición puede transportarse en ese tiempo.

En una quinta modalidad, la cuarta modalidad puede combinarse con todos los mensajes relacionados con movilidad como se describe en lo anterior e incluye reconfiguración, confirmación de actualización de celda y una Transferencia al comando de UTRA para transportar el valor del cronómetro de inhibición.

En la primera a cuarta modalidades, durante la movilidad, el UE mantiene su valor del cronómetro de inhibición actualmente almacenado. Como se indica en lo anterior, en algunos casos donde el cronómetro de inhibición se establece en infinidad, esto puede significar que el UE debe esperar a que los cronómetros de red expiren y que la red mueva el UE a un estado de RRC donde puede recibir o determinar un nuevo valor para el cronómetro de inhibición. En otros casos, donde el cronómetro de inhibición es cierto valor diferente a infinidad antes de la transferencia, este otro valor se continúa utilizando hasta que el UE es capaz de actualizar el valor del cronómetro a aquel indicado en la nueva celda.

Para la quinta modalidad, el proceso de La Figura 21 se utiliza para asegurar que el valor del cronómetro de inhibición se actualiza durante la movilidad, y que los mensajes de indicación de transición no se envían de manera innecesaria desde un UE.

Una excepción puede presentarse en el restablecimiento de RLC o cambio de inter-RAT. Si se presenta un restablecimiento del lado de transmisión de la entidad de RLC antes de la entrega exitosa del mensaje de indicación de transición se haya confirmado por el RLC, en una modalidad, el UE retransmite el mensaje de indicación de transición en el DCCH de enlace ascendente utilizando AM RLC.

En una modalidad, si una transferencia inter-RAT del procedimiento de UTRA se presenta antes de que la entrega exitosa del mensaje de indicación de transición se haya confirmado por la RLC, el UE aborta la conexión de señalización mientras se encuentra en la nueva RAT.

En el lado de red, el proceso se maneja de manera similar a aquella descrita con referencia a la Figura 18 siguiente .

Con referencia nuevamente a la Figura 1, en algunos casos puede ser más deseable encontrarse en el modo 120 conectado en un estado tal como estado 128 de URA_PCH que en el modo 110 inactivo. Por ejemplo, si la latencia para la conexión al estado 122 de CELL_DCH o el estado 124 de CELL_FACH en el modo 120 conectado se requiere que sea más bajo, es preferible encontrarse en un estado PCH del modo 120 conectado. Existe un número de formas para lograr esto tal como, por ejemplo, al modificar estándares para permitir que el UE solicite a la UTRA cambiarse a un estado específico (por ejemplo, en este caso el estado 128 de URA_PCH) .

Alternativamente, el administrador de conexión puede tomar en cuenta otros factores tales como qué estado se encuentra actualmente en la conexión de RRC. Si, por ejemplo, la conexión de RRC se encuentra en el estado de URA_PCH, puede decidir que es innecesario mover el modo 110 inactivo y de este modo 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 UTRA ) puede tomar en cuenta por sí misma otros factores tales como qué estado se encuentra actualmente en la conexión de RRC y si, por ejemplo, la conexión de RRC se encuentra en el estado de URA_PCH puede decir que es innecesario moverse al modo 110 inactivo y en su lugar una transición simple del UE en un estado más estable en lugar de liberar la conexión.

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

El UE inicia en el estado 110 inactivo de RRC y se basa en datos generados de forma local en la unidad móvil que necesitan transmitirse o una búsqueda recibida desde la UTRA , comienza a establecer una conexión de RRC.

Como se ilustra en la Figura 4A, el establecimiento 310 de conexión de RRC se presenta primero, y el estado de RRC se encuentra en un estado 410 de conexión durante este tiempo .

Después, el establecimiento 312 de conexión de señalización, el establecimiento 314 descifrado e integridad y el establecimiento 316 de portadora de radio se presentan. El estado de RRC es el estado 122 de CELL_DCH durante estos procedimientos. Como se ilustra en la Figura 4A, el tiempo transcurrido para moverse desde el estado inactivo de RRC al momento en que la portadora de radio se establece es de aproximadamente dos segundos en este ejemplo.

Los datos después se intercambian. En el ejemplo de La Figura 4A esto se logra en aproximadamente dos a cuatro segundos y se ilustra por la etapa 420.

Después de que se intercambian datos en la etapa 420, no se intercambian datos excepto para la PDU de señalización de RLC intermitente como se requiere y de este modo el recurso de radio se reconfigura por la red para moverse a una configuración de DCH de una tasa de datos más baja después de aproximadamente diez segundos. Esto se ilustra en las etapas 422 y 424.

En la configuración de DCH de tasa de datos más baja, nada se recibe durante diecisiete segundos, en cuyo punto la conexión de RRC se libera por la red en la etapa 428.

Una vez que la liberación de conexión de RRC se inicia en la etapa 428, el estado RRC procede a un estado 430 de desconexión por aproximadamente cuarenta milisegundos , después de lo cual el UE se encuentra en un estado 110 inactivo de RRC.

También se ilustra en la Figura 4A, el consumo de energía del UE se ilustra por el período en el cual el RRC se encuentra en el estado 122 de CELL_DCH . Como se ve, el consumo de energía es de aproximadamente 200 a 300 miliamperios por toda la duración del estado de CELL_DCH. Durante la desconexión e inactividad, aproximadamente 3 miliamperios se utilizan, suponiendo un ciclo de DRX de 1.28 segundos. Sin embargo, los 35 segundos de consumo de energía en 200 a 300 miliamperios se consume en la batería.

Ahora se hace referencia a la Figura 4B. La Figura 4B utiliza la misma infraestructura ejemplar "cuatro" de lo anterior, sólo ahora implementando la liberación de conexión de señalización.

Como se ilustra en la Figura 4B, las mismas etapas 310, 312, 314 y 316 de establecimiento se presentan y esto toma la misma cantidad de tiempo cuando se mueven entre el estado 110 inactivo de RRC y el estado 122 de CELL_DCH de RRC.

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

El UE en el ejemplo de la Figura 4B tiene un tiempo fuera de inactividad específica de aplicación, que en el ejemplo de la Figura 4B es dos segundos y se ilustra por la etapa 440. Después de que el adminis rador de conexión ha determinado que existe inactividad por la cantidad especifica de tiempo, el UE envía una indicación de transición, el cual en este caso es una indicación de liberación de conexión de señalización en la etapa 442 y en la etapa 448, la red procede, basándose en la recepción de la indicación y en un perfil de recursos de radio para el UE, para liberar la conexión de RRC.

Como se ilustra en la Figura 4B, el consumo de energía durante la etapa 122 de CELL_DCH aún es de aproximadamente 200 a 300 miliamperios . Sin embargo, el tiempo de conexión sólo es de aproximadamente ocho segundos . Como se apreciará por aquellos con experiencia en la técnica, la cantidad considerablemente más corto de tiempo que la unidad móvil permanece en el estado 122 de CELL_DCH resulta en ahorros significativos de batería para el dispositivo de UE.

Ahora se hace referencia a la Figura 5. La Figura 5 muestra un segundo ejemplo que utiliza la infraestructura indicada en lo anterior como infraestructura "tres". Como con las Figuras 4A y 4B, se presenta un establecimiento de conexión que toma aproximadamente dos segundos. Esto requiere que el establecimiento 310 de conexión de RRC, el establecimiento 312 de conexión de señalización y el establecimiento 314 descifrado e integridad y el establecimiento 316 de portadora de radio.

Durante este establecimiento, el UE se mueve desde el modo 110 inactivo de RRC hasta un estado 122 de CELL_DCH con un estado de RRC conectando la etapa 410 entre los mismos .

Como con la Figura 4A, en la Figura 5A el intercambio de PDU de datos de RLC se presenta en la etapa 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 de RLC no recibe datos y de este modo se encuentra en el modo inactivo por el periodo de cinco segundos en la etapa 422, excepto para la PDU de señalización de RLC intermitente como se requiere, en cuyo punto el recurso de radio reconfigura el UE para moverse en un estado 124 de CELL_FACH desde estado 122 de CELL_DCH. Esto se hace en la etapa 450.

En el estado 124 de CELL_FACH, el intercambio de PDU de señalización de RLC encuentra que no existen datos excepto para la PDU de señalización de RLC intermitente como se requiere por una cantidad predeterminada de tiempo, en este caso treinta segundos, en cuyo punto una liberación de la conexión de RRC por la red se realiza en la etapa 428.

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

Como además se ve en la Figura 5A, el consumo de energía durante el modo de DCH se encuentra entre 200 y 300 miliamperios . Cuando se mueve en el estado 124 de CELL_FACH reduce el consumo de energía baja a aproximadamente 120 a 180 miliamperios. Después de que el conector de RRC se libera y el RRC se mueve en el modo 110 inactivo el consumo de energía es de aproximadamen e 3 miliamperios.

El estado de Modo Conectado de RRC de UTRA que es el Estado 122 de CELL_DCH o el estado 124 de 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 el establecimiento 310 de conexión de RRC, el establecimiento 312 de conexión de señalización, el establecimiento 314 de cifrado e integridad y el establecimiento 316 de portadora de radio. Además, el intercambio 420 de PDU de datos de RLC toma aproximadamente dos a cuatro segundos.

Como con la Figura 4B, una aplicación de UE detecta un tiempo fuera de inactividad específico en la etapa 440, en cuyo punto de indicación de transición (por ejemplo, indicación de liberación de conexión de señalización 442) se envía por el UE y como consecuencia, la red libera la conexión de RRC en la etapa 448.

Como puede observarse adicionalmente en la Figura 5B, el RRC inicia en un modo 110 inactivo, se mueve a estado 122 de CELL_DCH sin proceder hacia el estado de CELL_FACH.

Como se observará adicionalmente en la Figura 5B, el consumo de energía es de aproximadamente 200 a 300 miliamperios en el momento en que la etapa de RRC se encuentra en estado 122 de CELL_DCH, en el cual 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 una cantidad significativa de consumo de energía se elimina, por lo que extiende la vida de batería del UE. Como apreciará por aquellos con experiencia en la técnica, lo anterior además puede utilizarse en el contexto de especificaciones del 3GPP actuales .

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

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

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

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

La porción 614 de ÑAS en el plano 611 de control de PS incluye adminis ración de movilidad (MM) y administración de movilidad de GPRS (GMM) 626. Además, incluye administración de sesión/administración de portadora de acceso por radio SM/RABM 624 y GSMS 628.

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

La función principal de la porción de RABM de SM/RABM 624 es conectar un contexto de PDP a una portadora de acceso por radio. De este modo, SM/RABM 624 es responsable del establecimiento, modificación y liberación de los recursos de radio.

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

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

El estrato 616 de acceso, en el plano 630 de usuario de PS incluye protocolo de convergencia de datos por paquetes (PDCP) 632. El PDCP 632 se diseña para hacer el protocolo de CD A adecuado para transportar el protocolo de TCP/IP entre el UE y RNC (como se ve en la Figura 8) , y opcionalmente para la compresión y descompresión de encabezado de protocolo de corriente de tráfico de IP.

El Control de Enlace de Radio de UMTS (RLC) 640 y capas 650 de Control de Acceso a Medios (MAC) forman las sub-capas de enlace de datos de la interfaz de radio de UMTS y reside en el nodo RNC y el Equipo de Usuario.

La capa de UMTS de Capa 1 (Ll) (capa 660 física) se encuentra por debajo de las capas 640 y 650 de RLC/MAC . Esta capa es la capa física para comunicación.

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

El UE 700 de preferencia es un dispositivo de comunicación inalámbrico de dos vías que tiene por lo menos capacidades de comunicación de voz y datos . El UE 700 de preferencia tiene la capacidad para comunicarse con otros sistemas de computadora en la Internet. Dependiendo de la funcionalidad exacta proporcionada, el dispositivo inalámbrico puede denominarse como un dispositivo de mensajería de datos, un busca personas de dos vías, un dispositivo de correo electrónico inalámbrico, un teléfono celular con capacidades de mensajería de datos, un aparato de internet inalámbrico, o un dispositivo de comunicación de datos, como ejemplos.

Donde el UE 700 se habilita para comunicación de dos vías, se incorporará un subsistema 711 de comunicación, que incluye un receptor 712 y un transmisor 714, así como componentes asociados, tales como uno o más, de preferencia integrados o internos, elementos 716 y 718 de antena, osciladores locales (OL) 713, y un módulo de procesamiento, tal como un procesador de señal digital (DSP) 720. Como será aparente para aquellos con experiencia en el campo de comunicaciones, el diseño particular del subsistema 711 de comunicación dependerá de la red de comunicación en la cual se pretende operar el dispositivo. Por ejemplo, el UE 700 puede incluir un subsistema 711 de comunicación diseñado para operar dentro de la red de GPRS o la red de UMTS .

Los requisitos de acceso de red también pueden variar dependiendo del tipo de red 719. Por ejemplo, en redes UMTS y GPRS, acceso a la red se asocia con un suscriptor o usuario del UE 700. Por ejemplo, un dispositivo móvil de GPRS por lo tanto, requiere una tarjeta de módulo de identidad del suscriptor (SIM) para operar en una red de GPRS. En UMTS se requiere un módulo de USIM o SIM. En el CDMA se requiere una tarjeta o módulo de RUIM. Estas se denominarán como una interfaz de UIM en la presente. Sin una interfaz de UIM válida, un dispositivo móvil puede no ser completamente funcional. Las funciones de comunicación local o sin red, así como las funciones legalmente requeridas (si las hubiera) , tales como llamadas de emergencia, pueden encontrarse disponibles, pero el dispositivo 700 móvil será incapaz de llevar a cabo cualesquiera otras funciones que impliquen comunicaciones sobre la red 700. La interfaz 744 de UIM es normalmente similar a una ranura de tarjeta en la cual puede insertarse una tarjeta y expulsase como un disquete o tarjeta de PCMCIA. La tarjeta de UIM puede tener aproximadamente de 64 KB de memoria y contener gran parte de la configuración 751 de clave, y otra información 753 tal como identificación, e información de suscriptor relacionada.

Cuando se requiere se han completado el registro de red o procedimientos de activación, el UE 700 puede enviar y recibir señales de comunicación sobre la red 719. Las señales recibidas por la antena 716 a través de la red de comunicación 719 se ingresan en el receptor 712, que puede realizar funciones de receptor comunes como amplificación de señal, conversión descendente de frecuencia, filtración, selección de canal y similares, y en el sistema ejemplar mostrado en la Figura 7, una conversión análogo a digital (AD) . La conversión AD de una señal recibida permite que funciones de comunicación más complejas tales como la desmodulación y descodificación que se realizan en el DSP 720. El DSP 720 no sólo procesa las señales de comunicación, sino también proporciona control de receptor y transmisor. Por ejemplo, las ganancias aplicadas a las señales de comunicación en el receptor 712 y el transmisor 714 pueden controlarse de manara adaptable a través de algoritmos de control de ganancia automáticos implementados en DSP 720.

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

El UE 700 de preferencia incluye un microprocesador 738, que controla la operación general del dispositivo. Las funciones de comunicación, que incluyen por lo menos comunicaciones de datos, se realizan a través del subsistema 711 de comunicación. El microprocesador 738 también interactúa con los subsistemas de dispositivos adicionales, como la pantalla 722, memoria 724 flash, memoria de acceso aleatorio (RAM) 726, subsistemas 728 auxiliares entrada/salida (E/S) , puerto 730 serial, teclado 732, altavoces 734 , micrófono 736 , un subsistema 740 de comunicación de corto alcance y cualquier otro subsistemas de dispositivo generalmente designado como 742 .

Algunos de los subsistemas se muestra en la Figura 7 realizan funciones relacionadas con la comunicación, mientras otros subsistemas pueden proporcionar funciones "residente" o en el dispositivo. De manera notable, algunos subsistemas, tales como el teclado 732 y la pantalla 722 , por ejemplo, pueden utilizarse para funciones relacionadas con la comunicación, tal como ingresar un mensaje de texto para transmisión sobre una red de comunicación, funciones de dispositivo-residentes tal como una calculadora o lista de tareas .

El software del sistema operativo utilizado por el microprocesador 738 se almacena de preferencia en un almacén persistente tal como la memoria 724 flash, la cual de hecho puede ser una memoria de sólo lectura (ROM) o elemento de almacenamiento similar (no mostrado) . Aquellos con experiencia en la técnica apreciarán que el sistema operativo, aplicaciones específicas de dispositivos, o partes del mismo, pueden cargarse de manera temporal en una memoria volátil tal como la RAM 726 . Las señales de comunicación recibidas también pueden almacenarse en la RAM 726 . Además, un identificador único también se almacena de preferencia en memoria de sólo lectura.

Como se muestra, la memoria 724 flash puede segregarse en diferentes áreas para programas 758 de computadora y almacén 750, 752, 754 y 756 de datos de programación. Estos diferentes tipos de almacenamiento indican que cada programa puede asignar una porción de la memoria 724 flash a sus propios requisitos de almacenamiento de datos. El microprocesador 738, además de sus funciones del sistema operativo, permite de preferencia la implementación de aplicaciones de software en el dispositivo móvil. Un conjunto predeterminado de aplicaciones que controlan operaciones básicas, incluyendo por lo 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 administrador de información personal (PIM) que tiene la capacidad de organizar y manejar elementos de datos con relación al usuario del dispositivo móvil, tal 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 pueden encontrarse disponibles en el dispositivo móvil para facilitar el almacenamiento de elementos de datos de PIM. Tal aplicación de PIM de preferencia puede tener la capacidad de enviar y recibir elementos de datos, mediante la red 719 inalámbrica. En una modalidad preferida, los elementos de datos de PIM se integran de manera continua, se sincronizan y actualizan, mediante la red 719 inalámbrica, con elementos de datos correspondientes del usuario del dispositivo móvil almacenados o asociados con un sistema de computadora central. Aplicaciones adicionales también pueden cargarse en el dispositivo 700 móvil a través de la red 719, un subsistema 728 auxiliar de E/S, puerto 730 serial, subsistema de comunicación 740 de corto alcance o cualquier otro subsistema 742 adecuado, e instalado por un usuario en la memoria 726 RAM o, de preferencia, un almacén no volátil (no mostrado) para su implementación por el microprocesador 738. Tal flexibilidad en la instalación de la aplicación incrementa la funcionalidad del dispositivo y puede proporcionar funciones mejoradas en el dispositivo, funciones relacionadas con comunicación, o ambas. Por ejemplo, las aplicaciones de comunicación seguras pueden habilitar funciones de comercio electrónico y otras transacciones financieras que se realizan utilizando el UE 700. Estas aplicaciones, sin embargo, de acuerdo con lo anterior, en muchos casos necesitarán ser aprobadas por un portador.

En un modo de comunicación de datos, una señal recibida tal como un mensaje de texto o descarga de página web se procesará por el subsistema 711 de comunicación y se ingresará al microprocesador 738, el cual de preferencia procesa adicionalmente la señal recibida para su salida en la pantalla 722, o alternativamente, a un dispositivo 728 auxiliar de E/S. Un usuario del UE 700 también puede componer elementos de datos tales como mensajes de correo electrónico, por ejemplo, utilizando un teclado 732, el cual de preferencia es un teclado alfanumérico completo o un teclado del tipo teléfono, junto con la pantalla 722 y, posiblemente, un dispositivo 728 auxiliar de E/S. Tales elementos compuestos pueden entonces transmitirse sobre una red de comunicación a través del subsistema 711 de comunicación.

Para comunicaciones de voz, la operación general del UE 700 es similar, excepto que las señales recibidas de preferencia pueden producirse en un altavoz 734 y las señales para transmisión pueden generarse por un micrófono 736. Subsistemas de E/S de voz o audio alternativos, tales como un subsistema de grabación de mensaje de voz, también pueden implementarse en el UE 700. Aunque la salida de señal de voz o audio de preferencia se logra principalmente a través del altavoz 734, la pantalla 722 también puede utilizarse para proporcionar una indicación de la identidad de una parte que llama, la duración de una llamada de voz, u otra información relacionada llamada de voz, por ejemplo.

El puerto 730 serial en la Figura 7 normalmente puede implementarse en un de dispositivo móvil tipo asistente digital personal (PDA) para el cual la sincronización con la computadora de escritorio de un usuario (no mostrada) puede ser deseable. Tal puerto 730 puede permitir a un usuario establecer preferencias a través de un dispositivo externo o aplicación de software y puede extender las capacidades del dispositivo 700 móvil, al proporcionar información o descargas de software al UE 700 de manera diferente a través de una red de comunicación inalámbrica. La trayectoria de descarga alternativa por ejemplo puede utilizarse para cargar una clave de encriptación en el dispositivo a través de una conexión directa y de este modo confiable y fiable para permitir por consiguiente comunicación segura del dispositivo .

Alternativamente, el puerto 730 serial podría utilizarse para otras comunicaciones, y podría incluir un puerto de bus de serie universal (USB) . Se asocia una interfaz con el puerto 730 serial.

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

Ahora se hacer referencia a la Figura 8. La Figura 8 es un diagrama de bloque 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.

El UE 802 que se comunica de manera inalámbrica con uno o múltiples nodos B 806 . Cada nodo B 806 es responsable de un procesamiento de interfaz aérea y ciertas funciones de administración de recursos de radio. El Nodo B 806 proporciona una funcionalidad similar a una Estación de Transceptor Base en redes de GSM/GPRS .

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

Un canal de RF es un recurso limitado que debe conservarse, típicamente debido a límites en el ancho de banda general y una energía de batería limitada del UE 802 . Aquellos con experiencia en la técnica apreciarán que una red inalámbrica en la práctica actual puede incluir cientos de celdas, que dependen de expansión general deseada de la cobertura de red. Todos los componentes pertinentes pueden conectarse por 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 (R C) 810. El RNC 810 es responsable de controlar de los recursos de radio en su área. Un RNC 810 controla múltiples Nodos B 806.

El RNC 810 en las redes de UMTS proporciona funciones equivalentes a las funciones del Controlador de Estación Base (BSC) en las redes de GSM/GPRS. Sin embargo, un RNC 810 incluye más inteligencia, incluyendo, por ejemplo, el manejo de transferencias autónomas sin implicar MSC y SGSN.

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

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

El tráfico conmutado por circuitos se enruta hacia el Centro de Conmutación Móvil (MSC) 830. El MSC 830 es la computadora que hace las llamadas, y toma y recibe los datos del suscriptor o de la PSTN (no mostrada) .

El tráfico entre el RNC 810 y MSC 830 utiliza la interfaz 828 lu-CS . La interfaz 828 de lu-CS es la conexión de conmutada por circuitos para transportar el tráfico de voz (típicamente) y señalización entre el 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 por radio) . El protocolo RANAP se utiliza en de señalización de UMTS entre la red 821 principal, la cual puede ser un MSC 830 o SGSN 850 (definido a mayor detalle a continuación) y el UTRAN 820. El protocolo de RANAP se define en la TS 25.413 V3.11.1 (2002-09) y la TS 25.413 V5.7.0 (2004-01) del 3GPP.

Para todos los UE 802 registrados con un operador de red, datos permanentes (tal como el perfil del usuario del UE 802), así como datos temporales (tal como la ubicación actual del UE 802) se almacenan en un registro de ubicación local (HLR) -838. En el 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 Visitante (VLR) 836 del MSC 830 es responsable de un grupo de áreas de ubicación y almacena los datos de las estaciones móviles que actualmente se encuentran en su área de responsabilidad. Esto incluye partes de los datos de la estación móvil permanentes que se han transmitido de HLR 838 a hasta VLR 836 para acceso más rápido. Sin embargo, el VLR 836 del MSC 830 también puede asignar y almacenar datos locales, tal como identificación temporal. El UE 802 también se autentifica en el acceso al sistema por el HLR 838.

Se enrutan datos por paquete a través del Nodo de Soporte de GPRS de Servicio (SGSN) 850. El SGSN 850 es un puerto de enlace entre el RNC y la red central en una red de GPRS/UMTS y es responsable de la entrega de paquetes de datos desde y hasta los UE dentro de su área de servicio geográfica. La interfaz 848 de lu-PS se utiliza entre el RNC 810 y el SGSN 850, y es la conexión conmutada por paquetes para transportar (típicamente) tráfico de datos y señalización entre el UTRA 820 y la red de datos central. El protocolo de señalización principal utilizado es RANAP (descrito en lo anterior) .

El SGSN 850 se comunica con el Nodo de GPRS de Soporte de Puerto de Enlace (GGSN) 860. El GGSN 860 es la interfaz entre la red de UMTS/GPRS y otras redes tales como Internet o redes privadas. El GGSN 860 se conecta a una red de datos pública PDN 870 sobre una interfaz de Gi .

Aquellos con experiencia en la técnica apreciarán que la red inalámbrica puede conectarse a otros sistemas, posiblemente incluyendo otras redes, no explícitamente mostradas en la Figura 8. Una red que normalmente transmitirá por lo menos una cierta clase de información de búsqueda y sistema en una base saliente, incluso si no existe ningún intercambiado de datos por paquetes actual. Aunque la red consiste de muchas partes, estas partes funcionaran juntas para dar como resultado en 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 conforme a múltiples sesiones de servicios de comunicación de datos por paquetes concurrentes. Aquí, dos servicios de datos por paquetes, cada uno asociado a un contexto de PDP particular, designado como PDPi y al mismo tiempo son PDP2 se encuentran concurrentemente activos. El esquema 1104 representa el contexto de PDP activado en el primer servicio de datos por paquetes, y el esquema 1106 representa el recurso de radio asignado al primer servicio de datos por paquetes. Y, el esquema 1108 representa el contexto de PDP activado en el segundo servicio de datos por paquetes, y el esquema 1112 representa el recurso de radio asignado al segundo servicio de datos por paquetes. El UE solicita la ubicación de portadora de acceso por radio por medio de una solicitud de servicio, indicada por los segmentos 1114. Y, el UE también solicita liberación de servicio de portadora de radio, indicada por los segmentos 1116 conforme a una modalidad de la presente descripción. Las solicitudes de servicio y las liberaciones de servicio para servicios separados son independientes entre sí, es decir, se generan de manera independiente. En la ilustración ejemplar de la Figura 11, el contexto de PDP y el recurso de radio para el contexto de PDP asociado se asignan a tiempos sustancialmente concurrentes. Y, la liberación de recursos de radio se concede con la solicitud del UE, como se muestra, o cuando el RNC (Controlador de Red de Radio) decide liberar los recursos de radio.

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

En la implementación ejemplar, un servicio de datos por paquetes simple se puede formar adicionalmente como un servicio primario y uno o más servicios secundarios, tal como se indica por las designaciones 1118 y 1122. La liberación de recursos de radio además se permite para identificar cuáles de uno o más servicios primarios y secundarios cuya asignación de recursos de radio ya no se necesitan, o de otra manera desean liberarse. La asignación de recursos de radio eficiente se proporciona por consiguiente. Además, la utilización óptima del procesador en el UE se proporciona puesto que la potencia del procesador que puede haberse asignado a procesamiento innecesario ahora puede utilizarse mejor para otros propósitos.

La Figura 12 ilustra partes del sistema 800 de comunicación, particularmente, el UE 802 y el controlador de red de radio (RNC) /SGSN 810/850 que opera conforme una forma de modalidad de la presente descripción que pertenece a las múltiples sesiones de servicio de datos por paquetes contiguas. El UE incluye el aparato 1126 y el R C/SGSN incluye el aparato 1128 de una modalidad de la presente descripción. Los elementos que forman el aparato 1126 y 1128 se representan de manera funcional, se pueden implementar en cualquier forma deseada, incluyendo por algoritmos ejecutables por la circuitería de procesamiento así como hardware o implementaciones de firmware. Los elementos del aparato 1128, aunque se representan como ejemplificados en el RNC/SGSN, en otras implementaciones, se forman en cualquier lugar en otras ubicaciones de la red, o se distribuyen a través de 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 ejemplar, los elementos 1132 y 1134 se representan en una capa de administración de sesión, por ejemplo, la capa de Estrato Sin Acceso (ÑAS) definida en UMTS, del UE.

En otra implementación ejemplar, los elementos se representan en una subcapa de Estrato de Acceso (AS) . Cuando se implementan en la subcapa de AS, los elementos se implementan como parte de un adminis rador de conexión, mostrada en 1136. Cuando se implementan de esta manera, los elementos no necesitan estar al tanto del comportamiento de contexto de PDP o del comportamiento de 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 de paquetes . La determinación se hace, por ejemplo, en una capa de aplicación, u otra capa lógica, y se proporcionan a la capa de administración de sesión y el detector representado en la misma. Las indicaciones de detecciones realizadas por el detector se proporcionan al remisor de indicación de liberación de recursos de radio. El emisor genera y provoca que el UE envíe una indicación de transición que forma la solicitud 1116 de liberación de servicio, mostrada en la Figura 11.

En una implementación adicional, la indicación de transición incluye un campo de causa que contienen una causa, tal como cualquiera de las causas antes mencionadas y descritas aquí y en lo anterior, como adecuadas o el campo causa identifica un estado preferido en el cual el UE prefiere que la red provoque que el UE haga transición.

El aparato 1128 representado en la red incluye un examinador 1142 y un concesor 1144. El examinador examina la indicación de transición, cuando se reciben el mismo. Y, el concesor 1144 de transición opera de manera selectiva para hacer transición del UE cuando se le solicite en la indicación de transición.

En una implementacion en la cual la señalización se realiza en una capa de control de recurso de radio (RRC) , el controlador de red de radio (R C) , en lugar del SGSN realiza el examen y hace transición del UE. Y, por consiguiente, el aparato representado en el UE se forma en la capa de RRC, o el aparato provoca de otra manera que la indicación generada se envíe en un nivel de RRC.

En un flujo de control ejemplar, una capa mayor informa a la capa de NAS/RRC, cuando es adecuado, que el recurso de radio se asigna a un contexto de PDP particular, si ya no se requiere. Un mensaje de indicación capa de RRC se envía a la red. El mensaje incluye un ID de RAB o ID de RB que, por ejemplo, identifica el servicio de datos por paquetes, al controlador de red de radio. Y, en respuesta, la operación del controlador de red de radio activa un procedimiento para resolver y finalizar la liberación de recursos de radio, la reconfiguración de los recursos de radio, o mensaje de liberación de conexión de control de los recursos de radio (RRC) que se regresa al UE. El procedimiento de RNC, por ejemplo, es similar o equivalente, al procedimiento establecido en la Sección 9.2.5 del documento de la TS 23.060 del 3GPP, . El ID de RAB, por ejemplo, se utilizar venta osamente como el ID que es el mismo que el Identificador de Punto de Acceso de Servicio de Red (NSAPI) que identifica el contexto de PDP asociado, y capas de aplicación que generalmente se encuentran al tanto del NSAPI.

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

La Figura 13 ilustra un diagrama de secuencia de mensaje, mostrado generalmente en 1137, que representa la señalización ejemplar generada conforme a la liberación de recursos de radio asociados con un contexto de PDP, tal como aquel mostrado gráficamente en parte de la representación gráfica mostrada en la Figura 11. La liberación se inicia, ya sea por el UE o en el RNC, u otra entidad de UTRAN. Cuando se inicia en el UE, por ejemplo, el UE envía una indicación de liberación de recursos de radio al UTRAN.

Al inicio, una solicitud de liberación de portadora de acceso radio (RAB) se genera, y se envía indicada por el segmento 1138 por el RNC/UTRAN y se suministra al SGSN. En respuesta, una solicitud de asignación RAB devuelve, indicada para el segmento 1140, al RNC/UTRAN . Y, después, como se indica por el segmento 1142, los recursos de radio que se extienden entre el UE 802 y la UTRAN se liberan. Una respuesta entonces se envía, como se indica por el segmento 1144.

La Figura 14 ilustra un diagrama de secuencia de mensaje mostrado generalmente en 1147, similar al diagrama de secuencia de mensaje mostrado en la Figura 13, pero aquí en el cual los recursos de un contexto de PDP final se liberan. Como al inicio, el RNC genera una solicitud 1150 de liberación de lu que se comunica al SGSN y en respuesta al mismo, el SGSN regresa un comando de liberación de lu, indicado por el segmento 1152. Después de esto, y como se indica por los segmentos 1154, en la portadora de radio formada entre el UE y la UTRAN se libera. Y, como se indica por el segmento 1156, el RNC/UTRAN regresa una liberación lu completa al SGSN.

La Figura 15 ilustra un diagrama de flujo del método, mostrado generalmente en 1162, representativo del proceso de una modalidad de la presente descripción para liberar los recursos de radio asignados conforme a un contexto de PDP .

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

Si, inversamente, una liberación de portadora de acceso por radio se ha solicitado, la ramificación si se -lleva en el bloque de decisión 1172. En el bloque de decisión 1172, se hace una determinación para cuanto ha si la portadora de acceso por radio que va a liberarse es la portadora de acceso por radio final que va liberarse. Si no es así, la ramificación no se lleva al bloque 1178, y se establece en el estado preferido. Después, procedimientos de liberación de portadora de acceso por radio se realizan, tal como aquella mostrada en la Figura 13 o tal como aquella descrita en la Sección 23,060, subcláusula 9.2.5.1.1 del documento del 3GPP.

Inversamente, si se hace una determinación en el bloque de decisión 1172 que RAB es el último que va liberarse, la ramificación sí se lleva al bloque 1186, un procedimiento de liberación lu, tal como aquel mostrado en la Figura 14 o como tal aquel descrito en la sección 23.060, subcláusula 9.2.5.1.2 del documento del 3GPP se realiza.

La Figura 16 ilustra un diagrama de flujo del método, mostrado generalmente en 1192, representativo del proceso de una modalidad de la presente descripción para liberar recursos de radio asignados conforme a un contexto de PDP.

Después del inicio del proceso, indicado por el bloque 1194, una determinación se hace, indicada por el bloque de decisión 1196 en cuanto a si existe una RAB (Portadora de Acceso por Radio) que liberar. Si no es así, la ramificación no se lleva al bloque final 1198.

Si, inversamente, una liberación de portadora de acceso por radio se ha solicitado, la ramificación si se lleva en el bloque de la decisión 1202. En el bloque de decisión 1202, se hace una determinación en cuanto si la portadora de acceso por radio que va a liberarse es la portadora de acceso por radio final que va a liberarse. Si no es así, la ramificación no se lleva en el bloque 1204, donde la lista RAB se establece, el bloque 1206 donde el estado preferido se establece, y el bloque 1208 donde los procedimientos de liberación de portadora de acceso por radio se realizan, tal como aquella mostrada en la Figura 13 o tal como aquella descrita en la sección 23.060, subcláusula 9.2.5.1.1 del documento del 3GPP.

Inversamente, si se hace una determinación en el bloque de decisión 1202 que la RAB es la última que va a liberarse, la ramificación si se lleva en el bloque 1212, y el dominio se establece en PS (conmutado por paquetes) . Entonces, como se indica por el bloque 1214, se establece una causa de liberación. Y, como se indica por el bloque 1216, se envía una INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en un DCCH. Un procedimiento de liberación lu, tal como aquel mostrado en la Figura 14 o tal como el descrito en la sección 23,060, subcláusula 9.2.5.1.2 del documento del 3GPP se realiza.

La Figura 17 ilustra un método, mostrado generalmente en 1224, representativo del método de operación de una modalidad de la presente descripción. El método facilita la utilización eficiente de recursos de radio en un sistema de comunicación de radio que proporciona ejecución concurrente de un primer servicio de paquete y un segundo servicio de paquete. En primer lugar, y como se indica por el bloque 1226, se hace una detección de 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 paquete. Entonces, y como se indica por el bloque 1228, un indicación de liberación de recurso de radio se envía respuesta a la detección de la selección para liberar el recurso de radio.

Después, en el bloque 1212 la indicación de liberación de recursos de radio se examina y después en el bloque 1214 la concesión de la liberación de la portadora de radio se concede selectivamente.

En una modalidad adicional, la red puede iniciar una transición basándose en la recepción de una indicación desde el equipo de usuario u otro elemento de red y en un perfil de recursos de radio para el equipo de usuario.

Una indicación como se recibe a partir del equipo de usuario u otro elemento de red podría ser cualquiera de las indicaciones de transición diferentes descritas en lo anterior. La indicación puede ser pasiva y de este modo solamente una indicación en blanco que en un estado de radio intensivo de menos batería debe ingresarse. 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 un número de indicaciones recibidas, y el perfil de recursos de radio del UE que un estado de radio de menor batería o de recursos de radio intensivo puede ingresarse. Alternativamente, la indicación podría ser dinámica y proporcionar información al elemento de red sobre un estado preferido o el modo en el cual hace transición. Como con lo anterior, la indicación podría contener una causa para la indicación (por ejemplo, normal o anormal) . En una modalidad adicional, la indicación podría proporcionar otra información sobre un perfil de recursos de radio, tal como una probabilidad de que el equipo de usuario es correcto sobre la capacidad de hacer transición a un estado o modo diferente, o información sobre de las aplicaciones que activaron la indicación.

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

En una modalidad adicional, la indicación del UE o el segundo elemento de red podría implicarse en lugar de explícita. Por ejemplo, una indicación de transición puede implicarse en el elemento de red responsable de hacer transición (por ejemplo, la UTRAN) a partir de los informes de estado del dispositivo en mediciones de tráfico salientes. Específicamente, la información de estado podría incluir un estado de memoria intermedia de enlace de radio, en donde, si no existen datos salientes, podría interpretarse como una indicación implícita. Tal información de estado podría ser una medición que puede enviarse de manera repetitiva desde el UE que por sí misma, no solicita o indica nada.

La indicación de lo que podría ser de este modo cualquier señal y podría ser indicación basada en aplicación, basada en recursos de radio, o una compuesta que proporcionar información con respecto a todos los recursos de aplicación y de radio del equipo de usuario. Lo anterior no pretende ser limitante para ninguna indicación en particular, y cualquiera con experiencia en la técnica puede apreciar que cualquier indicación podría utilizarse con el presente método y descripción .

Ahora se hace referencia a la Figura 18. El proceso se inicia en la etapa 1801 y procede a la etapa 1810 en cual un elemento de red recibe la indicación.

Una vez que la red recibe la indicación en la etapa 1810, el proceso procede a la etapa 1820 en la cual un perfil de recursos de radio para el equipo de usuario se comprueba opcionalmente .

El término "perfil de recursos de radio", como se utiliza en la presente, se pretende para ser un término amplio que podría aplicar a una variedad de situaciones, dependiendo de los requerimientos de un elemento de red. En amplios términos, el perfil de recursos de radio incluye información acerca de los recursos de radio utilizados por el equipo de usuario.

El perfil de recursos de radio podría incluir cualquiera o ambos elementos de perfil estático y elementos de perfil dinámico o negociado. Tales elementos podrían incluir un valor "duración de inhibición y/o indicación máxima/mensaje de solicitud por ventana de tiempo", que podría ser parte del perfil de recursos de radio, ya sea dentro o separado del perfil de transición y podría negociarse o estático.

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

Como se apreciará por aquellos con experiencia en la técnica, varios niveles de servicio de calidad podrían existir para un recurso de radio y el nivel de la calidad del servicio podría proporcionar información a una red sobre si la transición a un estado o modo diferente. De este modo, si la calidad de servicio se encuentra en segundo término, el elemento de red puede considerarse transición al modo inactivo más fácilmente que si la calidad del servicio se estableciera en interactivo. 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 hace transición al dispositivo móvil a un estado o modo más adecuado o desmantela los recursos de radio. En algunas modalidades, un contexto de PDP primario y secundario podría tener una calidad de servicio diferente, la cual también podría afectar a la decisión si realizar una transición de estado/modo.

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

En particular, el presente método y aparato pueden utilizar el Nombre de Punto de Acceso (APN) especificado por el UE para establecer el perfil de transición entre varios estados. Esto puede ser otra forma de describir la suscripción del UE. Como se apreciará, el Registro de Ubicación Local (HLR) puede almacenar información relevante sobre los suscriptores , y podría proporcionar al controlador de red de radio (RNC) con la suscripción del UE . Otras entidades de red también podrían utilizarse para almacenar información de suscripción de manera central. Si se utiliza el HLR u otra entidad de red, la información se inserta de preferencia a otros componentes de red, tal como el RNC y SGSN, que mapea información de suscripción a parámetros físicos relevantes, utilizados durante el intercambio de datos .

La UTRA podría incluir o tener acceso a una base de datos o tabla en la cual tales parámetros de APN o QoS podrían enlazarse a un perfil de transición específico. De este modo, si el UE es un dispositivo siempre encendido, será aparente a partir del APN y un perfil de transición adecuado para ese APN podría almacenarse en la UTRAN como parte del perfil de recursos de radio o ser remotamente accesible por la UTRAN. De manera similar, si la QoS o una porción de parámetro de QoS se utiliza, o un mensaje dedicado enviado con un perfil, esto podría significar para la UTRAN que un perfil de transición particular se desea basándose en una consulta de base de datos o una consulta en una tabla. Además, una pluralidad de comportamientos más allá del perfil de transición de estado conectado de RRC puede especificarse por este medio. Estos incluyen, pero no están limitados a: algoritmos de adaptación de tasa (periodicidad de etapa/tamaño de etapa) ; portadora de radio concedida inicial; portadora de radio concedida máxima; tiempo de establecimiento de llamada mínimo (evitar etapas innecesarias, tales como mediciones de volumen de tráfico) ; y la interfaz aérea (GPRS/EDGE/UMTS/HSDPA/HSUPA/LTE , etc . ) Además, si existen múltiples contextos de PDP que tienen diferentes requisitos de QoS pero comparten la misma dirección de IP APN, tal como un contexto primario, contexto secundario, etc., un perfil de transición diferente puede utilizarse para cada contexto. Este podría señalarse a la UTRA a través de mensajes de QoS o dedicados.

Si múltiples contextos de PDP activos se utilizan concurrentemente, el denominador común más bajo entre los contextos pueden utilizarse. Para transición de estado de RRC, si una aplicación tiene un primer contexto de PDP que se asocia con un perfil de transición en el cual el sistema se mueve desde el estado CELL_DCH a un estado de CELL_PCH o inactivo rápidamente, y un segundo contexto de PDP se asocia con un perfil de transición en cual el sistema es para permanecer en el estado CELL_DCH por más tiempo, el segundo perfil en el cual el estado CELL_DCH se mantiene más tiempo anulará el primer perfil .

Como se apreciará por aquellos con experiencia en la técnica, el denominador común más bajo puede considerarse de dos maneras diferentes. El denominador común más bajo, como se utiliza en la presente, implica un tiempo más requerido antes de hacer transición a un estado diferente. En una primera modalidad, el denominador común más bajo puede ser el más bajo de los PDP activados. En una modalidad alternativa, el denominador común más bajo puede ser el más bajo de los PDP que actualmente tienen los recursos de radio activos . Los recursos de radio podrían multiplexarse en un número de diferentes formas, pero el resultado final es el mismo.

Un caso ejemplar para tales métodos puede derivarse para dispositivos siempre encendidos. Como se describe, varios parámetros de APN o QoS pueden enlazarse a un comportamiento específico para siempre encendido. El considerar los recursos de radio inicialmente concedidos que pueden ser deseables basándose en un perfil de 'siempre encendido'. La red ahora tiene un medio para 'saber' que ráfagas de datos son cortas y con ráfagas para aplicaciones siempre encendidas, tal como correo electrónico. Para aquellos con experiencia en la técnica, claramente se ve que dada esta información, no existe ningún incentivo para ahorrar espacio de código para truncar eficiencia en la red. De este modo, una tasa máxima puede asignarse a un dispositivo de siempre encendido poco riesgo de no reservar suficiente espacio de código para otros usuarios. Adicionalmente el UE se beneficia en recibir datos más rápidamente y también ahorra vida de batería debido a un 'tiempo encendido' más corto. Nuevamente, para aquellos con experiencia en la técnica, altas tasas de datos tienen muy poco efecto sobre el consumo de energía puesto que los amplificadores de energía se desvían completamente sin importar la tasa de datos .

En la modalidad anterior, una tabla de consulta puede utilizarse por el UTRAN para determinar el perfil de control de recursos para los recursos de radio que se asignarán a diferentes aplicaciones para una conexión de RRC determinada para el UE. El perfil puede basarse en suscripción de usuario y almacenarse en el lado de red en una entidad de red tal como HLR o alternativamente en el RNC puesto que el RNC tendrá más recursos de tráfico actualizados disponibles (es decir, tasas de datos que pueden concederse) . Si tasa de datos más altas pueden lograrse, puede ser posible que estos tiempos fuera fueran más cortos.

En lugar de APN, otras alternativas tales como Parámetros de Calidad de Servicio (QoS) establecidos en una activación de contexto Protocolo de Datos por Paquete (PPD) o contexto de PDP modificado pueden utilizarse. El campo QoS además puede incluir la "prioridad de retención de asignación (Unidad de datos de servicio podría utilizarse para el volumen de datos entre tráfico) " de QoS en el caso de múltiples contextos de PDP que comparten la misma dirección del APN o un perfil de suscripción para establecer el perfil de transición. Alternativas adicionales incluyen mensajes dedicados tales como el mensaje de indicación anterior para señalar un perfil de control de recurso e información tal como duración de inhibición y/o indicación máxima/mensajes de solicitud por valor de ventana de tiempo.

El perfil de transición incluido en el perfil de recursos de radio además podría incluir si el estado del UE debe ser transición en absoluto basándose en el tipo de aplicación. Específicamente, si el equipo de usuario se utiliza como un módem de datos, puede establecerse una preferencia en el equipo de usuario de manera que las indicaciones de transición no se envían o si la confirmación de la preferencia se mantiene en la red, es cualquier indicación de transición recibida desde el UE mientras se utilice como módem de datos debe ignorarse. De este modo, la naturaleza de las aplicaciones que se ejecutan en el equipo de usuario podrían 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 de UMTS, el equipo de usuario puede preferir entrar a un estado de Cell_PCH en lugar de entrar al estado inactivo por varias razones. Una razón podría ser que el UE necesita conectarse a un estado de Cell_DCH más rápidamente si los datos necesitan enviarse o recibirse, y de este modo cambiarse a un estado Cell_PCH ahorrará cierta señalización de red y recursos de batería mientras aún proporciona una transición rápida al estado de Cell_DCH. Lo anterior igualmente se puede aplicar en redes sin UMTS y puede proporcionar un perfil de transición entre varios estados conectados e inactivos.

El perfil de transición también puede incluir varios cronómetros, que incluyen pero no se limitan a, duración de inhibición y/o indicación máxima/mensa es de solicitud por ventana de tiempo, cronómetros de retardo y cronómetros de inactividad. Los cronómetros de retardo proporcionan un periodo el cual el elemento de red esperará antes de hacer transición a un nuevo estado o modo. Como se apreciará, incluso si la aplicación se ha encontrado inactiva durante un período de tiempo particular, un retardo puede ser benéfico para asegurar que no más datos adicional se reciban o se transmitan desde la aplicación. Un cronómetro de inactividad podría medir un período de tiempo predeterminado en el cual no se reciben datos o se envían por una aplicación. Si los datos se reciben antes de que finalice el cronómetro de inactividad, típicamente el cronómetro de inactividad se res ablecerá. Una vez que el cronómetro de inactividad termina, el equipo de usuario entonces puede enviar la indicación de la etapa 1810 a la red. Alternativamente, el equipo de usuario puede esperar un cierto período, tal como aquel definido para el cronómetro de retardo, antes de enviar la indicación de la etapa 1810.

Además, el cronómetro de retardo o duración de inhibición y/o indicación máxima/mensajes de solicitud por ventana de tiempo podrían variar basándose un perfil que se proporciona al elemento de red. De este modo, si la aplicación que ha solicitado una transición a un modo o estado diferente es un primer tipo de aplicación, tal como una aplicación de correo electrónico, el cronómetro de retardo en el elemento de red puede establecerse en un primer tiempo de retardo, mientras si la aplicación desde un segundo tipo tal como una aplicación de mensajería instantánea, el cronómetro de retardo puede establecerse en un segundo valor. Los valores de la duración de inhibición y/o indicación máxima/mensajes de solicitud por ventana de tiempo, cronómetro de retardo o cronómetro de inactividad también podrían derivarse por la red basándose en el APN utilizado para un PDP en particular.

Como se apreciará por aquellos con experiencia en la técnica, el cronómetro de inactividad similarmente podría variar basándose en la aplicación utilizada. De este modo, una aplicación de correo electrónico puede tener un cronómetro de inactividad más corto que una aplicación de explorador puesto que la aplicación de correo electrónico espera un mensaje discreto después del cual puede no recibir datos. Inversamente la aplicación de explorador puede utilizar datos incluso después de un retardo más prolongado y de este modo requiere un cronómetro de inactividad más prolongado .

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

El perfil de transición además puede incluir varios valores de tiempo de recepción discontinua (DRX) . Además, un perfil de avance para los tiempos de DRX podría proporcionarse en un perfil de transición.

El perfil de transición podría definirse en una base de cada aplicación para aplicación o ser un compuesto de varias aplicaciones en el equipo de usuario.

Como se apreciará por aquellos con experiencia en la técnica el perfil de transición podrían crearse o modificarse de manera dinámica cuando un recurso de radio se asigne y podría hacerse en la suscripción, registro de PS, activación de PDP, activación RAB o RB o cambiarse al vuelo para el PDP o RAB/RB. El perfil de transición también podría ser parte de la indicación de la etapa 1810. En este caso, la red puede considerarse la indicación de estado de RRC preferido para determinar si permite la transición y en qué estado/modo. La modificación podría presentarse basándose en recursos de red disponibles, patrones de tráfico, entre otros.

El perfil de recursos de radio por lo tanto se comprende 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 descripción anterior no se pretende para limitar el presente método y sistema. En particular, el perfil de recursos de radio podría incluir y excluir varios elementos descritos en lo anterior. Por ejemplo, en algunos casos, el perfil de recursos de radio simplemente incluirá la calidad de servicio para un recurso de radio en particular y no incluirá otra información. En otros casos, el perfil de recursos de radio incluirá sólo el perfil de transición. En aún otros casos, el perfil de recursos de radio incluirá toda la calidad del servicio, APN, contexto de 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 protecciones para evitar transiciones innecesarias. Tales protecciones podrían incluir, pero no se limitan a, el número de indicaciones recibidas en un período de tiempo predeterminado, el número total de indicaciones recibidas, patrones de tráfico y datos históricos.

El número de indicaciones recibidas en un período de tiempo predeterminado podrían indicar a la red que no deber presentarse una transición. De este modo, si el equipo de usuario ha enviado, por ejemplo, cinco indicaciones dentro de un periodo de tiempo 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 indicación adicional ya sea de manera indefinida o por cierto período de tiempo configurado o predeterminado. Esto podría ser independiente de cualquier "duración de inhibición y/o indicación máxima/mensajes de solicitud por ventana de tiempo" en el UE .

Además, el UE podría configurarse para no enviar indicaciones adicionales durante un período de tiempo configurado, predefinido o negociado. La configuración del UE podría ser exclusiva de las protecciones en el lado de red descrito en lo anterior.

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

Si múltiples recursos de radio se asignan al equipo de usuario, la red puede necesitar considerar el perfil de recursos de radio completo para el equipo de usuario. En este caso, los perfiles de recursos de radio para cada recurso de radio pueden examinarse y tomarse una decisión de transición compuesta. Basándose en el perfil de recursos de radio de uno o múltiples recursos de radio, la red puede decidir entonces si debe hacerse o no una transición.

Una Limitación Adicional en las Indicaciones de Transición Como se describe previamente, existen varios mecanismos por los cuales un UE puede haber hecho transición a su estado de RRC actual. El inicio para la transición pueden haberse impulsado totalmente por la red, por ejemplo, como resultado de inactividad observada. En este ejemplo, la red mantiene los cronómetros de inactividad para cada uno de los estados RRC. Si el cronómetro de inactividad para el estado de RRC actual del UE expira, entonces la red enviará un mensaje de reconfiguración de RRC para hacer transición del UE a un estado diferente. Alternativamente, el inicio de la transición pueden haber sido impulsado por el UE que utiliza un mecanismo de indicación de transición como se describe en lo anterior (por ejemplo con el uso de un mensaje de indicación de transición) . Puesto que la red tiene el control de la máquina de estado de RRC, en este caso el UE puede enviar una indicación a la red de que no necesita mantenerse en el estado de RRC actual y solicita una transición a un estado de RRC menos consumidor de batería.

En una modalidad, se pone una limitación en la capacidad del UE transmita 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 previamente transmitida por el UE.

En otra modalidad, 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 previamente transmitida por el UE .

En otra modalidad, el número de indicaciones de transición que el UE puede enviar en estados específicos se limita sin importar la forma en la cual 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 aplica esta limitación.

Inhibir cualquier indicación de transición adición después de un cambio de estado de RRC a partir de una indicación de transmisión previamente transmitida En algunas modalidades, si el UE se encuentra en su estado actual como resultado de haber transmitido previamente una indicación de transición, se evita que el UE transmita cualquier indicación de transición adicional cuando se encuentre en este estado actual.

El UE puede mantener el indicador, ficha de bit, u otro indicador que indica si se le permite al UE enviar indicaciones de transición a la red mientras se encuentra en su estado actual. Si el UE se reconfigura por la red en un nuevo estado de RRC (por ejemplo, la red envía un mensaje de reconfiguración al UE para efectuar una transición al nuevo estado de RRC) , después de haber enviado una indicación de transición a la red entonces este indicador, ficha de bit, u otro indicador se establece (o se borra alternativamente) indicando que el UE no se le permite enviar indicaciones de transición adicionales mientras permanezca su estado actual . Si el UE cambia el estado de RRC, debido a una solicitud de transacción de datos por el UE (por ejemplo, debido a que su memoria intermedia muestra que tiene datos que enviar) o por la red (por ejemplo, debido a que la red ha buscado el UE) , entonces, este indicador se borra (o alternativamente se establece) para indicar que el UE una vez más se le permite enviar una indicación de transición a la red.

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

En algunas modalidades, si el UE se encuentra en su estado actual, como resultado de haber transmitido previamente una indicación de transición, al UE ya no se le permite transmitir más que 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 modalidades, el número predeterminado se codifica en el UE. En otras modalidades, el número predeterminado se configura por la red, y se somete a cambiados cuando el UE se mueve entre diferentes redes. La configuración de red puede llevarse a cabo, por ejemplo, utilizando un mensaje de señalización directamente a la estación móvil, o como parte de un mensa e de difusión.

El UE mantiene un indicador, ficha de bit, u otro indicador que indica si el UE se le permite enviar un número fijo de las indicaciones de transición a la red mientras permanezca en su estado actual. Si el UE ha hecho transición a este estado actual como resultado de haber enviado una indicación de transición en un estado previo, entonces, este indicador, ficha de bit, u otro indicador se establecerá. Si el UE ha hecho la transición a este estado actual como resultado de transiciones impulsadas por red normales basándose en cronómetros de inactividad, por ejemplo, entonces, este indicador, ficha de bit, u otro indicador no se establecerán y no habrán restricción en el número de indicaciones de transición que el UE puede enviar en su estado actual.

En el caso donde el indicador, ficha de bit un indicador se establece indicando que al UE sólo se le permite 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 se envxan por el UE después de que ha determinado que recién ha hecho transición a su estado actual, como resultado de una indicación de transición previamente transmitida.

En este ejemplo, si una vez se encuentra en el estado actual, el UE desea de manera subsiguiente transmitir una indicación de transición de este estado actual, primero ve el indicador, ficha de bit u otro indicador para ver si se limitó el número de indicaciones de transición que puede enviar a la red mientras permanece en su estado actual. Si se encuentra limitado, entonces el UE mantiene el conteo del número de indicaciones de transición que envía con la condición de que la respuesta de red para el indicador de transición sea para mover el UE a su estado de RRC actual (en el caso en donde el UE necesita hacer 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 donde el UE puede enviar el indicador de transición en su estado actual) .

Si cuando el UE compara el valor del contador de indicación de transición por el número máximo predeterminado de indicaciones de transición adicionales permitidas (posiblemente indicadas por un indicador, ficha de bit 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á de manera subsiguiente indicaciones de transición adicionales a la red.

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

Si el UE cambia el estado de RRC, debido a una solicitud de transacción de datos por el UE (por ejemplo, debido a que su memoria intermedia muestra que tiene datos que enviar) o por la red (por ejemplo, debido a que la red se ha buscado el UE) , entonces este indicador se borra (o alternativamente se establece) para indicar que el UE nuevamente le ha permitido enviar una indicación de transición a la red y el contador se restablece Inhibición más de un número predeterminado de las indicaciones de transición En algunas modalidades, se evita el UE haga transmisiones a algo más que un número máximo predeterminado de indicación de transición mientras la red mantiene el UE en su mismo estado actual. En algunas modalidades, el número predeterminado se codifica en el UE. En otras modalidades, el número predeterminado se configura por la red, y se somete a cambiarse cuando la estación móvil se mueve entre diferentes redes. La configuración de red puede llevarse a cabo, 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 el cual cuenta el número de indicaciones de transición que se envían por el UE después de su estado actual. Por lo tanto con una transición al estado actual, y el UE desea de manera subsiguiente transmitir una indicación de transición de este estado actual, entonces el UE mantiene el conteo del número de indicaciones de transición que envía como condición de que la respuesta de red al indicador de transición para regresar al UE su estado de RRC actual (en el caso donde el UE necesita hacer transición a otro estado de RRC para enviar el mensaje de indicación de transición) o para dejar el UE en su estado actual (en el caso en donde el UE puede enviar el indicador de transición en su estado actual) .

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

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

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

Si existe o no una transición de estado que resultado de haber transmitido previamente una indicación de transición puede utilizarse para habilitar/deshabilitar o limitar la transmisión adicional de indicaciones de transición de varias formas: 1) un prerrequisito para permitir la transmisión de una indicación de transición es que la transición de estado previa no debe haber sido el resultado del UE que ha transmitido previamente una indicación de transición. Este prerrequisito puede combinarse con otros prerrequisitos o inhibiciones de manera que la satisfacción del prerrequisito sólo no necesariamente puede permitir 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 previa fue el resultado del UE que ha transmitido previamente una indicación de transición, no más de un número definido de indicaciones de transición se han transmitido por el UE . Este prerrequisito puede combinarse con otros prerrequisitos o inhibiciones de manera que la satisfacción del prerrequisito sólo no necesariamente puede permitir que el UE transmita una indicación de transición 3) si la transición de estado previa fue el resultado del UE tener que ha transmitido previamente una indicación de transición, inhibe 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 tales que si la inhibición no se activa, ella sola no necesariamente puede permitir que el UE transmita una indicación de transición. 4) si la transición de estado previa fue el resultado del UE tener que ha transmitido previamente una indicación de transición, inhibe la transmisión de algo más que 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 tales que si la inhibición no se activa, ella sola no necesariamente puede permitir que el UE transmita una indicación de transición. 5) si la transición del estado previa no fue impulsada el UE, permite la transmisión de una indicación de transición. 6) si la transición de estado previa fue el resultado del UE tener que ha transmitido, previamente una indicación de transición, permite la transmisión de sólo hasta un número definido de indicaciones de transición. 7) para ciertos estados de RRC, permite la transmisión de sólo hasta un número definido de indicaciones de transición.

Interacción con el cronómetro de inhibición Como se indica en lo anterior, el prerrequisito basado en transición de estado o inhibición pueden combinarse con otros prerrequisitos o inhibiciones. Las modalidades se han descrito en lo anterior, las cuales evitan que un UE envíe una indicación de transición durante un cierto período de tiempo después de haber enviado previamente una indicación de transición. En algunas modalidades, esta inhibición se combina con la inhibición/prerrequisito basado en transición de estado descrito en lo anterior.

Por ejemplo, el uso de un cronómetro de inhibición se ha descrito previamente como un mecanismo para evitar que el UE envíe una indicación de transición durante un cierto período de tiempo después de haber enviado previamente una indicación de transición, en la cual un cronómetro de inhibición se inicia después de transmitir un indicación de transición, y el UE se le permite enviar una indicación de transición adicional sólo si el cronómetro de inhibición no se encuentra funcionando. En algunas modalidades, el uso de este cronómetro de inhibición se combina con la inhibición basada en transición de estado como sigue: ¿la transición de estado previa es el resultado del UE ¿que ha transmitido previamente una indicación de transición? inhibe la transmisión de indicación de transición, o inhibe la transmisión de más de un número definido de indicaciones de transición subsiguientes a una transición previa que fue el resultado del UE tener que ha transmitido previamente una indicación de transición; y ¿se encuentra funcionando el cronómetro de inhibición? inhibe la transmisión de la indicación de transición.

En algunas modalidades, sólo existen dos inhibiciones en lugar en cuyo caso, el comportamiento puede resumirse como sigue: permite la transmisión de una indicación de transición si el cronómetro de inhibición no se encuentra funcionando, y el estado actual no fue el resultado de una indicación de transición previa transmitida por el UE, o permite la transmisión de una indicación de transición si el cronómetro de inhibición no se encuentra funcionando, y si menos de un número definido de indicaciones de transición se han transmitido subsiguiente a una transición de estado que fue el resultado del UE que ha transmitido previamente una indicación de transición.

Mantenimiento de Causa de Transición de Estado Previa El UE tiene un mecanismo para mantener una indicación de si el estado actual es resultado de la transmisión previa de una indicación de transición por el UE. Esta indicación puede ser un valor de causa de transición de estado previa almacenado en una memoria en el UE que se acceder por un procesador que forma parte del UE, o un conmutador implementado en hardware por nombrar algunos ejemplos. En un ejemplo específico, la causa de transición de estado previa es un solo bit que es un primer valor ('1' ó 10') para indicar que la transición de estado previa es el resultado del UE que ha transmitido previamente una indicación de transición, o de otra es un segundo valor ('0' ó ?' ) .

Evaluación de Causa de Transición de Estado Previa El UE tiene un mecanismo para determinar si el estado actual es resultado de la transmisión previa de una indicación de transición por el UE .

Si el UE ha enviado la indicación de transición, y esta se ha confirmado por la red de manera que el UE sabe 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 reconfiguración RRC es un 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 ha confirmado) una indicación de' transición dentro de un período predeterminado de tiempo previo que conlleva a la reconfiguración, entonces el UE puede suponer 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 una transición de estado se presenta como resultado de una reconfiguración por la red, el UE evalúa si la transición de estado fue el resultado del UE que ha transmitido previamente una indicación de transición. Si esta fue una causa, el UE actualiza la causa de transición de estado previa para indicar que la transición de estado previa fue impulsada por el UE. Si la transición de estado fue diferente al resultado del UE que ha transmitido previamente una indicación de transición, entonces la causa de transición de estado previa se actualiza por consiguiente.

En algunas modalidades, donde una transición con valor causa se soporta, el UE determina si ha enviado previamente una indicación de transición con un valor de causa para el cual este mecanismo se implementará antes para recibir esta reconfiguración.

En algunas modalidades, el UE realiza las siguientes etapas para determinar si una transición de estado es el resultado del UE que ha transmitido previamente una indicación de transición: 1) transmitir una indicación de transición (o indicación de transición con valor de causa particular) ; 2) si una transición de estado que es consistente con la indicación de transición se presenta dentro de un intervalo de tiempo definido para transmitir la indicación de transición, evaluar la transición de estado para ser el resultado del UE que ha transmitido previamente una indicación de transición, y de otra manera evalúa la transición de estado para ser diferente al resultado del UE que ha transmitido previamente una indicación de transición.

En algunas modalidades, al transmitir una indicación de transición, se inicia un cronómetro comenzar el conteo que cuenta en forma regresiva el inicio de un valor de tiempo fuera, o de manera equivalente que emplea un valor de tiempo fuera. Si el cronómetro aún funciona cuando la transición de estado se presenta, entonces se evalúa como siendo el resultado del UE ha transmitido previamente una indicación de transición.

En algunas modalidades, cualquiera de estas modalidades se implementan utilizando una indicación de transición que incluye un código de causa para permitir el UE especifique una causa para la indicación de transición (por ejemplo, para indicar que una transferencia de datos o llamada se encuentra completa, o que no se esperan más datos adicionales durante un período prolongado) . Un ejemplo específico es la INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN definida en. la TS 25.331 Sección 8.1 0,14 del 3GPP, donde el código de la causa es la "Causa de Indicación de Liberación de Conexión y Señalización" del IE establecida en "Finalización de Sesión de Datos de PS" solicitada por UE .

En algunas modalidades, cualquiera de estas modalidades se implementa utilizando una indicación de transición que no incluye un código de causa. Un ejemplo específico es la INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN definido en la TS 25.331 Sección 8.1 0.14 del 3GPP.

Ejemplo Adicional de la Determinación del Mecanismo para la Transición de Estado de RRC Si el UE recibe un mensaje de reconfiguración de RRC desde la red, puede determinar si ha enviado un mensaje de SCRI con el valor de la causa "Finalización de Sesión de Datos de PS Solicitada por UE" antes de recibir esta reconfiguración.

Si el UE ha enviado este mensaje, y el mensaje se ha confirmado por la red de manera que el UE sabe que la red la recibió, entonces, el UE puede saber que si se recibe el mensaje de reconfiguración de RRC dentro de un período de tiempo fijo, que este mensaje de reconfiguración RRC es un resultado del envío del SCRI.

Si el UE se encuentra en un estado de RRC CELL_CDH o CELL_FACH y ha enviado una SCRI que se ha confirmado, pero la red no envía una reconfiguración de RRC dentro de un período de tiempo fijo, entonces el UE puede suponer que actualmente se encuentra en el estado en que la red desea permanecer, y que el UE puede considerar que el mecanismo para el cual permanece en ese estado es para propósito de Inactividad Rápida.

Si el UE recibe una reconfiguración de RRC y no ha enviado (y no ha confirmado) un mensaje de SCRI, el período de tiempo fijo que conlleva hasta la reconfiguración, entonces el UE puede asumir que la transición de estado no fue para propósito de Inactividad Rápida.

Ejemplos específicos Con referencia al diagrama de estados de la Figura 1, suponer que el UE inicialmente se encuentra 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 confirma la indicación de transición y las transiciones del UE a URA_PCH . En algunas modalidades, este es una transición de estado directa. En otras modalidades, esta es una transición de estado indirecta mediante del estado cell_FACH. Después de eso, al UE no se le permite enviar otra indicación de transición .

Obsérvese que en general, la descripción de las modalidades y el comportamiento que pertenecen al estado URA_PCH también aplica al estado CELL_PCH.

Si, por otro lado, la red decide por si misma hacer transición del UE al URA_PCH, por ejemplo debido a la expiración de un cronómetro de inactividad, al UE se le permite enviar una indicación de transición. En este punto, el UE busca hacer transición al modo inactivo desde URA_PCH . Sin embargo, el UE debe hacer transición a CELL_FACH para enviar la indicación de transición. Recordar que el propósito de la indicación de transición es para que el UE se mueva a un estado de menos batería intensa. Si la red deja el UE en CELL_FACH, esta no es una transición a un estado más eficiente de la batería (el único estado más eficiente batería de URA_PCH es INACTIVO) y de manera que el estado CELL_FACH no se considera que es resultado de una transmisión previa de una indicación de transición. Si la red hace transición del UE URA_PCH o al modo INACTIVO dentro de un período definido, entonces la transición de estado se considera como un resultado de una transmisión previa de una indicación de transición.

Otra Inhibición En algunas modalidades, si el UE ha enviado una indicación de transición que ha sea reconocido, pero la red no envía una reconfiguración de RRC dentro de un período de tiempo fijo, entonces el UE asume que actualmente se encuentra en el estado que la red desea permanecer. En algunas modalidades, en esta secuencia de eventos llevándose a cabo, al UE se le prohibe transmitir una indicación de transición, aunque el estado actual puede no ser necesariamente el resultado del UE que ha transmitido previamente una indicación de transición.

En algunas modalidades, la inhibición antes descrita sólo se implementa si el estado que el UE permanece es el estado RRC de CELL_CDH o CELL_FACH.

Estado Debido a (Inactividad Rápida) En algunas modalidades, cuando el UE se encuentra en un estado que es resultado de una indicación de transición previamente transmitida, se dice que el UE se encuentra en un estado debido a la invocación de la inactividad rápida. En algunas modalidades, cuando el UE ha transmitido una indicación de transición que se reconoce, pero el UE no experimenta un cambio de estado, el UE también se dice que se encuentra en un estado debido a la invocación de inactividad rápida .

Si el UE se transición a un estado de RRC (que no es INACTIVO) y esto no fue debido a una indicación de transición (también denominada como una indicación de transición para propósitos inactividad rápida) , entonces el UE utiliza el cronómetro de inhibición para determinar cuándo se le permite enviar un indicador de transición para propósitos de inactividad rápida. El comportamiento se describe actualmente en la TS 25.331 del 3GPP.

Si el UE hace transición a un estado de RRC (que no es INACTIVO) y esto fue debió a una indicación de transición, entonces el UE tendrá diferentes restricciones sobre su comportamiento. El UE establecerá cierta clase de indicador o indicación de manera interna cuando conozca que se encuentra en esta situación. Por ejemplo, este puede denominarse como el indicador de FDM (Mecanismo de Inactividad Rápida) .

En un caso, el UE se le puede prohibir enviar una indicación de transición adicional. Alternativamente, el UE se le puede permitir enviar solicitudes adicionales de una transición de estado, pero el número de solicitudes adicionales se limita a cierto número definido, por ejemplo uno o más. El período entre el enviar de estos resultados se controla por el cronómetro de inhibición.

Si cuando el UE solicita una transición de estado utilizando la indicación de transición (y esta se ha confirmado) la red deja el UE en su estado actual de RRC (por ejemplo, CELL_FACH) o se mueve de nuevamente al estado de RRC del cual envió el indicador de transición desde (por ejemplo, el UE encontraba en CELL_PCH, se movió a CELL_FACH para enviar el SCRI, después la red se movió al UE nuevamente CELL_PCH) , entonces UE disminuye el número de solicitudes de transición indicación restantes que se le permite a enviar.

Si el UE se mueve a un estado de RRC, debido a una transacción de datos se inicia (por ejemplo, recibe una búsqueda y responde a esta, o solicita recursos de una transacción de datos) entonces el UE borra el indicador de FDM y el procedimiento reinicia.

Si el UE hace una transición al estado CELL_FACH para transmitir un mensaje de CELL_UPDATE o un mensaje de URA_UPDATE y la confirmación de la red del UE se mueven nuevamente estado de CELL_PCH o URA_PCH, entonces, esto no borra el indicador de FDM.

Sí, sin embargo, si el UE hace una transición al estado CELL_FACH para transmitir un mensaje CELL_UPDATE o un mensaje de URA_UPDATE o un mensaje de indicación de transición, y la red deja de manera subsiguiente al UE en el estado de CELL_FACH, entonces el UE borra el indicador de FDM y el procedimiento reinicia.

En algunos casos, se evita que el UE envíe totalmente el mensaje de SCRI después de que el UE hace transición a un estado de RRC diferente en respuesta a una solicitud de Inactividad Rápida que utiliza el mensaje de SCRI con el valor causa "Señalización de sesión de datos de PS solicitada por UE" . En este caso el UE establece el indicador de FDM y sólo se borra este indicador cuando se mueve a un estado de RRC diferente para una transacción de datos que es iniciada por el UE o por la red.

En algunos casos, al UE sólo se permite 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 los diferentes estados. Por ejemplo, al UE sólo se le permite transmitir Mn" mensajes de indicación de transición (con o sin el código de causa como se describe anteriormente) , cuando se encuentra en los Estados de RRC CELL_PCH o URA_PCH .

En algunas modalidades, los métodos y dispositivos que cumplen con el Sistema de Telecomunicación Móvil Universal (UMTS) de la TS 25.331 del 3GPP, Control de Recursos de Radio (RRC) , especificación de Protocolo, Liberación 8, o una evolución de la misma, con modificaciones para facilitar o implementar una o más de las modalidades descritas en la presente se proporcionan. Ejemplos de estas se proporcionan en el Apéndice A, Apéndice B, y Apéndice C. Todos estos ejemplos se refieren al uso de SCRI, pero de manera más general se contempla el uso de cualquier indicación de transición.

En algunas modalidades (véase al Apéndice A para una implementación ejemplar) , una variable de estado interna de UE se define cuando se establece el primer tiempo en que el UE activo FD desde dentro del estado de PCH. Si se establece, entonces se evita que el UE active FD nuevamente dentro del estado de PCH, la variable se restablece cuando nuevos datos PS llegan para transmisión.

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

Si N316 se fija para ser 1, entonces el comportamiento es equivalente a la V316 que es una variable de estado de Boolean. Observe que el UE que tiene datos de PS disponibles para transmisión excluye específicamente el envío de una indicación de transición (tal como SCRI con causa) y provoca que el contador V316 se restablezca. En este contexto, el UE que tiene datos de PS disponibles por ejemplo, puede significar que el usuario tiene datos que transmitir en RB3 (portadora de radio 3) o más (el mensaje SCRI se envía en RB2 ) .

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

En algunas modalidades (véase apéndice C para una implementación ejemplar) , al UE se le prohibe transmitir una indicación de transición (tal como SCRI con causa) si la red mueve el UE al estado de PCH en respuesta a una indicación de transición (tal como SCRI con causa) transmitida por el UE mientras se encuentra en estado de DCH o FACH. Para inhibir la indicación de transición (tal como SCRI con causa) puede hacerse al establecer de V316 a N316. El UE evalúa si el movimiento se instruye por la red 'en respuesta' a la indicación de transición. Mecanismos descritos previamente pueden utilizarse para esto: por ejemplo, el UE puede juzgar si este es el caso si la reconfiguración se recibe dentro de un cierto tiempo para enviar la indicación de transición.

En algunas modalidades, un nuevo indicador se puede agregarse al mensaje de reconfiguración que puede establecerse en VERDADERO si el mensaje de reconfiguración se activa en la red por la recepción de un SCRI con la causa, de este modo permitiendo que el UE conozca ciertas reconfiguraciones en respuesta a la SCRI con causa. Un ejemplo de esto se representa en el Apéndice D.

En muchas modalidades diferentes para inhibir la transmisión de una indicación de transición, ya sea completamente o en cierto número máximo de las indicaciones de transición, se han descrito. Muchas de éstas 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 de batería más extensa que el Estado del UE antes de enviar una transición de estado.

En algunas modalidades, un mecanismo para evitar la transmisión de una indicación de transición se implementa, o no en una base por estado; en algunas modalidades, para ciertos estados no se implementa ningún mecanismo. En otras modalidades, un mecanismo diferente se utiliza para cada uno de por lo menos dos estados.

En una modalidad, la red tiene una pluralidad de opciones sobre cómo proceder cuando se ha recibido una indicación en la etapa 1810 y examina de manera opcional el perfil de recursos de radio o de perfiles en la etapa 1820.

Una primera opción es hacer nada. La red puede decidir que una transición no sea garantizada y de este modo no acepta la indicación de equipos de usuario hacer transición. Como se apreciará por aquellos con experiencia en la técnica, hacer nada ahorra señalización de red puesto que el estado no se cambia y en particular puesto que no se activa una transición.

Una segunda opción es cambiar el estado del dispositivo. Por ejemplo, en una red de UMTS, el estado del dispositivo puede cambiar de Cell_DCH a Cell_PCH. En redes sin UMTS, la transición de estado puede presentarse entre los estados conectados. Como se apreciará por aquellos con experiencia en la técnica, cambiar los estados reduce la cantidad de señalización de red central cuando se compara con una transición al modo inactivo. Cambiar el estado también puede ahorrar recursos de radio puesto que el estado de Cell_PCH no requiere un canal dedicado. También Cell_PCH es un estado con menos intensidad de batería que permite el UE ahorrar energía de 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 APN particular o contexto de PDP. Este procedimiento ahorra recursos de radio y señalización cuando la conexión se mantiene en su estado actual y no necesita restablecerse. Sin embargo, puede ser menos adecuado para situaciones donde la vida de batería del UE es una preocupación.

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

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

Otras opciones pueden ser evidentes para aquellos de experiencia en la técnica.

La decisión de la red en la cual utilizar cinco o más opciones variará de red a red. Algunas redes sobrecargadas pueden preferir ahorrar recursos de radio y de este modo pueden elegir la tercera, cuarta o quinta opciones anteriores. Otras redes prefieren reducir la señalización y de este modo pueden elegir la primera o segunda opciones anteriores.

La decisión se muestra en la Figura 18 en la etapa 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 por la red que recibe una indicación del equipo de usuario que el equipo de usuario puede desear hacer transición a otro estado, por ejemplo, un estado de menos batería intensa.

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 se apreciará por aquellos con experiencia en la técnica, el subsistema 1920 de comunicaciones no necesita comunicarse directamente con el equipo de usuario, pero podría ser parte de una trayectoria de comunicación para comunicación hasta y desde el equipo de usuario.

El elemento 1910 de red además incluye un procesador 1930 y un almacén 1940. El almacén 1940 se adapta para almacenar perfiles de recursos de radio preconfigurados o estáticos para cada equipo de usuario que se atiende por el elemento 1910 de red. El procesador 1930 se adapta para, con la recepción de una indicación por el subsistema 1920 de comunicación, considerar el perfil de recursos de radio para el equipo de usuario y decidir sobre una acción de red con respecto a la transición del equipo de usuario. Como se apreciará por aquellos con experiencia en la técnica, la indicación recibida por el subsistema 1920 de comunicación podría incluir además una porción de una parte o todo el perfil de recursos de radio para que el equipo de usuario, entonces pueda utilizarse por el procesador 1930 para tomar la decisión de red que concierne a cualquier transición.

Basándose en lo anterior, un elemento de red por lo tanto recibe una indicación del equipo de usuario de que una transición puede encontrarse en orden (tal como, por ejemplo, cuando un intercambio de datos se completa y/o que no esperan más datos en el UE) . Basándose en esta indicación, el elemento de red opcionalmente comprueba el perfil del recurso de radio del equipo de usuario, el cual podría incluir ambos elementos del perfil estático y dinámico. El elemento de red además puede comprobar las protecciones para asegurar que no se presenten transiciones innecesarias. El elemento de red entonces puede decidir no hacer nada o hacer transición a un modo o estado diferente, o desmantelar un recurso de radio. Como se apreciará, esto proporciona más control a la red de sus recursos de radio y permite que la red configure las decisiones de transición basadas sobre preferencias de red en lugar de sólo las preferencias del equipo de usuario. Además, en algunos casos la red tiene más información que el dispositivo con respecto a si hace transición. Por ejemplo, el equipo de usuario tiene conocimiento de comunicaciones corriente arriba y basándose en esto puede decidir que la conexión puede desmantelarse. Sin embargo, la red puede tener comunicaciones corriente abajo recibidas para el equipo de usuario y de este modo darse cuenta de que no puede desmantelar la conexión. En este caso, también puede introducirse un retardo utilizando el cronómetro de retardo para proporcionar la red con más certidumbre de que no se recibirán datos para el equipo de usuario en un futuro cercano.

Las modalidades descritas en la presente son ejemplos de estructuras, sistemas o métodos que tienen elementos que corresponden con elementos de las técnicas de esta descripción. Esta descripción escrita puede permitir que aquellos con experiencia en la técnica hagan y utilicen modalidades que tienen elementos alternativos que de igual forma corresponden con elementos de las técnicas de esta descripción. El alcance pretendido de las técnicas de esta descripción de este modo incluyen otras estructuras, sistemas o métodos que no difieren de las técnicas de esta descripción como se describe en la presente, y además incluyen otras estructuras, sistemas o métodos con diferencias insustanciales de las técnicas de esta descripción como se describe en la presente.

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 procedimiento de indicación de liberación de conexión de señalización se utiliza por el UE para indicar a la UTRAN que una de sus conexiones de señalización se ha liberado. El procedimiento a su vez puede iniciar el procedimiento de liberación de conexión de RRC. 8.1.14.2 Inicio El UE debe, al recibir una solicitud para liberar (abortar) la conexión de señalización de capas superiores para un dominio de CN específico: 1> si una conexión de señalización es la variable ESTABLISHED_SIGNALLING_CONNECTIONS para el dominio de CN específico identificado con el IE "identidad de dominio de CN" existe: 2> iniciar el procedimiento de indicación de liberación de conexión de señalización. 1> de otra manera: 2> abortar cualquier establecimiento en proceso de conexión de señalización para el dominio de CN específico como se especifica en 8.1.3.5a.

Con el inicio del procedimiento de indicación de liberación de conexión de señalización en el estado de CELL_PCH o URA_PCH, el UE debe: 1> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 2> moverse al estado de CELL_FACH; 2> restablecer el cronómetro T305 utilizando su valor inicial si la actualización de celda periódica se ha configurado por T305 en el IE "cronómetros de UE y constantes en el modo conectado" establecidos en cualquier otro valor que "infinidad". 1> además : 2> si la variable H_R TI y la variable C_RNTI se establecen: 3> continuar con el procedimiento de indicación de liberación de conexión de señalización como en lo anterior. 2> además: 3> realizar un procedimiento de actualización de celda, de acuerdo con la subcláusula 8.3.1, utilizando la causa "transmisión de datos de enlace ascendente"; 3> cuando el procedimiento de actualización de celdas se complete con éxito: 4> continuar con el procedimiento de indicación de liberación de conexión de señalización como en lo anterior.

El UE debe: 1> establecer el IE "identidad de dominio de CN" en el valor indicado por las capas superiores . El valor de IE indica el dominio de CN cuya conexión de ' señalización asociada en las capas superiores que indican que se libere; 1> remover la conexión de señalización con la identidad indicada por las capas superiores de la variable ESTABLISHED_SIGNALLI G_CONNECTIONS ; 1> transmitir un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH utilizando AM RLC .

Cuando la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el procedimiento finaliza.

Además, si el valor del cronómetro T323 se almacena en el IE "cronómetros de UE y constantes en el modo conectado" la variable TIMERS_AND_CONSTANTS , y si no existe ninguna conexión de dominio de CS indicada en la variable ESTABLISHED_SIGNALLING_CONNECTIONS, el UE puede: 1> si las capas superiores indican que no existen más datos de PS durante un período prolongado: 2> si el cronómetro T323 no funciona: 3> si el UE se encuentra en un estado de CELL_DCH o un estado de CELL_FACH; o 3> si el UE se encuentra en el estado CELL_PCH o el estado de URA_PCH y "activado" en la variable TRIGGERED_SCRI_IN_PCH_STATE es FALSO: 4> si el UE se encuentra en el estado de CELL_PCH o URA_PCH, establecer en "activado" en la variable TRIGGERED_SCRI_IN_PCH_STATE en VERDADERO; 4> establecer el IE "identidad de dominio de CN" en el dominio de PS; 4> establecer el IE "Causa de Indicación de Liberación de Conexión de Señalización" en " finalización de sesión de Datos de PS Solicitada por UE"; 4> transmitir un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH utilizando A RLC; 4> iniciar el cronómetro T323.

Cuando la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el procedimiento finaliza.

Al UE se le debe prohibir enviar el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN 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 de PS Solicitada por UE" , mientras que el cronómetro T323 se encuentra funcionando.

Después de enviar el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN 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 de PS Solicitada por UE", si los datos de PS se vuelven disponibles para transmisión, entonces el UE debe establecer "activado" en la variable TRIGGERED_SCRI_IN_PCH_STATE como FALSO. 8.1.14.2a Restablecimiento de RLC o cambio inter-RAT Si un restablecimiento del lado de transmisión de la entidad de RLC en la portadora de radio RB2 de señalización se presenta antes de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el UE debe: 1> retransmitir el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH de enlace ascendente utilizando AM RLC en la portadora de radio RB2 de señalización .

Si una transferencia inter-RAT del procedimiento de UTRAN se presenta antes de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el UE debe: 1> abortar la conexión de señalización mientras se encuentra en el nuevo RAT. 8.1.14.3 Recepción de la INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN por la UTRAN Con la recepción del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, si el IE "Causa de Indicación de Liberación de Conexión de Señalización" no se incluye, la UTRAN solicita la liberación de la conexión de señalización de las capas superiores. Las capas superiores entonces pueden iniciar la liberación de conexión de señalización .

Si el IE "Causa de Indicación de Liberación de Conexión de Señalización" se incluye en el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, la UTRAN puede iniciar una transición de estado a consumo de batería eficiente estado IDLE, CELL_PCH, URA_PCH o CELL_FACH. 8.1.14.4 Expiración del cronómetro T323 Cuando el cronómetro T323 expira: 1> el UE puede determinar si alguna indicación subsiguiente de las capas superiores no existen más datos de PS durante un período prolongado, en cuyo caso activa la transmisión de un solo mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN de acuerdo con la cláusula 8.1.14.2; 1>, el procedimiento finaliza. 13. .27x TRIGGERED_SCRI_IN_PCH_STATE Esta variable contiene información sobre si un Mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha activado en los estados de CELL_PCH o URA_PCH. Existe tal variable en el UE Apéndice B 8.1.14 Procedimiento de indicación de liberación de conexión de señalización La 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 se utiliza por el UE para indicar a la UTRAN que una de sus conexiones de señalización se ha liberado. El procedimiento a su vez puede iniciar el procedimiento de liberación de conexión de RRC. 8.1.14.2 Inicio El UE debe, al recibir una solicitud para liberar (abortar) la conexión de señalización de capas superiores para un dominio de CN especifico: 1> si una conexión de señalización es la variable ESTABLISHED_SIGNALLING_CONNECTIONS para el dominio de CN especifico identificado con el IE "identidad de dominio de CN" existe: 2> iniciar el procedimiento de indicación de liberación de conexión de señalización. 1> de otra manera: 2> abortar cualquier establecimiento en proceso de conexión de señalización para el dominio de CN específico como se especifica en 8.1.3.5a.

Con el inicio del procedimiento de indicación de liberación de conexión de señalización en el estado de CELL_PCH o URA_PCH, el UE debe: 1> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 2> moverse al estado de CELL_FACH; 2> restablecer el cronómetro T305 utilizando su valor inicial si la actualización de celda periódica se ha configurado por T305 en el IE "cronómetros de UE y constantes en el modo conectado" establecidos en cualquier otro valor que "infinidad". 1> además : 2> si la variable H_RTI y la variable C_RNTI se establecen : 3> continuar con el procedimiento de indicación de liberación de conexión de señalización como en lo anterior. 2> además: 3> realizar un procedimiento de actualización de celda, de acuerdo con la subcláusula 8.3.1, utilizando la causa "transmisión de datos de enlace ascendente"; 3> cuando el procedimiento de actualización de celdas se complete con éxito: 4> continuar con el procedimiento de indicación de liberación de conexión de señalización como en lo anterior.

El UE debe: 1> establecer el IE "identidad de dominio de CN" en el valor indicado por las capas superiores . El valor de IE indica el dominio de NC cuya conexión de señalización asociada en las capas superiores que indican que se libere; 1> remover la conexión de señalización con la identidad indicada por las capas superiores de la variable ESTABLISHED_SIGNALLING_CONNECTIONS; 1> transmitir un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH utilizando AM RLC .

Cuando la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el procedimiento finaliza.

Además, si el valor del cronómetro T323 se almacena en el IE "cronómetros de UE y constantes en el modo conectado" la variable TIMERS_AND_CONSTANTS , y si no existe ninguna conexión de dominio de CS indicada en la variable ESTABLISHED_SIGNALLING_CONNECTIONS , el UE puede: 1> si las capas superiores indican que no existen más datos de PS durante un período prolongado : 2> si el cronómetro T323 no funciona: 3> si el UE se encuentra en un estado de CELL_DCH o un estado de CELL_FACH; o 3> si el UE se encuentra en el estado CELL_PCH o el estado de URA_PCH y V316 < N316: 4> si el UE se encuentra en el estado de CELL_PCH o URA_PCH, incrementar N316 por 1; 4> establecer el IE "identidad de dominio de CN" en el dominio de PS; 4> establecer el IE "Causa de Indicación de Liberación de Conexión de Señalización" en " finalización de sesión de Datos de PS Solicitada por UE"; 4> transmitir un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH utilizando AM RLC; 4> iniciar el cronómetro T323.

Cuando la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACION se ha confirmado por el RLC, el procedimiento finaliza.

El UE se le debe prohibir enviar el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN 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 de PS Solicitada por UE", mientras que el cronómetro T323 se encuentra funcionando.

Si los datos de PS se vuelven disponibles para transmisión o el UE recibe un mensaje de búsqueda que activa el procedimiento de actualización de celda, el UE debe establecer V316 en cero. 8.1.14.2a Restablecimiento de RLC o cambio inter-RAT Si un restablecimiento del lado de transmisión de la entidad de RLC en la portadora de radio RB2 de señalización se presenta antes de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el UE debe: 1> retransmitir el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH de enlace ascendente utilizando A RLC en la portadora de radio RB2 de señalización.

Si una transferencia inter-RAT del procedimiento de UTRAN se presenta antes de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el UE debe: 1> abortar la conexión de señalización mientras se encuentra en el nuevo RAT. 8.1.14.3 Recepción de la INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN por la OTRAN Con la recepción del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, si el IE "Causa de Indicación de Liberación de Conexión de Señalización" no se incluye, la UTRAN solicita la liberación de la conexión de señalización de las capas superiores. Las capas superiores entonces pueden iniciar la liberación de conexión de señalización.

Si el IE "Causa de Indicación de Liberación de Conexión de Señalización" se incluye en el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, la UTRAN puede iniciar una transición de estado a consumo de batería eficiente estado IDLE , CELL_PCH, URA_PCH o CELL_FACH. 8.1.14.4 Expiración del cronómetro T323 Cuando el cronómetro T323 expira: 1> el UE puede determinar si alguna indicación subsiguiente de las capas superiores no existen más datos de PS durante un período prolongado, en cuyo caso activa la transmisión de un solo mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN de acuerdo con la cláusula 8.1.14.2; 1>, el procedimiento finaliza. 8.3 Procedimientos de movilidad de conexión de RRC Procedimientos de actualización de CELDA URA UE UTRAN ACTUALIZACIÓN DE CELDA CONFIRMAR ACTUALIZACIÓN DE CELDA Figura 8.3.1-2 procedimiento de actualización celda, flujo básico UE UTRAN ACTUALIZACIÓN DE CELDA' CONFIRMAR ACTUALIZACIÓN DE CELDA CONFIRMAR INFORMACIÓN DE MOVILIDAD DE UTRAN Figura 8.3.1-2 procedimiento de actualización de celda, flujo básico con actualización de información de movilidad de UTRAN UE UTRAN ACTUALIZACIÓN DE CELDA CONFIRMAR ACTUALIZACIÓN DE CELDA COMPLETAR RECONFIGURACIÓN DE CANAL FÍSICO 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 celda con liberación de portadora de radio Figura 8.3.1-6 procedimiento de actualización de celda con reconfiguración de portadora de radio Figura 8.3.1-6a procedimiento de actualización de celda con establecimiento de portadora de radio Figura 8.3.1-7 procedimiento de actualización celda, caso de falla Figura 8.3.1-8 procedimiento de actualización URA, flujo básico UE UTRAN ACTUALIZACIÓN DE CELDA CONFIRMAR ACTUALIZACIÓN DE URA CONFIRMAR INFORMACIÓN DE MIVILIDAD DE UTRAN Figura 8.3.1-9 procedimiento de actualización de URA con actualización de información de movilidad de UTRAN UE UTRAN ACTUALIZACIÓN DE CELDA LIBERAR CONEXIÓN DE RRC Figura 8.3.1-10 procedimiento de actualización URA, caso de falla 8.3.1.1 General Los procedimientos de actualización de URA y actualización de celda sirven para varios propósitos principales : - para notificar a la UTRAN después de reingresar al área de servicio en el estado de URA_PCH o CELL_PCH; para notificar a la UTRAN de un error irrecuperable de RLC [16] en una entidad de A RLC; - para utilizarse como un mecanismo de supervisión en el estado de CELL_FACH, CELL_PCH o URA_PCH por medio de una actualización periódica.

Además, el procedimiento de actualización de URA también sirve para el siguiente propósito: - para recuperar una nueva identidad de URA después de la re-selección de celda en una celda que no pertenece a la URA actual asignada al UE en el estado de URA_PCH.

Además, el procedimiento de actualización de celda también sirve para los siguientes propósitos: - para actualizar la UTRAN con la celda actual en la que se sitúa el UE después de la re-selección de celda; - para actuar en una falla de enlace de radio en el estado de CELL_DCH; para actuar en la falla de transmisión del mensaje de INFORMACIÓN DE CAPACIDAD DE UE; - para FDD y TDD 1.28 Mcps, si la variable H_RNTI no se establece, y para TDD de 3.84 Mcps y TDD de 7.68 Mcps; cuando se activa en el estado de URA_PCH o CELL_PCH para notificar a la UTRAN de una transición al estado de CELL_FACH debido a la recepción de la UTRAN que originó la búsqueda o debido a una solicitud de transmitir datos de enlace ascendente; - para contar el número de UEs en URA_PCH, CELL_PCH CELL_FACH que se interesan en recibir una transmisión de MBMS; - cuando se activa en el estado de URA_PCH, CELL_PCH y CELL_FACH, para notificar a la UTRAN del interés de UEs para recibir el servicio de MBMS; - para solicitar el establecimiento de MBMS P-T-P RB por el UE en el estado de CELL_PCH, URA_PCH y CELL_FACH.

Los procedimientos de actualización de URA y actualización de celda pueden: 1> incluir una actualización de la información relacionada con la movilidad en el UE; 1> provocar una transición de estado desde del estado de CELL_FACH a los estados de CELL_DCH, CELL_PCH O URA_PCH o modo inactivo.

El procedimiento de actualización de celda también puede incluir: - un re-establecimiento de las entidades de AM RLC; - una liberación de portadora de radio, reconfiguración de portadora de radio, reconfiguración de canal de transporte o reconfiguración de canal físico. 8.3.1.2 Inicio Un UE de iniciar el procedimiento de actualización de celda en los siguientes casos: 1> Transmisión de datos de enlace ascendente; 2> para FDD y TDD de 1.28 Mcps , si la variable H_RNTI no se establece, y para TDD de 3.84 Mcps y TDD de 7.68 Mcps ,- 3> si el UE se encuentra en el estado de URA_PCH o CELL_PCH, y 3> si el cronómetro T320 no funciona; 4> si el UE tiene PDU de datos de RLC de enlace ascendente o PDU de control de RLC de enlace ascendente en RB1 o más para transmitir; 5> realizar actualización de celda utilizando la causa "transmisión de datos de enlace ascendente". 3>además : 4> si la variable ESTABLISHMENT_CAUSE se establece: 5> realizar la actualización de celda utilizando la causa "transmisión de datos de enlace ascendente". 1> Respuesta de búsqueda: 2> si el criterio para realizar actualización de celda con la causa especificada en lo anterior en la subcláusula actual no se cumplen; y 2> si el UE en el estado de URA_PCH o CELL_PCH, recibe un mensaje de TIPO DE BÚSQUEDA 1 que cumple con las condiciones para iniciar un procedimiento de actualización de celda especificado en la subcláusula 8.1.2.3: 3> realizar la actualización de celda utilizando la causa "respuesta de búsqueda" . 1> Falla en el enlace de radio: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen: 3> si el UE se encuentra en el estado de CELL_DCH y los criterios para la falla de enlace de radio se cumplen como se especifica en la subcláusula 8.5.6; o 3> si la transmisión del mensaje de INFORMACION DE CAPACIDAD DE UE falla como se especifica en la subcláusula 8.1.6.6: 4> realizar la actualización de celda utilizando la causa "falla de enlace de radio". 1> solicitud de MBMS ptp RB : 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE se encuentra en el estado de URA_PCH, Cell_PCH o Cell_FACH; y 2> si el cronómetro T320 no funciona; y 2> si el UE debe realizar la actualización de celda para solicitud de portadora de radio MBMS ptp como se especifica en la subcláusula 8.6.9.6: 3> realizar la actualización de celda utilizando la causa "Solicitud MBMS ptp RB" . 1> reingresar al área de servicio : 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE se encuentra en el estado de CELL-FACH o CELL_PCH; y 2> si el UE se ha establecido fuera del área de servicio y reingresa al área de servicio antes de que expire T307 o T317: 3> realizar la actualización de celda utilizando la causa "regresar al área de servicio". 1> error irrecuperable de RLC: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE detecta un error irrecuperable de RLC [16] en una entidad de AM RLC; 3> realizar la actualización de celda utilizando la causa "error irrecuperable de RLC". 1> Reselección de celda: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; 3> si el UE se encuentra en el estado de CELL_FACH o CELL_PCH y el UE realiza la re-selección de celdas; o 3> si el UE se encuentra en el estado de CELL_FACH y la variable C_RTI se encuentra vacía: 4> realizar la actualización de celda utilizando la causa "re-selección de celda" . 1> Actualización de celda periódica: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE se encuentra en el estado de CELL-FACH o CELL_PCH; y 2> si el cronómetro T305 expira; y 2> si los criterios para "área en servicio" como se especifica en la subcláusula 8.5.5.2 se cumplen; y 2> si la actualización periódica se ha configurado por T305 en el IE "cronómetros y constantes de UE en el modo conectado" se establecen en cualquier valor diferente a "infinidad" : 3> para FDD: 4> si la variable COMMON_E_DCH_TRA SMISSION se establece en FALSO: 5> realizar la actualización de celda utilizando la causa "actualización de celda periódica" . 4> además: 5> reiniciar el cronómetro T305; 5> y finalizar el procedimiento. 3> para TDD de 1.28 Mcps y TDD de 3.84/7.68 Mcps; 4> realizar la actualización de celda utilizando la causa "actualización de celda periódica" . 1> recepción de MBMS : 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE se encuentra en el estado de URA_PCH, Cell_PCH o Cell_FACH; y 2> si el UE debe realizar la actualización de celda para conteo de MBMS como se especifica en la subcláusula 8.7.4: 3> realizar actualización de celda utilizando la causa "recepción de MBMS".

Un UE en el estado de URA_PCH iniciará el procedimiento de actualización de URA en los siguientes casos : 1> reselección de URA: 2> si el UE detecta que el URA actual asignado al UE, almacenado en la variable URA IDENTITY, no se encuentra en la lista de identidades de URA en el bloque de información de sistema tipo 2; o 2> si la lista de identidades de URA en el bloque de información de sistema tipo 2 se encuentra vacía; o 2> si el bloque de información de sistema tipo 2 no puede encontrarse: 3> realizar actualización de URA utilizando la causa "cambio de URA" . 1> actualización de URA periódica: 2> si los criterios para realizar actualización de URA con las causas como se específica en lo anterior en la subcláusula actual no se cumplen: 3> si el cronómetro T305 expira y si la actualización periódica se ha configurado por T305 en el IE "cronómetros de UE y constantes en el modo conectado" establecido en cualquier otro valor diferente a "infinidad"; o 3> si las condiciones para iniciar un procedimiento de actualización URA especificado en la subcláusula 8.1.1.6.5 se cumplen: 4> realizar actualización de URA utilizando la causa "actualización de URA periódica" .

Cuando se inicia el procedimiento de actualización de URA o de actualización de celda, el UE debe: 1> si el UE tiene el PDU de datos de RLC de enlace ascendente o PDU de control de RLC de enlace ascendente en RB3 o más para transmitir; o 1> si el UE recibió un mensaje de TIPO DE BÚSQUEDA 1 que satisface las condiciones para iniciar un procedimiento de actualización de celda especificado en la subcláusula 8.1.2.3: 2> establecer el contador V316 en cero. 1> si el cronómetro T320 funciona: 2> detener el cronómetro T320; 2> si el UE tiene el PDU de datos de RLC de enlace ascendente o PDU de control de RLC de enlace ascendente en RBl o más para transmitir: 3> realizar actualización de celda utilizando la causa "transmisión de datos de enlace ascendente". 2> además: 3> si el procedimiento de actualización de celda no se activa debido a una Respuesta de Búsqueda o falla de enlace de radio; y 3> si el UE debe realizar actualización de celda para solicitud de portadora de radio de MB S ptp como se especifica en la subcláusula 8.6.9.6: 4> realizar actualización de celda utilizando la causa "solicitud de MBMS ptp RB" . 1> detener el cronómetro T319 si funciona; 1> detener el cronómetro T305; 1> para FDD y TDD de 1.28 Mcps : 2> si el UE se encuentra en el estado CELL_FACH; y 2> si el IE "información de sistema común de HS-DSCH" se incluye en el bloque de Información de Sistema tipo 5 o el Bloque de Información de Sistema tipo 5 bis; y 2> para TDD de 1.28 Mcps, si IE "Información de Sistema de E-DCH común" en el Bloque de Información de Sistema tipo 5, y 2> si el UE soporta recepción de HS-DSCH en el estado de CELL_FACH: 3> si la variable H_RNTI no se establece o la variable C_RTI no se establece: 4> borrar la variable H_RNTI; 4> borrar la variable C_RJMTI ; 4> borrar cualquier IE almacenado "información de HARQ" ; 4> establecer variable de HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO; 4> e iniciar la recepción de los canales de transporte HS-DSCH mapeados en canales físicos de tipo HS-SCCH y HS-PDSCH, al utilizar los parámetros proporcionados por los IE "información de sistema común de HS-DSCH" de acuerdo con el procedimiento en la subcláusula 8.5.37. 3> además : 4> recibir los canales de transporte de HS-DSCH mapeados en canales físicos del tipo HS-SCCH y HS-PDSCH, al utilizar los parámetros proporcionados por los IE "información de sistema común de HS-DSCH" de acuerdo con el procedimiento en la subcláusula 8.5.36; 4> determinar el valor para la variable HSPA_ Tl_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 4> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 4> determinar el valor para la variable COMMON_E_DCH_TRANSMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46; 4> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 5> configurar el enlace ascendente mejorado en el estado de CELL_FACH y el modo inactivo como se especifica en la subcláusula 8.5.45 para FDD y 8.5.45a para TDD de 1.28 Mcps . 1> si el UE se encuentra en el estado de CELL_DCH: 2> en la variable RB_TIMER_INDICATOR , establecido en IE "T314 expirado" y el IE "T315 expirado" en FALSO; 2> si los valores almacenados del cronómetro T314 y el cronómetro T315 ambos son iguales en cero; o 2> si el valor almacenado del cronómetro T314 es igual a cero y no existen más portadoras de radio asociadas con alguna portadora de acceso por radio para la cual en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T315" y existe la conexión de señalización sólo en el dominio de CS : 3> liberar todos sus recursos de radio; 3> indicar liberación (abortar) de las conexiones de señalización establecidas (como almacenadas en la variable ESTABLISHED_SIGNALLING_CO ECTIONS) y las portadoras de acceso por radio establecidas (como almacenadas en la variable ESTABLISHED_RABS) en capas superiores; 3> borrar la variable ESTABLISHED_SIGNALLING_CONNECTIONS; 3> borrar la variable ESTABLISHED_RABS ; 3> entrar al modo inactivo; 3> realizar otras acciones cuando se entra al modo inactivo del modo del conectado como se especifica en la subcláusula 8.5.2; 3> y el procedimiento finaliza. 2> si el valor almacenado del cronómetro T314 es igual a cero: 3> liberar todas las portadoras de radio, asociadas con cualquier portadora de acceso por radio para la cual en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T314"; 3> en la variable RB_TIMER_INDICAT0R se establece el IE "T314 expirado" en VERDADERO; 3> si todas las portadoras de acceso por radio asociadas con un dominio de CN se liberan: 4> liberar la conexión de señalización de ese dominio CN; 4> remover la conexión de señalización para ese dominio de CN de la variable ESTABLISHED_SIGNALLING_CONNECTIONS; 4> indicar liberación (abortar) de la conexión de señalización en capas superiores; 2> si el valor almacenado del cronómetro T315 es igual a cero: 3> liberar todas las portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de , restablecimiento" se establece en "utilizar T315" ; 3> en la variable RB_TIMER_INDICAT0R se establece el IE "T315 expirado" en VERDADERO. 3> si todas las portadoras de acceso por radio asociadas con un dominio de CN se liberan: 4> liberar la conexión de señalización de ese dominio CN; 4> remover la conexión de señalización para ese dominio . de CN de la variable ESTABLISHED_SIGNALLING_CONNECTIONS; 4> indicar liberación (abortar) de la conexión de señalización en capas superiores; 2> si el valor almacenado del cronómetro T314 es mayor que cero : 3> si existen portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T314" : 4> iniciar el cronómetro T314. 3> si existen portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T314" o "utilizar T315" y la conexión de señalización que existe en el dominio CS : 4> iniciar el cronómetro T314. 2> si el valor almacenado del cronómetro T315 es mayor que cero : 3> si existen portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T315"; o 3> si la conexión de señalización existe para el dominio PS : 4> iniciar el cronómetro T315. 2> para las portadoras de radio liberadas: 3> borrar la información sobre el portadora de radio de la variable ESTABLISHED_RABS; 3> cuando todas las portadoras de radio pertenecen a la misma portadora de acceso por radio se han liberado: 4> indicar liberación de finalización local de la portadora de acceso por radio en capas superiores utilizando la identidad de dominio de CN junto con la identidad de RAB almacenada en la variable ESTABLISHED_RABS; 4> borrar toda la información sobre la portadora de acceso por radio de la variable ESTABLISHED_RABS . 2> si la variable E_DCH_TRA S ISSION se establece en VERDADERO: 3> establecer la variable E_DCH_TRANSMISSION en FALSO; 3> detener cualquiera de los procedimientos de recepción de E-AGCH y E-HICH; 3> para FDD, detener cualquiera de los procedimientos de recepción de E-RGCH. 3> para FDD, detener cualquier E-DPCCH y E-DPDCH procedimientos de transmisión. 3> para TDD de 1.28 Mcps, detener cualquier procedimiento de transmisión E-Puch. 3> borrar la variable E_RNTI; 3> actuar como si el IE "indicador de restablecimiento de MAC-es/e" se recibiera y establecer en VERDADERO ; 3> liberar todos los recursos de HARQ de E-DCH; 3> ya no considerar ningún enlace de radio a ser el E-DCH sirviendo enlace de radio. 2> mover al estado de CELL_FACH; 2> seleccionar una celda UTRA adecuada en la frecuencia actual de acuerdo con [4]; 2> borrar la variable E_R TI y: 3> determinar el valor para la variable HSPA_R TI_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 3> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 3> determinar el valor para la variable COMMON_E_DCH_TRA SMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46. 2> para TDD de 3.84 y TDD 7.68 Mcps; o 2> para FDD y TDD de 1.28 Mcps, si el UE no soporta la recepción de HS-DSCH en el estado de CELL_FACH; o 2> si el IE "información de sistema común de HS-DSCH" no se incluye en el bloque de Información de Sistema tipo 5 o el Bloque de Información de Sistema tipo 5 bis; o 2> para TDD de 1.28 Mcps, si el IE "Información del sistema de E-DCH común" no se incluye en el bloque de Información de Sistema tipo 5: 3> seleccionar PRACH acuerdo con la subcláusula 8.5.17; 3> seleccionar CCPCH secundario de acuerdo con la subcláusula 8.5.19; 3> utilizar el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1; 3> tomar las medidas relacionadas con la variable HS_DSCH_RECEPTION_GENERAL como se describe en la subcláusula 8.5.37a. 2> además: 3> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 4> configurar el enlace ascendente mejorado en estado CELL_FACH y el modo inactivo como se especifica en la subcláusula 8.5.45. 3> además: 4> seleccionar PRACH de acuerdo con la subcláusula 8.5.17 y: 5> utilizar PRACH para el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1. 3> borrar la variable H_R I ; 3> borrar cualquier IEs almacenado "información de HARQ " ; 3> restablecer la entidad MAC-ehs [15]; 3> establecer la variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO; 3> e iniciar la recepción de HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.37. 2> establecer la variable ORDERED_RECONFIGURA ION en FALSO. 1> establecer las variables PR0TOCOL_ERR0R_INDICAT0R , FAILURE_INDICATOR , U SUPPORTED_CONFIGURATION e INVALID_CONFIGURA ION en FALSO; 1> establecer la variable de CELL_UPDATE_STARTED en VERDADERO ; 1> si cualquiera de los IE relacionados con HS-DSCH se almacenan en el UE: 2> borrar cualquier IE almacenado "información de HS-PDSCH de enlace descendente"; 2> borrar cualquier IE almacenado "FDD de información de celda secundaria de enlace descendente"; 2> borrar todas las entradas de la variable ARGET_CELL_PRECONFIGURATIO ; 2> para TDD de 1.28Mcps, borrar el IE "Configuración de Secuencia de Entrenamiento de HS-PDSCH" y el IE "configuración de conjunto de HS-SCCH" en el IE "Información de Multiportadora de DL"; 2> determinar el valor para la variable HS_DSCH_RECEPTION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.25; 2> determinar el valor para la variable SECONDARY_CELL_HS_DSCH_RECEPTION y tomar las medidas correspondientes, como se describe en la subcláusula 8.5.51 1> si cualquiera de los IE relacionados con E-DCH se almacenan en el EU: 2> borrar cualquier IE almacenado "información de E-DCH" ; 2> determinar el valor para la variable E_DCH_TRANSMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.28. 1> si alguno de los IE "información de tiempo DTX-DRX" o "información de DTX-DRX" se almacenan en el UE: 2> determinar el valor para la variable DTX_DRX_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.34. 1> si el IE "información menos HS-SCCH" se almacena en el UE: 2> determinar el valor para la variable HS_SCCH_LESS_STATUS y tomar las medidas correspondientes como se describe en la subclausula 8.5.35. 1> si cualquiera de los IE relacionados con MIMO se almacenan en el UE : 2> determinar el valor para la variable MIMO_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.33. 1> para TDD de 1.28 Mcps , si los IE "información de DRX de canal de control" se almacena en el UE: 2> determinar el valor para la variable CONTROL_CHANNEL_DRX_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.53. 1> para TDD de 1.28 Mcps, si el IE "información de SPS" se almacena en el UE : 2> determinar el valor para la variable E_DCH_SPS_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.54; 2> determinar el valor para la variable HS_DSCH_SPS_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.55. 1> si el UE ya no se encuentra en el estado de CELL_FACH : 2> mover al estado de CELL_FACH; 2> determinar el valor para la variable HSPA_R TI_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 2> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 2> determinar el valor para la variable C0MMON_E_DCH_TRA SMISSI0N y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46; 2> para el TDD de 3.84 Mcps y TDD 7.68 Mcps; o 2> para FDD y TDD de 1.28 Mcps, si el UE no soporta la recepción de HS-DSCH en el estado de CELL_FACH; o 2> si el IE "información de sistema común de HS-DSCH" no se incluye en el bloque de Información de Sistema tipo 5 o el Bloque de Información de Sistema tipo 5 bis; o 2> para TDD de 1.28 Mcps, si el IE "Información del sistema de E-DCH común" no se incluye en el bloque de Información de Sistema tipo 5: 3> seleccionar PRACH acuerdo con la subcláusula 5.8.17; 3> seleccionar CCPCH secundario de acuerdo con la subcláusula 5.8.19; 3> utilizar el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1; 3> tomar las medidas relacionadas con la variable HS_DSCH_RECEPTION_GENERAL como se describe en la subcláusula 8.5.37a. 2> además: 3> si la variable READY_FOR_COM ON_EDCH se establece en VERDADERO: 4> configurar el enlace ascendente mejorado en estado CELL_FACH y el modo inactivo como se especifica en la subcláusula 8.5.45. 3> además : 4> seleccionar PRACH de acuerdo con la subcláusula 8.5.17 y: 5> utilizar PRACH para el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1. 3> si la variable H_RNTI no se establece o la variable C_R TI no se establece: 4> borrar la variable C_RNTI; 4> borrar la variable H_RNTI; 4> borrar cualquier ÍES almacenado "información de HARQ" ; 4> establecer variable de HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO; 4> e iniciar la recepción de HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.37. 3> además: 4> recibir el HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.36. 1> si el UE realiza la reselección de celda: 2> borrar la variable C_ TI, y 2> dejar de utilizar C_RNTI recién borrado de la variable C_RNTI en MAC; 2> para FDD y TDD de 1.28 Mcps, si la variable H_RNTI se establece: 3> borrar la variable H_RN I ; y 3> dejar de utilizar H_R TI recién borrado de la variable H_RNTI en MAC; 3> borrar cualquier IES almacenado "información de HARQ" ; 2> para FDD y TDD de 1.28 Mcps, si la variable E_RNTI se establece: 3> borrar la variable E_RNTI . 2> determinar el valor para la variable HSPA_R TI_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 2> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 2> determinar el valor para la variable COMMON_E_DCH_TRANSMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46; 2> para FDD y TDD de 1.28 Mcps , si el UE soportar la recepción de HS-DSCH en el estado de CELL_FACH y el IE "información de sistema de común de HS-DSCH" se incluye en el bloque de información de sistema tipo 5 o el bloque de información de sistema tipo 5bis : 3> restablecer la entidad MAC-EHS [15] . 3> establecer la variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO ; 3> e iniciar la recepción del HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.37. 2> además: 3> tomar las medidas relacionadas con la variable HS_DSCH_RECEPTION_GENERAL como se describe en la subcláusula 8.5.37a. 1> establecer CFN con respecto a SFN de la celda actual de acuerdo con la subcláusula 8.5.15; 1> en caso de un procedimiento de actualización de celda: 2> establecer los contenidos del mensaje de ACTUALIZACIÓN CELDA de acuerdo con la subcláusula 8.3.1.3; 2> enviar el mensaje de ACTUALIZACIÓN DE CELDA para la transmisión en el CCCH de enlace ascendente. 1> en caso de un procedimiento de actualización de URA: 2> establecer el contenido del mensaje de ACTUALIZACIÓN de URA de acuerdo con la subcláusula 8.3.1.3; 2> enviar el mensaje de ACTUALIZACIÓN de URA para la transmisión en el CCCH de enlace ascendente. 1> establecer el contador V302 en 1; 1> iniciar el cronómetro T302 cuando la capa de MAC indique éxito o falla en transmitir el mensaje. 10.3.3.43 Cronómetros y constantes de UE en el modo conectado Este elemento de información especifica los valores de cronómetro y constantes utilizados por el UE en el modo conectado . 13.4.27x TRIGGERED_SCRI_IN_PCH_STATE Esta variable contiene información sobre si un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha activado en los estados de CELL_PCH o URA_PCH. Existe tal variable en el UE.

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 conexión de señalización Figura 8.1.14-1 procedimiento de indicación 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 se utiliza por el UE para indicar a la UTRA que una de sus conexiones de señalización se ha liberado. El procedimiento a su vez puede iniciar el procedimiento de liberación de conexión de RRC. 8.1.14.2 Inicio El UE debe, al recibir una solicitud para liberar (abortar) la conexión de señalización de capas superiores para un dominio de CN específico: 1> si una conexión de señalización es la variable ESTABLISHED_SIGNALLING_CONNECTIONS para el dominio de CN específico identificado con el IE "identidad de dominio de CN" existe: 2> iniciar el procedimiento de indicación de liberación de conexión de señalización. 1> de otra manera: 2> abortar cualquier es ablecimiento en proceso de conexión de señalización para el dominio de CN específico como se especifica en 8. 1.3.5a.

Con el inicio del procedimiento de indicación de liberación de conexión de señalización en el estado de CELL_PCH o URA_PCH, el UE debe: 1> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 2> moverse al estado de CELL_FACH; 2> restablecer el cronómetro T305 utilizando su valor inicial si la actualización de celda periódica se ha configurado por T305 en el IE "cronómetros y constantes de UE en el modo conectado" establecida en cualquier otro valor diferente a "infinidad" . 1> además : 2> si la variable H_R TI y la variable CJNTI se establecen: 3> continuar con el procedimiento de indicación de liberación de conexión de señalización como en lo anterior. 2> además : 3> realizar un procedimiento de actualización de celda, de acuerdo con la subcláusula 8.3.1, utilizando la causa "transmisión de datos de enlace ascendente" ; 3> cuando el procedimiento de actualización de celda se completa con éxito: 4> continuar con el procedimiento de indicación de liberación de conexión de señalización como en lo anterior.

El UE debe: 1> establecer el IE "identidad de dominio de CN" en el valor indicado por las capas superiores . El valor de IE indica el dominio de CN cuya conexión de señalización asociada a las capas superiores indican que se liberarán; 1> remover la conexión de señalización con la identidad indicada por las capas superiores a partir de la variable ESTABLISHED_SIGNALLING_CONNECTIONS ; 1> transmitir un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH utilizando AM RLC .

Cuando la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el procedimiento finaliza.

Además, si el valor del cronómetro T323 se almacena en el IE "cronómetros y constantes de UE en el modo conectado" en la variable TIMERS_AND_CONSTANTS , y si no existe ninguna conexión de dominio de CS indicada en la variable ESTABLISHED_SIGNALLING_CONNECTIONS , el UE puede: 1> si las capas superiores indican que no existen más datos de PS durante un período prolongado: 2> si el cronómetro T323 no funciona: 3> si el UE se encuentra en un estado de CELL_DCH o un estado de CELL_FACH; o 3> si el UE se encuentra en el estado CELL_PCH o el estado de URA_PCH y V316 < N316; 4> si el UE se encuentra en el estado de CELL_PCH o URA_PCH incrementar V316 por 1; 4> establecer el IE "identidad de dominio de CN" en el dominio de PS; 4> establecer 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 de PS Solicitada por UE"; 4> transmitir un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN en DCCH utilizando AM RLC ; 4> iniciar el cronómetro T323.

Cuando la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el procedimiento finaliza.

Al UE se le debe prohibir enviar el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN 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 de PS Solicitada por UE", mientras que el cronómetro T323 se encuentra funcionando.

Si los datos de PS se vuelven disponibles para transmisión o el UE recibe un mensaje de búsqueda que activa el procedimiento de actualización de celda, entonces el UE debe establecer V316 en cero. Si el UE envía el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN con el IE "Causa de Indicación de Liberación de Conexión de Señalización" establecido "finalización de Sesión de Datos de PS Solicitada por UE" en el estado de CELL_DCH o CELL_FACH y en respuesta el UE recibe un mensaje de reconfiguración que hace transición del UE al estado de CELL_PCH o estado de URA_PCH, entonces el UE debe establecer V316 en N316. El UE debe considerar el mensaje de reconfiguración para ser en respuesta a mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN si se recibe dentro de 500ms. 8.1.14.2a Restablecimiento de RLC o cambio inter- AT Si un restablecimiento del lado de transmisión de la entidad de RLC en la portadora de radio RB2 de señalización se presenta antes de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el UE debe: 1> transmitir el mensaje de INDICACIÓN DE LIBERACION DE CONEXIÓN DE SEÑALIZACIÓN en el DCCH de enlace ascendente utilizando AM RLC en la portadora de radio RB2 de señalización.

Si una transferencia inter-RAT del procedimiento de UTRAN se presenta antes de la entrega exitosa del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha confirmado por el RLC, el UE debe: 1> abortar la conexión de señalización mientras se encuentra en la nueva RAT. 8.1.14.3 Recepción de la INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN por la UTRAN Con la recepción del mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, si el IE "Causa de Indicación de Liberación de Conexión de Señalización" no se incluye, la UTRA solicita la liberación de la conexión de señalización de las capas superiores. Las capas superiores entonces pueden iniciar la liberación de la conexión de señalización.

Si el IE "Causa de Indicación de Liberación de Conexión de Señalización" se incluye en el mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN, la UTRAN puede iniciar una transición de estado a consumo de batería eficiente en el estado de IDLE, CELL_PCH, URA_PCH o CELL_FACH . 8.1.14.4 Expiración del cronómetro T323 Cuando el cronómetro T323 expira: 1> el UE puede determinar si alguna indicación subsiguiente de las capas superiores de que no existen más datos de PS durante un período prolongado, en cuyo caso activa la transmisión de un solo mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN de acuerdo con la cláusula 8.1.14.2; 1> el procedimiento finaliza. 8.3 Procedimientos de movilidad de conexión de RRC 8.3.1 Procedimientos de actualización de celda y URA Figura 8.3.1-1 procedimiento de actualización 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 celda con reconfigur ció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 celda con liberación de portadora de radio Figura 8.3.1-6 procedimiento de actualización de celda con reconfiguración de portadora de radio Figura 8.3.1-6a procedimiento de actualización de celda con establecimiento de portadora de radio Figura 8.3.1-7 procedimiento de actualización celda, caso de falla Figura 8.3.1-8 procedimiento de actualización URA, flujo básico UE UTRAN ACTUALIZACIÓN DE CELDA ¦ CONFIRMAR ACTUALIZACIÓN DE URA CONFIRMAR INFORMACIÓN DE DE MOVILIDAD DE UTRAN Figura 8.3.1-9 procedimiento de actualización de URA con actualización de información de movilidad de UTRAN UE UTRAN ACTUALIZACIÓN DE URA . LIBERACIÓN DE CONEXIÓN DE RRC Figura 8.3.1-10 procedimiento de actualización de URA, caso de falla 8.3.1.1 General Los procedimientos de actualización de URA y actualización de celda sirven para varios propósitos principales : - para notificar a la UTRAN después de reingresar al área de servicio en el estado de URA_PCH o CELL_PCH; para notificar a la UTRAN de un error irrecuperable de RLC [16] en una entidad de AM RLC; - para utilizarse como un mecanismo de supervisión en el estado de CELL_FACH, CELL_PCH o URA_PCH por medio de una actualización periódica.

Además, el procedimiento de actualización de URA también sirve para el siguiente propósito: - para recuperar una nueva identidad de URA después de la re-selección de celda en una celda que no pertenece a la URA actual asignada al UE en el estado de URA_PCH.

Además, el procedimiento de actualización de celda también sirve para los siguientes propósitos: - para actualizar la UTRA con la celda actual en la que se sitúa el UE después de la re-selección de celda; - para actuar como una falla de enlace de radio en el estado de CELL_DCH; para actuar en la falla de transmisión del mensa e de INFORMACIÓN DE CAPACIDAD DE UE; - para FDD y TDD 1.28 Mcps , si la variable H_RNTI no se establece, y para TDD de 3.84 Mcps y TDD de 7.68 Mcps; cuando se activa en el estado de URA_PCH o CELL_PCH para notificar a la UTRAN de una transición al estado de CELL_FACH debido a la recepción de la UTRAN que originó la búsqueda o debido a una solicitud de tránsmitir datos de enlace ascendente; - para contar el número de UEs en URA_PCH, CELL_PCH CELL_FACH que se interesan en recibir una transmisión de MBMS ; cuando se activa en el estado, de URA_PCH, CELL_PCH y CELL_FACH , para notificar a la UTRAN del interés de UEs para recibir el servicio de MBMS; - para solicitar el establecimiento de MBMS P-T-P RB por el UE en el estado de CELL_PCH, URA_PCH y CELL_FACH.

Los procedimientos de actualización de URA y actualización de celda pueden: 1> incluir una actualización de la información relacionada con la movilidad en el UE; 1> provocar una transición de estado desde del estado de CELL_FACH a los estados de CELL_DCH, CELL_PCH o URA_PCH o modo inactivo.

El procedimiento de actualización de celda también puede incluir: - un re-establecimiento de las entidades de AM RLC; una liberación de portadora de radio, reconfiguración de portadora de radio, reconfiguración de canal de transporte o reconfiguración de canal físico. 8.3.1.2 Inicio Un UE de iniciar el procedimiento de actualización de celda en los siguientes casos : 1> transmisión de datos de enlace ascendente; 2> para FDD y TDD de 1.28 Mcps, si la variable H_RNTI no se establece, y para TDD de 3.84 Mcps y TDD de 7.68 Mcps ; 3> si el UE se encuentra en el estado de URA_PCH o CELL_PCH, y 3> si el cronómetro T320 no funciona; 4> si el UE tiene PDU de datos de RLC de enlace ascendente o PDU de control de RLC de enlace ascendente en RBl o más para transmitir; 5> realizar actualización de celda utilizando la causa "transmisión de datos de enlace ascendente". 3>además : 4> si la variable ESTABLISHMENT_CAUSE se establece: 5> realizar la actualización de celda utilizando la causa "transmisión de datos de enlace ascendente". 1> respuesta de búsqueda: 2> si el criterio para realizar actualización de celda con la causa especificada en lo anterior en la subcláusula actual no se cumplen; y 2> si el UE en el estado de URA_PCH o CELL_PCH( recibe un mensaje de TIPO DE BÚSQUEDA 1 que cumple con las condiciones para iniciar un procedimiento de actualización de celda especificado en la subcláusula 8.1.2.3: 3> realizar la actualización de celda utilizando la causa "respuesta de búsqueda" . 1> falla en el enlace de radio: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen: 3> si el UE se encuentra en el estado de CELL_DCH y los criterios para la falla de enlace de radio se cumplen como se especifica en la subcláusula 8.5.6; o 3> si la transmisión del mensaje de INFORMACION DE CAPACIDAD DE UE falla como se especifica en la subcláusula 8.1.6.6: 4> realizar la actualización de celda utilizando la causa "falla de enlace de radio". 1> solicitud de MB MS ptp RB: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE se encuentra en el estado de URA_PCH, Cell_PCH o Cell_FACH; y 2> si el cronómetro T320 no funciona; y 2> si el UE debe realizar la actualización de celda para solicitud de portadora de radio MBMS ptp como se especifica en la subcláusula 8.6.9.6: 3> realizar la actualización de celda utilizando la causa "Solicitud MBMS ptp RB" . 1> Reingresar al área de servicio: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE se encuentra en el estado de CELL-FACH o CELL_PCH; y 2> si el UE se ha establecido fuera del área de servicio y reingresa al área de servicio antes de que expire T307 o T317: 3> realizar la actualización de celda utilizando la causa "regresar al área de servicio". 1> error irrecuperable de RLC: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE detecta un error irrecuperable de RLC [16] en una entidad de A RLC; 3> realizar la actualización de celda utilizando la causa "error irrecuperable de RLC". 1> Reselección de celda: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; 3> si el UE se encuentra en el estado de CELL_FACH o CELL_PCH y el UE realiza la re-selección de celdas; o 3> si el UE se encuentra en el estado de CELL_FACH y la variable C_R TI se encuentra vacía: 4> realizar la actualización de celda utilizando la causa "re-selección de celda". 1> Actualización de celda periódica: 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen y 2> si el UE se encuentra en el estado de CELL-FACH o CELL_PCH; y 2> si el cronómetro T305 expira; y 2> si los criterios para "área en servicio" como se especifica en la subcláusula 8.5.5.2 se cumplen; y 2> si la actualización periódica se ha configurado por T305 en el IE "cronómetros y constantes de UE en el modo conectado" se establecen en cualquier valor diferente a "infinidad" : 3> para FDD: 4> si la variable COMMON_E_DCH_TRA SMISSION se establece en 'FALSO: 5> realizar la actualización de celda utilizando la causa "actualización de celda periódica". 4>además : 5> reiniciar el cronómetro T305; 5> y finalizar el procedimiento. 3> para TDD de 1.28 Mcps y TDD de 3.84/7.68 Mcps; 4> realizar la actualización de celda utilizando la causa "actualización de celda periódica". 1> recepción de MBMS : 2> si ninguno de los criterios para realizar actualización de celda con las causas especificadas en lo anterior en la subcláusula actual se cumplen; y 2> si el UE se encuentra en el estado de URA_PCH, Cell_PCH o Cell_FACH; y 2> si el UE debe realizar la actualización de celda para conteo de MBMS como se especifica en la subcláusula 8.7.4: 3> realizar actualización de celda utilizando la causa "recepción de MBMS".

Un UE en el estado de URA_PCH iniciará el procedimiento de actualización de URA en los siguientes casos : 1> reselección de URA: 2> si el UE detecta que el URA actual asignado al UE, almacenado en la variable URA_IDENTITY, no se encuentra en la lista de identidades de URA en el bloque de información de sistema tipo 2; o 2> si la lista de identidades de URA en el bloque de información de sistema tipo 2 se encuentra vacía; o 2> si el bloque de información de sistema tipo 2 no puede encontrarse: 3> realizar actualización de URA utilizando la causa "cambio de URA". 1> Actualización de URA periódica: 2> si los criterios para realizar actualización de URA con las causas como se especifica en lo anterior en la subcláusula actual no se cumplen: 3> si el cronómetro T305 expira y si la actualización periódica se ha configurado por T305 en el IE "cronómetros de UE y constantes en el modo conectado" establecido en cualquier otro valor diferente a "infinidad"; o 3> si las condiciones para iniciar un procedimiento de actualización URA especificado en la subcláusula 8.1.1.6.5 se cumplen: 4> realizar actualización de URA utilizando la causa "actualización de URA periódica" .

Cuando se inicia el procedimiento de actualización de URA o de actualización de celda, el UE debe: 1> si el UE tiene el PDU de datos de RLC de enlace ascendente o PDU de control de RLC de enlace ascendente en RB3 o más para transmitir; o 1> si el UE recibió un mensaje de TIPO DE BÚSQUEDA 1 que satisface las condiciones para iniciar un procedimiento de actualización de celda especificado en la subcláusula 8.1.2.3: 2> establecer el contador V316 en cero. 1> si el cronómetro T320 funciona: 2> detener el cronómetro T320; 2> si el UE tiene el PDU de datos de RLC de enlace ascendente o PDU de control de RLC de enlace ascendente en RBl o más para transmitir: 3> realizar actualización de celda utilizando la causa "transmisión de datos de enlace ascendente". 2> además : 3> si el procedimiento de actualización de celda no se activa debido a una Respuesta de Búsqueda o falla de enlace de radio; y 3> si el UE debe realizar actualización de celda para solicitud de portadora de radio de MBMS ptp como se especifica en la subcláusula 8.6.9.6: 4> realizar actualización de celda utilizando la causa "solicitud de MBMS ptp RB" . 1> detener el cronómetro T319 si funciona; 1> detener el cronómetro T305; 1> para FDD y TDD de 1.28 Mcps : 2> si el UE se encuentra en el estado CELL_FACH; y 2> si el IE "información de sistema común de HS-DSCH" se incluye en el bloque de Información de Sistema tipo 5 o el Bloque de Información de Sistema tipo 5 bis; y 2> para TDD de 1.28 Mcps, si IE "Información de Sistema de E-DCH común" en el Bloque de Información de Sistema tipo 5, y 2> si el UE soporta recepción de HS-DSCH en el-estado de CELL_FACH: 3> si la variable H_R TI no se establece o la variable C_RNTI no se establece: 4> borrar la variable H_RNTI; 4> borrar la variable C_RNTI; 4> borrar cualquier IE almacenado "información de HARQ" ; 4> establecer variable de HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO; 4> e iniciar la recepción de los canales de transporte HS-DSCH mapeados en canales físicos de tipo HS-SCCH y HS-PDSCH, al utilizar los parámetros proporcionados por los IE "información de sistema común de HS-DSCH" de acuerdo con el procedimiento en la subclausula 8.5.37. 3> además: 4> recibir los canales de transporte de HS-DSCH mapeados en canales físicos del tipo HS-SCCH y HS-PDSCH, al utilizar los parámetros proporcionados por los IE "información de sistema común de HS-DSCH" de acuerdo con el procedimiento en la subcláusula 8.5.36; 4> determinar el valor para la variable HSPA_R TI_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 4> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 4> determinar el valor para la variable COMMON_E_DCH_TRANSMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46; 4> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 5> configurar el enlace ascendente mejorado en el estado de CELL_FACH y el modo inactivo como se especifica en la subcláusula 8.5.45 para FDD y 8.5.45a para TDD de 1.28 Mcps . 1> si el UE se encuentra en el estado de CELL_DCH : 2> en la variable RB_TIMER_INDICATOR, establecido en IE "T314 expirado" y el IE "T315 expirado" en FALSO; 2> si los valores almacenados del cronómetro T314 y el cronómetro T315 ambos son iguales en cero; o 2> si el valor almacenado del cronómetro T314 es igual a cero y no existen más portadoras de radio asociadas con alguna portadora de acceso por radio para la cual en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T315" y existe la conexión de señalización sólo en el dominio de CS: 3> liberar todos sus recursos de radio; 3> indicar liberación (abortar) de las conexiones de señalización establecidas (como almacenadas en la variable ESTABLISHED_SIGNALLING_CO ECTIONS) y las portadoras de acceso por radio establecidas (como almacenadas en la variable ESTABLISHED_RABS ) en capas superiores; 3> borrar la variable ESTABLISHED_SIGNALLING_CON ECTIONS ; 3> borrar la variable ESTABLISHED_RABS ; 3> entrar al modo inactivo; 3> realizar otras acciones cuando se entra al modo inactivo del modo del conectado como se especifica en la subcláusula 8.5.2; 3> y el procedimiento finaliza. 2> si el valor almacenado del cronómetro T314 es igual a cero: 3> liberar todas las portadoras de radio, asociadas con cualquier portadora de acceso por radio para la cual en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T314"; 3> en la variable RB_Tl ER_INDICATOR se establece el IE "T31 expirado" en VERDADERO; 3> si todas las portadoras de acceso por radio asociadas con un dominio de CN se liberan: 4> liberar la conexión de señalización de ese dominio CN; 4> remover la conexión de señalización para ese dominio de CN de la variable ESTABLISHED_SIGNALLING_CONNECTIONS ; 4> indicar liberación (abortar) de la conexión de señalización en capas superiores; 2> si el valor almacenado del cronómetro T315 es igual a cero: 3> liberar todas las portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T315" ; 3> en la variable RB_TIMER_INDICATOR se establece el IE "T315 expirado" en VERDADERO. 3> si todas las portadoras de acceso por radio asociadas con un dominio de CN se liberan: 4> liberar la conexión de señalización de ese dominio CN; 4> remover la conexión de señalización para ese dominio de CN de la variable ESTABLISHED_SIGNALLING_CONNECTIONS ; 4> indicar liberación (abortar) de la conexión de señalización en capas superiores; 2> si el valor almacenado del cronómetro T314 es mayor que cero : 3> si existen portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T314" : 4> iniciar el cronómetro T314. 3> si existen portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T314" o "utilizar T315" y la conexión de señalización que existe en el dominio CS : 4> iniciar el cronómetro T314. 2> si el valor almacenado del cronómetro T315 es mayor que cero : 3> si existen portadoras de radio asociadas con cualquiera de las portadoras de acceso por radio para las cuales en la variable ESTABLISHED_RABS el valor del IE "Cronómetro de restablecimiento" se establece en "utilizar T315"; o 3> si la conexión de señalización existe para el dominio PS : 4> iniciar el cronómetro T315. 2> para las portadoras de radio liberadas: 3> borrar la información sobre el portadora de radio de la variable ESTABLISHED_RABS ; 3> cuando todas las portadoras de radio pertenecen a la misma portadora de acceso por radio se han liberado: 4> indicar liberación de finalización local de la portadora de acceso por radio en capas superiores utilizando la identidad de dominio de CN junto con la identidad de RAB almacenada en la variable ESTABLISHED_RABS ; 4> borrar toda la información sobre la portadora de acceso por radio de la variable ESTABLISHED_RABS . 2> si la variable E_DCH_TRA SMISSION se establece en VERDADERO: 3> establecer la variable E_DCH_TRANSMISSION en FALSO; 3> detener cualquiera de los procedimientos de recepción de E-AGCH y E-HICH; 3> para FDD, detener cualquiera de los procedimientos de recepción de E-RGCH. 3> para FDD, detener cualquier E-DPCCH y E-DPDCH procedimientos de transmisión. 3> para TDD de 1.28 Mcps, detener cualquier procedimiento de transmisión E-PUCH. 3> borrar la variable E_RNTI; 3> actuar como si el IE "indicador de restablecimiento de MAC-es/e" se recibiera y establecer en VERDADERO; 3> liberar todos los recursos de HARQ de E-DCH; 3> ya no considerar ningún enlace de radio a ser el E-DCH sirviendo enlace de radio. 2> mover al estado de CELL_FACH; 2> seleccionar una celda UTRA adecuada en la frecuencia actual de acuerdo con [4]; 2> borrar la variable E_RNTI y: 3> determinar el valor para la variable HSPA_RNTI_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 3> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 3> determinar el valor para la variable COMMON_E_DCH_TRANSMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46. 2> para TDD de 3.84 y TDD 7.68 Mcps; o 2> para FDD y TDD de 1.28 Mc s, si el UE no soporta la recepción de HS-DSCH en el estado de CELL_FACH; o 2> si el IE "información de sistema común de HS-DSCH" no se incluye en el bloque de Información de Sistema tipo 5 o el Bloque de Información de Sistema tipo 5 bis; o 2> para TDD de 1.28 Mcps, si el IE "Información del sistema de E-DCH común" no se incluye en el bloque de Información de Sistema tipo 5: 3> seleccionar PRACH acuerdo con la subcláusula 8.5.17; 3> seleccionar CCPCH secundario de acuerdo con la subcláusula 8.5.19; 3> utilizar el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1; 3> tomar las medidas relacionadas con la variable HS_DSCH_RECEPTlON_GENERAL como se describe en la subcláusula 8.5.37a. 2> además: 3> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 4> configurar el enlace ascendente mejorado en estado CELL_FACH y el modo inactivo como se especifica en la subcláusula 8.5.45. 3> además: 4> seleccionar PRACH de acuerdo con la subcláusula 8.5.17 y: 5> utilizar PRACH para el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1. 3> borrar la variable H_RUTI; 3> borrar cualquier IE almacenado "información de HARQ" ; 3> restablecer la entidad MAC-EHS [15]; 3> establecer la variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO; 3> e iniciar la recepción de HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.37. 2> establecer la variable ORDERED_RECONFIGURATION en FALSO. 1> establecer las variables PR0TOCOL_ERR0R_INDICATOR, FAILURE_INDICATOR, U SUPPORTED_CONFIGURATI0N e I VALID_CONFIGURA ION en FALSO; 1> establecer la variable de CELL_UPDATE_STARTED en VERDADERO; 1> si cualquiera de los IE relacionados con HS-DSCH se almacenan en el UE: 2> borrar cualquier IE almacenado "información de HS-PDSCH de enlace descendente"; 2> borrar cualquier IE almacenado "FDD de información de celda secundaria de enlace descendente"; 2> borrar todas las entradas de la variable TARGET_CELL_PRECONFIGURATIO ; 2> para TDD de 1.28Mcps, borrar el IE "Configuración de Secuencia de Entrenamiento de HS-PDSCH" y el IE "configuración de conjunto de HS-SCCH" en el IE "Información de Multiportadora de DL" ; 2> determinar el valor para la variable HS_DSCH_RECEPTION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.25; 2> determinar el valor para la variable SECONDARY_CELL_HS_DSCH_RECEPTION y tomar las medidas correspondientes, como se describe en la subcláusula 8.5.51 1> si cualquiera de los IE relacionados con E-DCH se almacenan en el EU: 2> borrar cualquier IE almacenado "información de E-DCH" ; 2> determinar el valor para la variable E_DCH_TRANSMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.28. 1> si alguno de los IE "información de tiempo DTX-DRX" o "información de DTX-DRX" se almacenan en el UE: 2> determinar el valor para la variable DTX_DRX_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.34. 1> si el IE "información menos HS-SCCH" se almacena en el UE: 2> determinar el valor para la variable HS_SCCH_LESS_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.35. 1> si cualquiera de los IE relacionados con MIMO se almacenan en el UE: 2> determinar el valor para la variable MIMO_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.33. 1> para TDD de 1.28 Mcps , si los IE "información de DRX de canal de control" se almacena en el UE : 2> determinar el valor para la variable CONTROL_CHA NEL_DRX_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.53. 1> para TDD de 1.28 Mcps, si el IE "información de SPS" se almacena en el UE: 2> determinar el valor para la variable E_DCH_SPS_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.54; 2> determinar el valor para la variable HS_DSCH_SPS_STATUS y tomar las medidas correspondientes como se describe en la subcláusula 8.5.55. 1> si el UE ya no se encuentra en el estado de CELL_FACH : 2> mover al estado de CELL_FACH; 2> determinar el valor para la variable HSPA_RNTI_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 2> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 2> determinar el valor para la variable COMMON_E_DCH_TRANS ISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46; 2> para el TDD de 3.84 Mcps y TDD 7.68 Mcps; o 2> para FDD y TDD de 1.28 Mcps, si el UE no soporta la recepción de HS-DSCH en el estado de CELL_FACH; o 2> si el IE "información de sistema común de HS-DSCH" no se incluye en el bloque de Información de Sistema tipo 5 o el Bloque de Información de Sistema tipo 5 bis; o 2> para TDD de 1.28 Mcps, si el IE "Información del sistema de E-DCH común" no se incluye en el bloque de Información de Sistema tipo 5: 3> seleccionar PRACH acuerdo con la subcláusula 8. 5.17; 3> seleccionar CCPCH secundario de acuerdo con la subcláusula 8.5.19; 3> utilizar el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1; 3> tomar las medidas relacionadas con la variable HS_DSCH_RECEPTION_GENERAL como se describe en la subcláusula 8.5.37a. 2> además : 3> si la variable READY_FOR_COMMON_EDCH se establece en VERDADERO: 4> configurar el enlace ascendente mejorado en estado CELL_FACH y el modo inactivo como se especifica en la subcláusula 8.5.45. 3> además : 4> seleccionar PRACH de acuerdo con la subcláusula 8.5.17 y: 5> utilizar PRACH para el conjunto de formato de transporte determinado en la información del sistema como se especifica en la subcláusula 8.6.5.1. 3> si la variable H_RNTI no se establece o la variable C_RNTI no se establece: 4> borrar la variable C_R TI ; 4> borrar la variable H_R TI; 4> borrar cualquier IE almacenado "información de HARQ" ; 4> establecer variable de HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO; 4> e iniciar la recepción de HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.37. 3> además: 4> recibir el HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.36. 1> si el UE realiza la reselección de celda: 2> borrar la variable C_R I , y 2> dejar de utilizar C_RNTI recién borrado de la variable C_RNTI en MAC; 2> para FDD y TDD de 1.28 Mcps, si la variable H_R TI se establece: 3> borrar la variable H_R TI; y 3> dejar de utilizar H_R TI recién borrado de la variable H_RNTI en MAC; 3> borrar cualquier IE almacenado "información de HARQ" ; 2> para FDD y TDD de 1.28 Mcps, si la variable E_R TI se establece: 3> borrar la variable E_RNTI . 2> determinar el valor para la variable HSPA_ TI_STORED_CELL_PCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.56; 2> determinar el valor para la variable READY_FOR_COMMON_EDCH y tomar las medidas correspondientes como se describe en la subcláusula 8.5.47; 2> determinar el valor para la variable COMMON_E_DCH_TRANSMISSION y tomar las medidas correspondientes como se describe en la subcláusula 8.5.46; 2> para FDD y TDD de 1.28 Mcps, si el UE soporta la recepción de HS-DSCH en el estado de CELL_FACH y el IE "información de sistema de común de HS-DSCH" se incluye en el bloque de información de sistema tipo 5 o el bloque de información de sistema tipo 5bis : 3> restablecer la entidad MAC-ehs [15]. 3> establecer la variable HS_DSCH_RECEPTION_OF_CCCH_ENABLED en VERDADERO; 3> e iniciar la recepción del HS-DSCH de acuerdo con el procedimiento en la subcláusula 8.5.37. 2> además: 3> tomar las medidas relacionadas con la variable HS_DSCH_RECEPTION_GENERAL como se describe en la subcláusula 8.5.37a. 1> establecer CFN con respecto a SFN de la celda actual de acuerdo con la subcláusula 8.5.15; 1> en caso de un procedimiento de actualización de celda : 2> establecer los contenidos del mensaje de ACTUALIZACIÓN CELDA de acuerdo con la subcláusula 8.3.1.3; 2> enviar el mensaje de ACTUALIZACIÓN DE CELDA para la transmisión en el CCCH de enlace ascendente. 1> en caso de un procedimiento de actualización de URA: 2> establecer el contenido del mensaje de ACTUALIZACIÓN de URA de acuerdo con la subcláusula 8.3.1.3; 2> enviar el mensaje de ACTUALIZACIÓN de URA para la transmisión en el CCCH de enlace ascendente. 1> establecer el contador V302 en 1; 1> iniciar el cronómetro T302 cuando la capa de MAC indique éxito o falla en transmitir el mensaje. 10.3.3.43 Cronómetros y constantes de UE en el modo conectado Este elemento de información especifica los valores de cronómetro y constantes utilizados por el UE en el modo conectado . 13.4.27x TRIGGERED_SCRI_IN_PCH_STATE Esta variable contiene información sobre si un mensaje de INDICACIÓN DE LIBERACIÓN DE CONEXIÓN DE SEÑALIZACIÓN se ha activado en los estados de CELL_PCH o URA_PCH. Existe tal variable en el UE.

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 portadora de Radio, flujo normal.

El mensaje se describe aquí, con la adición propuesta en cursivas y negritas: 10.2.27 RECONFIGURACIÓN DE PORTADORA DE RADIO Este mensaje se envía desde la UTRAN para reconfigurar parámetros relacionados con un cambio de QoS o para liberar y configurar una portadora de radio utilizada para transmisión PTP de servicios de MBMS del tipo de difusión. Este procedimiento también puede cambiar la multiplexión de la MAC, reconfigurar canales de transporte y canales físicos. Este mensaje también se utiliza para realizar una transferencia desde el modo lu de GERAN a UTRAN.

RLC-SAP: AM o UM o se envía a través del modo lu GERAN Canal lógico: DCCH o enviado a través del modo lu GERAN Dirección: UTRAN ? UE 0

Claims (28)

REIVINDICACIONES

1. Un método realizado por un equipo de usuario (UE) , el método caracterizado porque comprende: en el UE, mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; recibir datos conmutados por paquetes (PS) por el UE; restablecer el conteo por el UE en respuesta a recibir los datos de PS.

2. El método de conformidad con la reivindicación 1, caracterizado porque los mensajes de indicación comprenden mensajes de indicación de liberación de conexión de señalización .

3. El método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque los mensajes de indicación en el conteo cada uno tiene una causa establecida en "Finalización de sesión de Datos de PS Solicitada por UE".

. El método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque la causa se establece en "finalización de sesión de Datos de PS Solicitada por UE".

5. El método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque por lo menos un estado de RRC comprende un estado de CELL_PCH o un estado de URA_PCH.

6. El método de conformidad con cualquiera de las reivindicaciones precedentes caracterizado porque: mantener un conteo comprende utilizar un contador.

7. Un equipo de usuario (UE) caracterizado porque se configura para: mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; recibir datos conmutados por paquetes (PS) ; restablecer el conteo en respuesta a recibir los datos de PS .

8. El equipo de usuarios de conformidad con la reivindicación 7, caracterizado porque los mensajes de indicación comprenden mensajes de indicación de liberación de conexión de señalización.

9. El equipo de usuario (UE) de conformidad con cualquiera de las reivindicaciones 7 y 8, caracterizado porque los mensajes de indicación en el conteo cada uno tiene una causa establecida en "finalización de sesión de Datos de PS Solicitada por UE" .

10. El equipo de usuarios de conformidad con cualquiera de las reivindicaciones 7 a 9, caracterizado porque la causa se establece en "finalización de sesión de Datos de PS Solicitada por UE" .

11. El equipo de usuario de conformidad con cualquiera de las reivindicaciones 7 a 10, caracterizado porque por lo menos un estado de RRC comprende un estado de CELL_PCH o un estado de URA_PCH.

12. El equipo de usuario de conformidad con cualquiera de las reivindicaciones 7 a 11, caracterizado además porque comprende un contador para mantener el conteo.

13. Un método realizado por un equipo de usuario (UE) , el método caracterizado porque comprende: en el UE, mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra por lo menos en un estado de control de recursos de radio (RRC) ; transmitir datos conmutados por paquetes (PS) ; restablecer el conteo por el UE en respuesta a transmitir los datos de PS .

14. El método de conformidad con la reivindicación 13, caracterizado porque el equipo de usuario transmite datos de PS en la portadora de radio 5 (RB5) o superior.

15. El método de conformidad con cualquiera de las reivindicaciones 13 y 14, caracterizado porque la transmisión de datos de PS comprende unidades de datos de protocolo (PDU) de datos de control de enlace de radio (RLC) de enlace ascendente .

16. El método de conformidad con cualquiera de las reivindicaciones 13 a 15, caracterizado porque los mensajes de indicación comprenden mensajes de indicación de liberación de conexión de señalización.

17. El método de conformidad con cualquiera de las reivindicaciones 13 a 16, caracterizado porque los mensajes de indicación en el conteo cada uno tienen una causa establecida en "finalización de sesión de Datos de PS Solicitada por UE" .

18. El método de conformidad con cualquiera de las reivindicaciones 13 a 17, caracterizado porque la causa se establece en "finalización de sesión de Datos de PS Solicitada por UE" .

19. El método de conformidad con cualquiera de las reivindicaciones 13 a 18, caracterizado porque por lo menos un estado de RRC comprende un estado de CELL_PCH o un estado de URA_PCH.

20. El método de conformidad con cualquiera de las reivindicaciones 13 a 19, caracterizado porque mantener un conteo comprende utilizar un contador.

21. Un equipo de usuario (UE) caracterizado porque se configura para: mantener un conteo de cuántos mensajes de indicación con una causa establecida se han enviado por el UE mientras se encuentra en al menos un estado de control de recursos de radio (RRC) ; transmitir datos conmutados por paquetes (PS) ; restablecer el conteo por el UE en respuesta a la transmisión de datos de PS .

22. El equipo de usuario de conformidad con la reivindicación 21, caracterizado además porque se configura para transmitir datos de PS en la portadora de radio 5 (RB5) o superior.

23. El equipo de usuario de conformidad con cualquiera de las reivindicaciones 21 y 22, caracterizado porque la transmisión de datos de PS comprende unidades de datos de protocolo (PDU) de datos de control de enlace de radio (RLC) de enlace ascendente.

24. El equipo de usuario de conformidad con cualquiera de las reivindicaciones 21 a 23, caracterizado porque los mensajes de indicación comprenden mensajes de indicación de liberación de conexión de señalización.

25. El equipo de usuario (UE) de conformidad con cualquiera de las reivindicaciones 21 a 24, caracterizado porque los mensajes de indicación en el conteo cada uno tiene una causa establecida en "finalización de sesión de Datos de PS Solicitada por UE" .

26. El equipo de usuario de conformidad con cualquiera de las reivindicaciones 21 a 25, caracterizado porque la causa se establece en "finalización de sesión de Datos de PS Solicitada por UE" .

27. El equipo de usuario de conformidad con cualquiera de las reivindicaciones 21 a 26, caracterizado porque por lo menos un estado de RRC comprende un estado de CELL_PCH o un estado de. URA_PCH.

28. El equipo de usuario de conformidad con cualquiera de las reivindicaciones 21 a 27, caracterizado además porque comprende un contador para mantener el conteo.