ES2744309T3 - Gestión de recursos de comunicación - Google Patents

Abstract

Procedimiento de gestión de recursos de comunicación dentro de una red celular, comprendiendo el procedimiento las etapas de: determinar, por parte de un controlador, uno o más grupos de equipo de usuario, UEs (10), dentro de una celda proporcionada por una estación (20) base que participan en una llamada de grupo de servicio de difusión y multidifusión multimedia, MBMS, en un modo de operación de multidifusión a ser migrados a un modo de operación de unidifusión en base a la información que indica la carga de la estación (20) base que incluye información que indica la utilización de uno o más recursos (100) MBMS, mediante la determinación de que la utilización de uno o más recursos de MBMS está por encima de un primer umbral (120) y, si está por encima del primer umbral (120), entonces realizar la migración de uno o más grupos de UEs (10) a la operación de unidifusión, en el que la información que indica la carga de la estación (20) base está incluida en un informe de carga que incluye una lista identidades temporales de grupo móvil (TMGI) para las cuales se están transmitiendo los datos; y enviar un mensaje que indica que los uno o más grupos de UEs (10) determinados deben migrar al modo de operación de unidifusión.

Description

DESCRIPCIÓN

Gestión de recursos de comunicación

Campo de la invención

La presente invención se refiere a un procedimiento y a un sistema para la gestión de recursos de comunicación y, en particular, a la gestión de la congestión en redes de telecomunicaciones.

Antecedentes de la invención

LTE está siendo desarrollado por 3GPP para poder gestionar servicios de misión crítica para las operaciones de seguridad pública. Uno de los nuevos tipos de servicio que debe gestionarse es la capacidad para comunicaciones de grupo (y, en particular, grupos Push to Talk) para ser operados usando redes LTE. La comunicación Push To Talk tiene baja actividad por naturaleza, por lo tanto, con el fin de maximizar la eficiencia de los recursos de radio LTE, puede usarse una multiplexación estadística de múltiples llamadas de grupo para reducir la reserva total de recursos de radio requeridos para gestionar el tráfico de llamadas de grupo, lo que a su vez permite al operador liberar la capacidad de banda ancha para sus clientes y otros servicios. Además, se requiere que las comunicaciones de llamada de grupo sean fiables. Por ejemplo, la policía y los bomberos deben ser capaces de comunicarse con un alto nivel de fiabilidad.

Además de esto, el que la naturaleza de las llamadas de grupo sea punto-a-multipunto (Point-To-Multipoint, PTM) significa que múltiples terminales del mismo "grupo de conversación" recibirían los mismos datos desde la misma fuente (datos procedentes de otro terminal en el mismo grupo de conversación). Una característica denominada servicio de difusión y multidifusión multimedia evolucionado (eMBMS) dentro de LTE permite que una única ráfaga de datos sea asignada al recurso de radio y sea transmitida una vez en una forma de difusión, de manera que la misma señal transmitida (que contiene los datos) pueda ser recibida simultáneamente por múltiples terminales de recepción en la dirección de enlace descendente, con el fin de optimizar adicionalmente los recursos de radio usados.

Otra optimización de eMBMS es que múltiples eNode Bs contiguos desplegados (desplegados para proporcionar un área de cobertura contigua) pueden ser sincronizados en el tiempo, y las señales físicas eMBMS pueden ser transmitidas o alineadas en cada eNode B de manera que un terminal pueda recibir la misma señal desde múltiples eNode Bs casi simultáneamente. Este enfoque se denomina red de frecuencia única (Single Frequency Network, SFN). El enfoque SFN evita la interferencia en el terminal receptor y aumenta la relación señal a ruido (Signal-to-Noise, SNR) del canal físico eMBMS recibido. El área sobre la cual se envía simultáneamente la misma señal desde varios eNode Bs se denomina área MBSFN. Con el fin de garantizar que todos los eNode MBSFN Bs en un área puedan coordinarse apropiadamente, hay un nodo lógico que controla todos ellos, denominado MCE.

Teniendo en cuenta que la utilidad del uso de eMBMS depende de una serie de terminales, la totalidad de los cuales desean recibir los mismos datos al mismo tiempo, un procedimiento permite que el MCE y eNodoB "cuenten" el número de usuarios interesados en el servicio, y este procedimiento puede ser realizado periódicamente. Si hay un número insuficiente de terminales interesados en comparación con el recurso de radio empleado en el uso del recurso de radio eMBMS, entonces, los usuarios pueden cambiarse a la operación "unidifusión", usando un canal (punto-a-punto) dedicado para cada terminal individualmente dentro de una celda. Sin embargo, el proceso de asignación no es un proceso muy dinámico, y existe un cierto retardo en la asignación de llamadas de grupo a las señales físicas MBMS para recepción MBMS y la conmutación de las mismas de vuelta a canales dedicados para una operación de unidifusión. El control de esto es realizado actualmente por un canal de control (en la capa de protocolo "RRC") que es enviado desde el MCE cada cinco segundos a todos los terminales que reciben la señal física MBMS.

Por lo tanto, el uso de una señal física eMBMS transmitida en forma SFN desde múltiples eNode Bs en un área MBSFN es una característica importante para la gestión de llamadas de grupo. Sin embargo, debido a que los recursos de MBMS no pueden ser reservados con una granularidad muy fina dentro de una celda y al hecho de que el nivel de los recursos MBMS reservados en la celda no puede adaptarse muy rápidamente, múltiples llamadas de grupo deben ser capaces de ser multiplexadas y asignadas a la misma señal física eMBMS con el objetivo de usar el recurso reservado tan eficazmente como sea posible. Además, teniendo en cuenta el factor de baja actividad de las llamadas de grupo y la falta de dinamismo en la asignación y la des-asignación de llamadas de grupo a/desde MBMS, esto conduce a una necesidad de depender en gran medida de una multiplexación estadística para estimar los recursos de radio MBMS totales requeridos.

Además, no existe el equivalente de una operación eMBMS en dirección de enlace ascendente, las llamadas de grupo de transmisión de datos de voz o vídeo tendrían que usar el canal (punto a punto) dedicado en el enlace descendente, incluso si están recibiendo datos de voz o de vídeo a través de las señales físicas eMBMS en el enlace descendente.

El siguiente texto se extrae de 3GPP TS23.468 y TS36.440 3GPP para una descripción adicional de la arquitectura eMBMS para una operación de llamada de grupo.

La Figura 1 (Figura 4.2.2-1 de 3GPP TS23.468) muestra un modelo de arquitectura no itinerante para GCSE_LTE.

