Vous êtes sur la page 1sur 25

Voix sur IP (VoIP)

-
Analyse de trafic
pour
la Voix sur IP

1
Sommaire

• Introduction

• Présentation de l'analyse de Trafic

• Bases de la théorie du trafic


- Mesure de la charge de trafic
- Degré de Service
- Types de Trafic
- Méthodes d'échantillonnage

• Critères de sélection du modèle de trafic


- Motifs d'arrivée des appels
- Appels bloqués
- Nombre de sources
- Temps de maintien des communications

• Modèles de trafic
- Erlang B
- Erlang B étendu
- Erlang C
- Poisson
- EART/EARC et Neal-Wilkerson

• Application de l'analyse de trafic aux réseaux VoIP


- Codecs voix
- Echantillons
- Détection d'activité Voix (VAD)
- Compression de l'en-tête RTP
- Point à Point contre Point à Multipoint

• Exemple d'analyse de trafic de bout en bout

• Documents liés

2
Introduction
Ce document traite de divers concepts d'analyse de trafic et des fonctionnalités qui
applicables à la voix sur IP (Voice over IP). Ce document présente également la théo-
rie fondamentale du trafic, différents modèles statistiques de trafic, l'application aux
réseaux VoIP et un exemple d'analyse de trafic.

Ce document contient les sections suivantes:

• Présentation de l'analyse de Trafic

• Bases de la théorie du trafic

• Critères de sélection du modèle de trafic

• Modèles de trafic

• Application de l'analyse de trafic aux réseaux VoIP

• Exemple d'analyse de trafic de bout en bout

• Documents liés

Présentation de l'analyse de Trafic


Les réseaux voix ou données sont conçus autour de différentes variables. Deux des
facteurs les plus importants que vous devez prendre en compte dans la conception
de réseau sont le service et le coût. Le service est essentiel pour répondre aux be-
soins des clients. Le coût est toujours un facteur de rentabilité. Un moyen que vous
pouvez utiliser pour certains éléments de service et de coût dans la conception de
réseau est l'optimisation de l'utilisation de circuits.

Ce document décrit les différentes techniques que vous pouvez utiliser pour cons-
truire et dimensionner de manière appropriée les réseaux voix sensibles à la charge
de trafic. Ce document présente différents modèles de trafic et explique comment
utiliser les tables de probabilité de trafic pour vous aider à construire des réseaux
voix robustes et efficaces.

Bases de la théorie du trafic


Les concepteurs de réseaux ont besoin d'un moyen pour dimensionner correctement
la capacité d'un réseau tout spécialement si les réseaux évoluent. La théorie de tra-
fic permet aux concepteurs de réseaux de faire des hypothèses sur leurs réseaux ba-
sées sur l'expérience passée.

Le trafic est défini soit comme le volume de données soit comme le nombre de mes-
sages sur un circuit pendant une période donnée. Le trafic inclut également la rela-
tion entre les tentatives d'appel sur un équipement sensible au trafic et la vitesse à
laquelle la communication est établie. L'analyse de trafic vous permet de déterminer
le montant de bande passante dont vous avez besoin pour vos circuits pour des
3
communications voix et données. L'ingénierie de trafic résoud les problèmes de ser-
vice en vous permettant de définir un degré de service ou un facteur de blocage. Un
réseau bien structuré a un faible taux de blocage et une utilisation élevée des cir-
cuits ce qui signifie que le service est élevé et que les coûts sont réduits.

Il y a plusieurs facteurs que vous devez prendre en compte lors de l'analyse de trafic.
Les facteurs les plus importants sont décrits dans les sections suivantes:

● Mesure de la charge de trafic


● Degré de service
● Types de trafic
● Méthodes d'échantillonnage

Bien d'autres facteurs peuvent affecter les résultats de calculs d'analyse de trafic
mais ceux-ci sont les plus importants. Vous pouvez faire des hypothèses pour les
autres facteurs.

Mesure de la charge de trafic

Dans la théorie du trafic, vous mesurez la charge de trafic. La charge de trafic est le
rapport entre le nombre d'appels pendant une période spécifiée et le temps moyen
mis pour servir chaque appel pendant la période spécifiée. Ces unités de mesure sont
basées sur le AHT (Average Hold Time). AHT est la durée totale de toutes les commu-
nications dans la période spécifiée par le nombre de communications pendant cette
période comme le montre l'exemple suivant:

(3976 secondes de durée totale )/(23 appels) = 172.87s par appel => AHT = 172.87 s

Les deux unités de mesure principales sont l'Erlang et le nombre de communications


par centaine de secondes (Centium Call Seconds).

Un Erlang est égal à 3600 secondes de communication sur le même circuit ou assez
de charge pour garder le circuit occupé pendant 1 heure. Le trafic en Erlangs est le
produit du nombre de communications par AHT divisé par 3600 comme le montre
l'exemple suivant:

(23 Appels * 172.87 AHT)/3600 = 1.104 erlangs

Un CCS est égal à 100 secondes de communication sur le même circuit. Les commu-
tateurs voix mesurent généralement le volume de trafic en CCS.

Le trafic en CCS est le produit du nombre de communications par AHT divisé par 100
comme le montre l'exemple suivant:

(23 Appels * 172.87 AHT)/100 = 39.76 CCS

L'unité que vous utilisez dépend beaucoup de l'équipement que vous utilisez et
quelle unité de mesure celui-ci utilise. Beaucoup de commutateurs utilisent le CCS
car il est beaucoup plus facile de travailler par incréments de 100 plutôt que 3600.
Les deux unités sont reconnues comme des standards da la pratique. Voici comment
les lier : 1 Erlang = 36 CCS
4
Bien que vous puissiez prendre le nombre total de secondes de communications en
une heure et le diviser par 3600 secondes pour déterminer le trafic en Erlangs, vous
pouvez prendre des valeurs variées de période. Ces différentes valeurs vous permet-
tent d'utiliser plus de périodes d'échantillonnage pour déterminer le trafic réel.

Trafic heure chargée

