ES2425602T3 - Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados - Google Patents

Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados Download PDF

Info

Publication number
ES2425602T3
ES2425602T3 ES10702712T ES10702712T ES2425602T3 ES 2425602 T3 ES2425602 T3 ES 2425602T3 ES 10702712 T ES10702712 T ES 10702712T ES 10702712 T ES10702712 T ES 10702712T ES 2425602 T3 ES2425602 T3 ES 2425602T3
Authority
ES
Spain
Prior art keywords
flow
end node
request
network
time information
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
ES10702712T
Other languages
English (en)
Inventor
Gael Mace
Jean Le Roux
Claude Chapel
Original Assignee
Thomson Licensing SAS
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 Thomson Licensing SAS filed Critical Thomson Licensing SAS
Application granted granted Critical
Publication of ES2425602T3 publication Critical patent/ES2425602T3/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/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • 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/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/722—Admission control; Resource allocation using reservation actions during connection setup at the destination endpoint, e.g. reservation of terminal resources or buffer space
    • 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/801—Real time 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/826—Involving periods of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/23424—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/222—Studio circuitry; Studio devices; Studio equipment
    • H04N5/262—Studio circuits, e.g. for mixing, switching-over, change of character of image, other special effects ; Cameras specially adapted for the electronic generation of special effects
    • H04N5/268—Signal distribution or switching

Abstract

Método para programar unas reservas de recursos en una red de comunicaciones con paquetes conmutados quecomprende unos nodos extremos (Hi) y unos conmutadores (Sj) de la red central, en donde dicho métodocomprende los pasos, tratados en el nivel de la capa de enlace de datos del modelo de Interconexión de SistemasAbiertos, OSI, de: · incluir una información de tiempo en cada solicitud, emitida por un nodo extremo (Hi) y reenviada por al menosun conmutador (Sj) de la red central, y que solicita una reserva de recursos para recibir un flujo definido porespecificaciones en un momento que está representado por dicha información de tiempo, y · almacenar dicha información de tiempo, incluida en cada solicitud de nodo extremo enviada en correspondenciacon las especificaciones de flujo asociadas, en al menos una base de datos relacionada gestionada por unconmutador (Sj) de la red central que participa en dicho reenvío de la solicitud.

