ES2695176T3

ES2695176T3 - Ciclos de recepción discontinua (DRX) de búsqueda extendidos en redes de comunicación inalámbrica

Info

Publication number: ES2695176T3
Application number: ES13880622T
Authority: ES
Inventors: Hyung-Nam Choi; Sangeetha Bangolae; Tarradell Marta Martinez; Puneet Jain; Ana Pineheiro; Maruti Gupta; Ali Koc; Rath Vannithamby; Satish Jha
Original assignee: Intel IP Corp
Current assignee: Intel IP Corp
Priority date: 2013-03-29
Filing date: 2013-12-20
Publication date: 2019-01-02
Anticipated expiration: 2033-12-20
Also published as: EP2979504A4; US9794876B2; EP2979504A1; CN106060912B; HK1217589A1; US20180098280A1; EP2979504B1; CN105103634B; US20160057701A1; TW201505470A; TW201731331A; HUE041916T2; WO2014158268A1; TWI640212B; TWI528851B; US10470122B2; CN106060912A; TW201640944A; TWI590695B; CN105103634A

Abstract

Un terminal de usuario (111, 112) que comprende: una circuitería (520) de procesamiento configurada para determinar que se utilice un valor de DRX de búsqueda (paging) extendida para aumentar la longitud del ciclo de búsqueda a un valor mayor que un primer valor, cuando el terminal de usuario (111, 112) se encuentra operando en una red (100) de acuerdo con un estándar de la familia de estándares del 3GPP para la LTE, y un segundo valor, cuando el terminal de usuario (111, 112) se encuentra operando en una red (100) de acuerdo con un estándar de la familia de estándares UMTS; y una circuitería (540) de capa física configurada para: transmitirle a la red (100) un mensaje del estrato de no acceso indicando que el terminal de usuario (111, 112) desea utilizar el valor de DRX de búsqueda extendida; y recibir un mensaje de la red (100) que incluye un elemento de información que indica si la red (100) soporta el valor de DRX de búsqueda extendida; caracterizada por que la circuitería (540) de capa física está configurada para recibir un bloque de información del sistema desde un NodoB evolucionado (102) que indica si el NodoB evolucionado soporta DRX extendida en modo inactivo, siendo el bloque de información del sistema, SIB, un SIB2 para los sistemas LTE del 3GPP, un SIB1 para los sistemas UMTS del 3GPP, o un SIB de nueva definición.

Description

DESCRIPCION

Ciclos de recepcion discontinua (DRX) de busqueda extendidos en redes de comunicacion inalambrica

Campo tecnico

Los modos de realizacion pertenecen a las comunicaciones inalambricas. Algunos modos de realizacion estan relacionados con la recepcion discontinua (DRX) en redes inalambricas, incluyendo aquellas redes que operan de acuerdo con un estandar de red de la Red de Acceso Radio Terrestre Universal Evolucionada (E-U^trAⁿ) de la Evolucion a Largo Plazo Avanzada (LTE-A) del 3GPP o un estandar de red de la Red de Acceso Radio Terrestre Universal (UTRAN) del Sistema Universal de Telecomunicaciones Moviles (UMTS) del 3GPP.

El Tdoc. TD S2-124264 del 3GPP, "Extending idle mode DRX cycle by using NAS procedures (Extension del ciclo de DRX en modo inactivo mediante procedimientos del NAS)", Reunion # 94 del WG2 del TSG SA del 3GPP, noviembre de 2012, propone utilizar un procedimiento del estrato de no acceso (NAS) para configurar el ciclo de DRX extendido para los UE en modo inactivo e incluye las modificaciones propuestas para el TR 23.887 del 3GPP. Los nodos RAN dentro de un area servida por el nodo de la red troncal informan al nodo de la red troncal sobre su capacidad para soportar ciclos de DRX extendida para los UE en modo inactivo. El TR 23.887 del 3GPP, "Communications Enhancements (Release 12) (Mejoras en las comunicaciones (version 12))", version 0.6.0, diciembre de 2012, es una version posterior del TR 23.887 del 3GPP que adopta esencialmente las propuestas realizadas en el Tdoc. TD S2-124264 del 3GPP y tiene en cuenta explfcitamente que se podna informar a la MME sobre la capacidad para soportar DRX extendida por parte de los nodos RAN mediante senalizacion S1/Iu, un metodo de OA&M o configuracion manual.

Resumen

La invencion se define por la materia objeto de las reivindicaciones independientes. Los modos de realizacion ventajosos de la invencion estan sujetos a las reivindicaciones dependientes y se describen a continuacion con mas detalle en la presente solicitud.

Antecedentes

El ahorro de energfa es importante para los dispositivos de comunicacion inalambrica. En algunas redes convencionales de comunicacion inalambrica, para ahorrar energfa los dispositivos pueden pasar a un modo de recepcion discontinua (DRX) cuando no se estan comunicando con otros dispositivos o con otras entidades de la red. Algunos de los metodos actuales de ahorro de energfa en el modo de DRX pueden ser ineficientes, particularmente en el caso de dispositivos que realizan una comunicacion de tipo maquina (MTC) o que incluyen aplicaciones que transmiten de manera automatizada.

Breve descripcion de los dibujos

La FIG. 1 ilustra una red de comunicacion inalambrica de acuerdo con algunos modos de realizacion que se describen en la presente solicitud.

La FIG. 2 ilustra un ejemplo de comunicacion entre elementos y dispositivos en una red de acuerdo con algunos modos de realizacion que se describen en la presente solicitud.

La FIG. 3 ilustra un ejemplo de comunicacion para la transicion del modo inactivo al modo conectado para el procedimiento de Actualizacion del Area de Seguimiento (TAU) de acuerdo con algunos modos de realizacion que se describen en la presente solicitud.

La FIG. 4 ilustra un ejemplo de senalizacion de factores de escala de busqueda (paging) de acuerdo con al menos algunos modos de realizacion.

La FIG. 5 ilustra un diagrama de bloques de ejemplo de un terminal de usuario (UE), de acuerdo con algunos modos de realizacion que se describen en la presente solicitud.

La FIG. 6 es un diagrama de bloques que ilustra los detalles de un eNodoB de acuerdo con algunos modos de realizacion que se describen en la presente solicitud.

Descripcion detallada

La siguiente descripcion, junto con los dibujos, ilustra suficientemente modos de realizacion espedficos con el fin de permitir que aquellos experimentados en la tecnica los puedan poner en practica. Otros modos de realizacion pueden incorporar cambios estructurales, logicos, electricos, de proceso y otros.

La FIG. 1 ilustra una red 100 de comunicacion inalambrica, de acuerdo con algunos modos de realizacion que se describen en la presente solicitud. La red 100 de comunicacion inalambrica puede incluir una entidad 101 de gestion de moviles (MME), una estacion base como, por ejemplo, un Nodo-B evolucionado (eNodoB) 102, y unos equipos de usuario (UE) 111 y 112. El eNodoB 102 y los UE 111 y 112 pueden operar para comunicarse de forma inalambrica entre sf en la red 100 de comunicacion inalambrica. Aunque algunos modos de realizacion de la presente solicitud se describen en relacion con un eNodoB 102 y una ^mM^e101 que operan de acuerdo con los estandares del Proyecto de Asociacion de Tercera Generacion (3GPP) para la Evolucion a Largo Plazo (LTE), pueden ser aplicables otros modos de realizacion a los estandares del 3GPP para el Sistema Universal de Telecomunicaciones Moviles (UMTS) como, por ejemplo, un NodoB, un controlador de red radio (RNC) o un nodo de soporte del servicio general de paquetes de radio (GPRS) (SGSN) de servicio. En la presente solicitud se describen varios modos de realizacion en relacion con los estandares LTE del 3GPP, y en caso de que haya diferencias respecto a los estandares UMTS del 3GPP, estas se indicaran donde proceda.

Un ejemplo de red 100 de comunicacion inalambrica incluye una red de acceso de radio terrestre universal evolucionada (EUTRAN) que utiliza estandares LTE del 3GPP que operan en modo duplex por division de tiempo (TDD). Otro ejemplo de red 100 de comunicacion inalambrica incluye una EUTRAN que utiliza estandares LTE del 3GPP que operan en modo duplex por division de frecuencia (FDD). Otros ejemplos adicionales de red 100 de comunicacion inalambrica incluyen una UTRAN que utiliza estandares UMTS del 3GPP operando en TDD, FDD o en un modo dual de operacion. Algunos ejemplos adicionales de red 100 de comunicacion inalambrica no amparados por las reivindicaciones, pero utiles para comprender la invencion, incluyen redes de Interoperabilidad Mundial para Acceso por Microondas (WiMax), redes de tercera generacion (3G), redes Wi-Fi y otras redes de comunicacion inalambrica de datos.

