ES2342960A1 - Procedimiento y sistema de control de congestion en ehspa. - Google Patents
Procedimiento y sistema de control de congestion en ehspa. Download PDFInfo
- Publication number
- ES2342960A1 ES2342960A1 ES200802772A ES200802772A ES2342960A1 ES 2342960 A1 ES2342960 A1 ES 2342960A1 ES 200802772 A ES200802772 A ES 200802772A ES 200802772 A ES200802772 A ES 200802772A ES 2342960 A1 ES2342960 A1 ES 2342960A1
- Authority
- ES
- Spain
- Prior art keywords
- congestion
- service
- decoding
- enode
- data packets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 241000760358 Enodes Species 0.000 claims abstract description 84
- 238000010295 mobile communication Methods 0.000 claims abstract description 6
- 230000003111 delayed effect Effects 0.000 claims description 5
- 238000004891 communication Methods 0.000 claims description 4
- 230000004044 response Effects 0.000 claims description 4
- 230000008569 process Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000003245 working effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/16—Performing reselection for specific purposes
- H04W36/22—Performing reselection for specific purposes for handling the traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0289—Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/04—Interfaces between hierarchically different network devices
- H04W92/12—Interfaces between hierarchically different network devices between access points and access point controllers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
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 sobrequé 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.
Description
Procedimiento y sistema de control de congestión
en eHSPA.
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).
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.
\vskip1.000000\baselineskip
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.
\vskip1.000000\baselineskip
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 con continuidad, teniendo la red una red de
transporte, en el que:
- un equipo de usuario UE envía paquetes de
datos de enlace ascendente a un eNodo B de servicio y a un número
de eNodos B de no servicio,
- desde cada eNodo B de no servicio dichos
paquetes de datos de enlace ascendente se descodifican y se
transmiten en enlace ascendente a través de la red de transporte
sobre una interfaz IuR, y entonces se transmiten junto con los
datos de enlace descendente al eNodo de servicio.
\vskip1.000000\baselineskip
Según un primer aspecto de la invención, 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, 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, manteniendo activa la descodificación del
E-DPCCH o Canal de Datos Físico Dedicado
mejorado.
\vskip1.000000\baselineskip
Preferiblemente, el procedimiento comprende
además reanudar la descodificación del plano de usuario cuando
acaba la congestión sobre dichas interfaces IuR.
\newpage
Según una realización preferida de la invención,
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
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.
\vskip1.000000\baselineskip
La etapa de enviar una notificación de
congestión también puede comprender:
- si se detecta congestión sólo 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 uno o más 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.
\vskip1.000000\baselineskip
La detención de la descodificación de dichos
paquetes de datos de enlace ascendente puede llevarse a cabo para
todos los equipos de usuario al mismo tiempo. O puede llevarse a
cabo para equipos de usuario con tráfico de prioridad baja, y si la
congestión persiste, detener la descodificación de datos de los
usuarios de la siguiente prioridad.
La congestión puede detectarse mediante tramas
perdidas o retardadas en los paquetes de datos.
La notificación de congestión tiene
preferiblemente el formado indicado en 3GPP 25.423 y 25.425.
\vskip1.000000\baselineskip
Un segundo aspecto de la presente invención se
refiere a una 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, 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.
\vskip1.000000\baselineskip
Preferiblemente 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.
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.
También, como 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.
La detención de la descodificación de dichos
paquetes de datos de enlace ascendente puede llevarse a cabo para
todos los equipos de usuario al mismo tiempo. O puede llevarse a
cabo para equipos de usuario con tráfico de prioridad baja, y si la
congestión persiste, detener la descodificación de datos de los
usuarios de la siguiente prioridad.
La congestión preferiblemente se detecta
mediante tramas perdidas o retardadas en los paquetes de datos.
Es también un propósito de la presente invención
proporcionar una entidad de red de una red de comunicaciones
móviles de arquitectura plana que comprende medios para llevar a
cabo el procedimiento descrito anteriormente.
En el contexto de la presente invención, el
término "entidad de red" pretende significar cualquier estación
base, nodo B o similar, que comprende al menos un sector, que tiene
un equipo de usuario conectado al mismo en una situación de
traspaso con continuidad.
Las ventajas de la invención propuesta se harán
evidentes en la descripción a continuación.
Para completar la descripción y con el fin de
proporcionar una mejor comprensión de la invención, se proporciona
un conjunto de dibujos. Los dibujos forman una parte integrante de
la descripción e ilustran las realizaciones preferidas de la
invención, que no deberían interpretarse como restrictivas del
alcance de la invención, sino sólo como ejemplos de cómo puede
realizarse la invención. Los dibujos comprenden las siguientes
figuras:
la figura 1 muestra la arquitectura clásica.
La figura 2 muestra la arquitectura plana, y el
flujo de datos en tal arquitectura en una situación de traspaso con
continuidad.
La figura 3 muestra un diagrama de flujo del
procedimiento de la invención.
\vskip1.000000\baselineskip
A continuación se describe en detalle una
realización preferida del procedimiento de la presente invención,
que comprueba dinámicamente si hay congestión en una situación de
traspaso con continuidad (situación de Soft Handover SHO), y
dependiendo de en dónde se detecte la congestión toma las acciones
correspondientes en tal proceso de traspaso con continuidad.
El plano de usuario de traspaso con continuidad
siempre está activo, y también lo está el manejo de control de
potencia típico de traspaso con continuidad; pero según la
invención, se detiene la descodificación de los datos de equipo de
usuario en uno o más de los eNodos B de no servicio en caso de
problemas de congestión; como consecuencia, se reduce la ocupación
en la red de trasporte de acceso.
Cuando ya no existe la situación de congestión,
se reanuda la descodificación de los datos.
Como se muestra en la figura 3, cuando hay
congestión, el eNodo B de servicio puede detectar tramas perdidas o
tramas retardadas en el nivel de transporte en la dirección de
enlace descendente de su enlace de transporte (es decir, su IuR).
Por tanto, se detecta congestión (etapa 300).
Cuando se envían los paquetes de datos de equipo
de usuario UE, cada eNodo B de no servicio inserta un número de
secuencia y un sello o marca de tiempo. Cuando los paquetes de datos
llegan al eNodo B de servicio, éste comprueba el número de
secuencia, y si falta un número de secuencia, entonces ha habido una
pérdida de paquete. También comprueba el tiempo que ha tardado en
llegar el paquete de datos del equipo de usuario UE, por lo que
también puede detectar cuándo hay un retardo de paquete.
\vskip1.000000\baselineskip
Dependiendo de la cantidad de enlaces de
transporte que estén congestionados, hay dos posibl1es casos:
* caso de congestión 1: se detecta congestión en
los datos del equipo de usuario UE procedentes de todos los eNodos
B de no servicio. Esto implica que la congestión está probablemente
en la trayectoria de enlace descendente del eNodo B de servicio,
entre la red de transporte 30 (véase la figura 1B) y el eNodo B de
servicio 20.
* Caso de congestión 2: se detecta congestión
sólo en los datos del equipo de usuario UE desde uno o más eNB de
no servicio específicos, pero no en todos. Eso significa que la
congestión está sucediendo en el enlace ascendente de esos eNodos B
de no servicio específico(s) (por ejemplo, entre el eNodo B
de no servicio y la red de acceso de transporte de la figura
1).
\vskip1.000000\baselineskip
Por tanto, se lleva a cabo una comprobación de
congestión para determinar si hay una congestión del tipo "caso
de congestión 1" (etapa 310). Si se detecta que hay congestión en
la dirección de enlace descendente del enlace de transporte del
eNodo B de servicio, el eNodo B de servicio 20 envía una
notificación de congestión a todos los eNodos B de no servicio
(etapa 311). Tras la recepción de la notificación, los eNodos B
implicados detienen la descodificación del E-DPDCH
(Canal de Datos Físico Dedicado mejorado) de los equipos de usuario
cuyo tráfico es manejado mediante el eNodo B citado como eNodo B de
servicio en la notificación de congestión recibida (etapa 312).
Si el resultado de la decisión de congestión 310
es negativo, se lleva a cabo una comprobación de congestión para
determinar si hay congestión del tipo "caso de congestión 2"
(etapa 320). Si se detecta que hay congestión en la dirección de
enlace ascendente del enlace de transporte del eNodo B de servicio
se detecta entonces cuáles son los enlaces de transporte
congestionados (etapa 321). El eNodo B de servicio envía entonces
una notificación de congestión sólo a los eNodos B de no servicio
para los que se identificó congestión en su flujo (etapa 322).
Estos eNodos B de no servicio detienen la descodificación del
E-DPDCH de los equipos de usuario cuyo tráfico es
manejado por el eNodo B citado como eNodo B de servicio en la
notificación de congestión recibida (etapa 323).
\newpage
El formato utilizado para la notificación de
congestión es el de los mensajes indicados en los estándares 3GPP
para la Iur (Parte de Aplicación RNS), referencias 25.423 y 25.425.
La indicación de congestión se notifica en el elemento de
información "estado de congestión".
Los bits de estado de congestión se utilizan por
el DRNC (Controlador de Red de Radio de Desviación, Drift Radio
Network Controller) para indicar un estado de congestión
recibido. El DRNC proporciona el estado de congestión en la trama
de control (Control Frame) de asignación (tipo 1 o tipo 2) de
capacidad HS-DSCH cuando se ha recibido hacia el
RNC de servicio.
\vskip1.000000\baselineskip
Longitud de campo: 2 bits. Intervalo de
valores:
0 Ninguna congestión TNL
1 Reservado para uso futuro
2 Congestión TNL - detectada por retardo
incorporado
3 Congestión TNL - detectada por pérdida de
trama
\vskip1.000000\baselineskip
Cuando un eNodo B de no servicio recibe una
notificación de congestión, detiene la descodificación de los datos
de los usuarios de traspaso con continuidad de no servicio, y cesa
la transmisión al eNodo B que notificó la congestión. Hay dos
posibilidades:
- detener la descodificación de datos de todos
los usuarios al mismo tiempo;
- detener la descodificación de datos de
usuarios con tráfico de prioridad baja, y si la congestión persiste,
detener la descodificación de datos de los usuarios de la siguiente
prioridad.
Cuando el eNodo B de servicio detecta que ya no
hay congestión, envía la correspondiente notificación de "no
congestión", entonces los eNodos B de no servicio pueden reanudar
de nuevo la descodificación, preferiblemente usuario por usuario
para evitar histéresis.
De nuevo, el formato de los mensajes se indica
en 25.423 y 25.425. Cuando el valor es 0, no hay congestión TNL, y
entonces cada eNodo B de no servicio reanuda la descodificación del
tráfico en el enlace ascendente y el envío de paquetes de datos de
usuario al eNodo B de servicio.
En este caso la reanudación de la
descodificación empieza con los usuarios de prioridad alta cada T
segundos para evitar histéresis. Si no se recibe ninguna indicación
de congestión, entonces reanuda la descodificación del siguiente
usuario, según prioridad de tráfico, y así sucesivamente.
La invención no se limita obviamente a las
realizaciones específicas descritas en el presente documento, sino
que también engloba cualquier variación que pueda considerar
cualquier experto en la técnica (por ejemplo, en relación con la
elección de componentes, configuración, etc.), dentro del alcance
general de la invención según se define en las reivindicaciones
adjuntas.
Claims (15)
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);
\vskip1.000000\baselineskip
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.
\vskip1.000000\baselineskip
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.
\vskip1.000000\baselineskip
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.
\vskip1.000000\baselineskip
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.
\vskip1.000000\baselineskip
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.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200802772A ES2342960B1 (es) | 2008-09-30 | 2008-09-30 | Procedimiento y sistema de control de congestion en ehspa. |
| EP09171502.9A EP2169999A3 (en) | 2008-09-30 | 2009-09-28 | Method and system for congestion control in eHSPA |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200802772A ES2342960B1 (es) | 2008-09-30 | 2008-09-30 | Procedimiento y sistema de control de congestion en ehspa. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2342960A1 true ES2342960A1 (es) | 2010-07-19 |
| ES2342960B1 ES2342960B1 (es) | 2011-06-14 |
Family
ID=41507957
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200802772A Active ES2342960B1 (es) | 2008-09-30 | 2008-09-30 | Procedimiento y sistema de control de congestion en ehspa. |
Country Status (2)
| Country | Link |
|---|---|
| EP (1) | EP2169999A3 (es) |
| ES (1) | ES2342960B1 (es) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007069948A1 (en) * | 2005-12-14 | 2007-06-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for reducing uplink traffic load on transport network at basestation during soft handover. |
| EP1811800A1 (en) * | 2006-01-23 | 2007-07-25 | Alcatel Lucent | Method, base station, and communication network supporting high-speed uplink packet access (HSUPA) with soft handover mechanisms |
| WO2008066430A1 (en) * | 2006-11-28 | 2008-06-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Enhanced flow control in a cellular telephony system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7724656B2 (en) * | 2005-01-14 | 2010-05-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Uplink congestion detection and control between nodes in a radio access network |
| EP1901493A1 (en) * | 2006-09-14 | 2008-03-19 | Siemens S.p.A. | Controlling congestion over a non-serving branch |
| US20080293235A1 (en) | 2007-05-22 | 2008-11-27 | Harris Corporation | Compound wirebonding and method for minimizing integrated circuit damage |
-
2008
- 2008-09-30 ES ES200802772A patent/ES2342960B1/es active Active
-
2009
- 2009-09-28 EP EP09171502.9A patent/EP2169999A3/en not_active Withdrawn
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007069948A1 (en) * | 2005-12-14 | 2007-06-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for reducing uplink traffic load on transport network at basestation during soft handover. |
| EP1811800A1 (en) * | 2006-01-23 | 2007-07-25 | Alcatel Lucent | Method, base station, and communication network supporting high-speed uplink packet access (HSUPA) with soft handover mechanisms |
| WO2008066430A1 (en) * | 2006-11-28 | 2008-06-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Enhanced flow control in a cellular telephony system |
Non-Patent Citations (2)
| Title |
|---|
| "{}3rd Generation Partnership Project; Technical Specification Group Radio Access Network; High Speed Packet Access (HSPA) evolution; Frequency Division Duplex (FDD) (Release 7) (3GPP TR 25.999 version 7.0.1 Release 6); 3rd Generation Partnership Project (3GPP), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France. 01.03.2008. Epígrafe 7.3 * |
| "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; High Speed Packet Access (HSPA) evolution; Frequency Division Duplex (FDD) (Release 7) (3GPP TR 25.999 version 7.0.1 Release 6); 3rd Generation Partnership Project (3GPP), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France. 01.03.2008. Epígrafe 7.3 * |
Also Published As
| Publication number | Publication date |
|---|---|
| ES2342960B1 (es) | 2011-06-14 |
| EP2169999A3 (en) | 2014-02-05 |
| EP2169999A2 (en) | 2010-03-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2937935T3 (es) | Método y aparato de comunicación | |
| ES2962322T3 (es) | Gestión de duplicación de pdcp y recuperación de datos en una nueva tecnología de acceso por radio | |
| ES2744228T3 (es) | Entrega ordenada de paquetes de datos durante la transferencia | |
| ES2471888T3 (es) | Estación base, estación móvil, sistema de comunicaciones, y método de reordenación de los mismos | |
| ES2788874T3 (es) | Transmisión de un informe de estado PDCP | |
| ES2966693T3 (es) | Procedimiento para transmitir informe de estado de capa de PDCP en sistema de telecomunicaciones móviles y receptor de telecomunicaciones móviles | |
| US20210377784A1 (en) | Transmission techniques in a cellular network | |
| ES2928159T3 (es) | Método, dispositivo y sistema de control de transmisión | |
| ES2770767T3 (es) | Procedimientos y aparatos para la adaptación de velocidad en respuesta a la congestión de la red | |
| CN102598833B (zh) | 用于增强上行链路通信的传输网络拥塞控制的方法和节点 | |
| ES2604981T3 (es) | Procedimiento para desplazar una ventana de recepción en una red de acceso de radio | |
| ES2639131T3 (es) | Equipo de usuario y método para recuperación eficiente de datos almacenados temporalmente en un Nodo B después de atender un cambio de celda de un canal compartido de enlace descendente de alta velocidad | |
| US8369221B2 (en) | Efficient flow control in a radio network controller (RNC) | |
| ES2640220T3 (es) | Asignación fija de HS-DSCH o E-DCH para VoIP (o HS-DSCH sin HS-SCCH/E-DCH sin E-DPCCH) | |
| ES2442892T3 (es) | Traspaso de conmutación de paquetes en un sistema de comunicación móvil, durante el que un nodo móvil recibe paquetes desde un nodo de origen y un nodo de destino | |
| ES2714325T3 (es) | Control de la congestión de una red de comunicación utilizando prioridad de asignación y retención | |
| ES2315369T3 (es) | Tratamiento de la congestion y del retardo en una red de datos por paquetes. | |
| ES2410004T3 (es) | Método para enviar un acuse de recibo a un punto de malla de entrada en una red de malla. | |
| ES2734122T3 (es) | Selección de formato de transporte de enlace ascendente | |
| ES2363570T3 (es) | Longitud de unidad de datos en paquete para control de enlace de radio flexible. | |
| ES2529304T3 (es) | Control de congestión en una red de comunicación | |
| JP2010532952A (ja) | 送信ノードにおける輻輳制御 | |
| ES2356861T3 (es) | Utilización mejorada de enlaces de datos. | |
| JPWO2008029628A1 (ja) | データ再送方法、ネットワーク制御装置、移動局および基地局 | |
| ES2391588T3 (es) | Procedimiento y aparato para reubicación de SRNS en sistemas de comunicación inalámbrica |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20100719 Kind code of ref document: A1 |
|
| FG2A | Definitive protection |
Ref document number: 2342960 Country of ref document: ES Kind code of ref document: B1 Effective date: 20110614 |