Description

Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados
Campo de la invención.
La presente invención se refiere al campo de las redes de comunicación, y más precisamente a la gestión de la reserva de recursos en redes con paquetes conmutados.
Antecedentes de la invención.
Los nuevos esfuerzos de normalización, como los realizados en la organización de la IEEE, permiten realmente considerar la estricta aplicación de la reserva de recursos en el nivel OSI 2 (Capa de Enlaces). Sin embargo, todos estos mecanismos no están correlacionados en el tiempo y por lo tanto no permiten indicar el momento final de una reserva actual o planificar una reserva futura.
En el presente documento el término “recurso” se refiere a todas las variables de la red, tales como la anchura de banda, la fluctuación y el tiempo de espera, por ejemplo, que caracterizan un flujo (o tren) de datos entre dos nodos a través de una infraestructura dada.
Algunos entornos, tal como los entornos de producción de vídeo profesional y los de transmisión, son unos entornos muy sensibles al tiempo. Por lo tanto, se ha propuesto sustituir la infraestructura de punto a punto que normalmente han usado con una red con paquetes conmutados. No obstante, esto implica tener en cuenta todos los tiempos de espera que pudieran influir en las calidades de funcionamiento de todo el sistema.
El modelo OSI bien conocido (ilustrado esquemáticamente en la Figura 1 y normalizado por la organización ISO) define un marco de funcionamiento en red para aplicar unos medios de comunicación en siete capas. Las capas 1 a 4 están a cargo del transporte de los datos en un medio de comunicación dado, en tanto que las capas 5 a 7 se usan para permitir diferentes aplicaciones para comunicación independientemente de la infraestructura de comunicación usada.
El paradigma establecido por el documento WO2008/111791 es que ningún dispositivo de la red central (procesamiento de la capa 2 OSI) puede configurarse para tratar la conmutación de imágenes a partir de una interpretación de los datos transportados en un entorno que cumple la norma IEEE 802.1, por lo que el documento WO2008/113791 propone un dispositivo específico para realizar esta tarea (capas 5/6/7 OSI).
La presente invención solamente se refiere a la capa 2 OSI, es decir a la capa de enlace de datos. Por lo tanto, todos los mecanismos descritos a partir de ahora están tratados en la capa 2 OSI.
Como es sabido por el experto en la técnica, los conmutadores de la red central son equipos de la red central que envían tráfico en la información contenida en el encabezamiento de la capa 2. Este “reenvío” difiere del “encaminamiento” que se refiere a las operaciones en la información de la capa 3.
Estos conmutadores de la red central solamente envían tráfico a las direcciones usando una tabla de reenvío que asocia una dirección del equipo físico a uno de sus puertos. Cuando una trama es recibida por un conmutador de la red central, su encabezamiento de la capa 2 da la dirección del equipo físico y por lo tanto una entrada asociada a la tabla de reenvío, que designa el puerto al que el conmutador de la red central tiene que reenviar la trama. Debido a que operan en un nivel bajo, los procesos de los conmutadores de la red se aplican en el equipo físico, que permite la gestión de sus tiempos de espera.
El Grupo de Trabajo (TG) de Conexión en Puente de Audio/Video (AVB) de la IEEE 802.1, que forma parte de la IEEE 802.1, tiene como fin proporcionar unas especificaciones que permitirán los servicios de flujo de datos de bajo tiempo de espera sincronizados en el tiempo a través de las redes 802. Este TG comprende un subgrupo “IEEE 802.1AS: Temporización y Sincronización” que tiene como fin definir a través de una Capa 2 normal un servicio de sincronización del tiempo que es apropiado para las exigencias más estrictas de las aplicaciones de la electrónica de consumidor.
La norma 802.1AS especifica el protocolo y los procedimientos que deben usarse para asegurar que se cumplan las exigencias de sincronización de las aplicaciones sensibles al tiempo, tales como las de audio y video, a través de las Redes de Área Local de Conexión en Puente y Virtuales que constan de unos medios LAN en los que las demoras de transmisión son fijas y simétricas, tales como los enlaces duplex completos IEEE 802.3, por ejemplo. Esto incluye el mantenimiento del tiempo sincronizado durante la operación normal y la siguiente adición, la eliminación del fallo de los componentes de la red así como la reconfiguración de la red. Esta norma 802.1AS especifica el uso de las especificaciones IEEE 1588 cuando sean aplicables en el contexto de las normas IEEE 802.1D y 802.1Q. La sincronización de una señal de temporización proporcionada externamente (por ejemplo, una norma de temporización reconocida tal como UTC o TAI) no forma parte de esta norma pero no está excluida.
El grupo de trabajo IEEE 802.1AVB comprende otros dos subgrupos, los 802.1Qat y 802.1Qav, que se refieren al nuevo mecanismo de reserva de recursos.
La norma 802.1Qat tiene como fin definir un sistema de control de admisión que permite puentes para garantizar los recursos necesarios para los flujos de Audio/Video (AV). Especifica los protocolos, procedimientos y objetos gestionados, que pueden ser usados por los mecanismos de capa superior existentes, que permite que los recursos de red se reserven para flujos de tráfico específicos que atraviesan una red de área local conectada en puente. Identifica los flujos de tráfico a un nivel suficiente para que los conmutadores determinen los recursos requeridos y proporcionen un mecanismo para el mantenimiento dinámico de esos recursos.
Esta norma proporciona un protocolo de señalización para hacer posible la gestión de recursos de un extremo a otro de la reserva de recursos de los flujos garantizados con QoS. El protocolo de señalización facilita el registro, eliminación del registro, y retención de la información de reserva de recursos en los elementos de red pertinentes. El protocolo de señalización es un componente esencial de la configuración automática en aplicaciones de red de área local conectadas en Puente que requieren unas garantías de tiempo de espera y de anchura de banda. La aplicación de las actuales tecnologías IEEE 802 para flujos de datos de alta calidad sensibles al tiempo permite a los usuarios aumentar la carga de sus redes de forma desconocida en la medida en la que la experiencia del usuario está influida negativamente. Para proporcionar la capacidad de QoS coherente garantizada, la disponibilidad de los recursos de la red a lo largo de toda la vía de los datos tiene que ser asegurada antes de que tenga lugar la transmisión. Esto requiere la definición de descriptores del flujo de tráfico y de un protocolo para señalar la reserva de recursos a lo largo de la vía de los flujos de un extremo a otro extremo. Se usa el protocolo de registro múltiple (MRP) como una base para este protocolo.
La norma 802.1Qav tiene como objeto mejorar las reglas de reenvío de tramas de conexión en puente de la norma
802.1 para soportar los flujos AV. Permite a los conmutadores proporcionar garantías para la transmisión de datos de audio video (tráfico AV) en tiempo real de sensibilidad a las pérdidas y sensibilidad al tiempo (esto es, una variación ligada al tiempo de espera y a la entrega). Especifica la medición de ingresos según la prioridad, la regeneración de la prioridad y los algoritmos de drenaje de cola teniendo en cuenta la temporización. Se asignan losvalores de prioridad codificados de Red de Área Local Virtual (VLAN), en conjunto, para segregar tramas entre las colas controladas y no controladas, que permiten el soporte simultáneo para el tráfico AV y otro tráfico conectado en puente en y entre las Redes de Área Local por cable e inalámbricas (WLANs). Esta norma especifica las mejoras de la función de reenvío de los conmutadores de red anteriormente mencionados (que cada vez se usan más para interconectar los dispositivos que soportan las aplicaciones de flujos de datos de audio y video) para proporcionar garantías de calidad de funcionamiento que permitan el tráfico sensible al tiempo en una red de área local y para armonizar la pérdida por demora, fluctuación y de paquetes de las redes de la Capa 2.
Los nuevos trabajos de normalización en marcha antes mencionados permiten la sincronización precisa de los elementos de red conectados (nodo extremo y equipo de la red central) y asegurar una reserva estricta de recursos. No obstante, incluso si su fin es soportar aplicaciones sensibles al tiempo, no están totalmente relacionados debido a que la reserva de recursos no puede ser programada de acuerdo con el reloj “de pared” compartido por cualquier equipo sincronizado.
Resumen de la invención.
De este modo, la invención tiene como fin proponer una gestión de reserva de recursos sincronizada, basada en el mecanismo de reserva y sincronización de recursos nuevos, y permitir al menos minimizar la demora entre la reserva y la entrega de recursos, y programar el plan de reserva de recursos. Tal gestión de reserva de recursos sincronizada implica un respeto estricto de las variables de red especificadas (es decir, recursos), lo que significa que cualquier modificación de sus valores respectivos no deberá ser aceptada con el fin de no afectar a la calidad total del servicio (QoS).
Más precisamente, la invención propone incluir información de tiempo a las solicitudes de reserva de recursos que son emitidas por los nodos extremos y enviadas por los conmutadores de la red central, y a las bases de datos internas que son respectivamente gestionadas por los conmutadores de la red central para almacenar una información relativa a las reservas de recursos.
Todavía más precisamente, la invención proporciona un método previsto para programar reservas de recursos en una red de comunicación con paquetes conmutados que comprende conmutadores de los nodos extremos y de la red central (o equipos o bien dispositivos), y que comprende los pasos gestionados en el nivel de la capa de enlace de datos del modelo de Interconexión de Sistemas Abiertos, OSI, de:
•
incluir una información de tiempo en cada solicitud, emitida por un nodo extremo (Hi) y enviada por al menos un conmutador de la red central, y que solicita una reserva de recursos para recibir un flujo definido por especificaciones en un momento que está representado por esta información de tiempo, y
•
almacenar la información de tiempo, la cual está incluida en cada solicitud de un nodo extremo reenviada en correspondencia con las especificaciones de flujo asociadas, en al menos una base de datos relacionada gestionada por un conmutador de la red central que participa en el reenvío de la solicitud.
El método de acuerdo con la invención puede incluir unas características adicionales consideradas separadamente o combinadas, y notablemente:
-
la información de tiempo puede ser obtenida a partir de un momento que está dado por el reloj de pared compartido por los conmutadores de los nodos extremos y de la red central;
-
la información de tiempo puede ser añadida a una unidad de datos de protocolo de registro de flujos múltiple (MSRPDU), que constituye una solicitud de nodo extremo que cumple la norma 802.1Qat, en un nuevo campo especializado;
-
el nuevo campo especializado puede ser añadido a una subrama de la unidad de datos del protocolo de registro de flujo múltiple, denominada “Primer Valor”, en paralelo con el campo denominado “Flujo ID” que define un identificador de un flujo.
La invención propone además un nodo extremo, previsto para ser conectado a una red de comunicaciones con paquetes conmutados que comprende unos conmutadores de la red central, y que comprende unos medios de procesamiento dispuestos, cada vez que desea solicitar una reserva de recursos para recibir (o abonarse a) un flujo definido por especificaciones, i) para generar una solicitud que incluye las especificaciones de flujo y una información de tiempo que representa un momento en el que desea recibir este flujo, y ii) para transmitir la solicitud generada a un conmutador de la red central al que está conectada, de modo que pueda ser enviado, en el nivel de la capa de enlace de datos en el modelo de Interconexión de Sistemas Abiertos, OSI, a los otros conmutadores de la red central de la red de comunicaciones con paquetes conmutados.
Estos medios de procesamiento pueden ser dispuestos para obtener la información de tiempo a partir de un momento que está dado por el reloj de pared compartido por los nodos extremos y los conmutadores de la red central de la red de comunicaciones con paquetes conmutados.
La invención propone además un conmutador de la red central para una red de comunicaciones con paquetes conmutados a la que están conectados los nodos extremos, que comprende unos medios de procesamiento dispuestos, cuando su conmutador de la red central ha recibido una solicitud emitida por un nodo extremo y que incluye unas especificaciones de un flujo y una información de tiempo que representa un momento en el que desea comenzar a recibir este flujo, para almacenar esta información de tiempo en correspondencia con las especificaciones de flujo asociadas, en una base de datos relacionada de su conmutador de la red central, con el fin de que este último sea capaz de reenviar, en el nivel de la capa de enlace de datos del modelo de Interconexión de Sistemas Abiertos, OSI, el flujo solicitado al nodo extremo solicitante a partir del momento representado por la correspondiente información de tiempo almacenada.
Breve descripción de los dibujos.
Otras características y ventajas de la invención serán evidentes a partir del examen de las especificaciones detalladas y de los dibujos anejos, en los que:
-
la figura 1 ilustra esquemáticamente la disposición de capas del modelo OSI,
-
la figura 2 ilustra esquemáticamente un ejemplo de la infraestructura de producción del estudio en red Ethernet/IP,
-
la figura 3 ilustra esquemáticamente una topología LAN sencilla con el reloj de pared (parte izquierda) y su representación de Árbol Espaciador (parte derecha) relacionada,
-
la figura 4 ilustra esquemáticamente una entrega no sincronizada y sincronizada y unas solicitudes de reserva,
-
la figura 5 ilustra esquemáticamente un registro de flujo múltiple modificado PDU (MSRPDU) del receptor que incluye una marca temporal,
-
la figura 6 ilustra esquemáticamente una evolución de una base de datos no sincronizada, y
-
la figura 7 ilustra esquemáticamente una evolución de la base de datos sincronizada de acuerdo con la invención.
Descripción detallada de la invención.
Los dibujos anejos pueden servir no solamente para llevar a cabo la invención sino también para contribuir a su definición, si fuera necesario.
En la descripción que sigue se considerará que la red (de comunicaciones) con paquetes conmutados en la que se lleva a cabo la invención es una infraestructura de red local Ethernet/IP desplegada para una instalación de producción de audio/video. Un ejemplo de tal infraestructura de red local Ethernet/IP está ilustrado en la figura 2.
Esta infraestructura comprende notablemente i) unos primeros nodos extremos para producir o entregar unos contenidos de audio/video en forma de flujos de datos, tales como cámaras, servidores, grabadores de cinta de video (VTRs), micrófonos, mezcladores de audio, conmutadores, ii) unos segundos nodos extremos previstos para
visualizar unos contenidos de video o programas de televisión, o para difundir unos contenidos de audio, tales como televisiones o altavoces, y iii) unos dispositivos de la red central (o puentes), tales como unos conmutadores de Ethernet, previstos para reenviar los flujos de datos proporcionados por los primeros nodos extremos por medio de unidades de datos por paquetes o de unidades de datos de protocolo (PDUs).
Se recuerda que una unidad de datos de protocolo (PDU) es un paquete de protocolos enviado por un ordenador central conectado (o nodo extremo (Hi)). Además una Unidad de datos de protocolo conectada en puente (BDPU) es un paquete de protocolos enviado por un equipo (Sj) de la red central conectada.
Cuando un primer nodo extremo, denominado parlante, desea proporcionar una corriente o corrientes de datos a otros (segundos) nodos extremos, denominados oyentes, interesados en recibir este o estos flujos de datos, tiene que emitir una declaración del flujo. Una declaración del flujo permite a cada dispositivo de la red central conectado (tal como un conmutador de Ethernet) conseguir la especificación del flujo de datos (TSpec), tal como una Id del oyente, la anchura de banda máxima y el tiempo de espera máximo, e inicializar su propia base de datos interna relacionada con la reserva de recursos. Pero una vez que los dispositivos de la red central han inicializado sus propias bases de datos internas, aún no están reservados los recursos.
La reserva de recursos completa y la comprobación de las limitaciones de la TSpec se hacen cuando un oyente ha emitido una solicitud de “unión” para recibir un flujo previamente declarado. Durante esta comprobación la reserva de recursos (previamente emitida) se compara con la cantidad actual de recursos que quedan, y en consecuencia la reserva puede bien fallar o tener éxito. Estas situaciones están detalladas a partir de ahora con referencia a las figuras 3 y 4.
La figura 3 ilustra esquemáticamente una infraestructura de red sincronizada sencilla que soporta los procesos de reserva de recursos antes mencionados. En esta infraestructura el Equipo principal i de los nodos extremos (o usuarios) (o Hi, aquí i = 1 a 3 como ejemplo) están acoplados unos con otros a través de los conmutadores Sj (aquí j = 1 ó 2 como ejemplo). La representación de árbol espaciador de la infraestructura, situado en la parte derecha de la figura 3, muestra las interconexiones del puerto de conmutación.
Por ejemplo, los nodos extremos H2 y H3 son oyentes que han declarado previamente sus respectivos flujos (de datos). Por lo tanto, el nodo extremo H1 es un oyente que puede solicitar reservar recursos con el fin de recibir el flujo H2 y/o el flujo H3.
Sin embargo, si el enlace entre los conmutadores S1 y S2 no es capaz de soportar los flujos H2 y H3 al mismo tiempo, el oyente H1 tendrá que entregar el primer flujo solicitado (por ejemplo el flujo H2) para recibir el segundo (por ejemplo el flujo H3) para no superar la anchura de banda máxima. De este modo, si el oyente H1 es un conmutador de video, no es capaz de tratar un conmutador de video sin perturbaciones entre las dos fuentes H2 y H3 debido a la demora extra introducida por los consecutivos pasos de entrega y de reserva. La figura 4 es un diagrama que ilustra las solicitudes sincronizadas y no sincronizadas de entrega y de reserva como una función del tiempo.
Como se ha mencionado antes, el nuevo mecanismo de reserva de recursos como los propuestos por las normas 802.1Qat y 802.1Qav no permite la solicitud de entrega y de reserva programada.
No obstante, los nuevos mecanismos permiten la fijación de una sincronización de tiempo muy precisa entre cada nodo conectado de una red (o infraestructura). Por ejemplo, la norma IEEE 1588 y el nuevo borrador de la IEEE
802.1 AS que definen el perfil de la IEEE 1588 en Ethernet (802.3) y WiFi (802.11) permiten alcanzar una precisión de 1 Is sobre una topología de conexión en puente de 7 saltos de onda que define un único dominio de reloj.
Esta sincronización del tiempo permite el uso de una marca temporal para definir la fecha en la que un oyente desea una solicitud de entrega/reserva (o mensaje) para ser tenida en cuenta con objeto de detener el abono a al menos un flujo y/o comenzar a abonarse a al menos otro flujo.
La expresión “solicitud de entrega/reserva” significa aquí bien una solicitud de entrega de flujo o una solicitud de reserva de flujo o bien una solicitud pretendida para recursos de entrega de un primer flujo y para recursos de reserva de un segundo flujo.
Más precisamente, la invención propone incluir (o añadir) al menos una información de tiempo (o marca temporal) en la solicitud de entrega y/o reserva (por ejemplo en la unidad de datos de protocolo (PDU)) para sincronizar todas las solicitudes de entrega y/o de reserva del oyente. La marca temporal se obtiene preferiblemente a partir del momento dado por el reloj de pared WC que es compartido por cada dispositivo conectado (nodos extremos y equipos de de red centrales) y su anchura debe tener la precisión requerida por la aplicación considerada.
Esta adición de la señal temporal y de obtención del momento puede ser realizada por unos primeros medios de procesamiento que están asociados a un nodo extremo Hi, es decir que están localizados en su nodo extremo asociado Hi. Unos primeros medios de procesamiento pueden estar hechos de módulos de soporte lógico, al menos parcialmente, o de un circuito o circuitos electrónicos o módulos de equipos físicos, o bien de una combinación de módulos de equipos físicos y de soportes lógicos.
La figura 5 ilustra un ejemplo no limitativo de un registro de flujos múltiple modificado PDU (MSRPDU) formado a partir de un registro de flujos múltiple (MSRPDU) definido por el borrador de la 802.1Qat y que incluye una marca temporal 802.1AS. En este ejemplo la marca temporal 802.1AS está localizada en el campo denominado “PreciseTimeStamp” que está fijado en paralelo con el campo denominado “StreamID” (que define el identificador del flujo al que pertenece el MSRPDU) en la subrama denominada “Primer Valor”. En el ejemplo ilustrado de la figura 5 se ha mencionado que la marca temporal “PreciseTimeStamp” está definida por 80 bits. Esto resulta del hecho de que en la norma 802.1AS una marca temporal está definida por 80 bits. No obstante, se pueden usar otras cantidades de bits para definir marcas temporales que cumplan otras normas.
En el ejemplo de la figura 5, el campo “PreciseTimeStamp” que es añadido a la subrama denominada “Primer Valor” y que está definido por 80 bits, el número de bits que define el campo “Fallado el Oyente que pregunta” de esta subrama tiene que ser modificado. Por lo tanto, es igual a 18 octetos (48 bits + 16 bits + 80 bits = 144 bits = 18 octetos). Además, esta modificación de una MSRPDU clásica de la 802.1Qat obliga a otras modificaciones y/o ajustes en el número de octetos que definen algunos otros campos tales como los “AttributeLenght” y “AttributeListLength”. Por ejemplo, el número de octetos que define el campo AttributeLength puede fijarse en 18, y el número de octetos que define el campo AttributeListLength puede fijarse en 24.
Para asegurar una gestión de recursos coherente y estricta cada equipo de la red central debe actualizar su propia base de datos interna cada vez que se recibe una solicitud (o mensaje) de entrega/reserva de recursos en uno de sus puertos.
Se recuerda que, cuando un dispositivo Sj de la red central recibe un mensaje de aviso del parlante (o declaración TA de información del parlante) añade una entrada a su base de datos interna y registra la característica del flujo (TSpec) definida en este mensaje de aviso recibido del parlante antes de reenviar este mensaje de aviso del parlante al otro dispositivo de la red central contiguo (por ejemplo conmutadores) y nodos extremos.
Además, cuando un dispositivo Sj de la red central recibe una solicitud o declaración de “oyente preparado” (que indica que un nodo extremo Hi de oyente está preparado para recibir un flujo designado) comprueba en su base de datos interna si contiene la información que define este flujo designado y previamente enviado por un nodo de parlante por medio de un mensaje de aviso del parlante, y en caso afirmativo comprueba si el estatus de esta solicitud de oyente preparado recibida en cuanto a las especificaciones del flujo de datos (notablemente la anchura de banda y el tiempo de espera asignados) se ajusta a las especificaciones del flujo de datos almacenados (o TSpec) del flujo designado.
En caso de ajuste, el dispositivo de la red central envía la solicitud de oyente preparado en el puerto asociado al mensaje de aviso del parlante registrado.
En caso de no ajuste, la solicitud es rechazada y la notificación de rechazo es enviada al nodo del parlante y al nodo extremo del oyente. Un ejemplo de tal situación de rechazo se muestra en las tres evoluciones (1), (2) y (3) de una base de datos interna no sincronizada ilustrada en la parte izquierda de la figura 6. En este ejemplo TA designa un mensaje de información del parlante (o Aviso del Parlante), LR designa una solicitud de reserva de recursos (u “Oyente Preparado”) que ha sido enviada por un nodo extremo del oyente y que puede ser satisfecha, y LF (u “Oyente Fallado”) designa un nodo del oyente que ha requerido un flujo pero que no puede recibirlo a causa de no ajuste. En la primera base de datos interna (1) de un dispositivo de la red central, H1 designa el nodo extremo del oyente, H2 designa un primer nodo extremo del parlante que ha señalado que estaba preparado para enviar un primer flujo, y H3 designa un segundo nodo extremo del parlante que ha señalado que estaba preparado para enviar un segundo flujo. En la segunda base de datos interna (2) de este dispositivo de la red central, el último ha recibido una solicitud de reserva del oyente (LR) que designa el primer flujo (H2) del nodo extremo H1, y ha comprobado y registrado que era posible satisfacer esta solicitud (LR). En la tercera base de datos interna (3) del mismo dispositivo de la red central, el último ha recibido una solicitud de reserva del oyente que designa el segundo flujo (H3) del nodo extremo H1, y ha descubierto y registrado que era imposible satisfacer esta solicitud. Por lo tanto, se ha rechazado la última reserva del nodo extremo H1 del oyente.
Para impedir esta situación de rechazo cuando no hay señal temporal de las solicitudes de los diferentes nodos extremos del oyente de acuerdo con la invención, el nodo extremo H1 del oyente tiene que entregar el primer flujo (H2) solicitado para recibir el segundo (H3), que introduce una demora extra. Un ejemplo de tal situación de entrega se muestra en las cuatro evoluciones (1’), (2’), (3’) y (4’) de una base de datos interna no sincronizada ilustradas en la parte derecha de la figura 6.
En la primera base de datos interna (1’) de un dispositivo de la red central, H1 designa el nodo extremo del oyente, H2 designa un primer nodo extremo del parlante que ha señalado que estaba preparado para enviar un primer flujo, y H3 es un segundo nodo extremo del parlante que ha señalado que estaba preparado para enviar un segundo flujo. En la segunda base de datos interna (2’) de este dispositivo de la red central, el último ha recibido una primera solicitud del oyente (LR) que designa el primer flujo (H2) del nodo extremo H1 y ha comprobado y registrado que era posible satisfacer esta primera solicitud de reserva (LR). En la tercera base de datos interna (3’) del mismo dispositivo de la red central, el último ha recibido una segunda solicitud de reserva del oyente que designa el segundo flujo (H3) procedente del nodo extremo H1 y ha descubierto que era imposible satisfacer esta segunda
solicitud de reserva. Por lo tanto, el dispositivo de la red central ha informado de la situación al nodo extremo H1 del oyente, y el nodo extremo H1 del oyente ha enviado una solicitud de entrega de flujo para entregar su primera solicitud de reserva del primer flujo (H2). Entonces el dispositivo de la red central ha actualizado su base de datos interna (3’) sustituyendo la información LR por una información TA. En la cuarta base de datos interna (4’) del dispositivo de la red central, el último ha recibido una segunda solicitud de reserva del oyente que designa el segundo flujo (H3) procedente del nodo extremo H1 y ha comprobado y registrado que ahora era posible satisfacer esta segunda solicitud de reserva.
De acuerdo con la invención, introduciendo una señal temporal dentro de las solicitudes del nodo extremo del oyente, cada dispositivo de la red central es capaz de tratarlas de acuerdo con sus respectivas señales temporales, esto es de acuerdo con el instante en el que deberían ser tenidas en cuenta. En otras palabras, cada solicitud del nodo extremo del oyente, enviada en un primer momento, comprende ahora una señal temporal que ha sido añadida por unos primeros medios de procesamiento del nodo extremo y que definen un segundo momento que podría ocurrir más tarde y en el que la solicitud del nodo extremo del oyente tendrá que ser tenida en cuenta (es decir, aplicada).
Cuando un conmutador Sj de la red central recibe una solicitud, que ha sido emitida por un nodo extremo Hi e incluye unas especificaciones de un flujo y una información de tiempo que representa un momento en el que desea comenzar a recibir este flujo, unos segundos medios de procesamiento asociados a él (Sj), almacenan esta información de tiempo en correspondencia con las especificaciones de flujo asociadas en su base de datos relacionada, con el fin de que su conmutador Sj de la red central asociado sea capaz de reenviar el flujo solicitado al nodo extremo Hi solicitante a partir del momento que está representado por la correspondiente información de tiempo almacenada.
Los segundos medios de procesamiento están situados en su conmutador Sj asociado de la red central. Puede estar hecho de módulos de soporte lógico, al menos parcialmente, o de un circuito o circuitos electrónicos o de módulos de equipos físicos, o bien de una combinación de módulos de equipos físicos y de soportes lógicos.
La figura 7 ilustra un ejemplo de evoluciones (1), (2) y (3) de una base de datos de un dispositivo de la red central en caso de un tratamiento sincronizado de acuerdo con la invención basado en señales temporales registradas. En la primera base de datos interna (1) de un dispositivo de la red central H1 designa el nodo extremo del oyente, H2 designa un primer nodo extremo del parlante que ha señalado que estaba preparado para reenviar un primer flujo a partir del momento T0, y H3 designa un segundo nodo extremo del parlante que ha señalado que estaba preparado para enviar un segundo flujo a partir del momento T0. En la segunda base de datos interna (2) de este dispositivo de la red central, el último i) ha recibido una primera solicitud del oyente (LR) desde el nodo extremo H1, que designa el primer flujo (H2) y comprende una señal temporal (T1 gt; T0) que define el momento en el que el nodo extremo H1 desea que se satisfaga su primera solicitud de reserva, y ii) ha comprobado y registrado que era posible satisfacer esta primera solicitud de reserva (H2) en el momento T1. En la tercera base de datos interna (3) del mismo dispositivo de la red central, el último i) ha recibido una segunda solicitud de entrega y reserva desde el nodo extremo H1, que comprende una señal temporal (T3 gt; T1) que define el momento T3 en el que el nodo extremo H1 desea que su primera solicitud de reserva para que el primer flujo (H2) sea entregado y la reserva de recursos para que el segundo flujo (H3) sea exigida, y ii) ha comprobado y registrado que era posible exigir esta última (H3) reserva de recursos en el momento T3.
La invención no está limitada a las realizaciones del método, del nodo extremo y del conmutador de la red central descritos anteriormente, solamente como ejemplos, sino que abarca todas las realizaciones alternativas que pueden ser consideradas por un experto en la técnica dentro del alcance de las reivindicaciones que vienen a continuación.

