N° d’ordre : 07/TCO/IRS Année Universitaire : 2013-2014

UNIVERSITE D’ANTANANARIVO
ECOLE SUPERIEURE POLYTECHNIQUE D’ANTANANARIVO
DEPARTEMENT TELECOMMUNICATION
-------------------------------

MEMOIRE DE FIN D’ETUDES

en vue de l’obtention
du DIPLOME d’INGENIEUR
Grade : Master
Mention : Télécommunication
Parcours : Ingénierie des Réseaux et Systèmes (IRS)

par : ANDRIASAMIMANANA Rivohasindranto Nomenjanahary

ALLOCATION DYNAMIQUE DE
LA BANDE PASSANTE DANS
UN RESEAU OPTIQUE PASSIF 10-GIGABITAIRE
Soutenu le 23 Mars 2015 devant la Commission d’Examen composée de :
Président :
Monsieur RAKOTOMALALA Mamy Alain

Examinateurs :
Monsieur ANDRIAMANALINA Ando
Monsieur RAVALIMINOARIMALALASON Toky Basilide
Monsieur RANDRIAMIHAJARISON Mparany Jimmy

Directeur de mémoire : Monsieur RATSIMBAZAFY Andriamanga

 REMERCIEMENTS

Mon âme bénit le Seigneur, qui par sa grâce, m’a permis de réaliser ce mémoire de fin d’études
dans la joie et la santé.

Je tiens à exprimer ma gratitude envers Monsieur ANDRIANARY Philippe, Professeur Titulaire,

Directeur de l’Ecole Supérieure Polytechnique d’Antananarivo, pour les cinq années durant
lesquelles j’ai fait mes études supérieures au sein de l’établissement.

J’adresse mes vifs remerciements à Monsieur RAKOTOMALALA Mamy Alain, Maître de

Conférences, Chef du Département Télécommunication pour son dévouement au sein du
Département dans le but de nous offrir une formation complète, et pour l’honneur qu’il me fait de
présider le jury de ce mémoire.

Mes plus sincères remerciements vont à Monsieur RATSIMBAZAFY Andriamanga, Maître de

Conférences, qui a accepté d’être le Directeur de ce mémoire. Je n’aurais pu mener à termes ce
travail sans son encadrement. Je lui suis reconnaissant pour le temps qu’il m’a accordé ; son aide et
ses précieux conseils ont été d’une valeur inestimable.

Je remercie également tous les membres du jury :

- Monsieur ANDRIAMANALINA Ando, Maître de Conférences
- Monsieur RAVALIMINOARIMALALASON Toky Basilide, Enseignant Chercheur
- Monsieur RANDRIAMIHAJARISON Mparany Jimmy, Enseignant Chercheur
qui ont eu l’amabilité d’examiner ce mémoire malgré leurs nombreuses responsabilités.

Un grand merci à tous les enseignants de l’ESPA et particulièrement à ceux du Département

Télécommunication. Je leur dois tout ce que j’ai appris durant ces cinq années.

Merci à toutes les personnes ayant participé de près ou de loin à la réalisation de ce mémoire.

Merci à toute ma famille, à tous mes amis et à tous mes proches pour leur soutien et leurs
encouragements.

Pour terminer, je dédie ce mémoire de fin d’études à ma mère, celle qui m’a tout donné, qui m’a
fourni tous les moyens nécessaires jusqu’à la fin de mes études ainsi que pour la réalisation de ce
mémoire.

i
 TABLES DES MATIERES

REMERCIEMENTS ...................................................................................................................................... i
TABLES DES MATIERES .......................................................................................................................... ii
NOTATIONS ................................................................................................................................................ ix
ABREVIATIONS ......................................................................................................................................... xi
INTRODUCTION GENERALE.................................................................................................................. 1
CHAPITRE 1 RESEAUX D’ACCES OPTIQUE....................................................................................... 3
1.1 Introduction ......................................................................................................................................... 3

1.2 Réseaux de télécommunications ........................................................................................................ 3

1.2.1 Réseau de transport ...................................................................................................................... 4

1.2.2 Réseau d’accès .............................................................................................................................. 4

1.3 Technologie du réseau d’accès ........................................................................................................... 5

1.3.1 Terminologie du réseau d’accès ................................................................................................... 5

1.3.2 Réseau téléphonique commuté ..................................................................................................... 5

1.3.3 Les technologies xDSL ................................................................................................................. 6

1.3.4 Accès sans fil ................................................................................................................................. 6

1.3.5 Accès satellite ................................................................................................................................ 7

1.3.6 Courant Porteur en Ligne ............................................................................................................ 8

1.3.7 La fibre optique en distribution .................................................................................................... 8

1.4 Réseau d’accès optique ....................................................................................................................... 8

1.4.1 Architecture point à point ........................................................................................................... 10

1.4.2 Architecture point à multipoint .................................................................................................. 10

1.5 Les réseaux optiques passifs ............................................................................................................. 11

1.5.1 Principe des réseaux PON .......................................................................................................... 11

1.5.2 Topologie ..................................................................................................................................... 13

1.5.3 Terminologie et technique utilisés dans les réseaux PON ........................................................ 13

1.5.3.1 Les équipements ................................................................................................................... 14

1.5.3.2 Code en ligne ........................................................................................................................ 15

1.5.3.3 Budget optique ..................................................................................................................... 15

ii
 1.5.3.4 Ranging ................................................................................................................................ 15

1.5.3.5 Portée logique et portée physique ........................................................................................ 16

1.5.3.6 Distance différentielle le long des fibres .............................................................................. 16

1.5.3.7 Temps moyen de propagation du signal ............................................................................... 16

1.5.4 Sécurité dans les réseaux PON .................................................................................................. 16

1.5.5 Les standards de PON................................................................................................................. 16

1.5.5.1 Les organismes de normalisation ......................................................................................... 17

1.5.5.2 APON et BPON ................................................................................................................... 17

1.5.5.3 EPON ou 1GEPON et 10GEPON ........................................................................................ 18

1.5.5.4 GPON ................................................................................................................................... 19

1.5.5.5 NGPON ................................................................................................................................ 20

1.5.6 Les services pouvant être offerts par les réseaux PON.............................................................. 21

1.6 Conclusion ......................................................................................................................................... 21

CHAPITRE 2 LE XGPON ......................................................................................................................... 22

2.1 Introduction ....................................................................................................................................... 22

2.2 Caractéristiques générales ............................................................................................................... 22

2.3 Architecture en couche ..................................................................................................................... 23

2.4 PMD ................................................................................................................................................... 23

2.4.1 Débit binaire nominal ................................................................................................................. 23

2.4.2 Longueur d’onde de fonctionnement ......................................................................................... 23

2.4.3 Codage en ligne........................................................................................................................... 24

2.4.4 Type de fibre ................................................................................................................................ 24

2.4.5 Budget optique ............................................................................................................................ 24

2.4.6 Taux de couplage ........................................................................................................................ 24

2.4.7 Distance ....................................................................................................................................... 24

2.4.8 Temps moyen maximal de propagation des signaux ................................................................. 24

2.5 XGTC ................................................................................................................................................. 24

2.5.1 Les fonctions de chaque sous-couche XGTC ............................................................................ 26

iii
 2.5.1.1 La sous-couche XGTC Service Adaptation ......................................................................... 26

2.5.1.2 La sous-couche XGTC Framing........................................................................................... 27

2.5.1.3 La sous-couche PHY Adaptation ......................................................................................... 27

2.6 Gestion d’un système XGPON ......................................................................................................... 28

2.6.1 Le canal OAM imbriqué ............................................................................................................. 28

2.6.2 Le canal PLOAM ........................................................................................................................ 28

2.6.3 OMCI........................................................................................................................................... 28

2.7 Le multiplexage du trafic dans le XGPON ..................................................................................... 28

2.7.1 ONU-ID ....................................................................................................................................... 29

2.7.2 Alloc-ID ....................................................................................................................................... 30

2.7.3 XGEM Port-ID............................................................................................................................ 30

2.8 Media Access Control ....................................................................................................................... 31

2.9 Structure détaillée des trames XGTC ............................................................................................. 32

2.9.1 Structure de la trame XGTC descendante.................................................................................. 32

2.9.1.1 HLend ................................................................................................................................... 32

2.9.1.2 BWmap................................................................................................................................. 33

2.9.1.3 PLOAMd .............................................................................................................................. 35

2.9.2 Structure du burst XGTC montant ............................................................................................ 35

2.9.2.1 XGTC burst header .............................................................................................................. 36

2.9.2.2 Allocation Overhead............................................................................................................. 37

2.9.2.3 XGTC Trailer ....................................................................................................................... 37

2.10 XGEM .............................................................................................................................................. 37

2.10.1 Trame XGEM............................................................................................................................ 38

2.10.1.1 Structure du XGTC payload ............................................................................................... 38

2.10.1.2 L’en-tête de la trame XGEM .............................................................................................. 38

2.10.1.3 Format du XGEM payload ................................................................................................. 39

2.10.1.4 XGEM frame vide .............................................................................................................. 39

2.10.2 Délimitation du XGEM frame .................................................................................................. 40

iv
 2.10.3 Fragmentation des SDU ........................................................................................................... 40

2.11 Structure des PHY frames et des PHY bursts .............................................................................. 42

2.11.1 Structure du PHY frame descendant ....................................................................................... 42

2.11.1.1 PSBd ................................................................................................................................... 42

2.11.1.2 PHY frame payload ............................................................................................................ 43

2.11.2 Structure du PHY burst montant ............................................................................................. 43

2.11.2.1 PSBu ................................................................................................................................... 44

2.11.2.2 PHY burst payload ............................................................................................................. 44

2.11.2.3 Intervalle de garde .............................................................................................................. 45

2.12 Forward Error Correction ............................................................................................................. 45

2.13 Scrambling ....................................................................................................................................... 45

2.14 Activation de l’ONU........................................................................................................................ 45

2.15 Conclusion ....................................................................................................................................... 46

CHAPITRE 3 ALLOCATION DYNAMIQUE DE LA BANDE PASSANTE DANS LE XGPON ..... 47

3.1 Introduction ....................................................................................................................................... 47

3.2 Allocation de ressource et qualité de service dans le XGPON ...................................................... 47

3.2.1 Notion de QoS ............................................................................................................................. 47

3.2.2 Descripteur de trafic ................................................................................................................... 48

3.2.3 Principes de l’allocation de ressource dans le sens descendant................................................ 49

3.2.4 Principes de l’allocation de ressource dans le sens montant .................................................... 49

3.2.4.1 T-CONT ............................................................................................................................... 49

3.2.4.2 Allocation des ressources dans le sens montant ................................................................... 49

3.3 Allocation dynamique de la bande passante ................................................................................... 50

3.3.1 Notion de bande passante et de largeur de bande ..................................................................... 50

3.3.2 DBA ............................................................................................................................................. 50

3.4 Abstraction du DBA dans le XGPON ............................................................................................. 52

3.4.1 Construction du BWmap ............................................................................................................ 53

3.4.2 Résumé des champs de données intervenant dans le mécanisme du DBA ............................... 53

v
 3.5 Exigences fonctionnelles du DBA .................................................................................................... 54

3.6 Les méthodes d’allocation dynamique de la largeur de bande ..................................................... 54

3.7 Modèle de référence pour le DBA.................................................................................................... 54

3.7.1 Notations ..................................................................................................................................... 55

3.7.2 Offered load ................................................................................................................................ 55

3.7.3 Présentation du modèle de référence pour le DBA ................................................................... 55

3.7.4 Attribution de la largeur de bande garantie............................................................................... 57

3.7.5 Attribution de la largeur de bande additionnelle sur le critère de proportionnalité ................ 57

3.7.5.1 Largeur de bande non assurée .............................................................................................. 58

3.7.5.2 Largeur de bande de meilleur effort ..................................................................................... 58

3.7.6 Attribution de la largeur de bande additionnelle en se basant sur les critères de priorité et de
poids ..................................................................................................................................................... 59

3.8 Exigences de performance du DBA ................................................................................................. 60

3.8.1 Attribution de largeur de bande stationnaire............................................................................. 60

3.8.1.1 Définition ............................................................................................................................. 60

3.8.1.2 Performance visée ................................................................................................................ 60

3.8.2 Temps de restauration de la bande passante assurée ................................................................ 61

3.8.2.1 Définition ............................................................................................................................. 61

3.8.2.2 Performance visée ................................................................................................................ 61

3.8.3 Temps de convergence de DBA .................................................................................................. 61

3.8.3.1 Définition ............................................................................................................................. 61

3.8.3.2 Performance visée ................................................................................................................ 62

3.9 Types de T-CONT ............................................................................................................................. 62

3.10 Conclusion ....................................................................................................................................... 62

CHAPITRE 4 SIMULATION DE L’ALLOCATION DYNAMIQUE DE LA BANDE PASSANTE

DANS UN XGPON EN UTILISANT L’ALGORITHME GIANT ......................................................... 63
4.1 Introduction ....................................................................................................................................... 63

4.2 Présentation de NS3 .......................................................................................................................... 63

4.2.1 Terminologie et abstractions ...................................................................................................... 64

vi
 4.2.2 Organisation de NS3................................................................................................................... 64

4.2.3 Outil de visualisation .................................................................................................................. 65

4.3 Module XGPON pour NS3 ............................................................................................................... 65

4.3.1 Compromis de mis en œuvre ...................................................................................................... 66

4.3.2 Cas d’utilisation .......................................................................................................................... 66

4.3.3 Description du module ................................................................................................................ 67

4.3.4 Blocs fonctionnels ....................................................................................................................... 68

4.4 Objectifs de la simulation ................................................................................................................. 69

4.5 Présentation de la simulation ........................................................................................................... 70

4.5.1 L’algorithme GIANT .................................................................................................................. 70

4.5.1.1 Allocation de la partie garantie de la bande passante ........................................................... 71

4.5.1.2 Allocation de partie additionnelle de la bande passante ....................................................... 72

4.5.2 Architecture du réseau................................................................................................................ 74

4.5.2.1 Présentation de l’architecture ............................................................................................... 74

4.5.2.2 OnOffApplication................................................................................................................. 75

4.5.2.3 PacketSink ............................................................................................................................ 75

4.5.3 Programmation du simulateur ................................................................................................... 76

4.5.4 Déroulement général et résultats cherchés ................................................................................ 76

4.5.4.1 Déroulement d’un scénario .................................................................................................. 76

4.5.4.2 Résultats cherchés ................................................................................................................ 76

4.5.4.3 Remarque sur la durée d’une simulation .............................................................................. 77

4.6 Simulation .......................................................................................................................................... 77

4.6.1 Scénario 1 : Largeur de bande fixe ............................................................................................ 77

4.6.2 Scénario 2 : Largeur de bande fixe et largeur de bande assurée .............................................. 79

4.6.3 Scénario 3 : Largeur de bande fixe, largeur de bande assurée et largeur de bande non assurée
.............................................................................................................................................................. 81

4.6.4 Récapitulatif ................................................................................................................................ 83

4.7 Avantage et inconvénient de l’algorithme....................................................................................... 84

vii
 4.8 Conclusion ......................................................................................................................................... 85

CONCLUSION GENERALE .................................................................................................................... 86

ANNEXE 1 : MODELE GENERAL DE REFERENCE DE PROTOCOLE POUR LE RESEAU
D’ACCES ..................................................................................................................................................... 87
ANNEXE 2 : CARACTERISTIQUES DE LA FIBRE MONOMODE G.652 ...................................... 89
ANNEXE 3 : LISTE DES MESSAGES PLOAM.................................................................................... 90
ANNEXE 4 : HYBRID ERROR CORRECTION ET SCRAMBLER SEQUENCE ........................... 92
ANNEXE 5 : MAPPAGE DE SERVICE DANS LE XGEM FRAME .................................................. 94
ANNEXE 6 : BURST PROFILE ............................................................................................................... 95
ANNEXE 7 : LISTE DES MODELES DU MODULE XGPON ............................................................ 96
ANNEXE 8 : EXTRAIT DE CODES SOURCES ................................................................................... 97
ANNEXE 9 : FICHIERS DE TRACE .................................................................................................... 103
BIBLIOGRAPHIE .................................................................................................................................... 104
FICHE DE RENSEIGNEMENTS ........................................................................................................... 106
RESUME
ABSTRACT

viii
 NOTATIONS

1. Majuscules latines
A : Quantité de trafic qui arrive au tampon d’un ONU
ABmin : Allocation Bytes minimum
ABsur : Allocation Bytes surplus
B : Occupation d’un tampon
BE : Best effort, Valeur de l’indicateur d’admissibilité pour l'attribution de largeur
de bande best effort

C : Capacité de l'interface en amont

D : Descripteur de trafic
F : PHY frame
L : Longueur en octets d’un SDU
N : Nombre de structure d’allocation dans le BWmap
NA : Non assurée, Valeur de l’indicateur d’admissibilité pour l'attribution de largeur
de bande non assure

P : Priorité pour l'attribution de la bande passante best effort

R : Largeur de bande totale
𝑅𝐴 : Largeur de bande assurée
RBE : Largeur de bande de meilleur effort
𝑅𝐹 : Largeur de bande fixe
RG : Largeur de bande garantie
RL : Offered Load
𝑅𝑀 : Largeur de bande maximum
RNA : Largeur de bande non assurée
S : Nombre de message PLOAM dans la partition PLOAMd
SBE : Largeur de bande excédentaire disponible pour l’attribution d’une largeur de
bande de meilleur effort

SNA : Largeur de bande excédentaire disponible pour l’attribution d’une largeur de

bande non assurée
SImin : Service Interval minimum

ix
SImax : Service Interval maximum
T : Taille du XGEM payload
W : Contribution d’un SDU de longueur L dans le BufOcc
𝑋𝐴𝐵 : Indicateur d’admissibilité pour l'attribution de largeur de bande additionnelle

2. Minuscules grecques
𝜔 : Poids pour l'attribution de la bande passante best effort

3. Majuscules grecques
Δ : Temps d’évacuation du tampon d’un Alloc-ID

x
 ABREVIATIONS

1GEPON : 1-Gigabit Ethernet Passive Optical Network

3D : 3 Dimensions
10GEPON : 10-Gigabit Ethernet Passive Optical Network
ADSL : Asymmetric Data Subscriber Line
Alloc-ID : Allocation Identifier
AES : Advanced Encryption Standard
AO : Allocation Overhead
AON : Active Optical Network
APON : Asynchronious Transfer Mode Passive Optical Network
ATM : Asynchronious Transfer Mode
BCH : Bose Ray-Chaudhuri Hocquenghem
BER : Bit Error Rate
BIP : Bit-Interleaved even Parity
BPON : Broadband Passive Optical Network
BufOcc : Buffer Occupancy
CATV : Community Access Television
CPL : Courant Porteur en ligne
CRC : Code de Redondance Cyclique
CTVR : Centre for Telecommunications Value-Chain Research
DBA : Dynamic Bandwidth Assignement
DBRu : Dynamic Bandwidth Report upstream
DSL : Data Subscriber Line
EP2P : Ethernet Point To Point
EPON : Ethernet Passive Optical Network
EqD : Equalization Delay
FEC : Forward Error Correction
FITL : Fiber In The Loop
FSAN : Full Service Access Network
FTTB : Fiber To The Building
FTTC : Fiber To The Curb

xi
FTTH : Fiber To The Home
FTTN : Fiber To The Node
FTTX : Fiber To The X
FWI : Forced Wake-up Indication
GEM : Gigabit-capable Passive Optical Network Encapsulation Method
GIANT : GigaPON Access Network
GNUGPLv2 : GNU General Public License version 2
GPON : Gigabit-capable Passive Optical Network
GPRS : General Packet Radio Service
GSM : Global System for Mobile Communication
HD : Haute Définition
HDSL : High bit rate Data Subscriber Line
HEC : Hybrid Error Correction
ID : Identifier
IEEE : Institute of Electrical and Electronics Engineers
IP : Internet Protocol
IPTV : Internet Protocol Television
ITU-T : International Telecommunication Union – Telecommunication
LF : Last Fragment
LTE : Long Term Evolution
MAC : Medium Access Control
MPLS : Multiprotocol Label Switching
NGA : Next Generation Access
NGPON : Next Generation Passive Optical Network
NRZ : Non Return to Zero
NS2 : Network Simulator 2
NS3 : Network Simulator 3
OAM : Operation Administration and Management
OAN : Optical Access Network
ODN : Optical Distribution Network
OLT : Optical Line Termination
OMCI : ONU Management and Control Interface

xii
OMCC : ONU Management and Control Channel
ONT : Optical Network Termination
ONU : Optical Network Unit
OSI : Open System Interconnection
PCBd : Physical Control Block downstream
PHY : Physical Interface
PLC : PowerLine Communication
PLI : Payload Length Indication
PLOAM : Physical Layer Operation Administration and Maintenance
PLOAMd : Physical Layer Operation Administration and Maintenance downstream
PLOAMu : Physical Layer Operation Administration and Maintenance upstream
PMD : Physical Media Dependent
PON : Passive Optical Network
PON-ID : Passive Optical Network-Identifier
PSBd : Physical Synchronization Block downstream
PSBu : Physical Synchronization Block upstream
PSync : Physical Synchronisation
QoS : Quality of Service
RADSL : Rate Adaptative Data Subscriber Line
RNIS : Réseau Numérique à Intégration de Service
RTC : Réseau Téléphonique Commuté
RTD : Round Trip Delay
SDSL : Single pair ou Symmetric Data Subscriber Line
SDU : Service Data Unit
SFC : Superframe counter
SFD : Start Frame Delimiter
SLA : Service Level Agrement
SR DBA : Status Reporting Dynamic Bandwidth Allocation
TDM : Time division Multiplexing
TDMA : Time Division Multiple Access
TM DBA : Traffic Monitoring Dynamic Bandwidth Allocation
UMTS : Universal Mobile Telecommunication System

xiii
VDSL : Very high Data Subscriber Line
VOD : Video On Demand
VoIP : Voice over Internet Protocol
WIFI : Wireless Fidelity
WIMAX : Worldwide Interoperability for Microwave Access
WLAN : Wireless Local Area Network
WMAN : Wireless Metropolitan Area Network
WPAN : Wireless Personal Area Network
WWAN : Wireless Wide Area Network
XGEM : 10-Gigabit-capable Passive Optical Network Encapsulation Method
XGPON : 10-Gigabit-capable Passive Optical Network
XGTC : 10-Gigabit-capable Passive Optical Network Transmission Convergence

xiv
 INTRODUCTION GENERALE

La commercialisation des services de télécommunications pour un opérateur passe obligatoirement

par un réseau qui dessert tous ses clients. Un tel réseau est appelé réseau d’accès, et est l’élément
déterminant de la qualité du service perçu par les clients. L’arrivée de la télévision haute définition
et de la télévision en trois dimensions, l’augmentation des tailles des photos et vidéos numériques,
la multiplication du nombre des jeux vidéo haute qualité en ligne et le besoin de partager et
d’échanger des fichiers le plus rapidement possible ont accru considérablement le besoin en bande
passante des utilisateurs. Le réseau d’accès se doit de répondre à ce besoin en bande passante.

Le choix de la fibre optique comme support de transmission pour la desserte de chaque usager est
la solution pour assurer le confort d’utilisation des applications dites gourmandes en bande passante.
En effet, la fibre optique est l’unique support de transmission capable de fournir un débit de
plusieurs gigabits par seconde. Un réseau d’accès par fibre optique est appelé réseau d’accès
optique.

Ce sont les opportunités que présente le réseau d’accès optique qui nous ont mené la réalisation de
ce travail, qui est axé sur un aspect particulier encore plus intéressant de l’un de ses standards. Un
réseau d’accès optique possédant une architecture point à multipoint passif constitue un réseau
optique passif. Plusieurs standards de réseau optique passif ont été normalisés par les organismes
internationaux œuvrant dans le domaine de la télécommunication. Mais on se concentrera ici au
dernier standard actuel et donc le plus performant qui est le réseau optique passif 10-gigabitaire
abrégé XGPON (10-Gigabit-capable Passive Optical Network).

Un réseau d’accès XGPON est mutualisé, c’est-à-dire partagé entre plusieurs clients. Dans le sens
descendant de la transmission des données, cet aspect mutualisé présente un avantage dans le
partage des ressources réseaux notamment la bande passante. Pour profiter du même avantage dans
le sens montant, le XGPON utilise une technique dite allocation dynamique de la bande passante.

Cet ouvrage est consacré à l’étude de cette technique. Il comprend quatre chapitres. Le premier
chapitre commence par présenter le réseau d’accès et les technologies qui y sont associées, puis
continue avec le réseau d’accès optique et ses différentes architectures, et se termine avec les réseaux
optiques passifs et ses différents standards. Le second chapitre est entièrement consacré au XGPON
avec un intérêt particulier sur les entités intervenant dans l’allocation dynamique de la bande

1
passante. Cette dernière est décrite plus en détail dans le troisième chapitre ; une modélisation
servant de référence y sera rapportée. L’étude se terminera dans le quatrième chapitre par une
simulation de l’allocation dynamique de la bande passante dans le XGPON.

Même ardu, ce travail a été effectué minutieusement en fournissant un très grand confort de lecture.
Il est destiné à tout usage, pour s’instruire, s’informer ou actualiser ses connaissances.

2
 CHAPITRE 1

RESEAUX D’ACCES OPTIQUE

1.1 Introduction

