La invención se refiere a un procedimiento para control de congestión de recursos luR en una red de comunicaciones móviles de arquitectura plana o eHSPA en una situación de traspaso con continuidad,

teniendo la red una red de transporte, en el que:- un equipo de usuario (10) envía paquetes de datos de enlace ascendente a un eNodo B de servicio (20) y a un número de eNodo B de no servicio (20''),- desde cada eNodo B de no servicio dichos paquetes de datos de enlace ascendente se descodifican y transmiten en enlace ascendente a través de la red de transporte (30) sobre una interfaz luR, y entonces se transmiten junto con los datos de enlace descendente al eNodo de servicio (20);en el que el procedimiento comprende en el eNodo B de servicio:- detectar, mediante el eNodo B de servicio, si hay congestión en cualquiera de las interfaces luR y dónde se localiza la congestión;- enviar una notificación de congestión a uno o más de los eNodos B de no servicio (20''), dependiendo de sobre qué interfaz /interfaces luR se haya detectado la congestión;- detener la descodificación de los paquetes de datos de plano de usuario de enlace ascendente en uno o más de los eNodos B de no servicio, manteniendo activa la descodificación del E-DPCCH.La invención también se refiere a una entidad de red que comprende medios para llevar a cabo el procedimiento anterior

Procedimiento y sistema de control de congestión en eHSPA.

Campo de la invención

La presente invención se enmarca dentro del campo de las telecomunicaciones y, especialmente en las redes de comunicaciones inalámbricas incluyendo las redes de segunda generación (2G) y tercera generación (3G) (es decir, que soportan tecnologías GSM y WCDMA, respectivamente).

Antecedentes de la invención

Tal como se muestra en la figura 1, en la arquitectura 3G clásica (Release 99), los Nodos B 2 están conectados a un controlador de red de radio 3 (RNC, Radio Network Controller) a través de una interfaz IuB; el RNC encamina el tráfico de datos hacia la red de núcleo 4 (Core Network) a través de una interfaz IuPS, y desde ahí los paquetes de datos se suministran hacia el mundo de Internet.

Las interfaces IuB y IuPS son interfaces lógicas mapeadas en una red de transporte compleja formada por encaminadores y enlaces de punto a punto.

En la perspectiva de servicios PS de enlace ascendente, la función principal del RNC es encaminar el tráfico de datos PS a la red de núcleo, así como controlar e implementar funciones como el traspaso con continuidad o suave (SHO, Soft Handover) que tiene el objetivo de mejorar los funcionamientos de radio del sistema WCDMA. El traspaso con continuidad tiene lugar cuando un equipo de usuario (UE) 1 se conecta simultáneamente a dos o más Nodos B.

En traspaso con continuidad, los datos de usuario desde diferentes Nodos B 2 (flujo de datos UL 1, flujo de datos UL 2, flujo de datos UL 3) se combinan en el RNC de servicio para originar un flujo de datos único; este proceso también se denomina combinación de macrodiversidad (Macrodiversity combining). Cuando los Nodos implicados en el SHO pertenecen a diferentes RNC, un único RNC está conectado a la red de núcleo, y se denomina RNC de servicio, mientras que cualquier otro RNC implicado se denomina RNC de desviación (o RNC no de servicio) y está conectado al RNC de servicio a través de una interfaz denominada IuR.

3GPP ha desarrollado una arquitectura alternativa con el propósito de reducir la necesidad de desarrollar más máquinas RNC y más grandes a medida que crece la utilización de datos en el mercado con la introducción de servicios HSDPA (Acceso por Paquetes de Enlace Descendente a Alta Velocidad, High-Speed Downlink Packet Access) y HSUPA (Acceso por Paquetes de Enlace Ascendente a Alta Velocidad, High-Speed Uplink Packet Access). Esto se denomina arquitectura plana (Flat or Collapsed Architecture) (mostrada en la figura 2).

En esta arquitectura plana, muchas funciones RNC se implementan directamente en el Nodo B (denominado eNodo B = Nodo B mejorado). Los eNodos B (que pueden verse como pequeños RNC) están conectados entre sí, a través de interfaces IuR, y la función de traspaso con continuidad puede llevarse a cabo intercambiando datos a través de la IuR como en la arquitectura clásica.

Un reto de esta arquitectura plana es la implementación del traspaso con continuidad en el nivel de transporte.

En HSDPA hay control de potencia, y los paquetes de datos sólo se envían desde uno de los Nodos B, por lo que no hay traspaso con continuidad para el plano de usuario, es decir, los datos hacia un usuario sólo se envían a través de una celda. Pero en HSUPA (Acceso por Paquetes de Enlace Ascendente a Alta Velocidad) se envían paquetes de datos desde todos los Nodos B, por lo que se realiza traspaso con continuidad como se hacía en el Release 99. El problema es que HSUPA proporciona una tasa de transmisión de bits muy alta (hasta 5,7 Mbps en el Release 6 de 3GPP) lo que significa que con unos pocos usuarios, la cantidad de datos que va a transportarse (a través de IuB en arquitectura clásica, y a través de IuR en arquitectura plana) puede ser extremadamente alta.

