ES2357631B1 - 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 PDF

Info

Publication number
ES2357631B1
ES2357631B1 ES200930300A ES200930300A ES2357631B1 ES 2357631 B1 ES2357631 B1 ES 2357631B1 ES 200930300 A ES200930300 A ES 200930300A ES 200930300 A ES200930300 A ES 200930300A ES 2357631 B1 ES2357631 B1 ES 2357631B1
Authority
ES
Spain
Prior art keywords
data
burst
traffic
bursts
priority
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.)
Active
Application number
ES200930300A
Other languages
English (en)
Other versions
ES2357631A1 (es
Inventor
Francisco Javier DOM�?NGUEZ ROMERO
Beatriz Garriga Muñiz
Clara Serrano Solsona
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone Espana SA
Original Assignee
Vodafone Espana SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Vodafone Espana SA filed Critical Vodafone Espana SA
Priority to ES200930300A priority Critical patent/ES2357631B1/es
Priority to EP10165874A priority patent/EP2262306A1/en
Priority to US12/814,879 priority patent/US8767568B2/en
Publication of ES2357631A1 publication Critical patent/ES2357631A1/es
Application granted granted Critical
Publication of ES2357631B1 publication Critical patent/ES2357631B1/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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.
Campo de la invención
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.
Antecedentes de la invención
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.
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.
Descripción de la invención
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,yaun 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.
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.
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.
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;
-
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.
Las ventajas de la invención propuesta se harán evidentes en la descripción que sigue.
Breve descripción de los dibujos
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.
Descripción detallada de las realizaciones preferidas
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.
De modo que SC y SG se definen como:
SG[i] = No garantizado; si bandera de tráfico sensible a latencia = FALSO
SG[i]; si bandera de tráfico sensible a latencia = VERDADERO
SC[i] = No garantizado; bandera de tráfico sensible a latencia = FALSO
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.
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.
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 (de0a16)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:
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 (13)

  1. REIVINDICACIONES
    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.
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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).
    OFICINA ESPAÑOLA DE PATENTES Y MARCAS
    N.º solicitud: 200930300
    ESPAÑA
    Fecha de presentación de la solicitud: 12.06.2009
    Fecha de prioridad:
    INFORME SOBRE EL ESTADO DE LA TECNICA
    51 Int. Cl. : H04W28/10 (2009.01) H04W72/12 (2009.01)
    DOCUMENTOS RELEVANTES
    Categoría
    Documentos citados Reivindicaciones afectadas
    A
    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. 1-12
    A
    US 2007053290 A1 (MICHELS PETER) 08.03.2007, resumen; párrafo [0012]. 1-12
    A
    US 2009122717 A1 (DAS ARNAB et al.) 14.05.2009, resumen; párrafos [0006-0016],[0043-0069]. 1-12
    A
    WENJIE LI y 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íneas 1-22. 1-12
    A
    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 Abril 2009 (2009-04-26), páginas 1-8, ISBN: 978-1-4244-2517-4. Todo el documento. 1-12
    Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud
    El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:
    Fecha de realización del informe 13.04.2011
    Examinador M. Rivas Sáiz Página 1/4
    INFORME DEL ESTADO DE LA TÉCNICA
    Nº de solicitud: 200930300
    Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) H04W, H04Q Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de
    búsqueda utilizados) INVENES, EPODOC, WIPI, INSPEC
    Informe del Estado de la Técnica Página 2/4
    OPINIÓN ESCRITA
    Nº de solicitud: 200930300
    Fecha de Realización de la Opinión Escrita: 13.04.2011
    Declaración
    Novedad (Art. 6.1 LP 11/1986)
    Reivindicaciones Reivindicaciones 1-12 SI NO
    Actividad inventiva (Art. 8.1 LP11/1986)
    Reivindicaciones Reivindicaciones 1-12 SI NO
    Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).
    Base de la Opinión.-
    La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.
    Informe del Estado de la Técnica Página 3/4
    OPINIÓN ESCRITA
    Nº de solicitud: 200930300
    1. Documentos considerados.-
    A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.
    Documento
    Número Publicación o Identificación Fecha Publicación
    D01
    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. 22.02.2008
  13. 2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración
    El documento D01 se considera el más próximo del estado de la técnica a la invención solicitada.
    El documento D01 describe en el epígrafe 6 un método para programar 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 usuarios. En la sección 6.1 de este epígrafe describe un programador intra-usuario denominado SFP (Short Flow Priority). Un flujo es clasificado como corto o largo en función del número de bytes enviados por el programador. Los flujos cortos son priorizados frente a los flujos largos.
    La diferencia entre el documento D01 y la reivindicación 1 es que D01 clasifica inicialmente todos los flujos como cortos y en función de los bytes transmitidos reclasifica el flujo a largo. La reivindicación 1 tiene en cuenta la cantidad de datos en la cola de transmisión, es decir se clasifican antes de ser transmitidas. El efecto técnico es seleccionar de forma más precisa las ráfagas a las que es necesario dar prioridad por su tamaño, incluso antes de que el programador envíe datos. El problema técnico es como clasificar las ráfagas por su tamaño antes de ser enviadas por el programador. Este problema no se plantea en D01.
    Por tanto, a la vista del razonamiento anterior se concluye que la reivindicación 1 es nueva y implica actividad inventiva (Artículo 6 y 8 de L.P.).
    Las reivindicaciones 2 a 10, dependientes de la reivindicación, 1 también cumplen los requisitos de novedad y actividad inventiva (Artículo 6 y 8 de la LP.).
    Las reivindicaciones independientes 11 y 12 definen respectivamente un programador de red y un dispositivo de red basados en el método anterior. Por tanto, son nuevas e implican actividad inventiva (Artículo 6 y 8 de la LP.).
    Informe del Estado de la Técnica Página 4/4
