Are Faire

I.3.2.
A - Les couches de l'interface Uu

Les diffrentes couches peuvent tre assimiles aux 3 premires couches du
modle OSI, respectivement la couche physique, la couche liaison de
donnes et la couche rseau.
I.3.2.A. a - Couche 1
La couche physique de l'interface radio ralise les fonctions de modulation, de
codage canal, d'entrelacement et de contrle de puissance.
I.3.2.A. b - Couche 2
La seconde couche est divise en plusieurs sous-couches assurant chacune
une fonction bien dfinie pour le transport des donnes de l'UE.
La sous-couche MAC (Medium Access Control) qui est en charge du
multiplexage des donnes sur les canaux de transport radio. En effet, il
multiplexe diffrents flux de donnes issus d'un mme utilisateur sur un canal
de transport unique, et dans le cas de donnes issus d'utilisateurs diffrents, il
se charge de les multiplexer sur un canal de transport commun.
La sous-couche RLC (Radio Link Control) permet la fiabilit du transport des
donnes jusqu' destination.
La sous-couche BMC (Broadcast/Multicast Control) est en charge d'assurer
les fonctions de diffusion de messages sur l'interface radio, tels les SMS.
La sous-couche PDCP (Packet Data Convergence Protocol) permet de
compresser les donnes, comme les en-ttes BMC par exemple, via des
algorithmes de compression. Cela permet d'exploiter plus efficacement les
ressources radio. De plus, cette sous-couche PDCP a aussi pour rle de
rendre indpendant les protocoles radio du rseau d'accs UTRAN (souscouches MAC et RLC) par rapport aux couches de transport rseau. Ce type
d'architecture permettra l'volution future des protocoles rseaux sans
modifier les protocoles radio de l'UTRAN.
I.3.2.A. c - Couche 3
Cette couche appele RRC (Radio Resource Control) dispose de fonctions de
contrle de l'ensemble des couches. Elle se charge de grer la connexion de
signalisation lors de
20
Gestion des instabilits Iub et qualit de service sur l'accs 3G de la
SONATEL
Mmoire de fin de cycle - Master 2 Chapitre I - UMTS
Mamadou Lamine NDIAYE
l'tablissement ou de la libration de la communication entre le rseau
d'accs UTRAN et l'quipement usager.
I.3.2.B - Les canaux de l'interface Uu

Diffrents types de canaux ont t dfinis au niveau de l'interface Uu pour se
charger du transport des informations de natures diffrentes sur la voie radio
entre l'UE (User Equipment) et le Node B. Les canaux de l'interface Uu
peuvent tre classifis en trois catgories de canaux savoir, les canaux
physiques, les canaux de transport et les canaux logiques.
I.3.2.B. a- Les canaux logiques

C'est via les canaux logiques que sont transportes les donnes de la couche
MAC destination du coeur de rseau, et inversement. Chaque canal logique
se charge du transport d'informations de type particulier. Ils sont spars en
deux groupes, les canaux logiques de contrle et les canaux logiques de
trafic.
+ Les canaux logiques de contrle
Broadcast Control Channel (BCCH) : Il est utilis dans le sens descendant
pour la diffusion des informations du rseau au niveau de toutes les cellules.
Paging Control Channel (PCCH) : Il est utilis dans le sens descendant pour
acheminer les informations lies au paging. Il est utilis quand le rseau ne
sait pas dans quelle cellule se situe l'UE.
Common Control Channel (CCCH) : C'est un canal bidirectionnel pour le
transport des informations de contrle entre le rseau et UE.
Dedicated Control Channel (DCCH) : Il achemine les informations de
contrle ddies un UE donn de faon bidirectionnelle. ce canal est utilis
durant l'tablissement de connexion avec le RRC.
+ Les canaux logiques de trafic
Dedicated Trafic Channel (DTCH) : C'est un canal bidirectionnel pour la
transmission des donnes entre le rseau et un UE donn.
Common Trafic Channel (CTCH) : Il est utilis dans le sens descendant pour
assurer la transmission des messages pour un groupe d'UE situs dans
plusieurs cellules, et ce au niveau de plusieurs Node B diffrents.
21
I.3.2.B. b - Les canaux de transport

Les donnes en provenance de la couche MAC sont mappes dans des
canaux physiques via les canaux de transport. A chaque canal de transport
est associ un format correspondant aux donnes transporter. Les canaux
de transport peuvent tre classifis en deux groupes, savoir les canaux de
transport ddis et les canaux de transport communs.
+ Les canaux de transport communs
Random Access Channel (RACH) : C'est un canal utilis en sens ascendant
pour transporter les demandes de services des UE.
Common Packet Channel (CPCH) : Il est utilis dans le sens ascendant et
seulement en mode FDD, car la taille des paquets transports est lgrement
grande et il est important de les acheminer un haut dbit pour le transport.
Forward Access Channel (FACH) : Ce canal est utilis en sens descendant
pour les donnes de petites tailles vers les UE.
Downlink Shared Channel (DSCH) : C'est un canal utilis uniquement sur la

voie descendante. Il est partag dynamiquement par diffrents utilisateurs et
transporte des donnes de contrle ou de trafic.
Uplink Shared Channel (USCH) : Il est utilis en sens ascendant par
plusieurs UE pour le transport des donnes. Il est seulement en mode TDD
Broadcast Channel (BCH : Il est utilis dans le sens descendant pour la
diffusion d'informations du rseau pour toutes les cellules.
Paging Channel (PCH) : Ce canal est utilis en sens descendant pour les
informations relatives au paging sur toutes les cellules
+ Le canal de transport ddi
Dedicated Channel (DCH) est le seul type de canal ddies. Ce type de canal
existe dans les deux sens de la liaison et transporte des donnes.
I.3.2.B. c - Les canaux physiques

Les canaux physiques sont utiliss pour transporter de faon transparente les
donnes mappes au niveau des canaux de transport en direction des UE.
Ces canaux physiques
22
SONATEL
peuvent tre spars en deux groupes, savoir les canaux physiques ddis
et les canaux physiques communs.
+ Les canaux physiques ddis
DPDCH (Dedicated Physical Data Channel) : Il est utilis dans le sens
ascendant pour le transport des donnes d'un UE donn.
DPCCH (Dedicated Physical Control Channel) : C'est un canal utilis dans le

sens ascendant pour les informations de contrle.
DPCH (Dedicated Physical Channel) : Ce canal est utilis dans la voie
descendante pour acheminer les informations provenant du rseau.
+ Les canaux physiques communs
PDSCH (Physical Downlink Shared Channel) : Il est utilis dans la voie
descendante pour le transport des trafics de donnes haut dbit vers un ou
plusieurs quipements usagers situs dans une mme cellule
CPICH (Common Pilot Channel) : Ce canal il est utilis en voie descendante
utilis par les UE pour estimer la qualit du rseau.
SCH (Synchronization Channel) : Il permet aux UE de se synchroniser avec
le rseau.
I.3.3 - L'interface Iu (Iub, Iur, IuPS et IuCS)
Les interfaces Iub, Iur, IuPS et IuCS se basent sur un seul et unique modle
gnrique de structure en couches. Ceci dans le but d'assurer d'une part
l'indpendance des donnes transportes par rapport la technologie utilise
pour le transport et d'autre part la sparation complte entre les plans usager
et contrle.
L'architecture protocolaire est divise horizontalement en deux couches
principales. La partie suprieure est appele la couche rseau radio et la
partie infrieure la couche rseau transport. La couche rseau radio constitue
la source des donnes qui doivent tre transfres travers les interfaces, et
ces donnes peuvent tre de la signalisation ou du trafic. La couche rseau
transport fournit quant elle les mcanismes de transport ncessaires pour
l'acheminement des donnes.
L'architecture protocolaire est galement divise verticalement en trois plans :
le plan de contrle (Control Plane) qui gre les informations de contrle
concernant les protocoles d'interface radio ; le plan utilisateur (User Plane) qui
gre les donnes provenant de l'UE et
23

SONATEL
Chapitre I - UMTS
Mmoire de fin de cycle - Master 2
un plan de contrle du rseau de transport (Transport Network User
Plane). Le plan de contrle contient les protocoles d'application qui sont
spcifiques suivant les interfaces Tub, Tur et Tu (TuC S et TuPS). Le plan
usager comprend les flux de donnes (Data Stream) et la porteuse de
donnes (Data Bearer). Le plan de contrle du rseau de transport
(Transport Network Control Plane) comprend l'ALCAP (Access Link
Control Application Protocol) qui estncessaire pour tablir, maintenir et
librer les connexions point point sur les interfaces Tub, Tur et Tu.
Pour une meilleure perception, le schma qui suit illustre le modle de la
structure en couche des interfaces Tub, Tur et Tu de l'UTRAN.
Figure 9: Structure en couches des interfaces rseaux de l'UTRAN
Dans les paragraphes qui vont suivre nous verrons les diffrents
protocoles intervenant au niveau du modle gnrique de la structure en
couche de l'ensemble des interfaces rseaux. Cependant vu que
l'essence mme de cette tude porte sur l'interface Tub de faon
gnrale, de ce fait le protocole ALCAP ne sera pas trait dans ce
chapitre car sa prsence dans la structure en couches des interfaces Tu
dpend fortement du protocole de transport utilis dans la couche
rseau transport, et cela sera trait de faon explicite dans le prochain
chapitre.
24
SONATEL
I.3.3. a - Data Bearer
Les porteuses de donnes sont reprsentes par une ou plusieurs
connexions utilises pour transporter les donnes de l'utilisateur d'un noeud
un autre. Les donnes de l'utilisateur peuvent tre relayes de l'UE au
coeur de rseau sous forme de voix, vido, datagrammes IP, entre autres. De
la mme manire, les donnes utilisateurs peuvent aussi tre relayes du
coeur de rseau vers l'UE.
I.3.3.b - Signaling Bearer

Ce sont des porteurs de signalisation qui peuvent prendre la forme d'une
connexion ou de plusieurs connexions destines transporter les
informations de signalisation entre les noeuds. Ils peuvent aussi bien tre
utiliss pour le transport des informations signalisation des UE mais aussi
pour le transport des informations de signalisation propres aux noeuds.
I.3.3.c - Application Protocol

Les protocoles d'application transportent des services spcifiques tels la
gestion des ressources ou la reconfiguration d'un noeud du rseau. Par
exemple tous les services du RNC lis l'opration et la maintenance des
Node B sont transports par ces protocoles d'application.
I.3.3.d - Data Stream

Ils sont en charge d'offrir des services spcifiques au plan utilisateur en
fonction des exigences QoS des applications telles le dbit, le dlai pour la
voix, la vido et les datagrammes IP.
Nous avons fait voir dans ce chapitre le rseau UMTS de faon gnrale et la
faon dont se prsente son architecture globale. Dans le mme contexte,
nous nous sommes penchs sur les diffrentes interfaces reliant les
diffrentes entits du rseau, plus prcisment dans la partie accs de
l'UMTS. Dans le prochain chapitre, nous ferons focus sur l'interface Iub en
vue de voir sa structure protocolaire et surtout comment ses protocoles
interagissent entre elles pour russir faire passer les flux d'information de
faon transparente.
25
SONATEL
Chapitre II : Gnralits sur l'interface Iub

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface
Iub
L'interface Iub se dfinit comme tant la liaison entre le Node B et le RNC.
Dans ce chapitre nous tudierons l'interface Iub dans son contexte gnrique,
notamment l'tude dtaille de sa structure en couches. Nous ferons focus
sur les diffrents protocoles qui interviennent et la faon dont ils interagissent
entre eux pour assurer le transport sur l'interface Iub, et ce suivant les
diffrentes options de transport choisies au niveau de l'UTRAN. Enfin nous
nous pencherons sur la faon dont se fait la coexistence entre ces diffrents
protocoles de transport de l'interface Iub pour une migration souple vers le
Tout-IP .
II.1 - Gnralits sur les protocoles de transport de l'UTRAN
ATM fut le protocole de transport utilis sur l'interface Iub au niveau de
l'UTRAN, mais depuis la Release 5 de l'UMTS, l'option IP a t introduite
comme option de protocole de transport. Ainsi, au niveau du rseau d'accs
3G, il est possible d'avoir des Iub fonctionnant sous ATM, d'autres qui sont
bass sur IP et certaines bases aussi bien sur ATM que sur IP. Cependant
avant d'aller plus loin, il est essentiel de faire une brve description du
fonctionnement de ces diffrents protocoles de transport.
II.1.1 - Gnralits sur l'ATM
L'Asynchronous Transfer Mode communment appel ATM est un mode de
transfert, caractris par la transmission de donnes commutation de
cellules avec un mode de multiplexage par rpartition dans le temps
asynchrone. L'unit de transmission de donnes sur ATM est base sur des
cellules de taille fixe. ATM est un protocole dit asynchrone car les cellules
ATM sont envoyes de manire asynchrone, en fonction des donnes
transmettre, mais sont insres dans le flux de donnes synchrones d'un
protocole de niveau infrieur pour leur transport.
Dans le rseau UMTS, ATM est utilis dans la couche rseau de transport du
rseau. Ce choix repose sur deux proprits essentielles de l'ATM,
notamment avec la possibilit de transmettre des trafics dbit variable aussi
bien pour les services du domaine PS que pour les services du domaine CS.
Ce qui est particulirement utile pour l'UMTS tant donn la grande varit
des services offerts. L'utilisation de cellules ATM permet aussi la possibilit de
conserver la qualit de service requise pour les donnes transportes, et ce
suivant chaque classe de service.
27
SONATEL
Iub
II.1.1.a - La Commutation de cellules