La Figura 2 (Figura 4-1 de 3GPP TS23.468) muestra una arquitectura simplificada para MBMS en LTE/SAE. Consiste en entidades EPC funcionales y nodos E-UTRAN. Las funciones de las entidades EPC MBMS se definen en TS 23.246. Las funciones de los nodos MBMS E-UTRAN se definen en TS 36.300. Cabe señalar que TS 36.300 permite también el despliegue de MCE dentro de un eNodo B.

La Figura 2 muestra las interfaces relacionadas con E-UTRAN (es decir, M1, M2 y M3). Para MBMS, la señalización de control y el paquete de datos del plano de usuario se distribuyen desde la EPC a E-UTRAN a través de diferentes interfaces.

Interfaces del plano de control:

Las interfaces M3, M2 son interfaces del plano de control puras.

M3 entre MME y MCE transporta principalmente la señalización de gestión de sesión MBMS.

Un MCE está conectado a uno o más de un eNodo Bs (eNBs) dentro de la misma MBSFN a través de la interfaz M2 principalmente para la señalización de gestión de sesión MBMS y la señalización de configuración de radio.

Interfaz del plano de usuario:

La interfaz M1 es una interfaz de plano de usuario pura.

Un MBMS GW está conectado a múltiples eNBs través de la interfaz M1 para la distribución de datos.

Los puntos de referencia dentro de EPC no están incluidos en el alcance de este documento. Consúltese TS 23.246 para más detalles.

Típicamente, se asignan múltiples grupos de conversación a los recursos MBMS en la dirección de enlace descendente y existe la posibilidad de que, en un momento determinado, el tráfico generado por los grupos de conversación activos asignados al recurso MBMS podría exceder la capacidad de ese recurso. Esto es debido a la falta de dinamismo para adaptar los recursos MBMS reservados en la celda, y a la falta de dinamismo en la conmutación de terminales entre la operación de unidifusión y MBMS en la celda, y a la falta de previsibilidad y precisión de la multiplexación estadística, y a la necesidad de que los operadores LTE intenten usar su espectro asignado de manera eficiente. Si no hay otras "unidades" de recursos MBMS disponibles, esto podría conducir a que los datos para uno o más "grupos de conversación" sean descartados por el eNodo B antes de la transmisión a través de la interfaz de radio, incumpliendo de esta manera las necesidades del servicio.

A pesar de que MBMS está destinado principalmente para los grupos de conversación con número de usuarios/terminales medio a alto dentro de la celda o área MBSFN, típicamente, los niveles de tráfico generados por estos grupos pueden no ser suficientes para "llenar" el recurso MBMS reservado en la celda, y la falta de granularidad de las unidades de recursos MBMS reservadas significa que parte de la capacidad de la celda podría ser desperdicia. Por lo tanto, un mecanismo de gestión de recursos de radio (Radio Resource Management, RRM) razonable debería usar los recursos reservados de manera más eficaz. Para permitir esto, los grupos de conversación con bajo número de usuarios en la celda y/o el área MBSFN deberían estar configurados también para usar los recursos de MBMS que han sido reservados, incluso aunque estos grupos puedan ser gestionados también mediante una operación de unidifusión. Estos grupos de conversación estarían contribuyendo también a la carga de tráfico en el recurso de MBMS.

El documento US 2012/0263089 describe la determinación de si un nivel de demanda de contenido excede un umbral definido y el inicio de una sesión de multidifusión para el contenido.

El documento US 2007/0177592 describe la determinación de si un número de umbral de los dispositivos móviles en un área de servicio inalámbrico están participando en una llamada de grupo y si el número de umbral están participando en la llamada de grupo, designando el dispositivo móvil para recibir una transmisión multidifusión.

El documento WO 2013/182247 describe la iniciación de una conmutación desde sesiones de unidifusión a un servicio de difusión/multidifusión multimedia.

El documento US 2013/0024582 describe la detección, durante el acceso de una secuencia de unidifusión, de una instrucción para conmutar a una secuencia de multidifusión.

Por lo tanto, se requiere un procedimiento y un sistema que mejoren la gestión de la red y la utilización de los recursos de comunicación.

Sumario de la invención

Las estaciones base individuales pueden proporcionar una o más celdas a una red de comunicaciones. Un controlador coordina o gestiona las celdas dentro de la red. Grupos de equipos de usuario (UE) pueden estar implicados con una o más llamadas de grupo. Estos grupos pueden ser llamadas de grupo de multidifusión en las que los mismos datos son enviados a cada UE como una difusión. De manera alternativa, puede usarse una transmisión de punto-a-punto ("operación unidifusión"). El controlador determina si los grupos particulares usarán multidifusión o unidifusión para sus llamadas de grupo. Parte o la totalidad de esta determinación se basa en una indicación de carga de cada estación base proporcionada al controlador. El controlador puede determinar si migrar o no grupos de multidifusión a unidifusión. A continuación, el controlador emite una instrucción o envía un mensaje que resulta en la migración de uno o más grupos de UEs a unidifusión.

Aunque opcionalmente el controlador coordina o gestiona las celdas dentro de la red, en algunas realizaciones, el controlador puede estar situado en, y dedicado a, una estación base particular. El controlador puede recibir información directamente desde y relacionada con esa estación base. De esta manera, el controlador puede determinar para la estación base determinada si grupos particulares de UEs usarán multidifusión o unidifusión para las llamadas de grupo, en base a la carga en esa estación base.

En algunas realizaciones, una estación base particular o una o más estaciones base dentro de la red pueden proporcionar más información al controlador. Esta información adicional puede incluir datos acerca del número de UEs o acerca de qué UEs particulares están dentro de cada celda o qué grupos tienen una transferencia de datos en curso y/o la velocidad de datos de la transferencia de datos, por ejemplo. El mensaje o comando emitido por el controlador que indica qué grupos particulares de UEs deberían migrar a unidifusión puede estar en la forma de un comando para suspender o interrumpir una llamada de grupo, por ejemplo. Los UEs pueden interpretar dicha suspensión de su llamada como una sugerencia o instrucción para reiniciar la llamada de grupo en operación unidifusión. Mensajes alternativos pueden evitar la suspensión o interrupción de la llamada o proporcionar otro mecanismo para la migración de los grupos desde multidifusión a unidifusión.

El controlador puede usar también la información proporcionada por la estación base para migrar grupos desde unidifusión a multidifusión. Esta decisión puede basarse también en la información que indica la carga de las estaciones base individuales y/u otra información acerca del uso de la celda proporcionada por las estaciones base. Esto puede conseguirse mediante el uso de un canal de control para emitir instrucciones a intervalos.