ES200930300A 2009-06-12 2009-06-12 Método para programar tr�?fico en un canal de comunicaciones. Active ES2357631B1 (es)

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 ES2357631A1 (es) 2011-04-28
ES2357631B1 true 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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9112751B1 (en) * 2010-02-02 2015-08-18 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
WO2013125999A1 (en) * 2012-02-23 2013-08-29 Telefonaktiebolaget L M 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 国网宁夏电力有限公司信息通信公司 一种适用于电力通信网络的时间敏感网络流量调度方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
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
US20070053290A1 (en) * 2005-09-02 2007-03-08 Broadcom Corporation Packet attribute based prioritization
CN100488207C (zh) * 2005-09-23 2009-05-13 华为技术有限公司 无源光网络用户终端的运行方法
US8923157B2 (en) * 2007-11-05 2014-12-30 Qualcomm Incorporated Scheduling QOS flows in broadband wireless communication systems
US8031607B2 (en) * 2009-01-29 2011-10-04 Alcatel Lucent Implementation of internet protocol header compression with traffic management quality of service

Also Published As

Publication number Publication date
EP2262306A1 (en) 2010-12-15
US8767568B2 (en) 2014-07-01
ES2357631A1 (es) 2011-04-28
US20110019563A1 (en) 2011-01-27

Similar Documents

Publication Publication Date Title
ES2357631B1 (es) Método para programar tr�?fico en un canal de comunicaciones.
US10972934B2 (en) End-to-end prioritization for mobile base station
US11997652B2 (en) Scheduling transmissions on channels in a wireless network
US10171369B2 (en) Systems and methods for buffer management
JP3898965B2 (ja) 無線リソース割り当て方法及び基地局
US11026247B2 (en) Transmitting data based on flow input from base station
KR101130376B1 (ko) 패킷화된 무선 통신의 중단
US20060019671A1 (en) QoS differentiation for WCDMA services mapped onto an E-DCH channel
EP1986455A1 (en) Communication of scheduling related information in a mobile communication system
GB2563590A (en) Methods and devices associated with improvements in or relating to an uplink split bearer in new radio
EP3471456A1 (en) Congestion control method, base station, and terminal
KR20050063596A (ko) 큐오에스를 향상시키기 위한 무선 인터넷 단말 장치 및패킷 전송 방법
US20180206264A1 (en) Control information transmission method, transmit end, and receive end
Hassebo et al. Commercial 4G LTE cellular networks for supporting emerging IoT applications
ES2496175T3 (es) Método para reducir la congestión en el interfaz lub en redes UTRAN de acuerdo con el establecimiento de prioridades del usuario
US20140177535A1 (en) Method and apparatus for admission control in a wireless communication system
ES2442974A9 (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
US11706657B2 (en) End-to-end prioritization for mobile base station
CN107431901B (zh) 在蜂窝网络的无线电接口上分配资源的设备和方法
EP1652342B1 (en) Method, access point and program product for providing bandwidth and airtime fairness in wireless networks
Yu et al. Distributed resource reservation mechanism for IEEE 802.11 e-based networks
Lim et al. Modeling of LTE back-hauling through OFDMA-PONs
Sugesti et al. Performance Evaluation of WLAN Channel Utilization of TXOPHCCA for Real-time Applications
Ajib et al. Service disciplines performance for best-effort policies in packet-switching wireless cellular networks
Ayhan et al. A Priority and QoS-Aware Scheduler for LTE Based Public Safety 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