ES2376060T3

ES2376060T3 - Control de congestión dentro de una red de acceso radio.

Info

Publication number: ES2376060T3
Application number: ES04791186T
Authority: ES
Inventors: Mats SÅGFORS; Paul Teder; Tarmo Kuningas
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2004-10-08
Filing date: 2004-10-08
Publication date: 2012-03-08
Anticipated expiration: 2024-10-08
Also published as: US9232430B2; HK1106355A1; JP2008516486A; US20080084822A1; EP1797676B1; CN101040491A; JP4643650B2; CN101040491B; WO2006037378A1; US20150215807A1; EP1797676A1; ATE536684T1; PL1797676T3

Abstract

Un método de control del volumen de tráfico del plano de usuario en la interfaz Iub o Iub/Iur entre un Controlador de Red Radio y un Nodo B de una Red de Acceso Radio UMTS durante los periodos de sobrecarga, el método que comprende, para las conexiones de enlace ascendente y del enlace descendente individuales establecidas sobre la interfaz Iub o Iub/Iur, monitorizar en el Controlador de Red Radio la llegada tardía de tramas que transportan datos del plano de usuario en el Controlador de Red Radio o en el Nodo B transmitidos sobre la interfaz Iub o Iub/Iur, y en base a los resultados de dicha monitorización, provocar una reducción en la carga Iub o Iub/Iur para una conexión cuando sea apropiado, caracterizado porque el paso de monitorizar la llegada tardía de tramas comprende analizar los resultados proporcionados por una entidad de Protocolo de Trama que incluye, para la dirección de enlace descendente, derivar dichos resultados contando el número de tramas de Ajuste de Temporización recibidas en el Controlador de Red Radio desde el NodoB y, para la dirección del enlace ascendente, derivar dichos resultados directamente contando el número de tramas basadas en llegada tardía en el Controlador de Red Radio, y comparar el valor de cuenta con algún valor umbral.

Description

Control de congestión dentro de una red de acceso radio

Campo de la invención

La presente invención se refiere a un mecanismo para el control de congestión dentro de una red de acceso radio de un sistema de telecomunicaciones. Más concretamente, la invención se refiere a un mecanismo de control de congestión para la interfaz Iub o Iub/Iur de una Red de Acceso Radio de UMTS.

Antecedentes a la invención

El grupo del Proyecto de Cooperación de Tercera Generación, conocido como 3GPP, está implicado en el trabajo de estandarización en curso en el grupo WCDMA de protocolos conocido como Sistema Universal de Telecomunicaciones Móviles (UMTS) o 3G. Una red de operador UMTS se puede separar en una serie de componentes principales, a saber una o más redes centrales las cuales son responsables de las sesiones de usuario de establecimiento y control, y una Red de Acceso Radio UMTS (UTRAN) que controla el acceso a la interfaz aérea. La arquitectura de una UTRAN se ilustra esquemáticamente en la Figura 1. La interfaz entre la UTRAN y el equipo de usuario (UE) se proporciona por los nodos conocidos como “NodosB” (análogos a las Estaciones Base en las redes 2G/GSM). Los NodosB son responsables de transmitir y recibir datos sobre la interfaz aérea y se controlan por los Controladores de Red Radio (RNC). Los datos de usuario y control se encaminan entre los UE y una red central a través de los NodosB y los RNC. La interfaz entre un NodoB y un RNC se conoce como la interfaz Iub.

Hay situaciones en las que los mismos datos se pueden transmitir entre un UE dado y un RNC a través de dos o más NodosB. Esto se conoce como Función de Traspaso de Diversidad (DHO) o macro-diversidad. Los NodosB se pueden controlar por el mismo o distintos RNC. En este último caso, los datos se encaminan al RNC de control (o de servicio) a través de un RNC de deriva. La interfaz entre el RNC de servicio y el de deriva se conoce como la interfaz Iur. Ambos escenarios se ilustran en la Figura 1.

Los protocolos responsables de transportar la carga útil entre un RNC y un NodoB se describen en la TS 25.435 y la TS 25.427 del 3GPP para los canales comunes (es decir compartidos) y dedicados respectivamente. Las capas de protocolo presentes en el RNC y el NodoB se muestran en la Figura 2. De particular relevancia aquí son los Protocolos de Trama (indicados FP en la Figura 2), que son responsables de transportar los datos del plano de usuario ofrecidos por las capas superiores (MAC/RLC) entre el NodoB y el RNC. La TS 25.402 (v5.3.0) del 3GPP tiene que ver con la sincronización sobre las interfaces Iub/Iur.