Los siguientes escenarios ilustran cómo puede mejorarse la gestión del sistema cuando se encuentran ciertas condiciones de red.

Escenario 1: Durante ocasiones en las que los niveles de tráfico exceden la capacidad del recurso MBMS configurado, la primera etapa de cualquier mecanismo de RRM puede ser conmutar los grupos de conversación en el área MBMFN con un bajo número de usuarios/terminales de nuevo a la operación de unidifusión hasta el momento en el que el los niveles de tráfico generados por el tráfico asignado al recurso de MBMS se reduzcan de nuevo.

Escenario 2: En algunos casos, los recursos MBMS pueden ser usados también por terminales no configurados para recibir datos a través de canales MBMS, pero esto sólo puede hacerse si una unidad de recursos MBMS configurada no es usada en absoluto para la transmisión MBMS. Por lo tanto, en este tipo de configuración, también sería útil que el mecanismo de RRM conmute los grupos con pocos miembros (por ejemplo, por debajo de un número predeterminado) en el área MBSFN a unidifusión una vez que la primera unidad de recursos MBMS configurada empieza a ser usada, con el fin de que no se desborde parcialmente a la segunda unidad de recursos MBMS (previniendo que sea usada para "otros" terminales).

Sin embargo, actualmente no hay manera de usar características MBMS estándar para garantizar que los grupos de conversación con un bajo número de usuarios sean descargados a unidifusión cuando se producen situaciones con escenarios 1 y 2, mientras se mantienen los niveles de fiabilidad del servicio.

Según un primer aspecto, se proporciona un procedimiento de gestión de recursos de comunicación dentro de una red celular, tal como se describe en la reivindicación 1.

Esto permite que los recursos sean gestionados de manera más eficaz, ya que un controlador (por ejemplo, una entidad de coordinación multicelda) tiene más información para su uso para determinar cómo se están utilizando los recursos. Opcionalmente, puede tomarse una decisión acerca de si migrar cualquier grupo de UEs o no migran ninguno en absoluto. Esta decisión puede basarse en la información que indica la carga de la estación base. Por ejemplo, esta información puede ser la carga actual de la estación base (por ejemplo, 85%). A continuación, la entidad que toma la decisión (por ejemplo, un servidor, controlador o MCE) puede comparar esta carga real con un umbral u otros criterios (o si no puede realizar un cálculo) y decidir conmutar grupos de UEs de manera correspondiente. En otras realizaciones, la información puede ser una indicación de que se ha excedido un umbral de carga. Tras dicho evento, la conmutación entre modos de operación puede producirse siempre y, de esta manera, es posible que no se necesite ninguna decisión explícita. Sin embargo, seguirá siendo necesaria una determinación de qué grupos migrar para optimizar la operación.

La determinación de qué grupos de UEs conmutar puede basarse en la identidad de la estación base de origen u otra información, por ejemplo.

Preferiblemente, la información que indica la carga de una estación base puede ser recibida desde una o más estaciones base. En un ejemplo preferido, la información que indica la carga de una estación base puede ser recibida desde múltiples estaciones base. Por ejemplo, la información puede ser enviada o recibida desde una cualquiera una o más estaciones base externas o eNodo.

El mensaje que indica que uno o más grupos de UEs deben conmutar el modo puede adoptar muchas formas diferentes. El mensaje puede ir directamente a los UEs (por ejemplo, desde un controlador) o puede ser enviado a través de la estación base (por ejemplo, el MCE puede instruir a la estación base a suspender grupos o portadoras particulares. Esta instrucción puede incluir una marca de tiempo de cuándo enviar esta información a los UEs de manera que esta pueda ser coordinada a través de más de una estación base. La instrucción puede incluir información que suspende portadoras o grupos particulares y que indica para cada grupo si debe pasar a unidifusión). A continuación, los UEs individuales (o grupos de UEs) pueden solicitar un cambio de modo. Esto puede ser a través de la estación base, el controlador u otra entidad (por ejemplo, un servidor de aplicaciones), por ejemplo.

Opcionalmente, el primer modo de operación puede ser multidifusión y el segundo modo de operación puede ser unidifusión. El primer modo puede ser unidifusión y el segundo modo puede ser multidifusión en algunas realizaciones. El controlador puede mover los UEs en ambos sentidos, por ejemplo. El movimiento de los grupos desde multidifusión a unidifusión tiene ventajas particulares.

Opcionalmente, el mensaje que indica (por ejemplo, a la estación base) que los uno o más grupos de UEs determinados pueden ser migrados al modo de operación de unidifusión es un cese, suspensión o interrupción de la llamada de grupo o terminación de la llamada de grupo multidifusión. La llamada de grupo actual puede continuar, pero usando unidifusión. Esto tiene varias ventajas. Cuando los recursos son bajos, entonces algunas llamadas de grupo pueden fallar, pero los UEs pueden necesitar ser informados. Los usuarios pueden no saber que ya no están recibiendo información (por ejemplo, los servicios de emergencia pueden estar esperando un comando, pero no saben que la llamada de grupo ha fallado). La terminación de la llamada de manera activa significa que la estación base puede entonces proporcionar a los UEs información de que la llamada ya no está en curso. A continuación, pueden iniciar una nueva llamada o reanudar el servicio a través del modo de unidifusión. El mecanismo existente para informar a los UEs sería mediante la eliminación del ID de la llamada de grupo desde el canal de control eMBMS (por ejemplo, cada 5 segundos). Sin embargo, un nuevo mensaje/mecanismo para el envío de información a todos los UEs afectados significa que este puede ser más rápido que mediante el uso del mecanismo existente (por ejemplo, más rápido que cada cinco segundos). Por lo tanto, una nueva llamada o una reanudación del servicio, en modo unidifusión pueden iniciarse más rápido, lo que significa una menor interrupción del servicio.

Opcionalmente, el procedimiento puede comprender además las etapas de:

la recepción por parte de los UEs dentro de los uno o más grupos de UEs del mensaje para migrar al modo de operación de unidifusión; y

en respuesta al mensaje recibido, la emisión de una solicitud a un servidor de aplicaciones para migrar al modo de operación de unidifusión. El servidor de aplicaciones (o servidor de aplicaciones de llamada de grupo) puede estar separado del controlador.

Preferiblemente, la estación base puede ser un eNodoB dentro de una red de evolución a largo plazo (Long Term Evolution, LTE). Pueden usarse otros tipos de red.

Preferiblemente, los grupos de UEs pueden participar en una llamada de grupo de servicio de difusión y multidifusión multimedia, MBMS. Pueden usarse otros tipos de llamada. Las llamadas de grupo pueden incluir voz, datos, Push-to-talk u otros tipos.