Claims (6)

  1. REIVINDICACIONES
    1. Método para programar unas reservas de recursos en una red de comunicaciones con paquetes conmutados que comprende unos nodos extremos (Hi) y unos conmutadores (Sj) de la red central, en donde dicho método comprende los pasos, tratados en el nivel de la capa de enlace de datos del modelo de Interconexión de Sistemas
    5 Abiertos, OSI, de:
    •
    incluir una información de tiempo en cada solicitud, emitida por un nodo extremo (Hi) y reenviada por al menos un conmutador (Sj) de la red central, y que solicita una reserva de recursos para recibir un flujo definido por especificaciones en un momento que está representado por dicha información de tiempo, y
    •
    almacenar dicha información de tiempo, incluida en cada solicitud de nodo extremo enviada en correspondencia
    10 con las especificaciones de flujo asociadas, en al menos una base de datos relacionada gestionada por un conmutador (Sj) de la red central que participa en dicho reenvío de la solicitud.
  2. 2. Método de acuerdo con la reivindicación 1, caracterizado porque dicha información de tiempo se obtiene a partir de un tiempo dado por un reloj (WC) compartido por dichos nodos extremos (Hi) y los conmutadores (Sj) de la red central.
    15 3. Método de acuerdo con una de las reivindicaciones 1 y 2, caracterizado porque dicha información de tiempo se añade a una unidad de datos del protocolo de registro de flujos múltiples de datos, que constituye una solicitud de nodo extremo que cumple el Protocolo de Reserva de Flujo normalizado, como la norma 802.1Qat del Instituto de Ingenieros Eléctricos y Electrónicos, IEEE, en un nuevo campo especializado.
  3. 4. Método de acuerdo con la reivindicación 3, caracterizado porque dicho nuevo campo especializado se añade a
    20 una subrama de dicha unidad de datos del protocolo de registro de flujos múltiples, denominada “Primer valor”, en paralelo con un campo denominado “StreamID” que define un identificador de un flujo.
  4. 5. Un nodo extremo (Hi) destinado a estar conectado a una red de comunicaciones con paquetes conmutados que comprende unos conmutadores (Sj) de la red central, caracterizado por que comprende unos medios de procesamiento dispuestos, cada vez que dicho nodo extremo (Hi) desea solicitar una reserva de recursos para
    25 recibir un flujo definido por unas especificaciones,
    i) para generar una solicitud que incluye dichas especificaciones de flujo y una información de tiempo que representa un momento en el que dicho nodo extremo (Hi) desea comenzar a recibir dicho flujo, y
    ii) para transmitir dicha solicitud generada a un conmutador (Sj) de la red central al que dicho nodo extremo (Hi) está conectado, de modo que dicha solicitud pueda ser reenviada en el nivel de la capa de enlace de
    30 datos del modelo de Interconexión de Sistemas Abiertos, OSI, a los otros conmutadores (Sj) de la red central de dicha red de comunicaciones por paquetes conmutados.
  5. 6. Un nodo extremo de acuerdo con la reivindicación 5, caracterizado por que dichos medios de procesamiento están dispuestos para obtener dicha información de tiempo a partir de un momento dado por un reloj (WC) compartido por dichos nodos extremos (Hi) y los conmutadores (Sj) de la red central de dicha red de
    35 comunicaciones con paquetes conmutados.
  6. 7. Un conmutador (Sj) de la red central de una red de comunicaciones con paquetes conmutados a la que están conectados dichos nodos extremos (Hi), caracterizado por que comprende unos medios de procesamiento dispuestos, cuando su conmutador (Sj) de la red central ha recibido una solicitud emitida por un nodo extremo (Hi) y que incluye las especificaciones de un flujo y una información de tiempo que representa un momento en el que dicho
    40 nodo extremo (Hi) desea comenzar a recibir dicho flujo, para almacenar dicha información de tiempo en correspondencia con las especificaciones del flujo asociadas en una base de datos relacionada de su conmutador (Sj) de la red central, con el fin de que el último (Sj) sea capaz de reenviar, en el nivel de la capa de enlace de datos del modelo de Interconexión de Sistemas Abiertos, OSI, dicho flujo solicitado a dicho nodo extremo (Hi) solicitante a partir del momento representado por dicha información de tiempo almacenada.
