ES2364967T3 - Control de acceso para peticiones de canal multifusión. - Google Patents

Control de acceso para peticiones de canal multifusión. Download PDF

Info

Publication number
ES2364967T3
ES2364967T3 ES04704377T ES04704377T ES2364967T3 ES 2364967 T3 ES2364967 T3 ES 2364967T3 ES 04704377 T ES04704377 T ES 04704377T ES 04704377 T ES04704377 T ES 04704377T ES 2364967 T3 ES2364967 T3 ES 2364967T3
Authority
ES
Spain
Prior art keywords
user
bandwidth
request
session
allowed
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.)
Expired - Lifetime
Application number
ES04704377T
Other languages
English (en)
Inventor
Rolf Engstrand
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2364967T3 publication Critical patent/ES2364967T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/44—Star or tree networks
    • 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/15—Flow control; Congestion control in relation to multipoint traffic
    • 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/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/806—Broadcast or multicast traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data

Abstract

El método para el control de acceso en un sistema de multidifusión cuando la distribución de los datos desde una fuente (VS) en un enlace común (L3) a al menos dos usuarios (U1-U12) a través de un nodo (BN21), se caracteriza por los siguientes pasos: - asignar un peso a cada usuario (U1-U12) asociado con el nodo (BN21), cuyos pesos determinan cada ancho de banda permitido del usuario es decir el ancho de banda permitido a usar fuera del ancho de banda disponible en el enlace común (L3); - recibir en el nodo (BN21), una petición de unirse a una sesión de multidifusión (S81), desde un usuario (U1); - comparar en el nodo (BN21), el uso del ancho de banda real por el usuario (U1) calculado como la suma de la parte del ancho de banda del usuario de cada sesión utilizada en el enlace común (L3) incluyendo la nueva petición, con el ancho de banda del usuario (U1); - denegar la petición si el ancho de banda permitido es menor que el ancho de banda real.

Description