Opcionalmente, la estación base puede proporcionar múltiples celdas.

Opcionalmente, la información recibida desde la estación base (por ejemplo, en el controlador o MCE) puede ser un informe de carga y puede incluir además el número de UEs por celda.

Preferiblemente, la información que indica la carga de la estación base puede ser una indicación de que se ha alcanzado un umbral de carga. Esto puede ser provocado, por ejemplo. El umbral puede estar predeterminado.

De manera ventajosa, la información que indica la carga de la estación base puede incluir además información que indica la utilización de uno o más recursos MBMS. El recurso MBMS puede ser un recurso reservado de multidifusión.

Preferiblemente, cuando el primer modo de operación es multidifusión y el segundo modo de operación es unidifusión, la etapa de determinación de los uno o más grupos de UEs que participan en una llamada de grupo a ser migrada al modo de operación de unidifusión puede comprender además la etapa de determinar que la utilización de los uno o más recursos MBMS está por encima de un primer umbral y, si está por encima del primer umbral, entonces realizar la migración de los uno o más grupos de UEs a la operación de unidifusión. En otras realizaciones la migración puede invertirse cuando la carga se ha reducido a un valor inferior al primer umbral (u otro umbral).

Opcionalmente, cuando los UEs dentro de los uno o más grupos de UEs han migrado al modo de unidifusión, son capaces de usar un recurso MBMS configurado para multidifusión cuando no hay UEs en modo multidifusión que estén usando ese recurso MBMS. En otras palabras, parte o la totalidad de los UEs (por ejemplo, terminales) pueden tener la capacidad de usar un recurso de multidifusión MBMS incluso para llamadas unidifusión. Sin embargo, esta capacidad puede ser restringida a la condición de que no haya UEs en operación de multidifusión que estén usando el mismo recurso MBMS al mismo tiempo. Bajo ciertas circunstancias, puede ser ventajoso migrar un número relativamente bajo de UEs de multidifusión (o grupos) desde un recurso MBMS para liberarlo para uso unidifusión por dichos terminales a pesar de que esos grupos pueden ser más adecuados para la operación de multidifusión (puede haber un mayor número de UEs en el grupo, por ejemplo). Por ejemplo, si la estación base (o eNodo B) indica al controlador (MCE) que todos los UEs de este grupo están cerca de la estación base (por ejemplo, en base al conocimiento de la pérdida de ruta o los niveles de RSRP recibidos desde cada UE en la celda), entonces podría ser posible que el MCE para decidiera empujar este grupo a unidifusión.

Opcionalmente, el primer modo de operación es unidifusión y el segundo modo de operación es multidifusión y la etapa de determinación de los uno o más grupos de UEs que participan en una llamada de grupo a ser migrada al modo de operación de multidifusión puede comprender además la etapa de determinar que la utilización de los uno o más recursos MBMS está por encima de un segundo umbral y, si está por encima del segundo umbral, entonces realizar la migración de los uno o más grupos de UEs a la operación de multidifusión. Por lo tanto, el sistema puede ser optimizado para "llenar" un recurso MBMS con grupos de UEs que ordinariamente no se beneficiarían de la multidifusión (que pueden consistir en unos pocos UEs, por ejemplo). Debido a que el recurso MBMS ya se usa parcialmente para multidifusión, entonces esto excluye su uso por UEs de unidifusión, que de otro modo tienen que usar otros recursos de redes móviles. Esta realización mejora la utilización de los recursos de MBMS en la operación de multidifusión, mientras que libera otros recursos de red. En otras realizaciones, la migración puede invertirse cuando la carga se ha reducido a un valor inferior al segundo umbral (u otro umbral).

Opcionalmente, el primer modo de operación puede ser multidifusión y el segundo modo de operación puede ser unidifusión y el mensaje que indica que los uno o más grupos de UEs determinados deben migrar al modo de operación de unidifusión puede ser enviado a través de un canal punto-a-multipunto, mediante un mensaje de control de acceso al medio (Media Access Control, MAC), señalización MAC o elemento de control MAC, o mediante un paquete de solicitud de envío en el canal de datos eMBMS. El mensaje puede ser enviado como un comando directo, o puede ser enviado como un comando indirecto, por ejemplo, indicando que la transmisión de datos MBMS se interrumpe o se suspende. El mensaje puede ser enviado por la estación base a cada UE, por ejemplo. De manera alternativa, puede ser enviado por medio de punto-a-punto a cada UE, por ejemplo, a nivel de aplicación (paquete de aplicación), un nuevo registro de paginación o un nuevo campo de información enviado en el canal de control dedicado de enlace descendente (PDCCH en LTE), por ejemplo. Este mensaje puede ser enviado mediante la inclusión de la instrucción para cambiar el modo (o simplemente indicando que la transmisión se ha interrumpido), junto con el ID de grupo de la llamada de grupo (o una referencia al ID de grupo de la llamada de grupo). A continuación, los UEs en ese grupo pueden solicitar el uso del modo de operación de unidifusión. Opcionalmente, cuando el mensaje es un mensaje MAC, elemento de control MAC o señal MAC, el mensaje puede ser un mensaje MAC de información de planificación multidifusión (Muticast Scheduling Information, MSI) LTE.

Usando un elemento de control MAC, por ejemplo, un mensaje MAC MSI (u otro enfoque de señalización punto-amultipunto), puede significar que el MCE puede necesitar coordinar cuándo se envía el mismo entre diferentes estaciones base. Esto puede requerir el envío de información desde el MCE a las estaciones base que indica la información de marca de tiempo de cuándo debería ser enviada esta información a los UE desde cada estación base. Con el fin de ayudar al MCE en la generación de una marca de tiempo correcta (para cuando enviar el mensaje de multidifusión a los UEs), el MCE puede unirse al grupo de distribución de datos en el plano de usuario de multidifusión IP con el fin de recibir los paquetes SYNC, que son enviados también a los eNodo Bs (los paquetes SYNC transmiten información relacionada con el tiempo a los eNodos Bs).

De manera ventajosa, el mensaje MAC o mensaje MAC MSI puede comprender dos entradas que relacionadas con cada uno o más grupos de UEs y además en el que la primera entrada puede indicar que hay datos planificados para el grupo (por ejemplo, TMGI) dentro de un período de planificación y la segunda entrada puede indicar que una portadora (por ejemplo, portadora PTM) para el grupo está suspendida desde el final del período de planificación. La suspensión de la portadora puede indicar también que los usuarios deben migrar a unidifusión.