ES10702712T 2009-02-20 2010-02-09 Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados Active ES2425602T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP09305166 2009-02-20
EP09305166 2009-02-20
PCT/EP2010/051555 WO2010094595A1 (en) 2009-02-20 2010-02-09 Time synchronized resource reservation over packet switched networks

Publications (1)

Publication Number Publication Date
ES2425602T3 true ES2425602T3 (es) 2013-10-16

Family

ID=42060494

Family Applications (2)

Application Number Title Priority Date Filing Date
ES10702712T Active ES2425602T3 (es) 2009-02-20 2010-02-09 Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados
ES13176331.0T Active ES2536556T3 (es) 2009-02-20 2010-02-09 Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES13176331.0T Active ES2536556T3 (es) 2009-02-20 2010-02-09 Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados

Country Status (8)

Country Link
US (2) US9137046B2 (es)
EP (2) EP2399368B1 (es)
JP (2) JP5737723B2 (es)
KR (1) KR101642382B1 (es)
CN (2) CN102326368B (es)
ES (2) ES2425602T3 (es)
PL (2) PL2650779T3 (es)
WO (1) WO2010094595A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10764201B2 (en) 2017-11-28 2020-09-01 Dornerworks, Ltd. System and method for scheduling communications

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8908701B2 (en) 2011-03-14 2014-12-09 Broadcom Corporation Stream path selection within convergent networks
US9191305B2 (en) 2011-03-14 2015-11-17 Broadcom Corporation Convergent network architecture and path information
US8619803B2 (en) * 2011-05-05 2013-12-31 Harman International Industries, Incorporated Sparse mode system
US8995507B2 (en) 2011-06-07 2015-03-31 Broadcom Corporation Transceiver self-diagnostics for electromagnetic interference (EMI) degradation in balanced channels
US9031084B2 (en) * 2012-07-20 2015-05-12 Harman International Industries, Incorporated Quality of service for streams over multiple audio video bridging networks
CN107113250B (zh) * 2015-02-06 2020-08-07 华为技术有限公司 一种数据包的转发方法、无线中继节点及通讯系统
US11023492B2 (en) * 2015-05-20 2021-06-01 Guidewire Software, Inc. Deferred synchronization for work unit-related data
US10243880B2 (en) * 2015-10-16 2019-03-26 Tttech Computertechnik Ag Time-triggered cut through method for data transmission in distributed real-time systems
EP3253013B1 (en) * 2016-06-02 2020-01-15 Mitsubishi Electric R&D Centre Europe B.V. Ultra-low transmission latency for sporadic network traffic
JP6824027B2 (ja) * 2016-12-26 2021-02-03 キヤノン株式会社 通信装置、その制御方法、およびプログラム
JP7331066B2 (ja) * 2017-03-10 2023-08-22 シーメンス アクチエンゲゼルシヤフト Ａｖｂストリームのモジュール式ルーティングの方法及び装置
US11245732B2 (en) 2017-03-10 2022-02-08 Siemens Aktiengesellschaft Method and device for the modular orientation of an AVB stream
EP3518470A1 (de) * 2018-01-24 2019-07-31 Siemens Aktiengesellschaft Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium
EP3664465B1 (de) 2018-12-04 2024-01-24 Siemens Aktiengesellschaft Verfahren zum betrieb eines kommunikationssystems zur übermittlung zeitkritischer daten, und kommunikationssteuerungseinrichtung
EP3917089A1 (de) * 2020-05-28 2021-12-01 Siemens Aktiengesellschaft Verfahren zum betrieb eines kommunikationssystems zur übermittlung zeitkritischer daten und switch

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5933417A (en) 1997-06-16 1999-08-03 General Datacomm, Inc. Multimedia multipoint telecommunications reservation acceptance systems and controllers
US6611519B1 (en) 1998-08-19 2003-08-26 Swxtch The Rules, Llc Layer one switching in a packet, cell, or frame-based network
US6647448B1 (en) * 2000-06-29 2003-11-11 Sony Corporation Method and apparatus for managing resource schedules in a peer to peer distributed networking environment
DE60211157T2 (de) * 2002-09-06 2007-02-08 Sony Deutschland Gmbh Synchrones Abspielen von Medien-Paketen
JP2004193842A (ja) 2002-12-10 2004-07-08 Matsushita Electric Ind Co Ltd 資源予約方法及びパケット通信システム
US7746799B2 (en) * 2003-06-20 2010-06-29 Juniper Networks, Inc. Controlling data link layer elements with network layer elements
US20050076336A1 (en) * 2003-10-03 2005-04-07 Nortel Networks Limited Method and apparatus for scheduling resources on a switched underlay network
DE60336597D1 (de) 2003-12-19 2011-05-12 Ericsson Telefon Ab L M Betriebsmittelreservierung in einem paketvermittelten telekommunikationsnetz
WO2006011270A1 (ja) * 2004-07-27 2006-02-02 Sharp Kabushiki Kaisha 擬似ビデオオンデマンドシステム、擬似ビデオオンデマンドシステムの制御方法、およびそれらに用いるプログラムおよび記録媒体
JP2006087014A (ja) * 2004-09-17 2006-03-30 Fujitsu Ltd レイヤ２スイッチ
CN100486219C (zh) * 2005-10-17 2009-05-06 华为技术有限公司 一种实现端到端的流传输方法
US8000233B2 (en) 2006-02-28 2011-08-16 Alcatel Lucent Method and apparatus for real-time application-driven resource management in next generation networks
CN101179840A (zh) * 2006-11-07 2008-05-14 华为技术有限公司 正交频分复用系统接入方法和装置
JP4717785B2 (ja) * 2006-11-20 2011-07-06 日本電信電話株式会社 ネットワーク管理装置および方法
US8254248B2 (en) * 2007-03-20 2012-08-28 Broadcom Corporation Method and system for implementing redundancy for streaming data in audio video bridging networks
US8806547B2 (en) * 2007-03-20 2014-08-12 Thomson Licensing Virtual multimedia matrix over packet switched network
KR101427894B1 (ko) 2007-03-23 2014-08-11 삼성전자주식회사 링크 레이어에서의 큐오에스 제공 시스템 및 그 방법
US8391354B2 (en) * 2007-05-14 2013-03-05 Broadcom Corporation Method and system for transforming uncompressed video traffic to network-aware ethernet traffic with A/V bridging capabilities and A/V bridging extensions
WO2009012812A1 (en) 2007-07-23 2009-01-29 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for stream adaption in a packet switched network

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10764201B2 (en) 2017-11-28 2020-09-01 Dornerworks, Ltd. System and method for scheduling communications