Los ejemplos de UE 111 y 112 incluyen telefonos moviles (p.e., telefonos inteligentes), tabletas, lectores electronicos (p.e., lectores de libros electronicos), ordenadores portatiles, ordenadores de escritorio, ordenadores personales, servidores, asistentes digitales personales (PDA), dispositivos web, decodificadores (STB), encaminadores de red, conmutadores de red, puentes de red, parqmmetros, sensores y otros dispositivos. Algunos dispositivos (p.e., los parqmmetros) entre estos dispositivos de ejemplo se pueden considerar como dispositivos tolerantes al retraso, los cuales pueden incluir dispositivos de comunicacion tipo maquina (MTC). Un dispositivo MTC puede no requerir interaccion por parte del usuario para iniciar la comunicacion con la red (p.e., la red 100 de comunicacion inalambrica). Algunos otros dispositivos (p.e., los telefonos inteligentes) entre estos dispositivos de ejemplo pueden no ser considerados como dispositivos tolerantes al retraso (p.e., dispositivos no MTC). Un dispositivo no MTC (p.e., un terminal de usuario (UE), por ejemplo, un telefono inteligente) puede requerir interaccion por parte del usuario para iniciar una comunicacion con la red (p.e., la red 100 de comunicacion inalambrica).

La MME 101 puede ser un nodo de control principal para la red 100 de comunicacion inalambrica. La MME 101 se puede comunicar con el eNodoB 102 para rastrear y enviarles mensajes a los UE 111 y 112. La MME 101 se puede comunicar con otros UE, ademas del UE 111 y 112, a traves de uno o mas eNodoB adicionales similares o identicos al eNodoB 102. En los sistemas UMTS del 3GPP, la red 100 puede incluir un NodoB en comunicacion con un controlador de red radio (RNC) y un SGSN.

El eNodoB 102 puede operar como eNodoB de servicio en un area geografica como, por ejemplo, la celda 104 en la red 100 de comunicacion inalambrica. El eNodoB 102 se puede disponer (p.e., configurar) para operar como un eNodoB conforme con los estandares LTE del 3GPP o como un NodoB conforme con los estandares UMTS del 3GPP. La FIG. 1 ilustra una red 100 de comunicacion inalambrica que incluye unicamente un eNodoB (p.e., el eNodoB 102) a modo de ejemplo. No obstante, la red 100 de comunicacion inalambrica puede incluir multiples eNodosB (p.e., multiples eNodoB similares o identicos al eNodoB 102) o NodosB. Cada uno de los multiples eNodosB o NodosB puede dar servicio a una celda determinada en la red 100 de comunicacion inalambrica y puede o no ser vecino del eNodoB 102.

Los UE 111 y 112 pueden recibir servicio por parte del eNodoB 102 en la celda 104. Los UE 111 y 112 se pueden disponer (p.e., configurar) para operar en conformidad con los estandares LTE o los estandares UMTS del 3GPP. La FlG. 1 ilustra una red 100 de comunicacion inalambrica que incluye a modo de ejemplo solo dos UE (p.e., los UE 111 y 112) servidos por el eNodoB 102 en la celda 104. No obstante, la red 100 de comunicacion inalambrica puede incluir mas de dos UE atendidos por el eNodoB 102. El eNodoB 102 y cada uno de los UE 111 y 112 pueden operar para comunicarse entre sf utilizando una tecnica de acceso multiple por division de frecuencia ortogonal (OFDMA). Cada uno de los UE 111 y 112 puede operar para recibir senales de comunicacion OFDMA a traves de un canal de comunicacion multiportadora de acuerdo con una tecnica OFDMA. La tecnica OFDMA puede operar en modo duplex en el dominio de la frecuencia (FDD), que utiliza un espectro diferente para el enlace ascendente y el enlace descendente, o en modo duplex en el dominio del tiempo (TDD), que utiliza el mismo espectro para el enlace ascendente y el enlace descendente. Las senales de comunicacion OFDMA pueden comprender subportadoras ortogonales.

Cada uno de los UE 111 y 112 se puede encontrar en diferentes estados de operacion. En uno o mas de estos estados de operacion, el UE 111 puede pasar a un modo de ahorro de energfa con el fin de ahorrar energfa. Por ejemplo, el Ue 111 puede pasar a un modo de ahorro de energfa tras un penodo espedfico de tiempo sin comunicacion activa (p.e., sin intercambio de datos) entre el UE 111 y el eNodoB 102. De modo analogo, el UE 112 puede pasar a un modo de ahorro de energfa tras un penodo espedfico de tiempo sin comunicacion activa (p.e., sin intercambio de datos) entre el UE 112 y el eNodoB 102. Un ejemplo de modo de ahorro de energfa en los UE 111 y 112 incluye un modo de recepcion discontinua (DRX) como, por ejemplo, un modo de DRX conforme con los estandares LTE o UMTS del 3GPP.

En los sistemas UMTS 3GPP, el UE 112 puede estar registrado en diferentes dominios de la red troncal (CN) con diferentes longitudes del ciclo de DRX espedfico del dominio de la CN. Por ejemplo, en el modo FDD, la longitud del ciclo de DRX para cada dominio de la CN es igual a 2ktramas de radio, donde k es el coeficiente de longitud del ciclo de DRX espedfico de la CN. En un dominio de conmutacion de circuitos (CS), la red le envfa mediante senalizacion al UE 112 el valor de k en un bloque de informacion del sistema (SIB), por ejemplo el SIB1. Por consiguiente, en un dominio de CS, el valor de k no es negociable entre el UE y la red. En un dominio de conmutacion de paquetes (PS), el valor de k se puede negociar utilizando un procedimiento del estrato de no acceso (NAS), o si no se negocia el valor de k de este modo, entonces se puede utilizar el valor de k comunicado mediante senalizacion en el SIB. En estos u otros sistemas, el UE 112 almacena la longitud del ciclo de DRX espedfico del dominio de la CN para cada dominio de la CN en el que se encuentra registrado el UE 112 y utiliza la mas corta de dichas longitudes del ciclo de DRX.

En modo Inactivo, el UE 111 puede permanecer en estado dormido durante un penodo sin actividad, de tal modo que la mayor parte de los circuitos (p.e., la circuitena del receptor de radio) en el UE 111 se encuentran desconectados. El UE 111 se puede despertar durante una ocasion de busqueda (PO) para monitorizar la informacion de control en un canal espedfico. Por ejemplo, durante una PO, el UE 111 puede despertar y monitorizar las tramas de un canal de control a la espera de informacion del enlace descendente (p.e., mensajes de busqueda de la MME 101) u otra informacion iniciada por la red 100 de comunicacion inalambrica. A modo de ejemplo, si el UE 111 y el eNodoB 102 estan configurados para comunicarse entre sf segun los estandares LTE del 3GPP, el UE 111 puede despertar durante una PO y monitorizar los instantes de tiempo de transmision del canal ffsico de control del enlace descendente (PDCCH) con el fin de determinar si el UE 111 esta siendo buscado por la red 100 de comunicacion inalambrica. Cuando no esta en una PO, el UE 111 puede dejar de monitorizar el canal de control (p.e., no monitoriza el canal de control) con el fin de reducir el consumo de energfa. A modo de ejemplo, si el UE 111 y el eNodoB 102 estan configurados para comunicarse entre sf de acuerdo con los estandares LTE del 3GPP, el UE 111 puede dejar de monitorizar (p.e., no monitoriza) los instantes de tiempo de transmision del PDCCH durante los penodos fuera de una PO.

El ahorro de energfa en el UE 111 puede depender en parte del valor (p.e., puede ser proporcional al valor) de la longitud del ciclo de DRX. Por ejemplo, un valor relativamente mayor para la longitud del ciclo de DRX puede mejorar el ahorro de energfa en el UE 111. Sin embargo, un valor mayor para la longitud del ciclo de DRX puede aumentar el retraso para restablecer un enlace de comunicacion entre el UE 111 y un eNodoB (p.e., el eNodoB 102) si las senales de control estan presentes en el canal de control mientras el UE 111 se encuentra en modo de DRX. Asf pues, en funcion del tipo y/o la capacidad del dispositivo del UE 111, el eNodoB 102 y el UE 111 pueden comunicarse entre sf para proporcionar una solucion intermedia equilibrada entre el consumo de energfa reducido en el UE 111 y la calidad de servicio (QoS). Por ejemplo, si el UE 111 es un dispositivo tolerante al retraso (p.e., un dispositivo MTC como, por ejemplo, un parqmmetro), puede ser preferible el ahorro de energfa frente al retraso (p.e., el retraso en el acceso a la red). Asf pues, en este ejemplo, el UE 111 puede utilizar la longitud del ciclo de DRX con un valor (p.e., un valor extendido) mayor que el valor (p.e., un valor no extendido) utilizado por un dispositivo no MTC, con el fin de lograr una mayor reduccion en el consumo de energfa (p.e., mas ahorro de energfa). En otro ejemplo, si el UE 111 es un dispositivo no MTC (p.e., un telefono inteligente), puede ser mas preferible una conexion mas rapida a la red que el ahorro de energfa. Por consiguiente, en este ejemplo, el UE 111 puede utilizar una longitud del ciclo de DRX que tenga un valor (p.e., un valor no extendida) menor que el valor (p.e., un valor extendido) utilizado por un dispositivo MTC para mantener o conseguir una buena experiencia del usuario (p.e., conectividad rapida y/o calidad de servicio).