La fibre optique est un support privilégié pour les télécommunications à haut débit. Comparé à
d'autres supports de câbles conducteurs, elle présente de nombreux avantages en performance de
transmission tels qu'une très faible atténuation, une très grande bande passante et des possibilités de
multiplexage qui permettent d'atteindre de très hauts débits sur une très grande portée. Des avantages
de mise en œuvre sont aussi à relever : sa toute petite taille, sa grande souplesse, son faible poids,
sa sécurité électrique et électromagnétique. Ce support est largement utilisé par les réseaux très
longue distance et apparaît depuis quelques années dans le réseau d'accès pour permettre aux
abonnés de profiter de performances plus élevées que le cuivre, le WIFI (Wireless Fidelity) ou
encore la transmission satellite. Dans un réseau d’accès optique, on ne parle plus de « haut débit »
mais de « très haut débit ».

1.2 Réseaux de télécommunications

Dans la structure hiérarchique des réseaux publics de télécommunications, on est amené à distinguer
différentes portions du réseau correspondant à différents niveaux de cette hiérarchie, illustrés en
Figure 1.01. [1]

Figure 1.01 : Structure hiérarchique des réseaux de télécommunications

3
Chaque niveau hiérarchique est ici caractérisé par sa distance. On distingue les niveaux suivants :
Acess, Metro access, Metro edge, Metro core, Long haul, Ultra Long haul et Sub marine. Cependant,
une première distinction est opérée entre le réseau d’accès et le réseau de transport. [1]

1.2.1 Réseau de transport

Le réseau de transport constitue le cœur d’un réseau de télécommunications, on l’appelle également

réseau cœur. Les commutateurs de télécommunications reliés entre eux forment le réseau de collecte
(ou métropolitain) qui constitue le premier niveau du réseau de transport. On peut y distinguer
principalement au niveau national des réseaux maillés formés de plusieurs sous-réseaux ayant une
structure en boucle. Au-delà des réseaux nationaux, on trouve des réseaux s’étendant sur plusieurs
milliers de kilomètres à l’échelle des pays les plus grands ou de continents. On parle alors de réseaux
continentaux ou (très) longue distance ou encore de réseaux sous-marins. Le réseau de transport
permet de réaliser des transmissions de données à des débits atteignant une centaine de gigabits par
seconde. [1]

1.2.2 Réseau d’accès

Le réseau d’accès, encore appelé réseau de distribution ou encore boucle locale forme la partie qui
relie le terminal de l’utilisateur à un commutateur du réseau de transport. La distance séparant ces
deux unités est souvent de l'ordre de quelques kilomètres jusqu'à 20km. Le réseau d’accès est parfois
désigné par l’expression « derniers kilomètres du réseau ». Plusieurs réseaux d’accès sont
interconnectés entre eux grâce au réseau cœur Le coût global de développement, de mise en place
et de maintenance du réseau d’accès est énorme, il est très supérieur à celui du réseau cœur. Ces
coûts élevés s’expliquent par le fait qu’il faut atteindre chaque utilisateur dans son habitation. [2]

Réseau de transport

Réseau d’accès

Figure 1.02 : Les réseaux d’accès

4
1.3 Technologie du réseau d’accès

Le réseau d'accès connaît actuellement une évolution très rapide qui accompagne le développement
de l'Internet et des services de télécommunication dans le monde entier. Un panorama de l'accès en
général est ici dressé afin d'établir un état des lieux des technologies disponibles et de leurs
performances respectives.

1.3.1 Terminologie du réseau d’accès

On distingue trois parties dans l'architecture du réseau d'accès: le central, le point d'éclatement et le
client.

Figure 1.03 : Terminologie du réseau d’accès

Le central relie le réseau d’accès au réseau de transport. Le point d’éclatement distribue la partie
mutualisée du réseau d’accès (entre le central et le point d’éclatement) entre les clients. [1]

1.3.2 Réseau téléphonique commuté

Le réseau public de téléphonie RTC (Réseau Téléphonique Commuté) utilise une paire de cuivre
comme support physique. Le réseau d’accès téléphonique est un réseau dédié basé sur la
commutation de circuits. Il possède de nombreuses interconnexions afin de gérer les
communications internationales, fixes vers mobile ou encore d’un opérateur à un autre pour une
même communication. Le RTC peut être aussi utilisé pour un accès à Internet en mode commuté.
Historiquement utilisé pour fournir des services de voix analogique, il a intégré les technologies
numériques autorisant de nouveaux services. Le RNIS (Réseau Numérique à Intégration de Service)
est un service de téléphonie numérique qui permet de fournir des services voix et données à des
débits de 64 ou 128 kbps en utilisant la paire de cuivre traditionnelle. [3]

5
1.3.3 Les technologies xDSL

Les technologies xDSL (Data Subscriber Line) regroupent les systèmes de télécommunication qui
permettent de transmettre des données à haute vitesse sur des lignes téléphoniques torsadées. Il en
existe différentes variantes : HDSL (High bit rate DSL), SDSL (Single pair ou Symmetric DSL),
ADSL (Asymmetric DSL), RADSL (Rate Adaptative DSL), VDSL (Very high DSL). Les
différences essentielles entre ces différentes technologies sont la vitesse de transmission, la distance
maximale entre l'utilisateur et le central, une variation de débit entre le flux montant et flux
descendant. Les technologies xDSL sont divisées en deux familles, celles utilisant une transmission
symétrique et celles utilisant une transmission asymétrique. [1][2]

Technologie Mode de Débits min/max Distance Nombre de paire

transmission (Mbps) maximale (km)
HDSL 1,544/2,048 4,5 2 ou 3
Symétrique
SDSL 0,768/2 3,6 1
Descendant: 1,5/6
ADSL 5,4 1
Montant: 0,016/0,64
Descendant: 0,6/7
RADSL Asymétrique 5,4 1
Montant: 0,128/1
Descendant: 13/51
VDSL 1,3 1
Montant: 1,5/2,3

Tableau 1.01: Synthèse des technologies xDSL

1.3.4 Accès sans fil

Le réseau d'accès sans fil se répartit en quatre catégories illustrées sur la Figure 1.04. Ces catégories
se distinguant d'une part par la fréquence d'émission utilisée et d'autre part par le débit et la portée
des transmissions.

Le réseau personnel sans fil WPAN (Wireless Personal Area Network) concerne les réseaux sans
fil d'une faible portée : de l'ordre de quelques dizaines de mètres. Ce type de réseaux sert
généralement à relier des périphériques (imprimante, téléphone portable, appareils domestiques,...)
à un ordinateur sans liaison filaire ou bien à permettre la liaison sans fil entre deux machines très
peu distantes. Il existe plusieurs technologies utilisées pour les WPAN dont principalement le
Bluetooth fonctionnant à un débit théorique de 1 Mbps pour une trentaine de mètres maximum.

Le réseau local sans fil WLAN (Wireless Local Area Network) permet de couvrir un réseau d'une
portée d'environ une centaine de mètres. Parmi les technologies utilisées dans ce type de réseaux on

6
note le WIFI qui offre des débits allant jusqu'à 54Mbps sur une distance de plusieurs centaines de
mètres en espace ouvert. Les travaux de la norme sont actifs pour faire évoluer le débit vers quelques
100Mbps.

La norme de réseau métropolitain sans fil WMAN (Wireless Metropolitan Area Network) dont la
plus connue est le WIMAX (Worldwide Interoperability for Microwave Access) permet d'obtenir
des débits de l'ordre de 70 Mbps sur un rayon de plusieurs kilomètres.

Le réseau étendu sans fil WWAN (Wireless Wide Area Network) est également connu sous le nom
de réseau cellulaire mobile. Il s'agit des réseaux sans fil les plus répandus puisque tous les téléphones
mobiles sont connectés à un réseau étendu sans fil. Les principales technologies sont, du plus ancien
au plus récent, le GSM (Global System for Mobile Communication le GPRS (General Packet Radio
Service), l’UMTS (Universal Mobile Telecommunication System) et le LTE (Long Term
Evolution). Cette dernière technologie permet par exemple un débit crête de 100 Mbps sur la voie
descendante et 50 Mbps sur la voie montante. [1][2]

Figure 1.04 : Catégorie des réseaux sans fil

1.3.5 Accès satellite

Le réseau d'accès peut utiliser les techniques de distribution par satellite. A partir d'un utilisateur ou
d'un point de regroupement d'utilisateurs, il est possible de passer par un satellite pour accéder à un
point d'accès du réseau d'un opérateur. Deux grands types de satellites peuvent être distingués : les
satellites de diffusion, dits traditionnels, et les satellites multimédia de nouvelle génération. Les
satellites multimédia sont généralement bidirectionnels, c’est-à-dire permettant une voie de retour.

7
Trois grandes familles de service peuvent être envisagées avec ces satellites : les services "multicast"
basés sur une transmission point à multipoint, les services à la demande basés sur une transmission
point à point, et les services d’accès à Internet. [1][2]

1.3.6 Courant Porteur en Ligne

La technologie CPL (Courant Porteur en Ligne) ou PLC (PowerLine Communication) en anglais

est une solution pour l’accès à la boucle locale des abonnés dans des zones non desservies par
d’autres techniques. La simplicité apparente de sa mise en œuvre et la capillarité du réseau électrique
basse tension existant présentent des perspectives intéressantes pour la desserte locale du client final.
La première génération des spécifications du PLC autorise des débits de transmission de données
dans les bâtiments de l’ordre de 5 à 10 Mbps, ce qui permettra la mise en œuvre d'applications
comme le streaming audio ou multimédia et la VoIP (Voice over Internet Protocol). [1][2]

1.3.7 La fibre optique en distribution

La fibre optique peut être utilisée pour mettre en place une boucle locale puissante en recâblant
complètement le réseau de distribution en fibre optique. Cette technique est dite FITL (Fiber In The
Loop). En effet, déjà largement utilisée dans les réseaux longue distance, l'optique entre désormais
dans les réseaux de desserte grand public. On dit que la fibre optique est amenée au plus près de
l'utilisateur final. [1][2]

1.4 Réseau d’accès optique

Les systèmes de réseau d’accès optique OAN (Optical Access Network) se caractérisent d’une
manière générale par les entités suivantes :
- Un système de terminaison de ligne optique OLT (Optical Line Termination), situé dans le
site technique ou le central de l’opérateur. L’OLT assure l’interface coté réseau de l’OAN.
- Une unité de réseau optique ONU (Optical Network Unit) ou une terminaison de réseau
optique ONT (Optical Network Termination) dont la localisation dépend du type de
topologie réseau. L’ONU ou l’ONT assure l’interface coté utilisateur de l’OAN. L’ONT est
un cas particulier de l’ONU qui incorpore la fonction de port utilisateur. Dans la suite, les
deux termes feront références au même élément. Cependant, l’usage de l’une des
expressions à défaut de l’autre réside uniquement dans le fait que celui-ci est plus approprié
à l’intérieur du contexte en question.

8
 - Un réseau de fibres optiques ODN (Optical Distribution Network) assurant l’interconnexion
entre un OLT et plusieurs ONT.

Réseau de Transport

Figure 1.05 : Réseau d’accès optique

L’architecture du réseau de distribution optique ODN peut être soit point à point soit point à
multipoint. Plusieurs topologies sont envisageables, on parle de topologie FTTX (Fiber To The X)
qui signifie la fibre jusqu’à X :
- FTTH (Fiber To The Home) : le raccordement par fibre optique s’effectue jusqu’au
domicile ;
- FTTB (Fiber To The Building) : le raccordement par fibre optique s’effectue jusqu’au pied
d’immeuble ;
- FTTC (Fiber To The Curb) : le raccordement par fibre optique s’effectue jusqu’au point de
branchement. Le point de branchement est un point de flexibilité du réseau ODN ;
- FTTN (Fiber To The Node) : le raccordement par fibre optique s’effectue jusqu’au sous-
répartiteur qui est aussi un point de flexibilité du réseau ODN. [1][2][3][4]

Figure 1.06 : Topologie FTTX

9
1.4.1 Architecture point à point

L’architecture point à point utilise une ou deux fibres optiques entre l’OLT et chaque ONU. Les
clients sont raccordés en Ethernet à 100 Mbps ou 1Gbps et l’OLT est un switch Ethernet. Cette
technique est appelé EP2P (Ethernet Point To Point). Cette architecture nécessite un investissement
initial important mais présente l’avantage d’une gestion simplifiée et d’un coût d’exploitation
modéré. [1][2][3][4]

Figure 1.07 : Architecture point à point

1.4.2 Architecture point à multipoint

L’architecture point à multipoint utilise une ou deux fibres optiques entre l’OLT et un point de
flexibilité dans le réseau (sous-répartiteur, point de branchement) et une ou deux fibres optiques
entre ce point de flexibilité et l’ONU. Le partage du segment compris entre l’OLT et le point de
flexibilité entre les différents utilisateurs s’effectue :
- soit de manière active. Dans ce cas, le point de flexibilité héberge un switch Ethernet. On
obtient un système AON (Active Optical Network) qui est une évolution naturelle du
système point à point, car ce dernier trouve rapidement sa limitation dans la saturation des
câbles optiques ;

Figure 1.08 : Architecture AON

- soit de manière passive. Dans ce cas, le point de flexibilité héberge un coupleur optique
passif ou splitter. On obtient un système PON (Passive Optical Network). [1][2][3][4]

10
 Figure 1.09 : Architecture PON

1.5 Les réseaux optiques passifs

Les réseaux optiques passifs se basent sur l’architecture point à multipoint passif. L’architecture
point à multipoint passif est la plus rentable pour déployer les réseaux d’accès optique car elle
permet de réduire l’investissement en fibre, en répéteurs et en terminaux de ligne. Elle est la solution
la plus adoptée par les opérateurs car elle offre la possibilité de partager la même infrastructure pour
8,16, 32, 64 ou 128 clients. Les débits fournis par les réseaux PON varient actuellement de 155
Mbps à 10 Gbps partagés entre les clients dans les sens montant et descendant. Le débit peut être
égal (symétrique) ou différent (asymétrique) dans les deux sens de transmission. [1][2][3][4]

Figure 1.10 : PON en réseau d’accès

1.5.1 Principe des réseaux PON

Le PON permet de mutualiser une partie de l’infrastructure entre plusieurs clients. L’élément clé de
l’architecture est le splitter 1 vers k. Il a pour rôle de partager le signal optique pour la voie dite
descendante (de l’OLT vers les ONU) et de recomposer le signal à partir des multiples signaux
remontant dans l’autre sens (des ONU vers l’OLT). On utilise une seule fibre optique entre l’OLT
et le splitter et une fibre optique différente entre le splitter et chaque ONU. Les fibres optiques
fonctionnent en diplex c’est-à-dire qu’une longueur d’onde différente est utilisée pour chaque sens

11
de transmission (à ne pas confondre avec le fonctionnement duplex qui est une communication
bidirectionnelle utilisant la même longueur d'onde pour les deux sens de transmission sur une même
fibre). Le type de fibre optique utilisé est généralement la fibre optique monomode. [1][2][3][4]

Figure 1.11 : Méthode transmission dans les PON

Dans les sens descendant (aval), les données sont diffusées à tous les ONU, mais chaque utilisateur
ne reçoit que les informations qui lui sont destinées grâce à l’adresse de destination contenu dans
les trames d’informations. Cette propriété est particulièrement intéressante puisque, si un utilisateur
n’utilise pas son accès ou qu’il l’utilise peu, son débit peut être attribué aux autres utilisateurs.

Figure 1.12 : Sens descendant

Dans le sens montant (amont), chaque ONU utilise à l’émission un procédé d’accès multiple à
répartition dans le temps TDMA (Time Division Multiple Access). Les ONU se partagent les time-
slots de la trame temporelle montante afin de transmettre les informations. La distribution des
intervalles de temps est ordonnée par l’OLT. [1][2][3][4]

12
 Figure 1.13 : Sens montant

1.5.2 Topologie

Les PON peuvent être organisées :

- en étoile : un splitter en sortie de chaque port PON de l’OLT dessert plusieurs ONU
- en arbre : les splitters sont mis en cascade, un splitter peut desservir plusieurs sous-branches
- en bus : les splitters sont mis en série
C’est l’architecture en arbre qui est la plus souvent déployée, avec deux niveaux de splitters. Par
exemple, un splitter est situé au niveau du central ou du sous-répartiteur et un deuxième situé au
plus près des abonnés. [1][2][3][4]

(a) (b) (c)

Figure 1.14 : (a) Topologie en étoile, (b) Topologie en arbre (c) Topologie en bus

1.5.3 Terminologie et technique utilisés dans les réseaux PON

Les réseaux optiques passifs utilisent les mêmes techniques de transmission optique connues jusqu’à
ce jour. Les dispositifs émetteurs et récepteurs de signaux optiques sont directement intégrés au sein
des équipements. Les termes habituels employés pour parler de la transmission optique restent
valables. Néanmoins, de nouveaux vocabulaires propres aux PON seront introduits dans la suite.

13
1.5.3.1 Les équipements

a) OLT
L’OLT a pour fonction d’assurer d’un côté l’interconnexion du réseau PON avec les autres réseaux
et de l’autre côté d’émettre et de recevoir les informations au sein du réseau PON à travers les fibres
optiques. Un châssis OLT dispose de plusieurs cartes de collecte permettant de recevoir les services
à partir d'un routeur ou directement d'une plateforme de services. D’autres cartes réseau fournissent
ensuite la sortie optique vers l'architecture PON. Un seul châssis OLT possédant 16 cartes de sortie
à raison de 2 ports optiques par carte et dont chaque port de sortie permet de desservir jusqu'à 64
ONU permet alors de gérer jusqu’à 2048 clients. [1][2][3][4]

Figure 1.15 : Châssis OLT Alcatel-Lucent

b) ONT/ONU
L'ONT/ONU assurent la connexion avec les terminaux de l’utilisateur sur les interfaces spécifiques
de ces derniers. Un ONT/ONU dispose de plusieurs port RJ45 pour connecter les ordinateurs. Il
peut comporter un connecteur coaxial pour la télévision ou un port RJ11 pour le téléphone
analogique. Un port particulier servira à connecter la fibre optique desservant l’abonné à l’aide du
connecteur approprié. [1][2][3][4]

Figure 1.16 : Photographie d’un ONT/ONU

c) Splitter
Le splitter est un équipement passif sans électronique donc non alimenté en électricité dont le
fonctionnement est basé sur la seule propagation de la lumière à l’intérieur des fibres. Dans le sens

14
descendant, le coupleur divise le signal optique en provenance de l’OLT. Dans le sens montant, il
combine par addition les signaux optiques en provenance des ONU. Le coupleur n’est pas capable
d’aiguiller, de modifier, de retarder ou de bloquer les signaux qui le traversent. [1][2][3][4]

Figure 1.17 : Splitter 1x16

1.5.3.2 Code en ligne

Comme tout système de transmission optique, les PON utilisent également les codes en ligne. Le
codage en ligne utilisé pour la transmission dans les PON est le codage NRZ (Non Return to Zero).
La convention employée au niveau logique optique est la suivante:
- forte intensité de la lumière émise pour la valeur binaire « 1 » ;
- faible intensité de la lumière émise pour la valeur binaire « 0 ». [5]

1.5.3.3 Budget optique

Le budget optique comptabilise la perte ou l'atténuation optique possible entre un émetteur et un

récepteur reliés par des composants optiques passifs tels que fibres, coupleurs, atténuateurs ou
encore multiplexeurs. Cette notion de budget optique prend de l'importance pour les PON. Elle
constitue la principale limite sur la portée dans la réalisation d'architecture d'accès optique. [1][4][5]

1.5.3.4 Ranging

Le ranging est une technique très importante utilisée dans les PON. Il s'agit d'un calcul par l'OLT
de la distance des différents ONU du PON. En effet, la distance entre l’OLT et chaque ONU est
différente. Un échange de trames permet de récupérer le délai de propagation aller-retour RTD
(Round Trip Delay). Suite à cet échange, l'OLT transmet aux ONU un délai d'égalisation en temps.
Le but est de recaler les émissions de tous les ONU sur celles de l'ONU le plus éloigné pour éviter
les collisions dues aux différences de délai de propagation. [1][4][5]

15
1.5.3.5 Portée logique et portée physique

La portée logique est définie comme correspondant à la distance maximale pouvant être atteinte
pour un système de transmission donné indépendamment du budget optique. La portée logique est
donc la distance maximale entre un ONU et un OLT sans tenir compte de la limitation de la couche
Physique. La portée physique est la distance physique maximale entre l’ONU et l’OLT. Elle est
inférieure à la portée logique. [1][4][5]

1.5.3.6 Distance différentielle le long des fibres

Puisque la distance entre l’OLT et chaque ONU est différente, la distance différentielle le long des
fibres est la distance entre l’ONU la plus proche et l’ONU la plus éloignée de l’OLT, celui-ci étant
relié à plusieurs ONU. [5]

1.5.3.7 Temps moyen de propagation du signal

C’est la moyenne des temps de propagation d'un signal en amont et en aval entre des points de
référence. Elle est déterminée en mesurant le temps de propagation aller-retour, puis en divisant ce
temps par 2. [5]

1.5.4 Sécurité dans les réseaux PON

On entend par sécurité ici, les problèmes d'accès aux données que les PON soulèvent. La menace
principale réside dans le fait que les trames descendantes sont diffusées à tous les ONU. Si un
utilisateur malicieux venait à reprogrammer son ONU, il pourrait ainsi avoir accès à toutes données
descendantes de chaque utilisateur. C'est à ce fait "d'écouter aux portes" que le système de sécurité
des PON répond. Les mécanismes de sécurité reposent généralement l’utilisation un algorithme de
cryptage tel que l'AES (Advanced Encryption Standard). D'autres menaces plus exotiques seraient
aussi remarquables mais sont abandonnées car ce sont des attaques inenvisageables pour leur rapport
effort déployé / résultat. [1][4]

1.5.5 Les standards de PON

Plusieurs standards de PON existent. Les différences entre les standards concernent essentiellement
le mode de trafic, les débits dans le sens montant et le sens descendant et l’organisme de
normalisation à l’origine du standard.

16
1.5.5.1 Les organismes de normalisation

Les deux principaux organismes de normalisation des PON sont : l’ITU-T (International
Telecommunication Union – Telecommunication) et l’IEEE (Institute of Electrical and Electronics
Engineers). Dans le domaine de l'accès optique partagé, l'ITU-T la chambre de finalisation et
d'officialisation des options prises par le groupe de travail FSAN (Full Service Access Network).
Le FSAN est un organisme piloté par des opérateurs et des équipementiers. Le FSAN est fort de 76
compagnies membres. Ce groupe de travail informel travaille comme un groupe de pré-
normalisation [1] [4]. Le calendrier de normalisation des PON est donné à la Figure1.18.

Figure 1.18 : Systèmes IEEE et FSAN/ITU-T PON et leur état de standardisation dans le temps

1.5.5.2 APON et BPON

L’APON (Asynchronious Transfer Mode Passive Optical Network) est issu des techniques PON
associées à l’ATM (Asynchronious Transfer Mode). Il a ouvert la voie aux liaisons à 155/155 Mbps
(Descendant/Montant) partagée entre 32 abonnés au maximum. La solution APON demeure
complexe et coûteuse. Elle ne peut pas offrir de services vidéo. Le débit est limité et la récupération
d’horloge peut poser des difficultés. Le BPON (Broadband Passive Optical Network) est une
évolution de l’APON à 622/155 Mbps. Les flux descendant et montant des APON et BPON sont
composés de trames de 153µs structurées en cellules ATM. La taille de ces cellules pour les sens
descendant et montant est respectivement de 53 et 56 octets. Des cellules PLOAM (Physical Layer

17
Operation Administration and Maintenance) sont contenues dans les flux descendant et montant.
Les PLOAM gèrent l'identification, la synchronisation et l'allocation de la bande passante des ONU
pour le flux montant. Elles arbitrent également la gestion des opérations de maintenance et
d'administration entre les ONU et l'OLT. [1][2][4][5][6]

Figure 1.19 : Format de trame BPON asymétrique à 622/155 Mbps, (a) descendant et (b) montant

Plus le débit augmente plus le nombre de cellules ATM transportées dans une trame, augmente.
Pour un système à 155Mbps, la trame remontante propose 53 cellules ATM. Le Tableau 1.02
synthétise le nombre de cellules ATM disponibles dans une trame en voie descendante et remontante
pour les différents débits. [1][2][4][5][6]
Débit Voie montante Voie descendante
155 Mbps 53 54
622 Mbps 212 216

Tableau 1.02: Nombre de cellules ATM disponibles dans une trame en voies descendante et
montante

1.5.5.3 EPON ou 1GEPON et 10GEPON

En janvier 2001, le groupe de normalisation de l'IEEE a lancé des études sur l'avènement de la
technologie Ethernet dans le réseau d'accès, à la fois pour les réseaux résidentiels et les réseaux
professionnels. L'EPON (Ethernet Passive Optical Network) ou 1GEPON (1-Gigabit Ethernet
Passive Optical Network) est un réseau PON transportant du trafic sur encapsulation Ethernet
comme défini dans la norme IEEE 802.3. Il est aussi basé sur une infrastructure passive de type
point à multipoint pour un maximum de 16 clients. Deux longueurs d'ondes différentes ont été
utilisées pour diviser le trafic descendant (1490 nm) et remontant (1310 nm). La portée du système
a été définie entre 10km et 20 km. Les données sont diffusées depuis l'OLT vers les ONU en paquets

18
de 1518 octets (IEEE 802.3ah à 1.25 Gbps). Chacun des ONU ne prend en compte que les paquets
qui le concernent. Le trafic montant utilise une répartition dans le temps (TDMA), en
synchronisation avec les flux descendants. [1][2][3][4]

La norme 10GEPON (10-Gigabit Ethernet Passive Optical Network) est une évolution de l'EPON
et est compatible avec cette dernière. L’EPON offre un débit symétrique de 1 Gbps tandis que le
10GEPON un débit symétrique de 10 Gbps ou asymétrique de 10/1 Gbps (Descendant/Montant).
[1][2][3][4]

1.5.5.4 GPON