Vous mesurez logiquement la charge de trafic du réseau pendant l'heure la plus char-
gée car cette période représente la charge maximum de trafic que votre réseau doit
supporter. le résultat vous donne une mesure de charge de trafic communément ré-
férencée comme BHT (Busy Hour Trafic). Il y a des moments pour lesquels vous ne
pouvez pas faire un échantillonnage correct ou vous avez uniquement une estimation
du nombre de communications que vous gérez chaque jour. Dans de telles circons-
tances vous pouvez usuellement faire des estimations sur votre environnement par
exemple sur le nombre moyen de communications par jour et le AHT. Dans un envi-
ronnement de travail standard l'heure chargée pour n'importe quel jour représente 15
à 20 pourcent de trafic en plus pour ce jour. Dans vos calculs vous pouvez générale-
ment utiliser 17 pourcent du trafic journalier pour représenter le pic de trafic de
l'heure chargée. Dans plusieurs environnements de travail, un AHT acceptable est
estimé entre 128 à 210 secondes. Vous pouvez utiliser ces estimations si vous avez
également besoin de déterminer les exigences en nombre de circuits sans avoir toutes
les données.

Mesure des capacité du réseau

Parmi toutes les mesures de capacité réseau voici celles-ci:

● Busy Hour Call Attempts (BHCA)

● Busy Hour Call Completion (BHCC)

● Calls per Second (CPS)

Toutes ces mesures sont basées sur le nombre d'appels. Bien que ces mesures doi-
vent décrire la capacité du réseau, elles sont moins significatives que l'analyse de tra-
trafic car elles ne prennent pas en compte le temps de maintien de la communication.
Vous avez besoin d'utiliser ces mesures en conjonction avec un AHT pour en dériver
un BHT que vous pouvez utiliser pour l'analyse de trafic.

Degré de Service

Le degré de Service (GoS ou Grade of Service) est défini comme la probabilité de blo-
cage des communications lors de la tentative de prise des circuits. Il est décrit com-
me blocage ou facteur de blocage P.xx dans lequel xx représente le pourcentage d'ap-
pels qui sont bloqués pour un système de trafic. Par pour des trafic de facilités requé-
rant un degré de service, P.01 définit un pourcent de probabilité d'appelants bloqués
pour les facilités. Un degré de service de P.00 est rarement requis car pour être sur
qu'il n'y ait pas de blocage vous devriez avoir une conception de réseau où le rapport
appelant circuit soit 1/1. La majorité des formules de trafic supposent également que
le nombre d'appelants est infini.

5
Types de trafic

Vous pouvez utiliser l'équipement de télécommunication qui écoule le trafic pour en-
registrer les données décrites. Malheureusement la majorité des échantillons reçus
sont basés sur le trafic transporté et non sur la charge de trafic offerte.

Le trafic transporté est le trafic qui est actuellement servi par l'équipement de télé-
communications. Le trafic offert est le volume de tentatives de trafic sur un système.
Notez que la différence entre les deux peut entrainer quelques inexactitudes dans
votre calcul.

Plus grand est votre volume de blocage, plus grande sera la différence entre la charge
offerte et celle transportée. Vous pouvez utiliser la formule suivante pour calculer
la charge offerte à partir de la charge transportée.

Charge offerte = Charge Transportée/(1 – facteur de blocage)

Malheureusement cette formule ne prend pas en compte les tentatives de renouvelle-


ment d'appel quand un appelant est bloqué. Vous pouvez utiliser cette formule pour
prendre les tentatives de renouvellement d'appel en compte:

Charge offerte = Charge transportée * OAF (Offered Load Adjustment Factors)


OAF = [1.0 – (R * Facteur de blocage)]/(1.0 – Facteur de blocage)

R est le pourcentage de probabilité de renouvellement d'appel, R = 06 pour 60 pour-


cent de tentatives de renouvellement d'appel.

Méthodes d'échantillonnage

La précision de votre analyse de trafic dépendra également de la précision de vos


méthodes d'échantillonnage. Les paramètres suivants changeront la représentation
de la charge de trafic :

● Jours ouvrés ou "weekends"


● Vacances
● Type de trafic (Data ou Voix)
● Charge apparante offerte
● Période d'échantillonnage
● Nombre total d'échantillons pris en compte
● Stabilité de la période d'échantillonnage

La théorie de probabilité statut que pour examiner précisément le trafic voix d'un ré-
seau vous devez avoir au moins 30 des heures chargées de votre réseau voix dans la
période d'échantillonnage. Bien que cela soit un bon point de départ, d'autres varia-
bles peuvent affiner la précision de cet échantillon. Vous ne pouvez pas prendre les
30 plus élevés parmi 32 échantillons et vous attendre à ce que cet échantillonnage
donne une image précise de votre réseau. Pour obtenir les résultats les plus précis,
vous avez besoin de prendre autant d'échantillons que possible de la charge offerte.

6
D'une autre manière, si vous prenez des échantillons tout au long de l'année, vos ré-
sultats peuvent varier car votre charge croît ou décroît d'année en année. L'UIT- T
(Union Internationale des Télécommunications secteur de standardisation des Télé-
communications) produit des recommandations sur comment échantillonner le trafic
d'un réseau pour le dimensionner correctement.

L'UIT-T recommande que les mesures de connexion du réseau téléphonique public


commuté (RTPC) ou les périodes de lecture soient de 60 minutes et ou de 15 minutes.
Ces intervalles sont importants car ils vous laissent agréger l'intensité de trafic sur
une période de temps. Si vous prenez ces mesures tout au long de la journée, vous
pouvez trouver l'heure de pic de trafic pour n'importe quel jour. Il y a deux manières
recommandées pour déterminer le le pic de trafic comme suit:

● DPP (Daily Peak Period) enregistre le volume de trafic le plus élevé mesuré pen-
dant un jour. Cette méthode requiert une mesure continue et elle est typiquement
utilisée dans des environnements où l'heure chargée peut être différente d'un jour
à l'autre.

● Fixed Daily Measurement Interval (FDMI) demande des uniquement pendant des
périodes de pic prédéterminées. Elle est utilisée quand les motifs de trafic sont
assez prédictibles et que les périodes de pic se produisent à intervalles réguliers.
Le trafic d'affaires (commerce) a un pic aux environs de 10:00 à 11:00 et de 14:00
à 15:00.

Dans l'exemple du tableau suivant, avec utilisation de l'échantillonnage FDMI, vous


voyez que l'heure avec la plus haute charge de trafic total est 10:00 avec une charge
totale de trafic de 60,6 Erlangs.

Heure Lundi Mardi Mercredi Jeudi Vendredi Charge totale


