Ministre de lenseignement Ministre de la poste et des

suprieur et de la recherche technologies de linformation et

scientifique de la communication

Institut National des

Tlcommunications et des

Technologies de lInformation
et de la Communication

Projet de fin dtudes Pour lobtention du

Diplme dIngnieur
DEtat en Tlcommunications.

Thme:

Network Sharing

Prsent par :
Mlle AHMED FOUATIH Hind
Mr. HATTAB Fethi
Encadr par :
Mr. O. KAID OMAR
Prsident : Mr. A. AZIZOU
Examinateurs:
Mr. L. BENSAADA
Mr. A. MAZOUZI

Promotion: IGE 36
Anne Universitaire : 2015- 2016

1
Rsum
Actuellement, les oprateurs des tlcommunications sont en concurrence pour mettre
la disposition des utilisateurs des services divers, tout en optimisant les cots CAPEX et
OPEX engendrs qui continuent augmenter dun standard un autre. En contrepartie, la
rentabilit de certains sites ruraux est marginale, de mme les capacits des quipements
dploys ne sont jamais exploites au maximum. Par consquent, les oprateurs optent pour
de nouvelles solutions afin de rduire ces cots massifs toute en augmentant la couverture et
en rpondant aux demandes de bande passante. Le Network sharing est une perspective
qui a t introduite comme une approche par les oprateurs pour tre apte suivre lchelle du
march de dveloppement.Cette nouvelle approche va lencontre de la culture de loprateur
du rseau, car il sagit de ne plus se bas sur le rseau des tlcommunications comme un
argument cl la proposition de la valeur des tlcommunications, mais de mettre laccent sur
la consommation financire du rseau mobile. Le Network sharing a pour vocation de
partager les quipements des tlcommunications rseau entre plusieurs oprateurs Notre
tude sest base principalement sur le MORAN, nous avons labor le processus
dintgration des interfaces, par la suite un dimensionnement de la NodeB et du RNC est
ralis selon les principes de NSN, dans le but de pouvoir maintenir le rseau supporter le
trafic de deux oprateurs Ooredoo et Djezzy. A lissue de notre travail, on a pu sortir avec des
recommandations adquates lies aux ventuels problmes rencontrs.

Mots-cls : MORAN (Multi-Operator Radio Access Network), Dimensioning, Optimisation,

Processing Set, Channel Element (CE), HSDPA Scheduler, HSUPA Scheduler, traffic mixte.

2
Abstract
Currently, operators are competing for providing various services to
users, while optimizing CAPEX and OPEX costs continue to increase from
one standard to another. In return, the profitability of some rural sites is
marginal, and the capacity of its equipment deployed is never fully
exploited. Therefore, operators are opting for new solutions to reduce
these massive costs all increasing coverage and meeting the bandwidth
demands.Network sharing is a perspective that was introduced as an
approach by operators to be able to follow the development scale market.
This new approach goes against the culture of the network operator,
because it is no longer based on the telecommunications network as a key
argument for the value proposition of telecommunications, but to focus on
financial consumer mobile network. Le Network sharing aims to share
network telecom equipment between several operators. Our study is
based mainly on the MORAN; we developed the interfaces integration
process, then, a dimensioning of the NodeB and RNC is performed
according to the principles of NSN, in order to maintain the network to
handle the traffic of two operators Ooredoo and Djezzy. At the end of our
work, we have come out with appropriate recommendations related to
problems encountered.

Keywords:MORAN (Multi-Operator Radio Access Network), Dimensioning, Optimization,

Processing Set, Channel Element (CE), HSDPA Scheduler, HSUPA Scheduler, mixed traffic.

3
Table des matires
Rsum.........................................................................................................................................i

Abstract........................................................................................................................................ii

Table des matires......................................................................................................................iii

Liste des tableaux........................................................................................................................v

Liste des figures..........................................................................................................................vi

Liste des sigles..........................................................................................................................viii

Ddicace......................................................................................................................................ii

Remerciements...........................................................................................................................iii

On rend grce Dieu pour tous les bienfaits dont il nous a combls.............iii

Introduction gnrale...................................................................................................................1

CHAPITRE 1 : Architecture du rseau UMTS............................................................................2

Introduction..............................................................................................................................2
1.1 Architecture du rseau UMTS...........................................................................................2
1.1.1 Le rseau daccs UTRAN.........................................................................................3
1.2 La signalisation SIGTRAN................................................................................................7
1.3 Les interfacesbases sur la signalisation SIGTRAN lUTRAN........................................8
Conclusion.................................................................................................................................10

CHAPITRE 2 : La solution sharing...........................................................................................11

Introduction............................................................................................................................11
2.1 Dfinition.........................................................................................................................12
2.2 Les avantages de la solution sharing................................................................................12
2.3 Lvolution du sharing.....................................................................................................12
2.4 Les types de sharing.........................................................................................................13
2.4.1 Sharing passif............................................................................................................13
2.4.2 Sharing actif..............................................................................................................14
2.5 La Solution NSN pour RAN sharing...............................................................................17
4
Conclusion.................................................................................................................................17

CHAPITRE 3 : Intgration et dimensionnement de la solution NSN RAN Sharing................18

Introduction................................................................................................................................18

3.1 Intgration du RNC..........................................................................................................18

3.1.1 Les tapes de cration de linterface Iu-PS...............................................................19
3.1.2 La cration des Objets IUO (IU-Operators)............................................................20
3.2 Dimensionnement............................................................................................................22
3.2.1 Principes gnraux de dimensionnement..................................................................22
3.2.2 Le dimensionnement du NodeB..............................................................................22
3.2.3 Le dimensionnement du RNC..................................................................................31
Conclusion.................................................................................................................................36

CHAPITRE 4 : tude du dimensionnement du rseau daccs.................................................37

Introduction............................................................................................................................37
4.1 Application.......................................................................................................................37
4.1.2 Les aspects traits dans lapplication........................................................................37
4.2 tude du trafic cumul dans les NodeBs partages.........................................................40
4.2.1 La rpartition des HSDPA processing sets................................................................40
4.2.2 La configuration initiale...........................................................................................41
4.2.3 Loptimisation des ressources...................................................................................44
4.3 Ltude dutrafic cumul des NodeB sur RNC.................................................................49
4.3.1 Le trafic HSUPA et HSDPA au niveau du RNC.......................................................49
4.3.2 Lvolution du trafic mixed dans le RNC...............................................................50
4.3.3La charge des units fonctionnelles (NPGEP, ICSU)................................................52
4.3.4 Les recommandations faites......................................................................................54
Conclusion.................................................................................................................................57

Conclusion gnrale...................................................................................................................58

Bibliographie................................................................................................................................i

5
Liste des tableaux
Tableau 1: Les units fonctionnelles du RNC............................................................................6
Tableau 2 : les types de configuration du LCG, System module Rel.3.........25
Tableau 3 : La capacit HSDPA scheduler...............................................................25
Tableau 4 : Le nombre dunits dans RNC2600 dans chaque step.....................32
Tableau 5 :Frame Protocol bit rates.................................................................................34
Tableau 6: Configuration optimise de couverture...................................................................55

6
Liste des figures
Figure 1 : Architecture du rseau UMTS...................................................................................3
Figure 2: Les modules de la NodeB de type Flexi Multiradio BTS.........................4
Figure 3: Architecture du RNC NSN..........................................................................................5
Figure 4 :Pile protocolaire de linterface Iub..............................................................................8
Figure 5: Pile protocolaire de linterface Iu................................................................................9
Figure 6: Pile protocolaire de linterface Iur..............................................................................9
Figure 7 : Le pourcentage de trafic cumul dans les zones urbaines et
rurales......................................................................................................................................11
Figure 8: Les solutions techniques du Network Sharing..........................................................13
Figure 9: Schma descriptif du sharing passif..........................................................................13
Figure 10: Backhaul sharing.....................................................................................................14
Figure 11: Schma descriptif du MORAN...............................................................................15
Figure 12: Schma descriptif du MOCN..................................................................................16
Figure 13: Schma descriptif sur lintgration du MORAN entre les deux oprateurs............18
Figure 14 : Objet IUO de Ooredoo....................................................................................21
Figure 15: Objet IUO de Djezzy...............................................................................................21
Figure 16 : Les services offerts par le systme module FSMF.................................................23
Figure 17 :Dimensionnement du RNC selon le throughput...................................33
Figure 18: Reprsentation des champs pour calculer de la rpartition de capacit..................38
Figure 19: La rpartition des processing sets entre HSDPA scheduler.....................................39
Figure 20: reprsentation des configurations possibles...........................................................40
Figure 21: La rpartition des processing set entre les HSDPA scheduler.................................41
Figure 22: La slection dune configuration pour rpartir la capacit entre deux LCG...........42
Figure 23 :le rsultat de la configuration tablie.....................................................................43
Figure 24: La saisie de configuration sur le BTS Manager......................................................43
Figure 25 :(a) : Nombre des subunits pour HSUPA (b) : Le taux dutilisation des subunits...44
Figure 26: La slection dune configuration selon la plage de CE demand...........................45
Figure 27: Le Nombre de subunits et CE ddis pour chaque LCG selon la configuration
50%,50%....................................................................................................................................46

7
Figure 28: Le nombre de CE ddi pour LCG2 aprs le changement du type de configuratio
...................................................................................................................................................47
Figure 29 :La rpartition de capacit aprs inversion des LCGs..............................................48
Figure 30 :(a) : Le nombre de subunits HSUPA, (b) : Le taux dutilisation de subunits
(HSUPA,R99)............................................................................................................................48
Figure 31 : Les subunits utiliss pour HSUPA avant et aprs optimisation............................49
Figure 32 : Le dbit du trafic HSUPA dans RNC Figure 33 : Le dbit du trafic HSDPA....50
Figure 34 :(a) : Le taux dvolution du trafic mixed (b) :Le taux de cellules oprationnelle. .51
Figure 35: Peak load des units NPGEP..................................................................................51
Figure 36 : Load des units ICSU.............................................................................................52
Figure 37 : Les sites grs par (a) : ICSU6, (b) : ICSU8.........................................................53
Figure 38: ICSU6_CPU............................................................................................................55
Figure 39 : ICSU Load aprs le changement de frquence......................................................56