Le GPON (Gigabit-capable Passive Optical Network) offre un débit maximal de 2,5 Gbps en sens
descendant et 1,25 Gbps en sens montant, partagé pour un maximum de 64 abonnés. Il emploie le
protocole d’encapsulation GEM (GPON Encapsulation Method) pour le transport de services. Le
protocole GEM supporte à la fois l’Ethernet, l'ATM et le TDM (Time Division Multiplexing) ; les
trames ont une taille variable (jusqu’à 4095 octets avec un en-tête de 5 octets), elles sont identifiées
par un numéro de port et peuvent être fragmentées.
La gamme des longueurs d'ondes de fonctionnement dans le sens descendant est comprise entre
1480 et 1500 nm. La gamme des longueurs d'ondes de fonctionnement dans le sens montant est
comprise entre 1260 et 1360 nm. Le GPON présente également une option avec un triplexeur en
réception à l'ONU pour la diffusion de vidéo sur un canal analogique à 1550 nm. Néanmoins cette
option semble de plus en plus être abandonnée au profit de la vidéo sur IP, ce qui permet de
supprimer les composants analogiques plus coûteux. En effet ce type de transmission nécessite une
importante linéarité (puissance optique / fréquence) des composants optoélectroniques.

Figure 1.20 : Plan d'allocation des longueurs d'onde du GPON

Le partage des ressources dans le sens montant s'effectue par le TDMA. Chaque client a un intervalle
de temps bien précis pour émettre afin de ne pas interférer avec un autre client. Pour une
transmission descendante, les données sont réparties dans les trames temporelles en fonction du
client destinataire. Chaque ONU reçoit tout le flux d'informations car les données sont diffusées,

19
mais la synchronisation et le codage lui permettent de récupérer uniquement les données qui lui sont
destinées. La trame descendante se compose d’un bloc de commande physique descendant PCBd
(Physical Control Block downstream) et de la charge utile. La trame montante se compose de
multiples rafales de transmission.

Figure 1.21 : Structure des trames du GPON

Le GPON utilise un code correcteur d'erreur FEC (Forward Error Correction). L’utilisation du FEC
permet ainsi d'augmenter le budget optique du lien de l'ordre de 3 à 4 dB. En conséquence, l'OLT
et les ONU peuvent supporter des débits plus élevés, une plus longue distance de transmission ainsi
qu'un plus grand taux de couplage par arbre PON. [1][3][4][7][8][9]

1.5.5.5 NGPON

A partir du GPON, les industriels et les exploitants du FSAN ont réfléchi aux évolutions possibles
de la distribution en fibre optique, sous le nom de "Projet NGA" (Next Generation Access). Le débit
et la portée peuvent être augmentés tout en gardant l’architecture point à multipoint et le même
nombre d’abonnés desservis par réseau ou en portant le nombre d’éclatements à 1024 en acceptant
des compromis. Les standards NGPON (Next Generation PON) ont alors vu le jour. Un premier, le
NGPON1, normalisé en 2010, est caractérisé par sa capacité à réutiliser l’infrastructure déployée
pour le GPON. Le NGPON2, en cours de normalisation, se libère de la contrainte de coexistence
obligatoire avec l'architecture préalablement déployée. [1][4]

20
Le Tableau 1.03 donne un récapitulatif des standards de PON. [1][2][3][4][5][6][7][8][9]

GEPON (a)
APON BPON GPON
10 GEPON (b)
(a)IEEE 802.3.ah
Normes G.982 G.983 G.984
(b)IEEE 802.3.av
Protocoles ATM ATM Ethernet ATM, Ethernet, GEM
Longueur d’onde
1310/1550 nm 1310/1490 nm 1310/1490 nm 1310/1490 nm
(montant/descendant)
155 ou 622 (a) 1 Gbps
Débits descendants 155 Mbps 2.5 ou 1.25 Gbps
Mbps (b) 10 Gbps
(a) 1 Gbps 1.25 Gbps ou 622 Mbps
Débits montants 155 Mbps 155 Mbps
(b) 10 Gbps ou 155 Mbps
Distance maximum 20 Km 20 Km 20 Km 60 Km
Taux de couplage 8 ou 16 ou 32 32 32 32 ou 64
128 Kbps à 4
Débit par abonné 3 à 13 Mbps 30 à 100 Mbps 20 à 80 Mbps
Mbps
RNIS avec Service Triple Play avec
Intégration Bande étroite Ethernet seulement
CATV options

Tableau 1.03: Standards de PON

1.5.6 Les services pouvant être offerts par les réseaux PON

Les réseaux PON sont en mesure de prendre en charge, pour les abonnés résidentiels et les clients
professionnels, la totalité des services connus actuellement et des services nouveaux en cours de
discussion. Les services couvrent un large domaine de prescriptions réseau telles que le débit, la
symétrie ou l'asymétrie et les délais. On peut citer la télévision HD (Haute Définition) et la télévision
3D (3 Dimensions), la VOD (Video On Demand), le transfert électronique de données,
l'interconnexion de réseaux locaux, la téléphonie (VoIP), l’internet à très haut débit, etc... [1][4][7]

1.6 Conclusion

Le réseau d’un opérateur de télécommunication est constitué d’un réseau de transport

interconnectant les réseaux d’accès. Plusieurs moyens permettent de réaliser le réseau d’accès :
câbles, fils électriques, supports hertziens et la fibre optique. Le réseau d’accès par fibre optique ou
réseau d’accès optique existe en point à point et en point à multipoint. L’architecture point à
multipoint peut être active ou passive. Les réseaux optiques passifs PON sont basés sur
l’architecture point à multipoint passive. Il existe actuellement de nombreux standards de PON.
Chez l’ITU-T, on est déjà à la nouvelle génération de PON. Le chapitre suivant est dédié au premier
standard de cette nouvelle génération.

21
 CHAPITRE 2

LE XGPON

2.1 Introduction

L’ITU-T FSAN a distingué 2 grandes étapes de migration pour remplacer le GPON. Une première
étape dite « NGPON1 » intègre les solutions permettant une montée en débit jusqu'à 10Gbps et qui
nécessitent une compatibilité avec une infrastructure existante. Une seconde étape dite « NGPON2 »
permettra de poursuivre la montée en débit mais cette fois l'opérateur s'autorise des reprises
majeures de son infrastructure. Le NGPON1 peut donc être superposé à un système GPON en
activité sur la même infrastructure, en autorisant ainsi la migration progressive des clients sans
perturber les clients restés sur le GPON. Il existe deux variantes du NGPON1 : le XGPON1 et le
XGPON2. Le XGPON1 offre un débit asymétrique de 10/2.5Gbps tandis que pour le XGPON2 le
débit est de 10Gbps symétrique. La normalisation du NGPON1 a débuté en 2009. En 2010, la
variante XGPON2 du NGPON1 a été abandonnée au profit d’une migration vers le NGPON2. Le
NGPON2 est encore en cours de normalisation actuellement. Le NGPON1 a donc été renommé sous
le standard XGPON. Le X signifie 10 en chiffre romain et sert à indiquer l’augmentation du débit à
10Gbps.

2.2 Caractéristiques générales

Le standard XGPON constitue la série de recommandation G.987 de l’ITU-T. Le XGPON se

caractérise par une montée en débit par rapport au GPON. Cependant, son infrastructure passive se
voudrait calquée sur celle du GPON afin de faciliter la migration. Le XGPON utilise pour le
transport des services le protocole d’encapsulation XGEM (XGPON Encapsulation Method) qui
supporte tout comme le GEM à la fois l’Ethernet, l’ATM et le TDM. Il utilise également le système
de correction d’erreur FEC. Le XGPON permet d’assurer tous les services connus à l'heure qu'il est
et les nouveaux services à l'étude, destinés aux abonnés résidentiels et aux entreprises clientes : la
téléphonie (VoIP), la télévision en temps réel IPTV (Internet Protocol Television), la télévision HD
ou 3D, la diffusion numérique, les lignes privées (E1, T1), l’internet à très haut débit, les services
IP (Internet Protocol) et multimédia tel que la vidéoconférence et la VOD, la télémédecine...
[10][11][12][13]

22
2.3 Architecture en couche

Dans le XGPON, la couche de support de transmission du modèle général de référence de protocole

pour les réseaux d’accès, défini par l’ITU-T dans la recommandation G.902 [14] (voir Annexe 1),
est divisé en deux :
- la couche de convergence de transmission XGTC (XGPON Transmission Convergence)
- la couche dépendante du support physique PMD (Physical Media Dependent)
XGTC
Couche Support de Transmission
PMD
Figure 2.01 : Architecture en couche du XGPON

La couche PMD définit les caractéristiques de transmission : le débit, les longueurs d’ondes, le
budget optique… Elle est équivalente à la couche physique du modèle OSI (Open System
Interconnection). La couche de convergence de transmission XGTC est l’équivalente de la couche
liaison du modèle OSI. Les protocoles MAC (Medium Access Control) sont définis dans la couche
XGTC. [10][11][12][13]

2.4 PMD

La couche PMD définit les caractéristiques de transmission. Elles sont spécifiées dans la
recommandation G.987.2. [12]

2.4.1 Débit binaire nominal

Le XGPON se caractérise par un débit descendant de 10Gbps associé à un débit montant de 2,5
Gbps partagés entre les différents utilisateurs. Les valeurs exactes sont :
- Sens descendant : 9.95328 Gbps
- Sens montant : 2.48832 Gbps [12]

2.4.2 Longueur d’onde de fonctionnement

Les intervalles longueurs d’ondes utilisées sont :

- Sens descendant : 1575-1580 nm
- Sens montant : 1260-1280 nm
Les valeurs habituelles sont : 1577nm/1270nm (descendant/montant). [12]

23
2.4.3 Codage en ligne

Le code en ligne utilisé dans les deux sens de transmission est le code NRZ (Non Return to Zero).
La convention employée au niveau logique optique est la suivante:
- forte intensité de la lumière émise pour la valeur binaire « 1 » ;
- faible intensité de la lumière émise pour la valeur binaire « 0 ». [12]

2.4.4 Type de fibre

Le type de fibre utilisé est la fibre optique monomode conforme à la normalisation G.652 l’ITU-T.
(Voir Annexe 2). [12][15]

2.4.5 Budget optique

Deux classes de budget optique ont été définies pour le XGPON: La classe N1 (Nominal 1) pour un
budget optique de 14 à 29 dB et la classe N2 (Nominal 2) pour un budget optique de 16 à 31 dB.
[12]

2.4.6 Taux de couplage

Le taux de couplage minimum est 1:64 pour permettre la coexistence avec le GPON. Mais le
XGPON permet un taux de couplage de 1:128 voire même 1:256 en fonction du budget optique.
[12]

2.4.7 Distance

Le XGPON a une portée de 60 km avec une différence maximale de 20km entre le client le proche
et celui le plus éloigné du central. [12]

2.4.8 Temps moyen maximal de propagation des signaux

Dans le réseau XGPON, on doit pouvoir assurer des services qui nécessitent un temps moyen
maximal de propagation des signaux de 1,5 ms. [12]

2.5 XGTC

Les spécifications de la couche XGTC sont définies dans la recommandation G.987.3 de l’ITU-T.
La couche XGTC est équivalente à la couche 2 du modèle OSI. Le protocole MAC du XGPON est

24
défini dans la couche XGTC. La couche XGTC spécifie les formats et procédure de mappage entre
les SDU (Service Data Unit) des couches supérieures d’un côté et le train binaire pour moduler la
porteuse optique de l’autre côté. [13]
Elle est divisée en trois sous-couches :
- La sous-couche XGTC Service Adaptation
- La sous-couche XGTC Framing
- La sous-couche PHY Adaptation (Physical Interface Adaptation)

La couche XGTC est à la fois présente du côté de l’OLT et du côté de l’ONU. Dans le sens
descendant, l’interface entre la couche XGTC et la couche PMD est représenté par un train binaire
continu au débit nominal qui est partitionné en trames de 125µs. Dans le sens montant, l’interface
entre la couche XGTC et la couche PMD est représenté par des bursts. Les étapes de la
transformation lors de la procédure de mappage entre les SDU et les trains binaires dans le sens
montant et le sens descendant sont montrées respectivement dans les Figures 2.02 et 2.03. [13]

Figure 2.02 : Mappage des SDU dans le sens descendant

25
 Figure 2.03 : Mappage des SDU dans le sens montant

2.5.1 Les fonctions de chaque sous-couche XGTC

2.5.1.1 La sous-couche XGTC Service Adaptation

La sous-couche XGTC Service Adaptation est responsable de l’encapsulation, du multiplexage et

de la délimitation des SDU provenant des couches supérieures.

En émission, la sous-couche XGTC Service Adaptation accepte les SDU des couches supérieures,
représentée par des trames de données utilisateur et du trafic de gestion et de contrôle OMCI (ONU
Management and Control Interface), effectue la fragmentation si nécessaire, attribue un
identificateur XGEM Port-ID à un SDU ou un fragment de SDU, et lui applique la méthode
d'encapsulation XGEM pour obtenir une trame XGEM ou XGEM frame. La charge utile du XGEM
frame appelée XGEM payload peut éventuellement être chiffrée. Une série de XGEM frame forme
la charge utile d'un XGTC frame dans le sens descendant ou la charge utile d’un XGTC burst dans
le sens montant. La charge utile d’un XGTC frame ou d’un XGTC burst est appelé XGTC payload.

26
En réception, la sous-couche XGTC Service Adaptation accepte la charge utile des XGTC frames
et des XGTC bursts, effectue la délimitation des XGEM frames, effectue le filtrage des XGEM
frames à partir des XGEM Port-ID, décrypte le XGEM payload si le cryptage a été effectuée à
l’émission, réassemble les SDU fragmentés, et délivre les SDU aux clients respectifs. [13]

2.5.1.2 La sous-couche XGTC Framing

La sous-couche XGTC Framing est responsable de la construction et l'analyse des champs d’en-tête
de trame en charge la fonctionnalité de gestion du XGPON.

A l’émission, la sous-couche XGTC Framing accepte de la sous-couche XGTC Service Adaptation

plusieurs séries de XGEM frame formant le XGTC payload, et construit le XGTC frame en aval ou
le XGTC burst en amont en ajoutant les en-têtes de gestion et/ou les en-queues.

En réception, la sous-couche XGTC Framing accepte les XGTC frames ou XGTC bursts, analyse
les champs d’en-tête, extrait les flux de messages de gestion se trouvant dans ces en-têtes, et délivre
les XGTC payload à la sous-couche XGTC Service Adaptation. [13]

2.5.1.3 La sous-couche PHY Adaptation

La sous-couche PHY Adaptation comprend les fonctions qui modifient le train binaire de
modulation optique dans le but d'améliorer la détection, la réception et la délimitation du signal
transmis sur le support optique.

A l’émission, la sous-couche PHY Adaptation accepte les XGTC frames (en aval) ou les XGTC
bursts (en amont) de la sous-couche XGTC Framing, les partitionne en blocs de données FEC,
calcule et ajoute le champ de parité FEC pour chaque bloc de données FEC, effectue le scrambling
ou embrouillage, ajoute de bloc de synchronisation aval PSBd (Physical Synchronization Block
downstream) ou amont PSBu (Physical Synchronization Block upstream), et fournit l'alignement de
synchronisation du train de bits résultant. A stade, on obtient un PHY frame en aval ou un PHY
burst en amont.

En réception, la sous-couche PHY Adaptation effectue la synchronisation et la délimitation du train

binaire entrant, désembrouille le contenu du PHY frame ou du PHY burst, exécute la correction
d'erreur, extrait les symboles de parité FEC, et délivre les XGTC frames (si aval) ou les XGTC
bursts (si amont) à la sous-couche XGTC Framing. [13]

27
2.6 Gestion d’un système XGPON

Les informations de contrôle, d'exploitation et de gestion dans un système XGPON sont transportées
sur trois canaux: le canal OAM (Operation Administration and Management) imbriqué, le canal
PLOAM et le canal OMCI. Les canaux OAM imbriqués et PLOAM gèrent les fonctions des couches
PMD et XGTC. Le canal OMCI fournit un système uniforme pour la gestion des couches
supérieures. [13]

2.6.1 Le canal OAM imbriqué

Le canal OAM imbriqué est fourni par les champs d'en-tête et les structures imbriquées du XGTC
frame aval et du XGTC burst amont. Ce canal offre un chemin à faible latence pour les informations
de contrôle urgentes parce que chaque pièce de l'information est directement mappée dans un champ
spécifique. Les fonctions qui utilisent ce canal comprennent: la synchronisation et le profil des PHY
bursts amont, l’allocation de la bande passante, la gestion de l’énergie, la signalisation pour
l’allocation dynamique de la bande passante... [13]

2.6.2 Le canal PLOAM

Le canal PLOAM est à base de message et est transporté dans un espace dédié du XGTC frame aval
et du XGTC burst amont. Ce canal est utilisé pour toutes les informations de gestion de la couche
PMD et de la couche XGTC qui ne sont pas envoyées par le canal OAM imbriqué. [13] (La liste
des messages PLOAM se trouve dans l’Annexe 3)

2.6.3 OMCI

Le canal OMCI ou OMCC (ONU Management and Control Channel) est utilisé pour gérer les
couches de services se trouvant au-dessus de la couche XGTC. [13]

2.7 Le multiplexage du trafic dans le XGPON

Dans le sens descendant, la fonctionnalité de multiplexage de trafic est centralisée. L’OLT

multiplexe les XGEM frames sur le support de transmission en utilisant des XGEM Port-ID comme
clé pour identifier les XGEM frames qui appartiennent à différentes connexions logiques. Une
connexion logique est représentée par un XGEM Port. Chaque ONU filtre les XGEM frames en
fonction de leurs XGEM Port-ID et traite uniquement les XGEM frames qui lui appartiennent. Un

28
port XGEM de multidiffusion peut être utilisé pour transporter des XGEM frames pour plusieurs
ONU. [13]

Figure 2.04 : Multiplexage dans le sens descendant

Dans le sens montant, la fonctionnalité de multiplexage de trafic est distribuée. L’OLT accorde des
opportunités de transmission aux entités de trafic au sein des ONU, c’est ce qu’on nomme des
allocations de bande passante montante. Les entités de trafic de l'ONU qui sont bénéficiaires des
allocations de bande passante montante sont identifiées par leur Alloc-ID (Allocation Identifier).
Les allocations de bande passante pour différents Alloc-ID sont multiplexées dans le temps en
suivants les indications de l’OLT. Plusieurs connexions logiques ou XGEM Port sont multiplexés
dans un Alloc-ID, en utilisant le XGEM Port-ID comme clé de multiplexage. [13]

Figure 2.05 : Multiplexage dans le sens montant

2.7.1 ONU-ID

L'ONU-ID (ONU Identifier) est un identificateur de 10 bits que l'OLT affecte à un ONU pendant le
processus d’activation de l’ONU en utilisant le canal PLOAM. L'ONU-ID est utilisé pour identifier

29
un ONU et est unique dans le PON. La répartition des valeurs ainsi que leur utilisation sont présenté
dans le Tableau 2.01. [13]

ONU-ID Désignation Commentaire

Assigné par l’OLT à activation de l’ONU.
0-1022 Assignable Utilisé pour identifier l'expéditeur d'un burst ou d’un message
PLOAMu et le destinataire d'un message PLOAMd.
Broadcast / non Adresse de broadcast dans un PLOAMd.
1023
assigné ONU non assigné dans un PLOAMu.

Tableau 2.01: ONU-ID

2.7.2 Alloc-ID

L'Alloc-ID est un nombre 14 bits que l’OLT attribue à un ONU pour identifier une entité de trafic
qui est un bénéficiaire des allocations de bande passante en amont au sein de cette ONU. Une entité
de trafic peut être représentée soit par un conteneur de transmission T-CONT (Transmission
Container) soit par le canal OMCC amont. Un T-CONT sert à regrouper plusieurs flux de trafic
montant. Un ou plusieurs Alloc-ID sont assignés à chaque ONU y compris au moins l’Alloc-ID par
défaut. L’Alloc-ID par défaut est numériquement égale à l’ONU-ID et est attribué implicitement
lors de l'activation ONU. Un Alloc-ID est unique pour un PON donné et ne peut être affecté qu’à
un ONU. Les valeurs des Alloc-ID et leur utilisation sont réparties dans le Tableau 2.02. [13]

Alloc-ID Désignation Commentaire

Alloc-ID par défaut
0-1022 Par défaut Assigné implicitement
Egal à l’ONU-ID
1023 Broadcast Alloc-ID de diffusion
Si plus d'un seul Alloc-ID est nécessaire pour un ONU, l'OLT
assigne des Alloc-ID supplémentaires à cet ONU en sélectionnant
1024-16383 Assignable
un numéro unique de cette rangée et la communique à l'ONU en
utilisant le message PLOAM Assign_Alloc-ID (Voir Annexe 3).

Tableau 2.02: Alloc-ID

2.7.3 XGEM Port-ID

L'identificateur de port XGEM Port-ID est un nombre 16 bits qui est attribué par l’OLT à une
connexion logique ou XGEM Port. L'affectation d’un XGEM Port-ID pour la connexion logique
OMCC est implicite à l’attribution de l’ONU-ID. L’OMCC Port-ID est numériquement égale à

30
l'ONU-ID. L’assignement des autres XGEM Port-ID aux ONU sont effectuées via Le canal OMCI.
[13]
XGEM Port-ID Désignation Commentaire
XGEM Port-ID par défaut
Assigné implicitement
0-1022 Par défaut
Egal à l’ONU-ID
Utilisé pour transporter le trafic OMCC
Si plus d'un seul XGEM Port-ID est nécessaire pour un ONU,
l'OLT assigne des XGEM Port-ID supplémentaires à cet
1023-65534 Assignable
ONU en sélectionnant un numéro unique de cette rangée et la
communique à l'ONU en utilisant le canal OMCI
65535 Inactif Réservé pour les XGEM Port-ID inactifs

Tableau 2.03: XGEM Port-ID

2.8 Media Access Control

Dans un système XGPON, l'OLT fournit un contrôle d'accès au support ou MAC pour le trafic dans
le sens montant. Dans le concept de base, chaque PHY frame descendant contient une carte
d’allocation de la bande passante montante BWmap (Bandwidth map) qui indique les emplacements
de transmission de chaque ONU dans le PHY frame montant correspondant. De cette manière,
aucune collision de transmission n’est possible Le concept de contrôle d'accès au support dans un
système XGPON est illustré à la Figure 2.06. [13]

Figure 2.06 : Concept MAC XGTC

L'OLT transmet un PHY frame descendant toutes les 125 µs. A chaque PHY descendant reçu, un
ONU associe le PHY frame montant correspondant. [13]

31
Un BWmap contient un certain nombre de structures d’allocation, chaque structure d'allocation étant
destinée à un Alloc-ID particulier d'un ONU spécifique. Une séquence d'une ou plusieurs structures
d’allocation adressée aux Alloc-ID qui appartiennent au même ONU forme une série d'allocation.
Chaque structure d’allocation contient le StartTime et le GrantSize. Le Start time indique
l’emplacement de transmission destiné à chaque Alloc-ID par rapport au début du PHY frame
montant. Le GrantSize indique la taille de transmission accordée à chaque Alloc-ID. [13]

2.9 Structure détaillée des trames XGTC

2.9.1 Structure de la trame XGTC descendante

La trame XGTC descendante ou le XGTC frame aval possède une taille fixe de 135 432 octets et se
compose de l’en-tête XGTC ou XGTC frame header et de la charge utile ou XGTC payload. Le
XGTC payload est formé à l'émission et traité en réception par la sous-couche XGTC Service
Adaptation. Le XGTC header du XGTC frame se compose d'une structure de taille fixe HLend et
deux partitions de taille variable : BWmap et PLOAMd. [13]

Figure 2.07 : Format du XGTC frame aval

2.9.1.1 HLend

HLend est une structure de 4 octets, HLend contrôle la taille des partitions (BWmap et PLOAMd)
de longueur variable du XGTC header. Il comporte 3 champs :
- BWmap length : champ de 11 bits contenant un entier non signé N indiquant le nombre de
structure d’allocation dans la partition BWmap du XGTC header
- PLOAM count : champ de 8 bits contenant un entier non signé S indiquant le nombre de
message PLOAM dans la partition PLOAMd du XGTC header

32
 - HEC (Hybrid Error Correction) : champ de 13 bits de détection et de correction d’erreur
pour la structure HLend. Le code correcteur utilisé est une combinaison de code
BCH(63,13,2) tronqué, opérant sur les 31 premiers bits du champ HLend, et d’un bit de
parité. [13] (Voir Annexe 4)

2.9.1.2 BWmap

La partition BWmap contient une série de structure d’allocation ou Allocation Structure de 8 octets
chacune. Elle a une taille variable. Le nombre de structure d’allocation est donné dans le champ
BWmap length de HLend. La taille de la partition BWmap est donc de 8N octets. Chaque structure
d’allocation spécifie une allocation de bande passante montante pour un Alloc-ID particulier. Une
séquence d’un ou plusieurs structures d’allocation associées aux Alloc-ID appartenant au même
ONU forme une série d’allocation.

Figure 2.08 : Partition BWmap

Chaque structure d’allocation est formée des champs : Alloc-ID, Flags, StartTime, GrantSize, FWI
(Forced Wake-up Indication), BurstProfile et HEC. [13]
a) Alloc-ID
Le champ Alloc-ID contient un nombre de 14 bits indiquant le récepteur de l’allocation de bande
passante montante. Ce récepteur peut être un conteneur de transmission ou un OMCC. [13]
b) Flags
Le drapeau Flags de 2 bits contient deux indicateurs : DBRu (Dynamic Bandwidth Report upstream)
et PLOAMu. Ces deux indicateurs interviennent dans l’allocation dynamique de la bande passante
montante.