La red de transporte (TN) por debajo del Protocolo de Trama se puede realizar o bien como una red ATM de celdas conmutadas, o bien como una red IP basada en paquetes. El planteamiento típico para asegurar que la red de transporte entrega la calidad de servicio requerida es aplicar algún tipo de mecanismo de control de admisión de la red de transporte, que permita nuevas conexiones en tanto en cuanto hay capacidad disponible. Esta estrategia funciona bien para las conexiones cuya carga ofrecida y propiedades estadísticas son bien conocidas y comprendidas, por ejemplo la voz. La carga agregada de tales conexiones se puede estimar fácil y precisamente. Si la carga estimada excede la capacidad de la red de transporte, no se admiten conexiones adicionales. De esta manera, se puede asegurar que todas las conexiones activas reciben la calidad de servicio de red de transporte esperada sin gastar recursos con un mecanismo de admisión demasiado conservador.

El control de reserva y admisión de la red de transporte es mucho más difícil cuando se consideran conexiones de datos de paquetes conmutados (PS), por una serie de razones:

•: La carga presentada por unos canales de PS puede ser mucho más alta que para una conexión de voz: hasta 384 kbps y más sobre un Canal Dedicado (DCH), y del orden de Mbps sobre un Canal Compartido de Enlace Descendente de Alta Velocidad (HS-DSCH).

•: El patrón de tráfico sobre los portadores de PS muestra un grado de variación mucho más alto que para las conexiones de voz, que tienen largos periodos de inactividad seguidos por grandes ráfagas de datos.

•: Las propiedades estadísticas del tráfico de PS no son ni muy bien comprendidas ni capturadas por cualquier modelo simple. La carga puede ser una función compleja de la calidad del enlace, precio, segmento de cliente, hora del día/año, etc.

Cuando se usa un procedimiento de admisión de red de transporte para el tráfico de PS, se pueden adoptar dos planteamientos diferentes:

Admisión prudente: Para asegurar que la red de transporte siempre entrega el rendimiento deseado, las conexiones entrantes se bloquean en niveles de reserva moderados. La desventaja es la probabilidad del bloqueo innecesario de conexiones entrantes en momentos cuando las conexiones admitidas presentan baja actividad. Esta solución conduce a baja utilización de los recursos de la red de transporte y conexiones bloqueadas.

Admisión generosa: Para evitar el bloqueo innecesario, se admiten más usuarios de PS que se podrían servir momentáneamente si todas las conexiones se volvieran activas (la suposición que es que no todos los usuarios elegirán simultáneamente enviar o recibir datos). La desventaja es el aumento de la probabilidad de sobrecarga de la red de transporte en los momentos cuando demasiadas conexiones ofrecen carga.

Típicamente, el primero de estos planteamientos se usa, lo que significa que solamente unas pocas conexiones de PS de, digamos 384 kbps, se pueden admitir en cualquier momento dado. Esto es particularmente verdadero si se realiza la Iub con enlaces E1 o T1 poco densos.

Sería deseable admitir más conexiones de PS (para evitar el bloqueo) y tener algún método para manejar las condiciones de sobrecarga Iub potenciales. Hay dos problemas en la implementación de tales soluciones. En primer lugar, no hay ningún mecanismo para detectar explícitamente la congestión en la interfaz Iub de una forma por conexión. En segundo lugar, los protocolos Iub implicados son insensibles a la congestión Iub. Esto significa que la entidad de FP suministrará siempre a la red de transporte con la carga ofrecida por las entidades MAC/RLC, independientemente de la sobrecarga potencial sobre la interfaz Iub. La técnica existente en el control de carga de Iub (por ejemplo Saraydar y otros: “Impacto del control de tasa en la capacidad de un enlace Iub: Caso de servicio múltiple”, Actas del WCNC 2003) emplea soluciones centralizadas basadas en algún algoritmo de control de congestión. La EP 1331768 y la US 2003223454 también proponen soluciones centralizadas al problema del control de carga Iub.

El problema se puede ilustrar además asumiendo una estrategia de admisión generosa en que se han admitido varios portadores de 384 kbps sobre una realización Iub poco densa. Cuando varios/todos los portadores pasan a ofrecer tráfico simultáneamente, el resultado probablemente va a retrasar o perder tramas Iub para algunas o todas las conexiones. Dado que los portadores de PS se realizan típicamente con el Modo de Reconocimiento (AM), las entidades RLC de recepción requerirán retransmisiones del contenido de la trama perdido. Esto significa que la sobrecarga puede persistir, ya que los casos del FP continuarán barajando datos sobre el Iub en tanto en cuanto el MAC/RLC de envío los ofrezca. En un escenario del peor caso, ninguna conexión recibe ningún dato a tiempo y todos los datos perdidos van a los almacenadores temporales de retransmisión de RLC de envío. Las entidades RLC/MAC/FP entonces seguirán ofreciendo datos de sobrecarga al Iub sin ningún alivio hasta que sucedan errores de protocolo y las retransmisiones se abandonen con inserciones.