8
Liste des sigles
AMR Adaptive Multi Rate
CAPEX CApital Expenditure
CCCH Common Control CHannel
CE Channel Element
DL, ULDownLink ,UpLink
DMCU Data and Macro
Combining Unit
DPC Destination Point Code
EDGE Enhanced Data Rate for GSM
Evolution
GE Gigabit Ethernet
GSM Global System for Mobile
Communications
GPRS General Packet Radio Service
ICSU Interface Control and Signaling Unit
IP Internet Protocol
KPI Key Performance Indicator
LCG Local Cell Group
LTE Long Term Evolution
MAC Medium Access Control
MCC Mobile Country Code
MNC Mobile Network Code
MOCN Multi Operator Core Network
MORAN Multi Operator Radio Access
Network
MNO Multi Network Operator
M3UA MTP3 User Adaptation
MXUMultipleXer Unit
NBAP NodeB Application Part
NE Network Element
NPGEP Network Processor Gigabit
Ethernet Protected
NRT Non Real Time
OMU Operation and Maintenance Unit
Diversity OPC Originating Point Code
OPEX OPerationalEXpenditure
PDCP Packet Data Control Protocol
RAB Radio Acces Bearer
RANAPRadio Network Application Part
RNSAP Radio Network Subsystem
Application Part
RLC Radio Link Control
RNC Radio Network Controller
RRC Radio Resource Control
RSMU Resource and Switch Management
Unit
SCCPSignaling Connection Control Part
SCTP Stream Control Transmission
Protocol
SIGTRAN Signaling Transport
SFU Switching Fabric Unit
SGSN Serving GPRS Support Node
SHO Soft Handover Overhead
SS7 Signaling System No.7
STP Signaling Transfer Point
SUSubUnit
TBU Timing and hardware Bus Unit
UE User Equipement
9
UMTS Universal Mobile UTRAN Universal Terrestrial Radio
Tlcommunication System Access Network
WDU Winchester Disk Unit

10
Ddicace
A qui je dois ce que je suis,

A mes parents, grce leurs tendres encouragements et leurs grands sacrifices, ils ont
pu crer le climat affectueux et propice la poursuite de mes tudes. Aucune ddicace ne
pourrait exprimer mon respect, ma considration et mes profonds sentiments envers eux. Je
prie le bon Dieu de les bnir, de veiller sur eux, en esprant quils seront toujours fiers de
moi.

A mes grands-parents, je vous ddie ce mmoire en tmoignage de gratitude destime

et dattachement. Puisse Dieu vous accorder sant, longue vie et prosprit.

A mes chres surs.

A ceux qui me sont chers et proches.

A tous ceux que jaime et qui maiment.

Ce mmoire leur est ddi

-AHMED FOUATIH Hind-

A mes chers respectueux

parents
Vraiment aucune ddicace ne saurait exprimer
mon attachement, mon amour et mon affectation

Avec un norme plaisir, un cur ouvert et une immense joie,

que je vous ddicace mon travail en tmoignage de tous vos sacrifices et limmense
Tendresses que vous mavez toujours su me combler Puisse dieux
Tout puissant vous garder et vous procurer sant et bonheur

A ma sur, mes frres Amine, Mohamed Nadjib et mon petit cousin Walid
Ainsi que Lotfi et Younes qui sans eux ce mmoire naurait pas vu le jour
A toutes les personnes qui maiment.
-HATTAB Fethi-

11
Remerciements

On rend grce Dieu pour tous les bienfaits dont il nous a combls.

On ne pourrait commencer ce rapport sans prsenter nos remerciements les plus sincres
notre Encadrant, Mr. KAID OMAR, enseignant lINTTIC, pour nous avoir guid jusqu'
son aboutissement.Nous le remercions pour sa confiance, son coute et le soutien qu'il nous a
tmoign tout au long de la ralisation de ce mmoire. Ses remarques et ses consignes ont t
pour nous d'un grand apport.

Nous tenons aussi remercier chaleureusement Mr. BOUHALLOUFA Lotfi et Mr. EL

HAMRI Younesde nous avoir propos ce thme et qui nont cess de nous guider et de nous
faire bnficier de leur grand savoir, nous leur sont trs reconnaissants du fond du cur. Que
le tout puissant vous guide dans vos projets futurs.

Nous tenant remercier galementMr CHAOUCH Abdelhafid de nous avoir permis de

raliser ce travail. Nous avons aussi tout au long de ce projet bnficie dun apport prcieux
de la part de Mr. MOSTEFA Mohamed Amine et toute lquipe BSS Operations Ooredoo,
ainsi que Mr.ADDA BELLOUFA.

Nous sommes reconnaissons davoir bnfici de la bndiction et du soutien moral de la part

de Nos familles.

Enfin, nous tenons aussi exprimer l'honneur qui nous est fait par les membres de jury en
acceptant d'valuer notre travail. Qu'ils trouvent ici notre reconnaissance et nos respects.

Finalement, merci toute personne qui nous a aids pour la ralisation de ce travail.

12
Introduction gnrale
Pendant les dernires dcennies, l'industrie des radio-mobile a connu des
dveloppements considrablesen termes des technologies de tlcommunications, notamment
avec l'apparition des rseaux cellulaires de troisime gnration UMTS (Universal Mobile
Telecommuncation System) jusquaux rseaux LTE-Advanced et la 5Gqui ont permis une
volution rapide de nouvelles techniques multimdias mobile.

Cependant, actuellement les exigences des mobiles en termes de bande passante

suivent une tendance quasiment exponentielle, toute en voulant avoir accs aux divers
services moindre cots, ce qui suscite des investissements colossaux poussant les oprateurs
ainsi que les fournisseurs de tlphonie mobile penser sur de nouvelles solutions afin de
soutenir les cots engendrer pour lapprovisionnement des nouvelles technologies.

Le Network sharing ou le partage dinfrastructures de rseaux mobiles dans les

tlcoms, est une pratique qui a t initi ds les annes 90 comme une approche par les
oprateurs pour suivrelchelle du march de dveloppement.Cette nouvelle approche va
lencontre de la culture de loprateur de rseau, car il sagit de ne plus se bas sur le rseau
de tlcommunications comme un argument cl la proposition de la valeur des
tlcommunications, mais de mettre laccent sur la consommation financire du rseau
mobile.

Dans ce prsent rapport, nous prsenterons dans le premier chapitre larchitecture du

rseau UMTS, plus particulirement les lments du rseau daccs dont on a dcrit le
Hardware utilis (FlexiMultiradioWCDMA BTS et RNC 2600 de NSN), ainsi la signalisation
SIGTRAN change sur les interfaces du RNC. Dans le chapitre qui suit, on voquera la
solution sharing. Le troisime chapitre consiste laborer le processus dintgration et de
dimensionnement de la Node B et du RNC. Ces diffrents points abords nous ont permis de
ralis notre tude de dimensionnement du rseau daccs de loprateur Ooredoo, aprs le
dploiement du sharing dans la wilaya de Relizaneavec loprateur Djezzy. Pour cela, nous
avons ralis une application permettant de faciliter le dimensionnement et loptimisation du
rseau daccs au niveau des NodeBs.

1
CHAPITRE 1 : Architecture du rseau UMTS

Introduction
LUMTS (Universal Mobile Tlcommunications System) est un systme de
communication de tlphonie mobile qui permet d'assurer lacontinuit des services tels que
ceux fournis par le GSM et ses volutions (GPRS et EDGE), et de supporter des services de
transmission de donnes en paquet, avec diffrentes qualit de service pour des systmes
mobiles d'accs internet.Le support des services multimdia tels que la visiophonie, le
transfert de fichiers, la navigation sur le Web et la voix, sont tous assurs avec un dbit
thorique maximal de 2 Mbits/s.

Dans ce chapitre, nous allons voir larchitecture du rseau UMTS, plus prcisment les
entits du rseau daccs. Par la suite, on invoquera la signalisation change entre les
diffrentes interfaces de communication de lUTRAN.

1.1 Architecture du rseau UMTS

Comme chaque standard dun rseau mobile, lUMTS est compos de deux sous-
systmes (Figure 1) :

Le rseau daccs UTRAN (UMTS Terrestrial Radio Acces Network)

Le rseau cur CN (Core Network)qui est compos de trois parties :

Le domaine CS (Circuit Switched).

Le domaine PS (Packet Switched).
Les lments communs aux domaines PS et CS, savoir HLR, AuC et EIR.

2
 Figure 1 : Architecture du rseau UMTS

1.1.1 Le rseau daccs UTRAN

Le rseau daccs UTRAN a pour fonction principale lacheminement

des messages entre lusager et le rseau cur. Il est constitu dun ensemble de
RNCs (Radio Network Controller) auquel sont attaches une ou plusieurs NodeBs.

1.1.1.1 Description de la FlexiMultiradio WCDMA BTS

Cest une NodeB modulaire, trs compacte avec une grande capacit de couverture,
elle peut tre utilise dans plusieurs installationsindoor et outdoor. Cette station de base
consiste des modules suivants : (Figure 2)

3
 Figure 2: Les modules de la NodeB de type FlexiMultiradio BTS

RF Module: Ce module est compos des metteurs et rcepteurs RF, charg de

traitements radio frquences et le control de lignes dantennes. On peut avoir jusqu
trois RF modules par NodeB.

BTS Systme Module : Il est responsable du traitement bande de base, les interfaces
de transport, les fonctions de lO&M et la distribution de puissance.

Baseband Extension Module: Cette entit est une extension du

SystemModule selon la capacit requise[1].

1.1.1.2 Description du RNC 2600

Le RNC2600 est bas sur la plate-forme IPA2800qui rpond aux besoins croissants en
capacit pour le traitement des services hauts dbits[2].

Il est compos dune ou deux armoires (Figure 3), selon les exigences de la capacit.
Chaque armoire contient quatre subracks (blocs) dont ils comportent un certain nombre de
plug-in units (units fonctionnelles) rparties dans les groupes suivants:

4
 Fonctions d'interface rseau
Fonctions de commutation et de multiplexage
Fonctions de plan de contrle
Fonctions de plan d'utilisateur
Fonctions dO & M

Figure 3:Architecture du RNC NSN

5
 Unit fonctionnelle Fonction

OMU (Operating Remplit les fonctions de base de maintenance du systme telles que la
&Maintenance Unit) configuration du matriel et le traitement des systmes d'alarmes.

ICSU(Interface Control LICSU soccupe du traitement et lacheminement des messages de

and Signalling Unit) signalisation (RNSAP, RANAP et NBAP) dans le rseau daccs.