Campo técnico de la invención
La presente invención se refiere a los métodos y adaptaciones para el control de acceso en un sistema de multidifusión cuando los datos se distribuyen desde una fuente a al menos dos usuarios.
Descripción de la técnica relacionada
Es posible enviar vídeo sobre redes de paquetes tales como las redes IP y Ethernet. Dado que la secuencia de paquetes necesaria para producir imágenes en movimiento en la pantalla de TV tiene considerable ancho de banda, muchas redes no tienen suficiente ancho de banda total para proporcionar secuencias de datos de vídeo únicas a cada usuario. Para programas de TV vistos por varios usuarios (destinatarios), es suficiente enviar una secuencia de paquetes desde la fuente, y duplicar esta secuencia solamente en los puntos en la red en los que hay más de un puerto de salida, que conduce a un espectador. De acuerdo con este esquema, cualquier enlace entre un destinatario y la fuente transporta exactamente una copia de la secuencia de paquetes. Un enlace que no está entre la fuente y un destinatario no transporta la secuencia de paquetes. Esta técnica se llama multidifusión. La multidifusión es una forma valiosa de ahorrar ancho de banda cuando los datos van a ser enviados a varios destinatarios al mismo tiempo.
En algunos sistemas de multidifusión, el control de en qué enlaces se copia la secuencia de paquetes recae en los destinatarios. Las secuencias de datos se dirigen a direcciones destino más abstractas. Estas direcciones no representan conjuntos estáticos de destinos. Son etiquetas de identificación, que los usuarios y la red usan cuando se negocia sobre dónde van a ser copiadas las secuencias. Estas direcciones se llaman direcciones de multidifusión. De acuerdo con algunos protocolos para la negociación sobre las secuencias de multidifusión, las fuentes envían paquetes dirigidos con direcciones de multidifusión en la red. Otros nodos llegan a ser destinatarios de la secuencia de multidifusión solicitando que sea así. El IGMP es un protocolo para que los ordenadores centrales en las redes IP negocien con los conmutadores Ethernet sobre qué secuencias de multidifusión van a recibir. En algunas redes hay regiones, que no tienen suficientes recursos para transferir todas las secuencias de multidifusión, que los nodos podrían solicitar. Esto es razonable dado que la multidifusión está casi manejando grandes secuencias de datos. O, dicho de otra manera, si hay suficiente ancho de banda para todas las secuencias de datos en todas partes, no habría necesidad de multidifusión. La esperanza de los creadores de tales redes es que las peticiones sean suficientemente congruentes (nodos cercanos entre sí que piden las mismas secuencias de multidifusión a alguna extensión) para que los usuarios sean suficientemente satisfechos. Los recursos que pueden ser limitados incluyen el ancho de banda total y el número total de secuencias.
Para el caso cuando la red no es capaz de cumplir todas las peticiones de secuencias de multidifusión hay necesidad de un árbitro o dispensador de recursos. Un aparato de transmisión de paquetes se revela en la patente US 2003/0043840. Un árbitro de paquetes selecciona los paquetes mediante un algoritmo prescrito y requiere la transmisión del paquete. La patente US describe un sistema más bien estático en el que las necesidades actuales no se tienen en consideración y en el que la equidad se ha dejado a un lado. Dado que la carga en la red es dependiente de la congruencia de las peticiones, las técnicas usadas para la asignación de recursos en el caso de unidifusión no se pueden aplicar directamente. En el caso de unidifusión, la carga en la red se puede calcular añadiendo las cargas causadas por los usuarios individuales. En el caso de multidifusión, la petición de una nueva secuencia añade la nueva secuencia a la carga, mientras que la petición de una secuencia que ya se hizo fluir a otro usuario conectado al mismo nodo de red añade poco o nada a la carga en este nodo. Por lo tanto los métodos para limitar la utilización de recursos para los usuarios unidifusión no se pueden aplicar a los usuarios de multidifusión con razonable eficiencia. Límites de ancho de banda suficientemente bajos para asegurar que el sistema no se sobrecarga provocarían la infrautilización severa de los recursos de la red.
Resumen de la invención
La presente invención resuelve los problemas relativos a los conflictos de recursos en un sistema de multidifusión. Los problemas se resuelven mediante la invención limitando la accesibilidad de ancho de banda a los usuarios antes de que ocurran los conflictos de recursos.
Más en detalle los problemas se solventan por la invención mediante un método para el control de acceso en el sistema de multidifusión cuando se distribuyen los datos desde una fuente a los usuarios en un enlace común a través de un nodo. El nodo comprende un árbitro de petición dispuesto para seleccionar los datos desde la fuente a los usuarios. El método comprende los siguientes pasos:
-Asignar un peso a cada usuario asociado con el nodo, cuyos pesos determinan cada ancho de banda permitido del usuario es decir el ancho de banda a usar fuera del ancho de banda disponible en el enlace común.
-Recibir una petición de unión a una sesión de multidifusión, desde un usuario al nodo.
-Comparar en el nodo, el uso del ancho de banda real por el usuario calculado como la suma de la parte de ancho de banda del usuario de cada sesión usada en el enlace común incluyendo la nueva petición, con el ancho de banda permitido de los usuarios.
-Denegar la petición si el ancho de banda permitido es menor que el ancho de banda real o a la inversa, la petición se permite si el ancho de banda permitido es mayor que el ancho de banda real.
Una ventaja de la invención es que la denegación de acceso afecta a los grandes usuarios como una limitación de a cuánta información de multidifusión tienen acceso más que afectar a los usuarios que están intentando ir de ninguna información a alguna información. Esto significa una probabilidad mayor de éxito para los usuarios que están intentando obtener su primer canal a costa de los usuarios que obtiene una menor probabilidad de ver muchos canales.
Otra ventaja es que se ponen a disposición un mayor número de canales para aquéllos que ven los canales, los cuales también son vistos por otros. De esta manera, la capacidad de cargar la red de distribución se iguala. Los usuarios obtienen oportunidades más equitativas. O más bien, el operador tiene el control sobre las oportunidades que los espectadores tienen de cargar la red.
La invención se describirá ahora más en detalle con la ayuda de las realizaciones preferentes en conexión con los dibujos adjuntos.
Breve descripción de los dibujos
La Figura 1 muestra una ilustración esquemática de bloques de un sistema de comunicación de multidifusión usado para transferir datos desde una fuente de vídeo a través de un árbitro de petición a los usuarios en un destino.
La Figura 2 revela una tabla en la que se muestran los usuarios que se suscriben a distintas sesiones.
La Figura 3 revela un diagrama de flujo que ilustra un método para evitar los conflictos de recursos en un sistema de multidifusión.
La Figura 4 muestra una ilustración esquemática de bloques de un sistema de comunicación de multidifusión usado para transferir los datos desde una fuente de vídeo a través de árbitros de petición a los usuarios en un destino.
La Figura 5 revela una ilustración esquemática de bloques de un nodo de ramal.
Descripción detallada de las realizaciones
En la figura 1 se revela un sistema de transmisión de multidifusión para la transferencia de vídeo en una primera realización. El sistema de transmisión transmite y distribuye las secuencias de vídeo desde una fuente de vídeo VS a varios usuarios U1-U96. Los usuarios, que son receptores o distribuidores locales de las secuencias de vídeo, se simbolizan con recuadros en la figura 1 pero en aras de la claridad de la figura 1, solamente se muestran en la figura los usuarios U1, U2, U12, U85 y U96. El sistema de multidifusión comprende una parte de la red fuente S, una parte de la red de acceso AN, y una parte de la red destino DEST. La red de acceso AN, es una red de transmisión de paquetes que puede ser del tipo orientada a conexión o sin conexión. La fuente es en este ejemplo una fuente de vídeo VS y el destino consta de distintos usuarios U1-U96 situados por ejemplo en las oficinas u hogares. En este ejemplo se conectan noventa y seis usuarios divididos en grupos de doce a distintos nodos de ramal BN21-BN28 en la red de acceso, es decir se conectan doce usuarios a cada nodo de ramal. La red de acceso AN consta de conmutadores Ethernet ES1 y ES2 que distribuyen los datos entre la fuente VS y los nodos de ramal BN21-BN28. Un primer enlace L1 conecta la fuente de vídeo VS al conmutador Ethernet ES1, un segundo enlace L2 conecta el conmutador Ethernet ES1 al conmutador Ethernet ES2 y un tercer enlace L3 conecta el conmutador Ethernet ES2 a un nodo de ramal BN21. 200 sesiones de vídeo están disponibles a partir del servidor de vídeo VS. El tercer enlace L3, que también se llama un enlace de nodo de ramal común L3 es un enlace de 100 Mbit/s. El nodo de ramal BN21 es una unidad de Multiplexación que distribuye los datos que llegan al nodo para los usuarios U1-U12, a través de enlaces ADSL de 8 Mbit/s. El usuario U1 es un distribuidor en un hogar al que se conectan un TV y un PC. El nodo de ramal BN21 comprende un árbitro de petición ARB. El árbitro considera todas las peticiones de ancho de banda concedidas actualmente, las condiciones contratadas para todos los usuarios U1-U12 y los recursos disponibles. A partir de estos hechos el árbitro determina para cada petición si se debería conceder o no. Esto se explicará además más adelante.
De acuerdo con la invención, a cada usuario se le asigna un peso para determinar cuánto ancho de banda de multidifusión se va a permitir recibir a cada usuario. El peso se asigna cuando se configura el sistema. La disponibilidad de ancho de banda es por este medio proporcional al peso asignado. El peso asignado se traduce en el ancho de banda disponible para el usuario, es decir el ancho de banda permitido, usando un factor de conversión que disminuye con la carga real en el tercer enlace L3.
imagen1
Un ancho de banda real del usuario en un enlace se calcula como la suma de la cuota de los usuarios en todas las sesiones a las que están suscritos. Si el usuario está suscribiéndose a las sesiones S1, S2…Sm, el número de abonados a estas sesiones es n1, n2…nm y los anchos de banda son b1, b2…bm, respectivamente. El ancho de banda real de los usuarios es la suma de bi/ ni para todas esas sesiones.
5 La figura 2 revela una tabla de usuarios U1-U12 en relación con las sesiones suscritas en el tercer enlace L3 fuera de las doscientas sesiones S1 -S200. Como ya se dijo, el tercer enlace es un enlace de 100 Mbit/s. En este ejemplo se reserva un ancho de banda de 50 Mbit/s para las sesiones suscritas. En la figura 2 se puede ver que el U1 se ha suscrito a las sesiones S1, S2…S51 y que el U6 se suscribe a las sesiones S2…S41. En este ejemplo cada sesión suscrita requiere 1,5 Mbit/s fuera del ancho de banda de 50 Mbit/s reservado en el enlace L3. En la figura 2 se puede ver que diecisiete sesiones diferentes ocupan el tercer enlace L3 y consecuentemente 50-17x1,5=24,5 Mbit/s permanecen disponibles en el tercer enlace. Este es el denominado ancho de banda disponible.
Un método de acuerdo con la invención se explicará ahora. El método comprende los siguientes pasos:
-Cuando el sistema se configura se asigna a cada usuario un peso. El peso establece la importancia del usuario. En este ejemplo, a los usuarios U2-U6 se les ha asignado el peso “1”, a los U7-U12 se les asigna
15 el peso “2”, a los U13-U18 se les asigna el peso “3” y a los U19-U24 les ha sido asignado el peso “4”. Al usuario U1 le ha sido asignado el peso “3”. El peso “1” significa en este ejemplo que se permite al usuario usar el 20% del ancho de banda restante del tercer enlace L3, “2” supone el 15%, “3” supone el “10” y “4” supone el 5%.
-Una petición de unión a la sesión se recibe en el nodo de ramal BN desde el usuario U1. El U1 requiere unirse a la sesión S81. El árbitro ARB 21 comienza a determinar el ancho de banda real del U1. Como se puede ver en la figura 2, el U1 es ya parte de las sesiones S1, S2y S51. El U1 solo usa la sesión S1 mientras que el U1 comparte S2 con otros ocho usuarios y S51 con otros dos usuarios. La sesión S81 está ya compartida antes de la petición del U1 por otros dos usuarios U8 y U12. Como se dijo, cada sesión requiere 1,5Mbit/s de ancho de banda y el ancho de banda real del U1 se calcula por este medio como la suma de la
de cada sesión usada, incluyendo la nueva petición, es decir
2,167 Mbit/s más la parte de ancho de banda de la nueva sesión
= 0,5 Mbit/s. El ancho de banda real del U1 es por este medio 2,167+0,5=2,667 Mbit/s.
-El árbitro determina el ancho de banda disponible. En la figura 2 se puede ver que se reservan diecisiete sesiones en el tercer enlace L3. Esto significa que está disponible un ancho de banda de 50-17x1,5 Mbit/s en el tercer enlace L3, es decir está disponible 24,5 Mbit/s.
-El árbitro determina el ancho de banda disponible para el U1, es decir el ancho de banda permitido. El ancho de banda permitido se calcula como el ancho de banda disponible en el enlace L3 en relación con el peso del U1. El peso determina qué cuota relativa del ancho de banda reservado para este tipo de sesiones
35 al que el usuario tiene derecho. El ancho de banda puesto a disposición para el usuario es proporcional por este medio al peso asignado al usuario. En este ejemplo, el peso del U1 es “3” es decir al U1 se le permite usar el 10% del ancho de banda disponible. El ancho de banda permitido del U1 es por este medio 0,1x24,5=2,45 Mbit/s.
-El árbitro compara el ancho de banda real del U1 de 2,667 Mbit/s con el ancho de banda permitido del U1 de 2,45 Mbit/s y encuentra que el ancho de banda permitido es menor que el ancho de banda real.
-El árbitro deniega la petición desde el U1.
Distintos escenarios serán ahora concebidos para resaltar las ventajas de la invención. Por ejemplo:
-Suponiendo que el ancho de banda disponible en el tercer enlace L3 es más que 24,5 Mbit/s es decir que menos usuarios se han suscrito a las sesiones. Supongamos que el ancho de banda disponible es de 30
45 Mbit/s. El peso del U1 es “3” es decir al U1 se le permite usar el 10%. Esto a su vez conducirá a una situación en la que el árbitro compara el ancho de banda real del U1 de 2,667 Mbit/s con el ancho de banda permitido del U1 de 3,0 Mbit/s y encuentra que el ancho de banda permitido es mayor que el ancho de banda real. Consecuentemente el árbitro permitirá la petición desde el U1.
-Volviendo de nuevo al ejemplo original y suponiendo que el U1 ha sido ponderado como un usuario más importante y en lugar del peso “3” tiene el peso “2” es decir al U1 se le permite usar el 15%. Esto conducirá a una situación en la que el ancho de banda permitido del U1 es 0,15x24=3,6 Mbit/s. Esto a su vez conducirá a una situación en la que el árbitro compara el ancho de banda real del U1 de 2,667 Mbit/s con el ancho de banda permitido de U1 de 3,6 Mbit/s y encuentra que el ancho de banda permitido es mayor que
el ancho de banda real. Consecuentemente el árbitro permitirá la petición desde el U1.
-Volvemos de nuevo al ejemplo original y suponemos que el U1 durante el primer momento solicita unirse a la sesión. En este caso el ancho de banda real del U1 será de 1,5/3 = 0,5 Mbit/s en lugar del anterior de 2,167+0,5=2,667 Mbit/s. Esto a su vez conducirá a una situación en la que el árbitro compara el ancho de banda real del U1 de 0,5 Mbit/s con el ancho de banda permitido del U1 de 2,45 Mbit/s y encuentra que el ancho de banda real es menor que el ancho de banda permitido. Consecuentemente el árbitro permitirá la petición desde el U1.
-Volvemos de nuevo al ejemplo original y suponemos que el U1 es el primer abonado que solicita unirse a la sesión S81. En este caso el ancho de banda real del U1 será 2,167+1,5/1=3,667 Mbit/s. Comparamos si el U1 en su lugar fue el décimo usuario en unirse a la sesión S81. En este caso el ancho de banda real del U1 sería 2,167+1,5/10=2,317 Mbit/s. Cuando se comparan los dos escenarios se puede ver que el árbitro permitirá la petición cuando el U1 es el número diez pero deniega la petición si el U1 es el número uno.
Supongamos que la sesión requerida S81 ya se usó por alguien más. Este es realmente el caso con la sesión requerida S81 en la primera realización anterior. En este caso la nueva petición no implicará ninguna carga adicional y el usuario U1 se puede permitir usar la sesión incluso si no se justifica realmente. El método de acuerdo con esta variación de la primera realización permitirá esto, y comprende los siguientes pasos adicionales después de que el árbitro ha comparado el ancho de banda real del U1 de 2,667 Mbit/s con el ancho de banda permitido del U1 de 2,45 Mbit/s (comparar el método en la primera realización):
-El árbitro ARB21 descubre que la sesión solicitada S81 ya se usa por al menos otro usuario U8, U12. Esta información se almacena en una memoria en el árbitro ARB21.
-El árbitro permite la petición desde el U1.
Volvemos de nuevo ahora a la primera realización. Supongamos, como otra variación de la primera realización que el usuario quiere volver a la sesión S81 después de una breve pausa de publicidad de TV. El usuario es visto por este medio como que se suscribe a la sesión también durante algún tiempo después de que ha finalizado la suscripción real. Durante un periodo de tiempo después de que ha finalizado la suscripción real, se garantiza al usuario de que es capaz de “volver”. El operador fija un denominado tiempo de habilitación que se define “corto”. Si no se permitiese al usuario volver después de una pausa publicitaria corta causaría insatisfacción. El método de acuerdo con esta variación de la primera realización comprende los siguientes pasos adicionales después de que el árbitro ha comparado el ancho de banda real del U1 de 2,667 Mbit/s con el ancho de banda permitido del U1 de 2,45 Mbit/s (ver el método en la primera realización):
-El árbitro ARB21 encuentra que el usuario U1 usó la sesión S81 hace un tiempo que es menor que el tiempo de habilitación predefinido. Esta información se almacena en una memoria en el árbitro ARB21.
-El peso del usuario se cambia temporalmente desde “3” a “2”, es decir el usuario llega a ser un usuario más importante.
-El árbitro permite la petición desde el U1.
-Cuando el usuario más tarde abandona la sesión, el peso del usuario se cambiará de vuelta a “3”.
Para evitar que la navegación rápida a través de las sesiones acumule suscripciones adicionales que causen al árbitro denegar suscripciones, hay necesidad de filtrar las suscripciones reales muy cortas. El operador por este medio define un denominado tiempo de garantía que define el tiempo que debe estar un usuario en una sesión para que se le permita volver más tarde a la sesión. Esto supone una variación del método anterior por la cual el árbitro también comprueba el tiempo de garantía después de haber comprobado el tiempo de habilitación. Se cambiará por este medio el peso desde “3” a “2” solamente si el usuario usó realmente la sesión hace un tiempo que es menor que el tiempo de habilitación predefinido y si el usuario en ese tiempo usó la sesión durante un periodo de tiempo que excede el tiempo de garantía predefinido.
En la figura 3 se pueden ver los pasos más esenciales del método. El diagrama de flujo va a ser leído junto con las figuras mostradas anteriormente. El método de acuerdo con la invención comprende los siguientes pasos:
-Cuando el sistema se configura a cada usuario se le asigna un peso. Al usuario U1 se le ha asignado el peso “3”. Este paso se puede ver en el diagrama de flujo mediante un bloque 101.
-Una petición de unión a una sesión se recibe para el nodo de ramal BN desde el usuario U1. El U1 solicita unirse a la sesión S81. Este paso se puede ver en el diagrama de flujo mediante un bloque 102.
-El árbitro ARB21 determina el ancho de banda real del U1. El ancho de banda real del U1 es por este medio 2,167+0,5=2,667 Mbit/s. Este paso se puede ver en el diagrama de flujo mediante un bloque 103.
-El árbitro determina el ancho de banda disponible en el tercer enlace L3. Un ancho de banda de 50-17x1,5 Mbit/s está disponible, es decir están disponibles 24,5 Mbit/s. Este paso se puede ver en el diagrama de flujo mediante un bloque 104.
-El árbitro determina el ancho de banda permitido del U1. El ancho de banda permitido del U1 es de 0,1x24,5=2,45 Mbit/s. Este paso se puede ver en el diagrama de flujo mediante un bloque 105.
-El árbitro compara el ancho de banda real del U1 de 2,667 Mbit/s con el ancho de banda permitido del U1 de 2,45 Mbit/s y encuentra que el ancho de banda permitido es menor que el ancho de banda real. Este paso se puede ver en el diagrama de flujo mediante un bloque 106.
-El árbitro deniega la petición desde el U1. Este paso se puede ver en el diagrama de flujo mediante un bloque 107.
Se revela una segunda realización en la figura 4. La figura muestra el mismo sistema de multidifusión que fue revelado anteriormente en la figura 1. En este ejemplo no solamente se considera el tercer enlace L3 que sea un enlace crítico con respecto a los conflictos. También hay un riesgo potencial de conflictos en el segundo enlace L2. El segundo enlace L2 es un enlace de 100 Mbit/s y se llama enlace de Ethernet común L2. También el Conmutador Ethernet ES2 comprende en esta realización un árbitro de petición ARB2. Esta segunda realización es una continuación de la primera realización pero se supone que el árbitro ARB21 no denegó la petición anterior desde el U1 debido por ejemplo a que el usuario U1 estaba ponderado “2” de acuerdo con el escenario tratado anteriormente. Cuando el sistema fue configurado a cada usuario asociado con el Conmutador Ethernet se le asignó un peso. Al U1, como se mencionó, le fue asignado el peso “2”, a los U2-U12 les fueron asignados los pesos según se dijo en la primera realización mientras que a los usuarios U13-U96 a todos les fue asignado el peso “1”. El método de acuerdo con la invención en la segunda realización comprende los siguientes pasos adicionales:
-Después de que ARB21 ha permitido la petición desde el U1, la petición del U1 de unirse a la sesión S81 se envía desde el nodo de ramal BN21 al Conmutador de Ethernet ES2.
-El árbitro ARB2 en el Conmutador Ethernet ES2 determina el ancho de banda real del U1 en el segundo enlace L2. El U1 ya es parte de las sesiones S1, S2 y S51. Estas sesiones se comparten en el segundo enlace también por alguno de los usuarios U13-U96. El ancho de banda real del U1 se supone por este medio en este ejemplo que es de 1,5 Mbit/s.
-El árbitro de petición ARB2 ahora determina el ancho de banda disponible en el segundo enlace L2. En este ejemplo se supone que un ancho de banda de 3 Mbit/s está disponible en L2.
-El árbitro determina el ancho de banda permitido del U1. El peso del U1 es “2” (15%) y el ancho de banda permitido del U1 consecuentemente es de 0,15x3=0,45 Mbit/s.
-El árbitro compara el ancho de banda real del U1 de 1,5 Mbit/s con el ancho de banda permitido del U1 de 0,45 Mbit/s y encuentra que el ancho de banda permitido es menor que el ancho de banda real.
-El árbitro ARB2 deniega la petición desde el U1.
-El Conmutador Ethernet ES2 envía un mensaje de denegación al nodo de ramal BN21.
-El árbitro de petición ARB21 en el nodo de ramal BN21 también deniega la petición desde el U1 y por este medio libera capacidad en el tercer enlace L3.
En la figura 5, el nodo de ramal BN21 se revela esquemáticamente. El nodo comprende una unidad de multiplexación MU que distribuye los datos desde el tercer enlace L3 a los distintos enlaces ADSL ADSL-1. El nodo también comprende el árbitro de petición ARB21 que comprende una unidad central CU y dos espacios de memoria MEM1 y MEM2. MEM1 comprende la tabla revelada en la figura 2. MEM2 comprende información sobre qué usuarios han abandonado recientemente una sesión solicitada. La unidad central CU trae información desde el tercer enlace, los enlaces ADSL y los espacios de memoria. La CU procesa la información, calcula los anchos de banda y los tiempos, controla la unidad de Multiplexación y distribuye las sesiones seleccionadas a partir del tercer enlace L3 a los enlaces ADSL.
Distintas variaciones son por supuesto posibles dentro del alcance de la invención. La adaptación en la figura 5 se puede construir por ejemplo de manera diferente en tanto en cuanto las funciones de acuerdo con la invención permanezcan. Unos pesos de usuarios se pueden reasignar en cualquier momento. El ancho de banda ocupado por una sesión puede ser fijo o puede variar. La invención en otras palabras no está limitada a lo descrito anteriormente y en los dibujos que muestran las realizaciones sino que se puede modificar dentro del alcance de las reivindicaciones adjuntas.