El documento XP 0863924 revela un método de control del volumen del tráfico en un enlace durante los periodos de sobrecarga en los que la llegada tardía de paquetes se monitoriza para detectar la congestión en el enlace y como resultado de detectar una situación de congestión, se provoca una reducción en la carga de la conexión.

Resumen de la invención

Una solución al problema de sobrecarga descrito anteriormente es crear un método para reducir delicadamente la carga Iub en los momentos de sobrecarga. Se propone un mecanismo que busca aliviar la congestión Iub usando un planteamiento descentralizado en base a las mediciones locales recibidas desde la interfaz Iub. Se consideran varios medios para controlar la congestión usando tanto los métodos existentes como nuevos para responder a la congestión Iub detectada. Esto aplica igualmente a escenarios en que la sobrecarga ocurre sobre la interfaz Iub/Iur combinada.

El primer síntoma de la sobrecarga Iub (o Iub/Iur) es el retardo en la llegada de las tramas en la entidad de FP de recepción. Para la dirección del enlace descendente (es decir del RNC al NodoB), el FP define un mecanismo basado en ventana por el cual se monitoriza la llegada de las tramas. Este mecanismo se ilustra en la Figura 2 y es necesario asegurar que las tramas se pueden transmitir a tiempo sobre el aire (para soportar macro-diversidad). En caso de que se reciba una trama en la región “Tardía” o “Demasiado Tardía”, el NodoB responde mediante el envío de una trama de Ajuste de Temporización (TA) al RNC, que indica que la trama era (casi) demasiado tardía para enviar sobre el aire. El propósito primario de esta trama de TA es supervisar el control del desplazamiento de la temporización en el RNC, dado que diferentes etapas Iub del esquema de macro-diversidad pueden tener distintos retardos. En la dirección del enlace ascendente (es decir del NodoB al RNC), se puede implementar un mecanismo basado en ventana similar, con el RNC que tiene acceso directo a los datos de temporización (es decir en la dirección del enlace ascendente no hay necesidad del envío de las tramas de TA).

Es un objeto de la presente invención utilizar los mecanismos basados en ventanas para detectar la llegada tardía de las tramas sobre la interfaz Iub, para proporcionar una indicación temprana de la congestión Iub. Este planteamiento es aplicable tanto para las direcciones del enlace ascendente como del enlace descendente, y permite que la congestión sea detectada de una forma por conexión. Este es en contraste con los planteamientos centralizados conocidos, que proporcionan solamente soluciones centralizadas para el control de congestión de la interfaz Iub.

De acuerdo con un primer aspecto de la presente invención se proporciona un método de control del volumen de tráfico del plano de usuario en la interfaz Iub o Iub/Iur entre un Controlador de Red de Radio y un Nodo B de una Red de Acceso Radio del UMTS durante los periodos de sobrecarga, el método que comprende, para conexiones de enlace ascendente y enlace descendente individuales establecidas sobre la interfaz Iub o Iub/Iur, monitorizar en el Controlador de Red Radio la llegada tardía de tramas que transportan datos del plano de usuario en el Controlador de Red Radio o en el Nodo B transmitidos sobre la interfaz Iub, y en base a los resultados de dicha monitorización provocar una reducción en la carga de Iub para una conexión cuando sea apropiado,

caracterizado porque

5 el paso de monitorización de la llegada tardía de tramas comprende analizar los resultados proporcionados por una entidad de Protocolo de Trama que incluye, para la dirección del enlace descendente, derivar dichos resultados contando el número de tramas de Ajuste de Temporización recibidas en el Controlador de Red Radio desde el NodoB y, para la dirección del enlace ascendente, derivar dichos resultados directamente contando el número de tramas basadas en llegada tardía en el Controlador de Red Radio, y comparar el valor de la cuenta con algún valor umbral.

La invención es aplicable en particular a las conexiones de paquetes conmutados (PS) establecidas sobre la interfaz Iub. Las realizaciones de la invención reducen la probabilidad de bloqueo de conexión, dado que es posible permitir más portadores de PS sobre Iub en cualquier momento dado. El aumento de probabilidad de la congestión Iub se maneja entonces de tal manera que disminuye delicadamente la carga en los momentos de congestión. Los