DMCU (Data and Macro Cette unit prend en charge le trafic du plan utilisateur Parmi les taches
diversity Combining effectues sont : Macro diversitycombinig, Outer loop power control et
Unit) ciphering.

RSMU (Resources Elle est responsable de la gestion des ressources telles que le control des
and Switch connexions, la surveillance, la gestion et le traitement de logiciels des
Management Unit) cartes DMCU

SFU (Switching Fabric Elles ralisent les fonctions de commutation et de multiplexage over ATM
Unit)/ MXU (MultipleXer et permettent la communication interne du systme RNC.
Unit)

TSS/ TBU (Timing Charges de la distribution de la synchronisation lensemble des units

and hardware fonctionnelles
management Bus
Unit)

NPGEP (Network Cest la Gateway des units fonctionnelles, contenant 2 ports GE (Gigabit
Processor Gigabit Ethernet) over IP, elle dtermine si le trafic entrant est destin aux cartes
Ethernet Protected) ICSU ou DMCU.

Tableau 1: Les units fonctionnelles du RNC

6
1.2 La signalisation SIGTRAN
La signalisation SIGTRAN (Signaling Transport) est change entre toutes les entits
partir de la NodeB jusqu'au rseau cur.

Le SIGTRAN dfinit une architecture pour le transport de la signalisation temps rel

travers le rseau IP. Il dsigne un protocole de transport fiable appel SCTP (Stream Control
Transmission Protocol).

La couche SCTP

Le protocole SCTP est un protocole TCP de nouvelle gnration capable de fournir une
vitesse et une fiabilit suffisante pour la signalisation. Lavantage de ce protocole est le multi-
homing, c'est--dire quune extrmit SCTP appele end point est apte supporter plusieurs
adresses IP, contrairement au protocole TCP, qui spcifie une seule association (adresse IP,
numro de port), o chaque end point dune association SCTP transmet lautre end point une
liste dadresses IP accompagne dun seul numro de port.

M3-UA (MTP3 User Adaptation)

La couche dadaptation (user adaptation) permet dintgrer les protocoles de
signalisation SS7 dans le rseau IP.

La couche M3-UA assure la transmission des messages de signalisation SS7 comme

SCCP, en fournissant une interface MTP3 la couche suprieure. Elle permet aussi
aux entits disposant dun rseau SIGTRAN de partager une association SCTP.

La couche SCCP (Signaling Connection Control Part)

Cest un protocole de transport dans le rseau SS7, quivalent au protocole TCP dans internet,
il assure la continuit des fonctions effectues par la couche MTP3 (MTP3 User Adaptation)
pour le routage autonome de signalisation permettant de sadresser des applications bien
spcifiques[3].

1.3 Les interfacesbases sur la signalisation SIGTRAN lUTRAN

a) Linterface Iub
7
 Linterface Iub est prsente entre la NodeB et le RNC auquel il est attach. Sa pile
protocolaire comme la montre la figure 4, comporte un message NBAP (NodeB
Application Part) dans la couche application permettant la gestion des liens et le contrle
des mesures radio.

NBAP

SCTP

IP

Ethernet-MAC

Ethernet-Phy

Figure 4 :Pile protocolaire de linterface Iub

b) Linterface Iu

Cette interface relie le rseau daccs au rseau cur, elle est dsigne par deux interfaces Iu-
CS et Iu-PS qui sont raccordes avec le MSC du domaine CS et le SGSN du domaine PS
respectivement. Ces deux interfaces partagent la mme pile protocolaire dans le plan control.
Le protocole RANAP (Radio Acces Network Application Part) spcifie les fonctions
principales de linterface Iu : (figure5)
Les gestions du tunnel daccs RAB (Radio Access Bearer).
Lacheminement des messages de paging.

RANAP

8
SCCP

M3-UA

SCTP

IP
Ethernet-Phy
Ethernet-MAC
 Figure 5:Pile protocolaire de linterface Iu

c) Linterface Iur

Linterface Iur gre la mobilit inter-RNC dans le cas de la macro-diversit de lUE (User
Equipment) et le soft handover entre deux NodeBs attaches diffrents RNCs.
Le protocole dapplication du plan de control est le RNSAP (Radio Network Subsystem
Application Part) qui assure ltablissement, le maintien et la libration des canaux entre
les RNCs[4].

RNSAP

SCCP

M3-UA

SCTP

IP

Ethernet-MAC

Ethernet-Phy

Figure 6:Pile protocolaire de linterface Iur

Conclusion
Dans ce chapitre introductif, nous avons prsent brivement larchitecture du rseau
UMTS, ainsi quune description du hardware NSN utiliss (FlexiMultiradio BTS et
9
RNC2600) dans le rseau daccs. Ensuite, on a dfini les piles protocolaires de la
signalisation SIGTRAN sur laquelle on va se baser, lors de lintgration du sharing.

Dans le chapitre qui suit, nous aborderons la solution sharing dune faon gnrale et
les raisons pour lesquelles on a pench vers cette approche.

CHAPITRE 2 : La solution sharing

Introduction
Actuellement, les oprateurs sont en concurrence pour mettre la disposition des
utilisateurs des services divers, tout en optimisant les cots (CAPEX, lis limplmentation
du rseau, et les cots dexploitation OPEX, comme la location des sites, les frais de licences
et la gestion du rseau) engendrs qui continuent augmenter dun standard un autre.

En contrepartie, la rentabilit de certains sites ruraux est marginale, de mme les

capacits de ses quipements dploys ne sont jamais exploites au maximum. Par
consquent, les oprateurs optent pour de nouvelles solutions afin de rduire ces cots massifs
toute en augmentant la couverture et en rpondant aux demandes de bande passante.

Lune des entraves des oprateurs concernant la rentabilit des sites est exprime
dans la figure ci-dessous par le trafic cumul dans les diffrentes zones en fonction du nombre
des sites. On constate daprs la courbe, quavec 50% des sites dploys dans les zones
urbaines et suburbaines, environ 90% du trafic est coul. En outre, 50% des sites restant
situs dans les zones rurales rcoltent moins de 10% de trafic. Le network sharing est de plus en
plus adopt comme une approche pour la rsolution de ces problmes.

10
 Figure 7 :Le pourcentage de trafic cumul dans les zones urbaines et
rurales

2.1 Dfinition
Network sharing cest quand deux ou plusieurs oprateurs se mettent en accord pour le
partage des ressources et dinfrastructures de leurs rseaux afin de rduire les cots (Capex,
Opex)du dploiement et du maintien du rseau[5].

2.2 Les avantages de la solution sharing

Les infrastructures sharing apportent divers profits potentiels :

Des profitspour les abonns permettant une grande disponibilit de services hauts
dbits, un dploiementrapide du rseau, ainsi quune diminution des cots de services.
Peut stimuler une concurrence entre les oprateurs, par exemple parla convergence de
la concentration sur la couverture vers la qualit de services, ou par la sous-traitance
pour les nouveaux entrants sinstaller facilement.
Laugmentation des bnfices environnementaux dus la diminution du nombre total
des sites, par la rduction de limpact visuel des rseaux mobiles. En plus, moins
dnergie consomme et puissance rayonne puisque les blocs dalimentation sont
partags.
Pooling du spectre RAN transmissionpermettent doptimiser les ressources radio
utilises.

11
 Partage des frais dintgrations de nouvelles gnrations[5].

2.3 Lvolution du sharing

Network Sharing peut prendre plusieurs formes, comme le montre la figure ci-dessous,
allant du sharing passif (cellsites et mats) au sharing actif : Radio Access Network sharing
(RAN sharing), Core Network sharing et Full Network sharing.Ces diffrentes formes varient
en fonction des besoins en termes de capacits et des cots dinvestissement.

Figure 8:Les solutions techniques du Network Sharing

2.4 Les types de sharing

2.4.1 Sharing passif

Le sharing passif est gnralement dfini comme un partage despace ou

dinfrastructure de support physique(Figure 9), qui ne ncessite pas de coordination
oprationnelle active entre les oprateurs.

12
 Figure 9: Schma descriptif du sharing passif

Le sharing passif est utilis comme une solution dans les cas suivants:
Les zones prsentant un potentiel commercial lev.
Une concurrence serre entre les MNOs (Multi Network Operator).
Un control total des entits actives de son propre rseau.
Grand besoin potentiel pour amliorer les performances des services offerts.

2.4.1.1 Backhaul sharing

Dans le cas o loprateur a une capacit disponible dans son backhaul (rseau de
transmission), il est faisable de partager cette capacit avec un autre oprateur. Cette situation
attire les nouveaux entrants qui ont besoin des ressources pour implmenter leurs
infrastructures. Par consquent, ils peuvent acqurir de la capacit, souvent de la part des
oprateurs existants. Dans ce type du sharing passif, en plus des sites et mts, nous avons
aussi le rseau de transmission qui est partag (cbles, fibres optiques, microwave), ce qui
est illustr par la figure suivante.

13
 Figure 10: Backhaul sharing

2.4.2 Sharing actif

Ce type de sharing consiste partagerles quipements actifs (les

entits du rseau daccs et du rseau cur) qui assurent la transmission
des communications. Il est caractris par un control partiel du rseau.

2.4.2.1 MORAN (Multi-Operator Radio Access Network)

MORAN (RAN sharing) est la forme la plus rentable du partage des rseaux daccs,
approuv dans les zones potentiel moyen. Il associe le partage des quipements actifs du
rseau daccs tels que les stations de bases (NodeB, BTS, eNodeB), le rseau de transmission
ainsi que les stations de control (BSC, RNC). Ces derniers sont connects avec le rseau cur
de chaque oprateur.

La distinction entre les cellules de chaque oprateur est gre par lutilisation des
bandes de frquences ddies pour chaque oprateur. Au niveau de rseau cur, loprateur
identifie les donnes qui lui sont destines grce des informations envoyes par le mobile
lors de son accs au Rseau partag[6].

Lutilisation du MORAN apporte des conomies considrables aux niveaux du Capex

et Opex vu que le nombre des quipements et des sites dcrot.

Figure 11: Schma descriptif du MORAN

La figure ci-dessus clarifie lefonctionnement du MORAN dans un rseau

