1、5)4 4 !PPENDICE )SECTEUR DE LA NORMALISATION 2EC DES TLCOMMUNICATIONSDE LUIT (11/95)!30%#43 . 2!58 $%3 3934 -%3$% 42!.3-)33)/. .5- 2)15%35)$% $% -)3% %. 0!15%43!PPENDICE ) LARecommandation 5)4 4 (Antrieurement Recommandation du CCITT)UNION INTERNATIONALE DES TLCOMMUNICATIONSAVANT-PROPOSLUIT-T (Secte
2、ur de la normalisation des tlcommunications) est un organe permanent de lUnion internationale destlcommunications (UIT). Il est charg de ltude des questions techniques, dexploitation et de tarification, et met cesujet des Recommandations en vue de la normalisation des tlcommunications lchelle mondia
3、le.La Confrence mondiale de normalisation des tlcommunications (CMNT), qui se runit tous les quatre ans, dtermineles thmes dtudes traiter par les Commissions dtudes de lUIT-T lesquelles laborent en retour des Recom-mandations sur ces thmes.Lapprobation des Recommandations par les Membres de lUIT-T s
4、effectue selon la procdure dfinie dans laRsolution n 1 de la CMNT (Helsinki, 1er-12 mars 1993).LAppendice I la Recommandation UIT-T G.764, que lon doit la Commission dtudes 15 (1993-1996) de lUIT-T, at approuv le 13 novembre 1995 selon la procdure dfinie dans la Rsolution n 1 de la CMNT._NOTEDans le
5、 prsent appendice, lexpression Administration est utilise pour dsigner de faon abrge aussi bien uneadministration de tlcommunications quune exploitation reconnue de tlcommunications. UIT 1996Droits de reproduction rservs. Aucune partie de cette publication ne peut tre reproduite ni utilise sous quel
6、que formeque ce soit et par aucun procd, lectronique ou mcanique, y compris la photocopie et les microfilms, sans laccordcrit de lUIT.Recommandation G.764 (11/95) iTABLE DES MATIRESRecommandation G.764 (11/95)PageI.1 Introduction 1I.2 Historique . 1I.3 Rcapitulatif des questions de conception 2I.4 R
7、econstitution des signaux de parole 2I.5 Compensation du retard 2I.5.1 Retard en aveugle 3I.5.2 Horodateur absolu. 3I.5.3 Horodateur relatif 4I.6 Robustesse aux erreurs . 4I.6.1 Sensibilit de la parole aux erreurs sur les bits . 5I.6.2 Calcul du contrle de redondance cyclique (CRC) sur une partie de
8、 la trame 5I.6.3 Calcul du contrle de redondance cyclique (CRC) sur des trames entires 5I.7 Gestion des encombrements . 5I.7.1 Gestion globale . 6I.7.2 Gestion locale 6I.8 Perte de paquets 8I.8.1 Cas de la parole. 8I.8.2 Cas des donnes transmises dans la bande vocale 9I.8.3 Stratgies de remplissage
9、(parole) 9I.9 Choix de la taille des paquets . 10I.9.1 Considrations relatives la transmission vocale. 10I.9.2 Considrations relatives aux erreurs sur les bits . 10I.9.3 Intgration de trafic. 10I.9.4 Recommandation G.764 11I.10 Questions relatives la compression 11I.10.1 Algorithmes de codage de la
10、parole 11I.10.2 Interpolation numrique de la parole 11I.11 Signalisation voie par voie 12I.12 Extensions. 12I.12.1 Tlcopie. 12I.12.2 Synchronisation audio/vido. 13I.12.3 Interface entre le rseau RTPC et les rseaux locaux . 13I.12.4 Extension de nouveaux algorithmes. 14I.13 Rcapitulatif 14Rfrences .
11、14Recommandation G.764 (11/95) 1Appendice I la Recommandation G.764Recommandation G.764 (11/95)Guide de mise en paquets(Genve, 1995)(Cet appendice ne fait pas partie intgrante de la prsente Recommandation)I.1 IntroductionCet appendice rcapitule les points de vue actuels de la mise en paquets de la p
12、arole au sein de la Commissiondtudes 15 de lUIT-T durant la priode dtudes 1992-1996 et au sein de la Commission dtudes XV du CCITTdurant la priode dtudes 1988-1992. Ces points de vue pourraient voluer dans le futur.Cet appendice ne couvre pas les aspects suivants:1) les diffrents traitements auxquel
13、s des paquets peuvent tre soumis lintrieur du rseau selon leuraffectation dans des classes de priorit; il est cependant en gnral admis que le rseau devrait donner lapriorit la parole par rapport aux donnes numriques pour rduire les retards et la variabilit du retard,et la sparation du trafic par sal
14、ves par rapport au trafic en temps rel;2) qualit de service pour diffrentes classes de trafic.Lobjet de cet appendice est le suivant: expliquer les diffrentes questions relatives la mise en paquets de la parole; fournir un aperu gnral des techniques et des considrations intervenant dans la transmiss
15、ion de laparole sous forme de paquets qui sont utilises dans la Recommandation G.764; diffuser les informations sur diffrents sujets intressant les concepteurs, les fabricants dquipements demise en paquets de la parole et les fournisseurs de service qui les utilisent.I.2 HistoriqueTraditionnellement
16、, les services de phonie ont t mis en exploitation dans le rseau tlphonique publiccommut (RTPC) galement appel rseau rgional ou WAN (wide area network) en mode circuit. Le dveloppementdes techniques de transmission par paquets par exemple X.25/X.75, Internet, la technologie des paquets large bande,l
17、e relais de trames et le mode transfert asynchrone (ATM) a stimul la recherche dans les techniques nouvelles detransmission de la parole.Les systmes de mise en paquets peuvent exploiter la nature non permanente de la transmission pour multiplexerdiffrents types de trafic (par exemple la voix, les do
18、nnes, la vido) de nombreux utilisateurs, afin quils puissentpartager de faon dynamique la largeur de bande de transmission et les ressources de commutation. La mise en paquetsfacilite lintgration de diffrents types de trafic pour permettre une utilisation plus efficace de la largeur de bande et desr
19、essources de commutation existantes. La mise en paquets permet davantage de souplesse que les mthodes du modecircuit, tant donn que len-tte du paquet contient les informations de gestion ncessaires qui dsignent par exemple letype de trafic et, le cas chant, lalgorithme de codage.Les travaux relatifs
20、 la mise en paquets de la parole ont commenc au sein du CCITT depuis le milieu de la priodedtudes 1984-1988 dans le Groupe de travail XVIII/8 et se sont poursuivis dans le Groupe de travail XV/2 pendant lapriode dtudes 1989-1992. Ils continuent actuellement au sein de lUIT-T pour les paquets large b
21、ande et les systmesen mode transfert asynchrone (ATM). Lobjectif est de fournir une base uniforme pour la mise en paquets de la parole,avec ou sans la compression de la parole et avec linterpolation numrique de la parole pour faciliterlinterfonctionnement des quipements en provenance de diffrents co
22、nstructeurs dans le domaine des applications detlcommunications.Les travaux au sein du CCITT ont conduit au protocole de mise en paquets de la parole contenu dans laRecommandation G.764 et ses extensions dans la Recommandation G.765. Pour la couche liaison de donnes, cesprotocoles sont compatibles a
23、vec les protocoles LAPD et LAPF du rseau RNIS spcifis respectivement dans lesRecommandations Q.921 et Q.922.2 Recommandation G.764 (11/95)I.3 Rcapitulatif des questions de conceptionEn utilisant comme rfrence la pile de protocole prvue dans linterconnexion de systmes ouverts (OSI), les principalesco
24、nsidrations entrant dans la conception dun protocole de mise en paquets de la parole sont les suivantes:1) Couche 1 (couche physique) La question est la suivante: linterface physique sera-t-elle ou nonconforme celle des rseaux de tlphone publics (G.703/G.704) ou celle dautres rseaux locaux, tellesqu
25、elles sont dfinies dans IEEE 802.2, 802.3 ou 802.9, etc.2) Couche 2 (couche de liaison) Certaines questions sont les suivantes:a) la couche logique sera-t-elle ou non compatible avec les protocoles du rseau RNIS (LAPD/LAPF)ou aura-t-elle la mme structure que celle des rseaux locaux;b) comment prendr
26、e en compte la perte de trames;c) la robustesse aux erreurs.3) Couche 3 (procdures destines prendre en compte le trafic de la voix numrise et celui des donnes debande vocale), les questions tant:a) la variabilit du retard pour les paquets de parole;b) le transport de la signalisation voie par voie.4
27、) Les questions relatives aux couches suprieures concernent le codeur de parole et le type de compressionutilis.Un protocole de mise en paquets de la parole rpond aux critres suivants: La parole doit tre reconstitue lextrmit de rception partir de paquets arrivant des intervallesirrguliers (ou dans l
28、e dsordre pour certaines architectures particulires). Le protocole doit tre rsistant aux erreurs sur la ligne. Ce protocole doit comprendre une mthode simple de rgulariser les encombrements dans le rseau. Il doit spcifier les procdures lextrmit de rception pour compenser la perte de paquets ou les r
29、etardsexcessifs. Il doit transmettre la signalisation voie par voie. Si linterpolation numrique de la parole est utilise pour supprimer les intervalles de silence, elle devraspcifier le niveau auquel le bruit sera rinject lextrmit de rception.I.4 Reconstitution des signaux de paroleAfin de permettre
30、 une bonne qualit de la parole, lextrmit de rception doit reconstituer une squence de parolecontinue et la restituer des intervalles rguliers malgr des instants darrive irrguliers des paquets. Cela comprenddeux aspects:1) le maintien de la synchronisation relative des informations lintrieur dune sal
31、ve de parole; et2) la compensation du retard.Dans la Recommandation G.764, un numro de squence des paquets est utilis pour le codage de la synchronisationrelative des informations lintrieur dune salve de parole. Le premier paquet dune salve de parole a toujours unnumro de squence gal 0; les paquets
32、subsquents dans la mme salve ont des numros compris entre 1 et 15, et lanumrotation recommence partir de 1. Les extrmits de rception utilisent le numro de squence des paquets pour:1) dterminer le premier paquet dune salve de parole; et2) dtecter une perte de paquets. La dtermination du premier paque
33、t est utilise pour la compensation duretard et peut tre ncessaire pour certains algorithmes de codage tels que celui dcrit dans laRecommandation G.728. La compensation du retard est dveloppe dans le paragraphe suivant.I.5 Compensation du retardLes retards dans la transmission par paquets comprennent
34、 deux composantes: un retard fixe et un retard variable 1. Leretard fixe provient de la propagation du signal sur les liaisons de transmission et des retards de traitement constants auxextrmits dorigine et darrive dans le rseau. La variation de retard de propagation sur un chemin donn est considreco
35、mme tant ngligeable.Recommandation G.764 (11/95) 3En ce qui concerne la mise en paquets de la parole, les retards de traitement constants comprennent les modules suivants:1) le retard de mise en paquets durant lequel les chantillons de parole sont mis en mmoire tampon avant lapoursuite du traitement
36、;2) le temps de maintien du dtecteur de parole si linterpolation numrique de la parole est utilise afin desupprimer les intervalles de silence 2;3) le retard algorithmique de bout en bout en raison du codeur et du dcodeur de parole ce retard dpendde lalgorithme de codage; il est par exemple de 125 m
37、 s pour le codage MIC, de 250 m s pour lesalgorithmes du codage modulation par impulsions et codage diffrentiel adaptatif (MICDA) contenusdans les Recommandations G.726 et G.727, alors quil est infrieur 2 ms pour lalgorithme de laprdiction linaire faible retard avec excitation par code (LD-CELP) (lo
38、w delay code excited linearpredictor) contenu dans la Recommandation G.728;4) tout retard supplmentaire lextrmit de terminaison pour liminer la gigue provenant de la variabilitdu retard ce retard supplmentaire est appel reconstitution.Les retards variables proviennent essentiellement de la mise en f
39、iles dattente des paquets et du traitement associ. Ilsdpendent des caractristiques dacheminement de chaque paquet, comme par exemple le nombre de bonds detransmission (nuds), le type et la vitesse de chaque lien et lintensit de trafic.Le trafic vocal exige un retard faible et uniforme. La Recommanda
40、tion G.114 (1993) explique leffet des retards de bouten bout sur la qualit de la conversation. Les variations de retard qui peuvent tre acceptables pour le trafic numriquedes donnes, ont gnralement une incidence sur les pauses entre les mots et les syllabes et ont des consquencesfcheuses pour le mod
41、e dialogu. Les donnes disponibles indiquent que les variations dans les salves de la paroledevraient tre infrieures 200 ms afin dviter la dgradation subjective de la qualit audio. Dans des applications tellesque la visiophonie o des informations de type audio et vido simultanment sont transmises et
42、doivent restersynchronises, leffet du retard variable sur cette synchronisation doit galement tre pris en compte.Plusieurs mthodes permettent de masquer la variabilit du retard dans le rseau. Ces techniques comprennent:1) le retard en aveugle;2) lhorodateur absolu; et3) lhorodateur relatif.Ces mthod
43、es ont pour effet daugmenter le retard rel dans la mise en mmoire tampon et, par consquent, le retard totalde bout en bout.I.5.1 Retard en aveugleDans la mthode du retard en aveugle, un retard constant est toujours ajout dans une mmoire tampon lextrmitdarrive du premier paquet dune salve de parole.
44、Ce retard correspond au retard variable maximal attendu.Lavantage de lalgorithme du retard en aveugle rside dans sa simplicit qui lui donne un avantage quand la paroletransmise est telle que les retards variables sont de lordre dune fraction de milliseconde (par exemple dans les rseauxlocaux ou les
45、rseaux large bande 150 Mbit/s). Dans de tels cas, un retard constant de reconstitution de lordre de10 ms sera appropri pour liminer la gigue de retard 3.Sur les connexions de transmission longues dans le rseau RTPC, lalgorithme peut provoquer un retard trop importantde sorte que le retard total de b
46、out en bout serait suprieur aux caractristiques limites applicables aux retards dans lerseau qui sont spcifies dans la Recommandation G.114. Par exemple, si le premier paquet a dj subi un retard dansle cas de variation le plus dfavorable, le retard total variable devant tre ajout sera gal deux fois
47、la valeur du retardcorrespondant au cas le plus dfavorable 1. Etant donn que cette mthode ne masque pas compltement la variabilitdu retard, les pauses entre les mots peuvent tre ingales, ce qui peut dgrader la qualit subjective de la parole. Le traficde bande vocale, qui inclut la tlcopie dmodule, p
48、eut tre perturb; les retards dont la dure totale est suprieure 500 ms peuvent entraner des dconnexions prmatures dappels partir de tlcopieurs, en particulier en prsencedcho 4.I.5.2 Horodateur absoluCeci est la mthode utilise dans les rseaux de type datagramme. Len-tte du paquet comprend un champ pour unho