9:00 12,7 11,5 10,8 11,0 8,6 54,6
10:00 12,6 11,8 12,5 12,2 11,5 60,6
11:00 11.1 11.3 11.6 12.0 12.3 58.3
12:00 9.2 8.4 8.9 9.3 9.4 45.2
13:00 10,1 10,3 10,2 10,6 9,8 51,0
14:00 12,4 12,2 11,7 11,9 11,0 59,2

15:00 9,8 11,2 12,6 10,5 11,6 55,7

16:00 10,1 11,1 10,8 10,5 10,2 52,7

Le tableau suivant utilise DDP pour calculer la charge totale de trafic.

Lundi Mardi Mercredi Jeudi Vendredi Charge totale


Pic de 12,7 12,2 12,5 12,1 12,3 61,9
trafic
Heure 9:00 14:00 10:00 10:00 11:00
du pic

7
Vous avez également besoin de diviser les mesures en groupes qui ont le même
comportement statistique. L'UIT-T définit ces groupes comme: jours ouvrés, jours de
fin de semaine et jours exceptionnels de l'année. Grouper les mesures qui ont le mê-
comportement statistique est important car un grand volume d'appels exceptionnels
(tel que Noël où la Fête des Mères) pourrait fausser les résultats. La recommanda-
tion UIT-T E.492 inclut des recommandations pour déterminer les intensités de tra-
fic normales et élevées pour le mois. Pour la recommandation E.492, l'intensité de
trafic normale pour le mois est définie comme le quatrième pic de trafic journalier le
plus élevé. Si vous sélectionnez la seconde mesure la plus élevée pour le mois, cela
donnera l'intensité de charge de trafic la plus élevée pour le mois. Ce résultat vous
permet de définir le charge de trafic attendue pour le mois.

Critères de sélection du modèle de trafic


Maintenant que vous savez quelles mesures sont nécessaires, vous pouvez détermi-
ner comment les utiliser. Vous devez choisir le modèle de trafic approprié. Les élé-
ments clés pour le choix du modèle approprié sont décrits dans les sections suivan-
tes:

● Motifs d'arrivée des appels


● Appels bloqués
● Nombre de sources
● Temps de maintien (durée des communications)

Motifs d'arrivée des appels

La première étape est le choix du bon modèle de trafic pour déterminer le motif d'ar-
rivée des appels.

Les trois principaux motifs d'arrivée des appels sont les suivants et sont décrits
dans les sections suivantes :

● Motif d'arrivée des appels lisse


● Motif d'arrivée des appels par pics
● Motif d'arrivée des appels aléatoire

Motif d'arrivée des appels lisse

Un motif de trafic lisse ou "hypo-exponentiel" se produit quand il n'y a peu de varia-


tion de trafic. Le temps des maintien des communications et l'intervalle d'arrivée des
appels sont prédictibles et vous permet de prédire le trafic pour une instance donnée
où il y a un nombre de sources fini. Par exemple, supposez que vous voulez conce-
voir un réseau voix par une société de "télémarketing" dans laquelle quelques agents
passent toute une journée au téléphone pour faire des appels. Supposez que dans
une période d'une heure vous pouvez vous attendre à 30 appels séquentiels d'une
durée de deux minutes chacun. Vous aurez besoin d'allouer un circuit pour gérer
les appels pour une heure.

8
Pour un motif d'arrivée des appels lisse, un graphe des appels en fonction du temps
ressemble à ceci:

Appels

Temps

Motif d'arrivée des appels par pics

Un motif d'arrivée des appels par pics a des pics ce trafic importants par rapport à la
moyenne. Ce motif d'arrivée des appels est également connu comme motif d'arrivée
"Hyper-exponentiel". Les motifs d'arrivée par pics montre pourquoi ce n'est pas une
bonne idée d'inclure Noël ou la Fête des Mères dans une étude de trafic. Il peut y
avoir des moments où vous voudriez gérer des groupes de circuits de débordement
pour gérer cette sorte de motif de trafic. En général, pour gérer cette sorte de motif de
trafic vous aurez besoin d'allouer assez de ressources pour gérer le pic de trafic. Par
exemple, pour gérer 30 appels simultanés vous aurez besoin de 30 circuits.

Un graphique des appels en fonction du temps pour un motif d'arrivée des appels
par pics peut ressemble à celui-ci:

Appels

Temps

9
Motif d'arrivée des appels aléatoire

Les motifs d'arrivée des appels aléatoires se définissent d'eux-mêmes par leur nom.
Ils sont également connus sous le nom de Poisson ou distribution exponentielle.
Poisson est le mathématicien français qui est à l'origine de la définition de ce type de
distribution. Les motifs aléatoires de trafic se manifestent dans les cas où il y a plu-
sieurs appelants générant un peu de trafic. Vous voyez généralement cette sorte de
motif aléatoire de trafic dans des environnements de PABX. Le nombre de circuits
dont vous aurez besoin peut varier de 1 à 30.

Un graphe des appels en fonction du temps pour un motif aléatoire d'arrivée des ap-
pels peut ressembler à celui-ci:

Appels

Temps

Appels bloqués

Un appel bloqué est un appel qui n'est pas immédiatement servi. Les appels sont
considérés comme bloqués s'ils sont reroutés vers un autre groupe de circuits placé
dans une file d'attente, reçoivent une tonalité en retour ou une annonce vocale. La
nature de l'appel bloqué détermine le modèle que vous sélectionnez car les appels
bloqués donnent des résultats différents dans la charge de trafic.

Les principaux types d'appels bloqués sont les suivants:

● Appels perdus maintenus (LCH - Lost Calls Held) - Ces appels bloqués sont perdus
sans possibilité de retour en arrière. A l'origine les appels perdus en attente (Lost
Calls Held) étaient basés sur la théorie que les appels introduits dans un système
de trafic étaient maintenus pour un temps infini. Tous les appels y compris tous
les appels qui étaient bloqués ce qui signifie que les appels seront toujours main-
tenus jusqu'à ce que le temps soit dépassé pour cet appel.

● Appels perdus effacés et redirigés (LCC - Lost Calls Cleared) - Les appels bloqués
sont effacés du système ce qui signifie que lorsqu'un appelant est bloqué, l'appel
est acheminé vers autre part (principalement vers d'autres facilités sensibles au
trafic).