deux oprateurs. Dans ce scnario, les deux oprateurs partagent tous les
lments du rseau daccs radio jusquau point dinterconnexion dans lequel le RNC de
14
loprateur accueillant, achemine le trafic des abonns vers leur propres rseau cur, en se
basant sur les paramtres MCC (Mobile
Country Code) et MNC (Mobile Network Code) configurs dans la NodeB et le RNC pour
avoirle control au niveau des cellules, ce qui permet la diffrentiation des services offerts par
les oprateurs.

2.4.2.2 MOCN (Multi-Operator Core Network)

En plus du partage du rseau daccs (RAN sharing), le spectre de frquence

dechaqueoprateur est aussi accessible aux diffrents abonns par la technique de pooling.
Cette solution permet de mieux exploiter les ressources radio.

Figure 12: Schma descriptif du MOCN

2.4.2.3 Full Network Sharing

Un oprateur repose sur un autre oprateur pour la couverture dune zone, en

partageant en plus du rseau daccs les entits du rseau cur (MGW, 3G-SGSN)tenant
uniquement les systmes HLR (Home Location Register), dauthentifications et de taxation
indpendants. Ce type de sharing est dploy dans les zones potentiel commercial faible o
les mmes services sont fournis. Cest une approche moindre cot qui permet de satisfaire
les exigences rglementaires de couverture.

Bien que techniquement il est possible pour les oprateurs de partager leurs
quipements, limplmentation peut tre complexe pour le sharing actif, a existe
particulirement quand les deux oprateurs exercent dj, contrairement au dploiement dun
nouvel oprateur[6].

15
 Les considrations qui doivent tre prises en comptes comprennent les difficults de
coordination lors de linter-working, les procdures oprationnelles et mcanismes de control,
ainsi que les effets indsirables sur la QoS dues la combinaison de diffrentes normes
dquipements dlivrs par diffrents fournisseurs.

2.5 La Solution NSN pour RAN sharing

Nokia Solutions and Networks (NSN) a t toujours le leader du networksharing, son
approche novatrice lui a permis doffrir au monde le premier et le plus grand rseau
commercial partag pour la 2G, WCDMA et LTE. Pour cela Nokia est le partenaire privilgi
pour la plupart des rseaux partags commerciaux existants du fait de lexprience riche
acquise dans limplmentation et la gestion du network sharing[7].

A prsent Nokia dveloppe la solution MNOs sharing en WCDMA en Algrie,

permettant le partage du rseau daccs (RAN) entre deux oprateurs par limplmentation
des nouvelles fonctionnalits (features), laide des logiciels mis jour, au niveau du radio
network controller (RNC) pour faciliter la phase dintgration du RNC nimporte quel
rseau cur.

Conclusion
Ce chapitre nous a permis davoir une ide gnrale sur la solution sharing, o on a
cit ses avantages et ses deux types utiliss, savoir : sharing passif et le sharing actif.
Par la suite, on a voqu les volutions du sharing actif du MORAN jusquau Full Network
sharing. On a pu dduire que chaque forme du sharing actif apporte des conomies pour les
oprateurs, mais rduit le contrle du rseau. Les oprateurs doivent penser la meilleure
solution pour ce projet, en tenant compte de lalignement technologique avec le partenaire
potentiel, le niveau de couverture et de control ncessaire, la marge des risques tolrable dans
la vision des rseaux.

En sappuyant sur le principe du MORAN, notre tude dans le prochain chapitre se

focalisera en premier lieu, sur lintgration du RNC 2600 NSN dun oprateur A avec un
autreoprateur B, par ltablissement de linterface Iu-PS avec le rseau cur de loprateur

16
B. En second lieu, un dimensionnement des ressources des entits partages (Node B et RNC)
pour quelles soient apte grer le trafic des deux oprateurs.

CHAPITRE 3 : Intgration et dimensionnement de la

solution NSN RAN Sharing

Introduction
Dans ce chapitre, nous nous focaliserons surtout sur lintgration et le
dimensionnement du rseau 3G,afin de dployer la solution MORAN au niveau du rseau
daccs dans le but doptimiserlexploitation de la capacit des entits qui vont tre partages.
Dansce sens, nous allonslaborer le processus de la migration vers le partage dinfrastructures
du rseau daccs. Il consiste de redimensionner la NodeB et le RNC selon le trafic demand,
tout en gardant comme contrainte lestimation du cot qui est un point primordiale dans le
sharing.

17
3.1 Intgration du RNC

Figure 13:Schma descriptif sur lintgration du MORAN entre les deux oprateurs

Le schma tabli dans la figure 13 montre larchitecture envisageable de lintgration

de RAN sharing au sein du rseau de chaque oprateur.Dans un sens, il y a ltablissement des
interfaces Iu-PS, Iu-CS et Iur entre le RNC de Ooredoo avec les entits du rseau de djezzy
(SGSN, MGW, RNC) respectivement, en passant par le bloc STP (Signaling Transfer Point)
pour viter la congestion dadressage entre les deux oprateurs. Dans lautre sens, la mme
procdure est effectue au niveau du RNC de Djezzy.

Dans la premire partie, on intgre le RNC du rseau dOoredoo avec le SGSN de

Djezzy, par ltablissement de linterface IU-PS pour le control plane. Lintgration est
excute sur le Netact, qui est un logiciel de configuration de NE (Network Element)
distance suivant un script crer laide des commandes MML (Man-Machine Language).

18
3.1.1 Les tapes de cration de linterface Iu-PS
Les tapes de cration de linterface IU-PS de RNC Ooredoo vers le rseau cur de Djezzy,
se rfrent sur la pile protocolaire dfinie pour linterface IU-PS.

La phase prliminaire consiste :

1. Identifier les units de signalisation sur lesquelles on intgre linterface dans le RNC :
ICSU, NPGEP laide de la commande ZDOI .

2. Crer des interfaces IPoA (IP over ATM), la connexion interne dans le
RNC est base sur ATM, laide de la commande ZQMC .

Couche Ethernet :

Cration des VLAN (Virtual Local Area Network) au niveau des ports GE sur linterface du
NPGEP pour assurer la diversit dacheminement laide de la commande ZQRM .

Couche IP :
1. Assignation des adresses IP logiques pour les interfaces, AA pour
ICSU, et IFAI dans NPGEP laide de la commande ZQRM

2. Cration des static routes entre les units ICSU, NPGEP laide de la
commande ZQKC .

Couche SCTP:
1. Cration dune dassociation set, laide de la commande ZYOC

2. Lajout des associations SCTP dans Association set.

3. Cration dassociation en spcifiant @IP Source (primaire/secondaire), numro de

port et @IP Destination (primaire/secondaire) avec numro de port, laide de la
commande ZYOP

La couche M3-UA
1. La cration de Signaling Link Set qui encapsule lassociation set, et
dsigne les SPCs (Signaling Point Code) pour chaque signaling point,
ainsi que la configuration de certains paramtres tels que national
network number pour caractriser le type de rseau sur lequel
linterface est configure.

19
 2. Cration de signaling route set, en spcifiant les OPC (Originating Point Code) et DPC
(Destination Point Code) pour la liaison de signalisation et la QoS sur les liens,
laide de la commande ZNRC .

La couche SCCP :
Lajout dun signaleur SCCP permet de dfinir la destination finale, en sadressant un
subsystem dans le signaling point pour dterminer le type de message chang entre les deux
extrmits (RNSAP, RANAP), laide de la commande ZNFB

3.1.2 La cration des Objets IUO (IU-Operators)

Lobjet IUO est un paramtre utilis dans le MORAN qui permet de spcifier les
interfaces Iu intgrer selon loprateur auquel le RNC est li, il est bas sur les paramtres
MCC et MNC. A chaque fois que LICSU dsire tablir une interface Iu que ce soit, Iur, Iu-CS
ou Iu-PS, elle fait appel aux objets dIUO pour caractriser linterface de chaque oprateur,
afin que le RNC soit capable de distinguer le trafic ddi chaque oprateur. Les deux figures
ci-dessous montrent les deux objets IUO cres pour les deux oprateurs.

20
 Figure 14 : Objet IUO de Ooredoo

Figure 15:Objet IUO de Djezzy

3.2 Dimensionnement

3.2.1 Principes gnraux de dimensionnement

Le dimensionnement du rseau est aussi toujours li au trafic demand. Dfinir le trafic

demand est le point de dbut du processus de dimensionnement du rseau, et plus
lestimation du trafic demand est prcise, plus le dimensionnement du rseau est prcis. Ds
que lestimation du trafic est faite, ltape suivante dans le processus de dimensionnement est
de trouver la configuration du rseau appropri la demande de trafic spcifi. Donc, cette
procdure de dimensionnement permet dvaluer le nombre de sites ncessaires pour rpondre
aux exigences de loprateur en termes de couverture et de qualit de service.

Le processus de dimensionnement est bas sur des modules : Input et Output. Les
donnes Input dpendent des exigences de loprateur en termes de service fournir, la
qualit quil recommande, la capacit et la couverture. Output rsume le nombre des
quipements ncessaire ainsi que leurs configurations. Le dimensionnement de lUTRAN
rside dans la dtermination du nombre de NodeB et RNC[1].
21
3.2.2 Le dimensionnement du NodeB

3.2.2.1 System module FSMF

FlexiMultiradio system module FSMF est un type de system module qui permet la
NodeB de soutenir les normes hausses de la demande de trafic. Il approvisionne une
flexibilit et une amlioration de capacit, par lajout jusquaux deux sous systmes
dextension FBBA, en plus des configurations multiradios, diffrentes technologies GSM,
WCDMA, LTE et LTE-advanced sont ralisables [8].

Le FSMF comporte 5,5 subunits qui sont utiliss pour :

CCCH (Common Control Channel) processing
R99 usersprocessing.
HSDPAusers, throughputprocessing.
HSUPAusers,throughputprocessing.
CS voice over HSPA Users processing.
Pools de suppression dinterfrences PIC processing

96CE

HSDPA R99 HSUPA PIC CCCH

Scheduler Users
Figure 16 :Les services offerts par le systme module FSMF

Channel Element CE : Ce sont les ressources de bases ncessaires dans la NodeB pour
avoir la capacit soutenir et dterminer la qualit de services dun certain nombre
dutilisateurs, par exemple 1 CE est allou pour une communication AMR, et plus le service
offert devient important, plus le nombre de CEs augmente. Chaque 96 CE sont regroups dans
un subunit.
La capacit disponible pour le trafic pure dpend :
du type de configuration de LCG (Local Cell Group)
des ressources de traitement CCCHs additionnelles
du nombre des units actives pour lannulation dinterfrences PIC.