El valor de la longitud del ciclo de DRX se puede basar en el valor de un parametro de DRX soportado por (p.e., proporcionado por) el eNodoB 102. El valor del parametro de DRX soportado por el eNodoB 102 puede incluir el valor de un parametro de DRX predeterminado soportado por el eNodoB 102.

El eNodoB 102 se puede disponer (p.e., configurar) para soportar un numero predeterminado (p.e., N) de valores diferentes de los parametros de d Rx de Tc1 a Tcn asociados a la longitud del ciclo de DRX. Los valores de parametro de DRX de Tc1 a Tcn pueden incluir valores predeterminados de los parametros de DRX soportados por el eNodoB 102. El eNodoB 102 puede soportar un numero relativamente mayor de valores de los parametros de DRX, por lo que eNodoB 102 puede albergar un numero relativamente grande de longitudes del ciclo de DRX correspondientes. A modo de ejemplo, el eNodoB 102 puede soportar mas de cuatro (p.e., N > 4) valores para los parametros de DRX (p.e., valores para los parametros de DRX predeterminados) asociados a mas de cuatro valores de longitud del ciclo de DRX (longitudes del ciclo de DRX predeterminadas).

Se puede utilizar cada uno de los valores de Tc1 a Tcn de los parametros de DRX para determinar el valor de la longitud del ciclo de DRX correspondiente (que el UE 111 puede utilizar mientras se encuentra en modo de DRX). Por ejemplo, si el eNodoB 102 soporta ocho (p.e., N = 8) valores para los parametros de DRX de Tc1 a Tcs (Tc1, Tc2, TC3, TC4, TC5, TC6, TC7 y Tcs), se pueden determinar ocho valores correspondientes para la longitud del ciclo de DRX. La descripcion de la presente solicitud utiliza a modo de ejemplo ocho valores de parametro de DRX para la longitud del ciclo de DRX. El eNodoB 102 puede soportar un numero diferente de valores de parametro de DRX para la longitud del ciclo de DRX. El valor del parametro de DRX Tcn puede ser el valor maximo (p.e., valor maximo predeterminado) entre los valores de parametro de DRX de Tc1 a Tcn. As ^pues, el valor maximo (p.e., valor maximo predeterminado) de la longitud del ciclo de DRX (p.e., longitud del ciclo de DRX) soportada por el eNodoB 102 se puede determinar en funcion del valor maximo del parametro de DRX correspondiente (p.e., Tcn) soportado por el eNodoB 102.

Cada uno de los valores de parametro de DRX soportados por el eNodoB 102 puede corresponder (p.e., expresarse mediante) el numero de tramas de radio utilizadas en la red 100 de comunicacion inalambrica. Por ejemplo, el eNodoB 102 puede soportar un valor de parametro de DRX Tc1 = 32 tramas de radio, Tc2= 64 tramas de radio, Tc3 = 128 tramas de radio, Tc4 = 256 tramas de radio, Tc5 = W tramas de radio, Tc6 = X tramas de radio, Tc7 = Y tramas de radio y Tcs = Z tramas de radio, en donde Tc1 < Tc2 < Tc3 < Tc4 < Tc5 < Tc6 < Tc7 < Tcs. Asf pues, si Tc4 no es mayor que 256, cada uno de los valores W, X, Y y Z puede ser cualquier numero mayor que 256 tramas de radio, en donde W < X < Y < Z. La duracion de cada una de las tramas de radio puede encontrarse en el rango de algunos milisegundos (p.e., 10 ms).

El valor de la longitud del ciclo de DRX se puede determinar en funcion de uno de los valores de parametro de DRX (p.e., uno de los Tc1 a Tcn) soportados por el eNodoB 102. El valor de la longitud del ciclo de DRX se puede determinar de acuerdo con los estandares LTE o UMTS del 3GPP. Por ejemplo, el valor de la longitud del ciclo de DRX se puede determinar en funcion del menor (p.e., el mrnimo) entre el valor (p.e., Tdev) de parametro de DRX especificado por un dispositivo y el valor (p.e., uno de los Tc1 a Tcn) del parametro de DRX especificado por el eNodoB.

Varios modos de realizacion proporcionan metodos con ciclos de DRX de busqueda extendidos en el estado inactivo del RRC para contribuir a un ahorro adicional de energfa en el UE para MTC u otras aplicaciones. Las especificaciones UMTS del 3GPP actuales definen ciclos de DRX de busqueda de hasta 5120 ms, y las especificaciones LTE del 3GPP actuales definen ciclos de DRX de busqueda de hasta 2560 ms. Las aplicaciones MTC se pueden ejecutar en un gran numero de UE 112 de baja movilidad y pueden transmitir datos pequenos de manera relativamente infrecuente. Si los UE 111 y 112 que utilizan dichas aplicaciones tienen que despertar para cada ocasion de busqueda se pueden agotar las baterias de los UE 111 y 112. Por consiguiente, varios modos de realizacion permiten ciclos de DRX de busqueda mas largos proporcionando valores extendidos para los ciclos de DRX de busqueda mediante la definicion de valores para el ciclo de DRX extendido, el escalado de los valores actuales, u otros mecanismos.

Valores del ciclo de DRX extendido

En varios modos de realizacion se proporcionan valores para la longitud del ciclo de DRX extendido. En los sistemas actuales definidos de acuerdo con los estandares tecnicos (TS) 24.008 y 24.301 del 3GPP, los valores se comunican mediante senalizacion en un campo del Elemento de Informacion (IE) del Parametro de DRX, y varios modos de realizacion extienden los valores definidos en dicho campo. En varios modos de realizacion diferentes, el UE 112 puede enviarle a la red la longitud del ciclo de DRX extendido que se desea en, por ejemplo, el contenedor NAS como parte de un IE de nueva definicion, al SGSN en el caso de sistemas UMTS del 3GPP o a la MME en el caso de los sistemas LTE del 3GPP. El UE 112 puede enviar la longitud del ciclo de DRX extendido deseada durante diferentes procedimientos como, por ejemplo, un mensaje Attach Request (solicitud de registro) (tanto en el caso de los sistemas LTE como UMTS del 3GPP), una solicitud Routing Area Update (RAU) (actualizacion del area de encaminamiento) (en el caso de los sistemas UMTS del 3GPP) o una solicitud Tracking Area Update (TAU) (actualizacion del area de seguimiento) (en el caso de los sistemas LTE del 3GPP).

Despues de recibir este nuevo valor para el Ciclo de DRX extendido, en los sistemas UMTS del 3GPP, el SGSN le puede indicar el valor al RNC en, por ejemplo, un mensaje de busqueda lu, o el SGSN puede proponer otro valor. En el caso de los sistemas LTE del 3GPP, si la MME 101 acepta el valor indicado la MME 101 puede indicarle el valor al eNodoB 102 en un mensaje de busqueda S1, o la MME 101 puede proponer otro valor.

Cuando el eNodoB 102 (o el RNC en los sistemas UMTS del 3GPP) recibe el valor del ciclo de DRX de busqueda extendido desde la MME 101 (o el SGSN en los sistemas UMTS del 3g PP), el eNodoB 102 utilizara el valor del ciclo de DRX de busqueda extendido. Esto es en contraposicion a los sistemas actuales, que operan conforme a las especificaciones TS 25.304 o TS 36.304 del 3GPP, que seleccionan la longitud del ciclo de DRX espedfica del dominio CN mas corta de las almacenadas y el valor de ciclo predeterminado anunciado por el eNodoB 102. De modo analogo, el UE 112 aplicara el valor definido por el UE para el busqueda o esperara hasta que se reciba una confirmacion de recepcion antes de utilizar el valor definido por el UE para el busqueda. En algunos modos de realizacion, la MME 101 (o el SGSN) puede ejecutar cierta logica para comunicarle al eNodoB 102 (o al RNC) que regla se debe aplicar para seleccionar la longitud del ciclo de DRX.