33
 - DBRu=1 signifie que l’ONU à qui appartient la structure d’allocation doit envoyer le rapport
DBRu pour l’Alloc-ID en question dans le burst montant. DBRu=0 signifie que l’OLT ne
demande pas le rapport DBRu.
- PLOAMu : Si ce bit est mis à 1 dans la première structure d'allocation d'une série
d'allocation, l'ONU propriétaire de la série d’allocation doit transmettre un message PLOAM
dans le XGTC header du burst amont. S’il est mis à 0 dans la première structure d'allocation,
le message PLOAM ne doit pas être transmis. Pour toutes les structures d'allocation
suivantes de la même série d’allocation, PLOAMu doit être réglé à 0 à l’émission et sera
ignoré en réception. [13]

c) Champ StartTime
Le champ StartTime contient un nombre de 16 bits qui indique l'emplacement du premier octet du
XGTC burst amont dans le PHY frame amont. StartTime est mesurée à partir du début du PHY
frame amont et a une granularité de 1 mot (4 octets). La valeur de StartTime = 0 correspond au
premier mot du PHY frame amont; la valeur de StartTime = 9719 correspond au dernier mot du
PHY frame amont. Dans chaque série d'allocation, seule la première structure d’allocation comporte
une valeur spécifique de StartTime. Toutes les structures d’allocations restantes de la série
d'allocation portent la valeur de StartTime = 0xFFFF. [13]

d) Le champ GrantSize
Le champ GrantSize contient un nombre 16 bits qui indique la longueur totale XGTC payload+DBru
attribué à une structure d’allocation dans le XGTC burst amont. GrantSize a la granularité de 1 mot
(4 octets). La valeur de GrantSize est égale à zéro s’il ne s’agit que d’une attribution de canal
PLOAM. La valeur minimum non nulle possible de GrantSize est 1, ce qui correspond à un mot de
4 octets allouée pour la transmission d’un DBRu. L'allocation minimum pour un XGTC payload
correct (avec un flag DBRu =0) est de 4 mots (16 octets), auquel cas GrantSize = 4. [13]

e) FWI
Le bit FWI (Forced Wake-up Indication) est utilisé par l’OLT pour la gestion d’énergie des ONU.
FWI=1 est envoyé à un ONU en mode économie d’énergie pour accélérer son réveil. [13]

34
 f) Le champ BurstProfile
Le champ BurstProfile est un champ de 2 bits contenant l'index du profil à utiliser par la sous-couche
PHY Adaptation de l’ONU pour former le PHY burst amont. Cet index se réfère à un ensemble de
profils valides qui est communiquée aux ONU par le canal PLOAM. (Voir Annexe 6) [13]

g) Le champ HEC
C’est le champ de détection et de correction d’erreur pour la structure d’allocation. Le code
correcteur est une combinaison d’un code BCH(63,12,2) tronqué, opérant sur les 63 premiers bits
de la structure d’allocation, et d’un bit de parité. (Voir Annexe 4) [13]

2.9.1.3 PLOAMd

La partition PLOAMd contient zéro, une ou plusieurs messages PLOAM. La longueur de chaque
message PLOAM est de 48 octets. Le nombre de messages PLOAM dans la partition PLOAMd est
donné par le champ PLOAM Count de HLend. La longueur de la partition PLOAMd est donc 48xS
octets. (La liste des messages PLAOM se trouve dans l’Annexe 3). [13]

Figure 2.09 : Structure de la partition PLOAMd

2.9.2 Structure du burst XGTC montant

Dans le sens montant, l'interface entre la sous-couche XGTC Framing et la sous-couche XGTC
PHY Adaptation est représentée par un XGTC burst amont. Le XGTC burst émis par un ONU donné
possède une taille déterminée de manière dynamique. Il se compose du XGTC burst header, d’une
ou plusieurs intervalles d’allocation de bande passante associées à un Alloc-ID spécifique, et du
XGTC trailer. La taille de chaque intervalle d’allocation de bande passante est dictée par la structure
d’allocation correspondant au même Alloc-ID dans le BWmap.

Chaque intervalle d'allocation de bande passante contient la section XGTC payload et peut contenir
l’en-tête d’allocation AO (Allocation Overhead) qui précède le XGTC payload. Le XGTC payload
est fourni à l’émission et traité en réception par la sous-couche Service Adaptation. [13]

35
 Figure 2.10 : Format du XGTC burst

2.9.2.1 XGTC burst header

Le XGTC burst header comprend une section fixe de 4 octets et une section variable. La section
fixe se compose des champs ONU-ID, Ind et HEC. La section variable PLOAMu transporte un
message PLOAM montant. En fonction de la valeur du flag PLOAMu dans la structure d’allocation
correspondant dans le BWMap, cette section peut être ou non incluse dans le XGTC header. Sa
taille est donc soit 0 soit 48 octets. [13]

a) ONU-ID
Le champ ONU-ID est un champ de 10 bits qui contient l’identificateur unique de l'ONU qui
transmet le burst. L'ONU-ID est affectée à l'ONU pendant le processus d'activation. [13]

b) Le champ Ind
C’est un champ de 9 bits qui fournit une signalisation non-sollicitée rapide de l'état ONU. [13]

c) Champ HEC
Champ de détection et de correction d’erreur pour le XGTC burst header, c’est une combinaison de
code BCH(63,12,2) tronqué, opérant les 31 premiers bits du XGTC burst header, et d’un bit de
parité. (Voir Annexe 4). [13]

d) Champ PLOAMu
S’il est présent, ce champ contient exactement un message PLOAM de 48 octets. (La liste des
messages PLOAM se trouve dans l’Annexe 3). [13]

36
2.9.2.2 Allocation Overhead

S’il est présent, l’AO est composé du DBRu. La présence ou non du DBRu est contrôlée par l’OLT
à l’aide du flag DBRu dans la structure d’allocation correspondante dans le BWmap. Le DBRu a
une taille de 4 octets et transporte le rapport d’état du tampon associé à un Alloc-ID. Il est composé
des champs BufOcc (Buffer Occupancy) et CRC (Code de Redondance Cyclique). [13]

a) BufOcc
Ce champ indique l'occupation du tampon. C’est un champ de 3 octets qui contient la quantité totale
de trafic SDU (exprimée en unité de mot de 4 octets) de l’Alloc-ID. Si un SDU a une longueur de
L octets, sa contribution W dans le BufOcc est calculée comme suit :
𝐿
𝑊 = { 4⌉ 𝑠𝑖 𝐿 > 8
⌈
(2.01)
2 𝑠𝑖 0 < 𝐿 ≤ 8
La valeur 0x000000 de BuffOcc signifie un tampon vide. [13]

b) CRC
La structure DBRu est protégée en utilisant un CRC-8 de polynôme 𝑔(𝑥) = 𝑥 8 + 𝑥 2 + 𝑥 + 𝑥. [13]

2.9.2.3 XGTC Trailer

Le XGTC Trailer contient un champ de parité à entrelacement de bit BIP (Bit-Interleaved even
Parity) de 4 octets calculé sur le XGTC burst en entier. Le récepteur de l’OLT vérifie la BIP pour
estimer le BER (Bit Error Rate) sur la liaison optique montante. L’estimation de BER par le BIP
n’est applicable que lorsque la FEC est désactivé dans la sous-couche PHY Adaptation. [13]

2.10 XGEM

Dans le XGPON, les SDU sont transmis dans la section XGTC payload des XGTC frames aval et
des XGTC bursts amont en utilisant la méthode d’encapsulation XGEM. XGEM se charge de la
fragmentation, de l’encapsulation et de la délimitation des SDU dans les deux sens de transmission
aval et amont. XGEM supporte tout type de service comme Ethernet, ATM, TDM, MPLS
(Multiprotocol Label Switching). (Voir Annexe 6).

37
2.10.1 Trame XGEM

2.10.1.1 Structure du XGTC payload

Le XGTC payload est transporté dans les XGTC frames aval et XGTC bursts amont. La taille du
XGTC payload dans le XGTC frame aval est égal la taille du XGTC frame (fixé à 135432 octets)
moins la taille du XGTC header. La taille du XGTC payload dans le XGTC burst est égale à la taille
respective des allocations moins la taille de l’AO. Le XGTC payload contient un ou plusieurs
XGEM frame.

Figure 2.11 : Structure du XGTC payload

Chaque XGEM frame contient un XGEM header de taille fixe et un XGEM payload de taille
variable. [13]

2.10.1.2 L’en-tête de la trame XGEM

La taille du XGEM header est de 8 octets. Le format du XGEM header est montré à la Figure 2.12.

Figure 2.12 : Format du XGEM header

Le XGEM header comprend les champs suivants :

- PLI (Payload Length Indication) : Champ de 14 bits indiquant la longueur L en octets du
SDU ou du fragment de SDU dans le XGEM payload.
- Key index : Champ de 2 bits indiquant la clé de chiffrement utilisée pour crypter le XGEM
payload

38
 - XGEM Port-ID : Champ de 16 bits contenant l’identificateur du XGEM port auquel la trame
appartient
- Options : L'utilisation de ce champ de 18 bits reste un complément d'étude. Le champ est
mis à 0x00000 par l'émetteur et ignoré par le récepteur.
- LF (Last Fragment) : Champ de 1 bit indiquant que c’est le dernier fragment du SDU ou
que c’est un SDU non fragmenté.
- HEC : Champ de 13 bits utilisé pour la détection et la correction d’erreur dans le XGEM
Header. C’est une combinaison d’un code BCH (63,12,2) tronqué, opérant sur les 63
premiers bits du XGEM header, et d’un bit de parité. [13]

2.10.1.3 Format du XGEM payload

Le XGEM payload a une taille variable contrôlée par le champ PLI du XGEM header. Pour un
XGEM frame non-vide, la taille T du XGEM payload, en octets, dépend de la valeur L dans le
champ PLI tel que :
𝐿
4 ∗ ⌈ ⌉ , 𝑠𝑖 𝐿 ≥ 8
𝑇={ 4 (2.02)
8, 𝑠𝑖 0 < 𝐿 < 8
0, 𝑠𝑖 𝐿 = 0
Le XGEM payload peut contenir un à sept octets de remplissage Pad dans les octets de poids le plus
faible. L'émetteur remplit les octets de remplissage avec 0x55. Les octets de remplissage sont rejetés
à la réception. [13]

Figure 2.13 : Format du XGEM payload

2.10.1.4 XGEM frame vide

A chaque fois qu’à l’émission il n'y a pas de SDU ou de fragments de SDU à envoyer, ou que la
taille du SDU ou du fragment SDU dépasse l’espace disponible dans le XGTC payload mais que la
fragmentation ne peut être effectuée en respectant les règles de fragmentation, l'émetteur se doit de
générer des XGEM frames vides pour combler l’espace disponible dans le XGTC payload.

39
Un XGEM frame vide est tout XGEM frame avec la valeur de XGEM Port-ID égale à 0xFFFF. Le
champ PLI d'un XGEM frame vide contient la taille réelle de la charge utile de la trame, qui peut
être égale à un multiple de 4, y compris 0, jusqu'à la taille maximale prise en charge par le SDU.
Les XGEM frames vides sont transmis en clair avec Key index indiquant aucun chiffrement et
LF = 1. Le récepteur ignore les champs Key index et LF de l'en-tête et la charge utile du XGEM
frame avec un XGEM Port-ID de 0xFFFF.
Si l'espace disponible à la fin du XGTC payload est inférieure à la taille du XGEM header (c’est-à-
dire inférieure à 4 octets), l'émetteur doit générer un court XGEM frame vide, qui est défini comme
quatre octets tous nuls. [13]

2.10.2 Délimitation du XGEM frame

La délimitation consiste à retrouver en réception chaque XGEM frame dans le XGTC payload. Le
processus de délimitation s’appuie sur la présence du XGEM header au début de chaque XGTC
payload aval et amont. Le récepteur connaît ainsi l'emplacement du premier XGEM header et peut
utiliser le champ PLI pour déterminer la taille du XGEM payload et pour trouver l'emplacement du
prochain XGEM header, répétant cette procédure pour tous les XGEM frames ultérieures. Le
récepteur vérifie si oui ou non un XGEM frame a été délimité correctement en effectuant la
vérification HEC sur le XGEM header suivant. Si la vérification HEC échoue, le récepteur doit
rejeter la trame en cours avec le reste du XGTC payload. [13]

2.10.3 Fragmentation des SDU

La fragmentation est le processus par lequel un SDU disponible pour la transmission dans la
direction aval ou amont peut être divisé en deux ou plusieurs fragments qui seront transmises dans
un XGEM frame séparé, comme le montre la Figure 2.14.

Figure 2.14 : Fragmentation des SDU

40
La fragmentation dans les sens descendant et montant est soumise aux règles respectives suivantes.
Dans le sens descendant, si le XGTC payload disponible dans le XGTC frame courant est au moins
de 16 octets, et la longueur du SDU disponible pour la transmission, y compris les 8 octets XGEM
header, est supérieure à cette espace disponible, la SDU doit être partitionné en deux fragments. Le
premier fragment SDU occupe complètement le XGTC payload disponible du XGTC frame courant
tandis que le deuxième fragment SDU est transmis dans le XGTC payload du XGTC frame suivant.
Si la taille du second fragment SDU est inférieure à 8 octets, alors il devrait être rembourré jusqu’à
8 octets pour répondre à l’exigence de taille minimale de 16 octets du XGEM frame. Une fois la
fragmentation du SDU commencé, le deuxième fragment du SDU doit être transmis avant toute
autre SDU.

Dans le sens montant, si l’espace disponible du XGTC payload dans l’allocation courante est au
moins de 16 octets, et la longueur de la SDU ou du fragment SDU prévu pour la transmission, y
compris le XGEM header de 8 octets, est supérieure à la charge utile disponible, la SDU doit être
partitionné en deux fragments. Le premier fragment SDU occupe complètement l’espace disponible
du XGTC payload dans l’allocation courante tandis que le reste du SDU est transmis dans le XGTC
payload de la prochaine allocation amont associée au même Alloc-ID, faisant l'objet aux mêmes
règles de fragmentation. Une fois que la fragmentation du SDU a commencé, tous les fragments du
SDU sont transmis avant toute autre SDU associée au même Alloc-ID.

Les règles supplémentaires suivantes s’appliquent à la fois aux directions aval et en amont:
- Si, en raison de la fragmentation, la taille du deuxième fragment du SDU est inférieure à 8
octets, il devrait être rembourré jusqu’à 8 octets pour répondre à la taille minimale du XGEM
frame de 16 octets. En effet, la taille du XGEM header est de 8octets.
- Si la longueur du SDU ou fragment du SDU disponible pour la transmission, y compris le
XGEM header de 8 octets, est inférieure ou égale à l'espace disponible du XGTC payload,
une autre fragmentation est interdite: le SDU entier ou fragment de SDU entier est transmise
dans le XGTC payload courant.
- Si la taille de l’espace disponible dans le XGTC payload est inférieure à 16 octets, il doit
être rempli avec un XGEM frame vide. [13]

41
2.11 Structure des PHY frames et des PHY bursts

2.11.1 Structure du PHY frame descendant

La transmission descendante se fait continuellement par l’OLT. Les données transmises par l’OLT
sont partitionnées en PHY frame de taille fixe à la sortie de la couche PHY Adaptation. La durée
d’un PHY frame descendant est de 125µs. Cette durée correspond à une taille de 155520 octets soit
38880 mots au débit de 9,95328 Gbps. Un PHY frame descendant comprend un champ PSBd de 24
octet et une charge utile appelé PHY frame payload de 155496 octets. Le PHY frame payload est
représenté par un XGTC frame aval dont le contenu est protégé par FEC et scrambling.
Le début d’un PHY frame descendant correspond à la transmission par l’OLT ou la réception par
l’ONU du premier bit de son PSBd. [13]

Figure 2.15 : PHY frame descendant

2.11.1.1 PSBd

Le PSBd a une taille de 24 octets. Il contient trois structures de 8 octets : le PSync (Physical
Synchronisation), le SFC (Superframe counter) et le PON-ID (Passive Optical Network-Identifier).

Figure 2.16 : PSBd

42
 a) PSync
Le PSync est une séquence de 64 bits utilisé pour la synchronisation. L’ONU utilise cette séquence
pour obtenir l’alignement au bord du PHY frame. Le codage de ce champ est 0xC5E5 1840 FD59
BB49.

b) SFC
La structure SFC est un champ de 64 bits utilisé pour compter les PHY frames. 51 bits constituent
le SFC et les 13 bits restants constituent le HEC. La valeur du SFC dans chaque PHY frame
descendant est incrémentée de 1 par rapport au PHY frame précédent. Quand le SFC atteint sa valeur
maximale (tous les bits à 1), il est remis à 0 dans le PHY frame suivant. Le HEC est une combinaison
de code BCH(63, 12, 2), opérant sur les 63 premiers bit de la structure SFC, et d’un bit de parité.
(Voir Annexe 4).

c) La structure PON-ID
C’est une structure de 64 bits pour identifier le PON. Les 51 premiers bits constituent le PON-ID et
les 13 derniers bits constituent le HEC. Le PON-ID est défini par l’OLT à sa discrétion. Sa valeur
par défaut est 51 bits à 0. Le HEC est une combinaison de code BCH(63, 12, 2), opérant sur les 63
premiers bit de la structure PON-ID, et d’un bit de parité. (Voir Annexe 4).

d) Scrambling du PSBd
Après le calcul HEC à l'émetteur et avant la vérification HEC au niveau du récepteur, le SFC et le
PON-ID sont embrouillés à l’aide d’un ou exclusif XOR (Exclusive OR) avec
0x0F0F0F0F0F0F0F0F. [13]

2.11.1.2 PHY frame payload

La charge utile du PHY frame descendant a une taille de 155496 octets. Il est obtenu à partir du
XGTC frame descendant correspondant qui a une taille de 135 432 octets en appliquant le FEC qui
ajoute un total de 20064 octets et en brouillant le résultat. [13]

2.11.2 Structure du PHY burst montant

La durée d’un PHY frame montant est de 125 µs ce qui correspond à une taille de 38880 octets soit
9720 mots à un débit montant de 2,48832 Gbps. En effet, dans le sens montant chaque ONU
transmet une série de PHY bursts relativement court et laisse un intervalle de garde entre les bursts.

43
Un PHY burst montant comprend le PSBu et le PHY burst payload. La charge utile PHY burst
payload est représentée par un XGTC burst dont le contenu peut être protégé par FEC et scrambling.
L’OLT utilise les BWmap pour contrôler la synchronisation et la durée des PHY bursts montants
ainsi les transmissions montantes de chaque ONU ne se chevauchent pas. Le PHY frame montant
est formé par les PHY bursts de chaque ONU. Un PHY burst montant appartient au PHY frame
montant F aussi longtemps que ce burst est spécifié dans le BWmap transmis dans le PHY frame
descendant F. [13]

Figure 2.17 : PHY frame et PHY burst montant

2.11.2.1 PSBu

Le PSBu contient deux champs : le preamble et le delimiter. Ces champs permettent au récepteur
optique de l’OLT d’ajuster le niveau du signal optique et de délimiter les burst. La longueur et le
motif des champs preamble et delimiter constitue le burst profile. Les burst profile autorisés sont
spécifiés par l’OLT en avance en utilisant les messages PLOAM. Le profil à utiliser pour un burst
particulier est indiqué par l’OLT dans le champ BurstProfile de la structure d’allocation
correspondante dans le BWmap. [13]

Figure 2.18 : PSBu

2.11.2.2 PHY burst payload

La charge utile d’un PHY burst montant est obtenue à partir du XGTC burst correspondant en
appliquant optionnellement le FEC et en brouillant le résultat. [13]

44
2.11.2.3 Intervalle de garde

Pour éviter que les transmissions en amont n’entrent en collision, l'OLT construit le BWmap en
laissant l’intervalle de garde approprié entre les burst en amont des différents ONU. L’intervalle de
garde minimum recommandé est de 64 bits. [13]

2.12 Forward Error Correction

La sous-couche PHY Adaptation utilise le FEC pour introduire des redondances dans les données
transmises. Cela permet de détecter les erreurs de transmission à la réception. Dans un système
XGPON, le FEC est à base des codes de Reed-Solomon. Les codes RS (Reed Solomon) sont des
codes non binaires, qui fonctionnent sur des symboles de plusieurs octets. Les codes RS
appartiennent à la famille des codes en blocs linéaires cycliques systématiques. Un code RS prend
un bloc de données de taille constante et ajoute des octets de parité supplémentaires à la fin, créant
ainsi un mot de code. En utilisation ces octets supplémentaires, le décodeur FEC traite le flux de
données, découvre des erreurs, corrige les erreurs, et récupère les données d'origine.

Le code RS le plus couramment utilisé est RS (255, 239), où un mot de code de 255 octets se
compose de 239 octets de données suivis par 16 octets de parité, et RS (255, 223), où un mot de
code de 255 octets se compose de 223 octets de données suivis par 32 octets de parité.

Dans le système XGPON, le code FEC utilisé dans les sens descendant est RS (248, 216), qui est
une forme tronquée de RS (255, 223). Dans le sens montant, le code FEC utilisé est RS (248, 232),
qui est une forme tronquée de RS (255, 239) code. [13]

2.13 Scrambling

Le scrambling est effectué par la sous-couche PHY Adaptation. Le PHY frame aval et le PHY burst
amont sont embrouillés en utilisant le polynôme 𝑥 58 + 𝑥 39 + 1. [13]

2.14 Activation de l’ONU

Le processus d'activation de l’ONU se réfère à l'ensemble de procédures distribuées permettant une

ONU inactive de joindre ou reprendre les opérations sur le PON. Le processus d’activation se fait
en utilisant des messages PLOAM.

45
L’intervalle de temps perçu au niveau de l’OLT entre la transmission d’un PHY frame descendant
et la réception du PHY frame montant correspondant indique la durée d’un trajet aller-retour ou
RTD (Round Trip Delay). Le RTD est la somme du délai de propagation aller-retour et le temps de
réponse de l’ONU. Le RTD change d’un ONU à l’autre du fait que chaque ONU se trouve à une
distance différente de l’OLT. Dans le but d’assurer que les bursts provenant des différents ONU
soient alignés par rapport aux bords du même PHY frame, chaque ONU doit retarder sa transmission
d’un intervalle de temps supplémentaire en se référant à l’ONU le plus loin de l’OLT. L’intervalle
de temps supplémentaire ajouté au temps de réponse de chaque ONU s’appelle temps d’égalisation
ou EqD (Equalization Dealy). Les EqD sont différents par ONU et sont calculés par l’OLT en se
basant sur RTD.

Le processus d’activation comprend trois phases : la synchronisation, l’acquisition du numéro de

série et le ranging. La phase de synchronisation correspond à la synchronisation de l’horloge entre
l’OLT et l’ONU. La phase d’acquisition du numéro de série correspond à la réception par l’ONU
des burst profiles à utiliser dans la transmission montante, à l’indication de sa présence à l’OLT en
répondant à une demande de numéro de série et à l’attribution de l’ONU-ID par l’OLT. La phase
de ranging correspond au calcul et à l’attribution de l’EqD. [13]

2.15 Conclusion

Le XGPON est le premier standard de la nouvelle génération de PON. Il est caractérisé par un débit
asymétrique de 10/2,5 Gbps. Les caractéristiques de transmission du XGPON sont définies dans sa
couche PMD tandis que son protocole MAC est défini dans la couche XGTC. Le protocole MAC
du XGPON gère les transmissions en amont provenant des ONU pour éviter les collisions. Le
standard XGPON dispose également d’une fonction très intéressante qui permet d’allouer la bande
passante montante aux ONU selon leurs besoins : c’est l’allocation dynamique de la bande passante.

46
 CHAPITRE 3

ALLOCATION DYNAMIQUE DE LA BANDE PASSANTE DANS LE XGPON

3.1 Introduction

Dans le XGPON, le trafic descendant est diffusé à tous les ONU. Chaque ONU ne récupère que les
données qui lui sont destinées. Dans le sens montant, les ONU partagent la longueur d’onde
montante de manière temporelle, c’est dire en suivant un accès multiple à répartition dans le temps.
La bande passante montante est ainsi partagée entre les trafics émanant de tous les ONU. La
distribution de la bande passante montante entre chaque ONU est effectué par l’OLT et est
communiqué à tous les ONU dans les en-têtes des trames descendantes : c’est ce qu’on appelle
allocation de la bande passante. Pour une meilleure utilisation des ressources dans le sens montant,
l’OLT alloue dynamiquement la bande passante montante aux ONU. Cela se manifeste par une mise
à jour en continu de la bande passante allouée en tenant compte des conditions de trafic et des
besoins de chaque ONU. La notion d’allocation dynamique de la bande passante est souvent liée
aux notions de QoS (Quality of Service) ou qualité de service.

3.2 Allocation de ressource et qualité de service dans le XGPON

3.2.1 Notion de QoS

La qualité de service désigne la capacité à fournir un service conforme à des exigences spécifiques.
Appliquée au réseau, elle désigne la capacité à véhiculer dans de bonnes conditions un type de trafic
de données. C’est un concept de gestion qui a pour but d’optimiser les ressources du réseau. Les
principaux critères permettant d’apprécier la QoS sont le débit, le délai ou latence, la gigue et la
perte de paquet. La QoS permet de garantir de bonnes performances aux utilisateurs à l’aide d’une
différenciation de service par applications. Elle fait l’objet d’un contrat de service ou SLA (Service
Level Agreement) entre le fournisseur de service et le client. Ce contrat contient les services fournis
pendant une période bien définie ainsi que les niveaux de spécification ou métriques garantis pour
chaque service.