15 beneficios incluyen:

Utilización de recursos Iub más alta – costes de despliegue de red más bajos,

Probabilidad de bloqueo de conexión más baja – satisfacción del cliente más alta,

Manejo de la congestión delicada con menor impacto en la percepción del usuario – satisfacción del cliente más alta.

Adicionalmente, el método propuesto aquí emplea control de carga descentralizado, en que el control de carga de una conexión es independiente de cualquier otra conexión que utiliza el enlace Iub. Esto hace el mecanismo propuesto mucho más simple y fácil de desplegar.

El método propuesto aquí usa las mediciones de congestión Iub, en lugar de la técnica anterior que generalmente depende de un método en que la carga agregada se calcula añadiendo la carga de cada conexión de cada enlace

25 Iub particular. De nuevo, esto hace el método propuesto más simple y más directo de implementar.

El método de control de la presente invención se puede aplicar a todas las conexiones sobre la interfaz Iub, o solamente a un subconjunto de esas conexiones. Por ejemplo, el método se puede aplicar solamente para aquellas conexiones que transportan datos de paquetes conmutados.

La invención también es aplicable a las conexiones sobre el interfaz Iub establecidas para transportar los datos de circuitos conmutados tal que la reducción de carga Iub de habla se puede lograr reduciendo la tasa del códec para los datos del habla.

Dicho paso de monitorizar la llegada tardía de tramas puede comprender observar los valores del tiempo de llegada contenidos en las tramas de TA recibidas, o calculados para las tramas de llegada tardía, y que desencadenan la reducción de carga Iub si el tiempo de llegada excede algún valor umbral definido.

35 Dicho paso de provocar una reducción en la carga Iub puede comprender uno o más de

•: Restringir los formatos de transporte permitidos disponibles para la entidad MAC.

•: Reducir el tamaño de la ventana del RLC.

•: Conmutar el Portador de Acceso Radio (RAB) a un estado con un consumo de recursos Iub menor.

•: Tirar paquetes IP encolados para la transmisión sobre el enlace Iub congestionado.

•: Descartar una fracción de las tramas del plano de usuario Iub en respuesta a una trama de TA recibida en el controlador de red radio desde un NodoB.

Alternativamente o además el paso de provocar una reducción en la carga Iub o Iub/Iur comprende requerir una reducción de la tasa de codificación de un par codificador/descodificador de habla multi-tasa.

De acuerdo con un segundo aspecto de la presente invención se proporciona un Controlador de Red Radio

45 configurado para controlar el volumen de tráfico del plano de usuario en la interfaz Iub o Iub/Iur: entre el Controlador de Red Radio y un Nodo B de una Red de Acceso Radio del UMTS durante los periodos de sobrecarga, el Controlador de Red Radio que comprende, para las conexiones de enlace ascendente y de enlace descendente individuales establecidas sobre la interfaz Iub o Iub/Iur, los medios para monitorizar la llegada tardía de tramas que transportan los datos del plano de usuario en el Controlador de Red Radio o en el Nodo B transmitidos sobre la interfaz Iub o Iub/Iur, y en base a los resultados de dicha monitorización, provocar una reducción en la carga Iub o Iub/Iur para una conexión cuando sea adecuado,

caracterizado porque

dichos medios “para” monitorizar se configuran para monitorizar la llegada tardía de tramas analizando los resultados proporcionados por una entidad de Protocolo de Trama que incluye, para la dirección del enlace descendente, derivar dichos resultados contando el número de tramas de Ajuste de Temporización recibidas en el Controlador de Red Radio desde el NodoB y, para la dirección del enlace ascendente, derivar dichos resultados directamente contando el número de tramas basadas en llegada tardía en el Controlador de Red Radio, y comparar el valor de cuenta con algún valor umbral.

Breve descripción de los dibujos

La Figura 1 ilustra esquemáticamente la arquitectura UTRAN de un sistema UMTS;

La Figura 2 muestra los elementos de la pila de protocolo presentes en el RNC y en el NodoB de la UTRAN de la Figura 1; y

La Figura 3 ilustra esquemáticamente un concepto de ventana de sincronización de tramas implementado en un NodoB de la UTRAN de la Figura 1.

Descripción detallada de ciertas realizaciones de la presente invención

