Présentation du retard dans les réseaux voix par paquets
Contenu
Introduction
Quand vous concevez des réseaux qui transportent la voix sur des infrastructures de paquets, de trames ou de cellules, il est important de comprendre et d'expliquer les composants de délai dans le réseau. Une prise en compte correcte de tous les délais potentiels permet de s'assurer que les performances globales du réseau sont acceptables. La qualité vocale globale dépend de nombreux facteurs, notamment l'algorithme de compression, les erreurs et la perte de trame, l'annulation d'écho et le délai. Cet article explique les origines du délai quand vous utilisez des routeurs/passerelles Cisco sur des réseaux de paquets. Bien que les exemples soient adaptés à Frame Relay, les concepts s'appliquent également aux réseaux Voix sur IP (VoIP) et Voix sur ATM (VoATM).
Flux vocal de base
Le flux d'un circuit vocal compressé est indiqué dans ce schéma. Le signal analogique du téléphone est chiffré en signaux PCM (Pulse Code Modulation) par le codeur-décodeur (codec) vocal. Les échantillons PCM sont ensuite passés à l'algorithme de compression qui comprime la voix dans un format de paquet pour la transmission sur le WAN. De l'autre côté du nuage, les mêmes fonctions sont effectués dans l'ordre inverse. Le flux entier est indiqué à la Figure 2-1.
Figure 2-1 Flux vocal de bout en bout 
Selon la façon dont le réseau est configuré, le routeur/passerelle peut assurer les fonctions de codecs et de compression ou seulement l'une d'entre elles. Par exemple, si un système voix analogique est utilisé, le routeur/passerelle remplit la fonction CODEC et la fonction de compression comme indiqué à la Figure 2-2.
Figure 2-2 Fonction de codec dans le routeur/passerelle 
Si un PBX numérique est utilisé, le PBX remplit la fonction de codec et le routeur traite les échantillons PCM qui lui sont passés par le PBX. Un exemple est fourni à la Figure 2-3.
Figure 2-3 Fonction de codec dans le PBX 
Fonctionnement de la compression vocale
Les algorithmes de compression à complexité élevée utilisés dans le routeur/passerelle Cisco analysent un bloc d'échantillons PCM fourni par les codecs de voix. Ces blocs varient en longueur en fonction du codeur. Par exemple, la taille de bloc de base utilisée par un algorithme G.729 est de 10 ms, tandis que la taille de bloc de base utilisée par les algorithmes G.723.1 est de 30 ms. Un exemple de fonctionnement d'un système de compression G.729 est fourni par la Figure 3-1.
Figure 3-1 Compression vocale 
Le flux vocal analogique est chiffré en échantillons PCM et fourni à l'algorithme de compression en incréments de 10 ms. La lecture anticipée est discutée dans Délai algorithmique.
Normes pour les limites de délai
L'Union internationale des télécommunications (ITU) prend en compte le délai sur le réseau pour les applications vocales dans la Recommandation G.114. Cette recommandation définit trois bandes de délai à sens unique comme indiqué dans le Tableau 4.1.
Tableau 4.1 Spécifications de délai
| Plage en millisecondes | Description |
|---|---|
| 0-150 | Acceptable pour la plupart des applications utilisateur. |
| 150-400 | Acceptable à condition que les administrateurs soient conscients du délai de transmission et de l'impact qu'il a sur la qualité de transmission des applications utilisateur. |
| Au-dessus de 400 | Inacceptable pour la planification réseau générale. Cependant, on reconnaît que dans quelques cas exceptionnels cette limite est dépassée. |
Remarque : Ces recommandations concernent les connexions avec écho correctement contrôlées. Ceci implique que des annuleurs d'écho sont utilisés. Des annuleurs d'écho sont requis quand le délai à sens unique dépasse 25 ms (G.131).
Ces recommandations sont destinées principalement aux administrations de télécommunication nationales. Par conséquent, elles sont plus rigoureuses que lorsqu'elles sont normalement appliquées aux réseaux vocaux privés. Quand l'emplacement et les besoins professionnels des utilisateurs finaux sont bien connus du concepteur réseau, un délai plus élevé peut être acceptable. Pour les réseaux privés, un délai de 200 ms est un objectif raisonnable et la limite est de 250 ms. Tous les réseaux doivent être conçus de sorte que le délai de connexion vocale prévu maximum soit connu et minimisé.
Sources de délai
Il y a deux types distincts de délai : fixes et variables.
-
Les composants de délai fixe s'ajoutent directement au délai global sur la connexion.
-
Les délais variables résultent des délais de mise en file d'attente dans les mémoires tampon de ligne réseau de sortie sur le port série connecté au WAN. Ces mémoires tampon créent des délais variables, appelés gigue, sur le réseau. Les délais variables sont gérés par le tampon d'élimination de gigue au niveau du routeur/passerelle récepteur. Le tampon de dégivrage est décrit dans la section Délai de dégivrage (Δn) de ce document.
La Figure 5-1 identifie toutes les sources de délai fixes et variables dans le réseau. Chaque source est décrite en détail dans ce document.
Figure 5-1 : Sources de délai 
Délai de codeur (traitement)
Le délai de codeur est le temps pris par le processeur de signaux numériques (DSP) pour compresser un bloc d'échantillons PCM. On parle également de délai de traitement (χ n). Ce délai varie avec en fonction du codeur vocal utilisé et de la vitesse du processeur. Par exemple, les algorithmes ACELP (Algebraic Code Excited Linear Prediction) analysent un bloc de 10 ms d'échantillons PCM, puis les compresse.
La durée de compression pour un processus CS-ACELP (Conjugate Structure Algebraic Code Excited Linear Prediction) va de 2,5 ms à 10 ms en fonction du chargement du processeur DSP. Si le DSP est entièrement chargé avec quatre canaux vocaux, le délai de codeur est de 10 ms. Si le DSP est chargé avec un seul canal vocal, le délai de codeur est de 2,5 ms. À des fins de conception, utilisez la durée la plus défavorable (10 ms).
La durée de décompression est approximativement égale à dix pour cent de la durée de compression pour chaque bloc. Cependant, la durée de décompression est proportionnelle au nombre d'échantillons par trame en raison de la présence de plusieurs échantillons. En conséquence, la durée de décompression la plus défavorable pour une trame avec trois échantillons est de 3 x 1 ms, soit 3 ms. Habituellement, deux ou trois blocs de sortie G.729 compressés sont mis dans une trame tandis qu'un échantillon de sortie G.723.1 compressé est envoyé dans une seule trame.
Les délais de codeur les plus favorables et les plus défavorables sont indiqués dans le Tableau 5.1.
Tableau 5 .1 Délais de traitement les plus favorables et les plus défavorables
| Codeur | Taux | Bloc d'échantillonnage requis | Meilleur délai de codeur | Pire délai de codeur |
|---|---|---|---|---|
| ADPCM, G.726 | 32 Kbps | 10 ms | 2.5 ms | 10 ms |
| CS-ACELP, G.729A | 8,0 Kbps | 10 ms | 2.5 ms | 10 ms |
| MP-MLQ, G.723.1 | 6,3 Kbps | 30 ms | 5 ms | 20 ms |
| MP-ACELP, G.723.1 | 5,3 Kbps | 30 ms | 5 ms | 20 ms |
Délai algorithmique
L'algorithme de compression se base sur des caractéristiques vocales connues pour traiter correctement le bloc d'échantillonnage N. L'algorithme doit avoir connaissance de ce qui est dans le bloc N+1 afin de reproduire exactement le bloc d'échantillonnage N. Cette lecture anticipée, qui est en fait un délai supplémentaire, est appelée délai algorithmique. Ceci augmente effectivement la longueur du bloc de compression.
Ceci se produit de manière répétée, de sorte que le bloc N+1 examine le bloc N+2, et ainsi de suite. L'effet net est un ajout de 5 ms au délai global sur la liaison. Cela signifie que le temps total requis pour traiter un bloc d'informations est de 10 ms avec un facteur supplémentaire constant de 5 ms. Voir la Figure 3-1 : Compression vocale.
-
Le délai algorithmique pour les codeurs G.726 est de 0 ms.
-
Le délai algorithmique pour les codeurs G.729 est de 5 ms.
-
Le délai algorithmique pour les codeurs G.723.1 est de 7,5 ms.
Pour les exemples dans le reste de ce document, supposez une compression G.729 avec une charge utile de 30 ms/30 octets. Afin de faciliter la conception et d'adopter une approche prudente, les tableaux fournis dans le reste de ce document assument un délai de codeur le plus défavorable. Le délai de codeur, le délai de décompression et le délai algorithmique sont regroupés en un facteur appelé délai de codeur.
L'équation utilisée pour générer le paramètre de délai de codeur consolidé est :
Équation 1 : Paramètre de délai de codeur consolidé 
Le délai de codeur consolidé pour G.729 qui est utilisé pour le reste de ce document est :
Délai de compression le plus défavorable par bloc : 10 ms
Délai de décompression par bloc x 3 blocs 3 ms
Délai algorithmique 5 ms---------------------------
Total (χ) 18 ms
Délai de mise en paquets
Le délai de mise en paquets (π n) est le temps nécessaire pour remplir une charge utile de paquet avec un langage codé/compressé. Ce délai dépend de la longueur du bloc d'échantillonnage requise par le vocodeur et du nombre de blocs placés dans une trame. Le délai de mise en paquets peut également être appelé délai d'accumulation, car les échantillons vocaux s'accumulent dans une mémoire tampon avant d'être libérés.
En règle générale, vous devez essayer d'obtenir un délai de mise en paquets inférieur ou égal à 30 ms. Dans le routeur/passerelle Cisco, vous devez utiliser les figures du Tableau 5.2 basées sur la taille de charge utile configurée :
Tableau 5.2 : Mise en paquets commune
| Codeur | Taille de charge utile (octets) | Délai de mise en paquets (ms) | Taille de charge utile (octets) | Délai de mise en paquets (ms) | |
|---|---|---|---|---|---|
| PCM, G.711 | 64 Kbps | 160 | 20 | 240 | 30 |
| ADPCM, G.726 | 32 Kbps | 80 | 20 | 120 | 30 |
| CS-ACELP, G.729 | 8,0 Kbps | 20 | 20 | 30 | 30 |
| MP-MLQ, G.723.1 | 6,3 Kbps | 24 | 24 | 60 | 48 |
| MP-ACELP, G.723.1 | 5,3 Kbps | 20 | 30 | 60 | 60 |
Vous devez équilibrer le délai de mise en paquets et la charge CPU. Plus le délai est bas, plus la fréquence de trame est élevée et plus la charge sur le CPU est élevée. Sur certaines plates-formes plus anciennes, des charges utiles de 20 ms peuvent constituer une charge trop élevée pour le CPU principal.
Délai de pipeline dans le processus de mise en paquets
Bien que chaque échantillon vocal subisse un délai algorithmique et un délai de mise en paquets, en réalité les processus se chevauchent et il y a un effet net bénéfique résultant de cette canalisation. Prenez l'exemple de la Figure 2-1.
Figure 5-2 : Canalisation et mise en paquets 
La ligne supérieure de la figure représente un échantillon de forme d'onde vocale. La deuxième ligne est une échelle de temps par incréments de 10 ms. À T0, l'algorithme CS-ACELP commence à prélever des échantillons PCM du codec. À T1, l'algorithme a collecté son premier bloc d'échantillons de 10 ms et commence à le compresser. À T2, le premier bloc d'échantillons a été compressé. Dans cet exemple, le temps de compression est de 2,5 ms, comme indiqué par T2-T1.
Les deuxième et troisième blocs sont collectés à T3 et T4. Le troisième bloc est compressé à T5. Le paquet est assemblé et envoyé (supposé instantané) à T6. En raison de la nature pipelinée des processus de compression et de conditionnement, le délai entre le début du processus et l'envoi de la trame vocale est T6-T0, soit environ 32,5 ms.
À des fins d'illustration, cet exemple est basé sur le délai le plus favorable. Si le délai le plus défavorable est utilisé, ce chiffre est de 40 ms, 10 ms pour le délai de codeur et 30 ms pour le délai de mise en paquets.
Notez que ces exemples oublient d'inclure le délai algorithmique.
Délai de sérialisation
Le délai de sérialisation (γ n) est le délai fixe requis pour horloge une trame vocale ou de données sur l'interface réseau. Il est lié directement à la fréquence d'horloge sur la ligne réseau. À des fréquences d'horloge basses et pour de petites tailles de trame, l'indicateur supplémentaire requis pour séparer les trames est significatif.
Le Tableau 5.3 montre le délai de sérialisation requis pour différentes tailles de trame à différentes vitesses de ligne. Ce tableau utilise la taille de trame totale, et non la taille de charge utile, pour le calcul.
Tableau 5.3 : Délai de sérialisation en millisecondes pour différentes tailles de trame
| Taille de trame (octets) | Vitesse de la ligne (Kbps) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 19.2 | 56 | 64 | 128 | 256 | 384 | 512 | 768 | 1024 | 1544 | 2048 | |
| 38 | 15.83 | 5.43 | 4.75 | 2.38 | 1.19 | 0.79 | 0.59 | 0.40 | 0.30 | 0.20 | 0.15 |
| 48 | 20.00 | 6.86 | 6.00 | 3.00 | 1.50 | 1.00 | 0.75 | 0.50 | 0,38 | 0.25 | 0.19 |
| 64 | 26.67 | 9.14 | 8.00 | 4.00 | 2.00 | 1.33 | 1.00 | 0.67 | 0.50 | 0.33 | 0.25 |
| 128 | 53.33 | 18.29 | 16.00 | 8.00 | 4.00 | 2.67 | 2.00 | 1.33 | 1.00 | 0.66 | 0.50 |
| 256 | 106.67 | 36.57 | 32.00 | 16.00 | 8.00 | 5.33 | 4.00 | 2.67 | 2.00 | 1.33 | 1.00 |
| 512 | 213.33 | 73.14 | 64.00 | 32.00 | 16.00 | 10.67 | 8.00 | 5.33 | 4.00 | 2.65 | 2.00 |
| 1024 | 426.67 | 149.29 | 128.00 | 64.00 | 32.00 | 21.33 | 16.00 | 10.67 | 8.00 | 5.31 | 4.00 |
| 1500 | 625.00 | 214.29 | 187.50 | 93.75 | 46.88 | 31.25 | 23.44 | 15.63 | 11.72 | 7.77 | 5.86 |
| 2048 | 853.33 | 292.57 | 256.00 | 128.00 | 64.00 | 42.67 | 32.00 | 21.33 | 16.00 | 10.61 | 8.00 |
Dans le tableau, sur une ligne à 64 Kbits/s, une trame vocale CS-ACELP avec une longueur de 38 octets (37+1 indicateur) a un délai de sérialisation de 4,75 ms.
Remarque : Délai de sérialisation d'une cellule ATM de 53 octets (T1 : 0,275 ms, E1 : 0,207 ms) est négligeable en raison de la vitesse de ligne élevée et de la faible taille de cellule.
Délai de mise en file d'attente/mise en mémoire tampon
Une fois que la charge utile de voix compressée est construite, un en-tête est ajouté et la trame est mise en file d'attente pour la transmission sur la connexion réseau. La voix doit avoir la priorité absolue dans le routeur/passerelle. Par conséquent, une trame vocale doit attendre uniquement une trame de données déjà en lecture ou d'autres trames vocales qui se trouvent devant elle. La trame vocale patiente pendant le délai de sérialisation de toutes les trames précédentes dans la file d'attente de sortie. Le délai de mise en file d'attente (ßn) est un délai variable et dépend de la vitesse de liaison et de l'état de la file d'attente. Il y a des éléments aléatoires associés au délai de mise en file d'attente.
Par exemple, supposez que vous êtes sur une ligne 64 Kbits/s et que vous êtes en file d'attente derrière une trame de données (48 octets) et une trame vocale (42 octets). Puisqu'il y a une nature aléatoire quant à la quantité de la trame de 48 octets qui a été lue, vous pouvez sans risque supposer, en moyenne, que la moitié de la trame de données a été lue. Sur la base des données de la table de sérialisation, votre composant de trame de données est 6 ms * 0,5 = 3 ms. Quand vous ajoutez la durée d'une autre trame vocale en avant dans la file d'attente (5,25 ms), cela donne un délai de mise en file d'attente total de 8,25 ms.
La caractérisation du délai de mise en file d'attente incombe à l'ingénieur réseau. Généralement, on doit concevoir pour le scénario le plus défavorable, puis ajuster les performances une fois le réseau installé. Plus le nombre de lignes vocales disponibles aux utilisateurs est élevé, plus est élevée la probabilité que le paquet de voix moyen attend dans la file d'attente. La trame vocale, en raison de la structure prioritaire, n'attend jamais derrière plus d'une trame de données.
Délai de commutation réseau
Le Frame Relay ou le réseau ATM public qui interconnecte les emplacements de point de terminaison est la source des délais les plus élevés pour les connexions vocales. Les délais de commutation réseau (ω n) sont également les plus difficiles à quantifier.
Si la connectivité étendue est fournie par un équipement Cisco ou un autre réseau privé, il est possible d'identifier les composants individuels du délai. Généralement, les composants fixes proviennent des délais de propagation sur les segments du réseau et les délais variables proviennent des délais de mise en file d'attente des trames dans et hors des commutateurs intermédiaires. Afin d'estimer le délai de propagation, une estimation courante de 10 microsecondes/mille ou 6 microsecondes/km (G.114) est souvent utilisée. Cependant, l'équipement multiplex intermédiaire, le backhauling, les liaisons par micro-ondes et d'autres facteurs des réseaux de transport créent de nombreuses exceptions.
L'autre élément important du délai provient de la mise en file d'attente dans le réseau étendu. Dans un réseau privé, il peut être possible de mesurer les délais de mise en file d'attente existants ou d'estimer un budget par-saut dans le réseau étendu.
Les délais typiques de porteuse pour les connexions de relais de trame des USA sont de 40 ms fixes et 25 ms variable pour un délai le plus défavorable de 65 ms. Pour des raisons de simplicité, dans les exemples 6-1, 6-2 et 6-3, tous les délais de sérialisation à vitesse réduite dans le délai fixe de 40 ms sont inclus.
Il s'agit de chiffres publiés par les opérateurs de relais de trame des USA, afin de couvrir la couverture « n'importe où à n'importe où » aux États-Unis. On doit s'attendre à ce que deux emplacements géographiquement plus proches que le cas le plus défavorable aient de meilleures performances en matière de délai, mais les porteuses documentent normalement uniquement le cas le plus défavorable.
Les opérateurs de relais de trame offrent parfois des services de première classe. Ces services sont habituellement pour le trafic vocal ou SNA (Systems Network Architecture), où le délai sur le réseau est garanti et inférieur au niveau de service standard. Par exemple, un opérateur américain a récemment annoncé un tel service avec une limite de délai globale de 50 ms, plutôt que les 65 ms du service standard.
Délai d'élimination de gigue
La parole étant un service de débit binaire constant, la gigue issue de tous les délais variables doit être supprimée avant que le signal ne quitte le réseau. Dans les routeurs/passerelles Cisco, cela se fait avec un tampon de dégivrage (Δnn) au niveau du routeur/passerelle d'extrémité (de réception). Le tampon d'élimination de gigue transforme le délai variable en délai fixe. Il conserve le premier échantillon reçu pendant un laps de temps avant de le lire. Cette période de stockage porte le nom de délai de lecture initial.
Figure 5- 3 : Opération de tampon d'élimination de gigue 
Il est essentiel de gérer correctement le tampon d'élimination de gigue. Si les échantillons ne sont pas conservés suffisamment longtemps, les variations de délai peuvent potentiellement entraîner une sous-exécution de la mémoire tampon et provoquer des intervalles dans la parole. Si l'échantillon est conservé trop longtemps, la mémoire tampon peut déborder et les paquets abandonnés peuvent là encore provoquer des intervalles dans la parole. Pour finir, si les paquets sont conservés trop longtemps, le délai global sur la connexion peut s'élever jusqu'à un niveau inacceptable.
Le délai de lecture initial optimal pour le tampon d'élimination de gigue est égal au délai variable total le long de la connexion. Ceci est indiqué à la Figure 5-4.
Remarque : Les tampons de dégivrage peuvent être adaptatifs, mais le délai maximal est fixe. Quand des mémoires tampon adaptatives sont configurées, le délai devient une valeur variable. Cependant, le délai maximal peut être utilisé comme cas le plus défavorable à des fins de conception.
Pour plus d'informations sur les mémoires tampon adaptatives, voir Améliorations du délai de lecture pour la voix sur IP.
Figure 5-4 : Délai variable et le tampon d'élimination de gigue 
Le délai de lecture initial est configurable. La profondeur maximale de la mémoire tampon avant qu'elle déborde est normalement définie à 1,5 ou 2 fois cette valeur.
Si la valeur nominale de délai de 40 ms est utilisée, le premier échantillon vocal reçu quand le tampon d'élimination de gigue est vide est conservé pendant 40 ms avant d'être lu. Ceci implique qu'un paquet ultérieur reçu en provenance du réseau peut être retardé de 40 ms (par rapport au premier paquet) sans aucune perte de continuité de voix. S'il est retardé plus de 40 ms, le tampon d'élimination de gigue se vide et le paquet suivant reçu est conservé pendant 40 ms avant sa lecture afin de réinitialiser la mémoire tampon. Ceci a comme conséquence un intervalle dans la voix lue pendant environ 40 ms.
La contribution réelle du tampon d'élimination de gigue en termes de délai est le délai de lecture initial du tampon d'élimination de gigue plus la durée effective pendant laquelle le premier paquet a été mis en mémoire tampon dans le réseau. Le pire des cas est deux fois le délai initial de tampon d'élimination de gigue (l'hypothèse est que le premier paquet sur le réseau a subi uniquement un délai de mise en mémoire tampon minimal). Dans la pratique, sur plusieurs sauts entre commutateurs réseau, il est probablement inutile d'assumer le pire cas. Les calculs des exemples fournis dans le reste de ce document augmentent le délai de lecture initial par un facteur de 1,5 pour tenir compte de cet effet.
Remarque : Dans le routeur/passerelle de réception, il y a un retard par la fonction de décompression. Cependant, ceci est pris en considération par un regroupement avec le délai de traitement de compression, comme discuté précédemment.
Créer le budget de délai
La limite généralement acceptable pour un délai de connexion vocale de bonne qualité est de 200 ms dans une direction (ou 250 ms comme limite). Lorsque les délais dépassent cette limite, les locuteurs et auditeurs ne sont plus synchronisés et souvent ils parlent en même temps, ou chacun des deux attend que l'autre parle. Cette condition porte généralement le nom de superposition de locuteur. Bien que la qualité vocale globale soit acceptable, les utilisateurs estiment parfois la nature artificielle de la conversation trop insupportable. On peut observer la superposition de locuteur sur les appels téléphoniques internationaux transmis sur des connexions satellites (le délai du satellite est de l'ordre de 500 ms, 250 ms dans un sens et 250 ms dans l'autre).
Ces exemples montrent diverses configurations de réseau et les délais que le concepteur réseau doit prendre en considération.
Connexion à un seul saut
Figure 6 - 1 : Exemple de connexion à un seul saut 
À partir de ce chiffre, une connexion ordinaire à un seul saut sur une connexion de relais de trame publique peut avoir le budget de délai indiqué au Tableau 6.1.
Tableau 6.1 : Calcul de délai de saut unique
| Type de délai | Fixe (ms) | Variable (ms) |
|---|---|---|
| Délai de codeur,1 | 18 | |
| Retard de la mise en paquets, 1 | 30 | |
| Mise en file d'attente/mise en mémoire tampon, ß1 | 8 | |
| Délai de sérialisation (64 kbits/s), σ1 | 5 | |
| Délai réseau (trame publique), ω1 | 40 | 25 |
| Délai tampon de dégivrage, Δ1 | 45 | |
| Totaux | 138 | 33 |
Remarque : Étant donné que le délai de mise en file d'attente et le composant variable du délai réseau sont déjà pris en compte dans les calculs de tampon de dégivrage, le délai total n'est en fait que la somme de tous les délais fixes. Dans ce cas, le délai total est de 138 ms.
Deux sauts sur un réseau public avec un C7200 qui agit en tant que commutateur en cascade
Figure 6 - 2 : Exemple de réseau public à deux sauts avec routeur/passerelle en cascade 
Prenez maintenant une connexion filiale à filiale dans un réseau à topologie en étoile où le C7200 du site du siège social gère l'appel à la filiale de destination. Dans ce cas, le signal reste au format compressé dans le C7200 central. Ceci a comme conséquence une économie de budget de délai considérable dans l'exemple suivant, Connexion à deux sauts sur un réseau public avec commutateur PBX en cascade.
Tableau 6.2 : Calcul de délai de réseau public à deux sauts avec routeur/passerelle en cascade
| Type de délai | Fixe (ms) | Variable (ms) |
|---|---|---|
| Délai de codeur,1 | 18 | |
| Retard de la mise en paquets, 1 | 30 | |
| Mise en file d'attente/mise en mémoire tampon, ß1 | 8 | |
| Délai de sérialisation (64 kbits/s), σ1 | 5 | |
| Délai réseau (trame publique), ω1 | 40 | 25 |
| Délai en tandem dans MC3810, λ1 | 1 | |
| Mise en file d'attente/mise en mémoire tampon, ß2 | 0,2 | |
| Délai de sérialisation (2 Mbits/s), σ2 | 0,1 | |
| Délai réseau (trame publique), ω2 | 40 | 25 |
| Délai tampon de dégivrage, Δ1 | 75 | |
| Totaux | 209.1 | 58.2 |
Remarque : Étant donné que le délai de mise en file d'attente et le composant variable du délai réseau sont déjà pris en compte dans les calculs de tampon de dégivrage, le délai total n'est en fait que la somme de tous les délais fixes. Dans ce cas, le délai total est de 209.1 ms.
Connexion à deux sauts sur un réseau public avec un commutateur PBX en cascade
Figure 6-3 : Exemple de réseau public à deux sauts avec commutateur PBX en cascade 
Prenez une connexion de filiale à filiale dans un réseau siège social à filiale où le C7200 du site du siège social passe la connexion au PBX du siège social pour la commutation. Ici, le signal vocal doit être décompressé et la gigue éliminée, puis recompressé avec une deuxième élimination de gigue. Ceci a comme conséquence des délais supplémentaires par rapport à l'exemple précédent. Par ailleurs, les deux cycles de compression CS-ACELP réduisent la qualité vocale (voir Effets des cycles de compression multiples).
Tableau 6.3 : Calcul de délai de réseau public à deux sauts avec commutateur PBX en cascade
| Type de délai | Fixe (ms) | Variable (ms) |
|---|---|---|
| Délai de codeur,1 | 18 | |
| Retard de la mise en paquets, 1 | 30 | |
| Mise en file d'attente/mise en mémoire tampon, ß1 | 8 | |
| Délai de sérialisation (64 kbits/s), σ1 | 5 | |
| Délai réseau (trame publique), ω1 | 40 | 25 |
| Délai tampon de dégivrage, Δ1 | 40 | |
| Délai de codeur,2 | 15 | |
| Retard de la mise en paquets, 2 | 30 | |
| Mise en file d'attente/mise en mémoire tampon, ß2 | 0,1 | |
| Délai de sérialisation (2 Mbits/s), σ2 | 0,1 | |
| Délai réseau (trame publique), ω2 | 40 | 25 |
| Délai tampon de dégivrage, Δ2 | 40 | |
| Totaux | 258.1 | 58.1 |
Remarque : Étant donné que le délai de mise en file d'attente et le composant variable du délai réseau sont déjà pris en compte dans les calculs de tampon de dégivrage, le délai total n'est en fait que la somme de tous les délais fixes plus le délai de tampon de dégivrage. Dans ce cas, le délai total est de 258.1 ms.
Si vous utilisez le PBX au site central comme commutateur, cela augmente le délai de connexion à sens unique de 206 ms à 255 ms. Ce chiffre est proche des limites ITU pour le délai à sens unique. Ce type de configuration de réseau exige que l'ingénieur prenne bien soin de minimiser le délai.
Le pire des cas est assumé pour le délai variable (bien que les deux tronçons sur le réseau public n'observent pas des délais maximaux simultanément). Si vous effectuez des hypothèses plus optimistes pour les délais variables, cela améliore seulement faiblement la situation. Cependant, avec de meilleures informations sur les délais fixes et variables dans le réseau à relais de trame de la porteuse, le délai calculé peut être réduit. On peut s'attendre à ce que les connexions locales (par exemple inter-régionales) aient de biens meilleures caractéristiques de délai, mais les opérateurs sont souvent peu disposés à donner des limites de délai.
Connexion à deux sauts sur un réseau privé avec un commutateur PBX en cascade
Figure 6-4 : Exemple de réseau privé à deux sauts avec un commutateur PBX en cascade 
L'exemple 4.3 montre que, avec l'hypothèse des pires délais, il est très difficile de maintenir le délai calculé au-dessous de 200 ms quand une connexion de filiale à filiale inclut un saut PBX en cascade au site central avec des connexions réseau Frame Relay publiques de chaque côté. Cependant, si la topologie du réseau et le trafic sont connu, il est possible de réduire sensiblement le chiffre calculé. Cela est dû au fait que les chiffres généralement donnés par les opérateurs sont limités par le délai de transmission et de mise en file d'attente le plus défavorable sur une zone étendue. Il est beaucoup plus facile d'établir des limites plus raisonnables dans un réseau privé.
Le chiffre généralement accepté pour le délai de transmission entre commutateurs est de l'ordre de 10 microsecondes/mille. Selon le matériel, le délai de transport-commutateur dans un réseau à relais de trame doit être de l'ordre de 1 ms fixe et de 5 ms variable pour la mise en file d'attente. Ces chiffres dépendent du matériel et du trafic. Les chiffres de délais pour les commutateurs WAN Cisco MGX sont inférieurs à 1 ms par total de commutateur si des segments E1/T1 sont utilisés. Avec l'hypothèse de 500 milles de distance, avec des délais de 1 ms fixe et 5 ms variable pour chaque saut, le calcul de délai devient :
Tableau 6.4 : Calcul de délai de réseau privé à deux sauts avec commutateur PBX en cascade
| Type de délai | Fixe (ms) | Variable (ms) |
|---|---|---|
| Délai de codeur,1 | 18 | |
| Retard de la mise en paquets, 1 | 30 | |
| Mise en file d'attente/mise en mémoire tampon, ß1 | 8 | |
| Délai de sérialisation (64 kbits/s), σ1 | 5 | |
| Délai réseau (trame privée), ωS1 + ßS1+ ωS2 + ßS2 | 2 | 10 |
| Délai tampon de dégivrage, Δ1 | 40 | |
| Délai de codeur,2 | 15 | |
| Retard de la mise en paquets, 2 | 30 | |
| Mise en file d'attente/mise en mémoire tampon, ß2 | 0,1 | |
| Délai de sérialisation (2 Mbits/s), σ2 | 0,1 | |
| Délai réseau (trame privée), ωS3 + ßS3 | 1 | 8 |
| Délai de sérialisation (64 kbits/s), σS3 | 5 | |
| Délai tampon de dégivrage, Δ2 | 40 | |
| Délai de transmission/distance (non décomposé) | 5 | |
| Totaux | 191.1 | 26.1 |
Remarque : Étant donné que le délai de mise en file d'attente et le composant variable du délai réseau sont déjà pris en compte dans les calculs de tampon de dégivrage, le délai total n'est que la somme de tous les délais fixes. Dans ce cas, le délai total est de 191.1 ms.
Quand vous gérez un réseau de relais de trame privé, il est possible d'établir une connexion rayon à rayon par l'intermédiaire du PBX au site du concentrateur et de rester dans la limite des 200 ms.
Effets des cycles de compression multiples
Les algorithmes de compression CS-ACELP ne sont pas déterministes. Cela signifie que le flux de données en entrée n'est pas exactement identique au flux de données en sortie. Un peu de déformation est introduite avec chaque cycle de compression, comme indiqué à la Figure 7-1.
Figure 7-1 : Effets de la compression 
En conséquence, les cycles de compression CS-ACELP multiples introduisent rapidement des niveaux importants de déformation. Cet effet additif de déformation n'est pas aussi prononcé avec des algorithmes ADPCM (Adaptive Differential Pulse Code Modulation).
L'impact de cette caractéristique est qu'en plus des effets de délai, le concepteur réseau doit prendre en compte le nombre de cycles de compression CS-ACELP dans le chemin.
La qualité vocale est subjective. La plupart des utilisateurs estiment que deux cycles de compression fournissent toujours une qualité vocale adéquate. Un troisième cycle de compression a habituellement comme conséquence une dégradation apparente, qui peut être inacceptable pour certains utilisateurs. En règle générale, le concepteur réseau doit limiter à deux le nombre de cycles de compression CS-ACELP dans un chemin. Si davantage de cycles doivent être utilisés, laissez d'abord le client entendre la différence.
Dans les exemples précédents, il a été démontré que quand une connexion de filiale à filiale est commutée en cascade à travers le PBX (sous forme PCM) au niveau du site du siège social, les délais sont sensiblement supérieurs à ce qu'ils seraient si la connexion était commutée en cascade dans le C7200 du siège social. Il est clair que quand le PBX est utilisé pour la commutation, il y a deux cycles de compression CS-ACELP dans le chemin, au lieu d'un seul quand la voix tramée est commutée par le C7200 central. La qualité vocale est meilleure avec l'exemple avec commutation par C7200 (4.2), bien qu'il puisse y avoir d'autres raisons, telles que la gestion de plan d'appel, qui peuvent nécessiter que le PBX soit inclus dans le chemin.
Si une connexion de filiale à filiale est établie par un PBX central et qu'à partir de la deuxième filiale l'appel est prolongé sur le réseau vocal public puis se termine sur un réseau téléphonique cellulaire, il y a trois cycles de compression CS-ACELP dans le chemin, ainsi qu'un délai sensiblement plus élevé. Dans ce scénario, la qualité est sensiblement affectée. Là encore, le concepteur réseau doit prendre en compte le chemin d'appel le plus défavorable et décider s'il est acceptable étant donné le réseau, les attentes et les besoins professionnels des utilisateurs.
Considérations relatives aux connexions à délai élevé
Il est relativement facile de concevoir des réseaux vocaux de paquets qui dépassent la limite de délai unidirectionnel généralement acceptée par l'ITU (150 ms).
Quand vous concevez des réseaux vocaux de paquets, l'ingénieur doit prendre en compte la fréquence d'utilisation d'une telle connexion, les besoins des utilisateurs et le type d'activité professionnelle concernée. Il n'est pas rare que de telles connexions soient acceptables dans des circonstances particulières.
Si les connexions de relais de trame ne parcourent pas une grande distance, il est tout à fait probable que les performances en matière de délai du réseau soient meilleures que celles indiquées dans les exemples.
Si le délai total observé avec des connexions routeur/passerelle en cascade devient trop grand, une alternative consiste souvent à configurer des circuits virtuels permanents (PVC) supplémentaires directement entre les MC3810 de terminaison. Ceci ajoute un coût récurrent au réseau car les opérateurs facturent habituellement par PVC, mais cela peut être nécessaire dans certains cas.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)