Cuando se utiliza traspaso con continuidad en el enlace ascendente (véase el caso de arquitectura plana en la figura 2), los datos del equipo de usuario UE 10 tienen que llevarse tanto al eNodo B de servicio 20 como a los eNodos B de no servicio 20' (de desviación). En general, los datos desde el equipo de usuario UE van al eNodo B de servicio y a un número X de eNodos B de no servicio.

Cuando se utiliza traspaso con continuidad en arquitectura plana, los datos del UE van desde los eNodos B de no servicio al eNodo B de servicio a través de la red de transporte -a través de encaminadores (routers) que interconectan todos los nodos- para realizar la combinación de macrodiversidad y entonces desde el eNodo B de servicio a la red de núcleo. Eso significa que cada eNodo B de no servicio lleva el tráfico de datos del equipo de usuario UE una vez en enlace ascendente (flujo de datos UL 1, flujo de datos UL 2), y el eNodo B de servicio lleva en la interfaz de transporte, para los mismos datos de enlace ascendente del equipo de usuario UE, X veces los mismos datos en enlace descendente (flujo de datos UL 1, flujo de datos UL 2) y una vez en enlace ascendente (flujo de datos UL 3, que es una combinación de los X Nodos B de no servicio y el Nodo B de servicio). Por lo tanto, los datos de enlace ascendente del equipo de usuario UE tienen que llevarse sobre el transporte 2X+1 veces en la red de acceso (siendo X el número de eNodos B de no servicio), afectando a la capacidad de transporte del enlace descendente y el enlace ascendente.

Si se utiliza SHO con HSUPA (también denominado E-DCH=Enlace Ascendente de Canal Dedicado Mejorado, Enhanced Dedicated Physical Control Channel), implica un volumen significativo de datos, y la duplicación de los datos creados por la arquitectura plana puede crear una congestión que no sucedería con la arquitectura clásica.

Para evitar esta congestión en la red de acceso, se han propuesto soluciones estáticas, es decir, para permitir la posibilidad de evitar la utilización del traspaso con continuidad para el plano de usuario para ciertos servicios de alta tasa de transmisión de datos o ciertas aplicaciones o usuarios de Calidad de Servicios. Sin embargo, esto no es eficaz porque en el caso de redes de acceso no congestionadas, el traspaso con continuidad proporciona mejor rendimiento de usuario y mejor capacidad de interfaz de radio.

La solicitud de patente estadounidense US 2008/0293235 describe un procedimiento de control de congestión para un sistema de comunicación inalámbrico. El procedimiento descrito en este documento pretende hacer frente a la congestión reduciendo el traspaso con continuidad actuando en la búsqueda de tamaño de ventana de los vecinos. Pretende resolver una congestión de interfaz de radio, no un problema de congestión en el plano de transporte. Además, el procedimiento dado a conocer evita el traspaso con continuidad con un cambio de parámetros y no se refiere a la arquitectura plana.

Descripción de la invención

La invención se refiere a un procedimiento para control de congestión en una red de comunicaciones móviles de arquitectura plana o eHSPA en situación de traspaso con continuidad según la reivindicación 1, y a una entidad de red de una red de comunicaciones móviles de arquitectura plana según la reivindicación 9. En las reivindicaciones dependientes se definen realizaciones preferidas del procedimiento y de la entidad de red.

Los inconvenientes descritos en la sección anterior pueden mitigarse en gran medida según la presente invención, por medio de un procedimiento que comprueba dinámicamente la situación de congestión y toma acciones en el proceso de traspaso con continuidad.

Según el procedimiento de la presente invención, el traspaso con continuidad de plano de usuario siempre está activo, también se mantienen el manejo de control de potencia típico de traspaso con continuidad, es decir, se mantiene la descodificación de E-DPCCH (Canal de Control Físico Dedicado Mejorado), pero la descodificación de los datos de plano de usuario (E-DPDCH) en el eNodo B de no servicio se detiene en caso de problemas de congestión en la parte de transporte (es decir, en la parte IuR).

Como consecuencia, se reduce la ocupación en la red de transporte de acceso; cuando no existe la situación de congestión, entonces se reanuda la descodificación de los datos.

La presente invención se refiere a un procedimiento para control de congestión de recursos IuR en una red de comunicaciones móviles de arquitectura plana o eHSPA en una situación de traspaso...

1. Procedimiento de control de congestión de recursos IuR en una red de comunicaciones móviles de arquitectura plana en una situación de traspaso con continuidad, teniendo la red una red de transporte, en el que:

- un equipo de usuario (10) envía paquetes de datos de enlace ascendente a un eNodo B de servicio (20) y a un número de eNodos B no de servicio (20'),

- desde cada eNodo B de no servicio dichos paquetes de datos de enlace ascendente se descodifican y transmiten en enlace ascendente a través de la red de transporte (30) sobre una interfaz IuR, y entonces se transmiten junto con los datos de enlace descendente al eNodo de servicio (20);

en el que el procedimiento comprende en el eNodo B de servicio:

- detectar si hay congestión en cualquiera de las interfaces IuR y dónde se localiza la congestión;

- enviar una notificación de congestión a uno o más de los eNodos B de no servicio (20'), dependiendo de sobre qué interfaz o interfaces IuR se haya detectado la congestión;

- detener la descodificación de los paquetes de datos de plano de usuario de enlace ascendente en uno o más de los eNodos B de no servicio,

- mantener activa la descodificación del Canal de Datos Físico Dedicado Mejorado, E-DPCCH.

2. Procedimiento según la reivindicación 1, que comprende además

reanudar la descodificación de plano de usuario cuando la congestión sobre dichas interfaces IuR ha acabado.

3. Procedimiento según cualquiera de las reivindicaciones 1-2, en el que la etapa de enviar una notificación de congestión comprende:

si se detecta congestión en los paquetes de datos de equipo de usuario procedentes de todos los eNodos B de no servicio, enviar una primera notificación de congestión a todos los eNodos B de no servicio, lo que detiene la descodificación de los paquetes de datos de equipo de usuario cuyo tráfico es manejado mediante el eNodo B citado como eNodo B de servicio en la primera notificación de congestión.

4. Procedimiento según cualquiera de las reivindicaciones 1-3, en el que la etapa de enviar una notificación de congestión comprende:

si solamente se detecta congestión en los paquetes de datos de equipo de usuario procedentes de uno o más eNodos B de no servicio, pero no en todos, enviar una segunda notificación de congestión a dichos eNodos B de no servicio, lo que detiene la descodificación de los paquetes de datos de equipo de usuario cuyo tráfico es manejado mediante el eNodo B citado como eNodo B de servicio en la segunda notificación de congestión.

5. Procedimiento según cualquier reivindicación anterior, en el que la detención de la descodificación de dichos paquetes de datos de enlace ascendente se lleva a cabo para todos los equipos de usuario al mismo tiempo.

6. Procedimiento según cualquiera de las reivindicaciones 1-4, en el que la detención de la descodificación de dichos paquetes de datos de enlace ascendente se lleva a cabo para equipos de usuario con tráfico de prioridad baja, y si la congestión persiste, se detiene la decodificación de datos de los usuarios de la prioridad siguiente.

7. Procedimiento según cualquier reivindicación anterior, en el que la congestión se detecta mediante tramas perdidas o retardadas en los paquetes de datos.

8. Procedimiento según cualquier reivindicación anterior, en el que la notificación de congestión tiene un formato indicado en 3GPP 25.423 y 25.425.

9. Entidad de red de una red de comunicaciones móviles de arquitectura plana en una situación de traspaso con continuidad, que comprende:

- un detector para detectar si hay congestión en cualquiera de las interfaces IuR de la red de transporte y dónde se localiza la congestión;

- un notificador para enviar una notificación de congestión a uno o más de una pluralidad de eNodos B de no servicio (20'), dependiendo de sobre qué interfaz o interfaces IuR se haya detectado la congestión; y

- un procesador configurado para detener la descodificación de los paquetes de datos de plano de usuario de enlace ascendente en uno o más de los eNodos B de no servicio, y configurado para mantener activa la descodificación del Canal de Datos Físico Dedicado Mejorado, E-DPCCH.

10. Entidad de red según la reivindicación 9, en la que el procesador además está configurado para reanudar la descodificación en el plano de usuario cuando la congestión sobre dichas interfaces IuR ha acabado.

11. Entidad de red según cualquiera de las reivindicaciones 9-10, en la que en respuesta a que se detecte congestión en los paquetes de datos de equipo de usuario procedentes de todos los eNodos B de no servicio, el notificador puede estar configurado para enviar una primera notificación de congestión a todos los eNodos B de no servicio, que detienen la descodificación de paquetes de datos de equipo de usuario cuyo tráfico es manejado por el eNodo B citado como eNodo B de servicio en la primera notificación de congestión.

12. Entidad de red según cualquiera de las reivindicaciones 9-10, en la que en respuesta a que se detecte congestión únicamente en los paquetes de datos de equipo de usuario procedentes de uno o más de los eNodos B de no servicio, pero no en todos ellos, el notificador puede estar configurado para enviar una segunda notificación de congestión a dichos uno o más eNodos B de no servicio, que detienen la descodificación de paquetes de datos de equipo de usuario cuyo tráfico es manejado por el eNodo B citado como eNodo B de servicio en la segunda notificación de congestión.

13. Entidad de red según cualquiera de las reivindicaciones 9-12, en la que detención de la descodificación de dichos paquetes de datos de enlace ascendente se lleva a cabo para todos los equipos de usuario al mismo tiempo.

14. Entidad de red según cualquiera de las reivindicaciones 9-12, en la que detención de la descodificación de dichos paquetes de datos de enlace ascendente se lleva a cabo para equipos de usuario con tráfico de prioridad baja, y si la congestión persiste, se detiene la descodificación de datos de los usuarios de la siguiente prioridad.

15. Entidad de red según cualquiera de las reivindicaciones 9-14, en la que la congestión preferiblemente se detecta mediante tramas perdidas o retardadas en los paquetes de datos.