10
● Appels perdus en attente (LCD - Lost Calls Delayed) - Ces appels bloqués restent
sur le système jusqu'à ce que les facilités soient disponibles pour servir l'appel.
Les appels perdus en attente sont principalement utilisés dans environnements
centre d'appels ou avec des circuits de données car les facteurs clés des appels
perdus en attente pourraient être le délai en conjonction avec la charge de trafic.

● Appels perdus retentés (LCR - Lost Calls Retried) Les appels perdus retentés sup-
posent que lorsqu'un appel est bloqué, un pourcentage d'appels bloqués est reten-
té une seule fois et le reste des appels essaient jusqu'à ce qu'ils soient servis. Ce
modèle est un dérivé du modèle Appels perdus redirigés.

Nombre de sources

Le nombre de sources d'appels a un rapport avec le modèle de trafic que vous choi-
sissez. Par exemple, s'il y a uniquement une source et un circuit, la probabilité de
blocage est nulle. Dès que le nombre de sources croît, la probabilité de blocage aug-
mente vite. Le nombre de sources entre en jeu quand on dimensionne un PABX sur
lequel vous pouvez utiliser un plus petit nombre de circuits et toujours arriver à un
degré de service voulu.

Temps de maintien des communications

Quelques modèles de trafic prennent en compte les temps de maintien des communi-
cations. La majorité des modèles ne prennent pas en compte le temps de maintien
car les temps de maintien des communications sont supposés exponentiels. Généra-
lement, les communications ont un temps de maintien assez court ce qui veut dire
qu'ils auront une distribution exponentielle négative.

Modèles de trafic
Après avoir déterminé les motifs d'arrivée des appels, les types de blocage d'appels, le
nombre de sources et les temps de maintien des communications, vous êtes prêt pour
le choix du modèle de trafic qui correspond le mieux à votre environnement. Bien
qu'aucun des modèles de trafic ne corresponde exactement à des situations réelles,
ces modèles garantissent une moyenne dans chaque situation. Il y a différents modè-
les de trafic, la clé consiste à trouver le modèle qui correspond le mieux à votre envi-
ronnement.

Les modèles de trafic qui sont très largement adoptés sont Erlang B, Erlang B étendu
et Erlang C. Les autres modèles communément adoptés sont Engset, EART/EARC et
Neal-Wilkerson. Le tableau suivant donne une comparaison des différents modèles de
trafic.

Modèle de trafic Sources Motif d'arrivée Appels bloqués Temps de Maintien


Poisson Infini Aléatoire Maintenus Exponentiel
Erlang B Infini Aléatoire Effacés Exponentiel

11
Modèle de trafic Sources Motif d'arrivée Appels bloqués Temps de Maintien
Erlang B étendu Infini Aléatoire Retentés Exponentiel
Erlang C Infini Aléatoire En attente Exponentiel
Engset Fini Lisse Effacés Exponentiel
EART/EARC Infini Par pics Effacés Exponentiel
Neal-Wilkerson Infini Par pics Maintenus Exponentiel
Crommelin Infini Aléatoire En attente Constant
Binomial Fini Aléatoire Maintenus Exponentiel
Délai Fini Aléatoire En attente Exponentiel

Les sections suivantes décrivent les différents modèles de trafic. Bien que les tables
pour tous les modèles de trafic soient trop volumineuses pour être incluses dans un
document de cette taille, vous pouvez trouver des informations en ligne ou d'autres
sources. Vous pouvez choisir de calculer le facteur de blocage en utilisant:

● Les formules de ce document

● Des calculateurs en ligne à l'URL suivante:


http://www.erlang.com/calculator/index.htm

● Des tables de trafic disponibles en ligne ou dans des ouvrages.

Erlang B
Le modèle de trafic Erlang B est basé sur les hypothèses suivantes:

● Un nombre de sources infini

● Un motif d'arrivée de trafic aléatoire

● Des appels bloqués redirigés

● Temps de maintien avec distribution exponentielle

Le modèle Erlang B est utilisé quand les appels sont reroutés et ne reviennent jamais
au groupe de circuits original. Ce modèle suppose un motif d'arrivée des appels aléa-
toire. L'appelant fait une seule tentative; si l'appel est bloqué alors l'appel est rerouté.
Le modèle Erlang B est communément utilisé pour la première tentative pour un
groupe de circuits pour lequel vous prenez en considération le taux de reprise car les
appels sont reroutés ou vous vous attendez à un très faible blocage.

La formule suivante est utilisée pour le modèle Erlang B:

ac ● B(c,a) est la probabilité de blocage de l'appel

B (c, a )  c! ● c est le nombre de circuits


ak
 k  0 k!
c

● a est la charge de trafic

12
Exemple 1: Utilisation du modèle de trafic Erlang B.

Problème

Vous avez besoin de reconcevoir votre groupe de circuits longue distance en sortie qui
subi couramment des blocages durant l'heure chargée. Les rapports des commuta-
teurs disent que l groupe de circuits offre 17 Erlangs de trafic pendant l'heure char-
gée. Vous voulez avoir un faible taux de blocage aussi vous voulez une conception
qui donne moins de 1 pourcent de blocage.

Solution

Si vous regardez les tables Erlang B, vous voyez que pour 17 Erlangs de trafic et un
degré de service de 0,64, vous avez besoin de 27 circuits pour gérer cette charge de
trafic. Vous pouvez également vérifier le facteur de blocage en utilisant l'équation de
l'Erlang B avec l'information fournie. Une autre possibilité de vérification du facteur
de blocage est d'utiliser la fonction Microsoft Excel Poisson avec le format suivant:

=(POISSON(<circuits>,<traffic load>,FALSE))/(POISSON(<circuits>,<traffic load>,TRUE))

Il y a un calculateur Erlang B, Erlang B étendu et Erlang C d'une utilisation très


aisée à l'URL suivante:

http://www.erlang.com/calculator/index.htm

Erlang B étendu

Le modèle de trafic Erlang B étendu est basé sur les hypothèses suivantes:

● Un nombre de sources infini

● Un motif d'arrivée de trafic aléatoire

● Des appels bloqués redirigés

● Temps de maintien avec distribution exponentielle