Senalizacion del soporte del ciclo de DRX de busqueda extendido por parte de la red

El eNodoB 102 (o el NodoB en los sistemas UMTS del 3GPP) puede indicar mediante senalizacion el soporte de DRX de busqueda extendido en el SIB2 (SIB1 en los sistemas UMTS del 3GPP), o en un SIB de nueva definicion. El eNodoB 102 (o el NodoB) puede difundir este mensaje, y si el mensaje esta disponible antes de una solicitud Attach Request, el mensaje puede proporcionarle al UE 112 informacion sobre el soporte de DRX extendida del eNodoB 102 (o el NodoB). El UE 112 tambien puede utilizar el mensaje para actualizar las longitudes del ciclo de DRX espedfico del UE o las longitudes del ciclo de DRX espedfico del dominio CN utilizando una solicitud RAU (en los sistemas UMTS del 3GPP), una solicitud TAU (en los sistemas LTE del 3GPP), etc. La red 100 tambien puede redirigir el UE 112 a una celda diferente que soporte ciclos de DRX de busqueda extendidos o que soporte un valor solicitado por el UE 112 para el ciclo de DRX de busqueda extendido. La red 100 puede realizar esta redireccion al considerar, por ejemplo, las condiciones de la red.

Senalizacion del valor del ciclo de DRX de busqueda extendido por parte del UE

En los sistemas actuales conformes con las TS 24.008 y 24.301 del 3GPP se define un mensaje Attach Request que contiene un parametro de DRX (3 octetos de longitud) que indica si un UE 111 soporta el modo de DRX y la(s) longitud(es) del ciclo de DRX espedfico del UE (o espedfico del dominio de CN). No obstante, los modos de realizacion no se limitan a incluir el parametro de DRX en un mensaje Attach Request, y el parametro de DRX se puede incluir, por ejemplo, en una solicitud TAU o RAU. En varios modos de realizacion se incluyen valores adicionales para la longitud del ciclo de DRX en el tercer octeto de este parametro de DRX. Sin embargo, como el numero de tramas del sistema (SFN) se ve afectado por longitudes de ciclo mayores que un cierto valor, tanto el UE como la red 100 deben indicar mediante senalizacion el soporte para los ciclos de DRX de busqueda extendidos. En varios modos de realizacion diferentes, se anade un nuevo identificador de elemento de informacion (IEI) a los mensajes NAS como, por ejemplo, el mensaje Attach Request, la solicitud RAU (en los sistemas UMTS de 3GPP), o la solicitud TAU (en los sistemas LTE de 3GPP). La presencia de este IEI, que se puede denominar "parametro de DRX Extendida" aunque los modos de realizacion no se limitan a ello, indica que el UE 111 esta interesado en y puede soportar la d Rx de busqueda extendida. En lugar de, o ademas de, definir un parametro IEI de DRX Extendida, se puede modificar el valor de un parametro de DRX existente definido en las Ts 24.008 y 24.301 del 3GPP.

En algunos modos de realizacion, el IEI incluye los valores del ciclo de DRX extendido. En al menos esos modos de realizacion, se supone que el SFN se extiende segun sea necesario considerando la extension de la DRX. A continuacion, se ilustra un ejemplo de un parametro IE de DRX extendida de acuerdo con este modo de realizacion:

Tabla 1. Parametro IE propuesto de DRX extendida y contenido - caso 1 Parametro IEI de la DRX extendida

octeto 1

Valor de la DRX extendida

octeto 2

No obstante, en los sistemas actuales, el SFN se reinicia cada 40,96 segundos (en los sistemas UMTS del 3GPP) o cada 10,24 segundos (en los sistemas LTE del 3GPP). En consecuencia, en varios modos de realizacion se introduce un factor de reinicio del SFN para especificar el numero de ciclos que deben transcurrir antes de que el mensaje de busqueda pueda ser leido por el UE 111. A continuacion se ilustra un ejemplo de parametro IE de DRX extendido de acuerdo con esos modos de realizacion:

Tabla 2. Parametro IE propuesto de DRX extendida y contenido - caso 2 Parametro IEI de la DRX extendida

octeto 1

Factor de reinicio del SFN y valor de la DRX extendida

octeto 2

El factor de reinicio del SFN tambien se puede especificar como un multiplicador del SFN, un mdice de ciclo de SFN o un factor de repeticion del SFN. El eNodoB 102 y el UE 111 almacenaran el factor de reinicio del SFN ademas de otra informacion para calcular la trama de busqueda (PF) y la ocasion de busqueda (PO) en las que el UE 111 escuchara los mensajes de busqueda.

Si la MME 101 acepta el valor del Ciclo de DRX extendido indicado desde el UE 111 o cualquiera de los nuevos valores del Ciclo de DRX extendido, el UE 111 y el eNodoB 102 determinan la trama de busqueda (PF) y la ocasion de busqueda (PO) dentro de la PF de acuerdo con la Formula (1) siguiente:

PF = SFN mod T = (T div N) * (UE_ID mod N) (1)

En algunos modos de realizacion, T es el ciclo de DRX (representado en tramas), definido como el mas largo entre el ciclo de DRX extendido espedfico del UE negociado suministrado por las capas superiores o recibido desde la MME 101 y el ciclo de busqueda predeterminado anunciado en el SIB2, y N y otros parametros especificados en la TS 36.304 del 3GPP. En otros modos de realizacion, T puede referirse directamente al ciclo de DRX extendido espedfico del UE, siendo ignorado el valor difundido. En aun otros modos de realizacion, el eNodoB 102 puede difundir los valores espedficos de la celda en la informacion del sistema, por ejemplo defaultpagingcycle (ciclo de busqueda predeterminado) y defaultextendedpagingcycle (ciclo de busqueda extendida predeterminado), de tal modo que T continuara haciendo referencia al mas corto entre el ciclo de DRX espedfico del UE y uno de los dos valores del ciclo de busqueda predeterminados.

Si la MME 101 rechaza el valor del Ciclo de DRX extendido indicado solicitado por el UE 111, el UE 111 y el eNodoB 102 calculan la PF y la PO de acuerdo con la especificacion actual del 3GPP.

En algunos otros modos de realizacion, el UE 111 puede utilizar el IE de las Propiedades de Dispositivo para indicar mediante senalizacion un ciclo de DRX deseado en mensajes NAS como, por ejemplo, un Attach Request, una solicitud RAU (en los sistemas UMTS del 3GPP), o una solicitud TAU (en los sistemas LTE del 3GpP) o una Extended Service Request (solicitud de servicio extendido) (en los sistemas LTE del 3GPP). El UE 111 puede indicar mediante senalizacion un mdice, y este mdice puede representar un multiplicador del ciclo de DRX que el UE 111 esta senalizando. De acuerdo con las TS 24.008 y 24.301 del 3GPP, el IE de las Propiedades de Dispositivo ocupa actualmente tres bits de reserva que se pueden utilizar en algunos modos de realizacion para suministrar el multiplicador del ciclo de DRX. En varios modos de realizacion, se podna anadir una tabla para asociar el mdice al multiplicador real. Si solo se va a definir un unico ciclo de DRX extendido se podna utilizar un solo valor de reserva, el cual corresponded a un solo valor multiplicador. Ademas, para extender aun mas el valor del multiplicador se podna considerar si el UE 111 es un dispositivo de baja prioridad. A continuacion se ilustra una tabla de ejemplo, en la que M1, M2,... M6 son numeros predefinidos.

Tabla 3. Correspondencia del IE de las Propiedades de Dispositivo

Valor Baja prioridad (0 = falso) Multiplicador

senalizado

0 0 Parametro de DRX

0 1 Parametro de DRX

1 0 M1 * parametro de DRX

1 1 M2 * parametro de DRX

2 0 M3 * parametro de DRX

2 1 M4 * parametro de DRX

3 0 M5 * parametro de DRX

3 1 M6 * parametro de DRX

Los UE 111 de baja prioridad de acceso (esto es, tolerantes al retraso) pueden tolerar una gran latencia. La extension del ciclo de DRX para dichos UE 111 implica que los UE 111 se despertaran para recibir datos del enlace descendente con menor frecuencia. Como dichos UE 111 no tienen unos requisitos estrictos de latencia, estos UE 111 pueden tener ciclos de DRX mas largos. En consecuencia, se puede configurar el multiplicador para los UE 111 de baja prioridad relativamente mas grande que en el caso de los dispositivos no tolerantes al retraso.

