FR2913156A1 - Procede d'allocation de ressources de transmission d'un contenu de donnees, produit programme d'ordinateur, moyen de stockage et dispositif correspondants - Google Patents

Procede d'allocation de ressources de transmission d'un contenu de donnees, produit programme d'ordinateur, moyen de stockage et dispositif correspondants Download PDF

Info

Publication number
FR2913156A1
FR2913156A1 FR0701361A FR0701361A FR2913156A1 FR 2913156 A1 FR2913156 A1 FR 2913156A1 FR 0701361 A FR0701361 A FR 0701361A FR 0701361 A FR0701361 A FR 0701361A FR 2913156 A1 FR2913156 A1 FR 2913156A1
Authority
FR
France
Prior art keywords
data
application
value
data stream
intermediate device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0701361A
Other languages
English (en)
Other versions
FR2913156B1 (fr
Inventor
Kolli Yacine El
Arnaud Closset
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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to FR0701361A priority Critical patent/FR2913156B1/fr
Priority to US12/036,645 priority patent/US7751439B2/en
Publication of FR2913156A1 publication Critical patent/FR2913156A1/fr
Application granted granted Critical
Publication of FR2913156B1 publication Critical patent/FR2913156B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • 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/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40065—Bandwidth and channel allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894—Packet rate
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2475—Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
    • 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/28—Flow control; Congestion control in relation to timing considerations
    • 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/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • 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
    • 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/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40058—Isochronous transmission
    • 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/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40091—Bus bridging
    • 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/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un procédé d'allocation de ressources de transmission, dans un réseau de communication (1000), d'un flux de données, depuis un dispositif intermédiaire (1011) vers un dispositif destinataire (102), ledit flux de données comprenant une pluralité de paquets applicatifs de données et étant transmis d'un dispositif source (1031) au dispositif intermédiaire (1011) sous la forme de paquets de transport de données selon un protocole de communication.Selon l'invention, le dispositif intermédiaire (1011) effectue les étapes suivantes,- réception de paquets de transport de données selon le protocole de communication ;- obtention d'informations d'horodatage applicatif comprises dans les données du flux de données contenues dans les paquets de transport de données reçus- détermination d'un débit, dit débit applicatif, à partir desdites informations d'horodatage applicatif obtenues et d'une information de quantité de données du flux de données reçue par le dispositif intermédiaire (1011) ;- détermination d'une valeur de bande passante à allouer, en fonction dudit débit applicatif, pour transmettre ledit flux de données depuis le dispositif intermédiaire vers le dispositif destinataire (102) ;- allocation de ladite valeur de bande passante à allouer pour la transmission du flux de données depuis le dispositif intermédiaire vers le dispositif destinataire (102).

Description

Procédé d'allocation de ressources de transmission d'un contenu de
données, produit programme d'ordinateur, moyen de stockage et dispositif correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des transmissions de contenus de données dans un réseau de communication. Plus précisément, l'invention concerne la gestion de la réservation de ressources lors de transmissions d'au moins un flux dans un réseau de communication. 2. Solutions de l'art antérieur Le réseaux domestiques sont de plus en plus réalisés sous la forme de réseaux conformes à la norme IP LAN (pour Internet Protocol Local Area Network ) mettant en oeuvre un logiciel de contrôle de couche intermédiaire (ou middleware control ) tel que défini dans le standard UPnP (pour Universal Plug and Play ) ou dans le groupement DLNA (pour Digital Living Network Alliance ). Un des objectifs des réseaux domestiques est de permettre la distribution de contenus audio-vidéo à la maison et de fournir l'accès à différents terminaux sources depuis différents terminaux de lecture disponibles à la maison.
Par exemple, il doit être possible d'accéder à un même lecteur de DVD, connecté au réseau domestique, depuis un téléviseur situé dans la salle de jeu ou depuis un autre téléviseur situé dans une chambre ou depuis encore un autre téléviseur situé dans la cuisine. Les fabricants de dispositifs électroniques audio-vidéo commencent à intégrer des interfaces LAN dans leurs dispositifs. Cependant, beaucoup de dispositifs audio- vidéo sont toujours équipés d'interfaces conformes au standard IEEE-1394 (tel que décrit dans les documents IEEE Std. 1394-1995, Standard for High Performance Serial Bus et IEEE Std 1394a-2000, Standard for High Performance Serial Bus Supplement ) pour les émission/réception de contenus audio-vidéo.
L'interface IEEE-1394 étant l'interface privilégiée pour l'émission/réception de contenus audio-vidéo, des tentatives de standardisation sont mises en oeuvre afin de réaliser des dispositifs ponts (ou noeuds d'interconnexion) IEEE-1394 / LAN.
Une de ces tentatives de standardisation est réalisée par le groupe de travail désigné par EA-2005 AV Adapter to Connect Ethernet and 1394 Devices du CEA R7 tel que détaillé à l'adresse Internet suivante http://www.ce.org/Standards/2502.asp#2538. La qualité de service ou Quality of Service ci-après désignée par QoS est un problème important à résoudre lorsque l'on s'intéresse à l'interfaçage entre un dispositif source conforme au protocole IEEE-1394 et un réseau conforme au protocole IP LAN. Le bus IEEE-1394 met naturellement en oeuvre de la QoS du fait qu'il met en ceu'vre de la réservation de ressource (en termes de canal de transmission et de bande passante). Lorsqu'un canal de transmission et une bande passante sont alloués à un noeud, le système garantit ces ressources au noeud. Un réseau IP LAN classique ne met pas en oeuvre naturellement de QoS. Le protocole UPnP définit des QoS de haut niveau, le protocole RSVP (tel que défini dans le standard IETF RFC 2205) permet d'effectuer de la réservation de ressource à un niveau IP alors que le protocole conforme à la norme IEEE 802.1 AVB (tel que détaillé à l'adresse Internet suivante : http://www.ieee802.org/1/pages/avbridges.html) est dédié à la QoS de la couche 2. Le document End to End Stream Establishment in Consumer Home Networks publié dans IEEE CCNC 2006 Proceedings décrit comment combiner les protocoles UPnP, RSVP et IEEE 802.1 AVB. On peut donc concevoir une correspondance ( mapping ) entre la QoS sur IEEE-1394 et la QoS sur IP LAN. Classiquement, dans le cadre de la réservation de ressources pour un contenu à transmettre par un dispositif source IEEE-1394 vers un dispositif destinataire d'un réseau IP-LAN via un noeud d'interconnexion IEEE-1394 / IP LAN (le dispositif source étant relié au noeud d'interconnexion via un bus IEEE- 1394), on réserve pour ce contenu, sur le réseau IP-LAN, le même débit que celui réservé sur le bus IEEE-1394. Ce débit correspond, selon les normes IEEE 1394 et IEC 61883 ( Specification of Digital Interface for Consumer Electronics Audio/Video Equipment ), au débit maximal que peut fournir le dispositif source. Ainsi, la réservation de ressource sur un bus IEEE-1394 pour un contenu transmis par un dispositif source IEEE-1394 est uniquement basée sur les capacités (en termes de débit) du dispositif source et ne dépend pas des caractéristiques du contenu. Si l'on prend l'exemple d'un disque dur audio-vidéo ( AV HDD pour Audio-Video Hard Disk Drive en anglais), celui-ci exporte selon les normes IEEE 1394 et IEC 61883, une quantité de bande passante à réserver pour la transmission d'un quelconque de ses contenus égal au débit maximal que le AV H]DD peut supporter en émission. Ainsi, dans le cas où le contenu ne nécessite pas, pour sa transmission dans le réseau IP-LAN, un débit aussi élevé que le débit maximum que peut fournir le dispositif source, on observe une sur-réservation de ressources pour la transmission de ce contenu dans le réseau IP-LAN par rapport à ce qui est nécessaire. Or, la bande passante d'un bus IEEE-1394 varie généralement entre S100 (100Mbit/s) et S800 (800Mbit/s). La bande passante mise en oeuvre dans un réseau IP LAN (lorsque basé sur le protocole Ethernet) varie généralement entre lOMbit/s et 1Gbit/s. La bande passante la plus couramment mise en oeuvre est 100Mbit/s, notamment pour les applications domestiques. Dans le cas d'un réseau IP LAN de type sans fil ou IP WLAN (pour Wireless Local Area Network ), la bande passante mise en oeuvre varie généralement entre 12 et 120Mbit/s. Ainsi, du fait du phénomène de sur-réservation précité associé et du fait que la bande passante totale (pour tous les contenus à transmettre simultanément dans le réseau) du réseau IP-LAN est limitée, on observe une sous-utilisation du réseau IP LAN pour la transmission de flux de données à bande passante préalablement réservée et, en tout état de cause, le nombre de tels contenus ou flux de données qui peuvent transiter par le réseau IP-LAN est limité. 3. Objectifs de l'invention L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une technique de transmission d'un flux sur un chemin de transmission entre un dispositif source et un dispositif destinataire dans un réseau de communication qui permette d'optimiser, en fonction d'au moins une caractéristique du flux, la réservation de ressources pour la transmission du flux entre un dispositif intermédiaire du chemin de transmission et le dispositif destinataire. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette d'éviter l'occurrence de sur-réservation pour la transmission de contenus dans le réseau de communication. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette de transmettre plus de flux simultanément dans le réseau. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui soit compatible avec les recommandations des protocoles mis en oeuvre. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de mettre en oeuvre une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4. Exposé de l'invention Dans un mode de réalisation particulier de l'invention, il est proposé un procédé d'allocation de ressources de transmission, dans un réseau de communication, d'un flux de données, depuis un dispositif intermédiaire vers un dispositif destinataire, ledit flux de données comprenant une pluralité de paquets applicatifs de données et étant transmis d'un dispositif source au dispositif intermédiaire sous la forme de paquets de transport de données selon un protocole de communication, Selon l'invention, le dispositif intermédiaire effectue les étapes suivantes : -réception de paquets de transport de données selon le protocole de 5 communication ; - obtention d'informations d'horodatage applicatif comprises dans les données du flux de données contenues dans les paquets de transport de données reçus ; - détermination d'un débit, dit débit applicatif, à partir desdites informations 10 d'horodatage applicatif obtenues et d'une information de quantité de données du flux de données reçue par le dispositif intermédiaire ; - détermination d'une valeur de bande passante à allouer, en fonction dudit débit applicatif, pour transmettre ledit flux de données depuis le dispositif intermédiaire vers le dispositif destinataire ; 15 - allocation de ladite valeur de bande passante à allouer pour la transmission du flux de données depuis le dispositif intermédiaire vers le dispositif destinataire. Le principe général de l'invention consiste à déterminer, à partir d'informations d'horodatage applicatif comprises dans le flux, la bande passante 20 minimale requise pour la transmission du flux entre le dispositif intermédiaire et le dispositif destinataire et à réserver cette bande passante minimale pour cette transmission. Le fait d'utiliser de telles informations d'horodatage applicatif afin de déterminer la bande passante à allouer permet de s'affranchir des erreurs 25 introduites par les effets de la mise en paquets des données selon la norme IEEE 1394 dans le cadre du calcul de la bande passante. En effet, selon la norme IEC 61883, les paquets de type TS (pour Transport Stream ) sont des paquets applicatifs de données et sont encapsulés dans des paquets isochrones de type IEEE 1394 (qui sont des paquets de transport 30 de données), l'information d'horodatage applicatif étant présente dans l'en-tête des paquets de type TS. Un ou plusieurs paquets de type TS peut(peuvent) être encapsulé(s) dans un paquet isochrone de type IEEE 1394. Pour chaque canal de transmission réservé sur un bus de type IEEE 1394, un paquet isochrone est émis une fois par cycle (de 125 microsecondes).
Cependant, la fréquence de l'encodeur audio/vidéo permettant la génération des paquets de type TS est indépendante et le plus souvent différente de la fréquence du bus IEEE 1394. Il n'est alors pas possible d'assurer qu'un même nombre de données contenues dans des paquets de type TS seront disponibles à chaque cycle de 125 microsecondes cadençant le bus IEEE 1394.
Même si la norme IEC 61883 permet de définir des paquets de type TS partiels ( Partial Transport Stream ), les règles d'encapsulation des données de paquets de type TS définies dans la Partie 4 de cette norme (IEC 61883-4) ne permettent pas d'assurer un même nombre de données de paquets de type TS à chaque cycle. La taille des paquets isochrones de type IEEE1394 n'est donc pas constante d'un cycle à l'autre, même si le flux de données généré par l'encodeur audio/vidéo est à débit (applicatif) constant. La mise en paquets des données selon la norme IEEE 1394 et le calcul de la bande passante sur la base des paquets isochrones peut alors mener à interpréter un flux à débit applicatif constant (également dit flux à comportement CBR pour Constant Bit Rate ) comme étant un flux à débit applicatif variable (également dit flux à comportement VBR pour Variable Bit Rate ). Ainsi, grâce à l'utilisation des informations d'horodatage, il est possible de déterminer le débit applicatif réel indépendamment du mode de transport lié à l'encapsulation des données selon les normes IEEE 1394 et IEC 61883. Il sera ainsi possible d'utiliser un mode de transport sur le réseau IP LAN basé sur une encapsulation des données dans un protocole de type RTP et gérer la réservation de ressources, en fonction du débit applicatif déterminé, pour le transport des données encapsulées selon un mode de mise en forme de trafic ( traffic shaping en anglais) et ce afin d'assurer la qualité de service (QoS), par exemple conformément à la norme IEEE 802.11e.
Ainsi, le procédé de transmission selon l'invention permet d'optimiser, en fonction d'au moins une caractéristique du flux, la réservation de ressources pour la transmission du flux entre un dispositif intermédiaire du chemin de transmission et le dispositif destinataire.
En outre, le procédé selon l'invention permet d'éviter l'occurrence de sur- réservation pour la transmission de contenus dans le réseau de communication. D'autre part, grâce à la technique selon l'invention, on peut faire transiter simultanément plus de flux sur le réseau du fait que la bande passante disponible et non utilisée dans le réseau peut être réduite.
Par ailleurs, le procédé selon l'invention peut être basé sur des protocoles de transmission tels que le protocole IEEE-1394 et le protocole TCP/IP. Avantageusement, l'étape de détermination d'une valeur de bande passante à allouer comprend une étape de détermination si le flux de données est à débit constant ou à débit variable.
Il est ainsi possible d'appliquer une réservation de bande passante basée sur des informations différentes suivant le comportement du débit applicatif (constant ou variable). Préférentiellement, chacun desdits paquets applicatifs de données du flux comprenant un entête comprenant une information d'horodatage applicatif, ladite étape de détermination du débit applicatif comprend une étape de détermination d'au moins une valeur de débit applicatif instantané du flux de données à partir de l'écart temporel entre l'information d'horodatage applicatif d'un paquet applicatif de données précédent un paquet applicatif de données courant et l'information d'horodatage applicatif du paquet applicatif de données courant dans le flux de données. Ainsi, la valeur de la bande passante instantanée associée à un paquet applicatif courant est par exemple égale à la quantité d'information comprise dans le paquet précédant le paquet courant divisé par l'écart temporel entre l'information d'horodatage du paquet précédant le paquet courant et l'information d'horodatage du paquet courant.
Selon une caractéristique préférentielle de l'invention, ladite étape de détermination du débit applicatif comprend également une étape de comparaison d'au moins deux valeurs de débit applicatif instantané du flux de données. Il est alors possible de déterminer le comportement du débit applicatif (constant ou variable) : par exemple, si les valeurs de débit applicatif instantané sont égales, le débit applicatif est considéré comme un débit à comportement constant, sinon il est considéré comme un débit à comportement variable. Avantageusement, si le flux est à débit constant, alors la valeur de bande passante à allouer est: fonction de ladite ou de l'une desdites valeur(s) de débit applicatif instantané du flux. Préférentiellement, si le flux est à débit variable, le procédé selon l'invention comprend une étape de détermination du paquet applicatif de données de plus grande dimension du flux de données, et la valeur de bande passante à allouer est égale à une valeur déterminée, ladite valeur déterminée permettant de transmettre un flux de données dont chaque paquet applicatif de données a la dimension du paquet applicatif de plus grande dimension du flux de données. Selon un premier mode de réalisation de l'invention, qu'il comprend en outre une étape de vérification de la continuité du flux de données.
Ainsi, dans le cas de la détection d'une discontinuité du flux (due par exemple à une perte de paquet(s)), le procédé est par exemple réinitialisé. Selon un second mode de réalisation de l'invention, ledit procédé est mis en oeuvre périodiquement. Préférentiellement, le procédé selon l'invention est mis en oeuvre sous la forme de phases d'observation qui s'enchaînent les unes après les autres. Il est alors possible de détecter un changement de comportement du débit applicatif du flux de données transporté. C'est le cas, par exemple, quand un utilisateur change sélectionne un autre contenu émis par un disque dur audio-vidéo de type IEEE 1394 que celui qui était en cours de diffusion.
Ainsi, dans le cas où le flux subit une modification après qu'une bande passante lui a été allouée dans une phase d'observation donnée, le cas échéant, la bande passante à allouer au flux peut être modifiée en conséquence dans la phase d'observation consécutive à la modification du flux. Avantageusement, le procédé comprend au préalable les étapes suivantes : - réception d'une requête d'allocation de ressources de transmission pour le flux de données, ladite requête comprenant une information de quantité de ressources nécessaires maximale ; - tentative d'allocation d'une valeur de bande passante pour la transmission du flux de données depuis le dispositif intermédiaire vers le dispositif destinataire, ladite valeur de bande passante étant fonction de l'information de quantité de ressources nécessaires maximale ; - dans le cas où la tentative d'allocation échoue, établissement d'une connexion de flux selon le protocole de communication pour la transmission du flux de données depuis le dispositif source vers le dispositif intermédiaire, le dispositif intermédiaire effaçant les paquets de transport de données reçus une fois les informations d'horodatage applicatif obtenues. Ainsi, lorsqu'une tentative d'allocation de ressources pour la transmission d'un flux de données basée sur une information prédéterminée (par exemple les capacités maximales en terme de débit d'un disque dur audio-vidéo de type IEEE 1394) échoue entre le dispositif intermédiaire et le dispositif récepteur, une connexion de flux entre le dispositif source et le dispositif intermédiaire permet de mettre en oeuvre une phase d'observation du flux de données selon l'invention et ainsi, une fois le débit applicatif déterminé, faire une nouvelle tentative d'allocation de ressources pour la transmission d'un flux de données en fonction du débit réel du flux de données. Préférentiellement, préalablement à l'étape d'obtention d'information d'horodatage applicatif, il comprend une étape de détermination d'un format du flux de données.
Ainsi, il est possible d'appliquer une réservation de bande passante basée sur des informations différentes suivant le format du contenu du flux de données. Par exemple, dans le cas où le flux est de type DV, alors, la norme IEC 61883 concernant les flux de type DVCR (pour Digital Video Cassette Recorder ), plus communément connu sous la dénomination DV, indique que le flux est à comportement CBR (pour Constant Bit Rate , soit débit applicatif constant). Dans ce cas, la valeur de bande passante à allouer est de l'ordre de 3OMbit/s si le flux est de type SD-DVCR (pour Standard Definition Digital Video Cassette Recorder ), plus communément connu sous la dénomination SD-DV. Elle est de l'ordre de 6OMbit/s si le flux est de type HD-DVCR (pour High Definition Digital Video Cassette Recorder ), plus communément connu sous la dénomination HD-DV. Dans le cas où le flux est de type MPEG2 (pour Motion Picture Expert Group 2 ), dont le comportement peut être CBR (pour Constant Bit Rate , soit débit applicatif constant) ou VBR (pour Variable Bit Rate , soit débit applicatif variable), alors, le procédé selon l'invention permet d'obtenir une valeur de la bande passante à allouer pour la transmission de ce flux. L'invention concerne également un produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé d'allocation de ressources de transmission tel que précédemment décrit. L'invention concerne également un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre du procédé d'allocation de ressources de transmission tel que précédemment décrit. L'invention concerne également un dispositif intermédiaire comprenant des moyens d'allocation de ressources de transmission d'un flux de données comprenant une pluralité de paquets applicatifs de données, dans un réseau de communication, depuis le dispositif intermédiaire vers un dispositif destinataire, le dispositif intermédiaire comprenant des moyens de réception du flux sous la forme de paquets de transport de données selon un protocole de communication, ledit flux provenant d'un dispositif source. Selon l'invention, dans un tel dispositif, les moyens d'allocation de ressources de transmission comprennent, - des moyens de réception de paquets de transport de données selon le protocole de communication ; - des moyens d'obtention d'informations d'horodatage applicatif comprises dans les données du flux de données contenues dans les paquets de transport de données reçus ; -des moyens de détermination d'un débit, dit débit applicatif, à partir desdites informations d'horodatage applicatif obtenues et d'une information de quantité de données du flux de données reçue par le dispositif intermédiaire ; - des moyens de détermination d'une valeur de bande passante à allouer, en fonction dudit: débit applicatif, pour transmettre ledit flux de données depuis le dispositif intermédiaire vers le dispositif destinataire ; - des moyens d'allocation de ladite valeur de bande passante à allouer pour la transmission du flux de données depuis le dispositif intermédiaire vers le dispositif destinataire.
Préférentiellement, les moyens de détermination d'une valeur de bande passante à allouer comprennent des moyens de détermination si le flux de données est à débit constant ou à débit variable. Avantageusement, chacun desdits paquets applicatifs de données du flux comprend une entête comprenant une information d'horodatage applicatif, et les moyens de détermination du débit applicatif comprennent des moyens de détermination d'au moins une valeur de débit applicatif instantané du flux de données à partir de l''écart temporel entre l'information d'horodatage applicatif d'un paquet applicatif de données précédent un paquet applicatif de données courant et l'information d'horodatage applicatif du paquet applicatif de données courant dans le flux de données.
Préférentiellement, les moyens de détermination du débit applicatif comprennent également des moyens de comparaison d'au moins deux valeurs de débit applicatif instantané du flux de données. Avantageusement, les moyens d'allocation de ressources de transmission comprennent des moyens de détection si le flux est à débit constant, et les moyens de détermination d'une valeur de la bande passante à allouer tiennent compte de ladite ou de l'une desdites valeur(s) de débit applicatif instantané du flux si le flux est à débit constant. Selon une caractéristique préférentielle de l'invention, les moyens d'allocation de ressources de transmission comprennent des moyens de détection si le flux est à débit variable et des moyens de détermination du paquet applicatif de données de plus grande dimension du flux de données, lesdits moyens étant activés si le flux est à débit variable, et les moyens de détermination d'une valeur de la bande passante à allouer tiennent compte d'une valeur déterminée, ladite valeur déterminée permettant de transmettre un flux de données dont chaque paquet applicatif de données a la dimension du paquet applicatif de plus grande dimension du flux de données. Préférentiellement, les moyens d'allocation de ressources de transmission comprennent en outre des moyens de vérification de la continuité du flux de données. Avantageusement, les moyens d'allocation de ressources de transmission sont activés périodiquement. Selon une caractéristique avantageuse de l'invention, les moyens d'allocation de ressources de transmission comprennent : - des moyens de réception d'une requête d'allocation de ressources de transmission pour le flux de données, ladite requête comprenant une information de quantité de ressources nécessaires maximale ; - des moyens de mise en oeuvre d'une tentative d'allocation d'une valeur de bande passante pour la transmission du flux de données depuis le dispositif intermédiaire vers le dispositif destinataire, ladite valeur de bande passante étant fonction de l'information de quantité de ressources nécessaires maximale ; - des moyens d'établissement d'une connexion de flux selon le protocole de communication pour la transmission du flux de données depuis le dispositif source vers le dispositif intermédiaire, le dispositif intermédiaire comprenant des moyens d'effacement les paquets de transport de données reçus, lesdits moyens d'effacement étant activés par l'obtention des informations d['horodatage applicatif, lesdits moyens d'établissement d'une connexion de flux selon le protocole de communication étant activés dans le cas où la tentative d'allocation échoue. Préférentiellement, les moyens d'allocation de ressources de transmission comprennent des moyens de détermination d'un format du flux de données. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs modes de réalisation préférentiels, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : la figure 1 présente un schéma d'un réseau de communication local de type IP LAN dans lequel peut être mis en oeuvre le procédé de transmission selon un mode de réalisation particulier de l'invention ; - la figure 2 illustre un exemple d'architecture de protocole mis en oeuvre dans le premier noeud d'interconnexion du réseau de la figure 1 lors de la réception d'un contenu selon le mode de réalisation particulier précité ; la figure 3 présente un exemple d'implémentation du premier noeud d'interconnexion du réseau de la figure 1 selon le mode de réalisation particulier précité ; la figure 4 illustre les étapes principales d'un algorithme d'observation mis en oeuvre lors de l'ouverture d'une connexion pour la transmission d'un flux entre le premier bus IEEE-1394 et le premier segment Ethernet du réseau de la figure 1 selon le mode de réalisation particulier précité ; La figure 5 présente un exemple d'implémentation du module d'observation de trafic (ou moniteur) selon le mode de réalisation particulier précité ; la figure 6 présente les étapes principales d'un algorithme de contrôle de l'admission d'appels ( Cali Admission en anglais) mis en oeuvre par le module de gestion d'admission d'appels dans le cadre du mode de réalisation particulier précité ; la figure 7 présente les étapes principales d'un algorithme d'observation de l'évolution des besoins en termes de bande passante pour la transmission d'un contenu ou flux actif donné en provenance d'un bus IEEE-1394, dans le cadre du mode de réalisation particulier précité ; les figures 8A à 8D présentent les étapes principales d'un algorithme d'observation conforme au mode de réalisation précité, sur un canal donné, d'un contenu ou flux donné, par exemple le contenu c0, dans le cas où le format de c0 identifié (figure 8A) est MPEG2 TS (figures 8B et 8C) ou DV (figure 8D). 6. Description d'un mode de réalisation de l'invention On décrit ci-après le procédé de transmission selon un mode de réalisation particulier de l'invention dans le cadre du réseau communication local 1000 de 20 type IP LAN de la figure 1. Le réseau local 1000 ci-après désigné par réseau IP LAN 1000 est par exemple un réseau domestique dans lequel des contenus de données notamment de typemultimédia sont transmis en respectant des critères de Qualité de Service (ou QoS pour Quality of Service ). 25 Le réseau IP LAN 1000 comprend un commutateur Ethernet 100 auquel sont connectés : - un premier nceud d'interconnexion IEEE-1394 / IP LAN 1011 via un premier segment Ethernet 104]. ; - un second noeud d'interconnexion IEEE-1394 / IP LAN 1012 via un 30 second segment Ethernet 1042 ; et - un terminal récepteur 102 qui est par exemple un ordinateur via un troisième segment Ethernet 1043. Un premier terminal source 1031 est connecté au premier noeud d'interconnexion IEE',E-1394 / IP LAN 1011 via un premier bus IEEE-1394 1051.
Un second terminal source 1032 est connecté au second noeud d'interconnexion IEEE-1394 / IP LAN 1012 via un second bus IEEE-1394 1052. Les segments Ethernet 1041, 1042, 1043 et le commutateur 100 mettent en oeuvre un protocole de transmission classiquement mis en oeuvre sur un réseau LAN tel que le protocole TCP/IP.
Bien entendu, le réseau 1000 peut mettre en oeuvre tout autre protocole de communication que le protocole TCP/IP, par exemple un protocole de type IEEE 1355, un protocole de type IEEE 1394 ou même tout autre protocole. En effet, le réseau 1000 peut constituer un réseau fédérateur ( backbone network en anglais) auquel sont connectés un ensemble de bus IEEE 1394 au moyen de noeuds d'interconnexion ( bridge en anglais) entre chacun des bus de type IEEE 1394 et le réseau fédérateur. Sur le réseau fédérateur convergent alors un certain nombre de flux de données devant transiter d'un bus IEEE 1394 à un autre. Les ressources du réseau fédérateur sont alors limitées vis-à-vis des ressources de l'ensemble des bus IEEE 1394 et l'invention appliquée à ce contexte permettra au réseau fédérateur de transporter un plus grand nombre de flux. On notera que le réseau IP LAN 1000 peut aussi bien être un réseau domestique qu'un réseau local d'entreprise, par exemple constitué partiellement ou totalement de segments sans fil (par exemple conformes aux normes Wifi ou Bluetooth , marques déposées). Bien entendu, l'invention peut être mise en oeuvre dans tout type de réseau de communication de type sans fil ou de type filaire. Dans la suite, on décrit le procédé de transmission selon le mode de réalisation particulier de l'invention précité dans un exemple particulier de la transmission, dans le réseau 1000 d'un contenu (ou flux) audio vidéo c0 (par exemple de type SD-DV ou HD-DV ou MPEG2, ...) depuis le premier terminal source 1031 (dispositif source) vers le terminal récepteur 102 (dispositif destinataire) via le premier noeud d'interconnexion IEEE-1394 / IP LAN 1011 (dispositif intermédiaire). Dans le cadre de cette transmission, le contenu c0 est transmis sur un chemin de transmission comprenant le dispositif source et le dispositif destinataire, ledit chemin de transmission comprenant également le dispositif intermédiaire. Le procédé de transmission selon l'invention (ci-après décrit de manière plus détaillée) est mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) dans une ou plusieurs machines du réseau IP LAN 1000 notamment le premier noeud d'interconnexion 1011. On présente, en relation avec la figure 2, un exemple d'architecture de protocole mis en oeuvre dans le premier noeud d'interconnexion IEEE-1394 / IP LAN 1011 lors de la réception de c0 selon le mode de réalisation particulier précité. Bien entendu, dans le cas où un contenu est transmis via le second noeud d'interconnexion 1012, cette architecture de protocole est également mise en oeuvre dans ce second noeud d'interconnexion 1012. Cette architecture comprend un premier domaine 215, dit domaine composant, et un second domaine 216, dit domaine logiciel. Un plan de données 214, représenté en pointillé sur la figure 2, montre les différents modules traversés par le contenu c0 dans le premier noeud d'interconnexion IEEE-1394 / IP LAN 1011. Ainsi, des paquets de données arrivent depuis le premier bus IEEE-1394 1051 et sont reçus par un module 200 IEEE-1394 PHY (ou Physical Layer ). Puis ils sont placés dans une mémoire FIFO (pour First In First Out ) d'un module de liaison IEEE 1394 ( IEEE 1394 Link Layer ) 201. Puis les paquets IEEE 1394 sont reçus dans le domaine logiciel 216 par un module de transaction IEEE-1394 203 ( IEEE 1394 Transaction Layer ). Seuls les paquets asynchrones nécessitent un traitement transactionnel particulier, selon la norme IEEE 1394. Les paquets isochrones, transportant les flux de données dans le cadre de l'invention, ne nécessitent pas de traitement particulier par le module de transaction IEEE-1394 203, et ces paquets sont alors fournis au module IEC 61883 204. Ensuite, le module IEC 61883 204 sélectionne les paquets propres au contenu cO parmi les paquets isochrones reçus. Puis, les paquets de transport de cO sont délivrés, par un pont ( bridge en anglais) 207, à un serveur RTP 208. Les modules [EEE-1394 PHY 200, module de liaison IEEE 1394 201 et module de transaction IEEE 1394 203 sont décrits dans les documents IEEE Std. 1394-1995, Standard for High Performance Serial Bus et IEEE Std 1394a-2000, Standard for High Performance Serial Bus Supplement . Le module IEC 61883 204 est conforme au standard IEC 61883 précité. Le pont 207 peut être implémenté tel qu'explicité dans le document IETF draft : RTP Payload Format For IEEE 1394/IEC 61883 Isochronous Streams rédigé par 13. Fairman et disponible notamment sur le site Internet dont l'adresse est http:/www.potaroo.netlietf/idref/draft-fairman-rtp-61883. Puis, les paquets de transport de cO sont transmis au moyen d'un chemin de données conforme au protocole RTP classique. Ainsi, les paquets de transports sont encapsulés dans des paquets RTP par le serveur RTP 208, puis sont transmis à une pile TCP/UDP/IP 211, puis sont transmis à un pilote ( driver ) Ethernet 212 puis à un contrôleur Ethernet 213. Le contrôle du pont comprend un module UPnP 206, un module HTTTP 209, un module RSVP 210, un module de gestion d'admission d'appels 205 et un module de d'observation 202.
Les protocoles UPnP, HTTP et RSVP sont des standards classiques qui permettent de réaliser de l'établissement de flux et du contrôle d'admission d'appels. Le module de gestion d'admission d'appels 205 reçoit des commandes de contrôle d'admission d'appel provenant du module UPnP 206 et réalise l'établissement de connexions de flux ( stream connections en anglais) sur le bus IEEE-1394 au moyen du module IEC 61183 204 selon la norme IEC 61883. Le module de gestion d'admission d'appels 205 utilise également les services du module d'observation 202 pour réaliser de la surveillance (de l'observation) des flux afin d'ajuster la réservation de bande passante réalisée par le module UPnP 206 et le module RSVP 210 tel que prévue dans la présente invention. On présente, en relation avec la figure 3, un exemple d'implémentation du premier noeud d'interconnexion IEEE-1394 / IP LAN 1011 selon le mode de réalisation particulier précité. Dans le cadre du mode de réalisation particulier précité, le second noeud d'interconnexion 1012 est implémenté de la même manière que le premier noeud d'interconnexion 1011. Le premier nceud d'interconnexion 1011 comprend trois cartes, une carte de CPU 300 (ou carte de microprocesseur), une carte IEEE-1394 301 et une carte PCI (pour Protocol Control Information ) Ethernet 302. Ces cartes sont interconnectées via un bus PCI (pour Protocol Control Information ) 303. Au niveau de la carte CPU 300, un microprocesseur 309 (qui est par exemple un microprocesseur compatible x86 tel qu'un microprocesseur commercialisé sous la référence PENTIUM par la société INTEL , marques déposées) est connecté à une mémoire 310 et à un pont de bus PCI 311 (qui est par exemple le pont commercialisé sous la référence INTEL 82801 par la société INTEL , marque déposée). Le pont de bus PCI 311 est relié au bus PCI 303 via un contrôleur PCI 308. Le domaine logiciel de l'architecture de protocole de la figure 2 est implémenté dans le microprocesseur 309.
La carte IEEE-1394 301 comprend une interface physique (ou PHY interface ) IEEE-1394 304 relié à un module de lien IEEE-1394 305, lui-même relié à un module d'observation de trafic 306 et à un module d'interface PCI 307. L'interface physique IEEE-1394 304 est par exemple l'interface commercialisée sous la référence : TSB41BA3A par la société TEXAS INSTRUMENT , marque déposée, et le module de lien IEEE-1394 305 est par exemple le module commercialisé sous la référence TSB 12LV26 par la société TEXAS INSTRUMENT , rnarque déposée. Le module d'observation de trafic 306 (détaillé ci-après) observe les flux IEEE- 1394 entrants afin de donner des indications relatives à la bande passante au microprocesseur 309. La mise en oeuvre d'un tel noeud d'interconnexion IEEE-1394 / IP LAN 1011 peut alternativement être réalisée sur la base d'un nombre différent de cartes électroniques. On présente, en relation avec la figure 4, les étapes principales d'un algorithme d'observation mis en oeuvre par le module d'observation de trafic 306 lors de l'ouverture d'une connexion pour la transmission d'un flux, par exemple cO, entre le premier bus IEEE-1394 1051 et le premier segment Ethernet 1041 du réseau IP/LAN 1000 selon le mode de réalisation particulier précité. A chaque connexion, le module d'observation de trafic 306 observe (ou surveille), pendant une phase dite phase d'observation d'une durée déterminée, les caractéristiques du flux ci-après détaillées et transmet ces caractéristiques au module de gestion d'admission d'appels 205. De même qu'en tache de fond, le module d'observation 306 informe le module de gestion d'admission d'appels 205 lors d'un changement de caractéristique des flux dont les connexions ont déjà été établies. Dans une étape 400, lors de l'établissement d'une connexion pour la transmission de cO, ou au début d'une phase d'observation sur un flux dont la connexion a déjà été établie, le module d'observation de trafic 306 est initialisé pour cette connexion (identifiée par un numéro de canal isochrone IEEE-1394).
La phase d'observation commence à cet instant pour ce canal. Lors d'une étape 401, le module d'observation de trafic 306 attend la réception d'un paquet isochrone de type IEEE-1394 appartenant à la connexion établie pour la transmission du flux c0. Lors d'une étape 402, à la réception d'un paquet courant, le module d'observation de trafic 306 vérifie la continuité du flux cO. La discontinuité peut être vérifiée au moyen des informations DBC (pour Data Block Count ) contenues dans les entêtes CIP des paquets selon la norme IEC 61883, et sera plus amplement décrit en relation avec les figures 8A à 8D. Puis, dans une étape 403, si une discontinuité est détectée au niveau du flux cO (par exemple due à une perte de paquet), dans l'étape 400, la phase d'observation est réinitialisée puisque l'algorithme d'observation selon l'invention est basé sur une comparaison continue d'informations d'horodatages (tel qu'expliqué ci-après). Si aucune discontinuité n'est détectée au niveau du flux cO, alors dans une étape 404 est enregistrée la taille maximale de paquet observée pendant la phase d'observation. Puis, dans l'étape 405, il est vérifié si un entête de paquet de type TS est présente dans le paquet isochrone courant. Tel que définit dans la norme IEC 61883, les paquets de type TS peuvent être segmentés en plusieurs paquets isochrones de type IEEE-1394 ou plusieurs paquets de type TS peuvent être concaténés en un unique paquet isochrone de type IEEE-1394. Si aucun entête de paquet de type TS n'est présent dans le paquet isochrone courant, alors l'étape 401 est remise en oeuvre afin d'attendre le prochain paquet isochrone appartenant à la connexion établie pour la transmission du flux cO. Si un entête de paquet de type TS est présent dans le paquet IEEE-1394 isochrone courant, alors dans une étape 406, l'horodatage courant est obtenu à partir d'une information d'horodatage comprise dans chaque paquet de transport. Par exemple l'information d'horodatage d'un paquet de type TS est comprise dans l'entête dudit paquet. Puis, dans une étape 407, la valeur du débit réel de ce flux cO (ou bande passante nécessaire réelle de ce flux c0) est calculée à partir de la connaissance de l'intervalle de temps entre l'information d'horodatage du paquet de paquet de type TS courant et l'information d'horodatage d'un paquet de paquet de type TS précédent. Pour ce faire, on utilise l'information d'horodatage enregistrée pendant le traitement du paquet précédent. Ainsi, cette étape n'est pas mise en oeuvre la première fois lors de la réception du premier paquet isochrone appartenant à la connexion établie pour la transmission du flux cO. Dans une étape 408, l'information d'horodatage courante est enregistrée pour être utilisée pour le calcul du débit lors de l'analyse du prochain paquet. Dans une étape 409, on compare la valeur du débit calculée pour le paquet courant avec la valeur du débit précédemment calculée (cette étape n'est pas mise en oeuvre pour le premier paquet reçu). Si les valeurs de débit sont identiques, on augmente un compteur de débit constant ci-après (explicité en relation avec la figure 5) référencé par compteur CBR 508 (pour Constant Bit Rate ) dans une étape 410. Si les valeurs de débit sont différentes, on diminue le compteur CBR dans une étape 411. A la fin de la phase d'observation, si le compteur CBR présente une valeur positive, alors le flux cO est qualifié de flux à comportement à débit constant ou de flux à comportement CBR ; si le compteur CBR présente une valeur négative, alors le flux cO est qualifié de flux à comportement à débit variable ou de flux à comportement VBR . Puis, dans une. étape 412, il est vérifié si un autre entête de paquet de type TS est présent dans le paquet isochrone courant. Dans l'affirmative, l'étape 406 est remise en oeuvre. Dans le cas contraire, dans une étape 413, il est vérifié si la phase d'observation a expiré.
Si la phase d'observation n'a pas expiré, alors l'étape 401 est remise en oeuvre afin d'attendre le prochain paquet isochrone appartenant à la connexion établie pour la transmission du flux cO. Si la phase d'observation a expiré, alors dans une étape 414, les caractéristiques (notamment en termes de débit) du flux cO sont envoyées au 25 module de gestion d'admission d'appels 205. Les caractéristiques du flux cO précitées peuvent inclure le comportement CBR ou VBR du flux et/ou le débit du flux et/ou la taille maximale de paquet isochrone observée si le flux est un flux à comportement VBR. Puis, l'étape 400 est remise en oeuvre pour une nouvelle phase 30 d'observation.
On présente, en relation avec la figure 5, un exemple d'implémentation du module d'observation de trafic 306 selon le mode de réalisation particulier précité. Le module d'observation de trafic 306 comprend : une mémoire de réception 503 dans laquelle les paquets isochrones de type 5 IEEE-1394 reçus sont stockés ; un analyseur de paquets 504 qui calcule le débit du flux c0 grâce à l'analyse des paquets isochrones reçus (tel que décrit en relation avec la figure 4) ; des registres d'interface microprocesseur 500 qui communiquent avec le 10 microprocesseur 309 ; des registres internes 505 utilisés par l'analyseur de paquets 504 afin de réaliser l'observation tel que précédemment décrit en relation avec la figure 4 et tel que décrit plus en détail ci-après, en relation avec les figures 8A à 8D. Les registres d'interface microprocesseur 500 sont répartis en 15 deux ensembles de 64 registres chacun ; un ensemble de 64 registres de trafic 501 et un ensemble de 64 registres de paramètres (ou params ) 502, un registre de trafic et un registre de paramètres étant associé à chaque canal de transmission en mode isochrone sur 1[e bus IEEE 1394 (il y a 64 canaux de transmission en mode 20 isochrone disponibles sur un bus IEEE 1394) et donc correspondant à un flux donné. Le registre de trafic reflète le type du flux (le type peut être par exemple SD-DV, HD-DV, MPEG2 CBR ou MPEG2 VBR). Le registre params 502 comprend la valeur du débit si le flux est à comportement CBR (par exemple SD-DV, HD-DV, MPEG2 CBR) et la taille maximale 25 du paquet isochrone observée pendant la phase d'observation si le trafic est à comportement VBR (par exemple MPEG2 VBR) ; un registre Start_monitoring(i) 514 indiquant que le canal i a été validé ou pas pour le contrôle par le module de gestion d'admission d'appels 205 ; Les registres internes 505 sont répartis en 8 ensembles de 64 registres, 30 chacun des registres parmi les 64 correspondant à un canal isochrone, ils sont notamment pour le canal i. : un registre TS(i) 506 qui est un pointeur vers l'entête du paquet de type TS: un registre Period(i) 507 qui enregistre la durée de la phase d'observation ; un registre CBR(i) 508 qui est le compteur CBR précité. Ce compteur est représentatif des caractéristiques en termes de débit du flux ; si l'on observe un flux à comportement CBR pendant la phase d'observation, alors la valeur du compteur CBR 508 est égale à la valeur du registre Period(i) 507 - un registre Rai:e(i) 509 qui comprend la valeur du débit ; un registre Start_period(i) 510 qui indique qu'une nouvelle phase d'observation commence ; un registre DBC(i) (pour Data Block Count ) 511 qui est un compteur de blocs de données déjà traités du flux transporté ; - un registre Reinit(i) 512 qui indique si l'on doit réinitialiser les statistiques de canal ou pas ; un registre Max(i) qui stocke la taille maximale de contenu de paquet isochrone observée pendant la phase d'observation. Le module d'observation de trafic 306 comprend en outre un ensemble de registres (ou variables) de calcul intermédiaire : -un registre Ch qui identifie le canal de transmission dont le paquet isochrone en cours d'analyse est issu ; un registre Payload_Length et un registre DBC_temp qui sont utilisés lors de calcul de taille de données traitées ou à traiter ; - un registre Payload_Type qui indique le type de données que contient le paquet isochrone en cours d'analyse (DV, MPEG2) et un registre SD_HD qui permet d'indiquer, dans le cas d'un contenu de type DV, la définition du contenu (définition standard SD-DVCR ou haute définition HDDVCR) ; - un registre Tick_nb et un registre Cycle_nb qui servent respectivement à indiquer un nombre de coup d'horloge du bus IEEE 1394 et un nombre de cycle du bus IEEE 1394 ; un registre K qui indique un nombre de blocs de données de 192 octets ; un registre R qui indique un débit calculé ; un registre TS_temp qui est utilisé pour stocker temporairement l'entête d'un paquet de type TS. On présente, en relation avec la figure 6, les étapes principales d'un algorithme de contrôle de l'admission d'appels mis en oeuvre par le module de gestion d'admission d'appels 205 dans le cadre du mode de réalisation particulier précité. Dans une étape 600, un appel pour une connexion, provenant par exemple d'un module 206 selon le standard UPnP, est reçu. Puis, dans une étape 601, une lecture, selon les normes IEEE 1394 et IEC 61883, du registre oPCR (pour output Plug Control Register tel que défini par la norme IEC 61883) du premier terminal source 1031 permet d'obtenir le débit maximum que le premier terminal source 1031 est capable de délivrer. Puis, dans une étape 602, une tentative de réservation de ressources sur le premier bus IEEE-1394 1051, tel que décrit dans la norme IEEE 1394 est mise en oeuvre auprès de l'équipement IRM (pour Isochronous Ressource Manager ) du bus IEEE 1394 pour l'obtention d'un canal isochrone donné et d'une bande passante associée. Dans une étape 613, si aucune réservation de ressource n'est possible, alors dans une étape 608, l'appel est rejeté. Si la réservation de ressources est réussie (elle correspond au débit exporté par le premier terminal source selon les normes IEEE 1394 et IEC 61883, c'est-à-dire le débit maximum que le premier terminal source 1031 est capable de délivrer), alors, dans une étape 610, le module d'observation de trafic 306 est initialisé pour le canal IEEE-1394 obtenu dans l'étape 602 précitée. Pour l'initialisation, on attribue les valeurs 1 au registre Start_monitoring 514 du canal obtenu, non à la variable backgroundMonitoring du canal obtenu et non à la variable alreadyAdjusted du canal obtenu. La variable backgroundMonitoring sert à indiquer si, pour le canal obtenu, une phase d'observation du trafic doit être exécutée. La variable alreadyAdjusted sert à indiquer si, pour le canal obtenu, la bande passante (ou les ressources) nécessaire à la transmission du flux sur le réseau IP LAN a déjà été ajustée. Puis, dans une. étape 603, une tentative de réservation de ressources sur le réseau IP LAN 1000 conformément au protocole RSVP avec une valeur de bande passante, correspondant au débit maximum que le premier terminal source 1031 est capable de délivrer, obtenue dans l'étape 601 est mise en oeuvre.
Dans une étape 614, il est vérifié si la réservation de ressources a réussi. Si la réservation de ressources a réussi, alors dans une étape 604, l'appel est accepté, la valeur correspondant au débit maximum du premier terminal source 1031 est attribuée à la variable local_Param et la valeur inconnue est attribuée à la variable local_Traffic du canal obtenu. Puis il est mis fin à l'algorithme.
Les variables local_Param et local_Traffic servent à mémoriser les caractéristiques d'un flux afin d'en mesurer le changement lors de la détection d'un changement de nature de flux tel que décrit ci-après en relation avec la figure 7. Si la réservation de ressources n'a pas réussi, alors dans une étape 605, l'appel est accepté mais le chemin de données n'est pas encore ouvert. Le chemin de données n'est ouvert que du côté du premier bus IEEE-1364 1051. Ceci permet d'observer le trafic IEEE-1394. Les paquets IEEE-1394 ne sont pas retransmis vers le réseau IP LAN 1000 mais sont avalés (ou swallowed en anglais). Puis, dans une étape 606, les caractéristiques (notamment en termes de débit) du flux cO sont: attendues par le module de gestion d'admission d'appels 205. Les caractéristiques du flux cO sont annoncées grâce à une interruption générée par le module d'observation de trafic 306, une fois que celui-ci les a obtenues tel que précédemment décrit en relation avec la figure 4.
Puis, dans une étape 611, lorsque les caractéristiques de cO sont reçues, les caractéristiques de cO sont lues dans les registres Traffic et Param du canal obtenu. Si le flux cO est un flux à comportement CBR alors le registre Param comprend la valeur du débit lue dans les caractéristiques du flux c0, si le flux cO est un flux à comportement VBR alors le registre Param comprend la valeur du débit maximum que le premier terminal source 1031 est capable de délivrer (oPCR). Puis dans une étape 612, la valeur du débit lue dans les caractéristiques est comparée avec la valeur du débit maximum que le premier terminal source 1031 est capable de délivrer (obtenue dans l'étape 601).
Si les deux valeurs sont égales, alors cela signifie qu'il est impossible de réserver des ressources sur le réseau IP LAN 1000 pour la transmission de cO puisqu'une telle réservation a déjà échoué dans l'étape 603. Alors, dans une étape 617, les ressources réservées sur le premier bus IEE-1394 1051 sont libérées et la connexion IEEE-1394 est fermée, puis, dans une étape 609, les ressources allouées dans l'étape 605 sont libérées. Puis, il est mis fin à l'algorithme. Si la valeur du débit lue dans les caractéristiques est inférieure à la valeur du débit maximum que le premier terminal source 1031 est capable de délivrer, alors, dans une étape 607, une réservation de ressources (par exemple conforme au protocole RSVP) sur le réseau IP LAN 1000 est à nouveau tentée mais avec la valeur de débit (ou de bande passante) lue, c'est-à-dire que la valeur de la réservation demandée est inférieure à la valeur précédemment demandée à l'étape 603. Puis, dans une étape 615, il est vérifié si la tentative de réservation de ressources a réussi. Si la tentative de réservation de ressource a échoué, alors l'étape 617 est mise en ceuvre. Si la tentative de réservation de ressource a réussi, alors dans une étape 616, ravalement (ou swallowing ) des paquets est arrêté et un chemin de données est ouvert entre le premier bus IEEE-1394 1051 et le réseau IP LAN 1000. Puis, on attribue la valeur oui à la variable backgroundMonitoring, la valeur oui à la variable alreadyAdjusted pour le canal obtenu, on attribue la valeur du registre Traffic à la variable local_Traffic et la valeur du registre Param à la variable local_Param pour le canal obtenu. On présente, en relation avec la figure 7, les étapes principales d'un algorithme d'observation de l'évolution des besoins en termes de bande passante pour la transmission d'un contenu ou flux actif donné en provenance d'un bus IEEE-1394, dans le cadre du mode de réalisation particulier précité. Cet algorithme est mis en oeuvre en arrière-plan. Il permet de détecter un changement en termes de besoin en bande passante pour la transmission des flux. Si un changement en termes de besoin en bande passante est détecté, alors l'algorithme permet cle réaliser un ajustement de la réservation de ressources (par exemple conforme au protocole RSVP) sur le réseau IP LAN 1000. Dans une étape 701, lors d'une interruption générée par le module d'observation de trafic 306, l'algorithme obtient pour le contenu donné, par exemple le flux c0, en transmission sur un canal donné, les caractéristiques du contenu donné stockées dans les registres Param et Traffic associés au canal donné. Puis, dans l'étape 713, il est vérifié s'il est nécessaire de réaliser une observation en arrière-plan pour le flux donné (c'est-à-dire si un registre backgroungMonitoring pour le canal donné présente la valeur oui ). La première observation peut être réalisée pendant la phase d'admission d'appel du contenu donné si la réservation de la bande passante correspondant au débit maximum échoue au niveau du réseau IP LAN 1000. S'il n'est pas nécessaire de réaliser une observation en arrière-plan pour le contenu donné, alors, dans une étape 715, il est mis fin à l'algorithme.
S'il est nécessaire de réaliser une observation en arrière-plan pour le contenu donné, alors, dans une étape 702, il est vérifié si la bande passante a déjà été ajustée pour ce contenu donné (c'est-à-dire si un registre alreadyAdjusted pour le canal donné présente la valeur oui ). La première réservation est basée sur le débit maximum que peut fournir le premier terminal source 1031 et le premier ajustement est basé sur les propriétés du contenu donné (par exemple le type du flux : DV, MPEG2 CBR, MPEG2 VBR, ...). Ainsi, lorsqu'un premier ajustement a eu lieu, seuls les changements de débit pour le contenu donné importent. Si le débit a déjà été ajusté pour ce contenu donné, alors une étape 708 est mise en oeuvre, sinon, une étape 703 est mise en oeuvre. Dans l'étape 703, il est vérifié si le contenu donné est un contenu de type DV (c'est-à- dire si le registre Traffic pour le canal donné présente la valeur DV ). Si le contenu donné est un contenu de type DV, alors dans une étape 704, il est mis en oeuvre un ajustement de la réservation de ressources sur le réseau IP LAN 1000 pour le contenu donné au niveau du débit DV, par exemple on réserve 3OMbit/s pour un contenu donné de type SD-DV et 6OMbit/s pour un contenu donné de type HD-DV et on attribue la valeur du registre Param à la variable local_Param pour le canal donné et la valeur du registreTraffic à la variable local_Traffic pour le canal donné.
Si le contenu donné n'est pas un contenu de type DV mais un contenu de type MPEG2 TS (pour Transport Stream ), alors dans une étape 706, il est vérifié si le contenu est un contenu à comportement CBR (c'est-à-dire si le registre Traffic pour le canal donné présente la valeur CBR ). Si le contenu donné n'est pas à comportement CBR, alors, dans une étape 705, la réservation de ressources pour le contenu donné sur le réseau IP LAN 1000 est ajustée à la valeur pic du débit qui est stockée dans le registre Param du canal donné et l'on attribue la valeur du registre Param à la variable local_Param pour le canal donné et la valeur du registre Traffic à la variable local_Traffic pour le canal donné. Si le contenu donné est à comportement CBR, alors, dans une étape 707, la réservation de ressources pour le contenu donné sur le réseau IP LAN 1000 est ajustée à la valeur calculée du débit qui est stockée dans le registre Param du canal donné et l'on attribue la valeur du registre Param à la variable local_Param pour le canal donné et la valeur du registre Traffic à la variable local_Traffic pour le canal donné.
Dans l'étape 708, (le fait que 1"étape 708 soit mise en oeuvre signifie que la nature du contenu donné a changé) les valeurs des registres Traffic et Param pour le canal donné sont comparées aux valeurs des variables, respectivement, local_Traffic et local_Param pour le canal donné afin de déterminer si le débit requis a augmenté ou a diminué.
Si le débit requis a diminué, alors dans une étape 709, la réservation de ressources dans le réseau IP LAN pour le contenu donné est réduite à la valeur requise et l'on attribue la valeur du registre Param à la variable local_Param pour le canal donné et la valeur du registre Traffic à la variable local_Traffic pour le canal donné. Puis il est mis fin à l'algorithme.
Si le débit requis a augmenté, alors dans une étape 710, il est tenté d'augmenter la réservation de ressources dans le réseau IP LAN pour le contenu donné. Puis, dans une étape 711, on vérifie si l'augmentation de la réservation de ressources dans le réseau IP LAN pour le contenu donné a réussi ou pas. Si l'augmentation a réussi, alors, dans une étape 714, on attribue la valeur du registre Param à la variable local_Param pour le canal donné et la valeur du registre Traffic à la variable local_Traffic pour le canal donné. Puis il est mis fin à l'algorithme. Si l'augmentation a échoué, alors, dans une étape 712, les connexions du côté IEEE-1394 et du côté IP LAN sont libérées, en effet il n'y a pas assez de ressources pour transmettre le contenu donné. La connexion qui avait été établie pour la transmission du flux est alors stoppée, le réseau étant dans l'incapacité de poursuivre cette transmission. Puis il est mis fin à l'algorithme. On présente, en relation avec les figures 8A à 8D, les étapes principales d'un algorithme d'observation conforme au mode de réalisation précité, sur un canal donné, d'un contenu donné, par exemple le contenu c0, dans le cas où le format de c0 identifié (figure 8A) est MPEG2 TS (figures 8B et 8C) ou DV (figure 8D). Cet algorithme est mis en oeuvre par l'analyseur de paquets 504 du module d'observation de traffie 306.
Si le registre Start_monitoring associé au canal donné présente la valeur 1, alors dans une étape 801, l'algorithme est initialisé. Puis, dans une étape 802, l'algorithme attend la réception d'un nouveau paquet isochrone IEEE-1394. Si aucun nouveau paquet isochrone n'est reçu, alors l'étape 802 est remise en oeuvre.
A la réception d'un nouveau paquet isochrone IEEE-1394, dans une étape 803, le champ TAG (tel que défini dans la norme IEEE-1394) de l'entête du paquet isochrone IEEE-1394 est lu. Si le champ TAG présente la valeur 01 (ce qui signifie que le paquet isochrone comprend une entête CIP telle que définie dans la norme IEC 61883), alors une étape 804 est mise en oeuvre. Sinon, l'étape 801 est à nouveau mise en oeuvre. Dans l'étape 804, le champ FMT (tel que définie dans la norme IEC 61883) de l'entête CIP est lu. Si le champ FMT présente la valeur binaire 100000 (ce qui indique que le contenu cO est un contenu de type MPEG2) alors l'étape 806 est mise en oeuvre pour un traitement spécifique aux contenus MPEG2. Sinon, dans une étape 805, si champ FMT présente la valeur binaire 000000 (ce qui indique que le contenu cO est un contenu de type DV) alors l'étape 807 est mise en oeuvre pour un traitement spécifique aux contenus DV. Sinon, l'étape 801 est à nouveau mise en oeuvre.
Dans l'étape 806, le registre DBC 511 ainsi que des registres Ch, Payload_Type (type de contenu du paquet isochrone) et Payload_Length (longueur du contenu du paquet isochrone) sont remplis. Le registre DBC_temp est rempli avec les bits 7 à 0 de l'entête CIP (CIP [7...0]), ces bits représentant, selon la norme IEC 61883, un comptage de blocs de données (ou Data Block Count ). Le registre Ch est rempli avec les bits 13 à 8 de l'entête Iso Header (Iso Header [13... 8]) du paquet isochrone, ces bits représentant, selon la norme IEEE-1394, le canal isochrone utilisé pour la transmission du paquet. La valeur MPEG2 est attribuée au registre Payload_Type. Le registre Payload_Length est rempli avec les bits 31 à 6 de l'entête Iso Header (Iso Header [31...16]) du paquet isochrone, ces bits représentant, selon la norme IEEE-1394, la taille du paquet isochrone sans prendre en compte la taille de l'entête lui-même ni les champs réservés Header_CRC et Data_CRC utilisés pour le contrôle de l'intégrité des données. Puis, dans une étape 808, on vérifie si le registre Reinit présente la valeur 1 pour le canal donné. Si c'est le cas, alors dans une étape 809, on met en oeuvre une initialisation des registres associés au canal donné dans laquelle on attribue les valeurs suivantes : TS= vide ; Period = 0 ; Max = 8, correspondant à la taille d'un paquet isochrone ne contenant qu'un entête CIP sans bloc de données associé ; CBR = 0 (plus le registre CBR possède une valeur élevée, plus la probabilité d'avoir un flux à débit constant est élevée) ; Traffic = vide ; Rate = 0 ; Reinit = 0 ; Start_period = 1 ; DBC = vide . Puis l'étape 808 est à nouveau mise en oeuvre.
Si le registre Reinit ne présente pas la valeur 1 pour le canal donné, alors dans une étape 810, il est vérifié si le registre Start_period présente la valeur 1 pour le canal donné. Si le registre Start_period présente la valeur 1 pour le canal donné, alors dans une étape 811, on met en oeuvre une initialisation des registres associés au canal donné dans laquelle on attribue les valeurs suivantes : TS=0; Rate =0; Period = 0 ; Max = 8, correspondant à la taille d'un paquet isochrone ne contenant qu'un entête CIP sans bloc de données associé ; CBR = 0 (plus le registre CBR possède une valeur élevée, plus la probabilité d'avoir un flux à débit constant est élevée) ; Start_period == 0 ; DBC = DBC_temp (bits 0 à 7 de l'entête CIP).
Puis l'étape 801 est à nouveau mise en oeuvre. Si le registre Start_period ne présente pas la valeur 1 pour le canal donné (mais plutôt la valeur 0), alors dans une étape 812, on vérifie si l'égalité suivante est vraie : Payload_Length ù 8 = (DBC_temp ù DBC) * 24 pour le canal donné où DBC est le registre stockant le résultat du comptage de bloc de données depuis le début jusqu'au paquet courant (pour le canal Ch donné), 8 est la taille en octets de l'entête CIP (en effet, l'information de longueur donnée dans l'entête du paquet isochrone prend en compte l'entête CIP) et le coefficient 24 correspond au nombre d'octets par bloc de données selon la norme IEC 61883.
Dans le cas où l'égalité n'est pas vérifiée, cela signifie qu'il y a discontinuité dans la réception des paquets, c'est-à-dire qu'au moins un paquet a été perdu et dans ce cas, dans une étape 814, la valeur 1 est attribuée au registre Reinit associé au canal donné afin de réinitialiser les statistiques (du fait de la détection de la perte d'au moins un paquet). Puis, l'étape 801 est à nouveau mise en oeuvre. Dans le cas où l'égalité est vérifiée, cela signifie qu'aucun paquet n'a été perdu et dans ce cas, dans une étape 813, la taille du contenu du paquet isochrone courant (registre Payload_Length) est comparée avec la taille maximale précédemment enregistrée (registre Max pour le canal donné).
Si la taille du contenu du paquet isochrone courant est supérieure à la taille maximale précédemment enregistrée, alors, une étape 816 est mise en oeuvre. Si la taille du contenu du paquet isochrone courant est supérieure à la taille maximale précédemment enregistrée, alors, dans une étape 815, la longueur du paquet isochrone couvrant est enregistrée dans le registre Max associé au canal donné puis l'étape 816 est mise en oeuvre.
Dans l'étape 816, on affecte la valeur du registre DBC_temp au registre DBC. Puis, dans une étape 817, on vérifie si les trois bits les moins significatifs (ou Less Significant Bit LSB) du registre DBC_temp sont égaux à 000. Si c'est le cas, cela signifie que l'on n'est pas au début d'un paquet de type TS et alors l'étape 801 est à nouveau mise en oeuvre. Si les trois bits les moins significatifs du registre DBC_temp (équivalent à ce niveau de l'algorithme avec le contenu du registre DBC pour le canal donné) sont égaux à 000, cela signifie qu'on est au début d'un paquet de type TS et alors dans une étape 818, on enregistre dans un registre K le nombre de paquets de type TS compris dans le paquet isochrone (la valeur stockée dans le registre K est donnée par l'expression : K = Int (Payload_Length - 8) / 192, 8 étant la taille en octets de l'entête 1CIP et 192 est la taille en octets d'un paquet au format MPEG2 TS. En effet, un même paquet isochrone peut contenir plusieurs paquets de type TS (dont le nombre est identifié par la variable K), et l'algorithme vise à appliquer un traitement sur chacun de ces paquets de type TS. Puis, dans une étape 819, on attribue la prochaine entête de paquet de type TS (la première en cas de premier passage à l'étape 819) au registre TS_temp et l'on augmente la valeur du registre Period associé au canal donné.
Puis, dans une étape 820, il est vérifié si aucune valeur n'a été attribuée au registre TS associé au canal donné. Le registre TS 506 enregistre la dernière entête de paquet de type TS pour un canal donné, il est utilisé pour surveiller une progression lorsque comparé avec la valeur courante d'entête du paquet de type TS contenue dans le registre TS_temp.
Si aucune valeur n'a été attribuée au registre TS associé au canal donné, alors, dans une étape 828, la valeur du registre TS_temp est affectée au registre TS associé au canal donné puis une étape 829 est mise en oeuvre. Si une valeur a été attribuée au registre TS associé au canal donné, alors, dans une étape 821, on attribue : - la différence entre les bits 24 à 13 du registre TS_temp (TS (24..13)) et les bits 24 à 13 clu registre TS 506 (TS(24..13)) associé au canal donné au registre Cycle__nb qui représente le nombre de cycles de bus IEEE 1394 qui se sont produits depuis le dernier paquet de type TS (qui peut être contenu dans le même paquet isochrone de type IEEE 1394) ; la différence entre les bits 11 à 0 du registre TS_temp (TS (11..0)) et les bits 11 à 0 du registre TS 506 (TS(11..0)) associé au canal donné à un registre Tick_nb qui représente le nombre de coups d'horloge IEEE1394 (ou ticks en anglais) qui se sont produits depuis le dernier paquet de type TS (qui peut être contenu dans le même paquet isochrone de type IEEE 1394) ; La combinaison des cycles et des ticks qui se sont produits donne le temps écoulé depuis le précédent paquet de type TS analysé jusqu'au paquet de type TS courant. Puis, dans une étape 822, on calcule le débit R réel de l'application génératrice du flux de données comme étant 188 octets divisés par le temps écoulé précité, 188 octets correspondant à la taille du contenu d'un paquet de type TS selon la norme IEC 61883. Puis, dans une étape 823, on vérifie si une valeur est attribuée au registre Rate 509 associé au canal donné.
Si une valeur n'est pas encore attribuée au registre Rate 509 associé au canal donné, alors dans une étape 824, on attribue la valeur R au registre Rate 509 associé au canal donné puis une étape 829 est mise en oeuvre. Si une valeur est attribuée au registre Rate 509 associé au canal donné, alors dans une étape 825, les valeurs de R et du registre Rate 509 associé au canal donné sont comparées. Si ces valeurs sont égales, alors, dans une étape 827, on incrémente le compteur CBR 508 associé au canal donné. Si ces valeurs sont différentes, alors, dans une étape 826, on décrémente le compteur CBR 508 associé au canal donné. Puis, après chacune des étapes 826 et 827, dans une étape 829, le registre K est décrémenté.
Ensuite, dans une étape 830, on compare la valeur de K avec 0. Si K est strictement supérieur à 0 (ce qui signifie qu'il y a encore d'autres blocs de 192 octets (c'est-à-dire d'autres paquets de type TS) dans le paquet isochrone à traiter), alors on remet en oeuvre l'étape 819. Si la valeur de. K est 0, alors, dans une étape 831, on vérifie si on a atteint la fin de la phase d'observation pour ce contenu cO donné (c'est-à-dire qu'on vérifie si le registre Period associé au canal donné correspond à une valeur prédéterminée "Th" qui définie la durée de la période d'observation). Si tel n'est pas le cas, alors l'étape 801 est remise en oeuvre. Si la phase d'observation est arrivée à son terme, alors il est nécessaire d'envoyer les caractéristiques du contenu cO au microprocesseur 309. Ainsi, dans une étape 834, il est vérifié si une valeur a été attribuée au registre Traffic 501 associé au canal donné. Si aucune valeur n'a été attribuée au registre Traffic 501 (c'est-à-dire qu'il présente la valeur vide ) associé au canal donné, alors on met en oeuvre une étape 836. Si une valeur a été attribuée au registre Traffic 501 associé au canal donné, alors dans une étape 835, on vérifie si, pendant la phase d'observation, un contenu à comportement CBR a été observé (c'est-à-dire qu'on vérifie si le compteur CBR présente la valeur prédéterminée "Th"). Si tel est le cas, on met en oeuvre une étape 839. Sinon, on met en oeuvre une étape 841. Lors de l'étape 836, on vérifie si, pendant la phase d'observation, un contenu à comportement CBR a été enregistré. Si oui, on met en oeuvre une étape 837 et sinon, on met en oeuvre une étape 838. Dans l'étape 837, on vérifie si le débit précédemment enregistré dans le registre Param 502 est égal à la valeur du débit courant enregistrée dans le registre Rate 509 asocié au canal donné. Si le débit précédemment enregistré dans le registre Param 502 est égal à la valeur du débit courant enregistrée dans le registre Rate 509, ce qui signifie qu'aucune nouvelle information ne doit être communiquée au microprocesseur 309, alors une étape 840 est mise en oeuvre.
Si le débit précédemment enregistré dans le registre Param 502 est différent de la valeur du débit courant enregistrée dans le registre Rate 509, ce qui signifie que des nouvelles informations doivent être communiquées au microprocesseur 309, alors une étape 839 est mise en oeuvre.
Dans l'étape 838, il est vérifié si le débit courant enregistré dans le registre Param 502 est égal à la valeur du débit maximal enregistrée dans le registre Max 509 associé au canal donné. Si le débit maximal courant enregistré dans le registre Param 502 est égal à la valeur du débit maximal précédemment enregistrée dans le registre Max 509 associé au canal donné, ce qui signifie qu'aucune nouvelle information ne doit être communiquée au microprocesseur 309, alors l'étape 840 est mise en oeuvre. Si le débit maximal courant enregistré dans le registre Param 502 est différent de la valeur du débit maximal précédemment enregistrée dans le registre Max 509 associé au canal donné, ce qui signifie que des nouvelles informations doivent être communiquées au microprocesseur 309, alors l'étape 841 est mise en oeuvre. Dans l'étape 839, on attribue la valeur CBR au registre Traffic 501 associé au canal donné, on enregistre le débit dans le registre Param 502 associé au canal donné puis l'étape 840 est mise en oeuvre.
Dans l'étape 841, on attribue la valeur VBR au registre Traffic 501 associé au canal donné, on enregistre le débit maximal dans le registre Param 502 associé au canal donné puis l'étape 840 est mise en oeuvre. Dans l'étape 840, on attribue la valeur 1 au registre Start_period 510 associé au canal donné puis l'étape 801 est remise en oeuvre.
Concernant le traitement mis en oeuvre dans le cas d'un contenu cO de type DV, il n'est pas nécessaire d'observer le contenu cO. Un contenu de type DV est un contenu à comportement CBR. Dans l'étape 807, les registres Ch, Payload_Type (type de contenu du paquet isochrone) et SD_HD (qui porte l'information selon laquelle le flux est de type SD-DVCR ou HI)-DVCR, dans le cas ou le registre Payload_Type identifie un contenu de type DV) sont remplis. Le registre SD_HD est rempli avec les bits 23 à 19 de l'entête C][P (CIP header [23...19]), le registre Ch est rempli avec les bits 13 à 8 de l'entête Iso Header (Iso Header [13...8]) du paquet isochrone et la valeur DV est attribuée au registre Payload_Type.
Puis, dans une étape 842, on vérifie si le registre Reinit présente la valeur 1 pour le canal donné. Si c'est le cas, alors dans une étape 843, on met en oeuvre une initialisation des registres associés au canal donné dans laquelle on attribue les valeurs suivantes : Traffic = vide ; Rate=0; Reinit = 0 ; Puis l'étape 842 est à nouveau mise en oeuvre. Si le registre Reinit ne présente pas la valeur 1 pour le canal donné, alors dans une étape 844, il est vérifié la valeur du registre SD_HD afin de savoir si le 15 contenu donné cO est de type SD-DVCR ou de type HD-DVCR. Si la valeur binaire du registre est 01111, ce qui signifie que le contenu cO est de type SD-DVCR, alors, une étape 847 est mise en oeuvre. Dans l'étape 847, on vérifie si la valeur du registre Traffic 501 associé au canal donné est SD-DVCR pour savoir si le contenu cO était déjà un contenu de 20 type SD-DVCR. Si cO était déjà un contenu de type SD-DVCR, ce qui signifie que le microprocesseur 309 était déjà au courant de ce fait, alors aucune action ne doit être mise en oeuvre et l'étape 801 est à nouveau mise en oeuvre. Si la valeur du registre Traffic 501 associé au canal donné n'est pas SDDVCR, ce qui signifie que les caractéristiques du contenu cO viennent de changer 25 sur le canal donné (par exemple, lors d'un changement de sélection de contenu émis par un disque dur audiovidéo de type IEEE 1394) et qu'il est nécessaire de prévenir le microprocesseur 309, alors, une étape 846 est mise en oeuvre. Dans l'étape 846, on attribue la valeur SD-DVCR au registre Traffic 501 associé au canal donné, on attribue la valeur 3OMbit/s au registre Param 502 30 associé au canal donné et l'on génère une interruption au niveau du microprocesseur 309. Dans l'étape 844, si la valeur binaire du registre n'est pas 01111, ce qui signifie que le contenu cO est de type HD-DVCR, alors, une étape 848 est mise en oeuvre.
Dans l'étape 848, on vérifie si la valeur du registre Traffic 501 associé au canal donné est HD-DVCR pour savoir si le contenu cO était déjà un contenu de type HD-DVCR. Si cO était déjà un contenu de type HD-DVCR, ce qui signifie que le microprocesseur 309 était déjà au courant de ce fait, alors aucune action ne doit être mise en oeuvre et l'étape 801 est à nouveau mise en oeuvre.
Si la valeur du registre Traffic 501 associé au canal donné n'est pas HDDVCR, ce qui signifie que les caractéristiques du contenu cO viennent de changer sur le canal donné el: qu'il est nécessaire de prévenir le microprocesseur 309, alors, une étape 849 est mise en oeuvre. Dans l'étape 849, on attribue la valeur HD-DVCR au registre Traffic 501 associé au canal donné, on attribue la valeur 6OMbit/s au registre Param 502 associé au canal donné et l'on génère une interruption au niveau du microprocesseur 309.

Claims (22)

REVENDICATIONS
1. Procédé d'allocation de ressources de transmission, dans un réseau de communication (1000), d'un flux de données, depuis un dispositif intermédiaire (1011) vers un dispositif destinataire (102), ledit flux de données comprenant une pluralité de paquets applicatifs de données et étant transmis d'un dispositif source (1031) au dispositif intermédiaire (1011) sous la forme de paquets de transport de données selon un protocole de communication, caractérisé en ce que le dispositif intermédiaire (1011) effectue les étapes suivantes, - réception de paquets de transport de données selon le protocole de communication ; - obtention d'informations d'horodatage applicatif comprises dans les données du flux de données contenues dans les paquets de transport de données reçus ; - détermination d'un débit, dit débit applicatif, à partir desdites informations d'horodatage applicatif obtenues et d'une information de quantité de données du flux de données reçue par le dispositif intermédiaire (1011) ; - détermination d'une valeur de bande passante à allouer, en fonction dudit débit applicatif, pour transmettre ledit flux de données depuis le dispositif intermédiaire (1011) vers le dispositif destinataire (102) ; -allocation de ladite valeur de bande passante à allouer pour la transmission du flux de données depuis le dispositif intermédiaire vers le dispositif destinataire (102).
2. Procédé d'allocation de ressources de transmission selon la revendication 1, caractérisé en ce que l'étape de détermination d'une valeur de bande passante à allouer comprend une étape de détermination si le flux de données est à débit constant ou à débit variable.
3. Procédé d'allocation de ressources de transmission selon l'une quelconque des revendications 1 et 2, chacun desdits paquets applicatifs de données du flux 30 comprenant une entête comprenant une information d'horodatage applicatif,caractérisé en ce que ladite étape de détermination du débit applicatif comprend une étape de détermination d'au moins une valeur de débit applicatif instantané du flux de données à partir de l'écart temporel entre l'information d'horodatage applicatif d'un paquet applicatif de données précédent un paquet applicatif de données courant et l'information d'horodatage applicatif du paquet applicatif de données courant dans le flux de données.
4. Procédé d'allocation de ressources de transmission selon la revendication 3, caractérisé en ce que ladite étape de détermination du débit applicatif comprend également une étape de comparaison d'au moins deux valeurs de débit applicatif instantané du flux de données.
5. Procédé d'allocation de ressources de transmission selon l'une quelconque des revendications 3 et 4, caractérisé en ce que si le flux est à débit constant, alors la valeur de bande passante à allouer est fonction de ladite ou de l'une desdites valeur(s) de débit applicatif instantané du flux.
6. Procédé d'allocation de ressources de transmission selon l'une quelconque des revendications 3 à 5, caractérisé en ce que, si le flux est à débit variable, il comprend une étape de détermination du paquet applicatif de données de plus grande dimension du flux de données, et en ce que la valeur de bande passante à allouer est égale à une valeur déterminée, ladite valeur déterminée permettant de transmettre un flux de données dont chaque paquet applicatif de données a la dimension du paquet applicatif de plus grande dimension du flux de données.
7. Procédé d'allocation de ressources de transmission selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend en outre une étape de vérification de la continuité du flux de données.
8. Procédé d'allocation de ressources de transmission selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit procédé est mis en oeuvre périodiquement.
9. Procédé d'allocation de ressources de transmission selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend au préalable les étapessuivantes: - réception d'une requête d'allocation de ressources de transmission pour le flux de données, ladite requête comprenant une information de quantité de ressources nécessaires maximale ; - tentative d'allocation d'une valeur de bande passante pour la transmission du flux de données depuis le dispositif intermédiaire (1011) vers le dispositif destinataire (102), ladite valeur de bande passante étant fonction de l'information de quantité de ressources nécessaires maximale ; - dans le cas où la tentative d'allocation échoue, établissement d'une connexion de flux selon le protocole de communication pour la transmission du flux de données depuis le dispositif source (1031) vers le dispositif intermédiaire, le dispositif intermédiaire (1011) effaçant les paquets de transport de données reçus une fois les informations d'horodatage applicatif obtenues.
10. Procédé d'allocation de ressources de transmission selon l'une quelconque des revendications 1 à 9, caractérisé en ce que, préalablement à l'étape d'obtention d'information d'horodatage applicatif, il comprend une étape de détermination d'un format du flux de données.
11. Produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de transmission selon l'une au moins des revendications 1 à 10.
12. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de transmission selon l'une au moins des revendications 1 à 10.
13. Dispositif intermédiaire comprenant des moyens d'allocation de ressources de transmission d'un flux de données comprenant une pluralité de paquets applicatifs de données, dans un réseau de communication (1000), depuis ledispositif intermédiaire vers un dispositif destinataire (102), le dispositif intermédiaire (1011) comprenant des moyens de réception du flux sous la forme de paquets de transport de données selon un protocole de communication, ledit flux provenant d'un dispositif source (1031), caractérisé en ce que les moyens d'allocation de ressources de transmission comprennent, - des moyens de réception de paquets de transport de données selon le protocole de communication ; - des moyens d'obtention d'informations d'horodatage applicatif comprises dans les données du flux de données contenues dans les paquets de transport de données reçus ; - des moyens de détermination d'un débit, dit débit applicatif, à partir desdites informations d'horodatage applicatif obtenues et d'une information de quantité de données du flux de données reçue par le dispositif intermédiaire ; - des moyens de détermination d'une valeur de bande passante à allouer, en fonction dudit débit applicatif, pour transmettre ledit flux de données depuis le dispositif intermédiaire vers le dispositif destinataire ; - des moyens d'allocation de ladite valeur de bande passante à allouer pour la transmission du flux de données depuis le dispositif intermédiaire (1011) vers le dispositif destinataire (102).
14. Dispositif intermédiaire selon la revendication 13, caractérisé en ce que les moyens de détermination d'une valeur de bande passante à allouer comprennent des moyens de détermination si le flux de données est à débit constant ou à débit variable.
15. Dispositif intermédiaire selon l'une quelconque des revendications 13 et 14, chacun desdits paquets applicatifs de données du flux comprenant une entête comprenant une information d'horodatage applicatif, caractérisé en ce que les moyens de détermination du débit applicatif comprennent des moyens de détermination d'au moins une valeur de débit applicatif instantané du flux dedonnées à partir de l'écart temporel entre l'information d'horodatage applicatif d'un paquet applicatif de données précédent un paquet applicatif de données courant et l'information d'horodatage applicatif du paquet applicatif de données courant dans le flux de données.
16. Dispositif intermédiaire selon la revendication 15, caractérisé en ce que les moyens de détermination du débit applicatif comprennent également des moyens de comparaison d'au moins deux valeurs de débit applicatif instantané du flux de données.
17. Dispositif intermédiaire selon l'une quelconque des revendications 15 et 16, caractérisé en ce que les moyens d'allocation de ressources de transmission comprennent des moyens de détection si le flux est à débit constant, et en ce que les moyens de détermination d'une valeur de la bande passante à allouer tiennent compte de ladite ou de l'une desdites valeur(s) de débit applicatif instantané du flux si le flux est à débit constant.
18. Dispositif intermédiaire selon l'une quelconque des revendications 15 à 17, caractérisé en ce que les moyens d'allocation de ressources de transmission comprennent des moyens de détection si le flux est à débit variable et des moyens de détermination du paquet applicatif de données de plus grande dimension du flux de données, lesdits moyens étant activés si le flux est à débit variable, et en ce que les moyens de détermination d'une valeur de la bande passante à allouer tiennent compte d'une valeur déterminée, ladite valeur déterminée permettant de transmettre un flux de données dont chaque paquet applicatif de données a la dimension du paquet applicatif de plus grande dimension du flux de données.
19. Dispositif intermédiaire selon l'une quelconque des revendications 13 à 18, caractérisé en ce que les moyens d'allocation de ressources de transmission comprennent en outre des moyens de vérification de la continuité du flux de données.
20. Dispositif intermédiaire selon l'une quelconque des revendications 13 à 19, caractérisé en ce que les moyens d'allocation de ressources de transmissionsont activés périodiquement.
21. Dispositif intermédiaire selon l'une quelconque des revendications 13 à 20, caractérisé en ce que les moyens d'allocation de ressources de transmission comprennent : - des moyens de réception d'une requête d'allocation de ressources de transmission pour le flux de données, ladite requête comprenant une information de quantité de ressources nécessaires maximale ; - des moyens de mise en oeuvre d'une tentative d'allocation d'une valeur de bande passante pour la transmission du flux de données depuis le dispositif intermédiaire vers le dispositif destinataire (102), ladite valeur de bande passante étant fonction de l'information de quantité de ressources nécessaires maximale ; - des moyens d'établissement d'une connexion de flux selon le protocole de communication pour la transmission du flux de données depuis le dispositif source vers le dispositif intermédiaire (1011), le dispositif intermédiaire comprenant des moyens d'effacement les paquets de transport de données reçus, lesdits moyens d'effacement étant activés par l'obtention des informations d'horodatage applicatif, lesdits moyens d'établissement d'une connexion de flux selon le protocole de communication étant activés dans le cas où la tentative d'allocation échoue.
22. Dispositif intermédiaire selon l'une quelconque des revendications 13 à 21, caractérisé en ce que les moyens d'allocation de ressources de transmission comprennent des moyens de détermination d'un format du flux de données.25
FR0701361A 2007-02-26 2007-02-26 Procede d'allocation de ressources de transmission d'un contenu de donnees, produit programme d'ordinateur, moyen de stockage et dispositif correspondants Expired - Fee Related FR2913156B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0701361A FR2913156B1 (fr) 2007-02-26 2007-02-26 Procede d'allocation de ressources de transmission d'un contenu de donnees, produit programme d'ordinateur, moyen de stockage et dispositif correspondants
US12/036,645 US7751439B2 (en) 2007-02-26 2008-02-25 Method of allocation of resources for transmission of a data content, corresponding computer program product, storage means and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0701361A FR2913156B1 (fr) 2007-02-26 2007-02-26 Procede d'allocation de ressources de transmission d'un contenu de donnees, produit programme d'ordinateur, moyen de stockage et dispositif correspondants

Publications (2)

Publication Number Publication Date
FR2913156A1 true FR2913156A1 (fr) 2008-08-29
FR2913156B1 FR2913156B1 (fr) 2009-05-29

Family

ID=38566960

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0701361A Expired - Fee Related FR2913156B1 (fr) 2007-02-26 2007-02-26 Procede d'allocation de ressources de transmission d'un contenu de donnees, produit programme d'ordinateur, moyen de stockage et dispositif correspondants

Country Status (2)

Country Link
US (1) US7751439B2 (fr)
FR (1) FR2913156B1 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008105494A1 (fr) * 2007-02-28 2008-09-04 Nec Corporation Dispositif et procédé de transfert par accès direct en mémoire (dma)
WO2009019767A1 (fr) * 2007-08-08 2009-02-12 Fujitsu Limited Système de communication, contrôleur d'appel, dispositif de station de base et programme informatique
US8488661B2 (en) * 2008-06-13 2013-07-16 Verizon Patent And Licensing Inc. Systems and methods for data streaming
DE102008049600A1 (de) * 2008-09-30 2010-04-01 Bayerische Motoren Werke Aktiengesellschaft Ethernet-MOST-Gateway-Einrichtung und Verfahren zum Koppeln eines Ethernet-Netzknotens mit einem MOST-Empfänger
US8392631B1 (en) 2008-10-02 2013-03-05 Apple Inc. Methods and apparatus for transmitting data streams via a heterogeneous network
JP5237130B2 (ja) * 2009-01-15 2013-07-17 キヤノン株式会社 通信制御システム、通信制御方法、管理装置およびプログラム
CA2839436C (fr) * 2011-06-15 2015-08-04 Allot Communications Ltd Procede et appareil d'estimation de bande passante de session et de commande de debit
EP2817930B1 (fr) * 2012-02-20 2017-12-06 Telefonaktiebolaget LM Ericsson (publ) Estimation de capacité au moyen de trains de salves de fin
DE102012223308A1 (de) * 2012-12-14 2014-06-18 Continental Automotive Gmbh Synchronisieren von Datenpaketen in einem Datenkommunikationssystem eines Fahrzeugs
US10313243B2 (en) 2015-02-24 2019-06-04 Commvault Systems, Inc. Intelligent local management of data stream throttling in secondary-copy operations
CN108989239B (zh) * 2017-06-02 2023-10-13 中兴通讯股份有限公司 过载保护方法及装置、控制器及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6052384A (en) * 1997-03-21 2000-04-18 Scientific-Atlanta, Inc. Using a receiver model to multiplex variable-rate bit streams having timing constraints
US20010038640A1 (en) * 2000-05-19 2001-11-08 Mckinnon Martin W. Computerized method for allocating access across a shared communication medium
EP1154354A2 (fr) * 2000-05-13 2001-11-14 Samsung Electronics Co., Ltd. Dispositif et méthode de détection de la vitesse de transmission de données
US20020176367A1 (en) * 2001-03-30 2002-11-28 Gross Gerhard W. System and method for determining segment and link bandwidth capacities
US20050163156A1 (en) * 1995-04-28 2005-07-28 Hidetoshi Takeda Data transmitting apparatus, data receiving apparatus and data transmission control apparatus

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7075937B1 (en) * 1998-05-19 2006-07-11 Canon Kabushiki Kaisha Method and device for sending data, method and device for receiving data
EP1051000B1 (fr) 1999-03-25 2014-05-07 Canon Kabushiki Kaisha Procédé et dispositif pour l'affectation d'au moins un identificateur d'achéminement à au moins un pont dans un réseau
US6940831B1 (en) * 1999-11-29 2005-09-06 Matsushita Electric Industrial Co., Ltd Wireless communications system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050163156A1 (en) * 1995-04-28 2005-07-28 Hidetoshi Takeda Data transmitting apparatus, data receiving apparatus and data transmission control apparatus
US6052384A (en) * 1997-03-21 2000-04-18 Scientific-Atlanta, Inc. Using a receiver model to multiplex variable-rate bit streams having timing constraints
EP1154354A2 (fr) * 2000-05-13 2001-11-14 Samsung Electronics Co., Ltd. Dispositif et méthode de détection de la vitesse de transmission de données
US20010038640A1 (en) * 2000-05-19 2001-11-08 Mckinnon Martin W. Computerized method for allocating access across a shared communication medium
US20020176367A1 (en) * 2001-03-30 2002-11-28 Gross Gerhard W. System and method for determining segment and link bandwidth capacities

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
A/V TRANSPORT WORKING GROUP B FAIRMAN SONY-PTCA-NSA: "Internet Engineering Task Force A/V Transport Working Group<BR>Internet Draft B. Fairman<BR>Document: draft-fairman-rtp-61883-00.txt SONY-PTCA-NSA<BR>Expires: November 2003 June 2003<BR>RTP Payload Format for 1394/61883 Isochronous Streams", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, June 2003 (2003-06-01), XP015000862, ISSN: 0000-0004 *

Also Published As

Publication number Publication date
US7751439B2 (en) 2010-07-06
FR2913156B1 (fr) 2009-05-29
US20080205442A1 (en) 2008-08-28

Similar Documents

Publication Publication Date Title
FR2913156A1 (fr) Procede d&#39;allocation de ressources de transmission d&#39;un contenu de donnees, produit programme d&#39;ordinateur, moyen de stockage et dispositif correspondants
US6885643B1 (en) Method and device for facilitating efficient data transfer via a wireless communication network
US9986062B2 (en) Quality of service for distribution of content to network devices
EP1865673A1 (fr) Qualité de service dans des réseaux domestiques hétérogènes
US20130297743A1 (en) Managed Adaptive Streaming
FR2878106A1 (fr) Procede et dispositif d&#39;ordonnancement de paquets pour leur routage dans un reseau avec determination implicite des paquets a traiter en priorite
JP4601681B2 (ja) ネットワークにおけるサービス品質の提供方法、中間ノード装置、およびシステム
EP2862324B1 (fr) Procede et dispositif d&#39;estimation rapide et peu intrusive de la bande passante disponible entre deux n uds ip
FR2909241A1 (fr) Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d&#39;interconnexion de reseaux.
KR102107514B1 (ko) 방송 시스템에서 동적 큐 관리 방법 및 장치
FR2804812A1 (fr) Procede et dispositif de communication entre un premier et un deuxieme reseau
CN110199505B (zh) 确定通信链路的带宽
US20110083156A1 (en) Network streaming of a video stream over multiple communication channels
FR2925808A1 (fr) Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire
CN117041134A (zh) 一种数据路径规划方法、装置及设备
US20060083232A1 (en) Method and apparatus for transmitting isochronous stream
FR2875985A1 (fr) Procede et dispositif de transmission de donnees
FR2831745A1 (fr) Procede d&#39;etablissement d&#39;une connexion de flux de donnees isochrone impliquant la traversee d&#39;un reseau commute, noeuds d&#39;entree et de sortie correspondants
FR2848056A1 (fr) Procedes d&#39;insertion et de traitement d&#39;informations pour la synchronisation d&#39;un noeud destinataire a un flux de donnees traversant un reseau de base d&#39;un reseau heterogene, et noeuds correspondants
FR2908577A1 (fr) Procede de transmission conformement a un protocole de transmission par rafales d&#39;un contenu de donnees,produit programme d&#39;ordinateur,moyen de stockage et dispositif correspondants.
FR2816146A1 (fr) Procede et dispositif de gestion d&#39;un reseau de communication
WO2015092273A1 (fr) Procédé de réservation d&#39;une bande passante dans un réseau pour l&#39;exécution d&#39;un service sur un terminal utilisateur
FR2916930A1 (fr) Procede de reservation de ressources lors de la transmission d&#39;un contenu dans un reseau de communication, produit programme d&#39;ordinateur, moyen de stockage et dispositifs correspondants
FR3011704A1 (fr) Procede de mise en œuvre d&#39;une session de communication entre une pluralite de terminaux
CN115767143A (zh) 播放卡顿的判断方法、装置、电子设备和可读存储介质

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20141031