El Protocolo de Trama (FP) entre un RNC y un NodoB y su posición dentro de la pila de protocolo se ilustra esquemáticamente en la Figura 2. Un trabajo del FP es la implementación de una función de Sincronización de Tramas que cuida de la temporización de las tramas sobre la interfaz Iub entre un RNC y el NodoB asociado (o los NodosB en el escenario de macro-diversidad). La Figura 3 ilustra la ventana de sincronización de tramas en un NodoB en relación con la estructura de tramas de radio en el enlace descendente (DL), en que el tiempo que lleva procesar una trama en el NodoB se define como Tproc. En la dirección del enlace ascendente, el RNC de servicio puede coordinar la recepción de tramas idénticas recibidas sobre los distintos Iub/Iur, y de nuevo la función de Sincronización de Tramas debería asegurar que las tramas se reciben en el RNC de servicio a tiempo.

Considerando además la dirección del enlace descendente, se debe transmitir una cierta trama con un número CFN asociado sobre el aire en un momento dado. Si hay varios NodosB y enlaces Iub/Iur implicados, todos los NodosB tienen que transmitir esa trama particular en el mismo momento. Suponiendo que los retardos sobre los enlaces Iub difieren, el RNC de servicio debe enviar la trama con un desplazamiento de tiempo suficiente, de manera que las tramas se reciben en todos los NodosB de transmisión a tiempo. Esos NodosB “detrás” de un enlace Iub rápido deben almacenar temporalmente las tramas hasta el momento programado para la transmisión.

Para supervisar esta función, la TS 25.402 del 3GPP especifica los parámetros que definen una “Ventana de Recepción”, que facilita la monitorización de si las tramas se reciben pronto o tarde en un NodoB. Estos parámetros se ilustran en la Figura 3. La ventana sirve como un ‘objetivo’ de manera que el ToAWS (punto de Inicio de la Ventana de del Tiempo de Llegada) defina el punto más temprano y la mínima capacidad de almacenamiento temporal necesaria por el NodoB, mientras que el ToAWE (punto Final de la Ventana del Tiempo de Llegada) define el último tiempo de llegada ‘deseado’ de una trama. Las tramas recibidas durante el periodo entre el ToAWE y unpunto LtoA (Último Tiempo de Llegada) se consideran tardíos, pero no demasiado tardíos para la transmisión. Las tramas recibidas después del LtoA se descartan. El estándar especifica cómo el NodoB informará al RNC en caso de que las tramas se reciban fuera de la ventana, de manera que el RNC puede adaptar su desplazamiento en consecuencia: para cada trama recibida fuera de la Ventana de Recepción, el NodoB responderá con una trama de “Ajuste de Temporización” (TA), que indica el ToA (Tiempo de Llegada) de la trama, de manera que el RNC de servicio puede ajustar sus desplazamientos.

Se propone aquí usar el mecanismo de trama de TA como una indicación de la congestión en la dirección del enlace descendente, y tomar las acciones adecuadas en el RNC para aliviar la congestión. Por supuesto esto no afecta la opción de usar también la trama de TA para su propósito previsto, es decir la sincronización de tramas. En la dirección del enlace ascendente, el RNC tiene acceso directo a los datos de temporización producidos por la entidad de FP en el RNC.

Dado que el FP no soporta ningún método para el control de carga, la reducción de carga se puede lograr en el RNC usando los métodos disponibles en los niveles de Control de Acceso al Medio (MAC), de Control de Enlace Radio (RLC), o de Control de Recursos Radio (RRC). Estos métodos incluyen temporalmente:

a) Restringir los formatos de transporte permitidos disponibles en la entidad MAC. Para una conexión de 384 kbps, esto significa que la capacidad de conexión puede caer por ejemplo a 128 kbps durante un periodo de tiempo limitado (mediante la reducción del número máximo de bloques de transporte de 12 a 4 por Intervalo de Tiempo de Transmisión, suponiendo que el bloque de transporte contiene 40 octetos de carga útil y el intervalo de tiempo de transmisión es igual a 10 ms). Este es quizás el planteamiento preferente.

b) Reducir el tamaño de la ventana de RLC. Dado que la ventana de RLC limita la cantidad máxima de datos pendientes, esto reducirá la sobrecarga. Por ejemplo, la ventana de RLC se podría restringir al nivel actualmente en uso, lo que significa que solamente se permiten las retransmisiones hasta que se reconocen los datos adicionales desde la entidad de recepción.

c) Conmutar el Portador de Acceso Radio (RAB) a un estado con un consumo de recursos Iub más bajo. Esto implica señalización RRC entre el RNC y el Equipo de Usuario (UE).

d) Tirar paquetes IP (RLC SDU) encolados para la transmisión sobre el enlace Iub congestionado.