Comme il a t voqu prcdemment, l'ATM utilise des cellules pour le
transport des donnes sur le rseau du fait que les donnes sont segmentes
en de petits paquets de taille fixe appels cellules. Elles sont appeles ainsi
en raison de leur structure trs particulire, leur taille tant fix 53 octets
quelle que soit la longueur de l'information transmettre.
Le mode de transfert utilis par ATM est orient connexion, ce qui signifie
qu'elle ncessite un tablissement pralable de connexion virtuelle avant tout
transfert de donnes. De ce fait, un circuit virtuel est tabli soit par
configuration des quipements, soit par signalisation, et l'ensemble des
cellules seront commutes sur ce mme circuit virtuel par commutation. Les
chemins sont appels circuit virtuel du fait que les cellules transitent via un
VC (Virtual Channel) qui est lui-mme contenu dans un VP (Virtual Path),
sachant que durant la commutation, les cellules peuvent emprunter plusieurs
VP et VC diffrents suivant les champs VPI (Vitual Path Identifier) /VCI (Virtual
Channel Identifier) contenu dans les labels. En effet, contrairement aux
paquets IP qui contiennent des champs source et destination , ATM
utilise les champs VPI et VCI contenus au sein des cellules pour identifier les
connexions. Les labels permettant la commutation des cellules sont ports
dans l'en-tte de chaque cellule. Ci-dessous dcrit la structure gnrale d'une

cellule ATM.
Figure 10: Structure gnrale d'une cellule ATM.

Les cellules ATM ont une taille de 53 octets. L'en-tte est sur 5 octets et la
charge utile sur 48 octets. Cependant, le protocole ATM dfinit deux types de
cellules respectivement adapts sur une interface Utilisateur-Rseaux (UNI,
User-Network Interface) et sur une interface entre noeuds du rseau (NNI,
Network-Network Interface). Les champs VPI/VCI qui permettent d'identifier
les connexions virtuelles lors de la commutation sont contenus au niveau des
enttes des cellules ATM.
28
SONATEL
Iub
II.1.1.b - Le modle de rfrence

d'ATM
Le modle de rfrence sur lequel se base ATM est compos de quatre
couches :
La couche physique : Elle correspond la couche physique du modle de
rfrence d'OSI. Elle gre la transmission et la rception des bits composant
les cellules ATM sur le support physique choisi.
La couche ATM : Cette couche se charge d'acheminer les donnes tout en
assurant le multiplexage et le dmultiplexage des cellules via des circuits
virtuels, l'ajout ou le retrait de l'en-tte des cellules et la translation des

identifiants des circuits virtuels (VPI/VCI).
La couche AAL (ATM Adaptation Layer) : Elle est charge de segmenter et
de rassembler les donnes provenant des applications suivant la qualit de
service requise par les applications. Vu qu'ATM transporte diffrents types
d'informations et que les contraintes varient en fonction de la nature de
l'information elle-mme (vido, image,...), diverses couches AAL ont t alors
dfinies.
> AAL1 : Adapt aux applications vido dbit constant et le transport de la
voix.
> AAL2 : Adapt aux applications vido et audio dbit variable.
> AAL3/4 : Adapt au transfert scuris de donnes.
> AAL5 : Adapt au transport de donnes.
Les couches suprieures : Elles comprennent des couches de protocole
facultatives qui servent effectuer une encapsulation du service ATM en vue
de son utilisation avec TCP/IP et d'autres protocoles.
Les couches du modle de rfrence d'ATM sont regroupes sur trois plans :
Le plan utilisateur : Il permet le transfert des informations dans le rseau,
mais prend galement en charge les erreurs de transfert et la surveillance du
flux mis.
Le plan de contrle : ATM tant en mode connect, ce plan permet
l'tablissement, la libration et la surveillance des connexions.
Le plan de gestion : Ce plan assure des oprations de contrle et de
maintenance.
Dans le rseau UMTS, seules les couches adaptatives AAL2 et AAL5 sont
utilises dans les interfaces UTRAN pour assurer respectivement le transport
de la voix et des paquets IP. Pour une meilleure perception, la figure 11 dcrit
la structure du modle de rfrence d'ATM tel qu'il a t dcrit prcdemment.
29

SONATEL
Iub
Figure 11: Structure du modle de rfrence d'ATM

L'avantage d'ATM rside sur le fait qu'elle fournisse une qualit de service
adapte aux diffrents types de trafic, notamment la voix, la vido et les
donnes. Le trafic temps rel tolre certaines pertes mais pas de retard
comme la voix et la vido, tandis que le trafic sans contrainte de temps rel tel
que les donnes, tolre une distorsion temporelle mais pas de perte.
II.1.2 - Gnralits sur l'Internet Protocol
Internet Protocol communment appel IP est un protocole de couche rseau
qui contient des informations d'adressage et de contrle permettant aux
paquets d'tre routs dans un rseau. Avec le protocole IP, toutes les
donnes transportes sont segmentes en paquets de longueurs variables
routs travers le rseau. Les paquets IP, encore appels datagrammes ,
sont transmis en mode sans connexion de la source vers la destination, dans
le cadre d'un service de type best-effort . Au niveau de l'UMTS, l'IP est
utilis au niveau de la couche rseau de transport de la structure protocolaire
des interfaces Iub, IuCS, IuPS ainsi que l'interface Iur et il est bas sur la
norme IEEE G.802.3 communment appele Ethernet.
II.1.2.a - L'adressage IP
Comme pour tout protocole de couche rseau, le mcanisme d'adressage IP
est valable pour tout le mcanisme de routage des datagrammes travers le
rseau. L'adresse IP est un numro d'identification qui est attribu de faon
permanente ou provisoire chaque entit connect au rseau et utilisant le
protocole IP. Cependant il existe des adresses IP de version 4 (sur 32 bits,
30
SONATEL
Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface Iub

soit 4 octets) et de version 6 (sur 128 bits, soit 16 octets). La version 4
est actuellement la plus utilise. Elle est gnralement reprsente en
notation dcimale avec quatre nombres compris entre 0 et 255, spars
par des points (par exemple : 172.16.254.1). Ainsi chaque adresse IP
obit un format de base et est spare par deux parties, savoir un
numro de rseau appel Net ID et un numro du host appel Host ID
qui peuvent tre tous deux cods sur 1, 2 ou 3
octets suivant la classe d'adresse IP. La figure ci adresse
IP version 4.
Figure 12: Format de base d'une adresse IPv4
- dessous illustre le format de

base d'une
La version 6 de l'adresse IP est exige au niveau de l'UTRAN, la version

4 n'est utilise que pour permettre une transition graduelle vers la
version 6.
II.1.2.b - Le routage IP
Internet et les rseaux IP sont composs d'un ensemble de rseaux qui
sont relis par des entits particuliers que l'on appelle routeurs. Le
protocole IP est capable de choisir un chemin suivant lequel les paquets
de donnes seront relays de proche en proche jusqu'au destinataire. Le
routage IP se base donc sur l'adressage IP en vue de dterminer la
destination auquel le datagramme IP doit aboutir. Du fait que chaque
interface rseau d'une machine possde une adresse unique au sein du
rseau. Pour transmettre le paquet jusqu' bon port, le routage se base
aussi sur l'en-tte du paquet IP qui comportent entre autres les adresses
de l'metteur et du destinataire, ce qui rend facile l'aiguillage du paquet
IP jusqu' destination. Cependant, pour chaque paquet reu, le routeur
consulte sa table de routage qui contient entre autres la liste des
adresses de rseaux de destination, des passerelles (routeurs
intermdiaires) permettant de les atteindre, des interfaces de sorties et
des cots associs.
Pour renseigner les tables de routage, nous avons le routage statique par
lequel la table est configure de faon manuelle au niveau de chaque
routeur par l'administrateur lui-mme. Contrairement au routage
statique, nous avons aussi le routage dynamique qui tire son pingle du
jeu en faisant appel aux protocoles de routage. Ils sont mis en oeuvre
entre routeurs pour renseigner de manire dynamique les tables de
routage. Il est clair que les protocoles de routage dynamiques sont bien
plus performants, plus souples et plus efficaces, cependant ils
consomment nanmoins des ressources au sein du routeur et devront
donc tre utiliss de
31
SONATEL

Iub
manire adquate. Pour une meilleure perception, la figure ci-dessous illustre
le principe de routage d'un rseau IP.
.
Figure 13: Principe du routage IP

La figure 13 fait ressortir un exemple de routage dans lequel un rseau LAN
est connect au rseau Internet via des routeurs du backbone IP. L'aiguillage
des donnes est facilite par les adresses source et destination contenues au
sein du paquet IP. Ainsi un paquet du rseau Internet destination du PC 1
sera rout jusqu' destination en passant par les routeurs concerns. De ce
fait, aprs rception du paquet, chaque routeur consultera sa table de routage
pour acheminer le paquet, et ce jusqu'au rseau de destination.
Le protocole IP, reconnu par sa simplicit et sa souplesse, est devenu trs
populaire et s'est surtout mis au devant de la scne notamment avec la
convergence IP qui est de plus en plus d'actualit. Il est clair que le protocole
IP deviendra terme le protocole de transport de la plupart des rseaux de
tlcommunications.
II.2 - L'interface Iub
La liaison via laquelle le Node B communique avec le RNC qui le contrle est
dsigne comme tant l'interface Iub. Contrairement l'interface Abis du
rseau GSM qui n'est pas normalise, l'interface Iub elle est standardise.
Elle est aussi dite ouverte dans le sens o sa normalisation permet
l'interconnexion de RNC et de Node B de constructeurs diffrents. L'interface
Iub est non seulement utilise pour supporter les services offerts aux abonns
UMTS mais fournit aussi le moyen de transport de donnes entre l'UE et le
RNC via les ressources du Node B. Cependant il est tout aussi ncessaire de
rappeler que les piles de protocoles utilises au niveau de l'interface Iub se
basent sur le modle gnrique de la
32
SONATEL

Iub
structure en couches dfini pour les interfaces rseaux de l'UTRAN, trait

prcdemment dans le chapitre I (Figure 9). Comme il a t dfini dans la
norme 3GPP TS 25.401, le schma qui suit illustre la pile protocolaire de
l'interface Iub.
Figure 14: Structure en couches de l'interface Iub suivant ATM et IP
La figure 14 fait ressortir les diffrents protocoles intervenant pour chaque
option de transport choisi entre ATM et IP. En effet il est possible d'avoir sur la
couche rseau transport l'ATM pour assurer le transport sur l'interface Iub,
mais aussi l'IP. Le 3GPP a choisi le protocole AAL2 dans sa Release 99
comme le protocole de transport sur l'interface Iub. Cependant, depuis la
Release 5 du 3GPP, l'IP est introduit comme option du protocole de transport
dans une optique de raliser des rseaux Tout-IP .
Comme l'illustre la figure 14, la structure protocolaire de la couche rseau de
transport (Transport Network Layer) varie en fonction de la technologie
utilise pour le transport. De ce fait, si ATM est utilis pour le transport, cette
partie de la pile protocolaire sera tout fait diffrente si IP est utilis la
place.
33
SONATEL

Iub
II.2.1 - La couche rseau de transport
Comme l'illustre la figure 14, diffrents protocoles sont utiliss aussi bien pour
la signalisation que pour le transport des donnes et ce, suivant l'option de
transport choisie sur l'interface Iub. Dans la suite de cette tude nous ferons
focus sur les protocoles intervenant au niveau de la couche rseau de
transport, et ce suivant l'option de transport choisie.
II.2.1.A - Transport sur ATM
La structure de la couche rseau de transport base sur ATM fait appel

certains types de protocoles particuliers qui assurent une tche bien dfinie
pour l'acheminement des donnes sur l'UTRAN. Dans les paragraphes qui
vont suivre nous verrons ces diffrents protocoles intervenant sur la couche
rseau transport. Pour une meilleure perception, la figure qui suit illustre la
structure protocolaire de l'interface Iub base sur ATM.
Figure 15: Structure en couche de l'interface Iub base sur ATM
II.2.1.A. a- La couche Physique
Elle reprsente la couche la plus basse d'ATM. Elle est en fait spare en
deux sous couches. D'un ct nous avons la sous-couche TC (Transmission
Convergence), qui permet d'adapter
34
SONATEL
Iub
ATM sur le support de transport choisi. D'un autre ct, la sous-couche
physique (coiffe par la sous-couche TC) qui reprsente le support mme sur
lequel ATM est adapt.
La technologie ATM peut tre implmente sur plusieurs types de supports
physiques, qu'ils soient de type lectrique ou optique, parmi lesquels le SDH
(Synchronous Digital Hierarchy), SONET1 ou E1 qui reprsente une liaison
permettant le transfert de donnes un dbit de 2Mbits/s.
II.2.1.A .b - La couche ATM

Elle a pour rle principal d'assurer l'acheminement des donnes, ce qui
implique qu'elle se doit donc de s'occuper de la commutation et du
multiplexage des cellules ATM en fonction des VPI/VCI correspondants. Elle