De manera ventajosa, el mensaje MAC o mensaje MAC MSI puede comprender dos entradas relacionadas con cada uno o más de los grupos de UEs. La primera entrada puede indicar que hay datos planificados para el grupo dentro de un período de planificación y la segunda entrada puede indicar que los UEs deben ser conmutados a unidifusión. En otras palabras, la primera entrada puede describir los datos o la carga útil y la segunda entrada puede indicar que los UEs en un grupo particular deben migrar o conmutar a unidifusión desde multidifusión. Esta segunda entrada puede ser un comando directo para conmutar o puede ser un indicador o un comando indirecto que es interpretado como tal. Por ejemplo, la segunda entrada puede ser un comando alternativo para hacer alguna otra cosa o comunicar alguna otra cosa, pero que puede ser interpretado por los UEs como una solicitud de conmutación. Los UEs individuales dentro del grupo particular destinado a conmutar a unidifusión pueden solicitar que se produzca la conmutación (por ejemplo, a la red celular) y/o la red causará que se produzca la conmutación o migración.

El UE o grupos de UEs pueden recibir información o instrucciones de que van a ser conmutados o migrados a unidifusión (o que se les solicitará que lo hagan). Sin embargo, el UE puede seguir escuchando o puede mantener la comunicación con el canal MBMS mientras que el UE está en proceso (migrando). Debido a que la adquisición de los datos vía unidifusión puede ser no instantánea, de manera beneficiosa, mientras tanto, el eNodo B puede continuar enviando datos en el canal MBMS, para permitir que la comunicación "se realice antes de la interrupción" evitando de esta manera una interrupción del servicio durante la conmutación. En otras palabras, la operación de unidifusión puede establecerse antes de que la transmisión de datos MBMS sea interrumpida o suspendida. Por lo tanto, puede introducirse un retardo entre el momento en el que el UE recibe instrucciones o información para pasar a unidifusión y el momento en el que el eNodo B detiene la transmisión de datos MBMS.

Opcionalmente, la segunda entrada puede indicar que una portadora para el grupo está suspendida o que la transferencia de datos sobre la portadora está interrumpida. Este es un ejemplo de un mensaje indirecto para que se lleve a cabo la migración. En otras palabras, hay una indicación, comando o mensaje para hacer algo distinto a la migración específica, pero que puede ser interpretado como una instrucción o una indicación de que va a producirse una migración desde multidifusión a unidifusión. La conmutación o migración desde multidifusión a unidifusión puede estar acoplada a, vinculada a o ser dependiente (o independiente) de la suspensión de la portadora.

Preferiblemente, la portadora para el grupo puede ser suspendido después de un período de tiempo. En otras palabras, después de recibir una indicación de que la portadora será suspendida o interrumpida, los UEs pueden permanecer durante un período de tiempo en el modo multidifusión, mientras que al mismo tiempo intentan migrar a unidifusión. Esto puede dar a los UEs una oportunidad de migrar a unidifusión sin perder conectividad. El comando puede ser interpretado como una indicación de que la portadora será suspendida en el futuro (por ejemplo, en 80 ms, 800 ms, 1 s, 5 s, o en cualquier momento intermedio), después de un retardo predeterminado, después de un número predeterminado de períodos de planificación (por ejemplo, de 1 a 10) o después de un tiempo o un número de períodos de planificación especificados en la entrada del mensaje MAC MSI, por ejemplo. Por lo tanto, la entrada del mensaje MAC MSI puede indicar que sólo puede dependerse de la portadora durante un cierto período de tiempo (en el que el período de tiempo está predeterminado o se notifica en el mensaje).

Preferiblemente, la red celular puede suspender la portadora para el grupo. En otras palabras, la red celular puede ser la entidad que causa que la migración desde multidifusión a unidifusión tenga lugar con o sin una solicitud desde los UEs individuales.

Opcionalmente, el procedimiento puede comprender además que la base reciba desde la estación base información que indica el número de UEs dentro de cada uno o más grupos de UEs.

De manera ventajosa, el número puede ser indicado por cada célula de la estación base.

De manera ventajosa, el número puede ser usado para determinar si migrar o no los uno o más grupos de UEs al segundo modo de operación.

Opcionalmente, el procedimiento puede comprender además la etapa de enviar un indicador de tiempo para la sincronización de la migración al segundo modo de operación. El controlador o MCE pueden enviar el indicador de tiempo, por ejemplo.

Opcionalmente, el indicador de tiempo puede ser generado uniéndose a un grupo de distribución de datos en el plano de usuario de multidifusión IP con el fin de recibir paquetes SYNC que son enviados también a la estación base. El controlador o MCE puede generar el indicador de tiempo, por ejemplo.

Según un segundo aspecto, se proporciona un sistema, tal como se describe en la reivindicación 13.

Opcionalmente, el sistema comprende múltiples estaciones base.

Preferiblemente, el sistema puede comprender además un servidor de aplicaciones configurado para recibir solicitudes desde los UEs a ser migrados al segundo modo de operación. Por lo tanto, el servidor de aplicaciones de llamada de grupo puede administrar las configuraciones de llamadas de grupo separadas del controlador.

Preferiblemente, el primer modo de operación puede ser multidifusión y el segundo modo de operación puede ser unidifusión. Sin embargo, los modos pueden migrar a la inversa, es decir, el primer modo de funcionamiento puede ser de unidifusión y el segundo modo de operación puede ser de multidifusión.

Los procedimientos descritos anteriormente pueden ser implementados como un programa de ordenador que comprende instrucciones de programa para operar un ordenador. El programa de ordenador puede estar almacenado en un medio legible por ordenador.

El sistema de ordenador puede incluir un procesador, tal como una unidad central de procesamiento (Central Processing Unit, CPU). El procesador puede ejecutar una lógica en la forma de un programa de software. El sistema de ordenador puede incluir una memoria que incluye medios de almacenamiento volátiles y no volátiles. Puede incluirse un medio legible por ordenador para almacenar la lógica o las instrucciones de programa. Las diferentes partes del sistema pueden estar conectadas usando una red (por ejemplo, redes inalámbricas y redes cableadas). El sistema de ordenador puede incluir una o más interfaces. El sistema informático puede contener un sistema operativo adecuado, tal como UNIX, Windows (RTM) o Linux, por ejemplo.

Cabe señalar que cualquier característica descrita anteriormente puede ser usada con cualquier aspecto o realización particular de la invención.

Breve descripción de las figuras

La presente invención puede ser llevada a la práctica en una serie de maneras y a continuación se describirán realizaciones a modo de ejemplo solamente y con referencia a los dibujos adjuntos, en los que:

La Fig. 1 muestra un diagrama esquemático de una arquitectura LTE de la técnica anterior;