En algunos modos de realizacion, se puede utilizar un bit de reserva simplemente para que el UE 111 indique si soporta o no un Ciclo de DRX extendido. Como otra opcion, los valores de reserva pueden ser utilizados por parte de la red en combinacion con la indicacion de baja prioridad. En al menos esos modos de realizacion, se supone que algunos UE 111 son mas flexibles en terminos de tolerancia de retraso, por lo que dichos UE 111 pueden comportarse satisfactoriamente con ciclos de DRX altos. Cuando uno de dichos UE 111 le indica mediante senalizacion a la red que es "tolerante al retraso", tambien podna indicarle mediante senalizacion a la red (utilizando los bits de reserva del IE de las Propiedades de Dispositivo) que tipo del ciclo de DRX soporta el UE. Dados dos UE 111 tolerantes al retraso, pudiendo soportar uno de ellos ciclos de DRX mas grandes que el otro, los UE 111 pueden indicar mediante senalizacion si el UE 111 debena recibir un ciclo de DRX en la parte superior o inferior de un rango. En esta solucion, la red utiliza el conocimiento de que el UE es de baja prioridad combinado con el valor indicado (a partir de los bits de reserva) para decidir que DRX utilizar. Para cada valor senalizado, la red tendra un rango de ciclos de DRX extendida. Si el UE 111 es de baja prioridad, la red le asignara los valores superiores en dicho rango:

Tabla 4. Combinacion con la Indicacion de Baja Prioridad en el Lado de la Red Valor Baja Rango de ciclos de

senalizado prioridad DRX extendida en

la red.

0 0 R1-R2 La red debe asignar un ciclo de DRX extendido en la parte inferior del rango

0 1 R1-R2 La red debe asignar un ciclo de DRX extendido en la parte superior del rango

1 0 R3-R4 La red debe asignar un ciclo de DRX en la parte inferior del rango

1 1 R3-R4 La red debe asignar un ciclo de DRX en la parte superior del rango

Senalizacion de ciclos de DRX extendidos por parte de la MME/el SGSN

La red (p.e., el SGSN o la MME 101) le envfa un mensaje Attach Accept al UE 111 para indicarle que la solicitud Attach Request correspondiente ha sido aceptada. Como parte del Attach Request, si el UE 111 hubiera indicado una DRX de busqueda extendida, la MME o el SGSN puede indicar si ese valor ha sido aceptado o no segun los parametros de la red. De acuerdo con las especificaciones actuales de LTE y UMTS del 3GPP, los valores del ciclo de DRX estan limitados, y la MME o el SGSN acepta valores del UE 111 y le reenvfa el valor al eNodoB 102 o al RNC, segun corresponda, despues de actualizar la base de datos del SGSN o la MME.

No obstante, en varios modos de realizacion que proporcionan un valor de DRX de busqueda extendida, si la red no estima que el valor sea adecuado, la red se lo indica al UE 111 y, o bien sugiere un valor alternativo, o sugiere la utilizacion del valor predeterminado difundido por el NodoB o el eNodoB 102. En esta determinacion, la red puede tener en cuenta factores tales como si todos los NodosB o eNodosB en el area de encaminamiento, el area de seguimiento, etc. soportan la DRX de busqueda extendida.

El contenido del valor de la DRX de busqueda extendida puede corresponder a los cambios propuestos mas arriba en relacion con los mensajes del UE. Esta negociacion se puede basar en el parametro de DRX Extendida o en valores adicionales dentro del parametro de DRX existente.

En los sistemas LTE del 3GPP, la MME 101 puede proporcionarle una indicacion a un eNodoB 102 de que la MME 101 ha aceptado el ciclo de DRX espedfico del UE 111 tal como lo ha solicitado el UE 111 en el mensaje de solicitud de TAU o el mensaje Attach Request. Algunos modos de realizacion incluyen la incorporacion de un parametro IE del ciclo de DRX de busqueda extendido a los mensajes S1-Paging (busqueda S1) definidos en la TS 36.413 del 3GPP.

De modo analogo, en los sistemas UMTS del 3GPP, un SGSN puede proporcionarle una indicacion a un RNC para el ciclo de DRX espedfico del UE 111 aceptado tal como ha sido solicitado por el UE en un mensaje de solicitud Attach o de solicitud de RAU. Algunos modos de realizacion incluyen la incorporacion de un parametro del ciclo de DRX de busqueda extendido en un mensajes lu-Paging (busqueda lu) definido en la TS 25.413 del 3GPP.

En los sistemas LTE del 3GPP, el eNodoB 102 le informa a la MME 101 que el eNodoB 102 soporta ciclos de DRX extendida en mensajes de solicitud de configuracion S1 y mensajes de actualizacion de configuracion del eNodoB, actualmente definidos en la TS 36.413 del 3GPP. Algunos modos de realizacion pueden incorporar un IE de soporte de DRX de Busqueda Extendida a uno de estos mensajes o a ambos. En la Tabla 5 se ilustra, a modo de ejemplo, una parte de un mensaje de configuracion S1 que puede estar definido en la seccion 9.1.8.4 de la TS 36.413 del 3GPP, y el codigo ASN.1 asociado:

Tabla 5: Solicitud de configuracion S1.

IE / Nombre Presencia Tipo y referencia Descripcion semantica

del grupo (M = Obligatorio, de IE

O = Opcional)

Soporte de Opcional ENUMERATED Este IE le indica a la MME que el DRX de (verdadero) o BIT eNodoB es capaz de soportar la

busqueda STRING (1) DRX extendida

extendida

S1SetupRequestIEs S1AP-PROTOCOL-IES ::={

{ID id-ExtendedPagingDRXSupport CRITICALITY ignore TYPE ENUMERATED PRESENCE optional},

}

ENBConfigurationUpdate ::= SEQUENCE {

protocolIEs protocolIEContainer { {ENBConfigurationUpdateIEs} },

}

ENBConfigurationUpdateIEs S1AP-PROTOCOL-IES ::={

}

Actualizaciones a los procedimientos de indicacion de liberacion de la conexion de senalizacion para soportar DRX de busqueda extendida

Algunos modos de realizacion pueden configurar el UE 111 con ciclos de DRX de busqueda extendidos utilizando un procedimiento Signaling Connection Release Indication (Indicacion de Liberacion de la Conexion de Senalizacion). De acuerdo con las especificaciones UMTS actuales, el UE 111 en el estado CELL_DCH del modo RRC conectado puede enviar el mensaje Signaling Connection Release Indication para solicitarle a la UTRAN que libere una de sus conexiones de senalizacion NAS en un dominio de la CN. La UTRAⁿpuede responder transmitiendo un mensaje de Signaling Connection Release para liberar la conexion de senalizacion NAS como se ha solicitado. A continuacion, la UTRAN puede conmutar el UE 111 a un estado RRC mas eficiente para la batena, esto es, o bien al modo Inactivo (enviando un mensaje RRC Connection Release (Liberacion de la Conexion RRC)) o bien a los estados del modo conectado CELL_^fA^cH, CELL_PCH o URA_PCH (enviando, p.e., un mensaje Radio Bearer Reconfiguration (Reconfiguracion de la Portadora de Radio)).

De acuerdo con estos modos de realizacion, los mensajes existentes Signaling Connection Release Indication, Signaling Connection Release, Radio Bearer Reconfiguration y RRC Connection Release se extienden utilizando el IE de DRX de Busqueda Extendida descrito mas arriba en relacion con las modificaciones al IE de las Propiedades de Dispositivo. En los modos de realizacion en los que se incluye el IE de DRX de Busqueda Extendida en el mensaje Signaling Connection Release Indication, el UE 111 solicita que se configure la UTRAN con ciclos de DRX de busqueda mas largos tanto en los estados de modo inactivo como conectado. Asimismo, la UTRAN puede incluir, como respuesta, el IE de DRX de Busqueda Extendida en cualquiera de los mensajes Signaling Connection Release, Radio Bearer Reconfiguration y RRC Connection Release para indicarle al UE 111 si se ha aceptado o no la DRX de busqueda solicitada por el UE 111. En otros modos de realizacion, la UTRAN puede indicar una DRX de busqueda extendida diferente, que se utilizara tanto en el estado de modo inactivo como conectado.

Diagramas de senalizacion de ejemplo para el ciclo de DRX de busqueda extendido