e) Descartar una fracción, por ejemplo 1/2 o 1/3, de las tramas del plano de usuario Iub en respuesta a una trama de TA recibida en el RNC desde un NodoB (“descarte selectiva de tramas”).

Todas estas acciones reducirán la carga producida por una conexión sobre el enlace Iub congestionado y son aplicables tanto en el enlace descendente como en el enlace ascendente.

La inteligencia que actúa en la detección de congestión para implementar la reducción de carga se sitúa dentro del RNC. Esta inteligencia es una “herramienta” disponible en el MAC, RLC, y/o RRC para controlar la sobrecarga Iub/Iur es esencialmente una entidad de Gestión de Recursos de Transporte dentro del RNC.

El nivel de desencadenamiento al cual se precipita la reducción de sobrecarga es un rasgo de diseño el cual dependerá hasta cierto punto del comportamiento esperado de la red así como de las capacidades de la red. No obstante, a modo de ejemplo, uno puede especificar un número de tramas de TA que desencadena la reducción de sobrecarga. Otra solución es implementar la reducción de sobrecarga tras la recepción de una trama de TA, en base a alguna probabilidad, por ejemplo el 50%, es decir para cada trama de TA recibida, hay un 50% de posibilidad de reducción de sobrecarga que se precipita. Ambas de estas soluciones abordan dos problemas. En primer lugar, evitan la marcha atrás sincronizada de todas las conexiones al mismo tiempo y, en segundo lugar, evitan reducir la tasa binaria cuando la causa de la trama de TA es un retardo estático. El segundo problema también se podría abordar no reaccionando en caso que una trama de TA llegue para una “nueva” etapa en el traspaso suave, porque entonces es probable que la trama fuera debida a un retardo estático para la nueva etapa. Este filtrado de tramas de TA se puede usar en conjunto con una de las otras soluciones propuestas.

Los procedimientos de control de sobrecarga a) y b) perfilados anteriormente están establecidos en los procedimientos de protocolo especificados en la TS 25.321 y TS 25.322 del 3GPP, respectivamente. Ambos provocarán una disminución de carga, sin generar pérdidas adicionales. Las acciones son muy rápidas en el enlace descendente, y se pueden asignar en una base de TTI. Para el control de carga del enlace ascendente, hay un retardo algo mayor debido al hecho de que la limitación TFCS (o la restricción de tamaño de ventana de RLC) tiene que ser señalada en el aire desde el RNC al UE.

El procedimiento c) implica los procedimientos RRC estándares, pero el retardo (comparado con los procedimientos a) y b)) es mayor. Un beneficio del procedimiento c) es el hecho de que los recursos radio también se alivian durante un periodo de utilización del portador menor. Por ejemplo, la conmutación a una tasa de portador más baja libera recursos de código de esparcimiento para el enlace descendente WCDM. Es más eficiente enviar 60 kbps sobre un enlace de 64 kbps, que enviar el los mismos 60 kbps sobre un 384 kbps. Esto es debido a que el consumo de recursos “por bit” sobre 384 kbps es mayor comparado con 64 kbps: tanto el código como la potencia del código son más baratos sobre un enlace descendente más ligero.

Además de reducir la carga momentánea, el procedimiento d) tiene la ventaja de que también reducirá la carga extremo a extremo más persistente a través de la reactividad de protocolos extremo a extremo como TCP (“Gestión de Colas Activa”, AQM), dado que los RLC SDU se descartan fuera del bucle RLC AM y las pérdidas será visibles para protocolos extremo a extremo como el TCP. TCP es reactivo a las pérdidas de paquetes y por lo tanto reducirá su carga provocando una carga más baja ofrecida al enlace Iub.

El procedimiento e) tiene el beneficio de que afecta solamente a la etapa Iub que es objeto de la congestión. Si el UE está en traspaso suave y puede identificar el contenido de la trama en base a las recepciones de otras etapas (sin partir de la etapa Iub congestionada), significa que el flujo de datos de RLC/MAC permanecerá sin afectar. Si el UE no recibe el contenido de la(s) trama(s) descartada(s), el contenido se requerirá para la retransmisión por el RLC.

El procedimiento e) es aplicable actualmente en el enlace descendente solamente, ya que no hay medios actualmente para indicar la congestión Iub del enlace ascendente al NodoB y tal indicación sería requerida para tirar paquetes antes del punto de congestión (aunque es posible que alguna nueva medida se estandarizará para ese propósito, en cuyo caso el procedimiento es igualmente aplicable al enlace ascendente). Para el enlace descendente no obstante, los beneficios de descartar tramas del plano de usuario Iub salientes incluyen:

•: Evitar la reunión de una cola (o colas) en la Capa de Red de Transporte (TNL), es decir las tablas ET en los nodos de transmisión: las colas largas provocan excesivos retardos y por lo tanto la llegada muy tardía de tramas en el NodoB, es decir tales tramas muy tardías se descartarán en cualquier caso por el NodoB.

•: Evitar las pérdidas en la TNL cuando los almacenadores temporales de la TNL son cortos: las tramas se descartan para una o unas pocas conexiones de una manera controlada en lugar de una forma incontrolada para muchas/todas las conexiones.

La implementación de un procedimiento de control de carga en el RNC no puede eliminar inmediatamente la condición de sobrecarga. En ese caso, si se reciben indicaciones adicionales de congestión, el procedimiento puede ser repetido. Si no se reciben indicaciones adicionales de congestión durante un tiempo de guarda desde la última indicación de congestión para una conexión particular, entonces los recursos asignados originalmente se pueden reasignar a la conexión.

Para evitar que todos los usuarios afectados por el procedimiento de congestión vuelvan a aumentar sus cargas simultáneamente, el tiempo de guarda puede ser preferentemente un temporizador que está sujeto a variaciones aleatorias. Además, o alternativamente, es posible asignar una probabilidad a la que cada conexión reacciona a una indicación de congestión, asegurando por ello que todas las conexiones no reaccionan a una situación de congestión en el mismo momento (ver la consideración anterior del desencadenador de sobrecarga que se define como una probabilidad que sigue a la recepción de una trama de TA).

Los procedimientos de sobrecarga a) a e) se pueden desplegar separadamente o en combinación. Como ejemplo de este último planteamiento, las acciones en a) a b) se pueden desplegar de una manera secuencial, dependiendo de la persistencia de la congestión:

•: Siguiendo una primera indicación de congestión para una conexión dada:

: o Si la conexión está en traspaso suave y la etapa congestionada no es la etapa “principal”, entonces desplegar d)

: o De otro modo, desplegar a) o b)

•: Si la congestión persiste, desplegar tanto c) como e)

o Opcionalmente, ejecutar también d) o a)/b) como anteriormente, dado que se necesita mucho más tiempo para c) y e) para tener cualquier efecto.

Como alternativa a usar la trama de TA estandarizada como una indicación de congestión, uno podría considerar usar los valores de desplazamiento de temporización presentes, o considerar crear y estandarizar una medición particular para ese propósito. El anterior caso podría implicar monitorizar el valor de desplazamiento y tomar cualquiera de las acciones descritas en a. c a e. en caso de que se observe que el desplazamiento está aumentando por encima de un cierto umbral. La invención potencial debería también incluir la posibilidad de usar otras mediciones como una indicación de la congestión Iub, que incluyen:

•: La tasa de retransmisión de RLC (que aumenta significativamente en el caso de congestión persistente),

•: El flujo de datos de RLC.

•: Las tramas de sellado de tiempo para el análisis de la fluctuación y/o los retardos.

El método se puede aplicar sin modificaciones a los estándares existentes. No obstante, hay elementos que se podrían considerar para la estandarización.

•: Para desacoplar los ajustes de desplazamiento y el control de congestión Iub, puede haber una necesidad de definir mediciones separadas para los dos.

•: La congestión de enlace ascendente Iub: Para lograr la reducción de carga rápida en momentos de congestión del enlace ascendente Iub, podría haber una necesidad de indicar la congestión desde el RNC al NodoB. Esto no es posible con el estándar actual. Sin esta posibilidad, la congestión Iub tiene que ser aliviada controlando la carga Uu, que implica la señalización en el aire. Si el RNC pudiera solicitar al NodoB reducir su carga, el NodoB podría entonces tomar acciones rápidas para reducir la cantidad de tramas admitidas sobre Iub minimizando las consecuencias perjudiciales de la sobrecarga.

Aunque se hace referencia anteriormente a la interfaz Iub, se apreciará que en el caso en que tanto un RNC de servicio como de deriva están implicados en una conexión, la congestión ocurre sobre la interfaz Iub/Iur combinada, y será el RNC de servicio el que reciba las tramas de TA (u otra indicación de congestión) y precipita el procedimiento de reducción de sobrecarga. El RNC de deriva es efectivamente transparente a las tramas de TA y no reacciona a las situaciones de sobrecarga.

Se apreciará por la persona experta en la técnica que se pueden hacer varias modificaciones a las realizaciones descritas anteriormente sin salirse del alcance de la presente invención.

Claims

REIVINDICACIONES