22
3.2.2.2. Allocation des ressources CCCH

Ces ressources sont alloues pour lchange des messages de signalisation communs
tel que le paging, la voie balise, et laccs alatoire et la synchronisation travers les
diffrents canaux PCH,BCCH, le PRACH et SCH respectivement.

Chaquesystme module contient des ressources pour le CCCH processingdans sa

configuration de base pour un nombre de cellules et une porte dtermine. Si le nombre de
cellules configures dans un mme systme module dpasse 3 cellules 20km ou 6 cellules
10Km, additionnels CCCH sont ncessaires.

Les ressources bande de base de CCCH processing sont alloues par steps, appeles
CCCH pool, o chaque step contient 48 CE Rel 99.

Un pool CCCH a la possibilit de servir un nombre N de cellules suivant leurs portes

et le type de Rx en utilisant cette sommation :

( port cellule i signatureRx ) 480

(0)

O :
i : nombre de cellules (de 1 6);
porte cellule : rayon de la cellule en (Km).
Signature : le nombre maximum de prambule. Il varie de 1 4 et dpend de la porte et du
type de Rx.

3.2.2.3 Local Cell Group (LCG)

Local cell group permet de diviser la capacit bande de base disponible du system
module en pools responsable de la gestion du trafic dun groupe de cellules. Ce paramtre
peut tre utilis dans le cas du MORAN pour distinguer les cellules ddis pour chaque
oprateur.

23
 Chaque LCG a ses propres ressources CCCH processing, qui sont soit compris dans la
capacit du system module ou assigns de la capacit de bande de base du LCG. est dire
dans le cas o plus quun LCG est cr dans un system module, seulement le premier LCG
utilise CCCH pool inclus dans le system module. Tandis que pour les autres LCGs le CCCH
est pris de la capacit ddi pour le trafic et qui appartient LCG concern.

Il existe trois types de LCG pour le system module Rel.3 qui dcrit le nombre de
cellules supportant HSPA, ainsi que le nombre HSDPA/HSUPA Scheduler :

LCG Max number Max number Number of

configuration of supported of HSPA HSDPA
Type cells cells schedulers
Rel.99 only 12 0 0
Small HSPA 6 6 1
Normal HSPA 12 12 2

Tableau 2 : les types de configuration du LCG,System module Rel.3

Loprateur caractrise un LCG selon:

Frequency layer based.
Sector based.

Frequencybased: Lattribution des cellules ayant la mme frquence au mme LCG.

Sectorbased : Ce type permet lassignation des cellules appartenant la mme frquence
vers diffrents LCGs.
1. HSDPA scheduler

24
Lordonnanceur HSDPA a pour objectif de maximiser lefficacit spectrale de la cellule toute
en maintenant les exigences de la QoS pour les diffrents services en termes de dbit et
nombre dutilisateurs.
HSDPA Processing set dtermine la capacit maximale que peut fournir un HSDPA scheduler
pour atteindre un certain dbit en Downlink avec un nombre spcifique dutilisateurs.

Max number of Max. number of Max. number of cells Max scheduler

active users per active users per cells assign to HSDPA throughput
HSDPA scheduler scheduler
240 128 6 252 Mbps
Tableau 3 :La capacit HSDPA scheduler

Les capacits HSDPA processing set sont indiques ci-dessous:

HSDPA processing set 1: 32 utilisateurs avec un dbit de7.2Mbps.
HSDPA processing set 2: 72 utilisateurs avec un dbit de 21Mbps.
HSDPA processing set 3: 72utilisateurs avec un dbit de 42Mbps.
HSDPA subunits dfinit les ressources ddies pour HSDPA scheduler, et fourni une
des pools dadditionnels CCCH dans le cas o une extension de cellules/porte est
ncessaire.

HSDPA_scheduler_resources = max {(Cells_factor / 2) - 0,5;Min_HSDPA_resources }

+0,125
O: Cells_factor = Cells_factor = Roundup {(Roundup (non_MIMO_cells / 3) +
MIMO_cells)/2}.

(0)

Le nombre de CCCH pools offert par HSDPA scheduler est dtermin par la formule ci-
dessous :

Number_of_additional_CCCH_pools = max {Min_HSDPA_subunits ; (Cells_factor / 2)

0.5} * 2.

(0)

25
Le nombre de subunits rserves dans LCG pour le pur trafic est calcul par la formule ci-
dessous :

LCG_pure_traffic_subunits = LCG_dedicated _subunits Additional_CCCH_subunits

PIC_pool_subunits HSDPA_subunits.

(0)

Tcellgrouping :
Cest un paramtre qui caractrise un goupe de cellules dans un mme HSDPA scheduler.il
est dsign par un identifiant spcifique selon scheduler auquel il appartient. Chaque
scheduler peut grer jusqu 2 Tcellgrouping.
Dans le cas de Normal HSPA on peut avoir jusqu 2 HSDPA scheduler par LCG, donc les
Tcellgrouping vont tre assign, selon la norme 3GPP, comme suit :
- HSDPA scheduler 1: TCELL group 1et 3.

- HSDPA scheduler 2: TCELL group 2 et4.

Les cellules constituant le Tcellgrouping sont identifies des Tcell de la manire suivante :

- Group 1: Tcell values 0, 1 et 2.

- Group 2: Tcell values 3, 4 et 5
- Group 3: Tcell values 6, 7 et 8.
- Group 4: Tcell value 9.
Lorsque le type de configuration de LCG est small HSPA, uniquement un seul HSDPA
scheduler est disponible, du cot les cellules peuvent avoir les Tcells values uniquement des
TCellgouping 1 et 3.

Lallocation des resources HSDPA processing set:

HSDPA processing set sont les licences distribues sur les HSDPA schedulers ou les LCG
dans Rel3, selon :
- Le dbit HSDPA

Le dbit HSDPA total disponible se divise sur les HSDPA Schedulers disponible dans la
NodeB.

26
La distribution des processing set 1 suit la formule suivante :

Scheduler_licensed_throughput=
Round_down{Number_of_HSDPA_Processing_Sets*(Scheduler_HSDPA_throughput_step/
Total_number_of_HSDPA_throughput_step per BTS)} * 7,2 Mbits

(0)

Dans le cas des processing set 2 et 3, la distribution suit la formule ci-dessous :

Scheduler_licensed_throughput = Round_down
{(Number_of_HSDPA_Processing_Sets_2)+(4*Number_of_HSDPA_Processing_Sets_3)
*(Scheduler_HSDPA_throughput_step / Total_number_of_HSDPA_throughput_step_per_BTS) } * 21
Mbps.

(0)

Remarque: Si le dbitattribu pour tous les HSDPA schedulerdisponible aprs le calcul est
infrieur au dbit total offert (Processing set) pour la NodeB, le reste est dvis entre les
diffrents schedulers selon :
Le scheduler qui le plus petit rapport entre le dbit calcul et le debitcommission en
niveau de step.
Scheduler qui appartient au LCG avec un identifiant petit, par exemple dans la
configuration Normal HSPA (02 HSDPA schedules) le HSDPA scheduler1 est
prioritaire au HSDPA scheduler 2.

- Le nombre des utilisateurs

Le nombre des usagers HSDPA que peut supporter un LCG est spcifi selon le nombre et le
type de processing set configur, allant de 32 (processing set1) 72 utilisateurs (processing
set 2,3).
27
On dduit que le dbit fournie par HSDPA scheduler dpend du type de LCG configur, le
nombre et le type de processing set dploy ainsi que le niveau de stepscommisionned par
loprateur pour chaque scheduler.
2. Le service HSUPA

La capacit bande debase est rserve pour HSUPA selon les besoins. La rpartition de cette
capacit est alloue dune faon dynamique entre les utilisateurs DCH (R99 uniquement) et
les utilisateurs HSUPA sachant que la priorit est pour R99.
Dans le system module Rel 3, suivant le type de configuration LCG, HSUPA scheduler
supporte jusqu 240 utilisateurs avec normal HSPA, 160 utilisateurs avec small HSPA.

Lallocation des ressources pour les utilisateurs HSUPA est ralise suivant des steps. Chaque
step install consomme 0,125 subunite du system module.
- Lallocation desresources HSUPA processing set

HSUPA processing set accrot le nombre dusages qui peut tre desservis par un LCG par 24
utilisateurs et offre un dbit de 5.8 Mbits/s. pour satisfaire le nombre dabonns demande
avec un certain dbit cela, le nombre de processing set ncessaire est calcul selon cette
formule :

Number_of_HSUPA_BTS_Processing_Sets = max {Roundup (HSUPA_users / 24);

Roundup (HSUPA_data_users_throughput /5.8)};

(0)

3. Interference cancellation unit (PIC pool)

Pour atteindre un dbit HSUPA lev, les units PIC pools sont recommandes pour raliser
lannulation dinterfrence dans les cellules HSUPA.
Dans un system module Rel 3 on peut avoir jusqu deux units PIC pool o chacune gre
jusqu six cellules appartenant la mme frquence.
4. Hybridprocessing set

HSUPA processing set pour chaque LCG fournie une capacit de 48 Rel 99 CE qui peut tre
utilis lorsque tous les CE Rel99 sont consomms. Chaque CE Rel99 utilis dcrot la
capacit HSUPA permise par HSUPA hybride processing set.
28
Hybrid HSUPA processing set est dcompos en 8 steps, chaque step correspond 6CE.
Le nombre des utilisateurs et les steps HSUPA varient en fonction des CE qui sont pris par les
utilisateurs R99.
Le nombre des utilisateurs ayant accs hybrid HSDPA est dtermin selon la formule :

Amount_of_allowed_HSUPA_users_by_hybrid_HSUPA_Processing_Set
=24 Roundup (Amount_of_allocated_Rel99_CE / 2)

(0)

Le Nombre de stepshybrids disponible pour les utilisateurs HSUPA est calcul par la formule
ci-dessous :

Amount_of_resources steps by_hybrid_HSUPA_Processing_Set

=8Roundup (Amount_of_allocated_Rel 99_CE /6)

(0)

Exemple:
FSMF: 5.5 subunits (2 LCGs: 1er LCG/3cells - configuration Normal HSPA; 2me LCG/3
cells - configuration Small HSPA);
1er LCG: 3 cellules/10km / 2 way Rx Div /3.5 subunits ddis.