La FIG. 2 ilustra un ejemplo de comunicacion entre los elementos y dispositivos en una red 100, de acuerdo con algunos modos de realizacion descritos en la presente solicitud. Los elementos pueden incluir la MME 101, el eNodoB 102 y el UE 111. La comunicacion que se ilustra en la FIG. 2 puede incluir mensajes (p.e., en forma de senales de radiofrecuencia (RF)) como, por ejemplo, los mensajes 211, 221 y 231. No obstante, como comprendera cualquiera con un conocimiento normal de la tecnica, pueden encontrarse otros mensajes y senalizacion, por ejemplo, senales de busqueda u otras senales.

El UE 111 puede enviarle el mensaje 211 al eNodoB 102. El mensaje 211 puede incluir informacion para solicitar el establecimiento de un enlace de comunicacion (p.e., una conexion de radio) entre el UE 111 y el eNodoB 102. Por ejemplo, el mensaje 211 puede incluir un mensaje RRC Connection Request (Solicitud de Conexion RRC) conforme con los estandares LTE del 3GPP. Asf pues, el mensaje 211 puede incluir informacion que identifique la identidad del dispositivo y la causa del establecimiento del RRC de acuerdo con los estandares LTE del 3GPP. En el ejemplo asociado a la FIG. 2, el UE 111 puede incluir un dispositivo tolerante al retraso. Por ello, la causa del establecimiento incluida en el mensaje 211 enviado por el UE 111 puede incluir una causa de establecimiento tolerante al retraso. El eNodoB 102 puede volver a establecer un enlace de comunicacion apropiado con el UE 111 de acuerdo con, al menos en parte, la causa del establecimiento tolerante al retraso indicada por el UE 111. Por ejemplo, en funcion de la causa del establecimiento tolerante al retraso indicada por el UE 111, la MME 101 y el eNodoB 102, puede proporcionarle (p.e., enviarle) al UE 111 el valor de un parametro (p.e., uno de los Tc5 a Tcn) de DRX extendida (p.e., predeterminada) asociado a la longitud de un ciclo de DRX extendido (p.e., predeterminada) para su uso en el modo de DRX.

El UE 111 tambien puede enviarle el mensaje 221 al eNodoB 102. El mensaje 221 se puede enviar despues de que se haya enviado el mensaje 211 con el fin de completar el establecimiento de un enlace de comunicacion entre el UE 111 y el eNodoB 102. El mensaje 221 puede incluir informacion que indique la capacidad del dispositivo del UE 111. El Mensaje 221 puede incluir un mensaje Attach Request conforme con los estandares LTE del 3GPP. El mensaje 221 puede incluir un mensaje Extended Service Request (Solicitud de Servicio Extendido) conforme con los estandares LTE del 3GPP. Tal como se describe en la presente solicitud, el mensaje 221 puede incluir un IE del parametro de DRX extendida que incluya el ciclo de DRX de busqueda deseado del UE 111. A su vez, el eNodoB 102 puede transmitirle este mensaje a la MME 101. En el mensaje 231, la MME 101 puede aceptar el ciclo de DRX de busqueda solicitado, o proponer otro valor tal como se ha descrito mas arriba.

La FIG. 3 ilustra un ejemplo de comunicacion para la transicion del modo inactivo al modo conectado para el procedimiento de Tracking Area Update (TAU) de acuerdo con algunos modos de realizacion descritos en la presente solicitud en relacion con los sistemas que soportan LTE del 3GPP. Para los sistemas UMTS del 3GPP se puede aplicar una senalizacion similar. La comunicacion que se ilustra en la FIG. 3 puede incluir mensajes (p.e., en forma de senales de radiofrecuencia (RF)) como, por ejemplo, los mensajes 311, 321 y 331. No obstante, como comprendera cualquiera con un conocimiento normal de la tecnica, pueden encontrarse otros mensajes y senalizacion, por ejemplo, senales de busqueda u otras senales.

La senalizacion inicial puede ser similar a la que se ilustra en la FIG. 2 y, por lo tanto, no se describe en relacion con la FIG. 3. El UE 111 puede enviarle el mensaje 311 al eNodoB 102. El mensaje 311 puede incluir informacion para solicitar una actualizacion del area de seguimiento. Por ejemplo, el mensaje 311 puede incluir un mensaje de RRC Connection Setup Complete (Configuracion de la Conexion RRC Completada) conforme con los estandares LTE del 3GPP. El mensaje 311 puede incluir un IE del parametro de DRX extendida solicitado, tal como se describe en la presente solicitud. El eNodoB 102 puede pasarle el mensaje 311 a la MME 101.

En el mensaje 321, la MME 101 puede aceptar el ciclo de busqueda de DRX solicitado o proponer otro valor, tal como se ha descrito mas arriba. El eNodoB 102 puede transmitir el mensaje 331, que puede incluir, por ejemplo, RRC DL Info Transfer (transferencia de informacion en DL RRC), para indicarle al UE 111 que la MME ha aceptado el parametro de DRX extendida.

Aumento del ciclo de DRX de busqueda mediante la utilizacion de factores de escala

En algunos otros modos de realizacion se mantiene el numero de parametros de DRX disponibles y se anade un factor de escala, PagingCycleSF (factor de escala del ciclo de busqueda), con valores enteros de 0-12. Ademas del defaultPagingCycle actualmente difundido por el eNodoB 102 en los sistemas actuales, el eNodoB 102 tambien puede comunicar el PagingCycleSF en la Informacion del Sistema. El UE 111 tambien puede seleccionar un valor de PagingCycleSF para ser transmitido al eNodoB 102 cuando el UE 111 transmite un ciclo de DRX espedfico del UE. En varios modos de realizacion, el ciclo T de DRX del UE 111 se puede calcular por consiguiente del siguiente modo:

T = defaultPagingCycle * 2A(PagingCydeSF) (2)

En algunos otros modos de realizacion, en lugar de calcular el mmimo entre el ciclo de busqueda y el valor del ciclo de DRX espedfico del UE para determinar el ciclo de busqueda del UE 111, la red y el UE 111 especifican un factor de escala espedfico del dispositivo, PagingDeviceSF (factor de escala de busqueda del dispositivo). El UE 111 puede especificar el valor deseado de este parametro, pero el valor que se utilizara sera decidido en ultima instancia por la red y comunicado al UE 111. El PagingDeviceSF puede tener valores enteros de 0-12, al igual que el PagingCycleSF, y sera configurado de acuerdo con un criterio espedfico del UE. Consecuentemente, diferentes dispositivos pueden tener unos factores de escala diferentes y los correspondientes ciclos de busqueda diferentes. Por consiguiente, el ciclo de busqueda del UE 111 se puede calcular del siguiente modo:

Min(defaultPagingCycle,UE-specific DRX) * 2APagingDeviceSF (3) o

Min(defaultPagingCycle * PagingCycleSF, UE-specific DRX) * 2APagingDeviceSF (4) La formula (3) se podna utilizar para los modos de realizacion en los que el parametro de DRX espedfico del UE se modifica de acuerdo con la formula (2). La formula (4) se podna utilizar para los modos de realizacion en los que el PagingCycleSF esta definido.

En algunos modos de realizacion, el ciclo de busqueda puede ser establecido por el eNodoB 102. En los sistemas LTE del 3GPP actuales, el eNodoB 102 comunica el defaultPagingCycle en la informacion del sistema para todos los UE 111 en la red 100.

La FIG. 4 ilustra un ejemplo de senalizacion de factores de escala de busqueda de acuerdo con al menos algunos modos de realizacion. La FIG. 4 puede incluir mensajes (p.e., en forma de senales de radiofrecuencia (RF)) como, por ejemplo, los mensajes 411, 421, 431 y 441. No obstante, como comprendera cualquiera con un conocimiento normal de la tecnica, pueden encontrarse otros mensajes y senalizacion, por ejemplo, senales de busqueda u otras senales.

El UE 111 puede enviarle el mensaje 411 al eNodoB 102. El mensaje 411 puede incluir informacion para solicitar el establecimiento de un enlace de comunicacion (p.e., una conexion de radio) entre el UE 111 y el eNodoB 102. Por ejemplo, el mensaje 411 puede incluir un mensaje RRC Connection Request conforme con los estandares LTE del 3GPP. El mensaje 411 puede indicar que el UE 111 es un dispositivo MTC configurando como Establishment Cause (Causa del Establecimiento) el valor delayTolerantAccess (Acceso Tolerante al retraso).

En el mensaje 421, el UE le indica al eNodoB 102, el cual se lo indica a la MME 101, que el UE 111 es un dispositivo MTC incluyendo un IE de Propiedades de Dispositivo en un mensaje Attach Request. El mensaje 421 tambien puede incluir informacion del ciclo de DRX espedfico del UE y el PagingDeviceSF, tal como se describe en la presente solicitud.