Claims (11)

  1. REIVINDICACIONES
    1. El método para el control de acceso en un sistema de multidifusión cuando la distribución de los datos desde una fuente (VS) en un enlace común (L3) a al menos dos usuarios (U1-U12) a través de un nodo (BN21), se caracteriza por los siguientes pasos:
    •
    asignar un peso a cada usuario (U1-U12) asociado con el nodo (BN21), cuyos pesos determinan cada ancho de banda permitido del usuario es decir el ancho de banda permitido a usar fuera del ancho de banda disponible en el enlace común (L3);
    •
    recibir en el nodo (BN21), una petición de unirse a una sesión de multidifusión (S81), desde un usuario (U1);
    •
    comparar en el nodo (BN21), el uso del ancho de banda real por el usuario (U1) calculado como la suma de la parte del ancho de banda del usuario de cada sesión utilizada en el enlace común (L3) incluyendo la nueva petición, con el ancho de banda del usuario (U1);
    •
    denegar la petición si el ancho de banda permitido es menor que el ancho de banda real.
  2. 2. El método para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 1, que comprende los siguientes pasos adicionales:
    •
    descubrir que la sesión requerida (S81) se usa por al menos otro usuario (U8, U12);
    •
    permitir la petición desde el U1.
  3. 3. El método para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 1, que comprende los siguientes pasos adicionales:
    •
    percibir que el usuario (U1) usó la sesión (S81) menos de un tiempo de habilitación predefinido atrás;
    •
    cambiar temporalmente el peso del usuario;
    •
    permitir la petición si el ancho de banda permitido es mayor que el ancho de banda real.
  4. 4. El método para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 3, que comprende antes de cambiar el peso del usuario, los siguientes pasos adicionales:
    • percibir que el usuario usó la sesión (S81) durante un periodo de tiempo que excede un tiempo de garantía predeterminado;
  5. 5. El método para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 3 o 4, que comprende los siguientes pasos adicionales:
    •
    el usuario (U1) abandona la sesión requerida S81;
    •
    volver a cambiar el peso del usuario a su valor original.
  6. 6. La adaptación para el control de acceso en un sistema de multidifusión cuando se distribuyen datos desde una fuente (VS) en un enlace común (L3) a al menos dos usuarios (U1-U12) a través de un nodo (BN21), cuya adaptación se caracteriza por:
    •
    los medios para la asignación de un peso a cada usuario (U1-U12) asociado con el nodo (BN21), cuyo peso determina cada ancho de banda permitido del usuario es decir el ancho de banda permitido para usar fuera del ancho de banda disponible en el enlace común (L3);
    •
    los medios en el nodo (BN21) para la recepción de una petición de unirse a una sesión de multidifusión (S81), desde un usuario (U1);
    •
    los medios para comparar en el nodo (BN21), el uso del ancho de banda real por el usuario (U1) calculado como la suma de la parte del ancho de banda del usuario de cada sesión usada en el enlace común (L3) incluyendo la nueva petición, con el ancho de banda permitido del usuario (U1);
    •
    los medios para la denegación de la petición si el ancho de banda permitido es menor que el ancho de banda real.
  7. 7. La adaptación para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 6, que comprende:
    •
    los medios para descubrir que la sesión requerida (S81) se usa por al menos otro usuario (U8, U12);
    •
    los medios para permitir la petición desde el U1 si la sesión requerida (S81) se usa por al menos otro usuario (U8, U12).
  8. 8. La adaptación para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 6, que comprende:
    5 • los medios para percibir que el usuario (U1) usó la sesión (S81) al menos un tiempo de habilitación predefinido atrás;
    •
    los medios para cambiar temporalmente el peso del usuario;
    •
    los medios para permitir la petición si el ancho de banda permitido es mayor que el ancho de banda real.
  9. 9. La adaptación para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 8, que 10 comprende:
    • los medios para percibir que el usuario usó la sesión (S81) durante un periodo de tiempo que excede un tiempo de garantía predeterminado.
  10. 10. La adaptación para el control de acceso en un sistema de multidifusión de acuerdo con la reivindicación 8 o 9, que comprende los medios para cambiar de nuevo el peso del usuario a su valor original.
    15 11. La adaptación para el control de acceso en un sistema multidifusión de acuerdo con cualquiera de las reivindicaciones 6-10 que comprende los medios para calcular el ancho de banda real del usuario (U1).
  11. 12. La adaptación para el control de acceso en un sistema de multidifusión de acuerdo con cualquiera de las reivindicaciones 6-11, que comprende los medios para calcular el ancho de banda permitido del usuario (U1).
    20