Dans un réseau d'accès optique XGPON, la qualité de service est gérée par l’OLT et les ONU. Elle
est associée aux mécanismes permettant d'allouer les ressources disponibles, notamment la bande
passante, aux différents flux de trafic. [13]

47
3.2.2 Descripteur de trafic

Un flux de trafic ou traffic flow est approvisionné en bande passante à l’aide d’un ensemble
spécifique de paramètres de services en aval et en amont. Ces paramètres peuvent être représentés
par un descripteur de trafic. Dans le cas le plus général, un descripteur de trafic est de la forme:
𝐷 = (𝑅𝐹 , 𝑅𝐴 , 𝑅𝑀 , 𝑋𝐴𝐵 , 𝑃, 𝜔) (3.01)
𝑅𝐹 : Largeur de bande fixe [bps]
𝑅𝐴 : Largeur de bande assurée [bps]
𝑅𝑀 : Largeur de bande maximum [bps]
𝑋𝐴𝐵 : Indicateur d’admissibilité ou d’éligibilité pour l'attribution de largeur de bande
additionnelle : {None, NA (non assurée), BE (best effort)}
P : Priorité pour l'attribution de la bande passante best effort (meilleur effort)
𝜔 : Poids pour l'attribution de la bande passante best effort.

La largeur de bande fixe, 𝑅𝐹 ≥ 0 , représente la portion réservée de la capacité de liaison qui est
allouée au flux de trafic donné, indépendamment de sa demande de trafic et des conditions de trafic.

La largeur de bande assurée, 𝑅𝐴 ≥ 0, représente une partie de la capacité de liaison qui est allouée
au flux de trafic donné tant que le flux de trafic en question dispose encore de demandes de bande
passante insatisfaites, quelle que soit les conditions de trafic.

La largeur de bande maximum, 𝑅𝑀 > 0, représente la limite supérieure de la bande passante totale
qui peut être attribuée au flux de trafic quelles que soient les conditions de trafic.

Un descripteur de trafic correctement formé doit satisfaire les trois restrictions suivantes:
𝑅𝑀 ≥ 𝑅𝐹 + 𝑅𝐴 (3.02)
𝑆𝑖 𝑋𝐴𝐵 = 𝑁𝐴 𝑎𝑙𝑜𝑟𝑠 𝑅𝑀 > 𝑅𝐹 + 𝑅𝐴 > 0 (3.03)
𝑆𝑖 𝑋𝐴𝐵 = 𝐵𝐸 𝑎𝑙𝑜𝑟𝑠 𝑅𝑀 > 𝑅𝐹 + 𝑅𝐴 ≥ 0 (3.04)
En outre, la condition de stabilité de base est :

∑(𝑅𝐹𝑖 + 𝑅𝐴𝑖 ) ≤ 𝐶 (3.05)

𝑖

Où la somme est effectuée sur la totalité des flux de trafic en amont (respectivement en aval) sur le
XGPON, et C est la capacité de l'interface en amont (respectivement en aval).

48
Si nécessaire, deux ou plusieurs flux de trafic peuvent être considérés comme un seul agrégat de
flux. Le descripteur de trafic de l’agrégat de flux est construit à partir des descripteurs de trafic
individuels des flux de trafic constitutifs. Les paramètres du descripteur de trafic de l’agrégat de
flux (indiqué par un astérisque) doivent satisfaire les relations suivantes:
𝑗 𝑗
𝑅𝐹∗ + 𝑅𝐴∗ = ∑(𝑅𝐹 + 𝑅𝐴 ) (3.06)
𝑗

𝑗 ∗ 𝑗 (3.07)
max 𝑅𝑀 ≤ 𝑅𝑀 ≤ ∑ 𝑅𝑀
𝑗
𝑗

où l'exposant j représente un paramètre du j-ième flux de trafic constituant l’agrégat de flux. [13]

3.2.3 Principes de l’allocation de ressource dans le sens descendant

Dans le sens descendant, il est de la responsabilité de l’OLT d’assurer la gestion avec QoS des flux
de trafic d’un XGEM Port-ID en se basant sur leur descripteur de trafic respectif, la disponibilité
des ressources en bande passante, et les conditions de trafic. [13]

3.2.4 Principes de l’allocation de ressource dans le sens montant

3.2.4.1 T-CONT

Un T-CONT est un conteneur de transmission regroupant plusieurs flux de trafic amont. Un T-

CONT permet de définir un agrégat de flux en sens montant, le tout étant associé à un même contrat
de trafic. Un T-CONT peut donc transporter plusieurs flux XGEM, ce qui veut dire que plusieurs
XGEM Port sont multiplexés sur un T-CONT. Un T-CONT est identifié par son Alloc-ID. Un T-
CONT reçoit des données issues d’une ou plusieurs files d'attente. [13]

3.2.4.2 Allocation des ressources dans le sens montant

Dans le sens montant, un descripteur de trafic est construit pour chaque conteneur de transmission
T-CONT en se basant sur les paramètres de service de chaque flux de trafic appartenant aux XGEM
Port-ID multiplexés sur ce T-CONT. Il est de la responsabilité de l’OLT d’assurer la gestion avec
QoS de l’agrégat de flux associé aux T-CONT en se basant sur leurs paramètres de services, la
disponibilité de la bande passante en amont et, éventuellement, les informations obtenues grâce au
monitorage du trafic en amont et/ou aux rapports d’état de l’ONU. Pour chaque T-CONT, il est de
la responsabilité de l'ONU auquel le T-CONT appartient, d'assurer la gestion avec QoS du flux de

49
trafic de chaque XGEM Port-ID constituant le T-CONT, en se basant sur les paramètres de services
de chaque XGEM Port-ID respectif, la disponibilité des ressources et les conditions de trafic. [13]

3.3 Allocation dynamique de la bande passante

3.3.1 Notion de bande passante et de largeur de bande

En électronique, la bande passante est l’intervalle de fréquences dans lequel l’amplitude de la

réponse d’un système ne s’écarte pas d’un niveau prédéfini et la largeur de bande d’un signal indique
l’intervalle de fréquences à l’intérieur duquel on peut traiter convenablement le signal. Par analogie
dans le domaine des réseaux, on utilise le terme bande passante pour désigner le débit binaire
maximal d’un canal de communication et la largeur de bande est l’intervalle de fréquence utilisable
sur ce canal.

Dans la suite, les termes bande passante et largeur de bande seront confondus mais le choix de leur
utilisation dépend du contexte. Ainsi, on définit la bande passante ou la largeur de bande comme la
capacité de transmission d’une liaison de transmission de données soit la quantité d’informations
(en bit par seconde) qui peut être transmise sur une voie de transmission.

3.3.2 DBA

Dans un PON, l’allocation dynamique de la bande passante ou DBA (Dynamic Bandwidth

Assignement) désigne le processus par lequel les ONU demandent dynamiquement de la largeur de
bande en amont (implicitement ou explicitement) et la méthode par laquelle la terminaison OLT
réassigne en conséquence la largeur de bande en amont aux ONU.

Le DBA dans le XGPON est le processus par lequel l'OLT répartit les opportunités de transmission
en amont pour les entités de trafic au sein des ONU, selon une indication dynamique de leur activité
et leurs contrats de trafic. L'indication de l'état de l'activité peut être explicite au moyen de rapports
d'état de tampon, ou implicite par la transmission de XGEM frame vide pendant les opportunités de
transmission en amont.

En comparaison avec l'attribution statique de la bande passante, le mécanisme d'assignation

dynamique de largeur de bande améliore l'efficacité d'utilisation de la largeur de bande amont en
ajustant de manière dynamique la largeur de bande entre les ONU en réponse aux besoins associés
au trafic en rafale provenant des ONU. Les avantages pratiques apportés par la DBA sont de deux

50
types. Premièrement, les opérateurs de réseau peuvent ajouter un plus grand nombre d'abonnés sur
le réseau PON grâce à une utilisation plus efficace de la largeur de bande. Deuxièmement, les
abonnés peuvent bénéficier de services améliorés, tels ceux qui nécessitent des crêtes de largeur de
bande.

Une comparaison entre le mécanisme statique et l'assignation dynamique de largeur de bande est
illustrée aux Figures 3.01, 3.02 et 3.03. Trois ONU représentés sont désignées par n°1, n°2 et n°3.
L'ONU n°1 requiert un trafic à débit binaire constant qui est acheminé efficacement en utilisant une
méthode d'assignation statique de la largeur de bande. L'ONU n°2 et l'ONU n°3, toutefois,
présentent des crêtes de trafic; le trafic émanant de l'ONU n°3 a également des exigences du point
de vue temps de transmission.

Figure 3.01 : Trafic d’origine

Avec une allocation statique de largeur de bande (représentée à la Figure 3.02), le trafic émanant de
l'ONU n°2 serait perdu et le trafic provenant de l'ONU n°3 serait retardé.

Figure 3.02 : Transfert par assignation statique de largeur de bande

51
L'efficacité de l'allocation dynamique de largeur de bande est illustrée à la Figure 3.03, où l'ONU
n°3 se voit attribuer de manière dynamique une largeur de bande suffisante pour acheminer ses
crêtes de trafic, suivie par l'ONU n° 2 qui se voit attribuer dynamiquement une largeur de bande
suffisante pour son trafic. [13][15]

Figure 3.03 : Transfert par DBA

3.4 Abstraction du DBA dans le XGPON

Dans le XGPON, l'entité bénéficiaire de l'allocation de bande passante en amont est représentée par
un Alloc-ID. Quel que soit le nombre d’Alloc-ID attribué à chaque ONU, le nombre de XGEM ports
multiplexés sur chaque Alloc-ID et la structure de la file d'attente mis en œuvre par l'ONU, l’OLT
modélise l'ensemble du trafic associé à chaque Alloc-ID comme un seul tampon logique et, aux fins
d'allouer la bande passante, considère tous les Alloc-ID spécifiés pour le PON donné comme
indépendants.

Figure 3.04 : Abstraction du DBA

52
Le module fonctionnel de DBA de l'OLT déduit l'occupation du tampon logique de chaque Alloc-
ID soit en recueillant des rapports d'état, ou en observant les trames vides en amont, ou les deux. La
fonction DBA fournit ensuite une entrée au scheduler de l’OLT, qui est responsable de la génération
des BWmap. Le BWmap spécifie la taille et le calendrier des opportunités de transmission en amont
pour chaque Alloc-ID, et est communiqué aux unités ONU avec le trafic en aval.
Rapellons que le BWmap est formé de plusieurs structures d’allocation. Une structure d’allocation
est destinée à un Alloc-ID particulier et le StartTime et le GrantSize sont les deux champs qui
constituent l’opportunité de transmission amont. [13]

3.4.1 Construction du BWmap

La construction du BWmap par l’OLT suit quelques règles :

- L’OLT doit spécifier les différentes séries d’allocation du BWmap dans l’ordre croissant du
StartTime
- La valeur minimum du StatTime est 0
- La valeur maximum du StartTime est 9719
- Le nombre maximum de structures d’allocation par BWmap est 512
- Le nombre maximum de structures d’allocation dans une série d’allocation est 16
- Le nombre maximum de structures d’allocation par ONU dans un BWmap est 64
- Le nombre maximum de séries d’allocation par ONU dans un BWmap est 4
- La taille maximum d’une allocation est de 9718 mots
- La taille maximum du XGTC burst est 9720 mots
La taille maximum du XGTC burst ne doit pas dépasser la taille du PHY frame amont (soit 38880
octets ou 9720 mots). En tenant compte de la taille des en-têtes et en-queue XGTC (4 octets pour le
XGTC header sans le champ PLOAMu et 4 octets pour le XGTC trailer), le GrantSize maximal est
9718 mots. Si le champ PLOAMu est présent, le GrantSize maximal est 9706 mots. [13]

3.4.2 Résumé des champs de données intervenant dans le mécanisme du DBA

Le DBA dans le XGPON est assurée par la sous-couche XGTC Framing. Les principaux champs
des trames qui ont un rôle à jouer dans le DBA sont résumés ci-après :
- le BWmap dans le XGTC frame header aval qui contient les structures d’allocation. Les
champs importants de chaque Allocation Structure sont l’Alloc-ID destinataire de la

53
 structure d’allocation, le flag DBRu pour demander ou non un rapport d’état de tampon, le
StartTime et le GrantSize.
- le champ BuffOcc du XGTC burst amont qui indique l’occupation du tampon. [13]

3.5 Exigences fonctionnelles du DBA

Dans le XGPON, le DBA englobe les fonctions suivantes. Ces fonctions s’appliquent au niveau de
chaque Alloc-ID et des paramètres des composantes de la largeur de bande qui leur est attribuée :
- La déduction de l’état d'occupation du tampon,
- La mise à jour instantanée de la bande passante attribuée selon l’état d'occupation du tampon,
- Attributions des allocations en fonction des mises à jour instantanées de bande passante,
- La gestion des opérations de DBA. [13]

3.6 Les méthodes d’allocation dynamique de la largeur de bande

En fonction du mécanisme de détermination de l'occupation du tampon de l'ONU, deux méthodes

de DBA peuvent être distinguées:
- Le DBA par rapports d’états ou SR DBA (Status Reporting Dynamic Bandwidth Allocation)
qui est basé sur les rapports d'occupation des tampons explicites qui sont sollicités par l’OLT
et soumis en réponse par les ONU;
- Le DBA par monitorage du trafic ou TM DBA (Traffic Monitoring Dynamic Bandwidth
Allocation) qui est basée sur l'observation par l’OLT du motif des XGEM frames vides et la
comparaison du motif avec les BWmap correspondants.
Pour le TM DBA, aucune ressource de largeur de bande n'est nécessaire à l'ONU pour signaler son
état; l'OLT déduit les besoins en largeur de bande de chaque ONU à partir de l'utilisation en cours.
Toutefois, un des inconvénients de cette approche est la lenteur de la réaction aux demandes de
largeur de bande amont émanant des ONU. Pour le SR DBA, l’indication d’état de tampon
consomme une infime partie de la largeur de bande mais les réactions aux demandes de largeur de
bande sont plus rapides. [13]

3.7 Modèle de référence pour le DBA

Pour assurer le DBA, un algorithme, dit algorithme DBA, est implémenté au niveau de l’OLT. C’est
à partir de cet algorithme que l’OLT effectue le DBA. On décrit ici un modèle de référence pour le
DBA servant de point de départ à l’écriture d’un algorithme. [13]

54
3.7.1 Notations

Les notations suivantes seront utilisées pour définir le modèle de référence pour le DBA :
A : Quantité de trafic qui arrive au tampon [bit]
B : Occupation du tampon [bit]
R : Largeur de bande totale [bps]
RG : Largeur de bande garantie [bps]
RL : Offered Load [bps]
RNA : Largeur de bande non assurée [bps]
RBE : Largeur de bande de meilleur effort [bps]
SNA : Largeur de bande excédentaire disponible pour l’attribution d’une largeur de bande non assurée
[bps]
SBE : Largeur de bande excédentaire disponible pour l’attribution d’une largeur de bande de meilleur
effort [bps]
i : exposant indiquant un Alloc-ID spécifique

3.7.2 Offered load

Chaque Alloc-ID peut être caractérisé de manière dynamique par son offered load, RL(t), qui est
défini comme le débit moyen auquel le tampon d'une Alloc-ID devrait être servi pour être évacuée
pendant un certain temps fixe Δ, représentant une constante du système. Δ est au moins égal à la
durée d’une trame mais plus pratiquement Δ est égal à la durée de huit trames.
𝐵(𝑡) + 𝐴(𝑡, 𝑡 + ∆) (3.08)
𝑅𝐿 (𝑡) =
∆
B(t) représente l’occupation du tampon à l’instant t.
A(t,t+Δ) représente le trafic arrivant au tampon pendant l’intervalle de temps (t,t+Δ).

3.7.3 Présentation du modèle de référence pour le DBA

La largeur de bande 𝑅 𝑖 (𝑡) ≥ 0, attribuée dynamiquement à l’Alloc-ID i est composé d’une largeur
de bande garantie et d’une largeur de bande additionnelle. La largeur de bande garantie 𝑅𝐺𝑖 (𝑡) peut
être sous la forme d’une largeur de bande fixe et d’une largeur de bande assurée. La largeur de bande
𝑖
additionnelle peut être sous la forme d’une largeur bande non assurée 𝑅𝑁𝐴 (𝑡), ou d’une largeur de
𝑖 (𝑡).
bande de meilleur effort 𝑅𝐵𝐸

55
 𝑖
- Pour l’Alloc-ID i, si 𝑋𝐴𝐵 = 𝑁𝐴, 𝑅 𝑖 (𝑡) = 𝑅𝐺𝑖 (𝑡) + 𝑅𝑁𝐴
𝑖
(𝑡) (3.09)
𝑖
- Pour l’Alloc-ID i, si 𝑋𝐴𝐵 = 𝐵𝐸, 𝑅 𝑖 (𝑡) = 𝑅𝐺𝑖 (𝑡) + 𝑅𝐵𝐸
𝑖
(𝑡) (3.10)
𝑖
- Pour l’Alloc-ID i, si 𝑋𝐴𝐵 = 𝑁𝑜𝑛𝑒, 𝑅 𝑖 (𝑡) = 𝑅𝐺𝑖 (𝑡) (3.11)

L’attribution de la largeur de bande garantie se fait comme suit :

- La largeur de bande fixe est assignée de façon statique
- La largeur de bande assurée est attribuée dynamiquement en fonction de l’offered load de
l’Alloc-ID. [13]

L’attribution de la largeur de bande additionnelle peut suivre soit un critère de proportionnalité, soit
un critère de priorité et de poids. La largeur de bande additionnelle est attribuée dynamiquement en
fonction de l’offered load de l’Alloc-ID et les conditions de trafic. [13]

Le modèle de référence introduit une hiérarchie stricte de priorité entre les formes de largeur de
bande attribuée :

Largeur de bande de priorité la plus élévée Largeur de bande fixe

Largeur de bande assurée
Largeur de bande non assurée
Largeur de bande de priorité la plus faible Largeur de bande de meilleur effort
Figure 3.05 : Hiérarchie de priorité de chaque forme de largeur de bande

Premièrement, l’OLT affecte la largeur de bande fixe à tous les Alloc-ID sur le PON,
indépendamment de leurs offered load respectifs et des conditions de trafic. Puis l'OLT complète la
largeur de bande garantie par l'allocation de la largeur de bande assurée à chaque Alloc-ID jusqu'à
ce que le niveau RA respectif de chaque Alloc-ID soit atteinte ou que la demande de trafic soit
satisfaite.

Après cela, l’OLT alloue la largeur de bande non assurée aux Alloc-ID dits insaturés et admissibles
𝑖
(𝑋𝐴𝐵 = 𝑁𝐴) jusqu'à ce que tous les Alloc-ID atteignent leur niveau de saturation ou jusqu’à ce que
SNA(t) soit épuisé. Le niveau de saturation est le minimum entre la largeur de bande maximum RM
et l’offered load RL(t).

Enfin, l’OLT alloue la largeur de bande de meilleur effort aux Alloc-ID insaturés admissibles
𝑖
(𝑋𝐴𝐵 = 𝐵𝐸).

56
Le modèle de référence exige que, pour tout Alloc-ID i, à tout moment où l’offered load 𝑅𝐿𝑖 (𝑡)
dépasse 𝑅𝐹𝑖 , la bande passante assignée 𝑅 𝑖 (𝑡) doit satisfaire à la condition de conservation:
𝑖
𝑅 𝑖 (𝑡) ≤ min{𝑅𝑀 ; 𝑅𝐿𝑖 (𝑡)} (3.12)

Remarque : L’admissibilité ou éligibilité est indiquée par 𝑋𝐴𝐵 . NA signifie une admissibilité pour
l’attribution d’une largeur de bande additionnelle sous forme d’une largeur de bande non assurée.
BE signifie une admissibilité pour l’attribution d’une largeur de bande additionnelle sous forme
d’une largeur de bande de meilleur effort. None signifie une non-admissibilité pour l’attribution
d’une largeur de bande additionnelle. [13]

3.7.4 Attribution de la largeur de bande garantie

Tant que la condition de stabilité (3.05) est satisfaite, la composante garantie de la largeur de bande
attribuée est donnée par :
𝑅𝐺𝑖 (𝑡) = min{𝑅𝐹𝑖 + 𝑅𝐴𝑖 ; max{𝑅𝐹𝑖 + 𝑅𝐿𝑖 (𝑡)}} (3.13)

𝑅𝐺𝑖 (𝑡) est à la disposition de l’Alloc-ID an question, peu importe les conditions de trafic. Ainsi, 𝑅𝐹𝑖
est la limite inférieure de la largeur de bande garantie attribuée 𝑅𝐺𝑖 (𝑡), et 𝑅𝐴𝑖 + 𝑅𝐹𝑖 est la limite
supérieure. [13]

Figure 3.06 : Composants de la largeur de bande assignée par rapport à l’offered load

3.7.5 Attribution de la largeur de bande additionnelle sur le critère de proportionnalité

Pour ce faire, on donne aux Alloc-ID les paramètres 𝑅𝐹𝑖 , 𝑅𝐴𝑖 et 𝑅𝑀

𝑖
appropriés. Les paramètres
priorités (P) et de poids (𝜔) pour tous Alloc-ID sont réglés sur des valeurs identiques. L’indicateur

57
d’éligibilité pour l’attribution de la largeur de bande additionnelle peut prendre toute les valeurs
(NA, BE, None). [13]

3.7.5.1 Largeur de bande non assurée

La largeur de bande non assurée RNA est une forme de la largeur de bande additionnelle que l’OLT
peut attribuer dynamiquement à un Alloc-ID éligible proportionnellement à la somme de la largeur
de bande fixe et de la largeur de bande assurée de l’Alloc-ID. La quantité de largeur de bande
excédentaire qui peut participer à l'attribution de la largeur de bande non assurée est égale à la partie
de la capacité de liaison montante qui reste disponible après que les composantes de la largeur de
bande garantie ont été attribués dynamiquement à tous les Alloc-ID. Cette quantité excédentaire est
donnée par l'expression suivante:

𝑆𝑁𝐴 (𝑡) = 𝐶 − ∑ 𝑅𝐺𝑖 (𝑡) (3.14)

𝑖

où 𝑅𝐺𝑖 (𝑡) est donné à l’équation (3.13).

La largeur de bande excédentaire 𝑆𝑁𝐴 (𝑡) est partagée entre les Alloc-ID éligible (𝑋𝐴𝐵 = 𝑁𝐴) de
sorte que la condition de conservation (3.12) est satisfaite, et soit :
- Pour chaque Alloc-ID i, la largeur de bande assignée satisfait le critère de saturation
𝑖
𝑅 𝑖 (𝑡) = min{𝑅𝑀 ; max{𝑅𝐿𝑖 (𝑡); 𝑅𝐹𝑖 }} (3.15)
ou
- 𝑆𝑁𝐴 (𝑡)est épuisé et au plus un Alloc-ID reste insaturé, ou
- 𝑆𝑁𝐴 (𝑡)est épuisé et pour deux Alloc-ID insaturés admissibles i et j, les largeurs de bande
non assurées attribuées satisfont à la condition de capacité :
𝑖 (𝑡) 𝑗
𝑅𝑁𝐴 𝑅𝑁𝐴 (𝑡) (3.16)
=
𝑅𝐹𝑖 + 𝑅𝐴𝑖 𝑗
𝑅𝐹 +
𝑗
𝑅𝐴

3.7.5.2 Largeur de bande de meilleur effort

La largeur de bande de meilleur effort est une forme de largeur de bande additionnelle que l’OLT
peut attribuer dynamiquement à un Alloc-ID éligibles proportionnellement à la partie non garantie
de la largeur de bande maximale attribuée à cet Alloc-ID. L’Alloc-ID éligible pour l'attribution de
la largeur de bande de meilleur effort ne reçoit la largeur de bande additionnelle que si tous les
Alloc-ID éligible pour l'attribution de la largeur de bande non assuré ont été saturés. La quantité de
largeur de bande excédentaire qui peut participer à l'attribution de la largeur de bande de meilleur

58
effort est égal à la partie de la capacité de liaison montante qui reste disponible après que tous les
Alloc-ID admissible pour l'attribution de la largeur de bande non assurée ont été saturés, et que tous
les autres Alloc -ID ont été affectés de leurs composantes de largeur de bande garantie respectives.
Cette quantité excédentaire est donnée par l'expression suivante :

𝑆𝐵𝐸 (𝑡) = 𝐶 − ∑ 𝑅 𝑖 (𝑡) − ∑ 𝑅𝐺𝑖 (𝑡) (3.17)

𝑖 𝑖
𝑖 ∈{𝑋𝐴𝐵 =𝑁𝐴} 𝑖 ∈{𝑋𝐴𝐵 ≠𝑁𝐴}

où 𝑅𝐺𝑖 (𝑡) est donné à l’équation (3.13). et 𝑅 𝑖 (𝑡) est donné en (3.15).

La largeur de bande excédentaire 𝑆𝐵𝐸 (𝑡) est partagée entre les Alloc-ID éligible (𝑋𝐴𝐵 = 𝐵𝐸) de
sorte que la condition de conservation (3.12) est satisfaite, et soit
- Pour chaque Alloc-ID i, la largeur de bande assignée satisfait le critère de saturation (3.15)
ou
- 𝑆𝐵𝐸 (𝑡)est épuisé et au plus un Alloc-ID reste insaturé, ou
- 𝑆𝐵𝐸 (𝑡)est épuisé et pour deux Alloc-ID insaturés admissibles i et j, les largeurs de bande de
meilleur effort attribuées satisfont à la condition de capacité :
𝑖 (𝑡) 𝑗
𝑅𝐵𝐸 𝑅𝐵𝐸 (𝑡)
𝑖
= (3.18)
𝑅𝑀 − (𝑅𝐹𝑖 + 𝑅𝐴𝑖 ) 𝑗
𝑅𝑀 − (𝑅𝐹 + 𝑅𝐴 )
𝑗 𝑗