La Fig. 2 muestra un diagrama esquemático adicional de una arquitectura LTE de la técnica anterior;

La Fig. 3 muestra un diagrama esquemático de un sistema y de un flujo de señalización de un procedimiento para la gestión de los recursos de comunicación dentro de una red celular, proporcionado solo a modo de ejemplo;

La Fig. 4 muestra un diagrama esquemático de un mensaje de control dentro de un sistema de planificación;

La Fig. 5 muestra un diagrama esquemático que ilustra la utilización de los recursos con la red celular; y

La Fig. 6 muestra un diagrama esquemático adicional que ilustra la utilización de los recursos con la red celular.

Cabe señalar que las figuras se ilustran en aras de la simplicidad y no están necesariamente dibujadas a escala. Las características similares reciben los mismos números de referencia.

Descripción detallada de las realizaciones preferidas

La Figura 3 muestra un ejemplo de arquitectura y de flujo de señalización. Los UEs 10 dentro de una llamada de grupo pueden solicitar el uso de un modo de operación de unidifusión mediante la señalización a un servidor 40 de aplicaciones de llamada de grupo. La estación base o eNodo B (eNB) 20 puede ser uno de entre muchos eNBs dentro de la red y da servicio a muchos UEs 10 tanto para llamadas de grupo como para otros propósitos. El eNB 20 proporciona una indicación de su carga al controlador o entidad 30 de coordinación multicelda (Multicell Coordination Entity, MCE). Esto puede ser a intervalos regulares o puede ser desencadenado por ciertas cargas o eventos. Esta podría estar por encima de un porcentaje predeterminado (por ejemplo, 80%). Este informe de carga podría proporcionar, también o en su lugar, una indicación de la utilización de diversos recursos, incluidos los recursos MBMS. Puede incluirse otra información en este informe de carga, incluyendo una lista de las identidades temporales de grupo móvil (Temporary Mobile Group Identities, TMGI) para las que se están transmitiendo datos y los UEs incluidos en dichos grupos y/o el número de UEs dentro de cada celda proporcionado por la estación 20 base.

Por lo tanto, el controlador 30 puede ser capaz de determinar información acerca de los grupos que tienen un bajo número de UEs en los mismos y en qué modo están operando en (multidifusión o unidifusión).

El controlador 30 puede migrar las llamadas de grupo a y desde la operación de unidifusión y multidifusión. Hay varios mecanismos para hacerlo (directa e indirectamente). En una realización, el controlador 30 puede terminar una llamada de grupo. Esto puede ser interpretado por los UEs 10 en esos grupos para restablecer la comunicación en modo de unidifusión mediante la solicitud del mismo desde el servidor 40 de aplicaciones. La migración de un grupo desde la operación de unidifusión a la operación de multidifusión puede realizarse de forma convencional usando el planificador de MCCH (es decir, añadiendo la TMGI a la información de planificación). Lo que no es convencional es el uso de la información de carga proporcionada por la estación base para tomar esta decisión.

Diversos componentes, mejoras o realizaciones adicionales pueden usarse aisladamente o en cualquier combinación.

Componente 1: la estación 20 base (eNB) informa de la situación de carga (o del hecho de que ha habido un fallo de sincronización del plano de usuario en el eNodo B, o del hecho de que el hardware eMBMS en el eNodo B ha fallado) al controlador (MCE) 30 junto con los grupos (TMGIs) activos. El MCE 30 toma la decisión acerca de conmutar a unidifusión por cada TMGI de grupo de llamada: De manera adicional o alternativa, la estación 20 base puede informar cuando se producen escenarios particulares (por ejemplo, los escenarios 1 o 2 descritos a continuación). La información que pueda ser comunicada al MCE desde el eNodo B puede incluir:

- La carga ha pasado un umbral (que puede estar basado en un umbral señalado por el MCE 30 o preconfigurado por el operador) y desearía algunas portadoras MBMS para dejar de usar el recurso MBMS. La información comunicada puede indicar "utilización subtrama MBMSFN actual para el canal eMBMS físico" (es decir, el escenario 2 descrito a continuación), y "sobrecarga en el canal eMBMS físico" para ajustarse más al escenario 1 descrito a continuación).

- La carga se ha reducido por debajo de un umbral (que puede volver a usar la información de "utilización de subtrama MBMSFN actual para el canal de eMBMS físico” anterior para indicar que la sobrecarga ya ha terminado.

- La sincronización del plano de usuario eMBMS ha fallado.

- Los recursos de hardware que operan eMBMS han fallado.

- El servicio o los IDs de grupo (TMGIs) para los cuales se está generando tráfico.

Componente 2: el MCE 30 que usa los informes de recuento desde el UE 10 a través del eNB 20 para optimizar la decisión de descarga a unidifusión (pero necesita el ID de celda en el M2 "resultados de recuento" desde el eNodo B: El procedimiento de recuento actual puede usarse tal como se especifica en 3GPP TS36.331/TS36.443 para realizar un recuento de cuántos usuarios están interesados en cada servicio. Sin embargo, en la actualidad, la especificación no permite que el MCE conozca esta información a nivel de cada celda, solo a nivel de cada eNode B). En esta realización, el eNodo B 20 indica al MCE 30 en informes de recuento el "número de usuarios" por cada "celda" para cada TMGI para el que se solicita el recuento. Otra información comunicada puede ser una "indicación de si todos los UEs en el grupo de conversación dentro de la célula se encuentran dentro de un pequeño rango de la estación base". Esta información adicional puede permitir al MCE conocer si este grupo puede ser gestionado de manera eficiente mediante unidifusión a pesar de que hay un número de usuarios en el grupo en la celda).

Componente 3: Manera para ponerse en contacto con los terminales de manera más frecuente que el periodo de notificación MCCH para indicarles que pasen a unidifusión (de manera que no tengan hasta cinco segundos de interrupción del servicio): Todas las soluciones indicadas a continuación permitirían una comunicación más rápida con el terminal, de manera que no tendría una interrupción de cinco segundos antes de que sepa que tiene que cambiar a la operación de unidifusión. Aquí, la optimización puede reducir la interrupción del servicio y puede mejorar la fiabilidad y la continuidad del servicio para los terminales que conmutan desde MBMS a la operación de unidifusión. Cabe señalar que, cuando el servicio es conmutado de nuevo desde unidifusión a MBMS, puede suponerse que la conmutación ocurre cerca del punto en el que se transmite el MCCH.