Also Published As

Publication number Publication date
ES2536556T3 (es) 2015-05-26
PL2650779T3 (pl) 2015-07-31
JP2012518928A (ja) 2012-08-16
US20120026951A1 (en) 2012-02-02
JP5737723B2 (ja) 2015-06-17
KR101642382B1 (ko) 2016-08-10
CN105207903B (zh) 2019-02-15
CN102326368B (zh) 2015-08-05
JP6032824B2 (ja) 2016-11-30
EP2399368B1 (en) 2013-07-24
WO2010094595A1 (en) 2010-08-26
US9137046B2 (en) 2015-09-15
EP2650779B1 (en) 2015-04-01
KR20110122128A (ko) 2011-11-09
CN105207903A (zh) 2015-12-30
US9553824B2 (en) 2017-01-24
JP2015144476A (ja) 2015-08-06
PL2399368T3 (pl) 2013-12-31
CN102326368A (zh) 2012-01-18
EP2399368A1 (en) 2011-12-28
EP2650779A1 (en) 2013-10-16
US20150326493A1 (en) 2015-11-12

Similar Documents

Publication Publication Date Title
ES2425602T3 (es) Reserva de recursos sincronizados de tiempo en redes con paquetes conmutados
Nasrallah et al. Ultra-low latency (ULL) networks: The IEEE TSN and IETF DetNet standards and related 5G ULL research
KR102164032B1 (ko) 네트워크 장치 및 네트워크 장치의 전송 선택 방법
Teener et al. Heterogeneous networks for audio and video: Using IEEE 802.1 audio video bridging
KR20130081280A (ko) 뉴 네트워크의 통신 방법 및 시스템
CN103597778A (zh) 用于音频视频网络的增强流预留协议
US20230019215A1 (en) TSC-5G QoS MAPPING WITH CONSIDERATION OF ASSISTANCE TRAFFIC INFORMATION AND PCC RULES FOR TSC TRAFFIC MAPPING AND 5G QoS FLOWS BINDING
CN101466158B (zh) 包括主网络和副网络的网络中的通信方法
US20160087900A1 (en) A communication node for a packet-switched data network and a method for operation thereof
CN106851435B (zh) 一种组播流的发送方法以及后端设备
KR20190082960A (ko) 네트워크 장치 및 네트워크 장치의 큐 관리 방법
US8806547B2 (en) Virtual multimedia matrix over packet switched network
US20190058668A1 (en) Data streaming with layer 2 and layer 3 reservations
US10230660B2 (en) Method and system for centralized controller for audio visual broadcasts
CN112165416B (zh) 一种组网和通信的方法和装置
EP3420692B1 (en) Data streaming with layer 2 and layer 3 reservations
Teener et al. No-excuses audio/video networking: the technology behind avnu
CN113114973A (zh) 一种视频会议方法、装置及系统
Steiner et al. IEEE 802.1 Audio/Video Bridging and Time-Sensitive Networking
WO2024066585A1 (zh) 通信方法、装置及系统
CN116233004A (zh) 一种通信方法及装置
Abraham Kwabena Network Slicing System Supporting Ultra Reliable Low Latency Connectivity in 5G
JP2015109552A (ja) 通信装置、通信システム、中継方法、およびデータ送信方法、並びにコンピュータ・プログラム