Le modèle Erlang B étendu est conçu pour prendre en compte les appels retentés à
un certain rythme. Ce modèle suppose un motif d'arrivée des appels aléatoire, que
les appelants bloqués font de multiples tentatives pour aboutir et qu'aucun déborde-
ment n'est autorisé. Le modèle Erlang B étendu est communément utilisé pour des
groupes de circuits sans débordement avec une probabilité de nouvelle tentative
d'appel.

Exemple 2: Utilisation du modèle de trafic erlang B étendu

Problème

Vous voulez déterminer combien de circuits sont nécessaires pour votre serveur d'ac-
cès distant. Vous savez que vous recevez 28 Erlangs de trafic pendant l'heure chargée
et que 5 pourcent de blocage pendant cette période est acceptable. Vous vous atten-
13
dez également à ce que 50 pourcent des utilisateurs fassent immédiatement une nou-
velle tentative.

Solution

Si vous regardez les tables d'Erlang B étendu, vous voyez que pour 28 Erlangs de
trafic avec une probabilité de nouvelle tentative de 50 pourcent et un taux de blocage
de 4,05 pourcent vous avez besoin de 35 circuits pour gérer cette charge de trafic.

Il y a un calculateur Erlang B, Erlang B étendu et Erlang C d'une utilisation très


aisée à l'URL suivante:

http://www.erlang.com/calculator/index.htm

Erlang C

Le modèle de trafic Erlang C est basé sur les hypothèses suivantes:

● Un nombre de sources infini

● Un motif d'arrivée de trafic aléatoire

● Des appels bloqués en attente

● Temps de maintien avec distribution exponentielle

Le modèle Erlang C est conçu autour de la théorie des files d'attente. Ce modèle sup-
pose un motif d'arrivée des appels aléatoire; l'appelant fait un appel qui est maintenu
en file d'attente jusqu'à ce que l'appel ait une réponse. Le modèle Erlang C est plus
communément utilisé pour un centre d'appels (ACD) afin de déterminer le nombre
d'agents nécessaire. Il peut être utilisé également pour déterminer la bande passante
sur les circuits de transmission de données mais ce n'est pas le meilleur modèle à
utiliser pour ce besoin.

Dans le modèle Erlang C, vous avez besoin de connaître le nombre d'appels ou de pa-
quets pendant l'heure chargée, la durée moyenne d'une communication ou la taille
de paquet et le délai d'attente en secondes.

La formule suivante est utilisée pour le modèle Erlang C:

a cc ● C(c,a) est la probabilité de d'attente de l'appel


c!(c  a )
C (c, a )  k ● c est le nombre de circuits
c 1 a acc
k 0 k! c!(c  a)

● a est la charge de trafic

14
Exemple 3: Utilisation du modèle de trafic Erlang C pour la voix

Problème

Vous vous attendez à ce que le centre d'appel ait 600 appels durant approximative-
ment 3 mn chacun, que chaque agent ait un délai de 20 secondes entre appels. Vous
aimeriez que le temps moyen d'attente dans la file soit de 10 secondes.

Solution

Calculez la charge de trafic attendue. Vous savez que vous avez 600 appels d'une du-
rée approximative de 3 minutes. A ce nombre vous devez ajouter 20 secondes car un
agent répond à un appel en 20 secondes en moyenne. Le temps additionnel de 20 s
fait partie du temps mis pour servir l'appel comme le montre la formule suivante:

(600 appels * 200 secondes AHT)/3600 = 33.33 erlangs de trafic

Calculez le facteur délai en divisant le délai d'attente espéré par AHT comme suit:

(10 sec de délai)/(200 secondes) = 0.05 de facteur délai

Exemple 4: Utilisation du modèle de trafic Erlang C pour la donnée

Problème

Vous êtes en train de concevoir votre connexion de backbone entre deux routeurs.
Vous savez que vous aurez 600 paquets par seconde (pps) avec 200 octets par pa-
quet soit 1600 bits. La multiplication de 600 par 1600 donne la bande passante né-
cessaire (960000 bit/s). Vous savez que vous pouvez louer une liaison par incrément
de 64 Kb/s, volume de données nécessaire pour garder le circuit occupé pendant 1
second. De combien de circuits avez-vous besoin pour maintenir le délai inférieur à
10 ms.

Solution

Calculez la charge de trafic comme suit.

(960,000 bps)/(64,000 bps) = 15 Erlangs de charge de trafic

Calculez le temps de transmission moyen. Multipliez le nombre d'octets par paquet


par 8 pour obtenir le nombre ce bits par paquet ensuite diviser ce nombre obtenu
par 64000 bit/s (débit du circuit) pour obtenir le temps moyen de transmission par
paquet.

(200 octets par paquet) x 8 bits = 1600 bits par paquet

(1600 bits par paquet) / 64000 bit/s = 0,025 s ou 35 ms de transmission

(10 ms/ 25 ms) = 0,4 de facteur délai

15
Si vous regardez dans les tables d'Erlang C, vous voyez qu'avec une charge de trafic
de 15,45 Erlangs et un facteur délai de 0,4, vous avez besoin de 17 circuits. Ce calcul
est basé sur l'hypothèse que chaque circuit n'a aucune perte de paquet.

Il y a un calculateur Erlang B, Erlang B étendu et Erlang C d'une utilisation très


aisée à l'URL suivante:

http://www.erlang.com/calculator/index.htm

Engset

Le modèle de trafic Engset est basé sur les hypothèses suivantes:

● Un nombre de sources fini

● Un motif d'arrivée de trafic lisse

● Des appels bloqués effacés du système

● Temps de maintien avec distribution exponentielle

La formule Engset est généralement utilisée pour des environnements où il est aisé
de supposer qu'un nombre fini de sources utilisent un groupe de circuits. En con-
naissant le nombre de sources vous pouvez assurer un haut niveau de service. Vous
devez utiliser la formule Engset dans les applications telles que les cellules GSM
(Global System for Mobile) et les concentrateurs de lignes d'abonnés. Comme le mo-
dèle de trafic Engset est décrit dans beaucoup d'ouvrages dédié à l'analyse de trafic,
celui-ci n'est pas traité dans ce document.

Poisson

Le modèle de trafic Poisson est basé sur les hypothèses suivantes:

● Un nombre de sources infini

● Un motif d'arrivée de trafic aléatoire

● Des appels bloqués en attente

● Temps de maintien avec distribution exponentielle