1. Un método de control del volumen de tráfico del plano de usuario en la interfaz Iub o Iub/Iur entre un Controlador de Red Radio y un Nodo B de una Red de Acceso Radio UMTS durante los periodos de sobrecarga, el método que comprende, para las conexiones de enlace ascendente y del enlace descendente individuales establecidas sobre la interfaz Iub o Iub/Iur, monitorizar en el Controlador de Red Radio la llegada tardía de tramas que transportan datos del plano de usuario en el Controlador de Red Radio o en el Nodo B transmitidos sobre la interfaz Iub o Iub/Iur, y en base a los resultados de dicha monitorización, provocar una reducción en la carga Iub o Iub/Iur para una conexión cuando sea apropiado,

caracterizado porque

el paso de monitorizar la llegada tardía de tramas comprende analizar los resultados proporcionados por una entidad de Protocolo de Trama que incluye, para la dirección de enlace descendente, derivar dichos resultados contando el número de tramas de Ajuste de Temporización recibidas en el Controlador de Red Radio desde el NodoB y, para la dirección del enlace ascendente, derivar dichos resultados directamente contando el número de tramas basadas en llegada tardía en el Controlador de Red Radio, y comparar el valor de cuenta con algún valor umbral.
2.

Un método de acuerdo con la reivindicación 1, en el que el método se aplica a las conexiones de paquetes conmutados sobre la interfaz Iub o Iub/Iur.
3.

Un método de acuerdo con la reivindicación 1 o 2, en el que la reducción de carga Iub o Iub/Iur se desencadena cuando la cuenta es igual o excede el valor umbral.
4.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que la reducción de carga Iub

o Iub/Iur se desencadena en base a alguna probabilidad definida que sigue a la recepción de una trama de Ajuste de Temporización o la llegada tardía de una trama.
5.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicho paso de monitorizar la llegada tardía de tramas, comprende observar los valores del momento de llegada contenido en las tramas de Ajuste de Temporización recibidas, o los retardos calculados para las tramas que llegan tardías, y desencadenar la reducción de carga Iub o Iub/Iur si el tiempo de llegada o el retardo excede algún valor umbral definido.
6.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicho paso de provocar una reducción en la carga Iub o Iub/Iur comprende restringir los formatos de transporte permitidos disponibles para la entidad de Control de Acceso al Medio de envío.
7.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicho paso de provocar una reducción en la carga Iub o Iub/Iur comprende reducir el tamaño de la ventana de Control de Enlace Radio.
8.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicho paso de provocar una reducción en la carga Iub o Iub/Iur comprende conmutar el Portador de Acceso Radio a un estado con un consumo de recursos Iub menor.
9.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicho paso de provocar una reducción en la carga Iub o Iub/Iur comprende tirar paquetes IP encolados para la transmisión sobre el enlace Iub o Iub/Iur congestionado.
10.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicho paso de provocar una reducción en la carga Iub o Iub/Iur comprende descartar una fracción de las tramas del plano de usuario Iub en respuesta a una trama o tramas de Ajuste de Temporización recibidas en el controlador de red radio desde el NodoB.
11.

Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicho paso de provocar una reducción en la carga Iub o Iub/Iur comprende requerir una reducción de la tasa de codificación de un par codificador/descodificador de habla de tasas múltiples.
12.

Un Controlador de Red Radio configurado para controlar el volumen de tráfico en el plano de usuario en la interfaz Iub o Iub/Iur entre el Controlador de Red Radio y un Nodo B de una Red de Acceso Radio del UMTS durante periodos de sobrecarga, el Controlador de Red Radio que comprende, para las conexiones de enlace ascendente y de enlace descendente individuales establecidas sobre la interfaz Iub o Iub/Iur, los medios para monitorizar la llegada tardía de tramas que transportan datos del plano de usuario en el Controlador de Red Radio o en el Nodo B transmitidos sobre la interfaz Iub o Iub/Iur, y, en base a los resultados de dicha monitorización, provocar una reducción en la carga Iub o Iub/Iur para una conexión cuando sea apropiado,

caracterizado porque

dichos medios para la monitorización se configuran para monitorizar la llegada tardía de tramas analizando los resultados proporcionados por una entidad de Protocolo de Trama que incluye, para la dirección del enlace descendente, derivar dichos resultados contando el número de tramas de Ajuste de Temporización recibidas en el Controlador de Red Radio desde el NodoB y, para la dirección del enlace ascendente, derivar dichos resultados directamente contando el número de tramas basadas en la llegada tardía en el Controlador de Radio, y comparar el valor de cuenta con algún valor umbral.