- Enfoques de unidifusión: Tras la instrucción desde el MCE 30 de que una portadora MBMS será suspendida o interrumpida, el eNodo B 20 señaliza a los terminales 10 afectados de manera individual para informarles de esta situación y, en algunos ejemplos, también que deben desencadenar la operación de unidifusión. El eNB 30 tendría que realizar un seguimiento (a través del "procedimiento de recuento de RRC MBMS") de qué terminal está interesado en qué servicio MBMS, de manera que sepa con qué terminales contactar. A continuación, se proporcionan mecanismos ejemplares detallados:

° Enfoque paquete de solicitud: el eNodo B señaliza un paquete de nivel de aplicación para cada terminal afectado individualmente. El paquete de solicitud es pre-almacenado en el eNodo B.

° Enfoque de paginación: Se usa un nuevo registro de búsqueda/paginación para informar a los terminales afectados individualmente.

° Señalización de canal de control: Se usa el canal de control de enlace descendente para informar a los terminales afectados individualmente.

- Enfoques de difusión: Tras la instrucción desde el MCE de que una portadora MBMS será suspendida o interrumpida, el eNodo B señaliza a los terminales afectados usando los canales MBMS para informarles de esta situación de manera colectiva y, posiblemente, también de que deben desencadenar la operación de unidifusión. El MCE debería proporcionar alguna información nueva, tal como "información de sello de tiempo" al eNodo B 20, de manera que cada eNodo B 20 sepa cuándo enviar esta información a los UEs 10. Esto es necesario para garantizar que todo los eNodo Bs en el área MBSFN envíen la información al mismo tiempo, de manera que la operación SFN se mantenga.

° Paquete de solicitud enviado en el canal de datos MBMS a los terminales: Al igual que para el enfoque unidifusión, el paquete es almacenado previamente en el eNodo B y es enviado cuando sea necesario. Sin embargo, el tráfico generado puede aumentar en un punto de tiempo en el que el eNode B 20 está intentando reducir la carga de tráfico MBMS.

° Información proporcionada en la información de planificación eMBMS (proporcionada en la capa MAC) al inicio de cada período de planificación MBMS mediante un mensaje MAC o un elemento de control MAC, de manera ventajosa, un elemento de control MAC de información de planificación MCH.

En un ejemplo particular, el elemento de Control MAC de información de planificación MCH ilustrado en la Figura 4 se identifica por una sub-cabecera MAC PDU con LCID. Este elemento de control tiene un tamaño variable. Para cada MTCH, se incluyen los siguientes campos:

- LCID: este campo indica el ID de canal lógico del MTCH. La longitud del campo es de 5 bits;

- Stop MTCH: Este campo indica el número ordinal de la subtrama dentro del período de planificación MCH, contando sólo las subtramas asignadas al MCH, donde se detiene el MTCH correspondiente. El valor 0 corresponde a la primera subtrama. La longitud del campo es de 11 bits. El valor especial de Stop MTCH 2047 indica que el MTCH correspondiente no está planificado. El intervalo de valores 2043-2046 está reservado.

Uno de los puntos de código reservados (por ejemplo, 2046) puede ser usado para indicar el hecho de que "el servicio MBMS particular está suspendido/interrumpido" y, posiblemente, que "el móvil/los móviles o UE o UEs 10 deberían intentar una operación de unidifusión para este servicio". Esta información puede estar combinada con el "ID de portadora" (LCID en la Figura 4).

El uso del punto de código de repuesto requeriría que no se envíen datos MBMS para este mismo servicio dentro del período de planificación.

Puede ser útil colocar esta señalización de par de información "LCID: Stop MTCH” con el nuevo punto de código usado en la última posición de la lista de pares "LCID: Stop MTCH" dentro del elemento de información de planificación MCH. La razón es que los terminales antiguos (que deberían ignorar los puntos de código reservados si los reciben) usan la información "stop MTCH” del LCID señalizado anteriormente para saber cuándo empiezan los datos para el LCID siguiente, pero si no entienden el significado de punto de código nuevo, entonces pueden interpretar erróneamente dónde empiezan los datos para el LCID siguiente. Además, podría haber también dos instancias del par "LCID: stopMTCH" para el mismo valor LCID en el mensaje MSI. Esto permitiría que la primera instancia indicara que hay datos planificados para este TMGI dentro del período de planificación. La segunda instancia indicaría que, desde el final de este período de planificación, la portadora TMGI para este PTM se suspende (y posiblemente que los usuarios deberían intentar pasar a la operación de unidifusión). Esto tiene una ventaja sobre una única instancia, ya que el envío de un valor stopMTCH de (por ejemplo) "portador suspendido (y posiblemente pasar a unidifusión)", en este mismo mensaje MSI puede ser difícil o imposible que incluya también una indicación de que hay datos de usuario planificados en el MTCH para este UE (ya que los valores "stopMTCH" heredados se usan para verificar donde están los datos).

La Figura 5 muestra esquemáticamente dos recursos 100, 200 de MBMS. Pueden establecerse o predeterminarse un umbral 110 bajo y un umbral 120 alto. El umbral 120 alto puede ser simplemente cuando el recurso está lleno o utilizado al 100%. En la Figura 5, este umbral se muestra con una utilización menor del 100%. El área sombreada en la Figura 5 indica la utilización y, por lo tanto, se muestra que el primer recurso 100 excede el umbral 120 alto. La utilización de los recursos de MBMS es notificada al controlador 30 en el informe de carga junto con la información global de carga de recursos.

Por lo tanto, la Figura 5 muestra que los niveles de tráfico se acercan o exceden la capacidad del recurso 100 de MBMS. En esta situación, el controlador 30 determinará grupos de UEs conmutar a la operación de unidifusión con el fin de evitar pasar al segundo recurso 200 de MBMS (si está disponible) o encontrarse con una interrupción del servicio. Típicamente, se tratará de aquellos grupos con un número reducido de usuarios o terminales. Incluso cuando el recurso 200 está disponible y libre, entonces puede ser ventajoso para evitar su uso en absoluto (es decir, el desbordamiento desde el recurso 100), ya que esto significaría que ya no está disponible para los UEs que pueden usar los recursos de multidifusión (tales como el recurso 200 de MBMS), para una comunicación unidifusión. Los grupos de UEs pueden ser migrados de nuevo a multidifusión cuando la utilización cae por debajo del umbral 120 o según otros criterios.