3.7.6 Attribution de la largeur de bande additionnelle en se basant sur les critères de priorité
et de poids

Pour réaliser l'attribution de la largeur de bande additionnelle en fonction des priorités et de poids,
les Alloc-ID sont affectés respectivement des paramètres Pi et ωi. Les paramètres de bande passante
pour tous les Alloc-ID au sein de chaque niveau Pi sont réglés sur des valeurs identiques.
L’indicateur d’éligibilité est soit BE soit None. [13]

La quantité de largeur de bande excédentaire qui peut participer à l'affectation de bande passante de
meilleur effort est égale à la partie de la capacité de liaison montante qui reste disponible après que
les composantes de largeur de garantie ont été affectées de façon dynamique à tous Alloc-ID. Cette
quantité excédentaire est donnée par l'expression suivante:

𝑆𝐵𝐸 (𝑡) = 𝐶 − ∑ 𝑅𝐺𝑖 (𝑡) (3.19)

𝑖

où 𝑅𝐺𝑖 (𝑡) est donné à l’équation (3.13).

59
La largeur de bande excédentaire 𝑆𝐵𝐸 (𝑡) est partagée entre les Alloc-ID éligible (𝑋𝐴𝐵 = 𝐵𝐸) de
sorte que la condition de conservation (3.12) est satisfaite, et soit
- Pour chaque Alloc-ID i, la largeur de bande assignée satisfait le critère de saturation (3.15)
ou
- 𝑆𝐵𝐸 (𝑡)est épuisé et les deux déclarations suivantes sont réunies:
 Dans la mesure où au moins un Alloc-ID i éligible avec le niveau de priorité Pi reste
insaturé, la part de largeur de bande de meilleur effort assignée à une quelconque
Alloc-ID avec un niveau de priorité inférieur est égal à zéro;
 Aussi longtemps que deux Alloc-ID éligibles i et j avec des niveaux de priorité
identiques Pi = Pj resteraient insaturés, leur part de largeur de bande de meilleur
effort satisfont à la condition de capacité :
𝑖 (𝑡) 𝑗
𝑅𝐵𝐸 𝑅 (𝑡) (3.20)
= 𝐵𝐸
𝜔𝑖 𝜔𝑖

3.8 Exigences de performance du DBA

Dans la pratique, l'algorithme DBA de l’OLT n'a pas une connaissance complète de l'état du
système. En particulier, à la place des véritables offered load 𝑅𝐿𝑖 (𝑡), il opère sur la base d'estimations
𝑅̂𝐿𝑖 (𝑡) qui sont obtenus à partir des rapports DBRu et des résultats du monitorage du trafic. On donne
ici plusieurs critères de performance qui permettent d'évaluer une implémentation pratique du DBA
vis-à-vis du modèle de référence.

3.8.1 Attribution de largeur de bande stationnaire

3.8.1.1 Définition

Dans un système où l'activité des Alloc-ID et la demande de trafic restent constantes, la largeur de
bande attribuée à un Alloc-ID est mesurée comme une moyenne sur les BWmap transmis dans
n’importe quelle séquence consécutive de K trames descendantes, où K est choisi suffisamment
grand pour faire la moyenne des allocations qui peuvent varier d'une trame à l’autre. [13]

3.8.1.2 Performance visée

L'algorithme de DBA de l’OLT doit s’assurer que la bande passante stationnaire assignée pour
chaque Alloc-ID insaturé est au moins égale à la largeur de bande fixe plus la largeur de bande

60
assurée respective et est dans des limites spécifiées (par exemple, 10%) de la valeur dynamique
calculé, sur la base du modèle référence. [13]

3.8.2 Temps de restauration de la bande passante assurée

3.8.2.1 Définition

C’est l'intervalle de temps dans le pire des cas, comme observé à l’ONU, à partir du moment où un
Alloc-ID, qui devrait recevoir l'affectation de bande passante assurée mais qui ne l’a pas encore reçu
en raison de l’insuffisance de sa demande de trafic, augmente sa demande de trafic jusqu’à au moins
son niveau (fixe+assuré), jusqu'au moment où elle est affectée de la totalité de la bande passante
assurée en plus de la bande passante fixe. L'instant de fin de l'intervalle est plus précisément défini
comme le début de la première trame montante dans une séquence de K trames consécutives,
suffisamment grand pour faire la moyenne des variations de trame à trame, sur laquelle la moyenne
de la largeur de bande allouée à l’Alloc-ID satisfait la condition spécifiée. [13]

3.8.2.2 Performance visée

Quelques millisecondes sont souhaitées (objectif : 2 ms). [13]

3.8.3 Temps de convergence de DBA

3.8.3.1 Définition

C’est intervalle de temps dans le pire cas, entre le moment d'un seul statut d’activité ou d’un
changement de charge de trafic, à tout ONU dans un système déjà stationnaire, jusqu'au moment où
l’OLT ajuste ses attributions de bande passante pour tous les ONU insaturés jusqu’aux niveaux qui
sont au moins égale à la somme de leur largeur de bande fixe et largeur de bande assurée respectives,
et qui sont dans les limites spécifiées (par exemple, 20%) des valeurs dynamiques respectives
calculées sur la base du modèle de référence. L'instant de fin de l'intervalle est plus précisément
définie comme le début de la première trame en aval d'une séquence de K trames consécutives,
suffisamment grand pour faire la moyenne des variations de trame à trame, dans lequel les BWmaps
transmises contiennent des allocations de bande passante satisfaisant la condition spécifiée en
moyenne. [13]

61
3.8.3.2 Performance visée

Quelques millisecondes sont souhaitées (objectif : 6 ms). [13]

3.9 Types de T-CONT

Un T-CONT est identifié par son Alloc-ID. Les attributions de la largeur de bande montante sont
donc allouées aux T-CONT. En réalité, un T-CONT intègre plusieurs files d’attente physiques et
les agrège en une seule mémoire logique. Le trafic appartenant à un T-CONT est associé au même
contrat de trafic ou SLA. On peut donc définir plusieurs types de T-CONT. Chaque type de T-
CONT est caractérisé par les types de largeur de bande assignée qu’il prend en charge. L’allocation
de la largeur de bande dépend ainsi du type de T-CONT. Il y a cinq types de T-CONT : le T-CONT
1, T-CONT 2, T-CONT3, T-CONT 4 et T-CONT 5.
- Le T-CONT 1 est caractérisé la largeur de bande fixe.
- Le T-CONT 2 est caractérisé par la largeur de bande assurée.
- Le T-CONT 3 est caractérisé par la largeur de bande assurée et la largeur de bande non
assurée.
- Le T-CONT 4 est caractérisé par la largeur de bande Best Effort.
- Le T-CONT 5 prend en charge tous les largeurs de bande.
L’allocation de la largeur de bande pour le T-CONT 1 est donc constante. Pour le T-CONT 2,
l’allocation de la largeur de bande varie avec la demande. Pour le T-CONT3 et le T-CONT 4,
l’allocation de la largeur de bande tient compte de la largeur de bande laissée disponible une fois
que les demandes de largeur de bande fixe et assurée ont été satisfaites. Pour le T-CONT 5,
l’allocation de la bande passante est un sur-ensemble de celle des 4 autres T-CONT. [1][4][13]

3.10 Conclusion

Le DBA est un mécanisme très important du XGPON présent dans sa couche XGTC. Un ONU
indique la quantité de son trafic à l’OLT qui lui attribue la largeur de bande pour l’écouler. La
largeur de bande attribuée au flux de trafic de l’ONU est calculée par un algorithme DBA
programmée au niveau de l’OLT en fonction des paramètres de service et des ressources
disponibles. Le modèle de référence décrit dans le chapitre est la base de tout algorithme DBA. Il
définit quatre formes de largeur de bande de priorité différente regroupées en deux catégories qui
sont la largeur de bande garantie et la largeur de bande additionnelle.

62
 CHAPITRE 4

SIMULATION DE L’ALLOCATION DYNAMIQUE DE LA BANDE PASSANTE DANS

UN XGPON EN UTILISANT L’ALGORITHME GIANT

4.1 Introduction

On se propose ici de simuler le DBA dans un réseau XGPON. Pour ce faire, on a choisi d’utiliser
un algorithme DBA. Le simulateur réseau retenu est NS3 (Network Simulator 3) du fait de sa
disponibilité, de ses capacités en termes de simulation (vitesse et résultat), de sa facilité
d’apprentissage et surtout parce qu’il est le simulateur le plus approprié pour le travail envisagé, les
objectifs à atteindre et les résultats cherchés.

4.2 Présentation de NS3

NS3 est un simulateur de réseaux à événements discrets utilisé principalement dans la recherche et
l’enseignement. Il vise à remplacer son prédécesseur NS2 (Network Simulator 2) pour tenter de
remédier à ses limites. NS3 n'est pas une extension de NS2, c'est un nouveau simulateur. NS3 a été
créé en 2006, par Thomas R, Henderson et Sumit Roy, étudiants de l'université de Washington. Leur
but était de fournir une plateforme à la fois ouverte et extensible pour simulation des réseaux. Le
noyau et les modèles de NS3 sont implémentés en C++. NS3 est construit comme une bibliothèque
qui peut être liée de manière statique ou dynamique à un programme principal C++ qui définit la
topologie de simulation et démarre le simulateur. NS3 exporte également la quasi-totalité de son
API pour Python, permettant aux programmes Python d'importer un module NS3 de la même
manière que la bibliothèque NS3 est liée par exécutables en C++. Sous les termes de la GNUGPLv2
(GNU General Public License version 2); NS3 est open-source. Il peut être utilisé sur les plateformes
Linux/Unix, OS X (Mac), et Windows (grâce à l'émulateur Cygwin). [17][18][19]

Dans notre cas, le système d’exploitation utilisé est la dernière version stable, la version 14.04, de
la distribution Ubuntu de Linux. Les paquets d’installation des prérequis de NS3 pour Linux sont
plus facile à trouver. Le simulateur NS3 à notre disposition est le release ns-3.19.

NS3 est principalement utilisé pour des simulations de protocoles (TCP, UDP, IPv4, IPv6, OLSR,
AODV..), des simulations de médias (Ethernet, WIFI, WIMAX…). Il permet de définir des
topologies de réseau dynamiques ou statiques, c’est-à-dire avec ou sans modèles de mobilité. Il

63
fournit également une possibilité d’émulation qui permet d’exécuter une implémentation de
protocole.

4.2.1 Terminologie et abstractions

NS3 utilise des termes largement employés dans le domaine des réseaux, mais qui peuvent avoir
une signification particulière au sein du simulateur. En voici les principaux :
- Node : Node sert à désigner tout nœud d’un réseau. Les fonctionnalités de chaque nœud sont
à ajouter par l’utilisateur.
- Application : Application désigne un programme qui permet de générer les activités réseaux
à simuler. Il est installé sur un Node.
- Channel : Channel représente le canal de communication c’est-à-dire le lien qui relie entre
eux les Nodes, ou plus exactement les NetDevices installés dans les Nodes.
- NetDevice : NetDevice représente l’interface de communication ou interface réseau, qui
modélise à la fois l'équipement (carte réseau) et le pilote. Plusieurs NetDevices peuvent être
installées dans un Node, et servent à relier ce Node à d'autres Nodes via le Channel
correspondant. S'il s'agit de connecter un grand nombre de Node les uns avec les autres, ce
processus peut être très lourd ; Ns-3 fournit des TopologyHelpers pour faciliter ce genre de
tâches. [17][18][19]

Figure 4.01 : Fonctionnement interne de NS3

4.2.2 Organisation de NS3

NS3 est sous forme d’une librairie qu’on lie à un programme principal écrit en C++ qui définit la
topologie de la simulation et démarre le simulateur. Le code source est organisé dans le répertoire
src et est décrit par la Figure 4.02. On travaille à partir du bas, chaque module ne dépend que des
modules en dessous. [17][18][19]

64
 Figure 4.02 : Organisation de NS3

4.2.3 Outil de visualisation

L’outil de visualisation associé à NS3 utilisé dans le cadre de cette simulation est NetAnim. C’est
un outil de visualisation du scénario de simulation basée sur un fichier de trace xml traçant le
scénario qui est généré au cours de la simulation. Il fournit une animation sur l’acheminement des
paquets sur les canaux de transmission, une chronologie de paquets, des statistiques sur la position
des Nodes et un résumé sur les données contenus dans les paquets. [17][18][19]

4.3 Module XGPON pour NS3

Le simulateur réseau NS3 ne dispose pas de modèles pour la simulation des réseaux optiques dans
sa distribution officielle. Pourtant, plusieurs modules de simulation de réseau optique pour NS3
furent en cours de développement depuis Janvier 2013. Parmi ces modules, on compte un module
XGPON développé par des chercheurs sous l’égide du centre de recherche en télécommunications
CTVR (Centre for Telecommunications Value-Chain Research) du Trinity College de Dublin en
Ireland. Ces chercheurs sont Xiuchao Wu, Kenneth N. Brown, Cormac J. Sreenan, Jerome
Arokkiam, Pedro Alvarez, Marco Ruffini, Nicola Marchetti, David Payne, Linda Doyle. C’est ce
module qui va servir de point de départ pour la simulation.

Ce module XGPON a été conçu et mis en œuvre avec pour objectif de fournir un module conforme
aux normes, configurables et extensibles, qui peut simuler le XGPON à une vitesse raisonnable, et
qui peut prendre en charge un large éventail de sujets de recherche. Ce module est entièrement écrit
en C++ avec 72 classes et environ 22 000 lignes de code, il est sous licence GNUGPL. [20]

65
4.3.1 Compromis de mis en œuvre

Lors de la conception du module XGPON, quelques compromis ont dû être faits. Pour obtenir des
résultats de simulation fiables, il est extrêmement souhaitable de simuler tous les détails du réseau
XGPON. Cependant, XGPON un réseau à très haut débit avec des normalisations très complexes.
Ainsi, quelques aspects du réseau ont été simplifiés dans ce module. Ceci ayant pour but
d’augmenter la vitesse de simulation et de réduire les charges du processeur et la consommation de
mémoire. Néanmoins, les résultats obtenus à l’aide du module sont jugés acceptables puisque le
module a été développé principalement afin de répondre aux questions de performance d'un réseau
XGPON en fonctionnement. Les caractéristiques à retenir sont :
- Le module n’utilise qu’un cœur du processeur même si une machine peut en avoir plusieurs
dans un processeur.
- Considérant que NS3 est fondamentalement un simulateur de niveau paquet, ce module doit
simuler XGPON au niveau paquet.
- Quelques opérations de la couche physique ont été simplifiées dans leur implémentation :
FEC, ranging, activation de l’ONU, scrambling, codage en ligne, chiffrement…
- Dans XGPON, le réseau de distribution optique est assez complexe. Dans le module, l’ODN
sera modélisé comme un simple canal. Seuls le temps de propagation et le débit de la ligne
sont simulés. Le budget optique (Voir §1.5.3.3) est supposé être assuré et les dispositifs
d’émissions et de réception optique sont supposés bien fonctionner. La propagation du signal
optique n’est donc pas simulée et on suppose que les trames descendantes et les bursts
montants arrivent parfaitement au récepteur. [20]

4.3.2 Cas d’utilisation

Dans le cas présent, ce module XGPON sera utilisé pour simuler l’allocation de la bande passante
dans le XGPON. Les compromis indiqués ci-dessous n’influent en rien ou peu sur les résultats
attendus dans le travail envisagé. De plus, l’allocation dynamique de la bande passante est très
importante dans la performance du réseau XGPON alors les classes responsables de cette tâche ont
été soigneusement implémentées par les concepteurs du module. [20]

En résumé, les fonctions du réseau XGPON supportées et non supportées par le module sont
résumées dans le Tableau 4.01.

66
 Supporté Non supporté
XGTC Framing Propagation du signal
PLOAM Engine Codage en ligne
PLOAM Engine FEC
DBA Scrambling
QoS Encryption
XGEM Framing OMCI
Multiplexing/Demultiplexing Activation de l’ONU
Queue Mechanism Ranging
Burst Profile

Tableau 4.01: Fonctions supportées par le module XGPON

4.3.3 Description du module

Le module XGPON est une librairie qu’il faut ajouter et compiler avec les modèles déjà présents
dans le simulateur.

Figure 4.03 : Module XGPON pour NS3

La Figure 4.03 illustre une simulation typique qui utilise ce module XGPON et NS3 pour étudier
les questions de performance sur le XGPON. L’OLT est simulé comme un Node qui possède un
XgponOltNetDevice et d’autres NetDevices, comme par exemple un PointToPointNetDevice, pour
se connecter à d’autre réseau externe. L’ONU est simulé comme un Node qui possède un

67
XgponOnuNetDevice et d’autres NetDevices (Ethernet, Wifi, Wimax, LTE, etc…) pour connecter
les équipements utilisateurs à l’ONU.
Bien que XGPON est proposé pour transporter des trames de couche 2 des diverses technologies de
réseau (Ethernet, ATM, etc.), ce module XGPON interagit directement avec la couche IP et les
paquets IP sont les SDU. Ceci est plutôt raisonnable puisqu’il s’agit ici de réseau d’accès connectés
à Internet.

L’OLT et les ONU sont attachés au XgponChannel qui simule l’ODN. Un ODN est composé de
fibre optique et de splitter mais ici XgponChannel simule uniquement dmax qui est le temps maximal
de propagation pour un trajet simple. Pour une trame descendante, le XgponChannel passera la
trame à chaque ONU après avoir attendu le temps de propagation correspondant d. Un burst montant
provenant d’un ONU sera aussi directement passé à l’OLT après le temps de propagation
correspondant.

Cela signifie que, bien que la différence de temps de propagation entre les ONU est simulée, la
propagation des signaux optiques n’est pas simulée par le XgponChannel. Cette conception est
raisonnable puisque les sujets de recherche ciblés sont en relation avec couches MAC et les couches
supérieures. [20]

4.3.4 Blocs fonctionnels

Les blocs fonctionnels du module sont représentés dans la Figure 4.04. Chaque bloc est représenté
par une ou plusieurs classes au sein du module (Voir Annexe 7). En bleu est indiquée la succession
des procédés subis par les données envoyées dans le sens montant de l’ONU à l’OLT. En vert est
indiquée la succession des étapes de transmission de données dans le sens descendant de l’OLT à
l’ONU. [20]

68
 Figure 4.04 : Bloc fonctionnel du module XGPON

4.4 Objectifs de la simulation

Les objectifs de la simulation sont :

- mettre en évidence le mécanisme du DBA dans le XGPON,
- montrer les influences du DBA sur la qualité de service.

Pour ce faire, on utilise un algorithme DBA particulier : l’algorithme GIANT (GigaPON Access
Network).

69
4.5 Présentation de la simulation

En premier lieu, on a constitué une architecture réseau XGPON composé d’un OLT et d’un nombre
déterminé d’ONU à l’aide du module XGPON dans NS3. Dans cette architecture, il faut mettre en
place la fonction DBA au sein de l’OLT et de chaque ONU. Puis, on a implémenté l’algorithme
GIANT en tant qu’algorithme DBA au sein de l’OLT. Quand tout a été configuré, on lance la
simulation tout en collectant des données des évènements se déroulant au cours de la simulation
dans des fichiers particuliers appelés fichiers de traces. C’est à partir de ces fichiers de traces qu’on
peut tirer des résultats de la simulation. L’analyse des traces est une autre tâche qui se fait après la
simulation.

4.5.1 L’algorithme GIANT

L’algorithme GIANT est le premier algorithme de DBA implémenté physiquement sur un réseau
XGPON déployé. L’algorithme a déjà été utilisé dans de nombreux réseaux GPON. L’algorithme
GIANT fonde ses décisions d'allocation de bande passante sur les rapports d'état d’occupation de la
file d'attente reflétant les fluctuations de trafic ainsi que sur les paramètres de service exprimant le
SLA. Ces paramètres de service sont négociés au cours de la phase d'activation.
Selon les exigences en QoS, les Alloc-ID représentant les files d'attente de données au sein des ONU
sont associés lors de l'activation de service avec l'un des cinq types de T-CONT (T-CONT 1, T-
CONT 2, T-CONT 3, T-CONT 4 et T-CONT 5). Les considérations suivantes sont précisées par
l’algorithme, elles concernent la nature de chaque T-CONT :
- T-CONT 1 n’emploie pas de DBA, mais utilise des allocations de bande passante fixes et
périodiques liées au débit crête du SLA pour offrir des garanties de délai strictes.
- Les T-CONT 2 et 4 sont basés sur une méthode de réservation. Ainsi, ils ne sont desservis
du débit figurant dans le contrat que lorsque des files d'attente non vides sont signalées. De
cette façon, leur part de la bande passante est exploitée lorsqu’ils n’ont rien à transmettre.
La détection d’arrivée est basée sur les sondages ou polling.
- Pour le T-CONT 3, la partie garantie de la bande passante est affectée de manière statique
tandis qu’une bande passante additionnelle peut être attribuée selon les demandes et la
disponibilité. Le débit ne peut dépasser toutefois un maximum convenu comme c’est le cas
du T-CONT 4. Par ailleurs, pour le T-CONT 4, aucun garanti de débit n’est fourni.
- Pour le T-CONT 5, tous les types de bande passante sont assignables en suivant l’ordre de
priorité.

70
Quand un nouveau Alloc-ID est activé signifiant qu’un nouveau flux de trafic est arrivé, un module
de gestion des ressources au niveau de l’OLT vérifie la disponibilité des ressources nécessaires pour
satisfaire les exigences de la nouvelle source, veillant à ce que le total de la bande passante garantie
de tous les Alloc-ID actifs ne dépasse pas la capacité du système.

En fonction du type T-CONT associé, l’OLT calcule les quatre paramètres de services suivants :
- SImin (Service Interval minimum),
- SImax (Service Interval maximum),
- ABmin (Allocation Bytes minimum),
- ABsur (Allocation Bytes surplus).

SImin et SImax indiquent respectivement le minimum et le maximum de l’intervalle de temps après

lequel l’Alloc-ID doit être servi, ils sont exprimés en multiples de la durée d’une trame (125 µs).
ABmin et ABsur indiquent respectivement en octets la taille d’allocation minimum et la taille
d’allocation additionnelle.

𝐴𝐵𝑚𝑖𝑛 (4.01)
La bande passante garantie est exprimée par : 𝑆𝐼𝑚𝑎𝑥
𝐴𝐵𝑠𝑢𝑟 (4.02)
La largeur de bande additionnelle est exprimée par : 𝑆𝐼𝑚𝑖𝑛

Pour le T-CONT 3, le débit crête autorisé est la somme de la bande passante garantie et la bande
passante additionnelle. Pour le T-CONT 4, SImax exprime la période de polling et ABmin est égal
à la taille du DBRu.

Dans chaque trame montante, l’algorithme DBA attribue en premier lieu la largeur de bande garantie
puis la largeur de bande additionnelle s’il reste d’espace disponible dans la trame. [21]

4.5.1.1 Allocation de la partie garantie de la bande passante

Voici le pseudo-code qui montre comment procède l’algorithme GIANT pour l’allocation de la
partie garantie de la largeur de bande :

/*Phase d’allocation de la bande passante garantie*/

/*Inspection de tous les SImax_timer* /
For (chaque AllocID i)
If (SImax_timer(i)=1)

71
 Allocate_guaranteed(i)
SImax_timer(i)=SImax
Else
SImax_timer(i)=SImax_timer(i)-1

/*Processus Allocate_guaranteed(i)*/
If (T-CONT(i)=1 or T-CONT(i)=4)
Allocation_bytes=ABmin
Else
Allocation_bytes=min{ABmin,Request(i)}
Frame_bytes=Frame_bytes – Allocation_bytes
Request(i)=Request(i) – Allocation_bytes
Assign(i,Allocation_bytes)
/* Fin du pseudo-code*/

Assign(i, Allocation_bytes) signifie attribuer Allocation_bytes pour Alloc-ID i. SImax_timer est un

décompteur diminué de 1 à chaque durée d’une trame. SImax est le paramètre de service exprimant
la durée de vie de l’Alloc-ID. Frame_bytes contient la taille de la trame montante. A chaque fois
qu’un rapport d’occupation de file d’attente arrive pour un Alloc-ID j, la longueur de la file d’attente
est stockée dans la case Request[j] de la matrice Request. [21]

4.5.1.2 Allocation de partie additionnelle de la bande passante

Pour l’allocation de la largeur de bande additionnelle, dans le cas du T-CONT 3, SImin est fixé et
ABsur est varié, un service Round Robin pondéré est ainsi appliqué. Si ABsur est fixé, le service
devient un simple Round Robin. C’est pareil pour le service des Alloc-ID du T-CONT 4 [21]. Voici
le pseudo-code qui montre comment procède l’algorithme GIANT pour l’allocation de la partie
additionnelle de la bande passante :

/*Phase d’allocation de la bande passante additionnelle*/

/*Mis à jour des SImin_timer de T-CONT(3) et T_CONT(4) et T_CONT(5) */
For (AllocID i)
If ((T_CONT(i)=3 or T_CONT(i)=4 or T_CONT(i)=5) and SImin_timer(i)>1)
SImin_timer(i)=SImin_timer(i) – 1

72
/*Inspection des Request et SImin_timer de T_CONT 3*/
N=TC3_start_pointer
For (AllocID i)
If (Frame_bytes=0)
TC3_start_pointer = N+i+1
return
Else
If (T_CONT(N+i)=3 and Request (N+i)>0 and SImin_timer(N+i)=1)
allocate_surplus(N+i)

/*Inspection des Request et SImin_timer de T_CONT 4*/

L=TC4_start_pointer
For (AllocID i)
If (Frame_bytes=0)
TC4_start_pointer = L+i+1
return
Else
If (T_CONT(L+i)=4 and Request (L+i)>0 and SImin_timer(L+i)=0)
allocate_surplus(L+i)

/*Inspection des Request et SImin_timer de T_CONT 5*/

P=TC5_start_pointer
For (AllocID i)
If (Frame_bytes=0)
TC5_start_pointer = P+i+1
return
Else
If (T_CONT(P+i)=5 and Request (P+i)>0 and SImin_timer(P+i)=0)
allocate_surplus(P+i)

/*allocate_surplus(i)*/
Allocation_bytes=min{ABsur, Request(i),Frame_bytes}
Assign(i,Allocation_bytes)
SImin_timer(i)=SImin(i)

73
 Frame_bytes=Frame_bytes – Allocation_bytes
Request(i)=Request(i) – Allocation_bytes

/* Fin du pseudo-code */

4.5.2 Architecture du réseau

4.5.2.1 Présentation de l’architecture

Pour pouvoir mettre en évidence l’allocation dynamique de la bande passante, on a constitué une
architecture réseau particulière. L’architecture du réseau XGPON qu’on a simulé sous NS3 se
présente comme suit :
- Un nœud OLT dessert un nombre déterminé de nœuds ONU.
- Chaque nœud dispose de son NetDevice. L’OLT possède un XgponOltNetDevice chaque
ONU possède un XgponOnuNetDevice.
- L’interconnexion entre l’OLT et les ONU est assurée par le XgponChannel.
- L’OLT et les ONU disposent respectivement de leurs adresses MAC et de leurs adresses IP,
ils sont dans le même sous-réseau.
- La fonction DBA est mise en place sur l’OLT et les ONU.
- L’Algorithme GIANT est implémenté sur le bloc fonctionnel responsable du DBA au sein
de l’OLT.
- Pour générer les paquets dans le sens montant, on installe sur chaque ONU une Application
appelée OnOffApplication.
- Au niveau de l’OLT on installe ce qu’on appelle des PacketSink qui consument les paquets
reçus.

Figure 4.05 : Architecture du réseau

74
La visualisation fournie par NetAnim est donnée à la Figure 4.06.

Figure 4.06 : Visualisation sous NetAnim

4.5.2.2 OnOffApplication

L’OnOffApplication de chaque ONU génère un trafic, à un débit exprimé par son attribut DataRate,
dans le sens montant en destination de l’OLT. La particularité du OnOffApplication est qu’il génère
du trafic que pendant un intervalle de temps appélé OnTime et n’en génère pas pendant l’intervalle
de temps suivant appelé OffTime. Quand l’Application est lancée, elle passe alternativement d’un
état ON à un état OFF. Les durées des états ON et OFF correspondent respectivement au OnTime
et au OffTime. Mais dans le cas présent, on a mis l’OffTime égal à 0 pour générer du trafic en
continu. Le trafic généré par l’Application constitue de ce fait une file d’attente au sein de chaque
ONU et c’est ce dont on a besoin pour montrer le DBA. Chaque file d’attente est associée à un T-
CONT, ainsi on dispose d’un T-CONT sur chaque ONU.

4.5.2.3 PacketSink

Le PacketSink est une Application complémentaire de l’OnOffApplication. Le PacketSink est

installé sur le Node destinataire, dans notre cas c’est l’OLT. Le PacketSink reçoit et consume le
trafic généré par l’OnOffApplication.

75
4.5.3 Programmation du simulateur

Les classes principales en charge du DBA dans le module XGPON sont :

- XgponOltDbaEngine : il représente un moteur DBA installé sur le NetDevice de l’OLT
(XgpobOltNetDevice) ; il est responsable de la production du BWmap, de la réception et du
traitement des rapports d’états d’occupation des tampons (DBRu).
- XgponOnuDbaEngine : il représente le bloc fonctionnel DBA de l’ONU ; il est responsable
du traitement du BWmap et de la génération du DBRu.

L’algorithme GIANT est programmé dans une classe XgponOltDbaEngineGiant qui hérite
de la classe XgponOltDbaEngine et ses paramètres se trouvent dans la classe
XgponOltDbaParametersGiant.

Une simulation consiste à écrire une classe principale qui contient le main, où l’on fait appel au
module XGPON et ses différentes classes pour installer tous les blocs fonctionnels du système
XGPON. Pour démarrer le simulateur, on lance cette classe principale (des extraits de codes sources
se trouvent en Annexes 8). Le lancement se fait dans la console du système d’exploitation. Un outil
de construction et de compilation appelé Waf est déjà fourni avec NS3. La ligne de commande
utilisé pour le lancement est : ./waf - - run NomDeLaClasse.

4.5.4 Déroulement général et résultats cherchés

Trois scénarios de simulation ont été effectués avec des paramètres DBA différents.

4.5.4.1 Déroulement d’un scénario

Dans notre architecture, chaque ONU dispose de file d’attente représentant un T-CONT. Chaque T-
CONT est approvisionné en bande passante dynamiquement suivant l’algorithme GIANT
implémenté sur l’OLT. Le trafic dans le sens montant est donc entièrement ordonnancé par
l’algorithme. Arrivée à destination de l’OLT, le trafic est consumé. Un scénario typique se déroule
de cette manière.

4.5.4.2 Résultats cherchés

Puisque le trafic est complètement ordonnancé par l’algorithme, on peut observer le DBA par
l’observation du trafic. Pour ce faire, on trace chaque simulation et on tire les résultats des fichiers

76
de trace. Les fichiers de trace listent les évènements qui se sont déroulés au cours de la simulation
(Voir Annexe 9). Le DBA a un impact important sur le délai et la perte de paquets, ce sont les
résultats qu’on va tirer et interpréter de chaque simulation.

a) Le délai
Le délai est un des principaux critères de QoS. Le délai représente le temps que prend un bit de
données pour traverser le réseau d’un nœud émetteur jusqu’au nœud destinataire. Il est mesuré en
fractions de seconde soit en ms, µs ou ns. Dans notre cas, le délai représente la durée entre l’émission
d’un bit par l’ONU et la réception de ce bit par l’OLT.