Dans le modèle de Poisson, les appels bloqués sont maintenus jusqu'à ce qu'un cir-
cuit devienne disponible. Ce modèle suppose un motif d'arrivée des appels aléatoire;
l'appelant fait une seule tentative pour placer l'appel et les appels bloqués sont per-
dus. Le modèle de Poisson est communément utilisé pour surutiliser un groupe de
circuits isolés.

16
La formule suivante est utilisée pour le modèle de trafic Poisson:

ak
P ( c, a )  1  e  k  0
a c 1

k!

● P(c,a) est la probabilité de blocage de l'appel

● e est le nombre e

● c est le nombre de circuits

● a est la charge de trafic

Exemple 5: Utilisation du modèle de trafic Poisson

Problème

Vous créez un nouveau groupe de circuits pour qu'il soit utilisé par votre nouveau si-
te et vous voulez déterminer combien de lignes sont nécessaires. Vous vous attendez
à ce que le site écoule approximativement 300 appels par jour avec un AHT d'environ
4 minutes (240 secondes). Le but est d'avoir un degré de service P.01 ou 1 pourcent
de taux de blocage. Pour garder de la marge nous supposerons que 20 pourcent des
appels se produisent pendant l'heure chargée.

Calculer le trafic à l'heure chargée comme suit:

300 calls * 20% = 60 Appels pendant l'heure chargée


(60 calls * 240 AHT)/3600 = 4 Erlangs pendant l'heure chargée

Solution

Si vous regardez les tables de Poisson, vous voyez que pour 4 Erlangs de trafic avec
un taux de blocage de 0,81 pourcent (proche de 1 pourcent) vous avez besoin de 10
circuits pour gérer la charge de trafic. Vous pouvez vérifier cette valeur en insérant
les variables dans la formule de Poisson comme suit:

4k 16 64 256
P(10, 4)  1  e k 0
4 101
 1  e  4 (1  4     )  0,00813
k! 2 6 24
Une autre manière aisée pour trouver le taux de blocage est d'utiliser la fonction
Poisson de Microsoft Excel avec le format suivant:

=1 – POISSON(<circuits> – 1,<traffic load>,TRUE)

17
EART/EARC et Neal-Wilkerson

Les modèles EART/EARC et Neal-Wilkerson sont utilisés pour des modèles de trafic
avec pics. La majorité des sociétés de téléphonie utilisent ces modèles pour étendre
des groupes de circuits qui ont des motifs d'arrivée de trafic par pics. Les modèles
EART/EARC traitent les appels bloqués comme effacés et le modèle Neal-Wilkerson
comme des appels en attente. Comme les modèles EART/EARC et Neal-Wilkerson
sont décrits dans beaucoup d'ouvrages dédiés à l'analyse de trafic, ils ne sont pas
traités dans ce document.

Application de l'analyse de trafic aux réseaux VoIP

Parce que le trafic VoIP utilise RTP (Real Time Protocol) pour transporter le trafic voix,
vous pouvez utiliser les mêmes principes pour définir la bande passante sur vos liens
WAN.

Il y a quelques challenges dans définition de la bande passante. Les considérations


traitées dans les sections suivantes affecterons la bande passante des réseaux voix.

● Codecs voix

● Echantillons

● VAD (Voice Activity Detection)

● Compression de l'en-tête RTP

● Point à point opposé à point à multipoint

Codecs voix

Plusieurs codecs voix sont utilisés dans la téléphonie IP. Ces codecs ont tous des dé-
bits et des complexités différentes. Les codecs voix standardisés sont G.711, G.723.1,
G.726, G.728, G.729. Tous les routeurs et serveurs d'accès Cisco avec des capacités
voix supportent tout ou partie de ces codecs.

Les codecs impactent la bande passante car ils déterminent la charge utile des pa-
quets transférés sur la branche IP de la communication. Dans les passerelles voix
Cisco, vous pouvez configurer la taille de la charge utile pour contrôler la bande pas-
sante. En accroissant la charge utile, vous réduirez le nombre total de paquets trans-
mis réduisant ainsi la bande passante nécessaire en réduisant le nombre d'en-têtes
requis pour une communication.

Echantillons

Le nombre d'échantillons par paquet est un autre facteur de détermination de la ban-


de passante pour une communication voix. Le codec définit la taille de l'échantillon
mais le nombre total d'échantillons placés dans un paquet affecte le nombre de pa-
quets transmis par seconde. Par conséquent le nombre d'échantillons inclus dans un
paquet affecte la bande passante générale d'une communication.

18
Pour G.711 avec un échantillon de 10 ms donne 80 octets. Une communication avec
un seul échantillon par paquet donne les résultats suivants:

80 octets + 20 octets IP + 12 UDP + 8 RTP = 120 octets par paquet

(120 octets/paquet) * 100 pps = (12000 * 8 bits)/1000 = 96 Kb/s par communication

La même communication utilisant deux échantillons de 10ms par packet donnera les
résultats suivants:

(80 octets * 2 échantillons) + 20 octets IP + 12 UDP + 8 RTP = 200 octets par paquet
(200 octets par paquet) * (50 pps) = (10000 * 8 bits)/1000 = 80 Kb/s par communication

Note: Les en-têtes de couche 2 n'étaient pas inclus dans les calculs précédents

Les résultats montrent qu'il y a une différence de 16 Kb/s entre les deux communi-
cations. En changeant le nombre d'échantillons par paquet vous pouvez changer le
montant de bande passante utilisé par une communication mais il y a un inconvé-
nient. Quand vous augmentez le nombre d'échantillons par paquet, vous augmentez
également le délai de chaque communication. Les ressources DSP qui gèrent chaque
communication bufferiser les échantillons pendant un temps plus long. Vous devez
garder ceci en mémoire quand vous concevrez votre réseau voix.

Détection d'activité voix (VAD)

Des conversations voix typiques peuvent contenir 30 à 50 pourcent de silence. Avec


les réseaux traditionnels basés sur les circuits, toutes les communications voix utili-
sent une bande passante fixe de 64 Kb/s sans tenir compte de la répartition entre la
parole et les silences. Avec les réseaux VoIP toute la conversation et les silences sont
paquétisés. La détection d'activité voix (VAD) transmet des paquets RTP uniquement
quand la voix est détectée. Pour la planification de la bande passante VoIP, on admet
que la VAD réduit la bande passante de 35 pourcent. Bien que cette valeur puisse
être faible, elle fournit une estimation raisonnable qui prend en considérations les
différents langages.