La Figura 6 ilustra una situación en la que el recurso 100 se utiliza plenamente y el recurso 200 es utilizado parcialmente por grupos de multidifusión. Un umbral 210 adicional se ilustra en la Figura 6. Tal como se ha descrito con referencia a la Figura 5, una opción es migrar los grupos de multidifusión usando el recurso 200 al modo de unidifusión para liberar este recurso 200. Sin embargo, cuando hay un número significativo de grupos que llenan parcialmente el recurso (por ejemplo, en particular el umbral 210), entonces el uso excesivo del modo de unidifusión puede degradar él mismo el rendimiento de la estación base o la red de comunicaciones en su conjunto. Por lo tanto, puede producirse una optimización moviendo grupos de unidifusión al modo de multidifusión incluso cuando el número de miembros del grupo pueda ser bajo (que no optimizaría la red si se realizara de manera aislada). Esto aumenta o llena la utilización del recurso 200 (que si no podría estar infrautilizado) y, por lo tanto, puede liberar otros recursos de la estación base para el uso general de llamadas no de grupo.

Tal como apreciará la persona con conocimientos en la materia, los detalles de la realización anterior pueden variarse sin apartarse del alcance de la presente invención, tal como se define en las reivindicaciones adjuntas.

Por ejemplo, las realizaciones de la invención se han descrito con referencia a LTE, pero pueden usarse otros tipos de red. Las llamadas de grupo pueden ser llamadas de voz u otros datos.

En un ejemplo adicional, un controlador puede estar basado en una estación base particular. Opcionalmente, el controlador es un controlador dedicado para esa estación base. La información de la estación base es recibida por el controlador, y el controlador determina si uno o más grupos de los UEs en la comunicación con la estación base deberían migrar desde un primer modo de operación a un segundo modo de operación (por ejemplo, desde la operación de multidifusión a la operación de unidifusión). Esta determinación puede basarse en la información o datos asociados con la estación base, tales como la carga de la estación base. La determinación para la estación base determinada puede tener lugar en base a una serie de reglas preconfiguradas, sin contacto con otro nodo o estación base.

Muchas combinaciones, modificaciones o alteraciones en las características de las realizaciones anteriores serán evidentes para la persona con conocimientos en la materia y se pretende que formen parte de la invención. Cualquiera de las características descritas relacionadas específicamente con una realización o ejemplo puede ser usada en cualquier otra realización realizando los cambios apropiados.

Claims (14)

REIVINDICACIONES

1. Procedimiento de gestión de recursos de comunicación dentro de una red celular, comprendiendo el procedimiento las etapas de:

determinar, por parte de un controlador, uno o más grupos de equipo de usuario, UEs (10), dentro de una celda proporcionada por una estación (20) base que participan en una llamada de grupo de servicio de difusión y multidifusión multimedia, MBMS, en un modo de operación de multidifusión a ser migrados a un modo de operación de unidifusión en base a la información que indica la carga de la estación (20) base que incluye información que indica la utilización de uno o más recursos (100) MBMS, mediante la determinación de que la utilización de uno o más recursos de MBMS está por encima de un primer umbral (120) y, si está por encima del primer umbral (120), entonces realizar la migración de uno o más grupos de UEs (10) a la operación de unidifusión, en el que la información que indica la carga de la estación (20) base está incluida en un informe de carga que incluye una lista identidades temporales de grupo móvil (TMGI) para las cuales se están transmitiendo los datos; y

enviar un mensaje que indica que los uno o más grupos de UEs (10) determinados deben migrar al modo de operación de unidifusión.

2. Procedimiento según la reivindicación 1, en el que el mensaje que indica que los uno o más grupos UEs (10) determinados deben migrar al modo de operación de unidifusión es un cese de la llamada de grupo.

3. Procedimiento según cualquier reivindicación anterior que comprende además las etapas de:

la recepción por parte de los UEs (10) dentro de los uno o más grupos de UEs (10) del mensaje para migrar al modo de operación de unidifusión; y

en respuesta al mensaje recibido, la emisión de una solicitud a un servidor (40) de aplicaciones para migrar al modo de operación de unidifusión.

4. Procedimiento según cualquiera de las reivindicaciones anteriores, en el que la estación (20) base proporciona múltiples celdas.

5. Procedimiento según la reivindicación 1, en el que los UEs (10) dentro de los uno o más grupos de UEs (10) migrados al modo unidifusión son capaces de usar un recurso (100) MBMS configurado para multidifusión cuando ningún UE (10) en modo multidifusión está usando ese recurso (100) MBMS.

6. Procedimiento según cualquiera de las reivindicaciones anteriores, en el que el mensaje que indica que los uno o más grupos de UEs (10) determinados deben migrar al modo de operación de unidifusión es enviado por un elemento de control LTE MAC.

7. Procedimiento según la reivindicación 6, en el que el elemento de control MAC indica además que una portadora para el grupo se suspende o que la transmisión se interrumpe.

8. Procedimiento según cualquiera de las reivindicaciones anteriores que comprende además recibir información que indica el número de UEs (10) dentro de cada uno o más grupos de UEs (10).

9. Procedimiento según la reivindicación 8, en el que el número se indica para cada célula de la estación (20) base.

10. Procedimiento según la reivindicación 8 o la reivindicación 9, en el que el número se usa para determinar la migración de los uno o más grupos de UEs (10) al modo de operación de unidifusión.

11. Procedimiento según cualquiera de las reivindicaciones anteriores que comprende además la etapa de enviar un indicador de tiempo para la sincronización de la migración al modo de operación de unidifusión.

12. Procedimiento según la reivindicación 11, en el que el indicador de tiempo es generado uniéndose a un grupo de distribución de datos en el plano de usuario de multidifusión IP con el fin de recibir paquetes SYNC que son enviados también a la estación (20) base.

13. Sistema que comprende:

una o más estaciones (20) base; y un controlador configurado para:

recibir información que indica la carga de una estación (20) base de las una o más estaciones (20) base, indicando la información de la utilización de uno o más recursos (100) de servicio de difusión y multidifusión multimedia, MBMS;

determinar uno o más grupos de equipos de usuario dentro de una celda proporcionada por una estación (20) base, UEs (10), que participan en una llamada de grupo en un modo de operación de multidifusión a ser migrados a un modo de operación de unidifusión en base a la información que indica la carga de la estación (20) base de las una o más estaciones base, mediante la determinación de que la utilización de uno o más recursos de MBMS está por encima de un primer umbral (120) y, si está por encima del primer umbral (120), entonces realizar la migración de uno o más grupos de UEs (10) a la operación de unidifusión, en el que la información que indica la carga de la estación (20) base está incluida en un informe de carga que incluye una lista identidades temporales de grupo móvil (TMGI) para las cuales se están transmitiendo los datos; y

enviar un mensaje que indica que los uno o más grupos de UEs (10) determinados deben migrar al modo de operación de unidifusión.

14. Sistema según la reivindicación 13, que comprende además un servidor (40) de aplicaciones configurado para recibir solicitudes desde los UEs (10) a ser migrados al modo de operación de unidifusión.