ES04704377T 2004-01-22 2004-01-22 Control de acceso para peticiones de canal multifusión. Expired - Lifetime ES2364967T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2004/000073 WO2005071903A1 (en) 2004-01-22 2004-01-22 Access control for multicast channel request

Publications (1)

Publication Number Publication Date
ES2364967T3 true ES2364967T3 (es) 2011-09-19

Family

ID=34806312

Family Applications (1)

Application Number Title Priority Date Filing Date
ES04704377T Expired - Lifetime ES2364967T3 (es) 2004-01-22 2004-01-22 Control de acceso para peticiones de canal multifusión.

Country Status (10)

Country Link
US (1) US7817632B2 (es)
EP (1) EP1730898B1 (es)
KR (1) KR101101071B1 (es)
CN (1) CN100571193C (es)
AT (1) ATE512528T1 (es)
AU (1) AU2004314553B2 (es)
BR (1) BRPI0418412A (es)
ES (1) ES2364967T3 (es)
MX (1) MXPA06007673A (es)
WO (1) WO2005071903A1 (es)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7792025B2 (en) 2005-10-11 2010-09-07 Alcatel Lucent Multi-service session admission control
KR100721367B1 (ko) * 2006-05-23 2007-05-23 한국정보통신대학교 산학협력단 Ｔｄｍ-ｐｏｎ에서 멀티캐스트 트래픽 공유 기반의 공정한차등 대역폭 할당 방법 및 시스템
CN101309158A (zh) * 2007-05-15 2008-11-19 华为技术有限公司 实现组播连接允许控制的方法及装置
EP2003824B1 (en) * 2007-06-12 2012-01-18 Alcatel Lucent Method of performing multicast admission control in a communications network, central admission controller and communications network
US20090022064A1 (en) * 2007-07-18 2009-01-22 Moshe Oron Method and apparatus for monitoring multicast bandwidth to a user
WO2010053253A1 (ko) * 2008-11-07 2010-05-14 엘지전자주식회사 무선통신 시스템에서 대역폭 요청 과정을 수행하는 방법
WO2010053252A2 (ko) 2008-11-07 2010-05-14 엘지전자주식회사 무선통신 시스템에서 대역폭 요청 과정을 수행하는 방법
CN101771476B (zh) * 2009-01-06 2013-04-24 华为技术有限公司 感知无线电中次要用户的频谱接入方法及装置
WO2011067495A2 (fr) * 2009-11-24 2011-06-09 France Telecom Controle d'admission pour abonnement de service
US8995439B2 (en) 2010-05-13 2015-03-31 Comcast Cable Communications, Llc Control of multicast content distribution
US8824467B1 (en) 2011-01-28 2014-09-02 Adtran, Inc. Systems and methods for detecting and controlling multicast bandwidth
US9007898B2 (en) * 2011-02-01 2015-04-14 Google Inc. System to share network bandwidth among competing applications
US9559956B2 (en) * 2011-02-01 2017-01-31 Google Inc. Sharing bandwidth among multiple users of network applications
CN102687541A (zh) * 2012-02-23 2012-09-19 华为技术有限公司 获取无线网络质量信息的方法、设备和系统
FR3011414A1 (fr) * 2013-10-01 2015-04-03 Orange Procede d'abonnement a des flux en provenance de clients multicast
CN104022915B (zh) * 2014-05-19 2017-07-14 华为技术有限公司 一种流量调节方法及装置
US9582442B2 (en) 2014-05-30 2017-02-28 International Business Machines Corporation Intercomponent data communication between different processors
US9563594B2 (en) * 2014-05-30 2017-02-07 International Business Machines Corporation Intercomponent data communication between multiple time zones
US10275379B2 (en) 2017-02-06 2019-04-30 International Business Machines Corporation Managing starvation in a distributed arbitration scheme
JP7043808B2 (ja) * 2017-11-30 2022-03-30 富士通株式会社 通信装置、通信システム、および通信速度制御方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3171241B2 (ja) * 1998-03-06 2001-05-28 日本電気株式会社 通信方法
US6578076B1 (en) * 1999-10-18 2003-06-10 Intel Corporation Policy-based network management system using dynamic policy generation
JP3771153B2 (ja) * 2001-08-29 2006-04-26 三菱電機株式会社 Ｕｔｏｐｉａインタフェース制御装置及び方法並びに該装置に用いるバックワイヤボード
JP2003069641A (ja) * 2001-08-29 2003-03-07 Fujitsu Ltd パケット転送装置
MXPA04005817A (es) * 2001-12-15 2004-09-10 Thomson Licensing Sa Mecanismo de seleccion de anchura de banda de videoconferecia.
US6862456B2 (en) * 2002-03-01 2005-03-01 Cognio, Inc. Systems and methods for improving range for multicast wireless communication
IL150281A0 (en) * 2002-06-18 2002-12-01 Teracross Ltd Method and system for multicast and unicast scheduling
US20040181811A1 (en) * 2003-03-13 2004-09-16 Rakib Selim Shlomo Thin DOCSIS in-band management for interactive HFC service delivery
US7848343B2 (en) * 2004-07-15 2010-12-07 Calix, Inc. Traffic management for a passive optical network terminal