Cuando la MME 101 recibe el mensaje 421 Attach Request, en funcion de si el UE 111 es MTC o no MTC y de acuerdo con consideraciones tales como el tipo de aplicaciones y los servicios a los que se ha suscrito el UE 111, la MME busca el lfmite maximo del ciclo de busqueda para el UE 111 (que se puede encontrar almacenado en e1HSS o en algun otro lugar) y establece el lfmite para el ciclo de busqueda de acuerdo con el mismo. La MME comunica esta informacion en el mensaje 431, el cual puede incluir un mensaje Attach Accept conteniendo informacion acerca del ciclo de busqueda de informacion y el parametro propuesto en algunos modos de realizacion, PagingDeviceSF. El eNodoB 102 le comunica el valor al UE 111 en el mensaje 441, el cual puede incluir un mensaje RRC Connection Reconfiguration.

Ejemplo de dispositivo para implementar los modos de realizacion

La FIG. 5 es un diagrama de bloques de los componentes basicos de un UE 500 de acuerdo con algunos modos de realizacion. El UE 500 puede ser apropiado como UE 111 (FIG. 1). El UE 500 puede soportar metodos para ahorro de energfa de acuerdo con los modos de realizacion descritos mas arriba en relacion con las FIG. 1-4.

El UE 500 incluye una o mas antenas 510 dispuestas para comunicarse con un NodoB, un eNodoB 102 (FIG. 1), u otros tipos de puntos de acceso de red de area local inalambrica (WLAN). El UE 500 incluye, ademas, un procesador 520, instrucciones 525 y una memoria 530. El UE 500 puede incluir ademas una interfaz 540 de comunicaciones. En un modo de realizacion, la memoria 530 incluye, pero no se limita a, una memoria de acceso aleatorio (RAM), RAM dinamica (DRAM), RAM estatica (SRAM), DRAM smcrona (SDRAM), SDRAM de doble tasa de datos (DDR) (DDR-SDRAM), o cualquier dispositivo capaz de soportar un almacenamiento temporal de datos de alta velocidad.

Los modos de realizacion de ejemplo le permiten a un UE 500 transmitirle a la red, mediante la interfaz 540 de comunicaciones, un mensaje del estrato de no acceso (NAS), indicando que el UE desea utilizar el valor de DRX de busqueda extendida, y recibir un mensaje de la red incluyendo un elemento de informacion (IE) que indica si la red soporta dicho valor de DRX de busqueda extendida. El mensaje NAS puede incluir un mensaje Attach Request, y el valor de busqueda extendida se puede indicar en el IE del Parametro de DRX incluido en el mensaje Attach Request. En algunos modos de realizacion, el mensaje NAS puede incluir un mensaje Attach Request, un mensaje Tracking Area Update Request o un mensaje Routing Area Update Request, en el que el valor de busqueda extendida se indica en un IE del parametro de DRX Extendida. La interfaz 540 de comunicaciones puede recibir, en respuesta al Attach Request, un mensaje Attach Accept que incluye un IE del parametro de DRX extendida. En al menos un modo de realizacion, la interfaz 540 de comunicaciones es, por ejemplo, una capa ffsica inalambrica que funciona de acuerdo con una operacion de multiple entrada/multiple salida (MIMO).

El procesador 520 puede incluir logica o codigo para permitirle al UE 500 procesar las senales recibidas de la red a traves de la antena 510. El procesador 520 puede incluir codigo u otras instrucciones 525 para permitirle al UE 500 determinar la utilizacion de un valor de recepcion discontinua (DRX) de busqueda extendida para aumentar la longitud del ciclo de busqueda a un valor mayor que un primer valor cuando el UE opera en una red de acuerdo con un estandar de la familia de estandares del Proyecto de Asociacion de Tercera Generacion (3GPP) para la Evolucion a Largo Plazo (LTE), y un segundo valor cuando el UE opera en una red de acuerdo con un estandar de la familia de estandares del Sistema Universal de Telecomunicaciones Moviles (UMTS). Las instrucciones 525 pueden permitirle ademas al UE 500 configurar un mensaje del estrato de no acceso (NAS) para ser transmitido al eNodoB 102 indicando que el UE desea utilizar el valor de DRX de busqueda extendida. En respuesta al mensaje NAS, las instrucciones 525 pueden permitirle ademas al UE 500 recibir un mensaje del eNodoB 102 que incluye un elemento de informacion (IE) indicando si la red soporta el valor de DRX de busqueda extendida.

Las instrucciones 525 pueden permitirle al UE 500 recibir, en respuesta al Attach Request, un mensaje Attach Accept que incluye un IE del parametro de DRX Extendida. Las instrucciones 525 tambien pueden permitirle al UE 500 determinar un factor de escala por el cual multiplicar la longitud del ciclo de busqueda para el Ue , en donde la determinacion se basa en uno o mas criterios entre el tipo de dispositivo del UE y el tipo de una o mas aplicaciones que se ejecutan en el UE. Las instrucciones 525 pueden permitirle al UE 500 transmitirle el factor de escala a la red en un IE de Propiedades de Dispositivo.

Ejemplo de eNodoB para implementar los modos de realizacion

La FIG. 6 es un diagrama de bloques que ilustra los detalles de un eNodoB 600 de acuerdo con algunos modos de realizacion. El eNodoB 600 puede ser apropiado como eNodoB 102 (FIG. 1). Aunque algunos modos de realizacion se describen en relacion con un eNodoB que opera de acuerdo con la LTE del 3GPP, otros modos de realizacion pueden incluir una circuitena similar para implementar las funciones de un NodoB conforme con un estandar UMTS del 3GPP. El eNodoB 600 incluye un procesador 610, una memoria 620, un transceptor 630 e instrucciones 635. El eNodoB 600 puede incluir otros elementos (que no se muestran).

El procesador 610 comprende una o mas unidades centrales de procesamiento (CPU), unidades de procesamiento de graficos (GPU) o ambas. El procesador 610 proporciona funcionalidades de procesamiento y control para el eNodoB 600. La memoria 620 comprende una o mas unidades de memoria estatica y transitoria configuradas para almacenar las instrucciones 635 junto con los datos para el eNodoB 600.

El transceptor 630 comprende uno o mas transceptores que incluyen una antena de multiple entrada y multiple salida (MIMo ) para soportar comunicaciones de tipo MIMO. El transceptor 630 recibe transmisiones en el UL y envfa transmisiones en el ^dL, entre otras cosas, desde y hacia el UE 111 (FIG. 1).

El transceptor 630 puede transmitir una senal de control de recursos radio (RRC) que incluye un elemento de informacion (IE) que indica si el eNodoB soporta la utilizacion por parte del terminal de usuario (UE) de un valor de busqueda extendida. El transceptor 630 puede recibir de la MME 101 (FIG.1) u otra entidad de red como, por ejemplo, el SGSN, el valor de busqueda extendido en respuesta a una solicitud por parte del UE 111 para utilizar el valor de busqueda extendido.

El transceptor 630 puede recibir un mensaje indicando el grado hasta el que el UE 111 es tolerante al retraso. El transceptor 630 puede recibir esta indicacion en un mensaje Attach Request desde un UE 111. No obstante, los modos de realizacion no estan limitados a ello, y el transceptor 630 tambien puede recibir esta indicacion en una solicitud de TAU, una solicitud de servicio extendida o una solicitud de RAU, por ejemplo. El mensaje Attach Request puede incluir un factor de escala deseado por el UE 111, en donde el factor de escala deseado es un numero por el cual el UE 111 multiplicara un valor del ciclo de busqueda para generar un ciclo de busqueda espedfico del dispositivo para el UE 111. El procesador 610 puede determinar si se debe permitir al UE 111 utilizar el factor de escala deseado, y configurar un mensaje de RRC Connection Reconfiguration que incluya una indicacion de si se le permite al UE 111 utilizar el factor de escala deseado.

El procesador 610 puede redirigir el UE 111 a un NodoB o eNodoB vecino en la red 100 (FIG. 1) que soporte la utilizacion del valor de busqueda extendido cuando se determina no soportar el valor de busqueda extendido. El procesador 610 puede determinar en primer lugar si el UE 111 es tolerante al retraso antes de realizar esta redireccion. El procesador 610 puede seleccionar un valor de DRX extendido de una lista de valores de DRX extendidos, en funcion del grado hasta el que el UE 111 es tolerante al retraso.

Las instrucciones 635 comprenden uno o mas conjuntos de instrucciones o software ejecutados en un dispositivo (o equipo) informatico para hacer que dicho dispositivo (o equipo) informatico aplique cualquiera de los metodos que se exponen en la presente solicitud. Las instrucciones 635 (tambien denominadas instrucciones ejecutables por un ordenador o equipo) pueden residir, de forma completa o al menos parcial, en el procesador 610 y/o la memoria 620 durante la ejecucion de las mismas por parte del eNodoB 600. El procesador 610 y la memoria 620 tambien comprenden medios legibles por un equipo.