se charge aussi du retrait ou de l'ajout d'en-tte sur les cellules ATM.
II.2.1.A .c - AAL2
Dans sa Release 99, le 3GPP a choisi l'AAL 2 (ATM Adaptation Layer - Type
2) comme protocole de transport sur les interfaces Iub et Iur de l'UTRAN.
L'AAL2 a t normalis par l'UIT (Union Internationale des
Tlcommunications) en 1997 dans une nouvelle version adapte au
transport des applications bas dbits.
En effet, comme il a t dfini dans la spcification de l'IUT I.363.2, AAL2
fournit une transmission bas dbit (jusqu' 64 kbit/sec) efficace pour des
paquets courts de longueur variable, et ce pour des applications en temps
rel. Au vu de ses caractristiques, l'AAL2 est particulirement adapt pour le
transport de la voix et de la vido. Le principe d'AAL2 consiste transporter
des mini-paquets appels paquets CPS qui sont quips d'enttes qui
contiennent des Channel Identifier. Ceci est du au fait que les paquets CPS
proviennent de sources diffrentes et sont destins tre multiplexs dans
une seule et mme cellule ATM. Les CID sont ainsi utiliss pour identifier les
diffrentes sources, il peut y en avoir jusqu' 248 pour une seule connexion
virtuelle. Cette technique diminue considrablement le temps de
paqutisation, qui est essentiel pour les applications vido et audio.
AAL2 est la seule parmi toutes les autres couches adaptative d'ATM
disposer de son propre protocole de signalisation qui est en charge de
l'tablissement et de libration, de faon dynamique, les connexions AAL2.
1 SONET pour Synchronous Optical Network se base comme le SDH sur
un rseau en fibre optique, la diffrence que SONET est un standard
amricain tandis que SDH est europen.
35
SONATEL
Iub
II.2.1.A. d - AAL5
La couche d'adaptation AAL5, galement connue sous le nom de SEAL
(Simple and Efficient Adaptation Layer) est de loin la plus utilise des couches
d'adaptation d'ATM. Elle coiffe la couche ATM et contrairement l'AAL2, son
utilisation est limite pour les donnes d'application, qui n'ont pas d'exigences
stricte sur le dlai de transmission.
La couche d'adaptation AAL5 est particulirement adapte pour le transport
des paquets IP ainsi que les messages de signalisation entre les noeuds. La
couche AAL5 est aussi en charge d'assurer une fonction de fragmentation et
de rassemblage, respectivement de paquets de donnes en cellules ATM et
inversement. Comme il a t dfini dans la spcification IUT I.363.5, la
couche d'adaptation AAL5 englobe deux sous-couches qui forment sa partie
commune: le SAR (Segmentation And Reassembly) et le CPCS (Common
Part Convergence Sublayer) qui se chargeront de la fonction de segmentation
et de rassemblage. La figure 16 illustre le principe de segmentation des
PDU2 en cellules ATM.
Figure 16: Principe de segmentation en cellules ATM
2 PDU : Protocol Data Unit reprsente une unit de donnes spcifique

au protocole. Contrairement au SDU (Service Data Unit) qui reprsente
une unit de donnes spcifique au service et dont l'intgrit est
prserve d'une extrmit l'autre.
36
SONATEL
Iub
Comme l'illustre la figure 16, la couche suprieure (SSCOP) transporte de
manire fiable jusqu' la couche CPCS un SDU dont la longueur n'excde
pas 65535 octets. Le CPCS aprs avoir rcupr le paquet de donnes, se
charge alors d'ajouter des bits de contrle et de correction d'erreur, ainsi que
des bits de bourrage3avant de remettre un PDU la couche SAR
(Segmentation and Reassembly). Ainsi la couche SAR son tour rcupre le
PDU (Protocol Data Unit) du CPCS, puis se charge de le segmenter en blocs
de 48 octets appels SAR PDU. Ces SAR PDU seront par la suite dlivrs
la couche ATM, l o l'en-tte ATM de 5 octets sera ajout chaque SAR
PDU. C'est ainsi que se forment les cellules ATM sortant et l'opration inverse
est effectue pour les cellules ATM entrant.
II.2.1.A. e - SSCOP
Le SSCOP (Service Specific Connection Oriented Protocol) comme le stipule
la spcification de l'IUT Q.2110, se charge de fournir un transfert assur des
messages de signalisation. ATM a plusieurs couches d'adaptation nommes
AAL, parmi les plus importantes nous avons AAL5 et AAL2. Cependant, nous
avons une autre couche qui s'occupe du transport des informations de
signalisation, elle est appele Signaling ATM Adaptation Layer (SAAL). La
particularit qui le distingue du reste des couches adaptatives est du au fait
qu'il fournisse une livraison fiable, ce qui n'est pas un des caractristiques du
AAL5. Vu qu'AAL5 ne dispose pas de cette particularit, il est donc essentiel
de disposer d'une couche de service spcifique, englobe par le SAAL, et qui
fournit une livraison garantie. A cet effet, SCCOP a t introduit juste au

dessus de la couche AAL5, pour remplir cette fonction. SSCOP est utilis pour
le transfert des SDU longueur variable, en fait il reoit les informations
transmettre depuis la couche de la signalisation et forme ensuite les SSCOP
SDU (Service Data Unit) et se charge de les retransmettre au CPCS.
Le SSCOP est utilis pour fournir les mcanismes d'tablissement, de
libration et de resynchronisation des connexions pour des changes fiables
d'informations et de signalisations. De ce fait les SDU sont changs de faon
entre le CPCS et le SSCOP.
Il assure entre autres l'intgrit de la squence en conservant l'ordre des SDU
reus, la correction des erreurs par une retransmission slective des SDU
manquants, le contrle des flux par le receveur en choisissant le dbit au
niveau de l'metteur.
3
Au niveau du CPCS, les bits de bourrage ou Padding servent faciliter

la segmentation au niveau du SAR. Le champ des donnes (payload) du
PDU une longueur variable entre 1 et 65535 octets, mais sa taille totale
doit tre toujours un multiple de 48 pour que la sous couche SAR puisse
la segmenter en des blocs de 48 octets.
37
SONATEL
Iub
II.2.1.A. f - SSCF-UNI
SSCF dont le sigle signifie Service Specific Coordination Function, n'est pas
un protocole mais une fonction de coordination interne ou un protocole lger
si on peut l'appeler ainsi. SSCF, comme il a t dfini dans la spcification
de l'IUT Q.2130, se charge de coordonner l'accs entre la couche SSCOP et
les couches suprieures. Son rle principal est d'adapter le service fourni par
le SSCOP aux besoins de la couche de signalisation ALCAP, mais aussi pour

le protocole d'application de la couche rseau radio (NBAP).
Cependant il est noter qu'il existe deux types de SSCF : le SSCF-UNI utilis
sur l'interface Iub reliant la Node B et le RNC, et le SSCF-NNI utilis sur les
autres interfaces, tel qu'il a t dfini sur la spcification de l'IUT Q.2140.
II.2.1.A. g - STC
Vu qu'AAL2 est utilis au niveau de l'UTRAN, il est alors ncessaire qu'il y ait
une signalisation qui doit se faire pour l'tablissement, la maintenance et la
rupture des connexions AAL2 (les connexions AAL2 sont tablies au niveau
des connexions virtuelles d'ATM existantes), et cela se fait grce l'utilisation
de la signalisation AAL2. Hors, la signalisation AAL2 n'est qu'autre que le
protocole ALCAP.
Sachant que le protocole ALCAP se situe au dessus du SSCF-UNI pour
l'interface Iub, deux options se sont prsentes pour le transport de la
signalisation AAL2 : une option qui consiste adapter les signalisations AAL2
pour chaque type de transport de signalisation possible, alors que l'autre
option consiste maintenir les signalisations AAL2 fixe, mais une fonction de
convertisseur sera ncessaire pour adapter les signalisations d'AAL2 pour
chaque type de transport de signalisation. C'est cette seconde option qui a
conduit la notion du STC qui remplit cette fonction de conversion.
L'IUT a spcifi des normes pour le STC (Signaling Transport Converter), et
parmi ces normes nous trouvons le Q.2150.2 qui stipule que le STC rside au
dessus de SSCF-UNI et sera utilis pour l'interface Iub. Mis part sa fonction
de conversion, le STC se charge aussi de signaler aux entits de signalisation
AAL2 les congestions existantes au niveau du rseau de transport sousjacent, de leurs prciser aussi la longueur maximale des PDU qui peut tre
transmise sur le transport de signalisation utilis, de leur faire savoir si le
rseau de transport sous-jacent est disponible ou pas.
38
SONATEL

Iub
II.2.1.A .h - ALCAP
ALCAP pour Acces Link Control Application Part est le nom gnrique du
protocole de signalisation d'AAL2 qui fournit les moyens d'tablir, de maintenir
et de librer les connexions AAL2 au niveau de l'UTRAN.
Comme il a t dfini dans la spcification de l'IUT Q.2630.2, ALCAP rside
au dessus du STC (Q.2150.2) et se charge principalement de l'tablissement
dynamique des supports de donnes pour le plan usager. En effet, lorsqu'un
message de signalisation est initi par le protocole d'application NBAP,
ALCAP dclenche ainsi les signalisations ncessaires pour l'tablissement
des connexions AAL2 pour transporter les donnes des protocoles de niveau
suprieur du plan usager. Cependant il arrive que le protocole ALCAP ne soit
pas utilis dans le cas o l'tablissement des connexions AAL2 a dj t fait
manuellement par configuration
II.2.1.A .i - SAAL-UNI
Le SSCF, le SSCOP et l'AAL5 (I.363.5) eux trois forment non seulement la
couche de transport de la signalisation pour ALCAP, mais aussi pour le
protocole d'application de la couche de rseau radio, et l'ensemble de cette
pile de protocoles est communment appel le SAAL-UNI pour l'interface Iub.
Pour une meilleure perception la figure qui suit illustre la structure en couches
du SAAL-UNI.
Figure 17: Structure en couches du SAAL-UNI.

39
SONATEL
Iub
Le Signaling ATM Adaptation Layer est fonctionnellement divis en deux
parties, une couche de convergence (CS) et une couche de segmentation et
de rassemblage (SAR). Cependant la couche de convergence est compose
de la sous-couche de convergence de partie commune (CPCS) et de la souscouche de convergence de service spcifique (SSCS) qui est elle-mme
forme du SSCOP et du SSCF-UNI. Tandis que le SAR et le CPCS forment
tous deux la partie commune (CP) d'AAL5 comme il a t dfini dans la
spcification de l'IUT I.363.5. Le schma suivant illustre la structure en
couches du SAAL-UNI.
II.2.1.B - Transport sur IP

Comme il a t voqu prcdemment, la structure de la couche rseau
transport varie globalement si IP est choisi comme option de transport la
place d'ATM. Dans les paragraphes qui vont suivre nous verrons les diffrents
protocoles intervenant sur la couche rseau transport suivant IP. Pour une
meilleure perception, la figure qui suit illustre l'interface Iub base sur IP.
Figure 18: Structure en couches de l'interface Iub base sur IP

40
SONATEL
Iub
Le Transport Network Control Plane qui fait intervenir le protocole ALCAP
n'est pas requis dans la structure protocolaire de l'interface Iub base sur IP,
dans la mesure o les deux noeuds utilisent tous deux l'IP pour le transport
des donnes.
II.2.1.B .a - La couche Physique

Elle reprsente la couche la plus basse de la structure protocolaire de la
couche rseau transport. La couche physique est en charge d'assurer
l'mission et de la rception d'un bit ou de train de bits. Elle se charge aussi
de faire une conversion entre bits et signaux qui peuvent tre lectrique ou
optique en fonction du support choisi. Au niveau du rseau d'accs de
l'UMTS, les supports physiques utiliss pour le transport des paquets IP sont
bass sur la norme IEEE 802.3.
Cette norme largement utilise au niveau des rseaux bass IP est aussi
connue sous le nom d'Ethernet.
II.2.1.B .b - L2
Au niveau de la couche L2, appele communment la couche liaison de
donnes. Les protocoles utiliss pour transmettre les paquets IP sont, en
gnral, laisss non spcifis pour ne pas limiter l'utilisation des autres
protocoles ce niveau et ainsi laisser l'oprateur une large panoplie de
choix afin d'assurer sa qualit de service. Cependant, 3GPP recommande
que les entits utilisant l'option IP pour le transport doivent au moins supporter
des caractristiques spcifiques la couche liaison de donnes, notamment :
IPHC4 qui se charge de compresser les en-ttes UDP/IP en vue de rduire la
longueur des paquets ; le protocole PPP-mux qui a pour rle de multiplexer
les paquets sur une seule et mme trame PPP-mux ; ML/MC-PPP dont la
fonction principale est la sparation des trames en dfinissant des classes de
services. Durant les travaux du RAN5, il a t prouv que l'approche du
protocole PPP-mux fournit de bonnes performances.
Cependant, vu que les protocoles de la couche liaison de donnes ne sont
pas standardiss, il revient donc l'oprateur de choisir les protocoles L2
utiliss dans son rseau de transport IP pour trouver au mieux un bon
compromis sur ses investissements et sa qualit de service fournie.
4
IPHC: Internet Protocol Header Compressor - Rapport technique du 3GPP, TR 25.933 version 5.4.0 Release
5.
RAN3: Diminutif du TSG RAN WG3 pour Technical Specification Group Radio Access Network Work Group
3. Ils sont responsable des spcifications des interfaces Iub, Iur et Iu.
41
SONATEL
Iub
II.2.1.B .c - IP
Le protocole IP communment appel Internet Protocol reprsente le
protocole sur lequel est bas le transport dans la partie accs du rseau
UMTS. Comme il a t vu prcdemment, il existe deux versions du protocole
IP, et dans la Release 5 du 3GPP, il est stipul que tous les Node B de
l'UTRAN doivent supporter la version 6 du protocole IP du fait que la version 4
n'est qu'une alternative pour coexister avec la version 6.
II.2.1.B .d - UDP
L'utilisation d'UDP laisse entendre que le protocole IP est utilis au-dessous
comme pour le protocole TCP dans les rseaux IP. UDP (User Datagram
Protocol) est un protocole non orient connexion utilis pour les applications
temps rel. Dans les spcifications du 3GPP, l'utilisation de la pile UDP/IP au
niveau 3 de l'architecture OSI est obligatoire dans tous les Node B de
l'UTRAN. UDP offre le mme service best effort comme le fait l'IP. Avec UDP il
n'y a pas d'tablissement de liaison pour l'envoi et la rception des donnes,
raison pour laquelle elle est dite protocole non orient connexion. UDP est
utilis la place de TCP du fait qu'il offre une transmission beaucoup plus
rapide que TCP qui ncessite des tablissements de connexions pralables
avant l'envoi ou la rception des paquets, et cela ne rpond pas aux
exigences des applications concernant le dlai de transmission. Puisque les
tablissements de connexion ne sont pas effectus, le temps de transmission
demeure ainsi plus court. Le seul dsavantage avec UDP c'est que les
paquets arrivant destination ne sont pas garantis.
II.2.1.B .e - SCTP
SCTP pour Stream Control Transmission Protocol est un protocole qui a t
dvelopp par l'IETF6 dans le but d'assurer le transport de signalisation dans
un rseauIP. Au niveau de l'interface Iub, SCTP est utilis pour le transport de
la signalisation entre le protocole d'application NBAP de la couche rseau
radio et le reste des protocoles de la couche rseau de transport. SCTP est
un protocole de transport fiable orient connexion et implmente la
congestion et le contrle de flux, la dtection de la corruption de donnes, la
perte ou la duplication des donnes et prend en charge un mcanisme de
retransmission slective.
6 IETF: Internet Engineering Task Force est un comit de rflexion
concernant les normes utiliser pour les technologies et protocoles.
42
SONATEL
Iub
II.2.2 - La couche rseau radio

Pour assurer l'interdpendance, la couche rseau radio est spare de la
couche rseau transport. De ce fait les protocoles intervenant sur la couche
rseau radio demeurent les mmes, et ce quelque soit l'option choisie pour le
protocole de transport au niveau de la couche rseau de transport. La couche
rseau radio de l'interface Iub fait ressortir deux protocoles, savoir le
protocole d'application (NBAP) et le Frame Protocol.
II.2.2.a - NBAP
Le protocole NBAP ou Node B Application Part reprsente ici le protocole
d'application qui peut tre vu comme le protocole de signalisation de la
couche rseau radio. La principale fonction du protocole NBAP, comme il a
t spcifi dans le 3GPP TS 25.433, c'est de fournir aux RNC les moyens de
contrler et de manager les ressources de la Node B. Si l'interface Iub est
base sous ATM, les messages NBAP sont transports par le SAAL-UNI,
sinon ils sont transmis par le SCTP si l'interface Iub est base sur IP. Le
protocole NBAP dfinit des procdures de signalisation qui sont
essentiellement divises en deux parties : les procdures communes et les
procdures ddies.
Les procdures communes de NBAP ne sont pas spcifiques aux UE, elles
sont plutt orientes pour la gestion de l'ensemble des fonctionnalits des
Node B. Notamment, les configurations des cellules, les configurations des
ressources communes des Node B entre autres. Cependant, bien que cela
soit spcifique un UE donn, la mise en place d'un Radio Access Bearer qui
sert de transport entre l'UE et le rseau, est traite dans le cadre des
procdures communes.
Dans un tout autre registre nous distinguons aussi les procdures ddies de
NBAP, qui prennent en compte les procdures spcifiques aux UE (mis part
l'tablissement du Radio Access Bearer). Ces procdures ddies se
chargent de l'tablissement, de la libration et de la reconfiguration des
liaisons radio pour un UE donn. Elles incluent aussi l'initialisation et la
dclaration des mesures spcifiques des liaisons radio.
II.2.2.b - Frame Protocol

Le Frame Protocol se trouve au niveau du plan usager de la couche rseau
radio, il est aussi appel Data Stream . Il est non seulement responsable
de la transmission des donnes utilisateurs sur la liaison radio mais aussi du
transfert des informations de contrle tel le contrle de puissance par
exemple. C'est la raison pour laquelle il dfinit la structure des
43

SONATEL
Iub
trames approprie pour chaque type de donne. Ainsi les blocs de
transport7 reus par le Node B dans le sens montant via l'interface Uu sont
ensuite relays de faon transparente sur l'interface Iub en utilisant les
structures de trames dfinies par le Frame Protocol. De la mme manire,
pour le sens descendant, les blocs de transport reus par le Node B sont
ensuite transmis via l'interface Uu l'UE.
Le Frame Protocol est spcifi dans le 3GPP TS 25.427 pour les canaux de
transport ddis et dans le 3GPP TS 25.435 pour les canaux de transport
communs, du fait qu'il soit divis en deux parties distinctes, savoir : le FPCCH et le FP-DCH.
Le FP-CCH (Frame Protocols for Common Transport Channels) se charge
d'assurer le transfert des blocs de transport pour les canaux de transport
communs. Tandis que le FP-DCH (Frame Protocol for Dedicated Transport
Channels) fournit le transfert des blocs de transport pour les canaux de
transport ddis.
Cependant, il est aussi noter que les deux parties du Frame Protocol se
chargent d'effectuer des mcanismes pour la synchronisation des canaux de
transport aussi bien sur l'interface Iub que sur l'interface Iur. En fait, les
canaux de transport sur l'interface Iub qui mnent du Drift RNC au Node B
doivent avoir les mmes paramtres de configuration que les canaux de
transport sur l'interface Iur qui mne du Serving RNC au Drift RNC.
II.2.3 - Iub Hybride
Depuis la release 5 de 3GPP, le protocole IP a t introduit comme option de
transport de ce fait, l'ATM qui tait auparavant en charge d'assurer le
transport sur l'interface Iub se trouve prsent n'tre qu'une alternative et ne
demeure plus tre la seule option de transport sur la couche rseau de
transport de l'interface Iub. De ce fait, comme nous l'avons tudi
prcdemment, il est possible d'avoir des interfaces Iub bases sur ATM et
d'autres bases sur IP. Cependant il est aussi possible d'avoir des Iub bases
non seulement sur ATM mais aussi sur IP : C'est le cas des Iub hybrides. Il est
alors essentiel pour l'oprateur de mettre en place des solutions
d'interfonctionnement pour assurer l'interoprabilit entre les interfaces ATM
et IP lors de sa migration vers une architecture Tout-IP qui se fera
assurment de faon graduelle. Cependant l'interoprabilit entre un noeud
UTRAN disposant que d'interfaces bases sur IP et un noeud UTRAN bas
sur ATM, doit tre effectue au sein de la couche rseau de transport dans le
but de maintenir l'indpendance de la couche rseau radio. Ceci implique
qu'aucun mcanisme d'interfonctionnement n'est requis dans la couche
rseau
7
Un bloc de transport appartient un canal de transport, cependant plusieurs blocs de transport peuvent
tre envoys simultanment pour former un bloc de transport fix.
44
SONATEL

radio, quand bien mme diffrentes technologies sont utilises pour le
transport dans la couche rseau de transport. Ainsi pour assurer
l'interconnexion entre les noeuds supportant seulement l'option IP et
ceux qui sont uniquement bass sur ATM, deux solutions ont t
spcifies dans la Release 5 du3GPP : le Dual Stack, et le TNL IWU
(Transport Network Layer Interworking Unit).
II.2.3.a - Dual Stack

Le Dual Stack est particulirement adapt l'interface Iub hybride. Dans
cette option Dual Stack, qui se traduit en franais par Double Pile , un
RNC de la Release 5 doit fournir deux piles de transport, telle enseigne
que les Node B bass sur ATM et ceux bass sur IP puissent tre en
mesure de s'interfacer avec un RNC bas IP. Le schma qui suit illustre
le principe du l'option Dual Stack.
Figure 19: Interfonctionnement ATM et IP avec Dual Stack

L'interfonctionnement se fait uniquement au niveau de la couche
rseau transport, la couche rseau radio demeure la mme quelque soit
l'option choisie pour la couche rseau transport. Pour assurer
l'interfonctionnement, gnralement, un noeud IP communiquant avec
un noeud purement bas ATM, ncessite la pile protocolaire complte
d'ATM de la couche rseau transport. Sur l'interface Iub, la solution Dual
Stack est suffisante pour rpondre aux exigences d'interconnexion.
II.2.3.b - TNL IWU

Cette option est surtout implmente dans les interfaces Iur pour une
connexion entre un RNC bas IP voulant communiquer avec un RNC
bas sur ATM.Un TNL IWU peut aussi bien tre externalis et plac
quelque part entre les noeuds connects ou peut tre intgr dans un
noeud IP donn pour assurer l'interfonctionnement ATM et IP. Il se
charge principalement de
45
SONATEL

fournir une translation entre les formats ATM et IP en intervenant
uniquement au niveau de la couche rseau transport
Figure 20: Interfonctionnement ATM et IP avec IWU

La figure 20 illustre un TNL IWU externalis fournissant une interface
ATM d'un ct et une interface IP de l'autre. Cependant, il est essentiel
pour le TNL IWU qu'il soit externalis ou intgr dans un noeud IP, de
disposer d'un plan du transport (Transport Network Control Plane) qui fait
intervenir le protocole ALCAP utilis pour l'tablissement dynamique
des connexions AAL2 entre le TNL IWU et le noeud bas sur ATM.
Dans ce chapitre nous avons tudi l'architecture de l'interface Iub et
comment sa structure en couches se dfinit suivant les diffrentes
technologies de transport choisies au niveau de l'UTRAN, notamment
ATM et IP. Vu qu'actuellement nous assistons une re o
la convergence Tout-IP est d'actualit, nous avons aussi fait voir un
type d'interface Iub bien particulier, dit hybride dont le transport au
niveau de l'UTRAN est aussi bien bas sur ATM que sur IP, et cela
moyennant des techniques d'interfonctionnement entre les diffrents
options de transport. Dans le chapitre suivant, nous verrons comment la
SONATEL a dploy ses interfaces Iub dans son rseau d'accs.
46
SONATEL
Chapitre III : L'interface Iub dans l'UTRAN de la SONATEL

Mmoire de fin de cycle - Master 2 Chapitre III
Mamadou Lamine NDIAYE L'interface Iub dans l'UTRAN de la SONATEL
Dans le rseau d'accs 3G de la SONATEL, l'interface Iub existe sous

diffrentes architectures suivant la technologie choisie comme option de
transport. Cela dpend aussi de la position gographique du Node B
raccorder au RNC et des diffrentes entits qui se trouvent entre eux. Pour
tirer profit de faon optimale des ressources disponibles dans le rseau, la
SONATEL se base sur les technologies existantes afin de dfinir comment
relier au mieux le Node B au RNC. Dans la suite de cette tude nous verrons
dans un premier temps les quipements spcifiques au Node B et au RNC,
avant de voir les diffrentes architectures existantes de l'Iub, dpendamment
de la technologie choisie pour assurer le transport. Nous verrons par la suite
comment la SONATEL a tabli ses liens Iub dans son rseau d'accs 3G, et
enfin comment ses interfaces Iub sont gres en vue d'en apprhender les
instabilits rencontres.
III.1 - Les quipements de l'UTRAN de la SONATEL
Aprs l'appel d'offre effectu par la SONATEL auprs des fournisseurs pour le
dploiement du rseau 3G, l'quipementier Huawe a su tirer son pingle du
jeu. C'est ainsi que les principaux quipements de l'interface Iub tels que le
Node B et le RNC ont t dploys par Huawe.
III.1.1 - Le Node B
Le Node B de Huawe aussi appel DBS3900 est compos du BBU et du
RRU qui sont respectivement des quipements Indoor et Outdoor.
Actuellement le BBU3900 et le RRU3804 sont les sries utilises au niveau
du rseau. Le BBU est l'quipement intelligent du Node B qui se charge de
fournir des transmissions en bande de base et contient les interfaces de
communication avec le RNC. Le RRU quant lui, reprsente le module RF
qui joue le rle d'interface entre le systme antennaire et le BBU, du fait qu'il
reoit les signaux en bande de base de la BBU3900 et les convertit en
signaux RF pour le systme antennaire.
Le BBU3900 est caractris par sa capacit fournir des interfaces pour
diffrents types de transport en E1/T1, en FE (port optique et lectrique). Il
supporte les transmissions en ATM, IP ou hybride et fournit aussi une source
d'horloge interne en absence d'horloge externe pour la synchronisation.
48
SONATEL
III.1.1.a - Les cartes du BBU3900

Le BBU3900 comprend plusieurs cartes qui ont chacune une fonction
particulire :
UBFA : Cette carte se charge de contrler la ventilation du BBU3900.
WBBP : Elle est la carte mre du BBU3900, elle traite les signaux en
bande de base.
UTRP : Il s'agit d'une carte d'extension de transmission de la BBU3900.
WMPT : C'est la carte principale de contrle et de transmission qui
traite les signaux et manage les ressources pour les autres cartes. Elle
contient les ports pour chaque type de transport.
UPEU : Elle est essentielle, elle reprsente la carte d'alimentation du
BBU3900.
La figure qui suit illustre les diffrentes cartes contenues au sein du
BBU3900.
Figure 21: Les diffrentes cartes du BBU3900
Il peut y avoir jusqu' trois RRU pour chaque BBU, et chaque RRU est
reli au BBU par fibre optique. Au niveau de la SONATEL les DBS3900
disposent de six cellules, dont trois pour les donnes et trois autres
pour la voix et les donnes. La figure qui suit illustre les composantes
de la DBS3900 utilises au sein de l'UTRAN.
Figure 22: Le DBS3900 de Huawe.

49
SONATEL
Mmoire de fin de cycle - Master 2 Chapitre III Mamadou Lamine NDIAYE
L'interface Iub dans l'UTRAN de la SONATEL
III.1.2 - Le RNC
Le RNC de Huawe, aussi appel BSC6810, a la possibilit de grer 200
Node B et 600 cellules en configuration minimale avec un seul chssis,
tandis qu'en configuration maximale avec deux chssis, 1700 Node B et
5100 cellules peuvent tre grs. C'est par le RNC que la supervision se
fait au niveau du centre d'opration et de maintenance. Il est constitu
d'un chssis double face contenant quatre compartiments comme
l'illustre la figure qui suit.
Figure 23: Le BSC6810 de Huawe
III.1.2.a - Les cartes du RNC BSC6810

Le RNC comprend plusieurs cartes pour chaque face du chssis. La
figure suivante illustre la disposition des cartes au niveau du chssis.
Figure 24: Les cartes du BSC6810 de Huawe.

50
SONATEL
La figure 24 illustre les diffrentes cartes contenues au sein du RNC de

Huawe, notamment le BSC6810. Nous trouvons entre autres :
SPUa : Elles sont en charge du traitement de toute la signalisation.
DPUb : Les cartes DPUb s'occupent de tous les trafics voix et donnes. elles
se chargent aussi du multiplexage et du dmultiplexage des trafics entre les
Node B et le coeur de rseau.
GCUa et GCGa : Elles s'occupent des signaux de synchronisation. Elles
sont en charge de la rcupration des signaux d'horloge reus depuis
l'horloge de rfrence externe.
SCUa : Elle se charge de la commutation interne du RNC ainsi que de la
distribution des signaux d'horloge.
OMUa : C'est via les cartes OMU que les oprations de maintenances et de
supervision sont ralises au niveau de l'OMC-R, elle contient tous les fichiers
systme.
RINT reprsente les cartes de transport spcifiques qui permettent au RNC
de s'interfacer avec les diffrents lments du rseau. (Voir Annexe 1).
Pour assurer une bonne qualit de service, les cartes fonctionnent en
redondance Active/Standby. De ce fait, si une carte active prsente des
disfonctionnements, la carte standby prend aussitt le relais garantissant ainsi
une continuit transparente des services fournis par le RNC.
III.2 - L'interface Iub dans l'UTRAN de la SONATEL
Comme il a t soulign dans le chapitre prcdent, deux options de transport
sont possibles pour assurer le transport au niveau de l'UTRAN. Dans le
rseau de la SONATEL plusieurs configurations Iub ont t retenues, dont
certaines sont bases exclusivement sur ATM tandis que d'autres sont
hybrides et utilisent aussi bien l'ATM que l'IP pour assurer le transport.
III.2.1 - Architectures de l'interface Iub sous ATM
L'ide gnrale c'est de relier le Node B au RNC, et pour y parvenir beaucoup
d'entits interviennent pour assurer la liaison. Dans le cas o le RNC n'est
pas trs loign du Node B, un raccordement direct peut tre mis en oeuvre.
Cependant, il arrive que le Node B soit loign, ainsi la solution serait d'utiliser
le rseau de transmission SDH, et ensuite d'utiliser
51
SONATEL
des prolongements8 pour relier le Node B au RNC. Diffrentes architectures
sont possibles pour les interfaces Iub fonctionnant sur ATM, et cela dpend de
la distance du site dans lequel se situe le Node B.
III.2.1.a - Raccordement direct

Dans le cas d'un raccordement direct, le Node B se trouve sur le mme site
que le RNC. Ainsi, il sera desservi par des E1 ou MIC qui sont bass sur la
norme G.703 de l'UIT. La figure ci-dessous illustre un lien Iub par
raccordement direct.
Figure 25: Interface Iub par raccordement direct

Quand bien mme le Node B se trouve sur le mme site que le RNC ils ne
trouvent pas sur un mme primtre bien dfini, de ce fait la liaison se fait via
le rseau de transmission SDH qui fournit des accs pour chaque quipement
du central afin de relayer les donnes de faon transparente. La jonction entre
l'quipement et l'accs du rseau SDH est ralise par des jarretires.
III.2.1.b - Prolongement par SHDSL

Dans la plupart du temps, le Node B se situe sur un site quelque peu loign
du site dans lequel se trouve le RNC, gnralement appel un central. Vu que
la SONATEL dispose dj d'un rseau de transmission SDH, ainsi le premier
reflexe serait de raccorder le Node B au rseau de transmission SDH via le
NE le plus proche qui se chargera ensuite d'assurer la transmission jusqu'au
RNC dj raccord au rseau de transmission son niveau. Le NE de
transmission est un ADM (Add Drop Multiplexer) tel l'ADR-2500 de
l'quipementier SAGEM.
L'ADM est un multiplexeur SDH du fait qu'il peut multiplexer N signaux SDH
pour former une trame STM-4 ou STM-16 suivant le constructeur de
l'quipement.
8 Les prolongements servent de relais entre le rseau de transmission
SDH et le Node B. Il existe diffrents types de prolongements suivant la
distance du Node B raccorder.
52
SONATEL
Cependant, si l'ADM se trouve moins de 4,5 km du Node B raccorder, le
recours du SHDSL serait ncessaire pour atteindre le Node B et permettrait
ainsi de faire la synchronisation sur une ou deux paires tlphoniques
existantes.
Le SDHSL ou G.SHDSL est une des techniques de la famille DSL qui
correspond la norme internationale de l'UIT G.991.2. Il offre des dbits
symtriques en Upstream et Downstram qui peuvent atteindre 2,3Mbit/s sur
une simple paire de fils cuivre. Ainsi des dbits plus levs peuvent tre
obtenus en utilisant deux quatre paires de cuivre.
Dans cette architecture des modems SHDSL sont utiliss au niveau des Node
B pour adapter les E1 sur les liaisons SHDSL, et l'autre bout des liaisons
SHDSL, un MSAN (Multiservice Access Node) de type Megaplex-4100 de
l'quipementier RAD est utilis pour la collecte de l'ensemble des liaisons
SHDSL venant des Node B de sites diffrents. Ce mme MSAN sera ensuite
raccord au rseau SDH via un ADM qui assurera la transmission jusqu'au
RNC. Le Megaplex-4100 communment appel MP-4100 et le modem
SHDSL de la Node B peuvent tre vus respectivement comme un modem
matre et un modem esclave de la liaison SHDSL. La figure ci-aprs
illustre une interface Iub avec une liaison SHDSL.
Figure 26: Interface Iub par prolongement SHDSL III.2.1.c - Prolongement

par F.H
Il arrive que le site o se situe le Node B soit trs loign de l'ADM et se
trouve dans des zones difficiles d'accs, telle enseigne qu'il soit hors de
porte de la liaison SHDSL. De ce fait, pour atteindre le Node B il va falloir
faire recours l'utilisation des FH, communment appels faisceaux
hertziens, qui permettent d'avoir des portes beaucoup plus leves.
Un faisceau hertzien est une liaison compose de deux antennes mettricesrceptrices pointes exactement l'une vers l'autre, utilisant comme support les
ondes radiolectriques avec des frquences porteuses pouvant atteindre 40
GHz. Pour des raisons de distance et de visibilit, le trajet hertzien entre
l'metteur et le rcepteur est souvent dcoup en plusieurs tronons, appels
bonds, relis par des stations relais. Notamment, en voulant changer la
direction d'un FH, un couple d'antennes peut tre utilis de telle sorte que
l'une reoit via une direction, et l'autre se charge de rmettre sur une autre
direction donne. Pour chaque liaison
53
SONATEL

hertzienne il est essentiel de dfinir deux frquences correspondant aux deux
sens de transmission.
Les FH peuvent fournir des dbits allant de 2 155 Mbits/s et une porte
pouvant atteindre 70 km, et ce selon le plan de frquence attribu.
Pour les interfaces Iub exclusivement bases ATM, les FH dit classiques sont
utiliss pour assurer la liaison entre le Node B et le rseau de transmission
sur lequel le RNC est raccord. La figure qui suit illustre une liaison ralise
avec un faisceau hertzien.
Figure 27: Interface Iub par prolongement FH.

III.2.2 - Architecture de l'interface Iub sous IP
La SONATEL a dbut le dploiement de ses Node B dans le courant de
l'anne 2010, ce qui implique qu'actuellement ils sont en cours de migration
vers le Tout-IP . Assurment, cette migration se fait graduellement avec
l'utilisation du rseau ATM d'un ct, le rseau IP de l'autre et entre les deux
rseaux des quipements hybrides sont utiliss. Par analogie l'interface Iub,
l'interconnexion est ralise en faisant recours des quipements fournissant
des interfaces ATM et Ethernet avec l'option Dual Stack qui a t tudie
dans le chapitre prcdent (Figure 19). On peut distinguer plusieurs
architectures Iub faisant intervenir l'option Dual Stack au sein du rseau.
III.2.2.a - Dual Stack sur FH

La SONATEL dispose d'un nouveau type de FH, dit FH hybride qui se charge
d'assurer la fonction de Dual Stack. Le FH hybride est de type 9500 MPR
(Microwave Packet Radio), dernier n de la gamme d'Alcatel-Lucent, il
reprsente une nouvelle gnration de FH nativement IP/Ethernet. Le FH
hybride fournit des interfaces E1, Ethernet et STM permettant
54
SONATEL
ainsi de s'interfacer d'une part avec le rseau IP/MPLS et d'autre part avec le
rseau SDH. Il fournit ainsi un moyen de faire une migration souple vers une
infrastructure tout IP.
Le 9500 MPR supporte non seulement le trafic ATM existant, mais il se charge
aussi de transformer l'ensemble des trafics reus en paquets IP avant de
procder l'mission via l'antenne FH.
Le 9500 MPR est compos du MSS (Microwave Service Switch) qui
reprsente la partie Indoor, tandis que l'ensemble form du MPT (Microwave
Packet Transport) et de l'antenne FH reprsente la partie Outdoor. A
l'mission au niveau de l'quipement Indoor, notamment le Microwave Service
Switch, le trafic ATM reu est encapsul sur des paquets IP par l'mulation
PSEW39 et la rception, l'opration inverse est effectue pour la
reconstruction du trafic ATM d'origine. Ainsi les diffrents types de trafic des
Node B seront achemins au RNC, du fait que le trafic ATM sera relay vers
le rseau SDH tandis que les paquets IP natifs pourront transiter vers le
rseau IP/MPLS. La figure qui suit illustre l'architecture Iub base sur le FH
hybride.
Figure 28: Interface Iub hybride par prolongement FH.
III.2.2.b -Dual Stack sur MP-4100

Le Megaplex-4100, communment appel MP-4100 est un quipement de la
firme RAD. Il reprsente ici l'quipement intelligent qui se charge non
seulement de fournir des interfaces standard d'ATM bases sur la
spcification de l'IUT I.432.3, mais aussi des interfaces Ethernet et STM-1. Ce
qui lui permet de s'interfacer avec le rseau IP/MPLS et le rseau de
transmission SDH en fournissant ainsi aux oprateurs de faire une migration
souple vers le Tout-IP . Dans cette architecture les Node B disposent de
modems SHDSL pour
9
La technique d'mulation PSWE3 est utilise pour adapter les trafics ATM en paquet IP, tel qu'il a t dfini
dans la fiche technique du 9500 MPR d'Alcatel-Lucent.
55
SONATEL
multiplexer la voix et les donnes sur la liaison SHDSL, ainsi la terminaison
de la liaison SHDSL, le MP-4100 se chargera de rcuprer les diffrents types
de trafics et de les acheminer vers le rseau de transmission appropri,
destination du RNC.
Le MP-4100 a aussi la capacit d'muler les trafics des technologies

traditionnelles, tel l'ATM sur un rseau IP en utilisant l'mulation PSWE3.
Cependant, dans cette architecture cette mulation n'a pas lieu d'tre utilise,
du fait que le MP-4100 est dj raccord sur le rseau SDH. La figure qui suit
illustre l'architecture d'une interface Iub base sur le MP4100.
Figure 29: Interface Iub hybride par prolongement SHDSL.
III.2.2.c -Dual Stack sur Cell Site

Gateway
Dans cette architecture le Dual Stack est effectu par deux entits du rseau,
savoir le Cell Site Gateway (CSG) et le RNC Site Gateway (RSG) ou MASG
(Mobile Aggregation Site Gateway). A eux deux ils fournissent des interfaces
ATM et Ethernet pour le transport respectif de la voix et des donnes.
Le CSG et le MASG sont respectivement connects au Node B et au RNC et
servent coupler les deux technologies de transport via un rseau IP en
utilisant l'mulation PSWE310. Ainsi les trafics temps rel d'ATM (la voix)
seront adapts par le CSG en vue d'tre transports sur le rseau IP/MPLS
destination du MASG qui se chargera d'effectuer l'opration inverse. Le CSG
et le MASG peuvent tre considrs respectivement comme un modem
esclave et modem matre .
Sur l'interface Iub, en aval du CSG des liaisons SHDSL sont tablies. Le CSG
se charge alors de sparer les flux en dfinissant ainsi un VLAN appropri
pour chaque type de trafic. De ce fait, chaque paire SHDSL contient un type
de trafic donn, entre autres les donnes utilisateur (HSDPA et HSUPA) ainsi
que la voix et les donnes essentielles pour la supervision.
10
PSWE3 : Pseudo Wire Emulation Edge-to-Edge est une technique d'mulation d'une connexion point
point sur un rseau commutation de paquet, tel qu'il a t dfini par l'IETF.
56
SONATEL
Le DSLAM se chargera ensuite de faire la collecte de l'ensemble des liaisons
SHDSL. Il se charge de regrouper le trafic des diffrentes lignes SHDSL et de
le rediriger vers un commutateur, qui son tour, s'occupera de faire
l'aiguillage vers le routeur de priphrie du rseau IP/MPLS, communment
appel le PE routeur (Provider Edge Router).
Au coeur du rseau IP/MPLS, les flux de mme type sont traits de la mme
manire en suivant un mme chemin prtabli par le routeur de priphrie. A
cet effet, le PE routeur se base sur les VLAN et dfinit ainsi des tables de
routage virtuelles dites VRF (Virtual Routing and Forwarding) pour chaque
VLAN correspondant.
A la sortie du rseau IP/MPLS, le MASG se chargera de faire la collecte du
trafic puis procde une sparation des flux avant de le remettre au RNC.
Cette sparation de flux est rendue possible par les VRF contenues au sein
du MASG qui permettent de mapper un VLAN chaque de type de flux
donn, et ce pour tout le trafic venant de l'ensemble des Node B contrl par
le mme RNC. La figure suivante illustre l'architecture de l'interface Iub base
sur IP.
57
Figure 30: Interface Iub base sur IP

Cette architecture est la plus utilise dans le rseau d'accs 3G de la
SONATEL. Elle offre des dbits consquents en HSDPA, notamment avec la
technique de raccordement double entre le CSG et le DSLAM qui consiste
utiliser le port ADSL2+ du CSG pour raccorder une paire SHDSL. Cependant,
cette technique de raccordement double est lie une contrainte de distance,
car le CSG doit se situer moins de 2 Km du DSLAM pour bnficier de
dbits optimaux.
III.3 - La supervision de l'interface Iub
Pour garantir une bonne efficacit du rseau, les quipements doivent
fonctionner pleinement et en permanence. A tous les niveaux, chaque
quipement constitue un maillon sensible dont
SONATEL
la disponibilit et la qualit de service conditionnent le bon fonctionnement du
rseau. Les problmes lis aux quipements doivent donc tre rduits au
minimum, car un temps soit peu d'indisponibilit pourrait avoir des impacts
trs prjudiciables sur la qualit de service du rseau. Il est donc essentiel de
garantir une remonte d'information rapide en cas de problme en vue de
faire une intervention dans les plus brefs dlais. Tel est le rle de la
supervision.
Au niveau du rseau de la SONATEL, la supervision se fait plusieurs niveau
du rseau dans le sous systme d'exploitation et de maintenance (OSS).
Dans le cas de la supervision des lments de l'UTRAN, la supervision est
faite au niveau du centre d'exploitation et de maintenance radio,
communment appel OMC-R (Operation and Maintenance Center-Radio)
pour faire court. Le centre d'exploitation et de maintenance assure la gestion
technique qui consiste garantir la disponibilit et la bonne configuration des
quipements du rseau. Ses axes de travail sont la supervision des
quipements, la suppression des dysfonctionnements, la gestion des versions
logicielles, la gestion des performances et gestion de la scurit. Dans la suite
de cette tude, nous ferons focus sur la supervision des quipements de

l'interface Iub, savoir le Node B et le RNC.
III.3.1 - Description du M2000 (Huawe)
Le iManager M2000 Mobile Element System de Huawe, pour faire court est
communment appel M2000 Huawe, est le systme de management du
rseau utilis par la SONATEL pour assurer la supervision de son rseau
d'accs 3G. Le M2000 est compos d'un serveur, de clients et d'une boite
d'alarme, le tout formant ainsi un environnement Client/Serveur. Il est aussi
possible d'avoir une architecture dans laquelle plusieurs serveurs
interviennent, dans ce cas les serveurs fonctionneront en mode Master/Slave.
Le M2000 serveur est connect RNC, disposant ainsi d'une vue globale de
l'ensemble des Node B et RNC du rseau. Cette interconnexion entre le
M2000 serveur et le RNC est faite via les cartes OMU du RNC par Ethernet.
Les M2000 clients, aussi appels LMT (Local Maintenance Terminal) sont
raccords au serveur par le biais d'un rseau LAN Ethernet. La boite d'alarme
(ou Alarm box) est connecte au LMT et quand une alarme est signale, le
LMT se charge de transfrer les alarmes la boite d'alarme qui s'assure de
gnrer des alarmes audio-visuelles, en d'autres termes elle met des
indications audibles et visibles. Le M2000 offre au superviseur une interface
graphique conviviale sur le LMT et lui offre la possibilit de manager et de
grer les quipements et ressources du rseau l'aide de commandes
spcifiques (MML Command). Pour une meilleure perception la figure 31
illustre l'architecture du M2000 de Huawe.
58
SONATEL
Mmoire de fin de cycle - Master 2 Chapitre III Mamadou Lamine NDIAYE
L'interface Iub dans l'UTRAN de la SONATEL
Figure 31: Architecture du M2000 Huawe

III.3.2 - Les alarmes du M2000 (Huawe)
Diffrentes sortes d'alarmes sont signales par le M2000, et elles
dpendent surtout de la nature mme des dfaillances des quipements,
ainsi que de leurs gravits.
III.3.2.a - Nature des alarmes

Les alarmes peuvent tre de natures diffrentes suivant la cause de la
dfaillance. Ces alarmes peuvent tre causes par une dfaillance au
niveau mme de l'quipement, telle une carte dtriore, ou alors des
dfaillances lies l'infrastructure des sites et leurs accessoires.
Dans le M2000 Huawe nous trouvons entre autres les alarmes qui
suivent :
Alarme d'alimentation
Alarme d'environnent
Alarme de signalisation
Alarme de transmission
Alarme Hardware
Alarme Software
Alarme de fonctionnement du systme
Alarme de communication systme
Alarme QoS
59
SONATEL

Le superviseur a la possibilit de crer un filtre pour afficher des alarmes

spcifiques leurs natures et leurs degrs de gravit pour que les
dfaillances de niveau critique par exemple puissent tre restaures dans les
plus brefs dlais. La figure qui suit illustre un filtre pour le choix des natures
d'alarme voulant tre listes.
Figure 32: Filtre des natures d'alarmes sur M2000 pour les cellules 3G hors
services.
III.3.2.b - Niveau de gravit des alarmes
Suivant la svrit des alarmes, nous avons entre autres :
Alarme critique : Telle une panne d'nergie sur site qui affecte l'ensemble de
l'opration du systme. Elle ncessite une restauration immdiate.
Alarme majeure : Elle indique quand un cble prsente des dfauts par
exemple, et si ces dfaillances ne sont pas pris en charge elles peuvent
affecter la qualit de service.
Alarme mineure : Telle des bits d'erreurs dans certains liens physique, elle
indique que la qualit de service est lgrement affecte.
Alarme d'avertissement : Elle est purement indicative, elle informe sur le
statut de l'quipement durant l'excution d'une tche.
60
SONATEL

La figure qui suit illustre les alarmes remontes par M2000 de l'ensemble des
cellules hors services du rseau 3G de la SONATEL.
Figure 33: Alarmes des cellules 3G hors services
Tel nous pouvons le voir sur la figure 33, toutes les six cellules du Node B se
trouvant sur le site Cap Manuel sont hors services, en gnral cela est caus
par un problme li l'nergie du site ou par des coupures de liaisons entre le
Node B et le RNC.
Le M2000 de Huawe offre une large panoplie pour la gestion et le
management des quipements et ressources de l'UTRAN. Ainsi tous les Node
B et RNC du rseau d'accs 3G de la SONATEL sont superviss pour assurer

leurs bons fonctionnement et palier aux dfaillances en cas de panne. De
plus, aprs chaque dfaillance une intervention dite curative est faite sur le
site dans un dlai de 30 min aprs la signalisation de l'alarme par le
superviseur. Dans le mme contexte, la SONATEL se charge aussi de faire
des interventions prventives qui sont faites rgulirement pour s'assurer du
bon tat de fonctionnement des
61
SONATEL
quipements et de leur environnement. Cela permet d'viter d'ventuelles
dfaillances techniques qui ncessiteront des interventions curatives
l'avenir.
Nous avons fait voir dans ce chapitre les diffrentes architectures de
l'interface Iub existantes au niveau du rseau de la SONATEL. Nous avons
aussi tudi comment la SONATEL a dploy ses interfaces Iub hybrides en
vue de faire coexister les technologies ATM et IP pour effectuer une migration
graduelle vers une architecture Tout-IP . Dans ce chapitre nous avons
aussi fait voir la faon dont les interfaces Iub sont supervises dans le centre
d'opration et de maintenance radio (OMC-R) de la SONATEL. Dans le
prochain chapitre, nous tudierons les instabilits lies ces interfaces en
vue d'en amliorer la qualit de service du rseau 3G.
62
SONATEL
Chapitre IV : Instabilits de l'interface Iub et QoS dans l'UTRAN de la

SONATEL
63
SONATEL
Mmoire de fin de cycle - Master 2 Chapitre IV
Mamadou Lamine NDIAYE Instabilits de l'interface Iub et QoS dans
l'UTRAN de la SONATEL
Tel nous l'avons vu dans le chapitre III, l'interface Iub peut tre, de temps
autre, sujette des dfaillances de natures et de gravits diffrentes.
Cependant, une inconstance de nature spcifique, telle la perte de
synchronisation, vient assez rgulirement au niveau de l'interface Iub, et cela
est quelque peu prjudiciable la qualit de service du rseau. Dans ce
chapitre nous allons tudier, dans un premier temps, le rseau de
synchronisation de la SONATEL. Nous verrons par la suite les causes lies
aux pertes de synchronisation en vue de voir les diffrentes solutions
possibles pour viter, ou au pire, rduire au mieux la perte de synchronisation
du rseau. Enfin, nous finirons par voir des perspectives d'avenir afin
d'amliorer la qualit de service et ainsi faciliter la synchronisation du rseau.
IV.1 - La synchronisation dans le rseau d'accs 3G de la SONATEL
IV.1.1 - Description
La synchronisation est essentielle pour le bon fonctionnement du rseau. Il
s'agit d'un concept gnrique dont une source d'horloge se charge d'attribuer
tous les lments du rseau le mme signal d'horloge en vue d'viter une
fluctuation de frquence ou de gigue qui peuvent tre l'origine de pertes de
donnes.
Cependant, les pertes de donnes causes par les problmes de
synchronisation peuvent tre rduites par l'utilisation d'horloges
synchronises avec une horloge de rfrence de type atomique, et ce dans
tous les noeuds de l'UTRAN.
Pour rappel, l'horloge atomique est une horloge de trs haute prcision base
sur l'atome Csium. En effet, l'atome Csium est utilis comme rfrence de
la dure d'une seconde11, du fait que la seconde reprsente la dure de 9 192

631 770 priodes de la transition entre les deux niveaux hyperfins de l'tat
fondamental de l'atome Csium 133 : d'o le nom d'horloge atomique.
Les horloges atomiques avec leur stabilit et leur prcision avoisinant la
picosecondes font qu'elles constituent aujourd'hui les talons du temps (ou de
frquence).
La distribution d'horloge de rfrence peut tre faite plusieurs niveaux du
rseau.
Dans le cas du rseau de la SONATEL, la synchronisation est faite au niveau
du rseau SDH par deux horloges atomiques de l'quipementier Oscilloquartz
fonctionnant en mode Master/Slave. De ce fait, si l'une tombe en panne,
l'autre se charge de prendre le relais pour assurer la distribution fiable de
synchronisation.
11
L'unit de la seconde a t dfinie lors de la 13me Confrence gnrale des poids et mesures (CGPM) en
1967.
64
SONATEL
65
Instabilits de l'interface Iub et QoS dans l'UTRAN de la SONATEL
Tel qu'il a t dfini dans la spcification de l'IUT G.811, les horloges

atomiques sont utilises au sein des rseaux SDH comme horloge de
rfrence primaire (Primary Reference Clock) pour assurer une bonne
distribution d'horloge sur tous les noeuds du rseau.
La figure qui suit illustre la distribution d'horloge dans le rseau d'accs

3G de la SONATEL.
Figure 34: Distribution de l'horloge dans l'UTRAN de la SONATEL.

Comme l'illustre la figure, la distribution de l'horloge du PRC est assure
au niveau du rseau SDH pour assurer la synchronisation de tous les
noeuds de l'UTRAN. Ainsi d'une part le MASG rcupre l'horloge de
rfrence pour l'acheminer au RNC, et d'autre part le DSLAM se charge
de fournir une synchronisation des Node B aprs avoir rcupr le
signal d'horloge. Et dans le cas o l'horloge atomique Master
prsente des dfaillances, l'horloge de rfrence Slave se charge de
prendre le relais.
IV.1.2 - Les causes lies la perte de

synchronisation
Dans le rseau de la SONATEL, on constate qu'il se passe parfois des
phnomnes de glissements d'horloge, ou gigue, qui peuvent entrainer
la longue des pertes de donnes car les quipements perdent leur
rfrence d'horloge de synchronisation. Au niveau de la supervision par
exemple, les alarmes lies au problme de synchronisation viennent
assez souvent, du fait que les Node B perdent leur rfrence d'horloge
et cela est li plusieurs facteurs tels des cartes dtriores contenues
au sein des quipements, des connecteurs dfaillants entre autres. Mais
parmi les causes les plus frquentes, nous avons des dtriorations sur
les paires torsades au niveau de la boucle locale ainsi qu'un souci de

SONATEL
rgnration du signal d'horloge dans le rseau de synchronisation. Nous
tenterons de voir les solutions viables aux pertes de synchronisation du
rseau 3G de la SONATEL.
IV.2 - Solutions la perte de synchronisation du rseau 3G IV.2.1
- Section des paires de cuivre
Mis part les dfaillances techniques voques prcdemment, la plupart du
temps, les pertes de synchronisation ne sont qu'une consquence des
dfaillances physiques au niveau des paires torsades sur la partie SHDSL.
En effet, le SHDSL utilise la boucle locale comme support physique, dans
laquelle la paire torsade est utilise du rpartiteur au Node B en passant par
les sous-rpartiteurs et les points de concentration. La figure qui suit illustre la
boucle locale dans laquelle la paire torsade est utilise jusqu'aux Node B.
Figure 35: Boucle locale du rseau d'accs.

La paire torsade de la boucle locale est compose d'une paire de cuivre de
diamtre de 0.4 mm, 0.6 mm et 0.8 mm, et sont communment exprimes en
dixime de millimtres. La paire de cuivre 4/10me est couramment utilise sur
les tronons de la boucle locale de la SONATEL. Parmi les diffrentes paires

de cuivre de la boucle locale, celles en 4/10me sont beaucoup plus sujettes
aux dfaillances physiques, du fait qu'elles sont beaucoup plus
66
SONATEL

exposes aux dtriorations et aux coupures dans le long terme que les
autres paires de cuivre de diamtres suprieures. En effet plus le cble
est gros, plus il est cher mais meilleure est sa qualit. De plus, la
formule physique sur la rsistivit12 du fil montre que, plus le diamtre du
fil de cuivre est grand, et plus sa capacit s'opposer la circulation du
signal lectrique diminue. En d'autres termes, longueur gale,
l'affaiblissement est moindre dans un cble de grosse section. De ce fait,
quand bien mme elles sont plus coteuses, l'utilisation des paires de
cuivre 8/10me
prime sur celles de diamtres infrieures pour une meilleure qualit
de service sur le long terme.
IV.2.2 - Rgnration du signal d'horloge
Il faudrait aussi se pencher sur le rseau de synchronisation, car mme
si toutes les liaisons de la boucle locale sont faites avec des paires de
cuivre de type 8/10me, les pertes de synchronisation persisteront
toujours. Le rseau de synchronisation est essentiel pour viter les
pertes de synchronisation au niveau des Node B, et ces pertes de
synchronisation peuvent aussi tre causes par le manque
d'quipements rgnrateurs d'horloge de synchronisation. En effet,
lorsque le nombre d'quipements traverss est important, une
dgradation du signal d'horloge peut avoir lieu et les quipements ne
seront ainsi plus synchroniss. Pour pallier cette dgradation,
l'horloge doit tre rgulirement rgnre partir d'une source plus
prcise appele SSU (Synchronisation Supply Unit). Dans le cas du

rseau de la SONATEL, o la synchronisation est faire sur le rseau
SDH, il faudrait s'assurer que les informations de synchronisation du
PRC soient achemines avec prcision tous les noeuds du rseau via
une chane de rfrence dfinie dans la spcification de l'IUT G.803,
illustre sur la figure 36.
Figure 36: Chane de rfrence du rseau de synchronisation SDH.

Comme l'illustre la figure 36, le nombre maximum de noeuds traverss
avant de rgnrer l'horloge l'aide d'un SSU ne doit pas excder 20 ; le
nombre de SSU maximum derrire un
12 Loi d'Ohm sur la rsistance
67
SONATEL
PRC doit tre gal 10 et en tout tat de cause aucun noeud ne doit tre
spar de plus de 60 quipements du PRC. Les lments de la chane de
rfrence sont entre autres :
PRC : Le Primary Reference Clock reprsente l'horloge matresse du
rseau. Elle peut tre une horloge atomique ou un dispositif extrayant la
synchronisation d'un signal GPS depuis des satellites, du fait que les satellites
disposent d'horloges atomique embarques. Sa prcision est de 10-11 suivant
la spcification de l'IUT G.811.
SSU : Le Synchronization Supply Unit se charge d'assurer la rgnration

de l'horloge en liminant la gigue accumule et le drapage de l'horloge
conformment aux valeurs limites13, en vue de fournir ainsi une distribution
fiable de synchronisation aux noeuds du rseau. Le SSU a t dfini dans la
spcification de l'IUT G.812 et dispose d'une prcision de l'ordre de la
nanoseconde.
SEC : Le SDH Equipment Clock se charge de rcuprer l'horloge incidente
sur un des ses accs et le propage aux noeuds suivants partir de son
horloge locale. Sa prcision ne doit tre infrieure 10-7 telle qu'elle a t
dfinie dans la spcification de l'IUT G.813.
Pour une bonne synchronisation du rseau SDH et viter au mieux les pertes
de synchronisation, l'horloge PRC de plus fort niveau doit tre double par
une horloge secondaire SRC (Secondary Reference Clock).
Cependant, l'architecture du rseau SDH de la SONATEL est telle que
chaque noeud du rseau reoit au moins deux circuits d'horloge, du fait que le
rseau SDH est de type bidirectionnel en anneau. Ainsi la rfrence primaire
sera injecte sur la 1re fibre tandis que la rfrence secondaire se chargera
de diffuser sur la 2me fibre, la fibre de secours. L'horloge secondaire sera
utilise en cas de rupture du circuit normal ou en cas d'annonce du noeud N1
d'une perte du rythme de rfrence, ainsi l'horloge du SRC sera considre
comme nouvelle source de rfrence pour la synchronisation. Il est cependant
essentiel de souligner que sur chaque fibre (normal comme secours) il
faudrait qu'il y ait des SSU communs aux deux fibres qui se chargeront de
rgnrer l'horloge qui subira une dgradation aprs avoir travers un certain
nombre de noeuds. La figure ci-dessous illustre la distribution de l'horloge sur
un rseau SDH en anneau bidirectionnel.
13
Les limites de la tolrance de la gigue du rseau de synchronisation SDH sont spcifies dans le G.823
IUT.
68
SONATEL
Mmoire de fin de cycle - Master 2
Chapitre
IV
Mamadou Lamine
NDIAYE
Instabilits de l'interface Iub et QoS dans l'UTRAN de

la SONATEL
Figure 37: Distribution des signaux d'horloge dans un rseau SDH.

Il aussi important de souligner qu'entre les noeuds du rseau des
messages d'tat de synchronisation SSM (Synchronous Status
Messaging) sont changs pour identifier le niveau de la qualit
d'horloge transporte et pour spcifier aux noeuds un critre de
slection de leurs sources de synchronisation listes ci-dessous par ordre
de priorit :
Source d'horloge provenant d'un PRC
Interface STM-N Est (provenant de l'ADM voisin, qui est synchronis par
la rfrence secondaire SRC de secours en cas de panne de la rfrence
primaire)
Interface STM-N Ouest (Provenant de la SRC de secours, par l'autre
ct de l'anneau)
Horloge interne
Ainsi, un message G.811 est inclus dans l'octet S1 de la trame STM
(MSOH) pour spcifier que l'horloge est de trs bonne qualit de type
PRC ; G.812 pour une horloge de bonne qualit de type SSU ; G.813
pour une horloge interne d'quipement. Et surtout un message spcial a
t cre : Do Not Use (DNU). En effet, lorsqu'une horloge est rcupre
sur l'entre d'un port, le message DNU accompagne l'horloge dans le
sens sortie de ce mme port pour viter ainsi l'apparition d'une boucle
de synchronisation.
Le message DNU est aussi utilis pour spcifier au noeud rcepteur qu'il
n'y a plus de source de synchronisation extrieure, dans ce cas le
noeud utilise sont horloge interne et entre ainsi en
mode Free Running.
69
SONATEL
IV.3 - Perspectives d'avenir
Quand bien mme les solutions voques prcdemment reprsentent de
bonnes alternatives pour pallier la perte de synchronisation du rseau, il
serait aussi essentiel de se pencher sur d'autres alternatives qui permettront
au mieux d'viter les pertes de synchronisation dans l'avenir.
IV.3.1 - Synchronous Ethernet (Sync-E)
La migration vers le Tout-IP est d'actualit et les oprateurs tendent
dployer de plus en plus des rseaux de transport bass sur IP. Cependant,
les rseaux commutation de paquets, tel le rseau IP est asynchrone de
nature et ne sont pas appropris au transport d'horloge de synchronisation du
fait qu'il pourrait y avoir des inexactitudes du signal d'horloge produites par
perte des paquets ainsi que la variation du dlai des paquets (PVD) qui
peuvent avoir un impact prjudiciable sur la performance de la
synchronisation dlivre. Ainsi la synchronisation devient un grand dfi pour
les oprateurs voulant migrer vers un rseau de transport bas uniquement
sur Ethernet et IP/MPLS.
Le dfi de la synchronisation via le rseau IP affecte surtout les services
mobiles, car sans solutions viables de transfert d'horloge, les oprateurs
dsirant mettre en place une infrastructure tout IP surtout au niveau RAN
(Radio Access Network), vont courir le risque d'avoir des interruptions de

service lies au manque de synchronisation des Node B. Ainsi les rseaux
commutation de paquets, ncessitent donc une distribution d'horloge robuste
pour tous les lments du rseau tels les Node B, afin d'assurer une relve
prcise en temps rel des services voix et vido, ainsi que pour les
applications de donnes.
Pour faire face au caractre asynchrone du rseau commutation de paquets
et viter ainsi les PVD, l'Ethernet Synchrone ou Synchronous Ethernet en
anglais, communment appel SyncE pour faire court, est une solution viable
pour pallier ces limitations et assurer la synchronisation. SyncE est une
solution idale pour le transport de frquence sur un rseau bas Ethernet, du
fait qu'il supporte une fonction de transport de synchronisation similaire au
rseau SDH. SyncE a t standardis par IUT en coopration avec IEEE, et
l'IUT a publi trois recommandations portant sur SyncE, savoir le G.8261,
G.8262 et le G.8264.
IV.3.1.a - Description
Synchronous (SyncE) est une volution de l'Ethernet conventionnel dans le
sens o il supporte une fonction du transport de synchronisation avec une
haute prcision. En effet, tous les lments du SyncE sont synchroniss sur
une source d'horloge de rfrence tandis qu'en
70
SONATEL
Ethernet conventionnel les quipements fonctionnent juste en mode Free
Running du fait qu'ils ne disposent pas de rfrence d'horloge. C'est cela qui
cause surtout les PVD des paquets du fait qu'il a une diffrence notoire de la
prcision de synchronisation : 100 ppm14 en Ethernet conventionnel pour 4.6
ppm en SyncE. Cependant, tous les lments SyncE doivent fonctionner avec
des interfaces Ethernet fonctionnant en transmission continue15 car SyncE se

base sur la couche physique pour le transfert de l'horloge en se basant sur le
bit-time qui dsigne le temps mis pour transmettre un bit.
Le mcanisme de fonctionnement du SyncE est le mme que pour le
rseau de synchronisation SDH. Il utilise les mmes spcifications d'horloge,
du fait que la mme chane de rfrence du rseau de synchronisation SDH
(Figure 36) a t aussi dfinie pour le SyncE dans la recommandation de l'IUT
G.803 la seule diffrence que les lments SEC du SDH seront remplacs
par les EEC (Ethernet Element Clock). Cependant les mmes PRC et SSU
sont utiliss au niveau de chaque type de rseau de synchronisation.
Les EEC du SyncE ainsi que les SEC du SDH rpondent tous deux aux
exigences de limitations de gigues sur les interfaces de sortie comme elles
ont t dfinies dans la recommandation de l'IUT G.823.
IV.3.1.b - Rseau de synchronisation

unifi
Le point important soulever sur l'utilisation du rseau de synchronisation
SyncE sur un rseau bas Ethernet, c'est qu'il se marie bien avec le rseau
de synchronisation SDH du fait que les mmes messages de statut de
synchronisation (SSM) sont utiliss. Pour rappel, le SSM contient le niveau de
qualit d'horloge pour chaque quipement de la chane de distribution avec
l'utilisation d'un message spcial, dit DNU utilis en cas de rupture de liens ou
de source d'horloge perdue.
Au niveau du SyncE, les messages de statut de synchronisation fonctionnent
de la mme manire que ceux du rseau SDH. La seule diffrence rside sur
la forme des paquets. Au niveau SDH les SSM sont contenus dans la trame
SDH (MSOH), tandis que SyncE utilise l'ESMC (Ethernet Synchronization
Messaging Channel) qui consiste en des trames Ethernet spciales telles
qu'elles ont t dfinies sur la spcification de l'IUT G.8264/Y.1364.
Au vu des nombreuses similarits entre SyncE et le rseau de
synchronisation SDH, et surtout que les architectures soient les mmes
partout, il est alors possible que le rseau de
14 PPM : Partie par million, une unit souvent utilise lorsque le

pourcentage est infrieur 0,01%.
( http://fr.wikipedia.org/wiki/Partie_par_million)
15
Full Duplex Ethernet avec 100Base-TX, 1000BaseT, 2Base-TL, 100Pass-TS
71
SONATEL
synchronisation SDH soit combin avec le rseau de synchronisation SyncE
pour former ainsi un rseau de synchronisation unifi. La figure qui suit illustre
l'architecture d'un rseau de synchronisation SyncE combin au SDH.
Figure 38: Rseau de Synchronisation SDH et SyncE unifi

Comme nous pouvons le voir sur la figure 38, le rseau de synchronisation
SDH peut tre uni au rseau de synchronisation SyncE moyennant des
quipements hybrides disposant aussi bien d'interfaces ATM que d'interfaces
Ethernet. Le rseau de synchronisation unifi est possible, car les
spcifications sur les SEC sont les mmes que sur les EEC du SyncE et les
EMSC du SyncE acheminent les mmes informations que le SSM du SDH.
Le SyncE est une solution idale pour une bonne synchronisation, car elle
combine le rapport cot-efficacit d'Ethernet et la capacit de distribution de
synchronisation du rseau SDH. L'avantage qu'a le SyncE sur le standard
Ethernet c'est que les Node B seront synchroniss sans variation de dlai des
paquets (PVD) au sein du rseau IP ce qui rsout ainsi le problme de
distribution de synchronisation dans le contexte d'un rseau commutation
de paquets fonctionnant en mode asynchrone.
72
SONATEL
73
Instabilits de l'interface Iub et QoS dans l'UTRAN de la SONATEL
IV.3.2 - Network Timing Reference

Le NTR est une mthode trs prcise normalise pour la distribution de
frquence sur le dernier kilomtre bas sur la technologie DSL, telle le
SHDSL. Ainsi, au lieu de se baser sur une rfrence d'horloge externe
comme le PRC, cette approche consiste utiliser le Network Timing
Reference au niveau des DSLAM supportant cette fonctionnalit. Ainsi
l'horloge de rfrence sera envoye par le DSLAM qui se chargera de
mapper l'information d'horloge de rfrence sur le SHDSL pour les
modems SHDSL distants au niveau des Node B. Cela fournit une bonne
synchronisation des Node B.
Quand bien mme l'utilisation du NTR n'est pas exige dans la
recommandation de l'IUT G.991.2, la plupart des nouveaux DSLAM
supporte cette fonctionnalit. Cela reprsente une solution viable pour

une meilleure synchronisation au niveau DSL. Cependant, dans le cas
ou les DSLAM ne supportent pas la fonctionnalit NTR, il va falloir
utiliser une rfrence d'horloge externe. Il est important de souligner
que l'utilisation du NTR n'exclu pas l'utilisation d'autres moyens de
distribution de l'horloge au sein du rseau, car le NTR est surtout destin
pour assurer une source de rfrence d'horloge prcise en vue d'assurer
la synchronisation au niveau SHDSL. NTR fournit une haute prcision
d'horloge avec une prcision de 32 ppm. Pour une meilleure perception,
la figure 39 illustre le principe du Network Timing Reference.
Figure 39: Distribution de l'horloge sur SHDSL avec NTR

IV.3.3 - SDH NG (Next Generation)
Dans un tout autre registre, il est connu que le SDH est rput pour le
transport de la voix mais n'est pas adapt au transport des donnes. De
ce fait, les oprateurs disposent d'une part un rseau SDH pour le
transport de la voix et de l'autre ct un rseau commutation de
paquets pour le transport des donnes. Quand bien mme la migration
vers une infrastructure Tout-IP est d'actualit, elle se fera de faon
graduelle jusqu' maturit long terme.
SONATEL
Cependant, dans le mme contexte une alternative se prsente comme tant
une volution dans le court terme pour permettre aux oprateurs qui ont bti
leur fortune sur le SDH d'voluer vers l'Ethernet. En effet, les rseaux SDH
sont largement dploys de par le monde et la plupart des oprateurs se sont
abondement quips en SDH qui se marie mal avec l'Ethernet, et ils ne sont
pas prts d'abandonner cette technologie. Cela constitue d'une certaine

manire une rsistance vers une architecture tout IP car cette technologie
n'est pas prte de disparatre. Ainsi le Synchronous Digital Hierarchy Next
Generation est un moyen de permettre aux rseaux SDH traditionnels de
s'adapter l'environnement nouveau bas sur Ethernet.
Le Synchronous Digital Hierarchy Next Generation, ou SDH NG pour faire
court, est une volution du SDH traditionnel grce laquelle il est possible
d'encapsuler Ethernet dans SDH. Il se charge de pallier l'inefficacit et aux
lacunes qu'a le SDH traditionnel pour le transport de donnes en paquet. Le
SDH NG s'appuie sur trois mcanismes : l'encapsulation, la concatnation
virtuelle et la gestion dynamique de la bande passante.
IV.3.3.a - Encapsulation
L'encapsulation reprsente la premire tape pour le transport des trafics
Ethernet sur SDH. Elle est effectue par le protocole GFP (General Framing
Protocol) qui a t dfini dans la spcification de l'IUT G.7041/Y.1303.
Le GFP est une procdure d'encapsulation robuste pour le transport de
donnes en paquets sur un rseau SDH. GFP offre deux modes
d'encapsulation savoir le GFP-Transparent et le GFP-Framed, qui sont tous
deux utiliss en fonction du type de trafic reu. Le GFP-Transparent est utilis
dans l'optique d'encapsuler en paquets de tailles constantes contrairement au
GFP-Framed qui se charge d'encapsuler en paquets de tailles variables. Le
GFP-Framed est surtout adapt au transport des trafics Ethernet.
IV.3.3.b - Concatnation virtuelle

Au niveau de la concatnation virtuelle, ou VCAT pour faire court, les flux de
trafics sont spars en VC (Virtual containers) qui seront routs
indpendamment en suivant plusieurs voies VC au coeur du rseau SDH.
Une fois arrivs destination, les VC seront rassembls pour reconstituer les
flux de trafics de dpart. L'ensemble des VC routs sont aussi appels VCG
(Virtual Containers Group). La concatnation virtuelle est seulement utilise
au niveau des noeuds SDH NG metteurs/rcepteurs.
74
SONATEL
IV.3.3.c - Gestion dynamique de la

bande passante
La gestion dynamique de la bande passante est assure par le protocole
LCAS (Link Capacity Asdjustment Scheme). Tel qu'il a t dfini dans la
spcification de l'IUT G.7041/Y.1305, LCAS se charge de modifier
dynamiquement la bande passante en fonction du nombre de VC allous pour
chaque flux de trafic. De ce fait, pour un client disposant d'une bande
passante plus leve, des VC supplmentaires seront ajoutes et le protocole
LCAS se chargera d'ajuster dynamiquement le dbit des VC allous aux flux
de trafic du client. Le schma qui suit illustre un exemple de transport d'un flux
de trafic Ethernet suivant les mcanismes du SDH NG voqus
prcdemment.
75
Figure 40: Transport d'un flux de trafic Ethernet sur SDH NG.
SDH NG fournit un bon rapport efficacit-cots du fait qu'il y ait une
amlioration significative sur la faon dont la bande passante est gre, et
cela est bnfique pour l'oprateur qui dispose ainsi d'un moyen de
transporter aussi bien la voix que les donnes sur une mme infrastructure.
Concernant la distribution d'horloge, le SDH NG peut non seulement
supporter SyncE mais aussi la distribution de la synchronisation base sur le
SDH traditionnel, du fait que les noeuds SDH NG peuvent aussi bien
transporter les trafics Ethernet que les trafics ATM. En combinant GFP, VCAT
et LCAS, les oprateurs ont ainsi un moyen plus efficace d'optimiser leurs
rseaux SDH en remplaant uniquement les noeuds du rseau SDH existants
par des noeuds SDH NG et d'voluer ainsi vers un environnement Ethernet.
Ces technologies permettent un acheminement sans heurts et extrmement
prcis du trafic 3G sur le transport de paquets, garantissant des priorits QoS
pour le trafic d'horloge et rpondant aux exigences strictes du transport
mobile, y compris une haute prcision des frquences.
SONATEL
Nous avons d'avoir fait voir dans ce chapitre la faon dont la synchronisation
est effectue au niveau de l'interface Iub de la SONATEL avant de voir les
instabilits lies cette dernire, notamment la perte de synchronisation.
Nous avons tudi par la suite les causes lies cette perte de
synchronisation et les solutions viables qui permettront de pallier cette
inconstance pour l'amlioration de la qualit de service du rseau. Par la
suite, nous nous sommes penchs sur des perspectives d'avenir pour
prvenir au mieux la perte de synchronisation. Dans le mme contexte, avec
la migration vers l'architecture Tout-IP qui est d'actualit, nous avons fait
focus sur une plausible volution du rseau SDH qui ne fera que faciliter dans
l'avenir l'implmentation d'un rseau de synchronisation unique bas sur un
environnement Ethernet.
76
Conclusion
L'objectif de cette tude, a t d'apporter des lments de rponses sur la
gestion des instabilits de l'interface Iub, et ceci dans le but d'amliorer la
qualit de service du rseau.
Il parait vident que l'accent a t port sur la notion mme de l'interface Iub
en la considrant comme le matre mot de cette tude, dans le sens o ses
vicissitudes voques au niveau de la problmatique sont lies la perte de
synchronisation. Telle qu'elle a t souleve dans cette tude, une bonne
synchronisation entre les lments de l'interface Iub demeure essentielle pour
l'acheminement des donnes jusqu'aux clients, et ce de faon effective. Du
fait que les inconstances lies la synchronisation sont, quelque peu,
prjudiciables la qualit de service, et pour y remdier, une tude des
solutions viables pour une synchronisation stable a t faite cet effet.
Ce mmoire, bien que men son terme, est loin d'avoir t sans difficults,
notamment concernant les recherches effectues en vue d'apprhender la
faon dont la synchronisation serait adapt sur un rseau bas IP qui s'avre
tre inadapt pour le transport des signaux de synchronisation. En effet, de
nos jours, force est de constater que la technologie Ethernet se met au devant
de la scne avec la convergence IP. Ainsi il a aussi t vu dans cette tude
des perspectives d'avenir qui permettront de mettre en place un rseau de
synchronisation stable dans un environnement purement bas sur la
technologie Ethernet, tel le rseau mobile de quatrime gnration LTE (Long
Terme Evolution).
Il est vident que les solutions souleves dans ce mmoire ne sont pas
dfinitives, du fait qu'avec l'avance exponentielle des technologies d'autres
alternatives, certainement meilleures, feront leur apparition. Ce travail, comme
toute oeuvre humaine, prsente indniablement des imperfections, cependant
il m'a permis d'approfondir non seulement mes connaissances sur la collecte
mobile, mais m'a aussi permis de cerner la notion de rseau de
synchronisation. Durant le stage, j'ai eu la chance de mettre en pratique mes
connaissances thoriques acquises durant ma formation et de me familiariser
ainsi avec les outils du rseau. Dans le mme contexte, en passant de la
supervision radio aux interventions sur le terrain, notamment avec la
maintenance curative et prventive, j'ai pu voir, concrtement, comment les
lments du rseau d'accs interagissent entre eux ainsi que les difficults
lies au milieu professionnel. Ce stage fut une exprience professionnelle

enrichissante qui m'a permis de dvelopper un esprit d'analyse et de travail
en quipe qui sont des qualits essentielles pour une future carrire
professionnelle.
77
SONATEL
Mmoire de fin de cycle - Master 2 Liste des acronymes
Liste des acronymes
A
AAL : ATM Adaptation Layer
AAL2 : ATM Adaptation Layer - type 2 AAL5 : ATM Adaptation Layer - type
5 ADM: Add/Drop Multiplexer
ALCAP: Access Link Control Application Part
ATM: Asynchronous Transfer Mode AuC: Authentication Center
B
BBU: Base Band Unit
BCCH: Broadcast Control Channel BCH: Broadcast Channel
BMC: Broadcast Multicast Control
C
CCCH: Common Control Channel
CDMA: Code Division Multiple Access
CID: Channel ID
CN: Core Network

CP: Common Part
CS: Circuit Switched
CS: Convergence Sublayer
CPCS: Common Part Convergence Sublayer
i
SONATEL
CTCH: Common Traffic Channel D
DCCH: Dedicated Control Channel DCH: Dedicated Channel
DSCH: Dedicated Shared Channel DTCH: Dedicated Traffic Channel
F
FACH: Forward Access Channel
FDD: Frequency Division Duplex
FP: Frame Protocol
FP-CCH: Frame Protocol for Common Channel
FP-DCH: Frame Protocol for Dedicated Channel
FH: Faisceau Hertzien
G
GGSN: Gateway GPRS Support Node GPRS: General Packet Radio

Service GPS: Global Positioning System GSM: Global System for
Mobile GOUa: Gigabit Optical Unit version A
H
HLR: Home Location Register
HSDPA: High Speed Downlink Packet Access HSUPA: High Speed Uplink
Packet Access
ii
SONATEL
I
IEEE: Institute of Electrical and Electronics Engineers IETF: Internet
Engineering Task Force
IP: Internet Protocol
L
LTE: Long Term Evolution
M
MAC: Medium Access Control M2000: Manager 2000
ME: Mobile Equipment
MPLS: Multi-Protocol Label Switching
MPR: Microwave Packet Radio
MPT: Microwave Packet Transport MSS: Microwave Service Switch
N
NBAP: Node B Application Part NNI: Network-Network Interface
O
OMU: Operation and Maintenance Unit Version a OSI: Open Systems
Interconnection
P
PCH: Paging Channel
PDCP: Packet Data Convergence Protocol
iii
SONATEL
PDH: Plesiochronous Data Hierarchy
PSTN: Public Switched Telephone Network PSWE3: Pseudo Wire Emulation
Edge to Edge
Q
QoS: Quality of Service
S
SPUa: Signaling Processing Unit Version A
SCUa: Switching and Control Unit Version A
R
RACH: Random Access Channel RLC: Radio Resource Control
RNC: Radio Network Controller RNL: Radio Network Layer RNS: Radio
Network Subsystem RRC: Radio Resource Control RRU:Radio Remote Unit
S
SAR: Segmentation and Reassembly
SCTP: Stream Control Transmission Protocol
SDH: Synchronous Data Hierarchy
SGSN: Serving GPRS Support Node
SMS: Short Message Service
SONET: Synchronous Optical Network
iv
SONATEL
SSCOP: Service Specific Connexion Oriented Protocol SSCF: Service
Specific Coordination Fonction SSCS: Service Specific Convergence
Sublayer STM: Synchronous Transport Module
T
TDD: Time Division Duplex TNL: Transport Network Layer TRCH: Traffic
Channel
U
UDP: User Datagram Protocol
UE: User Equipment
UBFA: Universal BBU FAN Unit type A
UELP: Universal E1T1 Lighting Protection

UNI: User-Network Interface
UTRP: Universal Transmission Processing Unit
UPEU: Universal Power and Environnement Interface Unit
USIM: UMTS Subscriber Identity Module
UMTS: Universal Mobile Telecommunication System
UTRAN: Universal Terrestrial Radio Access Network
V
VC: Virtual Channel
VCI: Virtual Channel Identifier VPI: Virtual Path Identifier
v
SONATEL
VLAN: Virtual Local Area Network
W
W-CDMA: Wide band CDMA
WBBP: WCDMA Base Band Processing Unit
WMPT: WCDMA Main Processing and Transmission Unit

Are Faire

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Are Faire

Uploaded by

Copyright:

Available Formats

I.3.2.

A - Les couches de l'interface Uu

I.3.2.B - Les canaux de l'interface Uu

I.3.2.B. a- Les canaux logiques

I.3.2.B. b - Les canaux de transport

Downlink Shared Channel (DSCH) : C'est un canal utilis uniquement sur la

I.3.2.B. c - Les canaux physiques

DPCCH (Dedicated Physical Control Channel) : C'est un canal utilis dans le

Gestion des instabilits Iub et qualit de service sur l'accs 3G de la

I.3.3.b - Signaling Bearer

I.3.3.c - Application Protocol

I.3.3.d - Data Stream

Chapitre II : Gnralits sur l'interface Iub

II.1.1.a - La Commutation de cellules

dans l'en-tte de chaque cellule. Ci-dessous dcrit la structure gnrale d'une

Figure 10: Structure gnrale d'une cellule ATM.

II.1.1.b - Le modle de rfrence

virtuels, l'ajout ou le retrait de l'en-tte des cellules et la translation des

Gestion des instabilits Iub et qualit de service sur l'accs 3G de la

Figure 11: Structure du modle de rfrence d'ATM

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface Iub

Mamadou Lamine NDIAYE

Figure 12: Format de base d'une adresse IPv4

- dessous illustre le format de

La version 6 de l'adresse IP est exige au niveau de l'UTRAN, la version

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface

Figure 13: Principe du routage IP

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface

structure en couches dfini pour les interfaces rseaux de l'UTRAN, trait

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface

La structure de la couche rseau de transport base sur ATM fait appel

II.2.1.A .b - La couche ATM

multiplexage des cellules ATM en fonction des VPI/VCI correspondants. Elle

Mamadou Lamine NDIAYE

Figure 16: Principe de segmentation en cellules ATM

2 PDU : Protocol Data Unit reprsente une unit de donnes spcifique

fournit une livraison garantie. A cet effet, SCCOP a t introduit juste au

Au niveau du CPCS, les bits de bourrage ou Padding servent faciliter

le SSCOP aux besoins de la couche de signalisation ALCAP, mais aussi pour

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface

Figure 17: Structure en couches du SAAL-UNI.

II.2.1.B - Transport sur IP

Figure 18: Structure en couches de l'interface Iub base sur IP

II.2.1.B .a - La couche Physique

II.2.2 - La couche rseau radio

II.2.2.b - Frame Protocol

Gestion des instabilits Iub et qualit de service sur l'accs 3G de la

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface Iub

Mamadou Lamine NDIAYE

II.2.3.a - Dual Stack

Figure 19: Interfonctionnement ATM et IP avec Dual Stack

II.2.3.b - TNL IWU

Mmoire de fin de cycle - Master 2 Chapitre II - Gnralits sur l'interface Iub

Mamadou Lamine NDIAYE

Figure 20: Interfonctionnement ATM et IP avec IWU

Chapitre III : L'interface Iub dans l'UTRAN de la SONATEL

Dans le rseau d'accs 3G de la SONATEL, l'interface Iub existe sous

Mmoire de fin de cycle - Master 2 Chapitre III

Mamadou Lamine NDIAYE L'interface Iub dans l'UTRAN de la SONATEL

III.1.1.a - Les cartes du BBU3900

Figure 21: Les diffrentes cartes du BBU3900

Figure 22: Le DBS3900 de Huawe.

Figure 23: Le BSC6810 de Huawe

III.1.2.a - Les cartes du RNC BSC6810