Also Published As

Publication number Publication date
AU2004314553B2 (en) 2009-05-28
US20070263625A1 (en) 2007-11-15
EP1730898A1 (en) 2006-12-13
AU2004314553A1 (en) 2005-08-04
CN1906901A (zh) 2007-01-31
MXPA06007673A (es) 2006-09-04
ATE512528T1 (de) 2011-06-15
BRPI0418412A (pt) 2007-05-15
WO2005071903A1 (en) 2005-08-04
KR20070009549A (ko) 2007-01-18
US7817632B2 (en) 2010-10-19
KR101101071B1 (ko) 2011-12-30
EP1730898B1 (en) 2011-06-08
CN100571193C (zh) 2009-12-16

Similar Documents

Publication Publication Date Title
ES2364967T3 (es) Control de acceso para peticiones de canal multifusión.
US7856017B2 (en) Traffic diversion in an ethernet-based access network
ES2392563T3 (es) Dispositivo de petición de anchura de banda, sistema de petición de anchura de banda, y método de petición de anchura de banda
US9621614B2 (en) Regulating content streams from a weighted fair queuing scheduler using weights defined for user equipment nodes
Crowcroft Internetworking multimedia
KR100985626B1 (ko) 가입 서비스 액세스 제공 방법, 인터페이스 장치 및 가입 서비스 액세스 제공 장치
AU2006200338B2 (en) Method of controlling communication between a head-end system and a plurality of client systems
US7911956B2 (en) Packet level prioritization in interconnection networks
JP4389605B2 (ja) マルチキャスト情報配信システムおよびマルチキャスト情報配信方法
US20060013139A1 (en) Traffic management for a passive optical network terminal
KR20130081280A (ko) 뉴 네트워크의 통신 방법 및 시스템
CN101141616A (zh) 视频会议方法与系统、应用服务器及媒体资源服务器
US20040210927A1 (en) Multicasting systems using distributed user authentication
KR20090015592A (ko) 인스턴트 메신저 기반의 개인 방송 서비스 시스템 및 방법
BRPI0418412B1 (pt) Method and arrangement for control of access in a multi-diffusion system
CN110999233A (zh) 一种管理组播节目的方法、装置和网络设备
Mendes et al. Session-aware popularity resource allocation for assured differentiated services
Wang et al. Scalable IP multicast sender access control for bi-directional trees
UA105355C2 (uk) Спосіб багатопровідникової групової передачі складових
Ashourian et al. Optimization of Scheduling Information in a Network-Based Standard IEEE802. 17 and Measurement for Video Transmission.
Tobagi et al. Assessment of traffic prioritization in switched local area networks carrying multimedia traffic
Jiang et al. DiffStream: A Multi-channel Multimedia Content Dissemination Strategy Using MDC
De Upstream media access control protocol for integrated services (UPIS) in Cable TV networks
BPS2000 Solutions Reference Design
El-Khatib et al. Selecting the QoS parameters for multicast applications based on user profile and device capability