Les codecs G.729 Annexe-B et G.723.1 Annexe-A comprennent une fonction VAD in-
tégrée mais ont des performances identiques à G.729 et G.723.1

Compression de l'en-tête RTP

Tous les paquets voix ont deux composantes: les échantillons voix et les en-têtes
IP/UDP/RTP. Bien que les échantillons compressés par le DSP (Digital Signal Proces-
sor) et que la taille varie selon le codec utilisé, les en-têtes sont toujours de taille
constante et égale à 40 octets. Quand on les compare aux 20 octets des échantillons
voix par défaut dans une communication G.729, ces en-têtes prennent un montant
très important de la bande passante. En utilisant la compression de l'en-tête RTP
(cRTP) qui est utilisée liaison par liaison, ces en-têtes peuvent être compressés en 2
ou 4 octets. Cette compression offre des gains substantiels en bande passante pour
la VoIP. par exemple une communication VoIP G.729 classique consomme 24 Kb/s
sans cRTP mais seulement 12 Kb/s avec cRTP validé.

19
Le type de codec, le nombre d'échantillons par paquet, la VAD et cRTP peuvent affec-
ter d'une manière ou d'une autre la bande passante d'une communication. Dans cha-
que cas, il y a un compromis entre qualité de voix et bande passante. Le tableau sui-
vant donne l'utilisation de bande passante pour divers scénarios. L'efficacité de la
VAD dans ce tableau est supposée être égale à 50%.

Bande Charge En-tête


Bande Bande
passante Taille utile En-tête
Paquets IP/UDP/ En-tête passante passante
voix detrame Cisco par RTP cRTP couche 2 totale sans totale avec
Algorithme (Kb/s) (octets) (octets) seconde (octets) (octets) L2 (octets) VAD (Kb/s) VAD (Kb/s)

G.711 64 80 160 50 40 — Ether 14 85.6 42.8

G.711 64 80 160 50 — 2 Ether 14 70,4 35,2

G.711 64 80 160 50 40 — PPP 6 82,4 41,2


G.711 64 80 160 50 — 2 PPP 6 67,2 33,6
G.711 64 80 160 50 40 — FR 4 81,6 40,8
G.711 64 80 160 50 — 2 FR 4 66,4 33,2
G.711 64 80 80 100 40 — Ether 14 107,2 53,6
G.711 64 80 80 100 — 2 Ether 14 76,8 38,4
G.711 64 80 80 100 40 — PPP 6 100,8 50,4
G.711 64 80 80 100 — 2 PPP 6 70,4 35,2
G.711 64 80 80 100 40 — FR 4 99,2 49,6
G.711 64 80 80 100 — 2 FR 4 68,8 34,4
G.729 8 10 20 50 40 — Ether 14 29,6 14,8
G.729 8 10 20 50 — 2 Ether 14 14,4 7,2
G.729 8 10 20 50 40 — PPP 6 26,4 13,2
G.729 8 10 20 50 — 2 PPP 6 11,2 5,6
G.729 8 10 20 50 40 — FR 4 25,6 12,8
G.729 8 10 20 50 — 2 FR 4 10,4 5,2
G.729 8 10 30 33 40 — Ether 14 22,4 11,2
G.729 8 10 30 33 — 2 Ether 14 12,3 6,1
G.729 8 10 30 33 40 — PPP 6 20,3 10,1
G.729 8 10 30 33 — 2 PPP 6 10,1 5,1
G.729 8 10 30 33 40 — FR 4 19,7 9,9
G.729 8 10 30 33 — 2 FR 4 9,6 4,8
G.723.1 6,3 30 30 26 40 — Ether 14 17,6 8,8
G.723.1 6,3 30 30 26 — 2 Ether 14 9,7 4,8
G.723.1 6,3 30 30 26 40 — PPP 6 16,0 8,0
G.723.1 6,3 30 30 26 — 2 PPP 6 8,0 4
G.723.1 6,3 30 30 26 40 — FR 4 15,5 7,8
G.723.1 6,3 30 30 26 — 2 FR 4 7,6 3,8

20
Bande Charge En-tête Bande Bande
passante Taille de utile Paquets IP/UDP/ En-tête En-tête passante passante
voix trame Cisco par RTP cRTP couche 2 totale sans totale avec
Algorithme (Kb/s) (octets) (octets) seconde (octets) (octets) L2 (octets) VAD (Kb/s) VAD (Kb/s)

G.723.1 5,3 30 30 22 40 — Ether 14 14,8 7,4


G.723.1 5,3 30 30 22 — 2 Ether 14 8,1 4,1
G.723.1 5,3 30 30 22 40 — PPP 6 13,4 6,7
G.723.1 5,3 30 30 22 — 2 PPP 6 6,7 3,4
G.723.1 5,3 30 30 22 40 — FR 4 13,1 6,5
G.723.1 5,3 30 30 22 — 2 FR 4 6,4 3,2

Point à Point opposé à Point à Multipoint


Parce que les circuits RNIS sont construits comme des liaisons point à point et que les
réseaux VoIP sont basiquement point à multipoint, vous devez considérer où va votre
trafic et le grouper en conséquence. Ce groupage devient un facteur très important
quand on doit choisir la bande passante des liaisons de secours.

La figure suivante montre un réseau avec toutes les liaisons WAN fonctionnant correc-
tement.

B1

gs
B rlan
2E

ngs
2 Erla
A1 gs
rlan
10

E
2 Erla 10
Erl

ngs A
an
gs

10 E
rlan
gs
s

C
ng
la
Er

3
3

Er
la

A2
ng

s
ng
s

la
Er
2

C1

Liaison Physique
Liaison Virtuelle

21
Les liaisons point à point n'ont pas besoin de plus de bande passante que le nombre
de communications voix vers ou venant des liaisons du réseau téléphonique public
bien que la qualité de la voix puisse diminuer quand on approche le débit de la liai-
son. Si une de ces liaisons est perdue, vous devez vous assurer que vos liaisons de
secours ont la capacité de supporter l'augmentation de trafic. Dans la figure suivante
la liaison WAN entre les nœuds A et B est hors-service (down). Le trafic va s'accroître
entre le nœuds A et C et entre C et B. Ce trafic additionnel demande que les liaisons
soient dimensionnées pour supporter la charge supplémentaire.

