ES2357631A1 - Método para programar tráfico en un canal de comunicaciones. - Google Patents
Método para programar tráfico en un canal de comunicaciones. Download PDFInfo
- Publication number
- ES2357631A1 ES2357631A1 ES200930300A ES200930300A ES2357631A1 ES 2357631 A1 ES2357631 A1 ES 2357631A1 ES 200930300 A ES200930300 A ES 200930300A ES 200930300 A ES200930300 A ES 200930300A ES 2357631 A1 ES2357631 A1 ES 2357631A1
- Authority
- ES
- Spain
- Prior art keywords
- data
- burst
- traffic
- latency
- bursts
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
- H04L47/2433—Allocation of priorities to traffic types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/6215—Individual queue per QOS, rate or priority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/622—Queue service order
- H04L47/623—Weighted service order
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
- H04L47/628—Queue scheduling characterised by scheduling criteria for service slots or service orders based on packet size, e.g. shortest packet first
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
- H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
- H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
La invención se refiere a un método para programar tráfico en un canal de comunicación de una red de comunicaciones móviles que detecta ráfagas de datos de pequeño tamaño y prioriza su transmisión. La detección se realiza mediante comparación con dos umbrales, siendo uno un indicador del tamaño instantáneo de la ráfaga de datos y refiriéndose el segundo al tamaño de dicha ráfaga de datos a lo largo de un periodo de tiempo dado.La invención también se refiere a un programador de red que comprende medios para llevar a cabo el método anterior.
Description
Método para programar tráfico en un canal de
comunicaciones.
La presente invención se refiere a la
transferencia de datos en un sistema de comunicaciones y, más en
particular, a un método de programación de un canal compartido de
datos.
En redes de comunicación modernas la
planificación de canales compartidos de datos es un asunto de gran
importancia, puesto que es responsable de la correcta distribución
de ancho de banda entre un número de servicios y comunicaciones
establecidos sobre un canal. Esta distribución determina la cantidad
de tiempo que tiene que esperar un paquete en una cola de
transmisión, y por tanto, la latencia experimentada en una
comunicación y la calidad de la experiencia del usuario final.
No todos los servicios o tipos de tráfico tienen
la misma tolerancia a latencia. Las comunicaciones en tiempo real
requieren normalmente valores de latencia inferiores y más
homogéneos, mientras que la transferencia de cantidades mayores de
datos estáticos permite requisitos menos restrictivos. Por este
motivo, la mayoría de arquitecturas de red proporcionan algún tipo
de sistema que permite la asociación de un determinado grado de
prioridad a un paquete, dependiendo del tipo de tráfico que
porta.
Una correcta asignación de prioridad, y el
consiguiente manejo de paquetes de datos dependiente de la
prioridad, constituye un problema que se ha resuelto en cierta
medida, con diferentes grados de éxito, por un número de invenciones
y protocolos de comunicación.
Haciendo uso de los medios proporcionados por
diferentes normas de protocolo de comunicación, un número de
invenciones ha intentado optimizar el rendimiento del sistema de
asignación de prioridad. El documento de patente US
2006/153216-A1 usa información acerca del estado
actual de la red para generar una programación adaptativa. De esta
forma, reorganiza las prioridades de los diferentes paquetes que
están presentes en el sistema teniendo en cuenta la tasa de
transmisión de enlace descendente de programación de la estación
móvil y un factor de retardo que representa el retraso de los datos
en cola. Específicamente, este procedimiento busca mejorar la
calidad ofrecida a los servicios de voz
sobre IP, aunque demanda los recursos necesarios para proporcionar una supervisión constante del estado de la red.
sobre IP, aunque demanda los recursos necesarios para proporcionar una supervisión constante del estado de la red.
El documento de patente US
2005/288050-A1 proporciona un enfoque diferente al
mismo asunto de mejorar la experiencia del usuario a través de la
reducción de la latencia. En este caso, se centra en comunicaciones
de PTT ("push-to-talk", pulsar
para hablar), enviando paquetes que pertenecen a un tipo de tráfico
sensible al tiempo a través de un canal de señalización.
El manejo de datos diferenciales dependiendo del
tipo de tráfico portado se extiende a otros aspectos de la
comunicación, tal como el proceso de traspaso en redes celulares. Un
ejemplo de traspaso dependiente del tipo de tráfico puede
encontrarse en el documento WO 2006/062306-A1.
Sin embargo, en todos estos documentos los
diferentes sistemas realizan una caracterización genérica de los
servicios que están presentes en la red. Teniendo en cuenta sólo el
tipo de tráfico que está portándose, se ignora cualquier aspecto
referido a las características de una única comunicación. Por tanto,
la programación satisface sólo parcialmente las necesidades de la
comunicación, permitiendo mejoras adicionales de la experiencia del
usuario.
La invención se refiere a un método para
programar tráfico en un canal de comunicación según la
reivindicación 1, y a un dispositivo de red de una red de
comunicaciones móviles según la reivindicación 12. En las
reivindicaciones dependientes se definen realizaciones preferidas
del método.
La presente invención resuelve los problemas
mencionados anteriormente detectando y priorizando, antes de la
programación de los canales de comunicación, aquellas ráfagas de
datos que debido a su reducido tamaño son más sensibles a
latencia.
Con este fin, el método de la reivindicación
independiente de la presente invención etiqueta como tráfico
sensible a latencia aquellas ráfagas de datos que verifican
simultáneamente:
- -
- La cantidad de datos añadida a una cola de transmisión por dicha ráfaga de datos en un instante dado, esto es, la parte de la ráfaga que se envía al sistema de planificación o programación en un momento determinado para transmitirse sobre el canal de comunicación, es más pequeña que un umbral dado.
- -
- La cantidad de datos añadida a una cola de transmisión por dicha ráfaga de datos durante una cantidad de tiempo determinada definida por la longitud de una ventana de tiempo, es más pequeña que un segundo umbral dado. Preferentemente, la longitud de la ventana dependerá del caudal ("throughput") del usuario que es fuente o destino de dicha ráfaga de datos, para realizar una clasificación más eficaz.
\vskip1.000000\baselineskip
Por tanto, las ráfagas de datos con las
siguientes características permanecen sin etiquetar:
- -
- Ráfagas de datos que proporcionan una gran cantidad de datos en un instante dado.
- -
- Ráfagas de datos que proporcionan de forma constante una cantidad de datos moderada o grande a lo largo de un periodo de tiempo largo.
\vskip1.000000\baselineskip
Un primer aspecto de la invención se refiere a
un método para programar tráfico en un canal de comunicación de una
red de comunicaciones móviles, siendo compartido el canal de
comunicación por una pluralidad de equipos de usuario, que
comprende:
- -
- etiquetar como tráfico sensible a latencia cualquier ráfaga de datos que verifica que:
- -
- la cantidad de datos a partir de dicha ráfaga de datos añadida a una cola de transmisión en un instante dado es inferior a un primer umbral; y
- -
- la cantidad de datos a partir de dicha ráfaga de datos añadida a una cola de transmisión a lo largo de la duración de una ventana de tiempo es inferior a un segundo umbral;
- -
- priorizar la transmisión de ráfagas de datos etiquetadas como tráfico sensible a latencia.
\vskip1.000000\baselineskip
La longitud de la ventana de tiempo puede
ajustarse dinámicamente para cada tráfico de usuario de servicio
según el caudal o throughput de dicho usuario. Cada usuario
puede establecer más de una comunicación (normalmente dos), y cada
comunicación se calcula de forma independiente.
Los umbrales primero y segundo se ajustan
preferentemente como una función de un indicador de prioridad de la
ráfaga de datos, dependiendo dicho indicador de prioridad del tipo
de tráfico portado por dicha ráfaga de datos.
Dicho indicador de prioridad es preferentemente
un campo de SPI según se define en el protocolo de HSPA, TS
25.433.
La etapa de priorizar ráfagas de datos
etiquetadas como tráfico sensible a latencia se realiza
preferentemente ajustando un peso que modifica un indicador de
prioridad de la ráfaga de datos, siendo dicho indicador de prioridad
dependiente del tipo de tráfico portado por dicha ráfaga de datos,
donde dicho peso depende de si una ráfaga de datos está etiquetada
como tráfico sensible a latencia.
Dicho peso puede depender de dicho indicador de
prioridad de la ráfaga de datos.
Dicho indicador de prioridad es preferentemente
el campo de SPI definido en el protocolo de HSPA y dicho peso se
ajusta en el campo SPIweight definido en el protocolo de HSPA.
La etapa de priorizar ráfagas de datos
etiquetadas como tráfico sensible a latencia se realiza
preferentemente asignando un ancho de banda preestablecido a las
ráfagas de datos mientras las ráfagas de datos permanezcan
etiquetadas como tráfico sensible a latencia.
El valor de dicho ancho de banda preestablecido
puede depender de un indicador de prioridad de la ráfaga de datos,
dependiendo dicho indicador de prioridad del tipo de tráfico portado
por dicha ráfaga de datos.
Con el método de la presente invención se
realiza una caracterización completa del tráfico, considerando no
sólo el tipo general de tráfico establecido sobre una conexión, sino
también una característica intrínseca de ráfagas de datos solas.
Esto permite una programación o planificación más eficaz de los
recursos en la red, lo que da como resultado una mejor experiencia
del usuario.
Un segundo aspecto de la presente invención se
refiere a un dispositivo de red de una red de comunicaciones móviles
que comprende, al menos:
- -
- un detector de tráfico sensible a latencia configurado para etiquetar ráfagas de datos que verifican que:
- -
- la cantidad de datos de dicha ráfaga de datos añadida a una cola de transmisión en un instante dado es inferior a un primer umbral;
\newpage
- -
- la cantidad de datos de dicha ráfaga de datos añadida a una cola de transmisión a lo largo de la longitud de una ventana de tiempo es inferior a un segundo umbral; y
- -
- un programador de canal configurado para priorizar ráfagas de datos etiquetadas por el detector de tráfico sensible a latencia.
\vskip1.000000\baselineskip
Las ventajas de la invención propuesta se harán
evidentes en la descripción que sigue.
\vskip1.000000\baselineskip
A continuación se pasa a describir de manera muy
breve una serie de figuras que ayudan a comprender mejor la
invención y que se presentan como ejemplos ilustrativos pero no
limitativos de ésta.
La figura 1 muestra un esquema general del
sistema con ejemplos de las diferentes ráfagas de datos que
reconoce.
Las figuras 2A y 2B muestran los efectos de la
técnica empleada para seleccionar la longitud de las ventanas de
tiempo.
La figura 3 muestra una dependencia teórica
entre el tamaño de ráfaga y la sensibilidad a latencia.
La figura 4 muestra un ejemplo de la evolución
de SPIweight frente al tamaño de ráfaga de datos.
\vskip1.000000\baselineskip
A continuación se hace referencia en detalle a
una realización preferida del método de la presente invención que se
centra en tecnología de HSPA y hace uso de alguno de los campos que
éste define, tal como SPI o SPIweight. No obstante, debe
considerarse esta realización como un ejemplo explicativo no
limitativo, puesto que puede extenderse a cualquier otra
arquitectura de red que puede proporcionar equivalentes válidos para
las funcionalidades requeridas.
La figura 1 muestra un esquema general del
sistema, en el que las dos tareas principales del método se han
asignado a dos bloques funcionales: un detector de tráfico sensible
a latencia 10 y un programador de red 20. Muestra también diferentes
tipos de ráfagas de datos que entran en el sistema.
Para detectar ráfagas de datos que son sensibles
a latencia, deben descartarse dos situaciones:
- Grandes ráfagas de datos instantáneas, con una
alta tasa de transmisión de datos 30.
- Grandes ráfagas de datos con una tasa de
transmisión de datos más pequeña pero con una longitud mayor 31.
Para realizar la primera detección, se ajusta un
primer umbral sobre un buffer o memoria intermedia que sirve como
punto de entrada a la cola de transmisión. Este primer umbral se
denomina en este ejemplo tamaño máximo de buffer de usuario (MaxBS),
y se compara constantemente con la cantidad de datos real en dicho
buffer, esto es, tamaño de buffer de usuario (BS). Por tanto, si una
ráfaga de datos supera el MaxBS en un instante dado, no se
considerará como tráfico sensible a latencia.
La segunda detección necesita el cálculo de la
cantidad de datos introducida en el sistema por una ráfaga de datos
durante la longitud de una ventana de tiempo dada. Esta cantidad
denominada en este ejemplo bytes recibidos acumulados (CRB) se
compara con un segundo umbral, máximo de bytes recibidos acumulados
(MaxCRB).
Si se satisfacen ambas condiciones, esto es, si
BS<MaxBS y CRB<MaxCRB, la ráfaga de datos correspondiente 32
se etiqueta como tráfico sensible a latencia, y se ajusta una
bandera para ese fin como VERDADERO. En cualquier otro caso, la
bandera permanece como FALSO.
Una forma posible de seleccionar una longitud
apropiada para la ventana de tiempo (TW) es aplicar la siguiente
regla:
Las figuras 2A y 2B muestran el rendimiento de
esta opción (ventana de tiempo TW dinámica, mostrada en la figura
2A) en contraposición a la selección de una ventana estática (figura
2B), siendo MaxCRB = 500 KB.
En el caso mostrado en la figura 2A:
- Caudal Usuario1 > Caudal Usuario2
de modo que aplicando la ecuación previa:
- VentanaTiempo Usuario1 < VentanaTiempo Usuario2.
De modo que en este primer caso, con una ventana
de tiempo configurable, para ambos usuarios el tráfico se considera
como tráfico no sensible a latencia, puesto que el tamaño de ráfaga
600 KB supera el tamaño máximo de ráfaga, 500 KB.
En el caso mostrado en la figura 2B:
- Caudal Usuario1 > Caudal Usuario2
y usando la ecuación anterior:
- VentanaTiempo Usuario1 = VentanaTiempo Usuario2
En este segundo caso (ventana estática), la
ventana de tiempo para el segundo usuario (Usuario2) comprende 300
KB, que es inferior a 500 KB, de modo que la ráfaga se considera
como tráfico sensible a latencia. Pero el tamaño de ráfaga, 600 KB
es mayor que el tamaño de ráfaga máximo (CRB=500 KB), de modo que la
ventana de tiempo para el segundo usuario (usuario2) se ha
configurado de forma errónea.
Así, en ambos casos el caudal de usuario de la
segunda ráfaga de datos es inferior al de la primera ráfaga de
datos, pero sólo la primera opción (mostrada en la figura 2A) tiene
en cuenta ese hecho. Por tanto, la ventana estática (en la figura
2B) es incapaz de detectar el tamaño real de la segunda ráfaga y la
clasifica erróneamente como sensible a latencia.
Para dotar al sistema con mayor flexibilidad, la
realización preferida impone valores diferentes a MaxCRB y MaxBS
según un valor de prioridad previo de la ráfaga de datos indicada en
este caso en el campo de SPI, con valores en el intervalo entre 0 y
15 (siendo 0 la prioridad más alta). Estos valores de MaxCRB y MaxBS
se hacen más estrictos a medida que aumenta SPI.
Puede usarse un criterio libre para la elección
de la evolución de dichos valores (MaxCRB, MaxBS) a lo largo del
intervalo de SPI, pero también puede tenerse en cuenta el efecto
teórico que tiene el tamaño de ráfaga sobre la sensibilidad a
latencia. La sensibilidad a latencia (sensL(%)) puede definirse
como:
donde L es la latencia entre dos
elementos de la red y ST es el tiempo de servicio promedio, definido
como:
donde Ttx es el tiempo de
transmisión de la ráfaga de datos, que depende del caudal (Thr) y
del tamaño de ráfaga de datos
(A).
La figura 3 muestra la relación resultante,
calculada para valores típicos de 1 Mbps para caudal
("throughput") y 100 ms para la latencia. En la curva
resultante de la figura 3 se han aplicado los siguientes límites de
porcentaje recomendados a la sensibilidad a latencia a lo largo de
los diferentes valores de SPI, con los siguientes umbrales
resultantes:
La segunda etapa del procedimiento implica
realizar la programación real mejorando la prioridad de aquellas
ráfagas de datos que han sido etiquetadas como sensibles a
latencia.
A continuación se explican dos posibles
realizaciones de esta segunda etapa, aunque cualquier otra
programación que tenga en cuenta la clasificación previa debería ser
válida y debe considerarse como incluida en el alcance de la
presente invención.
1.- La primera solución posible tiene como
objetivo evitar acciones de aumento rápido en usuarios que
transmiten tráfico sensible a latencia, garantizando una
disponibilidad de recursos inicial alta y manteniéndola hasta que
deje de haber tráfico sensible a latencia.
- -
- Programador de enlace ascendente: si la bandera de tráfico sensible a latencia se ajusta a VERDADERO para un equipo de usuario UE, se indica una concesión de planificación sostenida SG/ms al UE. La concesión de planificación SG se mantiene hasta que la bandera se ajusta a FALSO (una de las dos variables supera su umbral). La concesión de planificación SG es configurable en función de SPI, y a mayor prioridad, mayor el valor.
- -
- Programador de enlace descendente: si la bandera de tráfico sensible a latencia está en VERDADERO para un equipo de usuario UE, se indica una capacidad sostenida (SC/ms) al flujo MAC-d del RNC, y la asignación de capacidad se mantiene hasta que la bandera se ajusta a FALSO (una de las dos variables supera su umbral). La capacidad sostenida SC es configurable en función de SPI, y a mayor prioridad, mayor valor.
\vskip1.000000\baselineskip
De modo que SC y SG se definen como:
- SG[i] =
- No garantizado; si bandera de tráfico sensible a latencia = FALSO
- \quad
- SG[i]; si bandera de tráfico sensible a latencia = VERDADERO
- SC[i] =
- No garantizado; bandera de tráfico sensible a latencia = FALSO
- \quad
- SC[i]; bandera de tráfico sensible a latencia = VERDADERO
donde i tiene 16 valores según se
define en los estándares para los 16 valores posibles de
SPI.
\vskip1.000000\baselineskip
La siguiente tabla muestra valores recomendados
para SG[i] y SC [i]:
Con esta flexibilidad en la configuración, puede
proporcionarse a las clases de mayor prioridad un mejor rendimiento
en términos de retardo. Para clases de mayor prioridad, puede
definirse mayor SG/ms y SC/ms, garantizando una mayor disponibilidad
de recursos y proporcionando menos retardo para el tráfico sensible
a latencia.
\vskip1.000000\baselineskip
2.- Algoritmos de prioridad de programación de
HSPA para un usuario dado comprenden las siguientes relaciones:
- -
- para el canal de enlace descendente:
- -
- para el canal de enlace ascendente:
donde:
- R(t) es la tasa de transmisión
instantánea de un equipo de usuario (UE) que puede alcanzarse según
el indicador de calidad de canal notificado (CQI) en el tiempo de
programación t;
- r(t) es la tasa de programación de
usuario en los últimos T segundos;
- SPIweight es el peso del usuario teniendo en
cuenta su prioridad; y
- SchedP es la prioridad de programación en el
enlace descendente para cada usuario calculada cada 2 ms para
decidir qué datos de usuario se transmitirán.
- Tasa_Transmisión_Concedida es la tasa de
transmisión instantánea de usuario asignada a cada usuario en el
enlace ascendente.
- Max_Tasa_Transmisión_Datos es el máximo ancho
de banda posible en términos de tasa de transmisión de bits para el
enlace ascendente.
Por tanto, el parámetro SPIweight afecta a la
prioridad eficaz de una ráfaga de datos tanto en el canal de enlace
ascendente como en el de enlace descendente:
- Enlace descendente: el programador calcula las
diferentes prioridades de los paquetes cada 2 ms teniendo en cuenta
las diferentes entradas, y entonces se asigna el canal de HSDPA al
paquete con la prioridad más alta (SchedP). Si el canal de HSDPA
permite enviar más de un paquete por intervalo de tiempo de
transmisión (TTI), entonces se elige el paquete con la siguiente
prioridad más alta.
Normalmente, el SPIweight es un peso relativo
entre diferentes usuarios, y de este modo se da un valor a cada
parámetro de SPI (hay un máximo de 16 valores de SPI diferentes) y
se define en los estándares 3GPP. Cada usuario tiene un valor de SPI
(de 0 a 16) y para cada valor de SPI hay un SPIweight configurado en
el RNC.
- Enlace ascendente: el programador asigna cada
10 ms recursos de enlace ascendente disponibles que no hayan sido
asignado aún a los usuarios de DCH (canal dedicado) a los usuarios
de E-DCH (canal dedicado mejorado) cuando tienen
datos para enviar. Si se produce una sobrecarga en cualquiera de los
recursos gestionados por el programador (es decir, interfaz Uu o
hardware), el programador calcula cuánto de los recursos es
necesario liberar para resolver la situación de sobrecarga,
compartiendo los recursos entre los usuarios.
Haciendo uso de los procedimientos descritos, la
prioridad eficaz de ráfagas de datos etiquetadas como tráfico
sensible a latencia puede mejorarse eligiendo un valor de SPIweight
diferente, dependiendo de si dicha ráfaga de datos está etiquetada.
Este valor depende, preferentemente, del valor de SPI de la ráfaga
de datos, según se muestra en el siguiente ejemplo, que contiene
valores recomendados para los SPIweight:
\vskip1.000000\baselineskip
La figura 4 muestra un ejemplo gráfico de la
evolución de SPIweight[i] frente al tamaño de ráfaga de
datos. Como los umbrales son configurables en función de SPI, para
este ejemplo, para la prioridad más alta (i=0) las ráfagas de datos
inferiores a MaxBS = MaxCBR = 100 kbytes han sido considerado como
tráfico sensible a latencia, dándoles mayor SPIweight (100) y por lo
tanto una latencia inferior, mientras que para SPI=2 sólo las
ráfagas de datos inferiores a MaxBS = MaxCBR = 500 bytes se han
considerado tráfico sensible a latencia (con un SPIweight de
70).
La diferenciación en la carga de QoS dota a los
usuarios de alta prioridad de un mejor rendimiento en términos de
retardo y no sólo en tasa de transmisión de bits.
La invención, obviamente, no se limita a las
realizaciones específicas descritas en el presente documento, sino
que también abarca cualquier variación que pueda considerarse por
cualquier experto en la técnica (por ejemplo, en lo concerniente a
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 (12)
1. Método para programas tráfico en un canal de
comunicación de una red de comunicaciones móviles, compartiéndose el
canal de comunicación por una pluralidad de equipos de usuario que
comprende:
- -
- etiquetar como tráfico sensible a latencia cualquier ráfaga de datos que verifica que:
- -
- la cantidad de datos de dicha ráfaga de datos añadida a una cola de transmisión en un instante dado, es inferior a un primer umbral; y
- -
- la cantidad de datos de dicha ráfaga de datos añadida a una cola de transmisión a lo largo de la duración de una ventana de tiempo es inferior a un segundo umbral;
- -
- priorizar la transmisión de ráfagas de datos etiquetadas como tráfico sensible a latencia.
\vskip1.000000\baselineskip
2. Método según la reivindicación 1, en el que
la longitud de la ventana de tiempo se ajusta dinámicamente para
cada tráfico de usuario de servicio según el caudal de dicho
usuario.
3. Método según cualquier reivindicación
anterior, en el que los umbrales primero y segundo se ajustan como
una función de un indicador de prioridad de la ráfaga de datos,
dependiendo dicho indicador de prioridad del tipo de tráfico portado
por dicha ráfaga de datos.
4. Método según la reivindicación 3, en el que
dicho indicador de prioridad es el campo SPI según se define en el
protocolo HSPA.
5. Método según cualquiera de las
reivindicaciones 1-4, en el que la etapa de
priorizar ráfagas de datos etiquetadas como tráfico sensible a
latencia se realiza ajustando un peso que modifica un indicador de
prioridad de la ráfaga de datos, dependiendo dicho indicador de
prioridad del tipo de tráfico portado por dicha ráfaga de datos,
donde dicho peso depende de si la ráfaga de datos está etiquetada
como tráfico sensible a latencia.
6. Método según la reivindicación 5, en el que
dicho peso depende de dicho indicador de prioridad de la ráfaga de
datos.
7. Método según la reivindicación 5, en el que
dicho indicador de prioridad es el campo SPI definido en el
protocolo HSPA y dicho peso se ajusta en el campo SPIweight definido
en el protocolo HSPA.
8. Método según cualquiera de las
reivindicaciones 1-4, en el que la etapa de
priorizar ráfagas de datos etiquetadas como tráfico sensible a
latencia se realiza asignando un ancho de banda preestablecido a las
ráfagas de datos mientras las ráfagas de datos permanezcan
etiquetadas como tráfico sensible a latencia.
9. Método según la reivindicación 8, en el que
el valor de dicho ancho de banda preestablecido depende de un
indicador de prioridad de la ráfaga de datos, dependiendo dicho
indicador de prioridad del tipo de tráfico portado por dicha ráfaga
de datos.
10. Método según la reivindicación 9, en el que
dicho indicador de prioridad es un campo SPI según se define en el
protocolo HSPA.
11. Un programador de red de una red de
comunicaciones móviles, que comprende medios para llevar a cabo el
procedimiento según cualquier reivindicación anterior.
12. Un dispositivo de red de una red de
comunicaciones móviles que comprende, al menos:
- -
- un detector de tráfico sensible a latencia (10) configurado para etiquetar ráfagas de datos que verifican que:
- -
- la cantidad de datos a partir de dicha ráfaga de datos añadida a una cola de transmisión en un instante dado, es inferior a un primer umbral;
- -
- la cantidad de datos a partir de dicha ráfaga de datos añadida a una cola de transmisión a lo largo de la longitud de una ventana de tiempo es inferior a un segundo umbral;
- -
- un programador de canal (20) configurado para priorizar ráfagas de datos etiquetadas por el detector de tráfico sensible a latencia (10).
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200930300A ES2357631B1 (es) | 2009-06-12 | 2009-06-12 | Método para programar tr�?fico en un canal de comunicaciones. |
| EP10165874A EP2262306A1 (en) | 2009-06-12 | 2010-06-14 | Scheduling traffic in a communication channel |
| US12/814,879 US8767568B2 (en) | 2009-06-12 | 2010-06-14 | Scheduling traffic in a communication channel |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200930300A ES2357631B1 (es) | 2009-06-12 | 2009-06-12 | Método para programar tr�?fico en un canal de comunicaciones. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2357631A1 true ES2357631A1 (es) | 2011-04-28 |
| ES2357631B1 ES2357631B1 (es) | 2012-03-08 |
Family
ID=42308644
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200930300A Active ES2357631B1 (es) | 2009-06-12 | 2009-06-12 | Método para programar tr�?fico en un canal de comunicaciones. |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US8767568B2 (es) |
| EP (1) | EP2262306A1 (es) |
| ES (1) | ES2357631B1 (es) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9065668B1 (en) | 2010-02-02 | 2015-06-23 | Qualcomm Incorporated | Distributed bandwidth control in a communication network |
| US8595374B2 (en) | 2010-12-08 | 2013-11-26 | At&T Intellectual Property I, L.P. | Method and apparatus for capacity dimensioning in a communication network |
| US9994002B2 (en) | 2011-05-23 | 2018-06-12 | Essel Propack Ltd. | Polymer composition for high clarity laminate, process of manufacture and applications thereof |
| US20120320751A1 (en) * | 2011-06-17 | 2012-12-20 | Jing Zhu | Method and system for communicating data packets |
| EP2817931B1 (en) | 2012-02-23 | 2019-10-30 | Telefonaktiebolaget LM Ericsson (publ) | Sub flow based queueing management |
| US9647916B2 (en) * | 2012-10-27 | 2017-05-09 | Arris Enterprises, Inc. | Computing and reporting latency in priority queues |
| US9426077B1 (en) | 2015-02-22 | 2016-08-23 | Erik J. Knight | Method to improve quality of service for real time internet applications |
| CN111385225B (zh) * | 2018-12-28 | 2022-11-22 | 中兴通讯股份有限公司 | 一种数据调度方法、计算机装置及计算机可读存储介质 |
| CN110856216A (zh) * | 2019-11-27 | 2020-02-28 | 航天科技控股集团股份有限公司 | 用于4g/5g高速网络的拥堵数据优先级判断方法 |
| CN113573366A (zh) * | 2020-04-28 | 2021-10-29 | 华为技术有限公司 | 数据传输方法，及相关设备 |
| CN113612700B (zh) * | 2021-08-12 | 2023-11-14 | 北京邮电大学 | 一种低时延零抖动的混合时间敏感流量调度方法及装置 |
| CN115333998B (zh) * | 2022-05-05 | 2023-09-08 | 国网宁夏电力有限公司信息通信公司 | 一种适用于电力通信网络的时间敏感网络流量调度方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070053290A1 (en) * | 2005-09-02 | 2007-03-08 | Broadcom Corporation | Packet attribute based prioritization |
| US20090122717A1 (en) * | 2007-11-05 | 2009-05-14 | Qualcomm Incorporated | Scheduling qos flows in broadband wireless communication systems |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6628668B1 (en) * | 1999-03-16 | 2003-09-30 | Fujitsu Network Communications, Inc. | Crosspoint switch bandwidth allocation management |
| US6957267B2 (en) * | 2000-12-28 | 2005-10-18 | Intel Corporation | Data packet processing |
| US6947409B2 (en) * | 2003-03-17 | 2005-09-20 | Sony Corporation | Bandwidth management of virtual networks on a shared network |
| US7613153B2 (en) * | 2003-11-06 | 2009-11-03 | Interdigital Technology Corporation | Access points with selective communication rate and scheduling control and related methods for wireless local area networks (WLANs) |
| US7835761B2 (en) | 2004-06-21 | 2010-11-16 | Qualcomm Incorporated | Method for distinguishing different types of data content in data packets in a wireless communication system |
| EP1633160A1 (en) * | 2004-09-07 | 2006-03-08 | Nokia Corporation | Admission control method, packet radio system and controller |
| KR100644629B1 (ko) * | 2004-09-18 | 2006-11-10 | 삼성전자주식회사 | 하이브리드 블록 매칭 기반의 움직임 추정 방법 및 그를적용한 프레임 레이트 변환 장치 |
| US7742455B2 (en) | 2004-11-19 | 2010-06-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Scheduling method for wireless packet data channel |
| US8320240B2 (en) * | 2004-11-30 | 2012-11-27 | Broadcom Corporation | Rate limiting and minimum and maximum shaping in a network device |
| KR100651033B1 (ko) | 2004-12-06 | 2006-11-29 | 한국전자통신연구원 | 트래픽 종류에 따른 ｌ２ 핸드오버 방법 |
| US8072887B1 (en) * | 2005-02-07 | 2011-12-06 | Extreme Networks, Inc. | Methods, systems, and computer program products for controlling enqueuing of packets in an aggregated queue including a plurality of virtual queues using backpressure messages from downstream queues |
| CN100488207C (zh) * | 2005-09-23 | 2009-05-13 | 华为技术有限公司 | 无源光网络用户终端的运行方法 |
| US8031607B2 (en) * | 2009-01-29 | 2011-10-04 | Alcatel Lucent | Implementation of internet protocol header compression with traffic management quality of service |
-
2009
- 2009-06-12 ES ES200930300A patent/ES2357631B1/es active Active
-
2010
- 2010-06-14 EP EP10165874A patent/EP2262306A1/en not_active Withdrawn
- 2010-06-14 US US12/814,879 patent/US8767568B2/en not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070053290A1 (en) * | 2005-09-02 | 2007-03-08 | Broadcom Corporation | Packet attribute based prioritization |
| US20090122717A1 (en) * | 2007-11-05 | 2009-05-14 | Qualcomm Incorporated | Scheduling qos flows in broadband wireless communication systems |
Non-Patent Citations (3)
| Title |
|---|
| 17.01.2005, Wenjie LI and Bin Liu: "Packet-mode Priority Scheduling for Terabit Core Routers" Parallel and Distributed Processing and Applications vol. 3358/2005, 17 Enero 2005 (2005-01-17), páginas 550-555, ISBN:978-3-540-24128-7. Página 551 línea1 a 22. * |
| 22.02.2008, Mun Choon Chan et Al, " Improving TCP/IP Performance over Third-Generation Wireless Networks¿. Transactions on Mobile Computing 2008, Vol. 7 Nº 4. IEEE Piscataway, NJ, USA. 22.02.2008. Páginas 430; ISSN 1536-1233. Epígrafes 5, 6 y 7 * |
| GARRIGA B ET AL: "QoS Load Differentiation Application in aUTRAN Live Network" 2009 IEEE 69TH VEHICULAR TECHNOLOGY CONFERENCE; Abril 26-29, 2009, Barcelona, España, IEEE, PISCATAWAY, NJ, USA, 26 April 2009 (2009-04-26), páginas 1-8, ISBN: 978-1-4244-2517-4. Todo el documento. * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2262306A1 (en) | 2010-12-15 |
| ES2357631B1 (es) | 2012-03-08 |
| US20110019563A1 (en) | 2011-01-27 |
| US8767568B2 (en) | 2014-07-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2357631A1 (es) | Método para programar tráfico en un canal de comunicaciones. | |
| JP5763811B2 (ja) | 移動通信システムにおけるバッファ状態報告 | |
| ES2622393T3 (es) | Asignación de recursos de enlace ascendente dentro de un sistema de comunicación móvil | |
| ES2478018T3 (es) | Estación móvil, dispositivo de estación base, método de control de comunicación y sistema de comunicación móvil | |
| JP5188568B2 (ja) | 移動通信システムにおけるスケジューリング関連情報の通信 | |
| ES2714325T3 (es) | Control de la congestión de una red de comunicación utilizando prioridad de asignación y retención | |
| ES2854823T3 (es) | Notificación de estado de memoria intermedia adaptativa | |
| ES2376060T3 (es) | Control de congestión dentro de una red de acceso radio. | |
| CN109155762B (zh) | 数据传输的方法及装置 | |
| ES2281445T3 (es) | Metodo y sistema para planificar en enlace ascendente el trafico de paquetes de datos en un sistema inalambrico. | |
| ES2575453T3 (es) | Procedimientos y aparatos para proporcionar información de planificación de forma eficiente | |
| ES2532518B1 (es) | Elemento de red y procedimiento para coordinar el uso de recursos radio entre redes de acceso radio | |
| Dighriri et al. | Comparison data traffic scheduling techniques for classifying QoS over 5G mobile networks | |
| EP3465989A1 (en) | End-to-end prioritization for mobile base station | |
| KR101502160B1 (ko) | 이동 통신 시스템에서 이동 단말의 우선순위 보고 장치 및방법 | |
| ES2551353T3 (es) | Método para la puesta en práctica de una combinación de macrodiversidad y sistema y aparato asociados | |
| US9439106B2 (en) | Mobile backhaul dynamic QoS bandwidth harmonization | |
| US20140247833A1 (en) | Prioritization of data packets | |
| US10405237B2 (en) | Air-time fair transmission regulation without explicit traffic specifications for wireless networks | |
| US11304228B2 (en) | Utilization of unused long-term UL assignments | |
| ES2448792T3 (es) | Congestión de tráfico en controladores de red radio | |
| ES2334963B1 (es) | Metodo para reducir la congestion en la interfaz iub en redes utran segun el establecimiento de prioridad del usuario. | |
| ES2394145T3 (es) | Método y estación móvil para petición de recursos de enlace ascendente | |
| ES2442974A2 (es) | Dispositivo de control de planificación, analizador de dispositivo de equipo de usuario y método de priorización de calidad de servicio que hace uso de los mismos | |
| EP1652342B1 (en) | Method, access point and program product for providing bandwidth and airtime fairness in wireless networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG2A | Definitive protection |
Ref document number: 2357631 Country of ref document: ES Kind code of ref document: B1 Effective date: 20120308 |