b) La perte de paquets
La perte de paquets correspond à la non-délivrance d’un paquet, c’est-à-dire qu’un nombre de
paquets traversant le réseau n’atteignent pas leur destination. Elle est principalement due à
l’encombrement du réseau.

4.5.4.3 Remarque sur la durée d’une simulation

La durée du trafic à simuler est paramétrée au début de la simulation. Cinq secondes de trafic sont
largement suffisantes pour obtenir des résultats pertinents. Notons cependant que le temps mis par
le simulateur pour simuler un trafic de 5 secondes est d’environ une quinzaine de minutes. L’analyse
des fichiers de trace pour un trafic de 5 secondes prend environ trois quarts d’heure. L’obtention de
résultat pour un seul scénario prend donc en moyenne une heure. Avec trois scénarios, la simulation
va durer 3 heures.

4.6 Simulation

La simulation a pour objet de mettre en évidence le DBA et de montrer ses impacts sur la qualité de
service. Pour chaque scénario, le nombre d’ONU desservi par l’OLT est égal à 16. Le trafic est
uniformément réparti sur les 16 ONU. Chaque file d’attente est associée au T-CONT 5 pour pouvoir
supporter tous les types de bande passante. La taille d’un paquet fourni par l’application est de 1472
octets.

4.6.1 Scénario 1 : Largeur de bande fixe

Chaque file d’attente de chaque ONU n’est affectée de la largeur de bande fixe. Le DataRate du
trafic généré par l’application OnOff est varié pour varier la charge de chaque file d’attente. La

77
largeur de bande fixe est égale à 60.928 Mbps. Les résultats obtenu en termes de délai et de pertes
de paquets en fonction du DataRate se trouvent dans le Tableau 4.02.

DataRate Délai (ms) Nombre de Nombre de Perte de Taux de

(Mbps) paquets paquets paquets perte de
envoyés reçus paquets (%)
50 0.568496621175 21229 21226 3 0.141
55 0.632687611688 23352 23349 3 0.0128
60 38.2092393836 25475 25089 386 1.5152
65 116.013488777 27598 25089 2509 9.1912
70 124.479814239 29721 25089 4632 15.5849
75 127.627323026 31844 25089 6755 21.2128
80 129.272830261 33967 25089 8878 26.1371

Tableau 4.02: Résultats de la simulation – Scénario 1

Sous forme de courbes, on obtient une meilleure perception des résultats fournis dans le Tableau
4.02. La Figure 4.07 présente le délai moyen an fonction du débit du trafic généré par l’application
pour le scénario 1. La Figure 4.08 présente la perte de paquets.

Délai en fonction du DataRate (Scénario 1)

140

120

100
Délai (ms)

80

60

40

20

0
50 55 60 65 70 75 80
DataRate (Mbps)

Figure 4.07 : Délai (Scénario 1)

78
 Taux de perte de paquets en fonction du
DataRate (Scénario 1)
30.00%

Taux de perte de paquets 25.00%

20.00%

15.00%

10.00%

5.00%

0.00%
50 55 60 65 70 75 80
DataRate (Mbps)

Figure 4.08 : Perte de paquets (Scénario 1)

On remarque que la qualité de service se dégrade énormément dès que le DataRate est supérieur ou
égal à la largeur de bande fixe attribuée. On est dans ce cas en présence d’une congestion de trafic
au niveau de chaque l’ONU. Cela s’explique par le fait que la quantité de trafic transporté en amont
pour chaque ONU à chaque allocation de bande passante est fixe, la bande passante attribuée ne
peut satisfaire un trafic supérieur à ce niveau fixé. Une congestion de trafic allonge la file d’attente,
augmente le délai moyen et cause une perte innombrable de paquets.

4.6.2 Scénario 2 : Largeur de bande fixe et largeur de bande assurée

Chaque file d’attente au niveau de chaque ONU est affectée d’une largeur de bande fixe de même
valeur que dans le scénario 1 soit 60.928 Mbps. Mais, on affecte en plus à chaque file d’attente une
largeur de bande assurée. La bande passante assurée est attribué dynamiquement selon les besoins.
La valeur maximale a été définie à 16 Mbps. Les résultats obtenus pour le scénario 2 se trouvent
dans le Tableau 4.03.

79
 DataRate Délai (ms) Nombre de Nombre de Perte de Taux de
(Mbps) paquets paquets paquets perte de
envoyés reçus paquets (%)
50 0.568496621172 21229 21226 3 0.0141
55 0.632687911688 23352 23349 3 0.0128
60 1.29119299764 25475 25468 7 0.0275
65 1.34337908463 27598 27590 8 0.0290
70 1.43352234841 29721 29712 9 0.0303
75 10.9117801613 31844 31714 130 0.4082
80 90.64375446547 33967 31715 2252 6.63

Tableau 4.03: Résultats de la simulation – Scénario 2

Les courbes de délai et de perte de paquets pour le scénario 2 sont données respectivement dans les
Figures 4.09 et 4.10.

Délai en fonction du DataRate (Scénario 2)

100
90
80
70
Délai (ms)

60
50
40
30
20
10
0
50 55 60 65 70 75 80
DataRate (Mbps)

Figure 4.09 : Délai (Scénario 2)

80
 Taux de pertes de paquets en fonction du
DataRate (Scénario 2)
7.00%
Taux de perte de paquets 6.00%

5.00%

4.00%

3.00%

2.00%

1.00%

0.00%
50 55 60 65 70 75 80
DataRate (Mbps)

Figure 4.10 : Perte de paquets (Scénario 2)

On remarque tout d’abord que les deux courbes ont la même allure. Cela démontre que le délai et la
perte de paquets sont des critères interdépendants. On remarque également que la qualité de service
s’est améliorée par rapport au scénario 1. La dégradation de performance n’est réellement observée
qu’au-delà du seuil 60.928 Mbps + 16 Mbps soit 76.928 Mbps. La largeur de bande assurée a
satisfait les demandes en bande passante non satisfaites par la largeur de bande fixe. Les résultats
obtenus pour les demandes qui sont entièrement satisfaites par la largeur de bande fixe n’ont
présenté aucun changement comme affiché dans les deux premières lignes des Tableaux 4.02 et
4.03. Cela prouve que la largeur de bande assurée n’est attribuée qu’en cas de besoin.

4.6.3 Scénario 3 : Largeur de bande fixe, largeur de bande assurée et largeur de bande non
assurée

Chaque file d’attente au niveau de chaque ONU est affectée d’une largeur de bande garantie sous
forme d’une largeur de bande fixe de même valeur que dans le scénario 1 et d’une largeur de bande
assurée de même valeur que dans le scénario 2. Une largeur de bande additionnelle sous forme de
largeur de bande non assurée est ajoutée à la largeur de bande garantie. Elle est aussi attribuée
dynamiquement selon les requêtes effectuées par les entités de trafic et la disponibilité, avec un
niveau maximum de 32 Mbps. Les résultats numériques pour le scénario 3 se trouvent dans le
Tableau 4.04 ; les Figures 4.11 et 4.12 sont les courbes associées.

81
DataRate Délai (ms) Nombre de Nombre Perte de Taux de perte
(Mbps) paquets de paquets paquets de paquets
envoyés reçus (%)
50 0.568496621172 21229 21226 3 0.0141
55 0.632687911688 23352 23349 3 0.0128
60 1.29116354892 25475 25468 7 0.0275
65 1.3180891245 27598 27590 8 0.0290
70 1.3543586133 29721 29713 8 0.0269
75 1.36780562227 31844 31835 9 0.0283
80 1.37748556483 33967 33957 10 0.0294

Tableau 4.04: Résultat de la simulation – Scénario 3

Délai en fonction du DataRate

(Scénario 3)
1.6
1.4
1.2
Délai (ms)

1
0.8
0.6
0.4
0.2
0
50 55 60 65 70 75 80
DataRate (Mbps)

Figure 4.11 : Délai (Scénario 3)

Taux de perte de paquets en fonction du

DataRate (Scénario 3)
Taux de perte de paquets

0.04%
0.03%
0.03%
0.02%
0.02%
0.01%
0.01%
0.00%
50 55 60 65 70 75 80
DataRate (Mbps)

Figure 4.12 : Perte de paquets (Scénario 3)

82
On remarque que le délai a une limite supérieure de 1,4 ms et que le taux de perte de paquets a une
limite supérieure de 0.03%. On constate donc une très bonne qualité de service. La largeur de bande
additionnelle a satisfait les requêtes non satisfaites par la largeur de bande garantie. Elle n’est pas
utilisée par les entités de trafic dont les besoins en bande passante sont complètement satisfaits par
la largeur de bande garantie.

4.6.4 Récapitulatif

Pour avoir une vue globale de la simulation et permettre ainsi une meilleure interprétation, on a
regroupé respectivement sur une même figure le délai (Figure 4.13) et la perte de paquets (Figure
4.14) pour les trois scénarios.

140
Délai en fonction du DataRate
120
100
Délai (ms)

80
60
40
20
0
50 55 60 65 70 75 80
DataRate (Mbps)
Scénario 1 Scénario 2 Scénario 3

Figure 4.13 : Délai (Tous les scénarios)

Taux de perte de paquets en fonction du DataRate

30.00%
Taux de perte de paquets

25.00%

20.00%

15.00%

10.00%

5.00%

0.00%
50 55 60 65 70 75 80
DataRate (Mbps)
Scénario 1 Scénario 2 Scénario 3

Figure 4.14 : Perte de paquets (Tous les scénarios)

83
Ces deux figures (Figures 4.13 et 4.14) permettent de mettre en évidence l’allocation dynamique de
la bande passante dans le XGPON. Les types de largeur de bande sont attribués en suivant l’ordre
de priorité. La largeur de bande fixe est affectée en premier, de manière statique. La largeur de bande
assurée complète la largeur de bande garantie, elle est attribuée dynamiquement. La largeur de bande
additionnelle est attribuée dynamiquement, elle peut être sous forme de largeur de bande non assurée
ou de largeur de bande best effort. Dans notre cas, elle est sous forme non assurée.

Ces deux figures montrent également l’interdépendance entre le délai et la perte de paquets. Une
augmentation du délai est accompagnée d’une augmentation du taux de pertes de paquets. Cette
augmentation est causée par des demandes de bande passante non satisfaites. On peut donc en
déduire que les causes entraînant une variation du délai possède la même influence sur la perte des
paquets.

On constate aussi que l’allocation dynamique de la bande passante est déterminante pour la qualité
de service. Il a une très grande influence sur deux des plus importants critères de QoS. Puisqu’elle
est le moteur de l’ordonnancement du trafic dans le sens montant dans le XGPON, il est donc un
élément important pour assurer une bonne qualité de service pour le trafic amont dans le XGPON.

Enfin, on remarque également dans ces deux figures la performance de l’algorithme GIANT.
L’algorithme supporte parfaitement les pics de trafic et les trafics avec des exigences en termes de
temps de transmission. En effet, lorsque le trafic est affecté de la bonne combinaison de largeur de
bande, le délai ne dépasse pas 1,4 ms et le taux de perte de paquets est presque nul.

4.7 Avantage et inconvénient de l’algorithme

Dans l’algorithme GIANT, chaque file d'attente au sein de chaque ONU a un décompteur pour
l'allocation de la bande passante. L'OLT alloue une bande passante à une file d'attente lorsque le
décompteur de cette file d'attente a expiré. La simplicité de GIANT fournit la faisabilité de sa mise
en œuvre. L’algorithme GIANT offre de bonnes performances. Ces dernières se dégradent
seulement lorsqu’une requête d'une file d'attente ne peut être satisfaite après que le décompteur de
la file ait expiré.

84
4.8 Conclusion

Bref, cette simulation a montré comment fonctionne le DBA dans un XGPON, les différents
scénarios ont mis en évidence les étapes du DBA. On a également constaté que le DBA a un impact
considérable sur la qualité de service. L’algorithme utilisé, le GIANT, est simple mais efficace. Il
sert de point de départ à l’élaboration de nouvel algorithme. Par ailleurs, on peut dire que NS3
possède de bonnes capacités de simulation en termes de vitesse et de précisions des résultats fournis.
Aussi, le module XGPON utilisé répond parfaitement aux spécifications du standard par l’ITU-T.
On peut donc penser que les résultats obtenus au cours de cette simulation pourraient être très
proches des résultats qu’on pourrait obtenir sur un système réel.

85
 CONCLUSION GENERALE

En somme, le réseau d’accès constitue le lien direct d’un opérateur réseau avec ses clients. Le
déploiement de la fibre optique jusqu’à l’usager permet de mettre en place une boucle locale
puissante. Les solutions d’accès optiques sont connues actuellement pour être les plus performantes
parmi les technologies utilisées en réseau d’accès. Le réseau optique passif ou PON est la solution
d’accès optique la plus attrayante du fait de sa rentabilité et des nombreuses opportunités qu’il
présente, elle est l’architecture la plus utilisée pour les réseaux d’accès optique.

Dans cet ouvrage, on s’est intéressé au dernier standard de réseau optique passif, c’est-à-dire le
XGPON ; on y a effectué l’étude de l’allocation dynamique de la bande passante dans le sens
montant. L’allocation dynamique de la bande passante améliore l’efficacité d’utilisation des
ressources dans le sens montant et possède une très grande influence sur la qualité de service.
L’allocation dynamique de la bande passante est assurée par un algorithme implémenté au niveau
de la terminaison de ligne optique ou OLT. Grâce à une simulation, on a pu mettre en évidence le
fonctionnement de l’allocation dynamique de la bande passante dans le XGPON et montrer ses
impacts sur la qualité de service. Le GIANT est l’algorithme utilisé pour la simulation, il offre de
bonnes performances et une simplicité de mise en œuvre.

Les réseaux optiques passifs présentent de nombreuses perspectives. En effet, c’est une technologie
qui va encore évoluer. Un nouveau standard est déjà en cours de normalisation : le NGPON2. Les
réseaux optiques passifs sont capables de fournir les ressources nécessaires pour assurer le plus
grand confort d’utilisation des services disponibles actuellement. En plus, ils permettent déjà de
prévoir les futurs services encore plus gourmands en bande passante. L’avenir est indéniablement à
la fibre, et la mobilité est d’actualité avec la « Fibre jusqu’à la cellule » qui est prévu pour la
quatrième génération de réseau mobile.

Ce travail touche à sa fin. Dans le cadre d’un travail futur, on peut envisager de chercher un nouvel
algorithme d’allocation dynamique de la bande passante pour le XGPON et les futurs standards.

86
 ANNEXE 1 :

MODELE GENERAL DE REFERENCE DE PROTOCOLE POUR LE RESEAU

D’ACCES

Le modèle général de référence de protocole pour le réseau d’accès est spécifié dans la
recommandation G.902 de l’ITU-T. Ce modèle est utilisé pour la définition de l'interaction des
entités homologues dans le réseau d’accès. La Figure A1.01 décrit les couches et leurs relations.

Figure A1.01 : Modèle général de référence de protocole pour le réseau d’accès

La couche de support de transmission, la couche de conduit et la couche de circuit constitue la

couche de transport de réseau d'accès. La couche de circuit fournit aux usagers des services de
télécommunication tels que les services à commutation de circuits, les services à commutation par
paquets et les services de ligne louée. On peut distinguer différentes couches de circuit selon les
services assurés. La couche de conduit sert de support à une ou plusieurs couches de circuit et elle
est indépendante de la couche de support de transmission. La couche de support de transmission
dépend du support et chargée du transfert d'informations. Elle est composée de la couche de section
et de la couche de support physique. Des exemples d'attributs de couches dans le réseau d'accès sont
rapportés dans le Tableau A1.01. [14]

87
 Supports Signalisation
Capacité support d’accès requise Commande Gestion
d’usager d’usager
Fonction de traitement de support
A définir selon l’interface de nœud se service
d’accès
Type en mode
Type en Type en
Couche de circuit circuit (Type Type ATM
mode paquet mode trame
STM)
Couche de conduit Type PDH Type SDH Type ATM Autres

Couche de Couche de section

support de A définir
Couche de support
transmission
physique

Tableau A1.01 : Attributs de couches dans le réseau d'accès

88
 ANNEXE 2 :

CARACTERISTIQUES DE LA FIBRE MONOMODE G.652

Les caractéristiques de la fibre monomode sont spécifiées dans la recommandation G.652 de l’ITU-
T. Cette recommandation décrit les attributs géométriques, mécaniques et de transmission de câbles
et fibres optiques monomodes dont la longueur d'onde de dispersion nulle se trouve au voisinage de
1310 nm. Optimisées au départ pour la région des 1310 nm, ces fibres peuvent également être
utilisées au voisinage de 1550 nm. Les caractéristiques des fibres dites G.652 sont résumées dans le
Tableau A2.01. [15]

Attribut Détail Valeur

Longueur d’onde 1310 nm (et 1550 nm)
Diamètre du champ de mode Plage des valeurs nominales 8,6 µm à 9,5 µm
Tolérance ± 0,6 µm
Nominal 125 µm
Diamètre de gaine
Tolérance ± 1µm
Erreur de concentricité du cœur Maximum 0,6 µm
Non-circularité de gaine Maximum 1%
Longueur d’onde de coupure du câble Maximum 1260 nm
Rayon 30 nm
Perte par microcourbure Nombre de tours 100
Maximum à 1550 nm 0.1 dB
Tension limite d’allongement Minimum 0.69 GPa
𝜆0𝑚𝑖𝑛 1300 nm
Coefficient de dispersion chromatique 𝜆0𝑚𝑎𝑥 1324 nm
𝑆0𝑚𝑎𝑥 0.092 ps/nm2 x km

Tableau A2.01 : Caractéristiques de la fibre G.652

89
 ANNEXE 3 :

LISTE DES MESSAGES PLOAM

Le canal de messagerie PLOAM est basé sur un jeu de messages transporté dans un champ désigné
du XGTC frame header et du XGTC burst header. Les fonctions du canal PLOAM sont
principalement la communication du burst profile, l’activation de l’ONU, l’enregistrement de
l’ONU, l’échange de clé de chiffrement, la gestion de l’énergie… Un message PLOAM a une taille
de 48 octets, sa structure est présentée dans le Tableau A3.01. [13]

Octet Nom du champ Description

Les 6 premiers bits sont réservés et sont mis à 0. Les 10 derniers
1-2 ONU-ID
bits contiennent l’ONU-ID
3 Message type ID Type de message
4 SeqNo Numéro de séquence
5 - 40 Message_content Contenu du message
41 - 48 MIC Message Integrity Check (pour vérifier de l’intégrité du message)

Tableau A3.01 : Structure d’un message PLOAM

La liste des principaux messages PLOAM dans le sens descendant est donnée dans le Tableau
A3.02.

Message type ID Nom du message Fonction

0x01 Profile Indication du burst profile
0x03 Assign_ONU_ID Attribution de l’ONU-ID
0x04 Ranging_time Indication du délai d’égalisation
0x05 Deactivate_ONU_ID Instruction reset pour ONU
Désactivation de l’ONU possédant le numéro de
0x06 Disable_Serial_Number
série indiqué
0x09 Request_Registration Requête d’enregistrement ONU
0x0A Assign-Alloc-ID Attribution d’un Alloc-ID à un ONU
Indication à un ONU de générer un nouveau clé
0x0D Key_Control
de chiffrement
Activation ou désactivation en temps réel du
0x12 Sleep_Allow
mode économie d’énergie de l’ONU

Tableau A3.02 : Messages PLOAM dans le sens descendant

90
La liste des principaux messages PLOAM dans le sens montant est donnée dans le Tableau A3.03.

Message type ID Nom du message Fonction

