FR3082386A1 - Adaptation de debit d'une session de communication en voix sur ip - Google Patents
Adaptation de debit d'une session de communication en voix sur ip Download PDFInfo
- Publication number
- FR3082386A1 FR3082386A1 FR1855048A FR1855048A FR3082386A1 FR 3082386 A1 FR3082386 A1 FR 3082386A1 FR 1855048 A FR1855048 A FR 1855048A FR 1855048 A FR1855048 A FR 1855048A FR 3082386 A1 FR3082386 A1 FR 3082386A1
- Authority
- FR
- France
- Prior art keywords
- cmr
- request
- rate
- adaptation
- bit rate
- 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.)
- Withdrawn
Links
- 230000006854 communication Effects 0.000 title claims abstract description 41
- 238000004891 communication Methods 0.000 title claims abstract description 41
- 238000012360 testing method Methods 0.000 claims abstract description 93
- 230000006978 adaptation Effects 0.000 claims abstract description 84
- 230000005540 biological transmission Effects 0.000 claims abstract description 79
- 238000000034 method Methods 0.000 claims abstract description 55
- 230000008859 change Effects 0.000 claims description 18
- 238000004590 computer program Methods 0.000 claims description 7
- 238000003860 storage Methods 0.000 claims description 5
- 238000010276 construction Methods 0.000 claims description 4
- 230000006870 function Effects 0.000 description 16
- 230000004913 activation Effects 0.000 description 9
- 230000011664 signaling Effects 0.000 description 8
- 230000003044 adaptive effect Effects 0.000 description 6
- 238000000605 extraction Methods 0.000 description 6
- 230000002457 bidirectional effect Effects 0.000 description 5
- 230000003213 activating effect Effects 0.000 description 4
- 230000015556 catabolic process Effects 0.000 description 4
- 238000006731 degradation reaction Methods 0.000 description 4
- 238000012417 linear regression Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000003247 decreasing effect Effects 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- 230000009897 systematic effect Effects 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000000750 progressive effect Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 239000001884 Cassia gum Substances 0.000 description 1
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 1
- 239000000654 additive Substances 0.000 description 1
- 230000000996 additive effect Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000003416 augmentation Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 238000012508 change request Methods 0.000 description 1
- 229910052804 chromium Inorganic materials 0.000 description 1
- 239000011651 chromium Substances 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000007727 signaling mechanism Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- 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/38—Flow control; Congestion control by adapting coding or compression rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
La présente invention se rapporte à un procédé d'adaptation d'un débit de codage de signaux temps réels d'une session de communication temps réel entre des dispositifs émetteur et des dispositifs récepteur de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets. Le procédé est tel qu'il comporte une étape de test d'augmentation du débit de codage au dispositif émetteur par la transmission (428) d'au moins un paquet redondant selon des paramètres de transmission choisis (423). L'invention se rapporte également à un procédé de détermination d'une requête d'adaptation de débit de codage de signaux temps réels pour la mise en œuvre d'un test d'augmentation du débit de codage au dispositif émetteur par la transmission d'au moins un paquet redondant selon des paramètres de transmission choisis. L'invention se rapporte également à un dispositif émetteur, un dispositif récepteur mettant en œuvre les procédés décrits ainsi qu'un terminal comportant ces dispositifs.
Description
Adaptation de débit d’une session de communication en voix sur I P
La présente invention se rapporte au domaine des télécommunications et plus particulièrement au domaine des réseaux de communication par paquets. Dans ce type de réseaux, il est possible d'acheminer des flux de données associées à des services temps réel.
Le protocole Internet, appelé IP pour Internet Protocol, développé par l'IETF, pour Internet Engineering Task Force, est mis en oeuvre sur les réseaux de communication par paquets aussi bien pour supporter des services non temps-réel tels que des services de transfert de données, de consultation de pages web, de messagerie électronique, que des services temps réels ou conversationnels, tels que la téléphonie sur IP, la vidéo téléphonie sur IP ou encore la diffusion vidéo sur I P.
L’invention se rapporte plus particulièrement à une adaptation de débit de codage/décodage de signaux temps réels comme les signaux de voix ou de vidéo lors d’une session de communication temps-réel entre deux terminaux de communication.
Cette adaptation de débit et les mécanismes qui s’en rapportent sont adaptés pour la transmission de signaux numériques tels que des signaux audiofréquences (parole, musique ou autres), cependant ils s’appliquent à d’autres signaux temps réels comme la vidéo.
Un exemple de système de communication voix sur IP existant est décrit en référence à la figure 1. Cette figure décrit un système de communication bidirectionnelle de voix sur IP (Vol P) avec deux terminaux de téléphonie (100 et 150) reliés par un réseau par paquets de type IP (125). Le plan de signalisation n’est pas représenté sur cette figure mais les solutions possibles pour établir et gérer des appels peuvent reposer sur différents protocoles connus comme par exemple:
• SIP/SDP(pour « Session Initiation Protocol/Session Description Protocol » en anglais) selon les spécifications IETF RFC 3261 et RFC 4566 - comme dans les services multimédia sur IMS (pour « IP Multimedia SubSystem » en anglais). Pour faciliter les échanges de signalisation sur les capacités média et les offres/réponses associées, il est également possible d'utiliser « SDPcapneg » selon la spécification IETF RFC 5939.
• JSEP (pour « JavaScript Session Establishment Protocol » en anglais) qui utilise la syntaxe de SDP pour définir des descriptions de session WebRTC (avec un échange par WebSocket ou un autre moyen).
La figure 1 est une vue simplifiée du plan média et de la chaîne audio utilisée quand l'appel est établi entre 2 terminaux (100 et 150) reliés par un réseau IP (125). On se limite ici au cas d'un signal audio mono, le signal acoustique ambiant est par exemple capté par un microphone (101 et 151) de chaque côté de la communication. On remarquera que le cas d'un signal d'entrée / sortie mono peut facilement se généraliser à un cas multicanal où plusieurs micros et/ou haut-parleurs sont utilisés. De même, les microphones et haut-parleurs pourront être remplacés par des caméras et écrans dans le cas de signaux vidéo.
Le signal distant est restitué sur un haut-parleur (102 et 152). Les signaux audio captés et restitués subissent en général différents pré-/post-traitements en émission et en réception (103 et 153) comme par exemple:
• En émission : conversion analogique/numérique, contrôle de gain, réduction de bruit, annulation d'écho, etc.
• En réception : conversion numérique/analogique, contrôle de gain, etc.
Le signal audio prétraité en émission est codé par trames successives - avec typiquement une longueur de trame de 20 ms - cette longueur est en général comprise entre 10 à 60 ms pour les applications conversationnelles. Les trames codées sont mises sous forme de paquets IP (104 et 154). Les paquets sont typiquement transportés par le protocole RTP (pour Real Time Protocol en anglais), décrit dans la spécification IETF RFC 3550, ce protocole se situe au-dessus des protocoles de transport IP/UDP (pour User Datagram Protocol en anglais). On notera que le protocole UDP peut être remplacé par un autre protocole de transport, par exemple par TCP (pour « Transmission Control Protocol » en anglais) pour notamment faciliter la traversée de réseaux avec traduction d’adresse réseau NAT (pour « Network Address Translation « en anglais), proxys ou pare-feux.
En réception (105 et 155), les paquets sont reçus dans un buffer de gigue visant à compenser les variations des temps de réception, et le signal est décodé (en compensant les pertes éventuelles de trames), enfin le signal reconstruit est post-traité (103 et 153) et restitué.
La communication est ici supposée bidirectionnelle et le système de communication forme ainsi un système bouclé avec rétroaction (feedback). Le « feedback » peut être transporté de deux façons:
• Hors bande (c’est-à-dire contenu dans des paquets qui constituent un flux supplémentaire par rapport au flux média RTP). Typiquement, le protocole RTCP (pour Real-Time Control Protocol) est utilisé comme canal de « feedback ». RTCP permet des transmissions de paquets de contrôle dans des paquets séparés du flux RTP. On rappelle que les paquets RTCP peuvent avoir une taille conséquente et donc résulter en un débit supplémentaire non négligeable; de plus, la perte possible de paquets peut être problématique, car si RTCP est utilisé à des fins d'adaptation, le feedback transporté peut être perdu. L’envoi des paquets par le protocole RTCP peut être discontinu et non répétitif, ce qui peut rendre l’adaptation moins réactive et dépendante des conditions réseaux (retard de transmission, pertes de paquets, etc.). En général, l’application doit supporter et utiliser le profil RTP AVPF (pour « Audio Video Profile with Feedback » en anglais) pour que RTCP soit réellement utilisable pour l’adaptation média. De plus, les applications de type voix sur IMS n’autorisent pour l’instant que le profil AVP (pour « Audio Video Profile » en anglais) qui restreint l’utilisation de RTCP; l'adaptation média dans les terminaux - si elle est utilisée - peut s'appuyer sur le monitoring des conditions réseaux, dont les informations contenues dans les rapports RTCP RR (Receiver Report) sur la perte de paquets ou la gigue qui sont envoyés en moyenne tous les 5 secondes.
• Dans la bande (c’est à dire dans le flux média RTP). Ce type de feedback peut être considéré comme plus robuste que RTCP car il est possible de répéter une même requête dans plusieurs paquets successifs. A noter que dans certaines situations (appel en attente, écoute de messagerie, ...), il est possible que les paquets RTP soient envoyés dans un seul sens, cependant on suppose ici un envoi de paquets RTP bidirectionnel pour que la rétroaction fonctionne. Un exemple de signalisation dans la bande est l’utilisation d’un champ CMR (pour « Codec Mode Request » en anglais) utilisé pour transmettre une requête d’adaptation de codage.
En général, plusieurs types de dégradation peuvent potentiellement affecter la qualité de la voix sur I P:
• bande passante variable / congestion du réseau • perte, dé-séquencement, répétition de paquets • retard des paquets (de transmission, de mise en file d’attente, de traitement...), variation du retard (gigue) • dérive d'horloge entre les terminaux
Ils existent différentes solutions pour pallier ces dégradations différentes, dont des solutions d’adaptation dans les terminaux. On distingue deux types d'adaptation dans les terminaux Vol P: l'adaptation basée émetteur (sender based en anglais) et l'adaptation basée récepteur (receiver based en anglais). Il existe aussi des variantes où la décision d’adaptation est assistée ou prise par le réseau, mais ce cas n’est pas traité ici car il dépasse le cadre de l’invention.
Dans le cas d’une adaptation basée émetteur, pour que l'émetteur puisse prendre une décision d’adaptation optimale de bout en bout, celui-ci doit recevoir un retour ou « feedback » du récepteur distant indiquant la qualité perçue en bout de chaîne, avec par exemple des indicateurs comme le taux de perte observé ou la bande passante disponible estimée par le récepteur distant.
Dans le cas d’une adaptation basée récepteur, la décision d’adaptation est prise par le récepteur distant (155) et transmise par «feedback» vers l'émetteur local (104) (par exemple le choix du mode ou débit à utiliser) - ce feedback est transmis en passant par l'émetteur distant (154) puis le récepteur local (105).
La figure 1 indique ce feedback par des flèches en pointillées pour le sens allant du récepteur 155 à l'émetteur 104. Bien entendu, ce feedback peut se faire dans l'autre sens de la communication, avec un feedback du récepteur 105 vers l'émetteur 154 en passant par les blocs 104 et 155; ce sens inverse n'est pas représenté sur la figurel pour ne pas alourdir cette figure.
On s’intéresse ici plus particulièrement à une adaptation en débit pour remédier par exemple aux changements de bande passante et à la congestion de réseau.
Dans un exemple de solutions d’adaptation, pour contrôler une variation de bande passante ou une congestion du réseau, on peut mettre en œuvre les techniques décrites cidessous.
Lorsqu'un codec fonctionne à un débit fixe, une solution d'adaptation pour modifier le débit effectif sur le réseau consiste à varier le nombre de trames consécutives de signal dans un paquet (frame bundling en anglais) et ainsi varier le débit paquet (packet rate en anglais) et le débit relatif des entêtes protocolaires IP/UDP/RTP (et des couches inférieures).
Lorsqu'un codec est multi-débit, on peut également changer le débit du codec. Ce changement de débit peut se faire en fonction de la bande passante disponible estimée par le récepteur distant et reçue par « feedback » (décision basée émetteur) ou en fonction d'une requête de changement de débit reçue par « feedback » (décision basée récepteur).
La figure 2 décrit un exemple avancé de contrôle de débit d'un codec multi-débit appelé iSAC (pour « internet Speech Audio Codec » en anglais). Le codec iSAC est un codec propriétaire développé par la société GIPS (Global IP Solutions). Depuis 2011 le code source d’iSACest disponible dans le projet open source WebRTCde Google Chromium™.
Le codec fonctionne selon deux modes différents :
• Le mode Wide Band (WB) code une bande audio de 0 à 8kHz avec une longueur de trames de 30 ou 60 ms.
• Le mode Super Wide Band (SWB) code une bande audio de 0 à 12kHz ou de 0 à 16kHz avec une longueur de trame de 30 ms.
Le débit du codec iSAC est variable ; le débit moyen peut aller de 10 à 32kbit/s en mode Wide Band et de 10 à 56 kbit/s en SuperWideBand. Le codec iSAC peut fonctionner selon deux modes de transmission sur le canal :
« Channel Adaptive » « Channel Independent »
Le mode « Channel Adaptive » prend en compte les estimations de bande passante faites en réception par le décodeur iSAC et permet d’adapter le débit de codage, tandis que le mode « Channel Independent » se contente de suivre un débit cible (« target bitrate »).
Comparée à la figure 1, on a volontairement omis à la figure 2 les blocs de traitements audio (103 et 153) et le réseau (125) afin d'alléger la figure. On retrouve les éléments de captation et restitution audio (blocs 101, 102 et 151, 152).
Le débit du codage (blocs 201, 251) est adapté dans le codec iSAC (blocs 202, 252) à partir de l'indication de débit dans le sens descendant, estimé au récepteur (blocs 205, 255).
En effet le récepteur (blocs 205, 255) estime la bande passante disponible dans le sens descendant (« downlink ») à chaque réception de paquets à partir des informations suivantes :
- taille du paquet (charge utile) ;
- temps d'arrivée ;
- numéro de séquence ;
- temps d’émission RTP.
Le débit estimé est ensuite mis à disposition de l'émetteur via une structure partagée (blocs 207 et 257). L’émetteur (blocs 204, 254) envoie un champ appelé BEI (pour « Bandwidth Estimate Index » en anglais) dont les valeurs vont de 0 à 23 pour indiquer la bande passante disponible estimée par le récepteur; le champ BEI indique une valeur de bande passante disponible (“bottleneck”) estimée parmi des valeurs définies entre les débits cibles minimum et maximum du codec iSAC (de 0 à 11 en mode WB et de 0 à 23 en mode SWB). Le champ BEI est décodé à l'autre bout de la chaîne (blocs 203, 253).
On notera également que l'estimation de bande passante dans le codec iSAC s'accompagne également d'une estimation de la gigue qui n'est pas décrite ici mais qui sert à l'estimation de la taille du bourrage décrite plus loin; la gigue estimée est représentée sur 1 bit pour indiquer une valeur faible ou élevée et elle transmise dans le champ BEI en mode WB (0 si le BEI est entre 0 et 11 et 1 s'il est entre 12 et 23) ou codée dans le train binaire (charge utile de la trame courante) en mode SWB.
Pour le sens de transmission de 200 à 250, l’adaptation de débit est mise en œuvre côté émetteur. Le codage effectué en 201 a un débit mis à jour par le bloc 202 à partir d’un champ BEI décodé en 203. Ce champ décodé a été codé en 254 à partir d’une estimation de bande passante disponible effectuée par le bloc 255 du récepteur 155.
La transmission dans l’autre sens s’effectue de la même façon avec les blocs correspondants.
Une méthode de bourrage (padding en anglais) de bits aléatoires, à la fin du paquet, est effectuée, pour tester s’il est possible d'augmenter le débit de codage (bandwidth probing en anglais). Cette méthode simple permet en effet d'augmenter artificiellement la taille de certains paquets à l'émission (210 ou 260 respectivement) afin de pouvoir estimer en bout de chaîne en réception (205 ou 255 respectivement) si la bande passante disponible sur le canal de transmission permet d’utiliser un débit supérieur au débit actuel. On notera cependant que cette méthode utilise des bits aléatoires sans autre utilité que le test de bande passante.
La taille et la décision d’envoi du bourrage de bits sont déterminées à l'aide d'un modèle de débit (rate model en anglais). Au début de l'appel (typiquement les 10 premières secondes), le débit est maintenu à un débit minimal. Ensuite trois paquets consécutifs comportant des bits de bourrage sont envoyés pour tester le canal, avec un intervalle maximal de typiquement 500 ms. La taille de ces paquets consécutifs est fixée pour que le débit instantané associé au paquet i soit donné par (1 + y,) 7?,, où fi, est la bande passante disponible estimée au paquet i et le terme adaptatif y, (de valeur supérieure >0) est calculé de façon heuristique. Le principe est d’envoyer des pics de débit réguliers (« bursts ») sur le canal pour tester une augmentation de débit par rapport au débit actuel.
Le modèle de débit (« rate model ») mis en œuvre dans les blocs 210 et 260 repose sur un modèle de goulot d’étranglement (« bottleneck ») limitant la bande passante disponible dans le réseau. Ce modèle de débit s'appuie sur plusieurs états internes définis au récepteur dont une détection binaire de dépassement (overuse en anglais) de la bande passante par le dernier paquet reçu avec une mesure du temps écoulé depuis le dernier dépassement détecté de bande passante (en ms), ainsi que des informations sur la file d'attente modélisant le bottleneck (nombre de paquets qui restent à transmettre, augmentation du retard).
L'estimation de débit effectuée au récepteur est en général efficace pour diminuer le débit de codage, c'est-à-dire détecter que la bande passante disponible est plus faible que le débit actuel et que le débit doit être abaissé. Par contre la méthode consistant à effectuer un bourrage de bits aléatoires pour vérifier que le débit actuel peut être augmenté n'est pas optimale, en effet, elle introduit des bits aléatoires non utilisés et non contrôlés. D’autre part, le codec iSAC produit un débit moyen qui peut être ajusté assez finement entre un débit minimal et un débit maximal (ex: 10 à 32 kbit/s ou 10 à 56 kbit/s), alors qu'un codec multidébit fonctionnant selon un ensemble défini de débits discrets, comme un codec de type AMR, AMR-WB ou EVS, ne fonctionne pas sur une gamme continue de débits.
Par ailleurs, la méthode d'adaptation de débit du codec iSAC, utilisant une estimation de débit en réception et un test de canal par bourrage de bits, suppose l'utilisation d'un champ spécifique au codec iSAC (BEI). Ce champ spécifique n’existe pas pour d’autres types de codecs, notamment pour les codecs multi-débit de type AMR, AMR-WB et EVS. On notera que le champ CMR des codecs AMR, AMR-WB et EVS est différent du champ BEI du codec iSAC, car l’un (BEI) représente une information sur la bande passante disponible estimée au récepteur et suppose une adaptation « basée émetteur », l’autre (CMR) permet de coder une requête d'adaptation indiquant un débit maximal et suppose une adaptation « basée récepteur ».
Une autre méthode plus avancée - reprenant les mêmes principes - d'estimation de bande passante disponible et d'adaptation de débit de codage est décrite dans l'article Making Google Congestion Control robust over Wi-Fi networks using packet grouping de G. Carlucci, L. De Cicco, S. Holmer, S. Mascolo, publié dans ACM, I RTF & ISOC, Applied Networking Research Workshop, 2016. Cet article décrit le fonctionnement de l'algorithme GCC (pour Google Congestion Control en anglais) pour le contrôle de congestion vidéo; l’algorithme d’adaptation GCC est divisé en deux parties: une partie émetteur et une partie récepteur. L’algorithme GCC suppose l’utilisation du profil RTP AVPF pour envoyer des messages RTCP REMB (RTCP message for Receiver Estimated Maximum Bitrate) toutes les secondes ou dès que la bande passante estimée a baissé de 3%.
La partie émetteur est basée sur le taux de perte (« loss based »). Elle transmet dans les entêtes des paquets RTP des temps d'émission absolus appelés abs-send-time, qui servent à l'estimation de bande passante disponible dans la partie récepteur. Elle utilise les rapports RTCP REMB indiquant le débit estimé Ar et la perte de trame observée /) par le récepteur distant pour adapter le débit de codage: le débit de codage cible As est respectivement augmenté, maintenu ou diminué quand le taux de perte est négligeable, faible ou élevé :
((1-0.5/))4//-1)
AS(T) =
1.054/i- 1) si ft > 0,1 si fi < 0,02 autrement
Le débit de codage réel est obtenu comme min(4s,4r), c’est-à-dire le minimum entre ce débit de codage cible et la dernière valeur de bande passante disponible estimée par le récepteur distant (reçue par RTCP).
La partie récepteur est basée sur la variation du retard unidirectionnel (« delay based »). Elle utilise une machine à états finis avec 3 états (baisse, maintien, augmentation) et une estimation en réception de la bande passante disponible par filtrage de Kalman.
L’estimation de bande passante s’appuie sur une modélisation de la variation du retard unidirectionnel (« one-way delay ») défini comme dm(0 = (t/i) - tr(i - 1)) - (t/i) - ts(i - 1))
Où ts(i) et t/i) sont les temps d’émission (selon l'information abs-send-time envoyée dans l'entête RTP) et de réception du paquet i, sous la forme de deux composantes : dm(f) = m(i) + n(i)
Où m(i) est la variation du retard de file d’attente - estimée par filtrage de Kalman et n(i) est la gigue réseau - considérée comme un bruit.
Le dépassement de la bande passante disponible (overuse en anglais) est détecté en appliquant un seuil adaptatif sur la variation estimée du délai de file d'attente m(i) pour piloter les transitions entre les 3 états. L’estimation de débit en réception est adaptée selon les états :
• Baisse : Ar(i) = aR(i) où a e [0,85,0,95] et R(i) est le débit mesuré sur les dernières 500 ms • Maintien : Ar(i) = Ar(i - 1) • Augmentation : Ar(i) = ηΑΓ(ί - 1) où η e [1,005,1,3]
Cette méthode d’adaptation utilise des heuristiques pour l’adaptation et elle suppose qu’il est possible d’adapter le débit de façon fine avec des facteurs multiplicatifs (1,05 et η) spécifiques pour l’augmentation de débit. Elle s’applique difficilement à des codecs voix comme EVS qui sont multi-débits avec un ensemble de débits discrets. Par exemple, le ratio entre débits successifs pour le codec va de 1,11 à 1,5 pour le codec EVS avec des débits fixes de 7,2 à 128 kbit/s. De plus, l’utilisation de paquets RTCP (de type REMB ou autre) n’est pas toujours possible dans les applications de Vol P restreintes à un profil RTP tel qu’AVP (pour Audio Video Profile, défini dans IETF RFC 3551) qui limite l’intérêt de RTCP à des fins d’adaptation.
Pour les applications de téléphonie actuelles de type VoLTE (pour « Voice over LTE (Long Term Evolution) » en anglais désignant une technique de transport de la voix sur les réseaux de téléphonie mobile 4G LTE spécifiée dans GSMA IR.92 et de type VoWifi (pour « Voice over Wi-Fi » en anglais) désignant une technique de transport de la voix sur le réseau Wi-Fi spécifiée dans GSMA IR.65, des mécanismes d'adaptation du codage sont décrits dans le chapitre 10 de la spécification 3GPP TS 26.114 (utilisation de a=bw-info, ECN, ANBR, définition de CMR et RTCP-APP, etc.) avec des recommandations générales mais aucune obligation d'adaptation dans le service. Un exemple d'algorithme (informatif) d’adaptation pour la Vol P est décrit dans l’annexe Cde la spécification TS26.114. En pratique seul le profil RTPAVPest autorisé et l'adaptation pour la voix sur IMS est pour l'instant rarement autorisée et configurée par les opérateurs de réseaux mobiles qui préfèrent dimensionner le service avec un débit fixe garanti (GBR pour « Guaranteed Bit Rate »).
De plus, la spécification TS 26.114 contient des recommandations (voir clause 7.5.2.1.6) sur le débit de codage initial (ICM pour initial codec mode en anglais) à utiliser au début d'un appel pour éviter la congestion du lien et qu'il est recommandé - si aucune information de contrôle de débit n'a été reçue pendant une certaine période - d'augmenter graduellement le mode (débit) de codage au plus à la valeur de l'ICM correspondant au débit de codage autorisé; si aucune mauvaise qualité n'est détectée ou en l'absence d'information de contrôle de débit, il est recommandé que l'émetteur augmente son débit par paliers progressifs avec un certain délai d'attente de l'ordre de 500-600 ms. Cette approche d'adaptation est très heuristique. L'augmentation de débit repose sur le passage au mode de codage immédiatement supérieur, avec un monitoring des indicateurs de qualité ou l'attente d'une réception d'une requête par le récepteur (typiquement CMR ou RTCP-APP) pour valider l'augmentation de débit. Cette méthode n’est pas optimale car elle repose sur des heuristiques d'augmentation par paliers progressifs et provoque des sauts brusques de changement de débit avec des « tests en aveugle » de l’augmentation de débit.
Il existe ainsi un besoin d'une méthode d'adaptation de débit pour le codage/décodage qui pallie aux inconvénients précités.
L'invention propose à cet effet, un procédé d’adaptation d’un débit de codage de signaux temps réels d’une session de communication temps réel entre des dispositifs émetteur et des dispositifs récepteur de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets. Le procédé est tel qu’il comporte une étape de test d’augmentation du débit de codage au dispositif émetteur par la transmission d’au moins un paquet redondant selon des paramètres de transmission choisis.
Le fait de tester l’augmentation de débit par des paquets redondants permet d’augmenter le débit sans sauts brusques puisqu’on peut définir les paramètres de transmission pour éviter de tester en aveugle le débit discret supérieur et risquer de dégradation la qualité sans pouvoir compenser les conséquences d'une augmentation directe du débit. Cette étape de test permet de vérifier si la bande passante disponible est suffisante.
De plus, la redondance des paquets peut être utilisée pour, par exemple, corriger les pertes de trames éventuelles, si l’augmentation de débit n’est pas justifiée et si elle crée un problème de congestion. Les paquets redondants servent alors à la fois pour tester l’augmentation de débit et aussi pour corriger des pertes de trames.
Selon un mode de réalisation, l’étape de test est mise en œuvre tant qu’aucune requête d’adaptation de débit n’est reçue d’un dispositif récepteur.
Ainsi, lorsque le dispositif récepteur met en œuvre une estimation de bande passante, il peut informer le dispositif émetteur d’un changement de débit supérieur ou inférieur. Dans les deux cas, le test s’arrête pour effectuer le changement de débit demandé.
Dans un mode de réalisation particulier, l’étape de test est mise en œuvre après un changement de débit au débit discret inférieur.
Ce processus permet ainsi de moduler encore plus l’augmentation de débit (augmentation moins brusque) mais elle peut cependant introduire des dégradations dans le signal transmis.
Dans un mode de réalisation, l’étape de test est mise en œuvre lorsqu’une temporisation a atteint un seuil depuis la dernière requête d’adaptation reçue d’un dispositif récepteur.
Ainsi, si le débit de codage n’a pas été adapté depuis un certain temps, alors une augmentation de débit est sans doute possible et un test d’augmentation est alors approprié.
Dans un mode de réalisation, la temporisation pour déclencher le test d’augmentation est adaptée en fonction d’une information de bande passante disponible estimée au dispositif récepteur..
Ainsi, selon l’état du réseau et la bande passante disponible, on peut définir un temps plus court pour tenter une augmentation de débit si par exemple la bande passante disponible a tendance à augmenter ou au contraire définir un temps plus long quand la bande passante estimée a tendance à diminuer.
Dans un mode de réalisation possible, l’étape de test est mise en œuvre en fonction d’une information d’évolution du débit de codage obtenue.
Dans le cas où la tendance d’évolution du débit de codage est plutôt à la baisse, alors il n’y a pas lieu d’effectuer un test d’augmentation du débit de codage.
Dans un mode de réalisation avantageux, l’information d’évolution du débit de codage est obtenue à partir d’un historique de bande passante disponible estimée au dispositif récepteur.
Ainsi, les différentes estimations de bande passante disponible au niveau d’un dispositif récepteur permettent d’obtenir une tendance d’évolution de cette estimation et d’en déduire une information d’évolution de la bande passante disponible.
Dans un autre mode de réalisation, l’étape de test est mise en œuvre après réception d’une requête d’adaptation reçue d’un dispositif récepteur et comportant une demande de transmission de paquets redondants selon des paramètres de transmission choisis.
Ainsi, dans ce mode de réalisation, c’est le dispositif récepteur qui détermine la pertinence de la mise en œuvre d’une étape de test selon des estimations de bande passante effectuées. La requête d’adaptation est par exemple déterminée au dispositif récepteur, en fonction de la bande passante disponible estimée.
La présente invention vise également un procédé de détermination d’une requête d’adaptation de débit de codage de signaux temps réels d’une session de communication temps réel entre des dispositifs émetteurs et des dispositifs récepteurs de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets. Le procédé est tel qu’il comporte une étape d’estimation d’une bande passante disponible pour un dispositif récepteur et de construction d’une requête d’adaptation à transmettre à un dispositif émetteur et comportant une demande de mise en œuvre d’une étape de test d’augmentation du débit de codage par la transmission de paquets redondants selon des paramètres de transmission choisis.
Ainsi, partir d’une estimation de bande passante effectuée au niveau d’un dispositif récepteur d’un terminal, celui-ci peut déterminer s’il est pertinent d’effectuer une étape de test au niveau d’un dispositif émetteur pour augmenter le débit de codage. Une requête d’adaptation est alors construite en conséquence.
L’invention vise également un dispositif émetteur d’un terminal de communication apte à mettre en œuvre des sessions de communication temps réel et comportant un codeur multi-débits selon un ensemble de débits discrets. Le dispositif émetteur est tel qu’il comporte une unité de transmission de paquets apte à mettre en œuvre une étape de test d’augmentation du débit de codage par la transmission d’au moins un paquet redondant selon des paramètres de transmission choisis.
Ce dispositif présente les mêmes avantages que le procédé d’adaptation décrit précédemment, qu’il met en œuvre.
L’invention vise aussi un dispositif récepteur d’un terminal de communication apte à mettre en œuvre des sessions de communication temps réel et comportant un codeur multidébits selon un ensemble de débits discrets. Le dispositif est tel qu’il comporte un module d’estimation apte à estimer une bande passante disponible et un module de construction et de transmission d’une requête d’adaptation, apte à construire et transmettre à un dispositif émetteur, une demande de mise en œuvre d’une étape de test d’augmentation du débit de codage par la transmission de paquets redondants selon des paramètres de transmission choisis.
Ce dispositif présente les mêmes avantages que le procédé de détermination d’une requête d’adaptation décrit précédemment, qu’il met en œuvre.
L’invention vise également un terminal de communication comportant un dispositif émetteur tel que décrit et/ou un dispositif récepteur tel que décrit.
L’invention vise un programme informatique comportant des instructions de code pour la mise en œuvre des étapes du procédé d’adaptation tel que décrit et /ou des étapes du procédé de détermination d’une requête tel que décrit, lorsque ces instructions sont exécutées par un processeur.
Enfin, l’invention se rapporte à un support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l’exécution du procédé d’adaptation tel que décrit et /ou des étapes du procédé de détermination d’une requête tel que décrit.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels:
- la figure 1 illustre un système de communication de Vol P connu de l'état de l'art et précédemment décrit ;
- la figure 2 illustre une méthode d'adaptation de débit connue de l'état de l'art et utilisée avec le codec iSAC précédemment décrit ;
- la figure 3 illustre un mode de réalisation d’un système de communication voix sur IP selon un mode de réalisation de l’invention ;
- les figures 4a à 4c illustrent sous forme d'organigrammes les étapes d'un procédé d’adaptation d’un débit de codage dans un premier mode de réalisation de l'invention;
- les figures 5a et 5c illustrent sous forme d'organigrammes les étapes d'un procédé d’adaptation d’un débit de codage dans un deuxième mode de réalisation de l'invention ainsi que les étapes d’un procédé de détermination d’une requête d’adaptation de débit selon un mode de réalisation de l’invention ;
- la figure 6 illustre un exemple matériel d'un terminal de communication incorporant un dispositif émetteur et un dispositif récepteur, selon un mode de réalisation de l'invention.
En référence à la figure 3, un système de communication bidirectionnelle avec adaptation de débit et utilisation de redondance selon un mode de réalisation de l'invention est maintenant décrit.
La communication est effectuée entre 2 terminaux A et B. On retrouve les éléments de captation et restitution audio (blocs 101, 102 et 151, 152) déjà présentés en rapport avec la figure 1. Sans perte de généralité on suppose ici que le codage s'effectue avec le codec EVS restreint aux modes « EVS Primary SWB » sur une gamme de débits possibles allant de 9.6 à 128 kbit/s. Dans des variantes de l’invention, on pourra utiliser le codec EVS sur une gamme de débit plus restreinte, par exemple de 9.6 à 24.4 kbit/s ou considérer également un changement possible de bande audio, avec des débits fixes par exemple de 7.2 (NB+WB) à 24.4 (NB+WB+SWB) kbit/s en utilisant la bande codée maximale à chaque débit. Dans des variantes, on pourra aussi utiliser d’autres codecs, comme par exemple AMR ou AMR-WB sur une gamme de débits allant respectivement de 4.75 à 12.2 kbit/s (pour AMR) et 6.6 à 23.85 kbit/s (pour AMR-WB).
Le débit du codage à l'émetteur (blocs 301, 351) est adapté selon l'invention en utilisant de façon privilégiée une signalisation dans la bande (in-band) pour indiquer les requêtes d'adaptation avec un champ CMR présent dans la charge utile (payload) des paquets pour le codec EVS. Ce type de signalisation in-band est robuste - dans le sens où il peut être répété dans des paquets RTP successifs si nécessaire - et ne dépend pas des contraintes sur les instants d’envoi de paquets pour RTCP. Pour des codecs n'ayant pas de champ CMR dans leur charge utile (payload), on pourra dans des variantes définir un champ de fonctionnalité équivalente ou utiliser une signalisation hors bande par RTCP (par exemple RTCP REMB); dans la suite on suppose que la signalisation de requête d'adaptation se fait dans la bande par CMR.
On suppose qu'à l'établissement d'appel, le payload RTP du codec EVS est configuré avec un mode « header-full » (hf-only= 1 ) et un CMR systématique (cmr=1). On renvoie le lecteur à la spécification du payload RTP d’EVS dans la spécification 3GPP TS 26.445 Annexe A pour la définition des paramètres SDP (cmr, hf-honly, ...) et aussi sur les modes de « paquétisation » (Compact ou Header-Full) du codec EVS. On rappelle que le code CMR appelé NO_REQ du codec EVS indique que le CMR ne contient pas de requête, et donc que l’information CMR peut être ignorée; cela permet donc d’envoyer des paquets sans requête, même quand l’envoi du CMR est systématique. Dans des variantes de l’invention il sera possible d’utiliser d’autres configurations SDP, comme cmr=0 (envoi de CMR à la demande, uniquement quand un CMR doit être envoyé) ou hf-only=0 (utilisation du mode Compact sauf quand le mode Header-Full est nécessaire, par exemple lorsqu'une trame redondante est ajoutée au paquet courant).
Par ailleurs, dans un mode de réalisation privilégié on suppose que la transmission discontinue (DTX pour « Discontinuous Transmission »), où les trames inactives sont transmises en moyenne toutes les 160 ms par des descripteurs de silence (SID pour Silence Description), est désactivée par le paramètre SDP dtx=-1 du codec EVS. Cela permet d’assurer un test continu de la bande passante sur le canal. Cependant, dans des variantes de l’invention, le mode DTX sera activé pour le codec EVS, ce qui implique que l’invention ne sera appliquée que dans les périodes de signal actif, car il n’est pas pertinent de modifier le mode de transmission discontinue de trames SID afin de préserver une efficacité maximale du mode DTX quand celui-ci est activé. On rappelle que pour les codecs AMR et AMR-WB il n'est pas possible de contrôler le mode DTX au niveau SDP, si bien que ce mode DTX est par défaut toujours activé.
Lorsque la négociation de l'appel utilise le protocole SDP, ce qui est le cas dans les modes de réalisation décrits ici, l'utilisation de la redondance au niveau applicatif (application layer redundancy) dépend du paramètre SDP max-red. Typiquement le paramètre maxred donne la durée maximale (en ms) - à l'émetteur - entre la transmission d'une trame (dite primaire) et la transmission d'une version redondante; ce paramètre permet donc de fixer un retard maximal lorsque la redondance est utilisée. Par exemple max-red=20 indique qu'il est possible d'utiliser la redondance et qu'une trame redondante peut être transmise jusqu'à 20 ms après la trame originale. En général, quand max-red est fixé à 0, cela revient à désactiver l'utilisation de la redondance et si max-red n'est pas présent comme paramètre de signalisation (attribut SDP), cela indique qu'aucune limitation n'existe sur l'utilisation de la redondance - dans la limite où la bande passante globale spécifiée par le paramètre SDP « b=AS: » selon ΙΊ ETE RFC 4566 et les modes de codage autorisés dans la session sont respectés. On suppose ici que le paramètre SDP max-red n'est pas défini ou que sa valeur est suffisante pour pouvoir appliquer l'invention (par exemple max-red=220).
Le récepteur (blocs 308 et 358) reçoit les paquets RTP successifs. Dès qu'un nouveau paquet est reçu, le champ CMR - s'il est présent - est extrait (blocs 307 et 357) et le contenu de ce champ CMR est écrit - sauf dans le cas « NO-REQUEST » (NO_REQ) ou si le champ CMR n'est pas présent - dans une structure appelée CMR_Req” en 306 et 356, qui est partagée entre l'émetteur et le récepteur dans un même terminal. Dans un exemple de réalisation, la structure CMR_Req comprendra plusieurs entrées:
• une entrée booléenne appelée updated qui indique si un nouveau CMR a été reçu (prenant pour valeurs vrai ou faux) • une entrée appelée requested_bitrate qui indique le débit de codage (maximal) demandé dans le CMR
On notera que les blocs 307 et 357 sont intitulés Ext. CMR_A/B afin de couvrir le cas général d'une requête CMR étendue utilisée dans le deuxième mode de réalisation; dans le premier mode de réalisation la requête CMR sera une requête classique.
Dans des variantes, on pourra compléter ces entrées par d'autres informations comme requested_bandwidth pour indiquer la bande audio codée demandée (NB, WB, SWB, FB) dans le CMR, et des entrées appelées par exemple activate_ca_mode / ca_fec_mode / ca_offset pour contrôler respectivement l'activation du channel-aware mode et les paramètres du channel-aware mode (FEC mode valant LO ou HI et offset valant -1, 0, 2, 3, 5, ou 7).
Dans une réalisation typique, l'émetteur et le récepteur sont exécutés en parallèle (par exemple dans des files d’exécution ou threads différents) ; cette structure partagée est alors nécessaire et l'accès à cette structure se fait typiquement dans une section critique avec l'usage d'une mutex pour gérer des accès en parallèle.
Le champ CMR à envoyer est construit et codé par les modules de codage du champ CMR 302 et 352. Le champ CMR reçu est extrait par les modules d’extraction 307 et 357. Le champ CMR peut être, soit selon un premier mode de réalisation de l'invention, un champ CMR classique avec des codes définis pour les codecs tels que AMR, AMR-WB ou EVS, soit selon un deuxième mode de réalisation de l’invention, un champ CMR étendu comme décrit ultérieurement dans le deuxième mode de réalisation. Dans ce deuxième mode de réalisation, on utilise un CMR étendu pour indiquer l'activation d'une transmission redondante.
On se restreint dans le mode de réalisation privilégié à un usage du codec EVS en mode Primary SWB pour simplifier la description. Les paramètres de codage et d'émission adaptés selon l'invention sont dans ce cas le débit de codage et l'utilisation de redondance 100%. Dans des variantes, plus de paramètres d'émission pourraient être considérés pour l'adaptation, par exemple la bande passante (NB, WB, SWB ou FB) dans le cas du codec EVS - si la gamme de débit utilisée pour l'adaptation permet aussi de changer de bande codée -, le type de redondance (par exemple une redondance partielle, ou une redondance à plus que 100%),
La redondance est ici définie comme un mode de transmission avec répétition de trames codées au niveau applicatif, comme décrit dans le chapitre 10 de la spécification 26.114. On considère plus particulièrement l'utilisation de la redondance dite à 100% qui implique que le paquet courant contient la charge utile (payload) de la trame courante et la charge utile (payload) d'une trame précédente décalée d'un offset prédéterminé. Ainsi ce type de redondance revient à (approximativement) doubler le débit instantané de transmission (en supposant que le débit de la trame courante et celui de la trame redondante sont identiques) par la recopie d’un paquet précédent de façon ponctuelle, dans un mode de réalisation.
On renvoie le lecteur au chapitre 10 de la spécification 3GPP TS 26.114 pour des illustrations de cas de redondance avec les codecs AMR, AMR-WB et EVS, où la trame codée N est répétée dans un paquet suivant avec une distance appelée offset et notée ici K. Quand K = 1, le paquet N contient la trame N et la trame précédente N -1, tandis que quand K = 2 le paquet N contient la trame N et la trame N - 2 ainsi qu'une trame vide (NO_DATA). Pour un offset K plus grand, le nombre de trames vides (NO_DATA) insérées entre la trame courante d’indice N et la trame redondante d’indice N - K est K -1. On notera qu'il est possible de combiner la redondance avec l'agrégation de trames, mais ce cas n'est pas détaillé ici (voir 3GPPTS26.114 figures 10.12 et 10.13).
Selon l'invention, les paramètres d’émission (débit, activation de redondance) sont fournis par le bloc 305, 355 au codeur/à l'émetteur (bloc 301, 351) qui applique ces paramètres lors du codage et de la transmission de la prochaine trame codée (ou des prochaines trames codées) jusqu'à réception d'une nouvelle requête CMR.
On suppose ici que le débit initial de codage est fixé au débit le plus faible autorisé dans la session, en supposant qu'il n'existe aucune garantie de qualité de service (QoS). Cependant dans des variantes, ce débit initial pourra être défini comme le débit maximal autorisé (si on dispose d'informations sur une garantie de débit « GBR » ) ou un débit intermédiaire prédéterminé entre le débit minimal et le débit maximal.
A la réception d'un nouveau paquet RTP, une estimation de bande passante est réalisée (blocs 304 et 354). Dans un mode de réalisation cette estimation sera similaire à l'estimation réalisée dans le codec iSAC à partir des informations sur le dernier paquet reçu (en ayant conservé l'historique de l'analyse réalisée à partir des paquets précédents):
- taille du paquet (charge utile RTP hors entêtes protocolaires)
- temps d'arrivée
- numéro de séquence (champ RTP)
- timestamp (champ RTP)
Cette estimation de bande passante disponible est effectuée chaque fois qu'un nouveau paquet RTP est reçu par le récepteur. Dans des variantes, on pourra utiliser une estimation différente de l'estimation de bande passante au récepteur, par exemple l'estimation de l'algorithme de contrôle de congestion GCC, ou d’autres méthodes d’estimation de bande passante disponible à partir des mêmes informations sur la réception des paquets ou d'informations dérivées comme le taux de perte estimé ou la gigue estimée.
On suppose ici que l'historique de la bande passante estimée lors de la réception des paquets sur une durée prédéterminée, par exemple 500 ms, incluant le paquet qui vient d'être reçu, est stocké dans le bloc 304 et 354, et qu'une structure partagée appelée BWJnfo en 303 et 353 est définie pour pouvoir communiquer à l'émetteur qu'un nouveau CMR doit être envoyé et les informations associées à ce CMR. Dans un exemple de réalisation, la structure BWJnfo comprend les entrées suivantes:
• une entrée booléenne appelée updated qui indique si un nouveau CMR sera à envoyer (prenant pour valeurs vrai ou faux) • une entrée appelée requested_bitrate qui donne le débit de codage correspondant à la bande passante disponible estimée par le récepteur
Dans des variantes de l'invention il sera possible de compléter ces entrées par des informations complémentaires permettant de construire une requête CMR pour changer de bande audio codée, d'activer le channel-aware mode du codec EVS. Dans le second mode de réalisation, les structures BWJnfo et CMR_Req comprendront également un champ appelé burst_uplink associée à une requête CMR étendue, comme expliqué plus loin dans le deuxième mode de réalisation.
A partir de l'historique de bande passante disponible estimé en 304, 354, il est possible de prendre en compte non seulement la valeur instantanée de la bande passante (mise à jour lors de la réception du dernier paquet), mais aussi sa tendance sur l'horizon temporel défini par l'historique (ici par exemple 500 ms). On considère ici à titre d'exemple que la tendance d'évolution de la bande passante disponible est estimée par une simple régression linéaire. On pourra ainsi calculer la pente du modèle linéaire y= f(x) où x est le temps d'arrivée des paquets (en secondes ou ms) et y est la bande passante disponible estimée. Cette pente (aussi appelée coefficient directeur) est par exemple donnée de façon analytique sous la forme : Σ(Χ ~ x)(yt~ ΫΪ/Σ&ί ~ x)2 où (¾^) sont Ιθ temps de réception et la bande passante estimée lors de la réception du paquet i, x et ÿ sont les moyennes des Xt et yt sur l'horizon temporel considéré. Dans des variantes on pourra utiliser des variantes robustes de régression linéaire, avec une régularisation selon la norme L1 ou L2. Dans des variantes on pourra aussi utiliser une estimation de tendance dérivée de l’estimation de bande passante disponible (ce qui est par exemple possible si un filtrage de Kalman est utilisé comme dans l'algorithme GCC).
Avant le codage de la prochaine trame, la requête extraite est lue et convertie (blocs 305 et 355) en paramètres de codage/d'émission, qui sont listés ci-dessous :
• le débit de codage à utiliser • l’utilisation de redondance 100%
On remarquera que la taille du payload RTP est souvent légèrement supérieure à la charge utile nette associée au débit de codage. Par exemple, pour un codage de type EVS avec un mode de transport Header-full et avec un CMR systématique (hf-only= 1, cmr=1), deux octets sont systématiquement rajoutés à la trame codée pour constituer le payload.
Un dépassement supplémentaire (overhead) peut également être présent dans un contexte de transmission, comme par exemple avec la technologie WebRTC, où des extensions d'entête RTP sont utilisées, ce qui rajoute des octets supplémentaires aux paquets RTP. Par exemple pour une communication voix, 12 octets peuvent être rajoutés dans l’entête RTP si la configuration suivante est utilisée:
• Une extension d’entête de type « one-byte » selon la RFC 5285 (avec un préambule OxBEDE sur 2 octets et un champ de longueur indiquant length=2 sur 2 octets pour signaler que 2 types d’extension sont ajoutées), pour un sous-total de 4 octets.
• Une extension « one-byte » sur 2 octets, de type :
a=extmap: 1 urn :ietf: params :rtp-hdrext:ssrc-audio-level • Une extension « one-byte » sur 4 octets de type :
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time • Un bourrage de 2 octets nuis.
Dans une autre configuration un seul type d’extension (par exemple l'extension ci-dessus de type ssrc-audio-level) pourrait être utilisé, ce qui ne rajouterait que 8 octets supplémentaires.
S ce débit supplémentaire n’est pas pris en compte (retranché de la taille du paquet RTP) dans l’estimation de bande passante disponible au récepteur, cela revient à tester un débit plus élevé que le mode de codage actuel. Ainsi, la bande passante réellement utilisée pour une trame donnée (sans redondance 100%) sera biaisée vers une valeur de débit de codage plus élevée, à cause des octets supplémentaires dans l'entête RTP si les entêtes RTP ne sont prises en compte qu'après estimation de bande passante. Dans le mode de réalisation privilégié, on éliminera ce biais en ne donnant à l'estimation de bande passante disponible (bloc 304, 354) que la taille de la charge utile sans les entêtes RTP. Dans des variantes de l’invention il sera prévu de ne pas éliminer ce biais, et on supposera que le récepteur compensera ce biais avant de former le CMR à envoyer.
On présente d'abord un premier mode de réalisation où l'émetteur et le récepteur agissent de manière coordonnée et où la décision d'activer la redondance est prise par l'émetteur à partir des informations sur la réception de CMR et du débit actuel. Le débit actuel est en particulier utilisé, pour vérifier s'il correspond au débit maximal autorisé dans la session, auquel cas la redondance n'est pas activée. Selon ce premier mode de réalisation, l'émetteur décide de tester le canal en envoyant des paquets avec redondance, après un certain délai avant de déclencher un test d'augmentation de débit. Dans un premier mode de réalisation, on considère d'abord le cas où chaque paquet issu de ce test contient de la redondance. Dans un autre mode de réalisation plus optimisée, la redondance ne sera envoyée que par intermittence pour limiter le pic de débit moyen occasionné par le test du canal. Dans ce premier mode de réalisation, l'initiative de décision sur la redondance revient à l'émetteur.
On rappelle que la logique normale du champ CMR pour les codecs AMR, AMR-WB, et EVS est d'indiquer qu'il ne faut pas dépasser un débit maximal indiqué par le CMR; selon l'invention; l'émetteur doit donc normalement respecter cette contrainte, qui est particulièrement importante dans les cas d'interopérabilité avec les systèmes mobiles en mode circuit qui peuvent avoir un débit maximal de codage (par exemple 12,65 kbit/s pour AMR-WB) inférieur à celui autorisé en voix sur LTE (par exemple 23,05 kbit/s). Ainsi, pour préserver l'interopérabilité avec d'autres systèmes (dont les passerelles d'interopérabilité), il sera prévu dans ce premier mode de réalisation de définir un paramètre SDP adapt, et dont l'utilité sera de vérifier que les deux terminaux en communications sont bien compatibles avec l'invention. Dans ce cas, la logique du champ CMR pourra être modifiée pour permettre à l'émetteur de dépasser temporairement la limite imposée par le dernier CMR reçu, afin de tester une augmentation de débit (qui par nature ne respecte par la contrainte de débit maximal du dernier CMR reçu). S un terminal implémentant l'invention communique avec un autre terminal non compatible avec le paramètre SDP adapt, l'invention ne pourra pas être utilisée car elle suppose que le terminal distant envoie par CMR un débit correspondant à une bande passante estimée en réception, ce qui ne serait pas le cas.
Dans ce mode de réalisation, quand la bande passante disponible estimée au récepteur est différente du débit actuel observé par le récepteur (à partir du dernier paquet reçu), un CMR est envoyé pour changer de débit. Cette approche est en particulier suffisante pour réduire le débit, car l’estimation de bande passante selon l’état de l’art fonctionne en général assez bien pour détecter qu’il faut baisser le débit actuel quand celui-ci dépasse la capacité du canal. En effet, lors d'un début de congestion, le récepteur observera une augmentation du délai de file d’attente ou du taux de perte. Cependant, quand le débit actuel est inférieur à la bande passante disponible, la bande passante est en général sous-estimée si un test d'augmentation de débit n’est pas mis en œuvre..
Ainsi pour pouvoir augmenter le débit, l’émetteur envoie selon l’invention des paquets contenant de la redondance pour tester le canal. S des pertes sont causées par cette augmentation de débit, elles pourront être compensées par la redondance. Le fait d’utiliser la redondance permet de tester le canal avant d’augmenter réellement le débit et de compenser les pertes induites de façon proactive.
On fixe dans ce mode de réalisation les paramètres d'adaptation suivants qui définissent les caractéristiques des paquets de redondance ou « bursts » selon un exemple suivant de valeurs:
• durée (maximale) de redondance: Lburst = 100 (définie en nombre de trames);
• offset de redondance: Kburst (sa valeur est fixée à une valeur >0, par exemple à 2, en cours de redondance, et elle vaut -1 quand la redondance est désactivée), on verra plus loin que l'offset pourra aussi prendre une valeur qui sera fonction d'un paramètre de fréquence d'envoi de redondance;
• temps écoulé (« timer ») depuis le dernier CMR reçu: TCMR réinitialisé à 0 à chaque réception de CMR (avec un débit donné, autre que NO_REQ);
• délai de déclenchement du test d’augmentation de débit par redondance : T6urst (défini en nombre de trames) fixé à 250 • facteur d'ajustement contrôlant le délai de déclenchement du test: fburst (sa valeur est adaptée mais ré-initialisée à 1.0) ;
• paramètre d'adaptation du facteur fburst : <p6urst = 1.5.
Dans des variantes, d'autres valeurs pourront être affectées aux paramètres ci-dessus.
Les figures 4a, 4b et 4c représentent un exemple d’implémentation d’un procédé d’adaptation de débit avec redondance selon l’invention sous la forme d’organigrammes, mis en œuvre dans un système bidirectionnel.
La figure 4a présente les étapes mises en œuvre par le récepteur selon un premier mode de réalisation de l’invention, à la réception d’un paquet.
Dans ce mode de réalisation, la communication est bidirectionnelle et les étapes suivantes peuvent être appliquées dans les deux terminaux.
A la réception d’un paquet (en 401), deux types d’information sont extraits :
• des informations de transmission du paquet actuel permettant l’estimation de la bande passante disponible (en 402) selon une des méthodes d’estimation précédemment décrites. L’extraction de ces informations est suivie par les étapes X décrites en référence à la figure 4b ;
• des informations sur le type d’adaptation demandé à partir de la requête CMR envoyée par l’autre bout de la communication (en 403). Le CMR extrait est indiqué dans la structure partagée CMR_req, en particulier pour signaler qu'un nouveau CMR a été reçu si celui-ci est présent et différent de NO_REQ. L'entrée updated de la structure CMR_Req est mise à la valeur vrai quand un CMR (autre que NO_REQ) a été extrait.
On rappelle que, pour le codec EVS, le champ CMR est codé sur un octet appelé CMR byte et qu'il est construit à partir de 3 champs: H (header à 1 bit), T (type sur 3 bits) et D (data sur 4 bits) selon les tableaux A.2 et A.3 de l'annexe A de la spécification 3GPP TS 26.445. On peut donc extraire le débit DcmR demandé et éventuellement d'autres paramètres de codage (comme la bande codée) en décodant le CMR (si celui-ci est reçu et autre que la valeur NO_REQ correspondant à T= 111 et D= 1111 en binaire).
On ne détaille pas ici les étapes connues de l'homme de l'art qui consistent à extraire les entêtes (champs CMR et ToC pour Table of Content si présents), à démultiplexer et décoder les trames codées à partir de la charge utile du paquet reçu pour le codec EVS. En particulier, en cas de pertes de paquet, la redondance éventuelle sera utilisée par le récepteur pour corriger des pertes si la trame courante perdue a été dupliquée dans un autre paquet avec un offset donné.
La figure 4b détaille les étapes X mises en œuvre au récepteur après extraction des informations sur le paquet actuel (402). Une estimation de la bande passante est faite selon l’une des méthodes précédemment décrite (en 411). Ensuite une correspondance (« mapping ») entre la bande passante estimée et les débits discrets EVS est réalisée (en 412) pour déterminer s’il y a besoin de changer le débit de réception actuel et s’il est possible de passer d’un débit discret à un autre.
Dans le mode de réalisation privilégié cette correspondance est mise en œuvre selon le pseudo-code donné en Annexe 1 pour obtenir le débit D à partir de la bande passante disponible B.
Dans des variantes, on pourra modifier cette correspondance en prenant par exemple le débit discret du codec EVS supérieur ou inférieur le plus proche de la bande passante estimé.
S le débit estimé est équivalent au débit actuel (N en 413), aucune information de débit (bloc 414) n’est écrite dans la structure partagée BWJnfo et l'entrée updated de cette structure est mise à la valeur faux. Si le débit estimé est différent du débit actuel (O en 413), on écrit dans la structure partagée BWJnfo les informations nécessaires à l’étape 415 (la valeur de l'entrée requested-bitrate) pour que l'émetteur puisse coder le CMR avec la prochaine trame à envoyer, en fixant aussi la valeur de l'entrée updated à vrai. Une requête classique de changement de débit à un débit discret correspondant sera alors construite et codée comme dans le cas d’un codec EVS de l’état de l’art.
La figure 4c détaille les étapes mises en œuvre à l'émetteur (incluant le codeur) d’un procédé d’adaptation de débit de codage selon un premier mode de réalisation de l'invention.
Lors de la réception d'une nouvelle trame de signal à coder (étape 420), l'émetteur vérifie si un CMR a été reçu dans la structure partagée CMR_Req en 421 (en vérifiant si l'entrée updated est passée à vrai). S c'est le cas, il réalise une adaptation des paramètres de codage et d'émission (en 424), si un CMR comportant une requête d’adaptation existe, puis il met la valeur de l'entrée updated de la structure CMR_Req à faux. De plus, si un CMR a été reçu avec un débit demandé différent du débit de codage actuel, une indication de réception de CMR est mise en mémoire et le compteur de trame depuis le dernier CMR reçu est remis à 0 (TCMR=0) à l’étape 424.
En 425, on vérifie si un test d’augmentation de débit avec redondance est en cours, en vérifiant si Nburst > 0. Si c’est le cas (O en 425), alors ce test est désactivé en 426. On réinitialise en 426 les paramètres de redondance avec Nburst = -1 (Nburst représentant le nombre de trames avec redondance qui reste à transmettre) et Kburst = -1. De plus, le délai de déclenchement du test d’augmentation de débit est adapté selon l’adaptation de débit demandée dans la requête CMR.
Ainsi;
• S le débit de codage actuel est supérieur au CMR reçu (7?s > RCMr) le récepteur demande de baisser le débit. Il est alors décidé d’augmenter la temporisation pour un déclenchement d’un test d’augmentation de débit. Pour cela, on augmente le facteur d’ajustement en fixant fburst =fburst + <pburst La temporisation pour déclencher un test est comme expliqué ultérieurement, fonction du facteur fburst selon la formule suivante :
~^CMR ~ fburst-tburst • Sinon le récepteur distant demande d'augmenter le débit (Rs < RCMr) et on choisit de réduire le délai de déclenchement d’un test d’augmentation de débit en adaptant le facteur selon la formule fburst = fburst/<Pburst On pourra également ajouter une condition d'intervalle temporel minimal avec par exemple l'étape supplémentaire: fburst «- max(fburst, 0.15).
Cette logique d'adaptation suit le principe Al MD (Additive Increase Multiplicative Decrease) de contrôle de congestion.
S’il n’y a pas de CMR reçu dans la structure partagée ou si le CMR ne comporte pas de requête d’adaptation (NO_REQ), alors l’étape 422 est mise en oeuvre.
En 422, l'émetteur vérifie si un test d’augmentation de débit est à mettre en oeuvre. On vérifie que les conditions pour activer un test d’augmentation du débit de codage sont vérifiées. Plus précisément, dans le mode de réalisation privilégié, il est décidé de tester une augmentation de débit en 422 si les conditions suivantes sont simultanément remplies:
• S le débit actuel Rs est inférieur au débit maximum R™ax autorisé dans la session. Sinon, si Rs = R™ax, il n’y a pas de test mis en oeuvre (429). On pourra aussi réinitialiser fburst = 1.
• Si le temps écoulé depuis la dernière requête CMR reçue TCMR (défini comme le nombre de trames depuis le dernier CMR) est supérieur à une temporisation prédéterminée tcmr (par exemple 500 ms). On prend ici tcmr = fburst.Tburst·, dans des variantes on pourra fixer par exemple tcmr=250 trames de 20 ms (ce qui correspond à 5 secondes). Sinon, si le temps nécessaire est insuffisant (TCMR < tcmr), aucun test n’est mis en œuvre (429).
Dans des variantes, on pourra également rajouter une condition supplémentaire:
• S la tendance d’évolution du débit est stable avec une tendance positive par rapport à l'historique de débit. On pourra par exemple utiliser une simple régression linéaire sur la bande passante estimée en fonction du temps d'arrivée des paquets sur une période de 500 ms pour calculer une pente (voir l'estimation de la pente décrite précédemment ou les variantes associées). Si la pente dépasse un seuil positif ou nul (par exemple 0), on pourra commencer un test par redondance pour tester le canal. Sinon, dans le cas où la une pente est négative, aucun test n'est mis en œuvre (429).
S un test d'augmentation de débit (burst) est à activer (O en 422), alors, on définit les paramètres de la redondance à appliquer en 423. On vérifie:
• Si le codeur n'a pas de redondance en cours (Nburst < 0; Nburst représentant le compteur de trame avec redondance) lors du codage de la trame courante. Si c’est le cas, alors on fixe les paramètres suivants: l'offset de la redondance à Kburst (par exemple à 2) et on initialise le compteur de trames avec redondance à Nburst = Lburst + Kburst avec par exemple Lburst à 100.
• S le codeur est en cours de redondance (Nburst > 0) lors du codage de la trame courante, alors, on vérifie:
S on a atteint la fin de la redondance appliquée actuelle (Nburst = 0). Dans ce cas, on fixe Kburst = -1 et on réinitialise TCMR=0.
Snon : on décrémente le compteur de trames avec redondance avec Kburst ~ Kburst ~ 1
En E427, l’émetteur vérifie si un CMR doit être transporté dans le paquet associé à la trame courante à coder. S c'est le cas, les données du CMR dans la structure BWJnfo sont extraites pour codage ultérieur du CMR.
L'émetteur crée ensuite l'entête du payload RTP courant, si les champs CMR et ToC sont à insérer dans le paquet courant. Pour le champ CMR, on renvoie le lecteur aux tableaux A.2 et A.3 de l'annexe A de la spécification 3GPP TS 26.445 pour la construction et le codage du champ CMR pour le codec EVS à partir des informations sur la requête CMR (débit, bande codée...) à coder. S un champ CMR doit être envoyé mais l'entrée updated de la structure BWJnfo a la valeur faux, on utilisera le code NO_REQ qui correspond à T=111 et
D= 1111 (en binaire). De façon similaire, le codage du champ ToC est décrit dans la figure A.4 et les tableaux A.4 et A.5 de l'annexe A de TS 26.445. Selon l'invention, si la redondance 100% est utilisée dans le paquet courant, le champ ToC décrira à la fois le débit de la trame courante, le débit de la trame redondante et l'offset de redondance Kburst (en utilisant le nombre adéquat de ToC associés à NO_DATA). On rappelle que des exemples de structure de trames redondantes sont donnés au chapitre 10 de la spécification 3GPP TS 26.114 et la construction du champ ToC suit les principes donnés dans cette spécification pour les codecs AMR, AMR-WB et EVS.
La trame courante est codée en 427 et ajoutée aux données du paquet.
Si la redondance est activée (O en 422), la trame codée redondante correspondant à l'offset Kburst (mémorisée dans une file ou une autre structure de données) est aussi ajoutée aux données du paquet courant pour être transmise en 428.
Le paquet ainsi formée avec les entêtes (éventuelles) et données codées est transmis (428) en utilisant les informations relative à la taille de la charge utile RTP et le nombre de trames codées depuis la réception du dernier CMR est incrémenté de 1 (TCMR <- TCMR+1). La trame codée courante est mémorisée dans une file pour une éventuelle utilisation ultérieure comme trame redondante.
On notera qu’il n’est pas toujours possible de doubler le débit de codage, si la session SDP (avec le paramètre b=AS) ou les paramètres de qualité de service (GBR et MBR sur réseau mobile de type VoLTE) limitent le débit maximal utilisable par le codec.
Dans des variantes de l’invention, on prendra par exemple en compte la définition d’un paramètre SDP de type b=AS limitant le débit maximal utilisable par le codec. Par exemple dans le cas du codec EVS SWB, on peut avoir un paramètre b=AS limitant le débit à 24.4 kbit/s (en transmission d’une trame unique de 20 ms). Dans ce cas, selon l’invention, on pourra limiter l’utilisation de la redondance de deux façons :
• si le réseau ne rejette pas les paquets sur la base du débit instantané (par exemple un débit supérieur à 24.4 kbit/s) mais en utilisant une moyenne glissante du débit sur une fenêtre temporelle (par exemple d'une durée de 2 secondes comme indiqué à la section 7.5.5.1 de la spécification 3GPP TS 26.114), on pourra garder la réalisation d’une transmission alternée de paquets avec ou sans redondance, c'est-à-dire utiliser une transmission redondante intermittente pour le test d'augmentation de débit. La fréquence de transmission des paquets redondants est alors adaptée à cette contrainte de débit maximum. On détaille plus loin une variante du premier mode de réalisation pour ce cas.
• si aucun paquet ne peut dépasser une taille limite correspondant au débit maximal (par exemple une taille correspondante à 24.4 kbit/s), on pourra tester par exemple 2x9.6 kbit/s mais pas 2x13.2 kbit/s et on pourra passer ainsi aux débits de 13.2 ou 16.4 kbit/s qui sont compris entre 9.6 et 2x9.6 kbit/s; par contre il sera difficile de tester le passage à 24.4 kbit/s, à moins d'alterner un codage à 9.6 et un codage à 13.2 et d'associer une trame codée et une trame redondante pour un débit d'environ 9.6+13.2 kbit/s. Dans tous les cas, cette variante implique qu’avant d’appliquer la redondance, une diminution du débit à un débit discret inférieur doit être potentiellement effectuée (par exemple pour tester si l'on peut passer de 13.2 à 16.4 ou de 16.4 à 24.4 kbit/s). On utilisera un débit inférieur (par exemple 9.6 kbit/s) au débit actuel (par exemple 13.2 ou 16.4 kbit/s). En effet il ne serait pas possible d’utiliser 2x13.2 kbit/s, car cela dépasserait le débit de 24.4 kbit/s et seuls les cas 2x9.6 kbit/s et 9.6+13.2 kbit/s seront autorisés.
Dans des variantes de l'invention selon le premier mode de réalisation, l'activation de la redondance pourra n'être autorisée que lors des périodes de signal actif pour minimiser les impacts de l'augmentation de débit.
On a décrit précédemment un test d’augmentation de débit avec une redondance 100%, c’est-à-dire une redondance pour chaque paquet transmis pendant un nombre de trame déterminé (Lburst). Dans des variantes de réalisation, comme pour le deuxième mode de réalisation décrit ultérieurement, la redondance ne sera activée que de façon intermittente. Par abus de langage, on appellera ici fréquence de redondance la période avec laquelle un paquet redondant est utilisé - ainsi une fréquence de x signifie qu'une trame redondante est insérée tous les x paquets.
Plutôt que de doubler (approximativement) le débit de codage, la redondance est utilisée par exemple tous les 2 ou 3 paquets ce qui permet d'obtenir en moyenne une augmentation relative de débit fractionnaire, afin de tester (en moyenne) le passage au débit discret immédiatement supérieur et non un débit doublé.
Par exemple si le débit est de 9.6 kbit/s, l'activation de la redondance fait passer le débit pic instantanée à approximativement 2x9.6 kbit/s mais le débit moyen réel sur le canal sera de (freq+1 )/freq x 9.6, soit 2x9.6 (approx. 19.2) si freq=1, 1.5x9.6 (approx. 14.4) si freq=2, 4/3x9.6 (approx. 12.8) si freq=3.
L'offset de redondance est fixé à la même valeur que le paramètre de fréquence (freq) pour que la redondance puisse être exploitée.
Cet autre paramètre définissant la redondance, pourra être déterminé à l’étape 423 de la figure 4c en fonction d’information du débit actuel et du débit immédiatement supérieur. Par exemple, si la gamme de débit 9.6 à 24.4 kbit/s est utilisable dans une session avec le codec EVS en mode Super-Wideband, on pourra utiliser:
- à partir d'un débit de 9.6 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 9.6 kbit/s tous les 2 paquets (pour arriver à un débit moyen sur le canal de près de 14.4 kbit/s) ou tous les 3 paquets (approximativement 12.8 kbit/s)
- à partir d'un débit de 13.2 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 13.2 kbit/s tous les 3 paquets (approx. 17.6 kbit/s) ou tous les 4 paquets (approx.16.5 kbit/s)
- à partir d'un débit de 16.4 kbit/s, le test d'augmentation de débit pourra se faire avec une trame redondante codée à 16.4 kbit/s tous les 2 paquets (approx. 24.6 kbit/s)
La fréquence d'envoi de la redondance est donc adaptative, en fonction du débit actuel. Elle est de 2 ou 3 à 9.6 kbit/s, 3 ou 4 à 13.2 kbit/s, 2 à 16.4 kbit/s.
L'offset de redondance sera de façon privilégié défini comme étant égal à la fréquence d'envoi des paquets redondant pour compenser d'éventuelles pertes des paquets plus volumineux. Dans des variantes il sera possible d'utiliser un autre offset pour répéter par exemple la trame qui suit immédiatement le paquet avec redondance.
D'une manière plus générale, la fréquence pourra être choisie en fonction du débit discret courant DO et du débit discret D1 immédiatement supérieur pour un codec donné, comme la valeur entière la plus proche de 1 /(D1/D0-1 ).
A titre d'exemple, on considère les cas suivants (Tableau 1) qui seront utilisés de façon privilégiée dans cette variante du premier mode de réalisation:
| D0 | D1 | 1/(D1/D0-1) | freq |
| 9.6 | 13.2 | 2.66 | 3 |
| 13.2 | 16.4 | 4.125 | 4 |
| 16.4 | 24.4 | 2.05 | 2 |
Tableau 1
On présente ensuite un deuxième mode de réalisation où l'émetteur et le récepteur agissent encore de manière coordonnée mais où cette fois-ci le récepteur envoie une requête explicite d'activation de redondance 100% pour tester une augmentation de débit, par le biais d'une requête CMR étendue. On suppose dans cette description un débit maximal de 24.4 kbit/s et une valeur de b= AS correspondante à ce débit maximal.
Dans ce mode de réalisation, les codes CMR existants du codec EVS (comme définis dans le tableau A.3 de la spécification 3GPP TS 26.445) sont utilisés pour envoyer une requête vers un débit de codage donné, lorsqu'il s'agit de baisser ou d'augmenter le débit en fonction de la bande passante disponible estimée. Cependant, un CMR non classique, dit CMR étendu est nécessaire pour envoyer une requête d'activation de redondance, car les codes CMR existants du codec EVS ne permettent qu’une adaptation en débit, bande audio et le contrôle d’un mode spécial de redondance partiel à 13.2 kbit/s (appelé « channel-aware mode »). On suppose que la session SDP inclut un paramètre supplémentaire appelé sans perte de généralité adapt pour signaler et autoriser l'utilisation d'un tel CMR étendu, et que les deux terminaux sont compatibles avec le paramètre SDP adapt. Pour indiquer l'activation d’une étape de test d’augmentation de débit par une transmission de paquets redondants, par exemple, une redondance 100%, dans le cas du codec EVS, on utilise selon ce mode de réalisation, des codes CMR qui sont libres, laissés pour un usage futur ( for future use) ou réservé (reserved) et qui ne sont pour l'instant pas utilisés dans les spécifications du codec EVS.
A titre d'exemple, on considère les codes suivants (Tableau 2) :
| Code CMR (HTD) | Requête EVS |
| 1111 0000 | RED 2x9.6-SWB, freq.1, offset= 1 |
| 1111 0001 | RED 2x9.6-SWB, freq.2, offset=2 |
| 1 111 0010 | RED 2x9.6SWB, freq. 3, offset=3 |
| 1 111 0011 | RED 2x13.2-SWB, freq.1, offset = 1 |
| 1 111 0100 | RED 2x13.2-SWB, freq.2, offset=2 |
| 1 111 0101 | RED 2x13.2-SWB, freq.3, offset=3 |
| 1 111 0110 | réservé |
| 1 111 0111 | réservé |
| 1 111 1000 | réservé |
| 1 111 1001 | réservé |
| 1 111 1010 | réservé |
| 1 111 1011 | réservé |
| 1 111 1100 | réservé |
| 1 111 1101 | réservé |
| 1 111 1110 | réservé |
Tableau 2 où la redondance 100% est activée par l'émetteur de façon intermittente tous les 1, 2, ou 3 paquets (selon la fréquence d'envoi) pour augmenter le débit.
Par exemple si le débit est de 9.6 kbit/s, l'activation de la redondance fait passer le débit pic instantanée à approximativement 2x9.6 kbit/s mais le débit moyen réel sur le canal sera de (freq+1)/freq x 9.6, soit 2x9.6 (approx. 19.2) si freq=1, 1.5x9.6 (approx. 14.4) si freq=2, 4/3x9.6 (approx. 12.8) si freq=3.
L'offset est fixé à la même valeur que la fréquence (freq) pour que la redondance puisse être exploitée. Dans des variantes, une autre convention pourra être définie pour fixer la valeur d'offset.
On ne détaille pas ici les détails de construction ou d'extraction de CMR selon le tableau 2. Cependant on suppose que la structure CMR_Req contiennent un champ appelé burst_uplink qui est mis à 1 , 2 ou 3 lorsque des codes CMR étendus selon le tableau 2 sont utilisés, sinon sa valeur est mise à -1. Ainsi en combinant l'entrée requested_bitrate et cette entrée burst_uplink il est possible de signaler complètement le type de requête à envoyer ou de requête reçue.
Une caractéristique importante de ce deuxième mode de réalisation par rapport à l'utilisation classique de redondance 100% est que la redondance est de façon privilégiée intermittente: plutôt que de doubler (approximativement) le débit de codage, la redondance est utilisée de façon adaptative par exemple tous les 1, 2 ou 3 paquets ce qui permet d'obtenir en moyenne une augmentation de débit fractionnaire, afin de tester (en moyenne) le passage au débit discret immédiatement supérieur et non un débit doublé. D'une manière plus générale, la fréquence pourra être choisie en fonction du débit discret courant D0 et du débit discret D1 immédiatement supérieur pour un codec donné, comme la valeur entière la plus proche de 1 /(D1/D0-1 ).
Dans le cas où le débit pic instantané ne peut pas dépasser le débit maximal autorisé dans la session (par exemple 24.4 kbit/s), on n'utilisera que des requêtes associées à 9.6 kbit/s avec différentes valeurs de fréquences (freq= 1,2 ou 3), sachant qu'il sera difficile dans ce cas de tester un débit proche de 24.4 kbit/s car la fréquence freq= 1 donne un débit autour de 19.2 kbit/s. Sinon on pourra également autoriser les requêtes associées au débit de 13.2 kbtit/s, ce qui permet de tester des débits d'approximativement (freq+1 )/freq x 13.2, soit 2x13.2 (approx. 26.4) si freq= 1, 1.5x13.2 (approx. 19.8) si freq=2, 4/3x13.2 (approx. 17.6) si freq=3.
A partir de la bande passante estimée - en instantané ou sur un horizon de passé donné par l’historique - et en utilisant potentiellement des informations supplémentaires comme le taux de pertes de paquets mesuré en réception (où la bande passante estimée sera multiplié par un facteur <1 comme 0,9 dès que le taux est par exemple >10%), une requête d'adaptation de débit est déterminée et encodée en un code CMR (bloc 302 et 352 de la figure 3). Cette requête CMR est rajoutée par l'émetteur local dans le prochain paquet à transmettre.
On définit selon l'invention trois types de décisions de requête d’adaptation à envoyer pour l'adaptation de débit :
• décision SET_RATE : on envoie dans ce cas un CMR qui indique un débit de codage qui correspond à la bande passante estimée si le débit actuel n'est pas dans un intervalle autour de cette bande passante estimée ;
• décision NO_REQ: on garde le débit actuel si le débit à utiliser reste inchangé - dans ce cas on peut envoyer un CMR indiquant le débit actuel ;
• décision USE_RED: on envoie un CMR indiquant qu’il faut activer la redondance 100% à l'émission - dans un mode de réalisation privilégié, la redondance est utilisée de façon adaptative - avec un offset adaptatif lié au débit de codage - pour tester le passage au débit immédiatement supérieur au débit actuel (avec une fréquence d'envoi variable), dans des variantes on pourra envisager d'activer la redondance pour un usage en continu - avec freq=1 et offset = 1 - jusqu'à ce qu'on détecte des problèmes de qualité. Cela permet une remontée rapide du débit mais en général on préférera une remontée progressive par paliers pour tester les débits supérieurs un par un.
Pour les codecs AMR et AMR-WB qui fonctionnent avec un feedback inband par CMR, la signification du CMR NO_REQ est différente de celle d’EVS, NO_REQ indique le débit maximal autorisé. Dans des variantes utilisant ces codecs, on remplacera donc la décision NO_REQ par une décision SET_RATE pour indiquer le débit courant. Dans des variantes de l’invention utilisant EVS on pourra de la même façon remplacer la décision NO_REQ par une décision SET_RATE pour indiquer le débit courant.
Selon ce deuxième mode de réalisation, des codes CMR réservés sont utilisés, ce qui justifie la notation de CMR étendu (Ext. CMR) dans les blocs 307 et 357 de la figure 3. Les codes étendus de CMR servent à indiquer une requête d'adaptation pour augmenter le débit de codage, cette requête indique à l'émetteur distant de tester un débit supérieur à ce débit donné dans la requête - dans ce cas l'émetteur activera par transmission de paquets redondants, une transmission à ce débit donné avec redondance 100%.
Cette requête suppose une utilisation de redondance côté émetteur. Dans un mode de réalisation simplifié, l'émetteur pourra exécuter la requête issue du CMR comme dans le premier mode de réalisation de l'invention, en vérifiant que l'entrée updated' est à vrai dans la structure CMR_Req et en appliquant les paramètres d'adaptation contenus dans CMR_Req; après récupération des paramètres, la valeur de updated est remise à faux. Dans un mode de réalisation privilégié, on laissera à l'émetteur suffisamment de flexibilité pour exécuter la requête d'activation de redondance en fonction du signal en cours de codage. Comme expliqué plus loin l'augmentation de débit peut résulter en une congestion, avec des pertes de paquets ou une augmentation de la gigue, il est donc important, quand la bande passante disponible n'est pas connue et testée en aveugle (pour estimer le bottleneck dans le sens descendant) de ne pas dépasser outre mesure cette limite sur le canal; par ailleurs l'impact des pertes et de la gigue est différent selon les types de trames codées, pour les parties inactives ou les parties les moins sensibles de la parole active, on peut plus facilement tolérer ces dégradations.
Pour ce deuxième mode de réalisation, la figure 5a reprend du premier mode de réalisation les étapes d’extraction effectuées au récepteur. Ainsi, à la réception d’un paquet en 501, deux informations sont extraites au récepteur:
• des informations de transmission du paquet actuel permettant l’estimation de la bande passante disponible (en 502) selon une des méthodes d’estimation précédemment décrites. L’extraction de ces informations est suivie par les étapes X décrites en référence à la figure 5b ;
• des informations sur le type d’adaptation demandé à partir de la requête CMR envoyée par l’autre bout de la communication (en 503).
La différence principale avec la figure 4a concerne le fait que la requête CMR peut correspondre à un CMR étendu alors qu'à la figure 4a on suppose une requête CMR classique; de plus les étapes X incluent également la possibilité de décider d'envoyer une requête étendue pour activer la redondance en utilisant l'entrée burst_uplink.
La figure 5b détaille les étapes X mises en œuvre par le dispositif récepteur après extractions des informations sur le paquet actuel (502).
De la même façon que pour le premier mode de réalisation, une estimation de la bande passante est faite selon l’une des méthodes précédemment décrite (en 511). Ensuite une correspondance (« mapping ») entre la bande passante estimée et les débits discrets EVS est réalisée (en 512) comme décrite précédemment pour déterminer s'il faut changer le débit de réception actuel et s’il est possible de passer d’un débit discret à un autre.
S le débit déterminé selon la bande passante estimée dans le dernier paquet reçu est différent du débit actuel (O en 513), on prend la décision « SET_RATE », de changement de débit selon ce nouveau débit. Une requête classique de changement de débit à un débit discret correspondant est définie à l’étape 514 ; les données associées sont écrites dans la structure partagée BWJnfo, pour que l'émetteur puisse ensuite coder la requête correspondance avec la trame à envoyer.
Dans le cas où le nouveau débit est identique au débit actuel, alors une étape de vérification de conditions d’application de test est effectuée en 516.
Cette étape de vérification 516 vérifie l’historique d’estimation de bande passante et mesure ainsi une tendance de variation de la bande passante estimée. S cette tendance est positive (O à 516), c’est-à-dire si la bande passante estimée tend à augmenter, alors une décision « USE_RED » peut être prise et l’étape 517 est alors mise en œuvre.
Dans le cas contraire (N à 516), si la tendance est négative, alors il n’y a pas d’émission de requête, la décision « NCjREQ » est prise et les données associées au CMR sont écrites dans la structure partagée BWJnfo.
Pour mesurer la tendance de variation, on pourra par exemple utiliser une simple régression linéaire sur la bande passante estimée en fonction du temps d'arrivée des paquets sur une période de 500 ms pour calculer une pente, comme décrit précédemment.
Le temps depuis lequel cette décision « NO-REQ » reste sélectionnée peut être mesuré pour décider si un test d’augmentation de débit doit être activé ou non. Si ce temps écoulé est inférieur à un seuil (par exemple 500 ms), alors une décision « NO_REQ » est prise (N à 516). Le mode « NO-REQ » n’a pas été suffisamment long. Dans ce cas, on enverra typiquement aucune requête (pas de CMR) ou un CMR indiquant NO_REQ en 519 - dans ce dernier les données associées au CMR NO_REQ sont écrites dans la structure partagée BWJnfo.
Dans des variantes, on pourra réutiliser les critères de déclenchement (d'activation) du test d'augmentation de débit du premier mode de réalisation.
Dans des variantes, la décision NO_REQ sera remplacée par une décision SET_RATE au débit actuel, de façon équivalente. On notera que pour les codecs AMR et AMR-WB le CMR est systématiquement présent dans chaque paquet, et on pourra remplacer le cas NO_REQ par le débit actuel.
A l’inverse (O à 516), lorsque le temps écoulé est supérieur au seuil, la décision « USE_RED » est prise pour demander un test d’augmentation du débit. Dans ce cas, à l’étape 517, une requête CMR étendue est préparée, en écrivant les données associées au CMR étendu dans la structure partagée BWJnfo.
La figure 5c décrit le fonctionnement de l'émetteur à la réception d'une requête CMR (normale ou étendue, autre que NO_REQ). On ne reprend pas ici les étapes restées identiques à l'émetteur en rapport à la figure 4c par souci de simplification.
Deux cas possibles se présentent lors de l'étape de vérification si un champ CMR a été reçu. Ainsi, si le champ CMR contient une requête d’adaptation du débit classique ou une requête CMR étendue, les paramètres de codage et d'émission sont fixés comme dans le premier mode de réalisation. Cependant, on pourra laisser l'émetteur décider du moment pour activer la redondance.
En rapport avec la figure 5c, à l’étape 521, on vérifie si un CMR classique de changement de débit a été reçu (updated à vrai et ”burst_uplink=-1) et si une étape de test par transmission de paquets de redondance est en cours (Nburst > 0). Dans la positive (O en 521), on arrête l’étape de test et on désactive la redondance en 522 comme décrit précédemment dans le premier mode de réalisation.
S’il n’y a pas d’étape de test en cours (N en 521) - si Nburst < 0 -, alors l’étape 523 est mise en œuvre.
A l’étape 523, on vérifie si une requête CMR étendu a été reçue (updated à vrai et burst_upiink>0 dans la structure CMR_Req). Dans la positive (O en 523), l’émetteur met en œuvre une étape de test d’augmentation de débit par la transmission de paquets redondants en 524 en fonction des informations contenues dans la structure CMR_Req. On fixe également le débit pour coder la prochaine trame en fonction du CMR reçu (en 525).
Dans des variantes l’algorithme ci-dessus peut être complété pour utiliser également le taux de perte de paquets. Cela rajoute des conditions supplémentaires pour en particulier baisser le débit en cas de pertes significatives (> = 10%) et/ou basculer sur un mode plus robuste (comme le channel-aware mode) s’il est inférieur ou égal au débit actuel, ou éviter la décision USERED en cas de pertes >= 10%.
Dans des variantes, on pourra utiliser une redondance partielle comme expliqué cidessus au lieu de la redondance 100% et on pourra également utiliser une redondance plus élevée, non limitée à 100% , par exemple une redondance à 200 ou 300%.
Dans des variantes, on pourra aussi utiliser des codecs audio ou vidéo qui ne disposent pas du mécanisme de signalisation CMR « dans la bande » (« inband » en anglais) tel que défini précédemment, dans ce cas on pourra utiliser des paquets RTCP pour indiquer des requêtes équivalentes au CMR utilisé dans les modes de réalisation de l’invention.
La figure 6 illustre un exemple matériel d’un terminal de communication TA comportant un dispositif récepteur et un dispositif émetteur apte à mettre en œuvre les procédés d’adaptation de débit et de détermination d’une requête d’adaptation selon les différents modes de réalisation de l’invention.
Le terminal TA comporte un espace de stockage 11, par exemple une mémoire MEM, une unité de traitement 10 comportant un processeur P, piloté par un programme informatique PG, stocké dans la mémoire 11 et mettant en œuvre les étapes du procédé de d’adaptation de débit et/ou du procédé de détermination d’une requête d’adaptation de débit au sens de l'invention, et notamment l’étape de test d’augmentation du débit de codage mis en œuvre par un dispositif émetteur par la transmission d’au moins un paquet redondant selon des paramètres de transmission choisis , lorsque ces instructions sont exécutées par le processeur P.
Typiquement, la description des figures 4a à 4c et des figures 5a à 5c reprend les étapes des algorithmes de tels programmes informatiques.
A l’initialisation, les instructions de code du programme PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d’être exécutées par le processeur P de l’unité de traitement 10. Les instructions de programme peuvent être mémorisées sur un support de stockage tel qu’une mémoire flash, un disque dur ou tout autre support de stockage non-transitoire.
Le terminal TA comporte un module de communication 12 apte à recevoir les paquets voix d’un réseau IP et à transmettre des paquets voix vers le réseau IP avec une redondance pour tester une augmentation de débit selon l’invention.
Le terminal comprend un dispositif émetteur comportant une unité de transmission de paquets apte à mettre en œuvre une étape de test d’augmentation du débit de codage par la transmission d’au moins un paquet redondant selon des paramètres de transmission choisis.
Le terminal comprend également un dispositif récepteur qui selon un mode de réalisation, comporte un module d’estimation apte à estimer une bande passante disponible et un module de construction et de transmission d’une requête d’adaptation, apte à construire et transmettre à un dispositif émetteur, une demande de mise en œuvre d’une 5 étape de test d’augmentation du débit de codage par la transmission de paquets redondants selon des paramètres de transmission choisis.
Ces modules sont tels que décrits en référence à la figure 3.
Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant 10 logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de 15 fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.)
Le terminal est par exemple un téléphone, un téléphone intelligent, une tablette, un ordinateur, une passerelle résidentielle ou un objet connecté.
ANNEXE 1 :
EVS_D(O à 8) = (9600, 13200, 16400, 24400, 32000, 48000, 64000, 96000, 12800)
Pour i=0 à 8:
S EVS_D(i) > B-(EVS_D(i+1 )-EVS_D(i))/2: Sortir de la boucle Pour
Fin S
Fin Pour
Si i = = 9: D = EVS_D(i-1)
Snon D = EVS_D(i)
Claims (15)
1. Procédé d’adaptation d’un débit de codage de signaux temps réels d’une session de communication temps réel entre des dispositifs émetteur et des dispositifs récepteur de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu’il comporte une étape de test d’augmentation du débit de codage au dispositif émetteur par la transmission (428) d’au moins un paquet redondant selon des paramètres de transmission choisis (423).
2. Procédé selon la revendication 1, dans lequel l’étape de test est mise en œuvre tant qu’aucune requête d’adaptation de débit n’est reçue d’un dispositif récepteur.
3. Procédé selon l’une des revendications 1 à 2, dans lequel l’étape de test est mise en œuvre après un changement de débit au débit discret inférieur.
4. Procédé selon l’une des revendications 1 à 3, dans lequel l’étape de test est mise en œuvre lorsqu’une temporisation a atteint un seuil depuis la dernière requête d’adaptation reçue d’un dispositif récepteur.
5. Procédé selon la revendication 4, dans lequel la temporisation pour déclencher le test d’augmentation est adaptée en fonction d’une information de bande passante disponible estimée au dispositif récepteur.
6. Procédé selon l’une des revendications 1 à 5, dans lequel l’étape de test est mise en œuvre en fonction d’une information d’évolution du débit de codage obtenue.
7. Procédé selon la revendication 6, dans lequel l’information d’évolution du débit de codage est obtenue à partir d’un historique de bande passante disponible estimée au dispositif récepteur.
8. Procédé selon la revendication 1, dans lequel l’étape de test est mise en œuvre après réception d’une requête d’adaptation reçue d’un dispositif récepteur et comportant une demande de transmission de paquets redondants selon des paramètres de transmission choisis.
9. Procédé selon la revendication 8, dans lequel la requête d’adaptation est déterminée au dispositif récepteur, en fonction d’une information d’évolution d’une bande passante disponible estimée.
10. Procédé de détermination d’une requête d’adaptation de débit de codage de signaux temps réels d’une session de communication temps réel entre des dispositifs émetteurs et des dispositifs récepteurs de terminaux de communication, un dispositif émetteur comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu’il comporte une étape d’estimation d’une bande passante disponible (511) pour un dispositif récepteur et de construction d’une requête d’adaptation (517) à transmettre à un dispositif émetteur et comportant une demande de mise en œuvre d’une étape de test d’augmentation du débit de codage par la transmission de paquets redondants selon des paramètres de transmission choisis.
11. Dispositif émetteur d’un terminal de communication apte à mettre en œuvre des sessions de communication temps réel et comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu’il comporte une unité de transmission de paquets (301,351) apte à mettre en œuvre une étape de test d’augmentation du débit de codage par la transmission d’au moins un paquet redondant selon des paramètres de transmission choisis.
12. Dispositif récepteur d’un terminal de communication apte à mettre en œuvre des sessions de communication temps réel et comportant un codeur multi-débits selon un ensemble de débits discrets, caractérisé en ce qu’il comporte un module d’estimation (304, 354) apte à estimer une bande passante disponible et un module de construction (302, 352) et de transmission d’une requête d’adaptation, apte à construire et transmettre à un dispositif émetteur, une demande de mise en œuvre d’une étape de test d’augmentation du débit de codage par la transmission de paquets redondants selon des paramètres de transmission choisis.
13. Terminal de communication comportant un dispositif émetteur selon la revendication 11 et/ou un dispositif récepteur selon la revendication 12.
14. Programme informatique comportant des instructions de code pour la mise en œuvre des étapes du procédé d’adaptation selon l’une des revendications 1 à 10 et /ou des étapes du procédé de détermination d’une requête selon la revendication 10, lorsque ces instructions sont exécutées par un processeur.
15. Support de stockage, lisible par un processeur, mémorisant un programme informatique comportant des instructions pour l’exécution du procédé d’adaptation selon l’une des revendications 1 à 10 et /ou des étapes du procédé de détermination d’une requête selon la revendication 10.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1855048A FR3082386A1 (fr) | 2018-06-08 | 2018-06-08 | Adaptation de debit d'une session de communication en voix sur ip |
| PCT/FR2019/051301 WO2019234338A1 (fr) | 2018-06-08 | 2019-06-03 | Adaptation de débit d'une session de communication en voix sur ip |
| EP19742839.4A EP3804243A1 (fr) | 2018-06-08 | 2019-06-03 | Adaptation de débit d'une session de communication en voix sur ip |
| US16/972,744 US11349898B2 (en) | 2018-06-08 | 2019-06-03 | Bitrate adaptation of a voice-over-IP communication session |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1855048A FR3082386A1 (fr) | 2018-06-08 | 2018-06-08 | Adaptation de debit d'une session de communication en voix sur ip |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3082386A1 true FR3082386A1 (fr) | 2019-12-13 |
Family
ID=63638002
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1855048A Withdrawn FR3082386A1 (fr) | 2018-06-08 | 2018-06-08 | Adaptation de debit d'une session de communication en voix sur ip |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US11349898B2 (fr) |
| EP (1) | EP3804243A1 (fr) |
| FR (1) | FR3082386A1 (fr) |
| WO (1) | WO2019234338A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN121001071A (zh) * | 2025-10-24 | 2025-11-21 | 国网湖南省电力有限公司信息通信分公司 | 电力应急抢修场景下电力终端的通信调控方法及系统 |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112997464B (zh) * | 2018-11-02 | 2023-09-05 | 苹果公司 | 发信号传送多媒体电话会话的编解码器模式通知 |
| US11824737B2 (en) * | 2019-09-09 | 2023-11-21 | Apple Inc. | Per-packet type packet loss management |
| CN112468758B (zh) * | 2019-09-09 | 2023-12-15 | 苹果公司 | 用于分组丢失管理的设备及方法 |
| CN113747202B (zh) * | 2021-08-05 | 2023-09-15 | 杭州网易智企科技有限公司 | 一种通过带宽估计发送数据的方法、装置、设备及介质 |
| KR20240164879A (ko) * | 2022-03-21 | 2024-11-21 | 퀄컴 인코포레이티드 | 번들링된 멀티레이트 피드백 오토인코더 |
| US20250016271A1 (en) * | 2022-03-30 | 2025-01-09 | Jio Platforms Limited | System and method for restricting bit rate for enhanced voice services (evs) |
| US20230318980A1 (en) * | 2022-04-04 | 2023-10-05 | Google Llc | Congestion control for low-latency interactive video streaming |
| CN117062143A (zh) * | 2022-05-05 | 2023-11-14 | 联发科技（新加坡）私人有限公司 | 调整语音帧比特率的方法及其装置 |
| CN118573574A (zh) * | 2023-02-28 | 2024-08-30 | 抖音视界有限公司 | 带宽估计方法、装置、电子设备及存储介质 |
| US20240323230A1 (en) * | 2023-03-24 | 2024-09-26 | International Business Machines Corporation | Reverse path feedback protocol for unidirectional networks |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2364541A1 (fr) * | 2008-11-11 | 2011-09-14 | Telefonaktiebolaget L M Ericsson (publ) | Sondage séquentiel pour diffusion en flux adaptative dans un réseau de communication par paquets |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008024056A1 (fr) * | 2006-08-21 | 2008-02-28 | Telefonaktiebolaget L M Ericsson (Publ) | Procédé et moyen d'adaptation d'une transmission de données codées |
| GB2454606C (en) * | 2009-02-02 | 2017-01-25 | Skype Ltd | Method of transmitting data in a communication system |
| WO2010111261A1 (fr) * | 2009-03-23 | 2010-09-30 | Azuki Systems, Inc. | Procédé et système d'adaptation dynamique de débit de lecture vidéo en transit |
| US9253233B2 (en) * | 2011-08-31 | 2016-02-02 | Qualcomm Incorporated | Switch signaling methods providing improved switching between representations for adaptive HTTP streaming |
| US20130195119A1 (en) * | 2011-10-14 | 2013-08-01 | Qualcomm Incorporated | Feedback channel for wireless display devices |
| US10382495B2 (en) * | 2015-09-25 | 2019-08-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and interworking network node for enabling bit rate adaption in media streaming |
| US10652594B2 (en) * | 2016-07-07 | 2020-05-12 | Time Warner Cable Enterprises Llc | Apparatus and methods for presentation of key frames in encrypted content |
| EP3625945B1 (fr) * | 2017-06-09 | 2021-09-15 | Huawei Technologies Co., Ltd. | Dispositif de communication émetteur et procédé de transmission de données vidéo |
-
2018
- 2018-06-08 FR FR1855048A patent/FR3082386A1/fr not_active Withdrawn
-
2019
- 2019-06-03 US US16/972,744 patent/US11349898B2/en active Active
- 2019-06-03 WO PCT/FR2019/051301 patent/WO2019234338A1/fr not_active Ceased
- 2019-06-03 EP EP19742839.4A patent/EP3804243A1/fr active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2364541A1 (fr) * | 2008-11-11 | 2011-09-14 | Telefonaktiebolaget L M Ericsson (publ) | Sondage séquentiel pour diffusion en flux adaptative dans un réseau de communication par paquets |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN121001071A (zh) * | 2025-10-24 | 2025-11-21 | 国网湖南省电力有限公司信息通信分公司 | 电力应急抢修场景下电力终端的通信调控方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20210258363A1 (en) | 2021-08-19 |
| US11349898B2 (en) | 2022-05-31 |
| EP3804243A1 (fr) | 2021-04-14 |
| WO2019234338A1 (fr) | 2019-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR3082386A1 (fr) | Adaptation de debit d'une session de communication en voix sur ip | |
| US11489781B2 (en) | Bandwidth management | |
| EP3692696B1 (fr) | Signalisation d'une requête d'adaptation d'une session de communication en voix sur ip | |
| US11323383B2 (en) | System, method, and device of RTP packet transmission for VoIP channels | |
| US20230171196A1 (en) | Bandwidth Management | |
| WO2008034851A1 (fr) | Procédé d'optimisation du contrôle du trafic dans un réseau de télécommunication par paquets | |
| FR2908576A1 (fr) | Procede,dispositif et application logicielle d'ordonnancement d'une transmission de paquets d'un flux de donnees | |
| FR2946820A1 (fr) | Procede de transmission de donnees et dispositif associe. | |
| EP1172958A1 (fr) | Système de communication, émetteur, mèthode de protection contre des erreurs de transmission | |
| EP1692824A1 (fr) | Procede et serveur de controle des flux de donnees dans un reseau de telecommunications | |
| FR2804813A1 (fr) | Procede de codage facilitant la restitution sonore des signaux de parole numerises transmis a un terminal d'abonne lors d'une communication telephonique par transmission de paquets et equipement mettant en oeuvre ce procede | |
| EP1427154B1 (fr) | Procédé de contrôle d'une mémoire tampon de paquets de données, et dispositif correspondant | |
| Assem | Assessing and improving the VVoIP call quality | |
| FR2941110A1 (fr) | Procede et dispositif de prediction d'un etat de pertes d'un reseau de communication | |
| FR3059185A1 (fr) | Procede et circuit de dectection de congestion | |
| WO2018220298A1 (fr) | Procédé de traitement d'une communication, et passerelle | |
| Herrero | Analytical model and comparative evaluation of application layer loss in the context of media encapsulation in wireless RTC | |
| US8351439B2 (en) | Techniques for measuring media statistics on forked media using a DSP | |
| Balan et al. | An experimental evaluation of voice-over-ip quality over the datagram congestion control protocol | |
| WO2025061714A1 (fr) | Format optimisé de transport de données audio d'une session de communication en voix sur ip | |
| Bhattacharya | Flow control of real-time unicast multimedia applications in best-effort networks | |
| WO2007101962A1 (fr) | Mécanisme de régulation multicouches du débit d'un flux de données tcp dans un réseau haut débit ethernet full duplex | |
| FR2908577A1 (fr) | Procede de transmission conformement a un protocole de transmission par rafales d'un contenu de donnees,produit programme d'ordinateur,moyen de stockage et dispositif correspondants. | |
| FR2978322A1 (fr) | Procede et dispositif de generation d'un signal porteur d'un code numerique |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20191213 |
|
| ST | Notification of lapse |
Effective date: 20210206 |