2me LCG: 3 cellules / 2subunits ddis.

1. Calcul de capacit pour trafic pure LCG1 :

Selon lquation (2), on calcule :

Cells_factor =Roundup{ (Roundup (nombre-cells/3) / 2 } =
Roundup{ (Roundup(3/3) + 0) / 2} = Roundup{ (Roundup(1) + 0) / 2
} = Roundup{ (3 + 0) /2} = Roundup{ 1/2 } = Roundup{ 1/2 } = 1

HSDPA_subunits= max {Cells_factor / 2 0.5 ; Min_HSDPA_subunits}

+ 0,125 = max {1/ 2 0.5 ; 1} + 0.125 = max {0 ; 1} + 0.125 = 1
+ 0.125 = 1.125.

29
On note que CCCH processing pour les trois cellules sont couvertes par les ressources inclues
dans la capacit du systme module Rel3.
LCG_pure_traffic_subunits = LCG_dedicated _subunits Additional_CCCH_subunits
PIC_pool_subunits HSDPA_subunits = 3.5 0 1.125 = 3.375

2. Calcul de capacit pour trafic pure LCG2 :

Cells_factor = Roundup{ (Roundup (non_MIMO_cells/3) + MIMO_cells

) / 2 } =Roundup{ (Roundup(3/3) + 0) / 2} = Roundup{ (Roundup(1)
+ 0 ) / 2 } =Roundup{ 1/2 } = Roundup{ 1/2} = 1.

HSDPA_subunits= max {Cells_factor / 2 0.5 ; Min_HSDPA_subunits}

+ 0.125 =
max {1 / 2 0.5 ; 1} + 0.125 = max {0 ; 1} + 0.125 = 1.125

LCG2 ncessite un pool CCCH pour le traitement CCCH pour cela 0.5 subunit est consomm
de la capacit spcifi pour LCG.
LCG_pure_traffic_subunits = LCG_dedicated_subunits CCCH_subunitsPIC_pool_subunits
HSDPA_subunits = 3 0.5 0 0.125 =0.385

3.2.3 Le dimensionnement du RNC

Dans cette partie, nous allons donner une ide sur la capacit du RNC2600 et par la
suite nous allons entamer le dimensionnement.

3.2.3.1 La capacit du RNC 2600

Le RNC2600 peut tre quip de trois steps de configuration HW
diffrentes :
STEP1 : consiste dune armoire (4 subracks) contenant un certain nombre
dunits fonctionnelles avec un DL Iubthroughput de 1100 Mbps.
STEP2 : La seconde configuration ncessite une deuxime armoire et un
nombre spcifique de plug-in units pour 2 subracks ajouts. Le DL
Iubthroughput est de 1800 Mbps.

30
STEP3 : Cest la configuration maximale. Elle ncessite 2 armoires avec un
DL Iubthroughput qui est de 2500 Mbps.
Les 3 steps comprennent un nombre bien dtermin des units suivantes :
(Tableau 4)

Functio Total Total Total

nal units number of number of number of
units in units in units in
step1 step2 step3

ICSU 14 26 38

DMCU 18 28 38

MXU 8 12 16

RSMU 2 2 2

SFU 2 2 2

OMU 2 2 2

TBUF 6 10 14

TSS 2 2 2

NPGEP 8 12 16

Tableau 4 : Le nombre dunits dans RNC2600 dans chaque step

31
3.2.3.2 Dimensionnement du RNC 2600

Pour tablir un dimensionnement de RNC, il est ncessaire de procder un

dimensionnement prliminaire des BTSs, et les interfaces Uu, Iub, Iur et Iu.

Le dimensionnement du RNC est bas principalement sur les aspects

suivants[9] :
Throughput
Le nombredabonns
Control plane (ICSU load)
Le nombre des NodeB et cellules connectes avec le RNC
Les interfaces physiques (NPGEP load)

1. Dimensionnement bas sur le throughput

Le dimensionnement du RNC peut se faire suivant une mthode

(Figure 18) qui permet de calculer le nombre de RNCs ncessaire pour
supporter le nombre des utilisateurs dans la zone planifier.

Total user

Voice CS-data PS-data HSUPA HSDPA

Erlangs Mbps Mbps Mbps Mbps

Add Add Add Add FP

SHO SHO SHO Overhead
Overhead Overhead Overhead

Calculate RNC
32 load and fill rate

Quantity of RNC in the area

 Figure 17 :Dimensionnement du RNC selon le throughput

Cette mthode de dimensionnement permet dvaluer le nombre

ncessaire et la configuration des RNCs par rapport aux abonns, y
compris une distinction entre la voix, CS, PS et le trafic HSPA, suivant les
procdures qui suivent :
Calculer le trafic de tous les utilisateurs et ceci pour les diffrents
services : AMR, CS Data, NRT Data et le trafic HSDPA et HSUPA.

- Le trafic AMR est trait indpendamment des autres trafics.

- Le trafic NRT Data est calcul par type de trafic selon la formule
suivante :

SitesNRT load per SiteNRT Bearer i

NRT_Traffic_On_Bearer_i
Bearer ( i ) rateNRT Activity Factor

(0)

Service (TTI) FP bit rate

AMR 12.2 16400
CS 64 (20 ms) 66100
PS 64 (20 ms) 69500
PS 128 (20 ms) 136700
PS 256 (10 ms) 273300
PS 384 (10 ms) 408000

Tableau 5 :Frame Protocol bit rates

Le nombre de connections simultanes au niveau du RNC dans CS et

PS Data, est calcul par la table Erlang B avec une probabilit de
blockage =0.1%
33
 Ajouter le trafic supplmentaire d au SHO (Soft Handover
Overhead) qui est de 40% pour R99 CS Data, PS Data et HSUPA et FP
Overhead pour HSDPA (Nokia default FP OH =11%).

Choisir le nombre quil faut de RNC afin de supporter ce trafic

obtenu. La charge quon utilise pour dimensionner le RNC ne doit
pas dpasser 80% de sa capacit maximale afin de prvoir une
ventuelle augmentation du trafic.

Vrifier le taux du trafic Uplink, y compris le trafic HSUPA. Le trafic

ddi lUpLink est quivalent 30% du trafic DownLink.

Si le trafic PS dans le UpLink est infrieur 30% de celui dans le

DownLink, cela na pas deffet sur le dimensionnement. Sinon, le
trafic max Iub PS DL doit tre calcul selon la formule suivante :

PS
Max_Iub_PS_DL_throughput 1.3Originalmax DL throughput
1+UL share

(0)

Le dbit UL_share est calcul en divisant le user traffic dans le UpLink sur le user trafficdans
le DownLink :

throughput
throughput
PS_UL_throughput_share IuPS
IuPS

(0)

34
Vrifier si le trafic HSPA correspond la capacit du RNC choisi. Le trafic HSDPA est
calcul avec la formule qui suit :

HSDPA_Traffic = (1+FP_Overhead)* Sites* Users per Site*HSDPA_Traffic_per_User

(0)

Le calcul de la capacit du RNC en se basant sur le traffic mix rule :

Dans le trafic mix, la somme des quatre types de trafics (AMR, CS Data, PS Data et HSDPA
Data) dans linterface Iub, doit tre infrieur ou gale 1. Sinon, si le rsultat de la formule
suivante est suprieur 1, le nombre des RNCs ncessaire doit tre augment.

AMR ( Erl ) CS Data ( Mbps ) PS Data ( Mbps )

+ +
max AMR ( Erl ) max Iub throughput ( Mbps ) max Iub throughput ( Mbps )

+ HSDPA Data ( Mbps )

1
max Iub throughput ( Mbps)
(0)

Conclusion
Dans ce chapitre, nous avons pu dtailler le procd dintgration du RNC et le
dimensionnement des lments qui constituent lUTRAN, que loprateur doit tablir pour le
MORAN.

Cette prsentation permet de poser les briques de base de ce travail qui vont la
concrtiser dans un cas pratique laide dune application.

35
CHAPITRE 4 : tude du dimensionnement du rseau
daccs

Introduction
Notre tude vise dterminer limpact du projet MORAN sur la capacit du rseau
grer le trafic coul des deux oprateurs, Ooredoo et Djezzy, en ayant une estimation sur la
tendance daugmentation du trafic. On invoquera ensuite les dmarches suivre avec les
recommandations les plus adquates, pour assurer la continuit de fonctionnement du Rseau
daccs.
La phase 1 : consiste raliser un dimensionnement de capacit bande de base aux niveaux
des NodeB pour couvrir les exigences des deux oprateurs.
La phase 2 : une optimisation des configurations tablies au pralable dans le RNC, en se
basant sur les KPI (Key Performance Indicator) prlevs du logiciel performance manager,
(voir annexe 1) et lvaluation de leffet du trafic engendr par les cellules de Djezzy sur la
capacit du RNC selon certains aspects tels que le trafic mixed, et units load (ICSU et
NPGEP).
Notre travail sachvera par une estimation sur lvolution du trafic total suite la
submergence des cellules de Djezzy, et les recommandations labores pour pouvoir tenir
laccroissement attendu.

4.1 Application
Notre but est de raliser un outil qui facilite loptimisation dexploitation des
ressources. Le principe est de dterminer les configurations appropries aux besoins et aux
exigences de chaque site, en sappuyant sur les diffrentes formules mentionnes dans le
dimensionnement de la NodeB.A lissue de la conception de lapplication, on a
opt dvelopper avec Windev (voire annexe1)

36

Check
Throughput
Limitations
4.1.2 Les aspects traits dans lapplication
Lapplication comporte deux aspects :

Premier aspect : Consiste :

1. Calculer le trafic pure pour les services (HSUPA, R99), en se basant sur une
configuration donne (le type de LCG, nombre de cellules dans chaque LCG,
pourcentage des ressources attribues pour chaque LCG).

2. Calculer le dbit en Mbps pour chaque LCG, en se basant sur une configuration
donne, nombre de processing sets disponible, le pourcentage des ressources
attribues pour chaque LCG et le niveau de steps configur dans chaque HSDPA
scheduler.

Figure 18:Reprsentation des champs pour calculer de la rpartition de capacit

Exemple de rpartition des Processing sets HSDPA disponible :

La NodeB est configure avec deux HSDPA schedulers qui sont commissionns comme suit :
- Scheduler 1: HSDPA Throughput Step=6 (42Mbps)
- Scheduler 2: HSDPA Throughput Step=18 (126Mbps

On dispose de 4 HSDPA processing sets:(3* Processing set 2, 1*processing set 3).

37
En sappuyant sur les formules de dimensionnement de NodeB intgres dans lapplication :

Figure 19: La rpartition des processing sets entre HSDPA scheduler

Le dbit offert pour chaque scheduler est calcul suivant les formules indiques dans le
dimensionnement de NodeB :
- Scheduler 1 : le dbit offert=21Mpbs

- Scheduler 2 : le dbit offert=105Mpbs

Le dbit total disponible dans la NodeB est 147Mpbs, alors que le dbit assign pour les deux
HSDPA scheduler est gale 126 Mpbs. Le 21 Mpbs restant est attribu au scheduler qui a le
rapport (R=dbit offert/dbit commissionn) le plus faible.

- Scheduler 1: R=21Mbps / 42Mbps = 0.5

- Scheduler 2: R=105Mbps / 126Mbps = 0.83

Alors les 21 Mpbs restantes vont tre attribu au scheduler 1. Pour cela dans le scheduler
1=42Mpbs et scheduler2=105Mpbs.

38
Deuxime aspect :Il permet partir du nombre de CE ncessaire, dafficher les configurations
possibles qui peuvent tre excut dans la rpartition de la capacit BB pour trafic pure
donn.

Figure 20:reprsentation des configurations possibles

4.2 tude du trafic cumul dans les NodeBs partages

4.2.1 La rpartition des HSDPA processing sets

Au niveau des sites, il y avait 2 processing set 3 quivalent 2*(84 Mbps/240

utilisateurs) pour le trafic HSDPA.

Le niveau de steps commissionn dans chaque HSDPA scheduler:

- HSDPA scheduler 1 (LCG1)= 12 steps (84 Mpbs)

- HSDPA scheduler 2 (LCG2)=12 steps (84 Mpbs)

Alors la rpartition des processing sets est effectue comme suit :

39
 Figure 21:La rpartition des processing set entre les HSDPA scheduler

4.2.2 La configuration initiale

La configuration tablie sur les NodeB aprs lintgration des cellules de Djeezy, est
effectue de telle sorte privilgier loprateur accueillant, dans notre cas loprateur
Ooredoo.

Tout dabord on a vrifi les diffrentes configurations possibles :

40
 Figure 22: La slection dune configuration pour rpartir la capacit entre deux LCG

Aprs, on a choisi la configuration qui permet davoir plus de CE ddi pour le pure trafic.
Cette configuration est assigne au LCG qui comporte les cellules de loprateur Ooredoo,
parce quon savait pas au pralable comment ce partage de ressources va influer sur les
performances du rseau.
La capacit bande de base du system module est divise entre deux LCG, chaque LCG ddi
un oprateur et paramtr comme suit :
- LCG1(Ooredoo) : 60% de capacit, 3cellules ORD, Normal HSPA.
- LCG2 (Djeezy) :40% de capacit, 3 cellules DJZ, Normal HSPA.

Aprs la rpartition de capacit ddie pour chaque LCG entre les diffrents services (voir le
dimensionnement du NodeB), on aura comme le montre la figure 23:
- 228 CE available pour HSUPA, R99 dans LCG1.
- 36 CE available pour HSUPA,R99 dans LCG 2.

41
 Figure 23 :le rsultat de la configuration tablie

Figure 24: La saisie de configuration sur le BTS Manager

Suite la mise en Air des sites, on constate daprs la figure 25(a) que le trafic HSUPA des
cellules de Djezzy est assez faible, alors que la consommation davailablesubunits pour le

42
pure trafic est de 100%, comme cest montr dansla figure 25(b). La raison de cette
discrimination est que les utilisateurs R99 sont toujours prioritaires par rapports HSUPA et
puisque le nombre de CEs est relativement restreint. Tous les 36 CE sont utiliss uniquement
pour le service R99.

(a) (b)

Figure 25 :(a) : Nombre des subunits pour HSUPA (b) : Le taux dutilisation des subunits

(HSUPA, R99)

4.2.3 Loptimisation des ressources

La phase doptimisation consiste redimensionner la capacit attribue pour chaque

LCG de telle faon permettre aux cellules de Djezzy, LCG2, daccder plus de ressources
sans influer sur la capacit ncessaire pour LCG1.

43
 Figure 26: La slection dune configuration selon la plage de CE demand

4.2.3.1 La rpartition de capacit (50%,50%)

La reconfiguration ralise est ci-dessous :
- LCG1: 50%, 3 cellules dOoredoo, Small HSPA.

- LCG2 : 50%, 3 cellules de Djezzy, Normal HSPA

3 subunits sont consacrs pour LCG2, illustr par la figure 27 puisque les subunits
disponibles sont rduits par 0.5subunit ddi pour les ressources CCCH, tandis que le premier
LCG dispose de 2 subunits, tant donn quils prennent les ressources CCCH de la capacit
du system module.

Alors, avec le mme type de configuration pour les deux LCG (Normal HSPA), on
aura 132 CE disponibles pour chaque LCG. Sachant que la consommation des ressources pour
LCG1, selon la configuration prcdente, a atteint 65%, environ 1.667 subunits de 2.375
disponible, et avec une telle reconfiguration, le premier LCG perd 1 subunit (quivalent
42%). Pour cela on procde une modification du type de LCG vers le Small HSPA pour
rcuprer 0.5 subunit.

On constate une amlioration remarquable au niveau du trafic HSUPA engendr par

les cellules qui appartiennent aux LCG2, ainsi quune diminution du pourcentage dutilisation
des ressources libres car, il y avait une augmentation du nombre de ressources de 36CE
132CE. En parallle le changement du type de LCG 1 vers le small HSPA na pas altrer sur
le trafic HSUPA, comme sest prsent dans la figure 30 (a).

44
 Figure 27: Le Nombre de subunits et CE ddis pour chaque LCG selon la configuration
50%,50%

Pour loprateur Ooredoo, adopter cette solution long terme nest pas optimale, car si on
veut garder la configuration Normal HSPA, le nombre de ressources sera rduit par 84 CE,
alors pour satisfaire les besoins de chaque oprateur, on a opt pour une autre solution.

4.2.3.2 La rpartition 60%,40% avec inversion des LCGs

Phase1 : modification du type de configuration de LCG2 du normal vers small HSPA pour
avoir 48 CE, ce qui lui permet davoir 84 CE disponibles pour les services R99, HSUPA.

45
Figure 28: Le nombre de CE ddi pour LCG2 aprs le changement du type de configuration

Aprs la supervision du trafic coul par les deux LCG, sur la figure 31 phase1, on constate
que le trafic HSUPA dans les cellules de LCG 1 devient nul, et certainement, ce nest pas d
au manque de ressources.
La raison pour laquelle le trafic HSUPA ne sest pas progresser, cest le paramtrage de Tcell
value qui selon, les normes 3GPP. Small HSPA peut tre utilis uniquement pour HSDPA
scheduler1 avec comme Tcell group 1 ou 3. Alors quil tait paramtr pour HSDPA scheduler
2 inclus dans LCG2 (voir Tcellgrouping). Pour cela, on a procd une inversion des LCG
afin dy remdier ce problme.
Phase2:
- LCG1: 40%, 3 cellules DJZ, Small HSPA

- LCG2 : 60%,3 cellules ORD, Normal HSPA

Aprs linversion des LCGs, 0.5 CCCH prise de la capacit de LCG2.

LCG1 bnficie de 48 CE de plus, 0.5 subunit, par rapport la solution prcdente, alors il
aura 132 CEs. LCG2 avec Normal HSPA, il disposera de 180 CE.

46
 Figure 29 :La rpartition de capacit aprs inversion des LCGs

Solution 1 : Configuration (50%, 50%)

(a)
(b)

Figure 30 :(a) : Le nombre de subunits HSUPA, (b) : Le taux dutilisation de subunits(HSUPA,R99)

Solution 2 : Configuration (40%, 60%)

47
 Figure 31 : Les subunits utiliss pour HSUPA avant et aprs optimisation

4.3 Ltude dutrafic cumul des NodeB sur RNC

4.3.1 Le trafic HSUPA et HSDPA au niveau du RNC

On insinue, daprs la figure 32, que le redimensionnement instaurer aux niveaux des
sites, provoque des amliorations considrables du dbit HSUPA dans RNC. Un dbit quil ne
doit pas dpass 30% par rapport au dbit fourni pour le Downlink, pour respecter les normes
du dimensionnement de RNC, alors que le dbit HSDPA, reprsent par la figure 33 sur le
RNC, na pas subi des amliorations considrables vu que les ressources ddies pour ce
service au niveau de HSDPA scheduler sont statiques et indpendants des autres services.

48
 (a) (b)

Figure 32 : Le dbit du trafic HSUPA dans RNC Figure 33 : Le dbit du trafic HSDPA

4.3.2 Lvolution du trafic mixed dans le RNC

Le mixed trafic signifie la cohrence quelle doit y avoir entre les diffrents services
que peut grer le RNC simultanment : il regroupe le dbit du trafic PS exprim en Mpbs, et
la capacit AMR du trafic CS en Erlang.

49
 (a) (b)

Figure 34 :(a) :Le taux dvolution du trafic mixed (b):Le taux de cellules oprationnelles.

Depuis le dploiement du sharing. On aperoit que le trafic mixed accrot en mme

temps avec le nombre de cellules oprationnelles discerns par la figure 34 (a) et (b), suivant
une tendance quasi linaire. En outre Le taux de cette croissance slve encore plus aprs le
redimensionnement tabli aux niveaux des sites. Il atteint un pourcentage de plus 40% de la
capacit rserv pour trafic mixed par RNC (step1).

4.3.3La charge des units fonctionnelles (NPGEP, ICSU)

Figure 35: Peak load des units NPGEP

50
 Figure 36 :Load des units ICSU

4.3.3.1 NPGEP LOAD

Le graphe de la figure35, reprsente le pourcentage dutilisation des huit NPGEP,

constituant Step 1, par jour sur une dure de 3 mois.

On constate daprs lallure des courbes, uniquement deux NPGEP se dmarquent des autres
avec untaux de charge qui se progresse au fil des jours. Ce comportement suit un
renversement affin entre ces deux cartes, tandis que pour les autres cartes, leurs taux charges
varient environ les 10% durant toute cette priode.

La diffrence de charge entre les deux NPGEP 6 et 7, reprsentes en bleu et en rouge,

par rapport autres est d au fait que ces deux NPGEP acheminent le trafic IUB qui a un
volume de donnes lev, car elle regroupe lensemble du trafic cumul des sites. En parallle
concernant le reste des NPGEPs chacune est ddie pour le routage sur une interface
spcifique soit IUR, Iu-CS ou Iu-PS.

Le renversement des courbes entre NPGEP6 et le NPGEP 7 est engendr par le switch
du trafic achemin par le NPGEP6 vers le NPGEP7, cause systme, parce que ce type de carte
est configur selon un type de protection (4+4) ce qui signifie que chaque carte en working

51
sa propre standby qui est synchronis avec la premire, pour la soutenir en cas dventuelle
panne ou usurpation.

4.3.3.2 ICSU LOAD

On remarque daprs le graphe obtenu de la figure 36, qui exprime le taux de charge
des cartes ICSUs du RNC, que les ICSU6 et 8 ont un load important, 60% et 77%
respectivement, Par rapport au taux moyen de lensemble de cartes. Cette distinction est due
au trafic gnr par les sites appartenant chaque ICSU. Les deux figures ci-dessous clarifient
que, LICSU6 supporte 13 sites dont 9 sont partags et qui gnrent un trafic lev, figure
37(a), tandis que 16 sites sont supports par lICSU8 avec 8 sites partags (figure 37(b))

(a) (b)

Figure 37 : Les sites grs par (a) : ICSU6, (b) : ICSU8

Bien quil est avr linstant que, limpact des cellules de Djezzy nest pas contraignant dans
les cas traits dans notre tude de capacit de RNC, on doit tenir compte que le Sharing des
sites smergent de plus en plus dans le rseau, en dployant plus de cellules de Djezzy. La
croissance du nombre de cellules crer, illustr par la figure 34(b), va se rpercuter sur le
trafic cumule de mme lusage des ressources disponibles tel que les units fonctionnelles
etc

52
4.3.4 Les recommandations faites

Daprs ce quon a effectu dans cette tude, et les entraves sur lesquelles on tait
mises, tel que lvolution du trafic cumul dans le RNC (step1), on peut prdire que les
ressources utilises tendront vers leur saturation.

Cependant afin danticip tout rejet daccs au rseau cause dinsuffisance de

ressources, et en se rfrant sur les principes de dimensionnement et doptimisations fixs par
NOKIA, on voquera certaines recommandations qui conviennent avec les problmes
rencontrer et qui ont fait preuves dans des situations pareilles.

Parmi les recommandations envisageables pour :

4.3.4.1 Le nombre de cellules

RNC2600 supporte la solution doptimisation de couverture, c'est--dire que le

nombre de cellules livr par RNC (step 1) peut accrotre de 1440 2450 en revanche une
diminution de 10% de trafic maximal approvisionner pour les services AMR et PS. Cette
procdure est ralise par une configuration logicielle software). Elle est prsente dans le
tableau suivant :

AMR (DL+UL) Dbit PS (DL+UL)

Step 1 Nombre de cellules
Erlang Mbps
Configuration normal 23800 1540 1440

Configuration optimis 21420 1380 2450

Tableau 6: Configuration optimise de couverture

tant donn que le nombre de cellules est proche de la saturation, daprs la figure 34(b) et en
parallle le trafic mixed atteint 50% de la capacit maximal du RNC, on peut sappuyer sur
loptimisation de configuration afin de prosprer le nombre de cellules maximales.

4.3.4.2 Load dans NPGEP

Reconfiguration des interfaces NPGEP qui avaient un type de
protection 2N dans step1 (4+4), c'est--dire 4 working et 4 Standby,
vers lutilisation de lune des cartes NPGEPs standby comme working
53
 pour exploiter une carte en plus simultanment, ce qui permet de
soulager la charge sur lesNPGEPs, plus particulirement celle qui
gre linterface Iub.

une expansion de capacit vers le step2 offre la possibilit dintgrer plus de cartes.

4.3.4.3 Loaddans ICSU

Linstallation de feature daugmentation de frquence du CPU de la carte de 1.3GHZ

1.9GHZ pour bnficier dune rduction de 15% de charge sur la carte.

ICSU blancing : linitialisation manuelle ou automatique laide dun algorithme, qui

calcule chaque fois le trafic produit par les sites appartenant la mme carte ICSU
pour dterminer la distribution de charge entre ces diffrentes cartes, et effectue une
rallocation quitable des sites, en terme de capacit, particulirement celles qui
atteignent les 80 % de charge.

une expansion de capacit vers le Step2.

Suite la tendance de charge des ICSUs, on a procd au changement de frquence du

processeur vers le 1.9GHZ,figure 38. Ce qui a permis de soulager dune faon significative la
charge des ICSU comme le montre la figure 39.

Figure 38: ICSU6_CPU

54
 Figure 39 : ICSU Loadaprsle changement de frquence

Conclusion
Dans cette tude nous avons pu mettre en pratique tous ce que nous avons acquis
comme connaissances thoriques sur le dimensionnement des entits du rseau daccs
UTRAN (NodeB, RNC). Nous avons utiliss des rapports fournies du logiciel Performance
Manager, en se basant sur les KPI, pour suivre le comportement du rseau suite au
dploiement du sharing. Loptimisation aux niveaux des sites, laide de notre application,
55
influer sur la tendance de consommation des ressources telle que la charge sur les units
fonctionnelles (ICSU, NPGEP) et le dbit HSUPA. On a achev notre travail par une
proposition des recommandations pour maintenir le rseau (minimiser le taux des rejets d
linsuffisance de ressources).

Conclusion gnrale
Dans Le cadre de ce projet de fin dtude, on a labor le processus du MORAN
depuis lintgration des interfaces entre les deux oprateurs, Ooredoo et Djezzy, jusquau
dimensionnement et optimisation du rseau daccs.

A lissue de ce travail, et afin de pouvoir raliser notre tude. Dans la premire partie
nous avons prsent larchitecture du rseau UMTS, particulirement les lments
fondamentaux (NodeB, RNC) dont on sest appuy. On a cit les types de hardware utilis
dans le rseau daccs, ainsi que la signalisation SIGTRAN chang dans chaque interface sur
le RNC. Subsquemment on a voqu le principe de la solution sharing dans le rseau
UMTS.

Dans la deuxime partie, nous avons invoqu le mcanisme dintgration de linterface

IUPS control plane qui relie le RNC de loprateur Ooredoo vers le SGSN de Djezzy. Ensuite,
on a expliqu profondment le principe de dimensionnement de capacit dans la NodeB et
RNC suivant les perspectives de Nokia.

Dans Notre approche on a pris comme exemple ltude de la wilaya de Relizane.

Grce aux donnes fournis par Ooredoo, nous avons ralisun dimensionnement de capacit
des sites suite au dploiement de cellules de Djezzy accompagn dune interprtation de
rsultats obtenus laide des KPI du logiciel performance Manager ; ces rsultats expriment
lutilisation des services HSUPA et R99 utiliss par chaque oprateur. Aprs nous avons
conceptualis un outil pour faciliter le choix de configuration appropri lors de la phase
doptimisation des sites. Ultrieurement, nous avons valu limpact du sharing, reprsenter
par le nombre de sites cres, sur la capacit de RNC suivant certains aspects. Lors de
lachvement de ltude on tait capable de recommander des solutions adquates aux
constatations effectuer.

56
 Pour conclure, lors de la procdure de ralisation du projet Network sharing, le cot
dinvestissement est le critre primordial qui doit tre fig avant dentamer chaque tape. Car
cest la raison principale pour laquelle on adopte cette technique.

Bibliographie

[1] Y. MAATALLAOUI, Etude de la solution NSN RU30, 2011.

[2] Nokia, RNC2600 Product Description, 2013.
[3] Institut Numrique, http://www.institut-numerique.org/chapitre-ii-role-principal-de-la-
signalisation-dans-un-reseau-telephonique-515d5091f296b. [En ligne].
[4] NSN, WCDMA RAN IP Transport, 2014.
[5] B. PAPER, Shared Networks- performance Management Challenges.
[6] Mobile Infrastructure Sharing.
[7] Nokia, [En ligne]. Available: http://networks.nokia.com/portfolio/solutions/network-
sharing.
[8] NSN, Dimensioning WCDMA RAN: Flexi BTS Baseband, 2013.
[9] NSN, Access Network Dimensioning, 2012.
[10] B. Paper, Shared Networks- performance Management Challenges.
[11] Salim, Chap4ReseauUMTS, Biskra, 2014.
[12] L'UMTS et le haut-dbit mobile, 2006. [En ligne]. Available: http://www-igm.univ-
mlv.fr/~dr/XPOSE2006/eric_meurisse/umts.php.

57
Annexe 1 : Description des logiciels utiliss
Logiciel Windev :

C'est un langage qui est fait pour des applications simples, peu complexes
et il ne demande pas beaucoup de temps de programmation, ce qui rpond
au besoin de notre application de dimensionning.
Il sert crer des applications orientes donnes tels que le WMS( Web
Map Server) et dispose de son propre langage de programmation le
Wlanguage.Un des principaux atouts de Windev rside dans sa capacit
concevoir des interfaces logicielles conviviales et fonctionnelles.

BTS MANAGER :

BTS manager est un logiciel utilis pour grer la maintenance, supervision et la mise en
services des stations de bases (BTS,NodeB).
Les stations de bases sont contrles localement o distance, via un cble Ethernet et une
adresse IP spcifi dans le logiciel respectivement, par louverture dune session entre cette
dernires et le BTS manager.

Performance Manager :
Nokia Performance Manager t conu pour grer le rseau dune manire fiable, prcise et
rentable. Il identifie les dgradations de performance et priorise ceux qui ont le plus grand
impact sur la qualit du rseau.Il contient un paramtre capacityadvisor qui aide prvoir les
besoins de capacit du rseau, et recommande les mesures prendre chaque situation. Ce
logiciel offre les indicateurs de performances KPI et les rapports ncessaires pour grer les
donnes normes gnrer chaque jour.
Performance manager aide les oprateurs faire face lacclration du changement
dindustrie de tlcommunications
Performance manager est pris en charge pas les professionnels Nokia Network pour intgrer
optimiser et adapter le contenu Multi-technologie de loprateur, lenvironnement

1
2