B1

gs
B Erlan
2

ngs
2 Erla
A1 gs
rlan

10
E
2 Erla 10

Erl
ngs A

an
gs
10 E
rlan
gs
s

C
ng
la
Er

3
3

Er
la

A2
ng

s
ng
s

la
Er
2

C1

Liaison Physique
Liaison Virtuelle

22
Exemple d'analyse de trafic de bout en bout
Avec les tables de trafic appropriées, définir le nombre de circuits nécessaires pour
supporter les communications devient aisé. En définissant le nombre de communica-
tions côté RTCP (réseau téléphonique public), vous pouvez également définir le mon-
tant de bande passante nécessaire sur la branche IP d'une communication. Malheu-
reusement les mettre ensemble peut être un problème.

La figure suivante montre la topologie du réseau utilisé pour cet exemple.

36000 mn
par jour

GB

USA Chine

12882,4 mn 28235,3 mn
par jour par jour

Problème

Comme cela est illustré par la figure ci-dessus, il y des bureaux aux USA, en Chine
et en Grande-Bretagne. Parce que votre site principal est en Grande-Bretagne, vous
allez acheter des lignes louées de Grand-Bretagne vers les USA et la Chine. La majo-
rité de votre trafic va de la Grande-Bretagne vers les USA ou la Chine avec un peu de
trafic entre les USA et la Chine. Les enregistrements détaillées des communications
donnent les statistiques suivantes:

● Grande-Bretagne : 36000 minutes par jour

● USA : 12882,4 minutes par jour

● Chine : 28235,3 minutes par jour

23
Pour ce réseau vous faites les suppositions suivantes:

● Le trafic à chaque nœud a un motif d'arrivée aléatoire

● Les temps de maintien des communications sont exponentiels

● Les appels bloqués sont effacés du système

● Il y a un nombre infini d'appelants

Ces suppositions vous indiquent que vous pouvez utiliser le modèle Erlang B pour
dimensionner vos groupes de circuits vers le réseau téléphonique public. Vous vou-
lez également un degré de service GoS de P.01 sur chacun de vos groupes de circuits.

Solution

Calculez la charge de trafic pour les liaisons téléphoniques à chaque nœud comme
suit:

GB = (36000 mn par jour) * 17% = (6120 mn par heure chargée)/60 = 102 Erlangs BHT
USA = (12882.4 mn par jour) * 17% = (2190 mn par heure chargée)/60 = 36.5 Erlangs BHT
Chine = (28235.3 mn par jour) * 17% = (4800 mn par heure chargée)/60 = 80 Erlangs BHT

Ces valeurs vous donneront effectivement le nombre de circuits nécessaires pour vos
connexions téléphoniques publiques dans chacun des nœuds. Maintenant que vous
avez une valeur de trafic utilisable, regardez dans les tables pour trouver le nombre
le plus proche qui correspond.

Pour la Grande-Bretagne, un BHT de 102 Erlangs avec un GoS P.01 indique un total
de 120 circuits DS-0 (64 Kb/s) pour supporter cette charge.

Le trafic USA montre que pour un blocage égal à P.01 et une charge de trafic égale à
36,108 Erlangs, vous avez besoin de 48 circuits. Comme votre charge de trafic réelle
est de 36,5 Erlangs vous pouvez subir un taux de blocage légèrement supérieur à
P.01. En utilisant la formule Erlang B, vous voyez que vous allez subir un taux de
blocage d'environ 0,01139.

Avec un BHT de 80 Erlangs et un GoS P.01, la table Erlang B montre que vous pou-
vez utiliser deux valeurs. Avec un blocage P.01 vous voyez que 80,303 Erlangs de
trafic requièrent 96 circuits. Comme les circuits sont commandés par blocs de 24 ou
32 à un opérateur de transport numérique, vous devez choisir 4 T1 ou 96 Ds-0 ou
4 E1 ou 120 DS-0. Quatre E1 est excessif pour le montant de trafic que vous aurez
mais vous respecterez votre taux de blocage.

Maintenant que vous connaissez de combien de circuits téléphoniques vous avez be-
soin, vous devez déterminer la bande passante dont vous aurez besoin sur vos cir-
cuits point à point. Comme le volume de trafic que vous avez sur la bande passante
téléphone public, vous pouvez faire le lien entre le nombre de circuits et le montant
de bande passante nécessaire.

24
Vous devez d'abord choisir à utiliser avec les opérateurs. Le codec G.729 est le plus
utilisé car il a une très bonne qualité de voix pour la bande passante utilisée.

Un codec G.729 utilise la bande passante suivante:

● 26,4 Kb/s par communication avec les en-têtes

● 11,2 Kb/s par communication avec la VAD

● 9,6 Kb/s par communication avec cRTP

● 6,3 Kb/s par communication avec la VAD et cRTP

Par conséquent la bande passante nécessaire sur la liaison entre la Grande-Bretagne


et les USA est la suivante:

● Plein débit : 96 DS-0 * 26,4 Kb/s = 2,534 Mb/s

● Avec la VAD : 96 DS-0 * 11,2 Kb/s = 1,075 Mb/s

● Avec cRTP : 96 DS-0 * 17,2 Kb/s = 1,651 Mb/s

● Avec la VAD et cRTP : 96 DS-0 * 7,3 Kb/s = 700,8 Kb/s

La bande passante nécessaire sur la liaison entre la Grande-Bretagne et la Chine est


la suivante:

● Plein débit : 72 DS-0 * 26,4 Kb/s = 1,9 Mb/s

● Avec la VAD : 72 DS-0 * 11,2 Kb/s = 806,4 Kb/s

● Avec cRTP : 72 DS-0 * 17,2 Kb/s = 1,238 Mb/s

● Avec la VAD et cRTP : 72 DS-0 * 7,3 Kb/s = 525,6 Kb/s

Comme vous pouvez le voir, la VAD et cRTP ont un impact substantiel sur la bande
passante nécessaire sur la liaison WAN.

Documents liés

Cisco IOS Voice, Video and Fax Configuration Guide


Voice over IP Fundamentals, Cisco Press, 2000
ITU-T Recommendation E.500, Traffic Intensity Measurement Principles
ITU-T Recommendation E.492, Traffic Reference Period

25