Las tecnicas descritas en la presente solicitud pueden mejorar el consumo de energfa para algunos UE (p.e., los dispositivos tolerantes al retraso tales como los dispositivos MTC) y tambien mantener o mejorar una buena experiencia del usuario para algunos otros UE (p.e., los dispositivos no MTC). Por ejemplo, las tecnicas descritas en la presente solicitud pueden permitir que algunos UE (p.e., los dispositivos MTC) utilicen un valor (p.e., un valor extendido) para la longitud del ciclo de DRX (p.e., basado en uno de los To5 a Tcn) en modo DRX con el fin de conseguir una mayor reduccion del consumo de energfa. Las tecnicas descritas en la presente solicitud tambien pueden permitir que algunos otros UE (p.e., los dispositivos no MTC) utilicen otro valor (p.e., un valor no extendido) para la longitud del ciclo de DRX (p.e., basado en uno de los T01 a Tc4) en modo DRX con el fin de mantener o mejorar una buena experiencia del usuario.

Como aquellos con un conocimiento normal de la tecnica apreciaran facilmente, varios aspectos descritos a lo largo de esta divulgacion se pueden extender a otros sistemas de telecomunicacion, arquitecturas de red y estandares de comunicacion. A tttulo de ejemplo no limitativo se pueden extender varios aspectos a otros sistemas del Sistema Universal de Telecomunicaciones Moviles (UMTS). Varios aspectos se pueden utilizar en sistemas que utilicen la Evolucion a Largo Plazo (LTE) (en FDD, TDD o en ambos modos), y la LTE Avanzada (LTE-A) (en FDD, TDD o en ambos modos).

Claims

REIVINDICACIONES

Un terminal de usuario (111, 112) que comprende:

una circuitena (520) de procesamiento configurada para determinar que se utilice un valor de DRX de busqueda (paging) extendida para aumentar la longitud del ciclo de busqueda a un valor mayor que un primer valor, cuando el terminal de usuario (111, 112) se encuentra operando en una red (100) de acuerdo con un estandar de la familia de estandares del 3GPP para la LTE, y un segundo valor, cuando el terminal de usuario (111, 112) se encuentra operando en una red (100) de acuerdo con un estandar de la familia de estandares UMTS; y una circuitena (540) de capa ffsica configurada para:

transmitirle a la red (100) un mensaje del estrato de no acceso indicando que el terminal de usuario (111, 112) desea utilizar el valor de DRX de busqueda extendida; y

recibir un mensaje de la red (100) que incluye un elemento de informacion que indica si la red (100) soporta el valor de DRX de busqueda extendida;

caracterizada por que

la circuitena (540) de capa ffsica esta configurada para recibir un bloque de informacion del sistema desde un NodoB evolucionado (102) que indica si el NodoB evolucionado soporta DRX extendida en modo inactivo, siendo el bloque de informacion del sistema, SIB, un SIB2 para los sistemas LTE del 3GPP, un SIB1 para los sistemas UMTS del 3GPP, o un SIB de nueva definicion.

El terminal de usuario (111, 112) de la reivindicacion 1, en donde el mensaje NAS es uno de los siguientes: un mensaje Attach Request (solicitud de registro), un mensaje Tracking Area Update Request (solicitud de actualizacion del area de seguimiento) o un mensaje Routing Area Update Request (solicitud de actualizacion del area de encaminamiento), y el valor de busqueda extendida se indica en un elemento de informacion de Parametro de DRX.

El terminal de usuario (111, 112) de la reivindicacion 1, en donde el mensaje NAS es uno de los siguientes: un mensaje Attach Request, un mensaje Tracking Area Update Request o un mensaje Routing Area Update Request, y el valor de busqueda extendida se indica en un Elemento de informacion de Parametro de DRX Extendida.

El terminal de usuario (111, 112) de la reivindicacion 3, en donde la circuitena (540) de capa ffsica esta configurada ademas para recibir un elemento de informacion de Parametro de DRX Extendida en uno de los siguientes: un mensaje Attach Request, un mensaje Tracking Area Update Request o un mensaje Routing Area Update Request

El terminal de usuario (111, 112) de la reivindicacion 1, en donde

la circuitena (520) de procesamiento esta configurada ademas para determinar un factor de escala por el cual multiplicar la longitud del ciclo de busqueda para el terminal de usuario (111, 112), en donde la determinacion se basa en uno o mas de los siguientes: el tipo de dispositivo del terminal de usuario (111, 112) y el tipo de una o mas aplicaciones que se ejecutan en el terminal de usuario (111, 112); y

la circuitena (540) de capa ffsica esta configurada ademas para transmitirle el factor de escala a la red (100) en un elemento de informacion de las Propiedades de Dispositivo.

El terminal de usuario (111, 112) de la reivindicacion 5, en donde el factor de escala se recibe en un mensaje de informacion del sistema.

El terminal de usuario (111, 112) de la reivindicacion 1, en donde

la circuitena (520) de procesamiento esta configurada ademas para determinar un factor de escala por el cual multiplicar la longitud del ciclo de busqueda para el terminal de usuario (111, 112), en donde la determinacion se basa en uno o mas de los siguientes: el tipo de dispositivo del terminal de usuario (111, 112) y el tipo de una o mas aplicaciones que se ejecutan en el terminal del usuario (111, 112); y

la circuitena (540) de capa ffsica esta configurada ademas para transmitirle el factor de escala a la red (100) en un mensaje Attach Request y recibir un mensaje de confirmacion de la red (100) indicando que el terminal del usuario (111, 112) utilizara el factor de escala.

Un metodo, aplicado por un terminal de usuario (111, 112) para ahorrar energfa, comprendiendo dicho metodo: determinar que se utilice un valor de DRX de busqueda extendida para aumentar la longitud del ciclo de busqueda a un valor superior a 256 milisegundos cuando el terminal de usuario (111, 112) esta operando en una red (100) de acuerdo con un estandar de la familia de estandares del 3GPP para LTE, y 512 milisegundos cuando el terminal de usuario (111, 112) esta operando en una red (100) de acuerdo con un estandar de la familia de estandares UMTS;

transmitirle un mensaje del estrato de no acceso a la red (100) indicando que el terminal de usuario (111, 112) desea utilizar el valor de DRX de busqueda extendida; y

recibir un mensaje de la red (100) que incluye un elemento de informacion que indica si la red (100) soporta el valor de DRX de busqueda extendida;

caracterizado por

recibir un bloque de informacion del sistema desde un NodoB evolucionado (102) que indica si el NodoB evolucionado (102) soporta DRX extendida en modo inactivo, siendo el bloque de informacion del sistema, SIB, un SIB2 para los sistemas LTE del 3GPP, un SIB1 para los sistemas ^uM^tS del 3GPP, o un SIB de nueva definicion.

9. El metodo de la reivindicacion 14, en donde el mensaje NAS es uno de los siguientes: un mensaje Attach Request, un mensaje Tracking Area Update Request o un mensaje Routing Area Update Request, y el valor de busqueda extendida se indica en un elemento de informacion de Parametro de DRX.

10. El metodo de la reivindicacion 14, que comprende ademas recibir un elemento de informacion de parametro de DRX Extendida en un mensaje Attach Request, un mensaje Tracking Area Update Request o un mensaje Routing Area Update Request.

11. El metodo de la reivindicacion 14, que comprende, ademas:

determinar un factor de escala por el cual multiplicar la longitud del ciclo de busqueda para el terminal de usuario (111, 112), en donde la determinacion se basa en uno o mas de los siguientes: el tipo de dispositivo del terminal de usuario (111, 112) y el tipo de una o mas aplicaciones que se ejecutan en el terminal de usuario (111, 112); y transmitirle el factor de escala a la red (100) en un elemento de informacion de Propiedades de Dispositivo. 12. El metodo de la reivindicacion 14, que comprende, ademas:

determinar un factor de escala por el cual multiplicar la longitud del ciclo de busqueda para el terminal de usuario (111, 112), en donde la determinacion se basa en uno o mas de los siguientes: el tipo de dispositivo del terminal de usuario (111, 112) y el tipo de una o mas aplicaciones que se ejecutan en el terminal de usuario (111, 112); y transmitir el factor de escala a la red (100) en un mensaje Attach Request; y

recibir un mensaje de confirmacion desde la red (100) indicando que el terminal de usuario (111, 112) utilizara el factor de escala.