0x01 Serial_Number_ONU Informer le numéro de série
0x02 Registration Enregistrement d’un ONU
0x05 Key_Report Envoi de la clé de chiffrement
0x09 Acknowledgement Indication de la réception d’un message
Indication d’entrée ou de sortie du mode
0x10 Sleep_Request
économie d’énergie

Tableau A3.03 : Messages PLOAM dans le sens montant

91
 ANNEXE 4 :

HYBRID ERROR CORRECTION ET SCRAMBLER SEQUENCE

A4.1 HEC

La structure du HEC est montrée dans les Figures A4.01 et A4.02. Le HEC est très utilisé dans le
XGPON à plusieurs endroits. Par exemple, dans le XGTC header, il est applique au champ protégé
ou protected field de 19 bits pour produire une structure totale de 32 bits. Dans le BWmap et
plusieurs autres champs, le protected field est de 51 bits et on obtient après une structure totale de
64 bits. La Figure A4.01 illustre le HEC pour un protected field de 51 bits et la Figure A4.02 illustre
le HEC pour un protected field de 19 bits. [13]

Figure A4.01 : HEC 64 bits

Figure A4.02 : HEC 32 bits

Le HEC est une combinaison de code BCH (63,12,2) et d’un bit de parité. Le polynôme générateur
du code BCH (62,12,2) est 𝑥12 + 𝑥10 + 𝑥 8 + 𝑥 5 + 𝑥 4 + 𝑥 3 + 1.

A4.2 Scrambler Sequence

Les premiers 256 bits de la séquence d’embrouillage est donnée dans la Figure A4.03 en
représentation binaire et hexadécimal. [13]

92
Figure A4.03 : Séquence d’embrouillage

93
 ANNEXE 5 :

MAPPAGE DE SERVICE DANS LE XGEM FRAME

A5.1 Mappage de trame Ethernet

Les trames Ethernet sont transportées directement dans le XGEM payload. Le préambule IEEE 802
et le SFD (Start Frame Delimiter) sont rejetés avant l’encapsulation. Chaque trame Ethernet est
mappée dans un seul XGEM frame or plusieurs XGEM frames tout en respectant les règles de
fragmentation. Un XGEM frame ne peut encapsuler plus d’une trame Ethernet. [13]

Figure A5.01 : Mappage de trame Ethernet

A5.2 Mappage de paquet MPLS

Les paquets MPLS sont transportés directement dans le XGEM payload. Chaque paquets MPLS est
mappé dans un seul XGEM frame or plusieurs XGEM frames tout en respectant les règles de
fragmentation. Un XGEM frame ne peut encapsuler plus d’un paquet MPLS. [13]

Figure A5.02 : Mappage de paquet MPLS

94
 ANNEXE 6 :

BURST PROFILE

Les burst profiles sont utilisés par la sous-couche PHY Adaptation de l’ONU pour former le PHY
burst amont. Ce sont les champs preamble et delimiter de PSBu qui constitue le burst profile. Ces
champs sont utilisés par le récepteur de l’OLT pour déterminer la présence d’un PHY burst et pour
effectuer sa délimitation. Ils sont également employés pour déterminer l’horloge du signal dans le
but de bien reconstituer le signal transmis. La longueur et le motif de ces deux champs sont formés
comme indiqué par l’OLT dans le champ BurstProfile du BWmap. L’index contenu dans le champ
BurstProfile se réfère à un ensemble de profil admis. Cet ensemble de profil admis est communiqué
aux ONU par le canal PLOAM.
La taille recommandée pour le preamble est de 160 bits mais le motif traditionnel est 0x AAAA
AAAA. La taille recommandée pour le delimiter est de 32 bits mais un delimiter plus long de 64
bits est requis en cas de BER élévé pour permettre une meilleure délimitation. Dans d’autre cas, il
est préférable d’indiquer si le FEC est activé ou non.
Les valeurs conseillées du preamble et du delimiter sont données dans le Tableau A6.01. [13]

Preamble Delimiter 32 bits Delimiter 64 bits

0x A376 70C9
0x BB52 1E26 0x 4BDE 1B90 (FEC on)
0x A376 70C9 (FEC off)
0x AD4C C30F
0x AAAA AAAA 0x A566 79E0 (FEC on)
0x AD4C C30F (FEC off)
0x B9D4 3E68 462B C197
0x B9D4 3E68 462B C197 (FEC on)
0x B752 1F06 48AD E879 (FEC off)
0x B3BD D310 B2C5 0FA1
0x B3BD D310 B2C5 0FA1 (FEC on)
0x CE99 CE5E 5028 B41F (FEC off)

Tableau A6.01 : Preamble et Delimiter

95
 ANNEXE 7 :

LISTE DES MODELES DU MODULE XGPON

Voici la liste des classes présentes dans le module XGPON : [20]

pon-channel xgpon-onu-conn-manager-speed
pon-frame xgpon-onu-dba-engine
pon-net-device xgpon-onu-engine
xgpon-burst-profile xgpon-onu-framing-engine
xgpon-channel xgpon-onu-net-device
xgpon-connection xgpon-onu-omci-engine
xgpon-connection-receiver xgpon-onu-phy-adapter
xgpon-connection-sender xgpon-onu-ploam-engine
xgpon-ds-frame xgpon-onu-us-scheduler
xgpon-fifo-queue xgpon-onu-us-scheduler-round-robin
xgpon-key xgpon-onu-xgem-engine
xgpon-link-info xgpon-phy
xgpon-net-device xgpon-psbd
xgpon-olt-conn-manager-flexible xgpon-psbu
xgpon-olt-conn-manager xgpon-qos-parameters
xgpon-olt-conn-manager-speed xgpon-queue
xgpon-olt-conn-per-onu xgpon-service-record
xgpon-olt-dba-bursts xgpon-tcont
xgpon-olt-dba-engine xgpon-tcont-olt
xgpon-olt-dba-engine xgpon-tcont-onu
xgpon-olt-dba-engine-round-robin xgpon-us-burst
xgpon-olt-dba-per-burst-info xgpon-xgem-frame
xgpon-olt-ds-scheduler xgpon-xgem-header
xgpon-olt-ds-scheduler-round-robin xgpon-xgem-routines
xgpon-olt-engine xgpon-xgtc-bw-allocation
xgpon-olt-framing-engine xgpon-xgtc-bwmap
xgpon-olt-net-device xgpon-xgtc-dbru
xgpon-olt-omci-engine xgpon-xgtc-ds-frame
xgpon-olt-phy-adapter xgpon-xgtc-ds-header
xgpon-olt-ploam-engine xgpon-xgtc-ploam
xgpon-olt-xgem-engine xgpon-xgtc-us-allocation
xgpon-onu-conn-manager-flexible xgpon-xgtc-us-burst
xgpon-onu-conn-manager xgpon-xgtc-us-header

96
 ANNEXE 8 :

EXTRAIT DE CODES SOURCES

A8.1 : Classe XgponOltDbaEngineGiant

La classe XgponOltDbaEngineGiant hérite de la classe XgponOltDbaEngine du module XGPON.

L’implémentation de l’algorithme se trouve dans cette classe. Voici quelques lignes de cette classe :

#include "ns3/log.h"
#include "ns3/simulator.h"

#include "xgpon-olt-dba-engine-giant.h"
#include "xgpon-olt-dba-parameters-giant.h"
#include "xgpon-olt-net-device.h"
#include "xgpon-phy.h"
#include "xgpon-olt-ploam-engine.h"
#include "xgpon-link-info.h"
#include "xgpon-burst-profile.h"
#include "ns3/enum.h"
#include "ns3/uinteger.h"
#include "ns3/double.h"
#include <vector>

NS_LOG_COMPONENT_DEFINE ("XgponOltDbaEngineGiant");

namespace ns3 {

NS_OBJECT_ENSURE_REGISTERED (XgponOltDbaEngineGiant);

TypeId
XgponOltDbaEngineGiant::GetTypeId (void)
{
static TypeId tid = TypeId ("ns3::XgponOltDbaEngineGiant")
.SetParent<XgponOltDbaEngine> ()
.AddConstructor<XgponOltDbaEngineGiant> ();
return tid;
}

TypeId
XgponOltDbaEngineGiant::GetInstanceTypeId (void) const
{
return GetTypeId ();
}

XgponOltDbaEngineGiant::XgponOltDbaEngineGiant () : XgponOltDbaEngine(),
m_lastScheduledAllocIndex(0),
m_nullTcont(0),
m_getNextNonAssuredTcontAtBeginning(false),
m_getNextBestEffortTcontAtBeginning(false),
m_stop(false)
{
m_usAllTcons.clear();

97
}

XgponOltDbaEngineGiant::~XgponOltDbaEngineGiant ()
{
}

void
XgponOltDbaEngineGiant::DoInitialize()
{
}

void XgponOltDbaEngineGiant::GenerateAllocOltGiantParameterPairs()
{
std::vector< Ptr<XgponTcontOlt> >::iterator it;
for (it = m_usAllTcons.begin(); it!=m_usAllTcons.end(); it++) {
Ptr<XgponQosParameters> qos = (*it)->GetAggregatedQosParameters();

Ptr<XgponOltDbaParametersGiant> giantParameter;

uint32_t serviceRateFixed, serviceRateAssured, serviceRateNonAssured,

serviceRateBestEffort, serviceRateMax;
uint64_t serviceIntervalMax, serviceIntervalMin;

//Fixe
serviceRateFixed = qos->GetFixedBw();
if(serviceRateFixed>0)
{
serviceIntervalMax = qos->GetMaxInterval();
giantParameter = CreateObjectWithAttributes<XgponOltDbaParametersGiant>(
"ServiceInterval",UintegerValue(serviceIntervalMax),
"ServiceIntervalTimer",UintegerValue(serviceIntervalMax),
"AllocationBytes",UintegerValue(GetAllocationBytesFromRateAndServiceInterval(se
rviceRateFixed, serviceIntervalMax)),
"BandwidthType",UintegerValue(XGPON_GIANT_BW_FIXED));
m_allocOltFixedBandwidthPair.push_back (std::make_pair((*it),
giantParameter));
}

//Assurée
serviceRateAssured = qos->GetAssuredBw();
if(serviceRateAssured>0)
{
serviceIntervalMax = qos->GetMaxInterval();
giantParameter = CreateObjectWithAttributes<XgponOltDbaParametersGiant>(
"ServiceInterval",UintegerValue(serviceIntervalMax),
"ServiceIntervalTimer",UintegerValue(serviceIntervalMax),
"AllocationBytes",UintegerValue(GetAllocationBytesFromRateAndServiceInterval(se
rviceRateAssured,serviceIntervalMax)),
"BandwidthType",UintegerValue(XGPON_GIANT_BW_ASSURED));
m_allocOltAssuredBandwidthPair.push_back (std::make_pair((*it),
giantParameter));
}

//Non Assurée
serviceRateNonAssured = qos->GetNonAssuredBw();
if(serviceRateNonAssured>0)
{
serviceIntervalMin = qos->GetMinInterval();

98
 giantParameter = CreateObjectWithAttributes<XgponOltDbaParametersGiant>(
"ServiceInterval",UintegerValue(serviceIntervalMin),
"ServiceIntervalTimer",UintegerValue(serviceIntervalMin),
"AllocationBytes",UintegerValue(GetAllocationBytesFromRateAndServiceInterval(se
rviceRateNonAssured,serviceIntervalMin)),
"BandwidthType",UintegerValue(XGPON_GIANT_BW_NON_ASSURED));
m_allocOltNonAssuredBandwidthPair.push_back (std::make_pair((*it),
giantParameter));
}

//Best Effort
serviceRateMax = qos->GetMaxBw();
serviceRateBestEffort = (serviceRateMax - serviceRateFixed -
serviceRateAssured - serviceRateNonAssured);
if(serviceRateBestEffort>0)
{
serviceIntervalMin = qos->GetMinInterval();
giantParameter = CreateObjectWithAttributes<XgponOltDbaParametersGiant>(
"ServiceInterval",UintegerValue(serviceIntervalMin),
"ServiceIntervalTimer",UintegerValue(serviceIntervalMin),
"AllocationBytes",UintegerValue(GetAllocationBytesFromRateAndServiceInterval(se
rviceRateBestEffort, serviceIntervalMin)),
"BandwidthType",UintegerValue(XGPON_GIANT_BW_BEST_EFFORT));
m_allocOltBestEffortBandwidthPair.push_back (std::make_pair((*it),
giantParameter));
}

m_nonAssuredLastServedTcont=m_nonAssuredFirstServedTcont=m_allocOltNonAssuredBa
ndwidthPair.begin();

m_bestEffortLastServedTcont=m_bestEffortFirstServedTcont=m_allocOltBestEffortBa
ndwidthPair.begin();

99
A8.2 : Classe principale pour la simulation

Voici quelques lignes de code de la classe principale qui contient le main pour démarrer le
simulateur et exécuter la simulation :

#include <iostream>
#include <fstream>

#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/internet-module.h"
#include "ns3/object-factory.h"
#include "ns3/applications-module.h"
#include "ns3/point-to-point-module.h"

#include "ns3/xgpon-module.h"

...

int
main (int argc, char *argv[])
{
...

/* Creation des ONU et de l'OLT */

NodeContainer oltNode, onuNodes;
oltNode.Create (1);
onuNodes.Create (nOnus);

NodeContainer xgponNodes;
xgponNodes.Add(oltNode.Get(0));
for(int i=0; i<nOnus; i++) { xgponNodes.Add (onuNodes.Get(i)); }

...

/* Configuration des XGEM ports et des Alloc-Id */

for(int i=0; i<nOnus; i++)

{
Address addr = xgponInterfaces.GetAddress(i+1);

Ptr<XgponOltNetDevice> oltDevice = DynamicCast<XgponOltNetDevice,

NetDevice> (xgponDevices.Get(0));
Ptr<XgponOnuNetDevice> onuDevice = DynamicCast<XgponOnuNetDevice,
NetDevice> (xgponDevices.Get(i+1));

xgponHelper.SetQosParametersAttribute ("FixedBandwidth", UintegerValue

(fixedBw[i]) );
xgponHelper.SetQosParametersAttribute ("AssuredBandwidth", UintegerValue
(assuredBw[i]) );
xgponHelper.SetQosParametersAttribute ("NonAssuredBandwidth", UintegerValue
(nonAssuredBw[i]) );
xgponHelper.SetQosParametersAttribute ("MaxBandwidth", UintegerValue
(maxBw[i]) );

100
 xgponHelper.SetQosParametersAttribute ("MaxServiceInterval", UintegerValue
(siMax[i]) );
xgponHelper.SetQosParametersAttribute ("MinServiceInterval", UintegerValue
(siMin[i]) );
xgponHelper.SetQosParametersAttribute ("TcontType", EnumValue
(XgponQosParameters::XGPON_TCONT_TYPE_5) );

uint16_t allocId = xgponHelper.AddOneTcontForOnu (onuDevice, oltDevice);

uint16_t upPortId = xgponHelper.AddOneUpstreamConnectionForOnu (onuDevice,
oltDevice, allocId, addr);
uint16_t downPortId = xgponHelper.AddOneDownstreamConnectionForOnu
(onuDevice, oltDevice, addr);
allocIdList.push_back(allocId);
}

/* OnOff Application et PacketSink */

ApplicationContainer onuApps;
ApplicationContainer oltApps;
for(uint32_t i=0; i<nOnus;i++)
{
serverPorts[i]= 9000+i;
}
for(int i=0; i<nOnus; i++)
{
OnOffHelper onOff ("ns3::UdpSocketFactory",InetSocketAddress(Ipv4Address
(xgponInterfaces.GetAddress(0)), serverPorts[i]));
onOff.SetAttribute ("OnTime", StringValue
("ns3::ConstantRandomVariable[Constant=1000]"));
onOff.SetAttribute ("OffTime", StringValue
("ns3::ConstantRandomVariable[Constant=0]"));
onOff.SetAttribute("DataRate", DataRateValue(DataRate(dataRate)));
onOff.SetAttribute("PacketSize", UintegerValue(packetSize));
onOff.SetAttribute("MaxBytes", UintegerValue(maxBytes));

onuApps.Add(onOff.Install(xgponNodes.Get(i+1)));
}

for(int i=0; i<nOnus; i++)

{
PacketSinkHelper packetSink
("ns3::UdpSocketFactory",InetSocketAddress(Ipv4Address
(xgponInterfaces.GetAddress(0)), serverPorts[i]));
oltApps.Add(packetSink.Install(xgponNodes.Get(0)));
}

onuApps.Start (Seconds (appStart));

onuApps.Stop (Seconds (appStop));
oltApps.Start (Seconds (appStart));
oltApps.Stop (Seconds (appStop));

/* Initialisation du DBA */

Ptr<XgponOltNetDevice> oltDevice = DynamicCast<XgponOltNetDevice, NetDevice>

(xgponDevices.Get(0));
Ptr<XgponOltDbaEngine> dbaEngine = oltDevice->GetDbaEngine();

DynamicCast<XgponOltDbaEngineGiant,XgponOltDbaEngine> (dbaEngine)-
>GenerateAllocOltGiantParameterPairs();

101
 std::vector< uint16_t >::iterator it;
uint32_t timerIt;

for (it = allocIdList.begin(), timerIt=0; it!=allocIdList.end();it++,

timerIt++)
{
DynamicCast<XgponOltDbaEngineGiant,XgponOltDbaEngine> (dbaEngine)-
>SetTimerStartValue(*it, XGPON_GIANT_BW_FIXED, fixedInitialTimers[timerIt]);
DynamicCast<XgponOltDbaEngineGiant,XgponOltDbaEngine> (dbaEngine)-
>SetTimerStartValue(*it, XGPON_GIANT_BW_ASSURED,
assuredInitialTimers[timerIt]);
DynamicCast<XgponOltDbaEngineGiant,XgponOltDbaEngine> (dbaEngine)-
>SetTimerStartValue(*it, XGPON_GIANT_BW_NON_ASSURED,
nonAssuredInitialTimers[timerIt]);
DynamicCast<XgponOltDbaEngineGiant,XgponOltDbaEngine> (dbaEngine)-
>SetTimerStartValue(*it, XGPON_GIANT_BW_BEST_EFFORT,
bestEffortInitialTimers[timerIt]);
}

...

/* Lancer la simulation */
Simulator::Stop(Seconds(simStop));
Simulator::Run ();
Simulator::Destroy ();
return 0;
}

102
 ANNEXE 9 :

FICHIERS DE TRACE

Un fichier de trace liste tous les évènements qui se sont déroulés au cours d’une simulation avec
NS3. L’analyse des fichiers de trace permet de déduire des métriques sur la performance du réseau
simulé. Un fichier de trace peut comporter des milliers de lignes, on ne peut donc pas l’analyser
manuellement. Il faut écrire un script qui passe une à une les lignes du fichier, une ligne décrit un
évènement. Voici deux lignes d’un fichier de trace :

Ligne 1 :
+ 0.00137386 ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 13 protocol 17 offset
(bytes) 0 flags [none] length: 1500 10.0.0.2 > 10.0.0.1) ns3::UdpHeader (length: 1480 49153 >
9000) Payload (size=1472)

Ligne 2 :
- 0.00140003 ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 0 protocol 17 offset
(bytes) 0 flags [none] length: 1500 10.0.0.2 > 10.0.0.1) ns3::UdpHeader (length: 1480 49153 >
9000) Payload (size=1472)

Au début d’une ligne on a soit le signe + soit le signe –. Le signe + signifie une mise en file d’attente
d’un paquet, le signe – signifie un envoi, c’est-à-dire la sortie de la file d’attente d’un paquet. Le
signe + ou – est suivi de l’instant auquel s’est déroulé l’évènement en seconde. Ensuite on a l’en-
tête du paquet : Ipv4Header. Entre parenthèses se trouvent les détails sur l’en-tête IPv4, on peut citer
le tos, le ttl, l’offset, la longueur du paquet (en-tête IPv4 compris), l’adresse source et l’adresse
destination. On a après l’en-tête suivant : UdpHeader, avec ses caractéristiques entre parenthèses.
A la fin, on a la taille de la charge utile. Une charge utile de 1472 octets avec un UdpHeader 8 octets
donne 1480 octets. On obtient 1500 octets avec l’Ipv4Header de 20 octets.

103
BIBLIOGRAPHIE

[1] F. Saliou, « Etudes des solutions d’accès optique exploitant une extension de portée »,
TELECOM PARIS TECH, Thèse de doctorat, 2010

[2] G. Pujolle, « Les Réseaux », EYROLLES, 2014

[3] A. Perez, « Architecture des réseaux fixes », LAVOISIER, 2011

[4] F. Raharimanitra, « Contribution à l’étude des architectures basées sur le multiplexage en temps
et en longueur d’onde dans le réseau d’accès, permettant la migration vers la nouvelle génération
de PON (NGPON) à 10 Gbits/s », Télécom Bretagne, Thèse de doctorat, 2012

[5] ITU-T, « Broadband optical access systems based on Passive Optical Networks (PON) »,
Recommandations G.983.1, 2005

[6] ITU-T, « Réseaux d’accès optiques pour la prise en charge des services fonctionnant jusqu’au
débit primaire du RNIS ou à des débits équivalents », Recommandations G.982, 1996

[7] ITU-T, « Gigabit-capable passive optical networks (GPON) : General characteristics »,

Recommandations G.984.1, 2008

[8] ITU-T, « Gigabit-capable Passive Optical Networks (G-PON) : Physical Media Dependent
(PMD) layer specification », Recommandations G.984.2, 2003

[9] ITU-T, « Gigabit-capable passive optical networks (G-PON) : Transmission convergence layer
specification », Recommandations G.984.3, 2014

[10] ITU-T, « 10-Gigabit-capable passive optical network (XG-PON) systems : Definitions,

abbreviations and acronyms », Recommandations G.987, 2012

[11] ITU-T, « 10-Gigabit-capable passive optical network (XG-PON) systems : General

requirements », Recommandations G.987.1, 2010

[12] ITU-T, « 10-Gigabit-capable passive optical network (XG-PON) systems : Physical media
dependent (PMD) layer specification », Recommandations G.987.2, 2010

104
[13] ITU-T, «10-Gigabit-capable passive optical network (XG-PON) systems : Transmission
convergence (TC) layer specification », Recommandations G.987.3, 2014

[14] ITU-T, « Framework Recommendation on functional access networks (AN) - Architecture and
functions, access types, management and service node aspects », Recommandations G.902, 1995

[15] ITU-T, « Characteristics of a single-mode optical fibre and cable », Recommandations G.652,
2009

[16] ITU-T, « A broadband optical access system with increased service capability using dynamic
bandwidth assignment », Recommandations G.983.4, 2001

[17] « ns-3 Manual, Release ns-3.19 », ns-3 project, 2014

[18] « ns-3 Tutorial, Release ns-3.19 », ns-3 project, 2013

[19] « ns-3 Model Library, Release ns-3-dev », ns-3 project, 2012

[20] X. Wu, K. N. Brown, C. J. Sreenan, J. Arokkiam, P. Alvarez, M. Ruffini, N. Marchetti, D.

Payne, L. Doyle, « An XG-PON Module for the NS-3 Network Simulator : The Manual »,
Department of Computer Science, University College Cork, Ireland, CTVR / The
Telecommunications Research Centre, Trinity College Dublin, Ireland, 2013

[21] H. C. Leligou, CH. Linardakis, K. Kanonakis, J. D. Angelopoulos, TH. Orphanoudakis,

« Efficient medium arbitration of FSAN-compliant GPONs », International Journal of
Communication Systems, Volume 19, Page 603-617, 2006.

105
 FICHE DE RENSEIGNEMENTS

Nom : ANDRIASAMIMANANA
Prénoms : Rivohasindranto Nomenjanahary
Adresse : Lot III E 38 J Ankazomanga Sud
ANTANANARIVO 101
Téléphone : +261 (0) 34 81 083 00
E-mail : nomenjanahary100@gmail.com

Titre du mémoire :
ALLOCATION DYNAMIQUE DE LA BANDE PASSANTE
DANS UN RESEAU OPTIQUE PASSIF 10-GIGABITAIRE

Nombre de pages : 106

Nombre de tableaux : 16
Nombre de figures : 65

Directeur de mémoire : Monsieur RATSIMBAZAFY Andriamanga

Téléphone : +261 (0) 34 01 377 97

106
 RESUME

Un réseau optique passif 10-Gigabitaire ou XGPON consiste en une terminaison de ligne optique
OLT desservant plusieurs unités de réseau optique ONU. Dans le XGPON, le partage de la largeur
de bande entre les ONU dans le sens montant, des ONU vers l’OLT, suit un accès multiple par
répartition dans le temps. Grâce à l’allocation dynamique de la bande passante ou DBA, les
ressources en bande passante dans le sens montant sont mieux utilisées car les ONU reçoivent la
largeur de bande en fonction de leur besoins. Un algorithme programmé au niveau de l’OLT est
chargé de l’attribution de la largeur de bande en recensant les besoins de chaque ONU. L’algorithme
GIANT est le premier algorithme implémenté physiquement sur le XGPON, il constitue un
algorithme de base pour en élaborer de nouveaux afin de profiter au maximum des performances
fournies par le XGPON.

Mots clés : XGPON, OLT, ONU, DBA, GIANT

ABSTRACT

XGPON consists of an optical line termination OLT and multiple optical network units ONU. The
upstream bandwidth, from ONU to OLT, is shared between ONU following a time division multiple
access. DBA or dynamic bandwidth allocation allows a better use of the resources in the upstream
direction because each ONU receives bandwidth according to its needs. An algorithm implemented
on the OLT identifies the needs of each ONU and performs DBA. The GIANT algorithm is the first
DBA algorithm that is physically implemented. New DBA algorithms can be developed from the
GIANT algorithm in order to enjoy the performance provided by the XGPON.

Keywords : XGPON, OLT, ONU, DBA, GIANT