SIBOR

Service 3G

RESUME : Ce document permet danticiper

lextension de la capacit des sites 3G en fonction
de lobservation des indicateurs.

1/45
SOMMAIRE

1 INTRODUCTION......................................................................................4

2 RAPPELS SUR LE CONTRLE DADMISSION CAC.......................................5

2.1 RAB MATCHING..................................................................................................5
2.2 ALGORITHME IRM CAC.........................................................................................6
2.2.1 COULEUR DU LIEN RADIO.........................................................................................................................................8
2.2.2 COULEUR DE LA CELLULE........................................................................................................................................8
2.3 ALLOCATION DES RESSOURCES...............................................................................11
2.3.1 RESSOURCES DE TRANSPORT..................................................................................................................................11
2.3.2 PUISSANCE DL.......................................................................................................................................................11
2.3.3 CODES OVSF DL...................................................................................................................................................13
2.3.4 RESSOURCES RNC-IN............................................................................................................................................13
2.3.5 RESSOURCES CEM.................................................................................................................................................13
2.3.6 CAC UL.................................................................................................................................................................13
3 ETUDE DE LA CONGESTION...................................................................14
3.1 CARACTRISATION DU BLOCAGE..............................................................................14
3.2 RESSOURCES IMPLIQUES.....................................................................................14
3.3 MOYENS DISPOSITION POUR LA DTECTION.............................................................14
3.3.1 CONGESTION RRC.................................................................................................................................................15
3.3.2 CONGESTION LTABLISSEMENT OU LA RECONFIGURATION DU RB................................................................16
3.3.3 CONGESTION HSDPA.............................................................................................................................................20
3.4 ANALYSE DUNE SITUATION DE BLOCAGE...................................................................22
4 NOUVEAUTS UA5................................................................................23
4.1 DOWNLINK IRM................................................................................................ 23
4.1.1 CHARGE CEM DL..................................................................................................................................................23
4.1.2 PARAMTRES..........................................................................................................................................................25
4.1.3 COMPTEURS DE CONGESTION CEM DL.................................................................................................................26
4.2 UPLINK IRM..................................................................................................... 26
4.2.1 CHARGE CEM UL..................................................................................................................................................26
4.2.2 CHARGE RADIO UL................................................................................................................................................27
4.3 RNC OVERLOAD................................................................................................ 30
4.3.1 PRINCIPE.................................................................................................................................................................30
4.3.2 PARAMTRES..........................................................................................................................................................31
4.3.3 COMPTEURS............................................................................................................................................................32
4.4 COMPTEURS UTILES POUR LA CHARGE......................................................................33
5 DMARCHE PRDICTIVE........................................................................35
5.1 DFINITION DES INDICATEURS IMPLIQUS..................................................................36
5.2 ARBRE DE DCISION POUR LA PRDICTION.................................................................38
6 CONCLUSION.......................................................................................39

7 ANNEXES.............................................................................................40
7.1 INDICATEURS OSIRIS.........................................................................................40
7.2 EXEMPLE DE CONGESTION CEM DTECTE ET CORRIGE................................................40
7.3 IRM PREEMPTION.............................................................................................. 40
7.3.1 PRSENTATION........................................................................................................................................................40
7.3.2 PARAMTRES..........................................................................................................................................................41
7.3.3 Compteurs..............................................................................................................................................................42

Introduction

2/45
Lobjectif de ce document est de poser les premires bases de traitement des points noirs
relatifs la congestion, dans le but de faciliter le travail des optimisateurs rseau.

Ce cahier mtier est consacr la dtection et lanticipation de problmes de capacit CEM et

radio des BTS en place au sein du rseau, ainsi que de lengorgement de la bande passante sur
les interfaces Iub, Iur. Dautres cahiers mtiers viennent en complment pour traiter les
problmatiques de slection/reslection, mobilit 3G/2G, coupure dappels, etc.

Dans cette tude, lajustement des paramtres dpend du temps moyen ncessaire
lextension des cartes CEM. En fait, souvent le temps critique est celui relatif la disponibilit
de la LL.

Cette tude traite de tous les aspects de CAC DL disponibles en UA4.2, mais galement des
nouveauts ct UA5 avec notamment lapparition dune gestion plus volue de ladmission
UL. Les aspects relatifs au HSUPA ne sont pas traits dans cette tude.

Ce document a vocation voluer partir des retours des units oprationnelles.

3/45
1 Rappels sur le contrle dadmission CAC
La procdure de Call Admission Control est gre par le RNC au sein de lUTRAN Nortel. Elle est
partie intgrante dune procdure plus haut niveau, le Radio Resource Management. Le CAC
est responsable de lallocation de ressources pour un service demand, tout comme de son
rejet.

Dans ce qui suit, nous allons examiner dans le dtail le droulement de cette procdure
garante de ltablissement dappels.

Lalgorithme de CAC peut tre divis en trois parties :

1- Le RNC dtermine, parmi une liste de RAB supports, le RAB le plus adquat en fonction
du service demand par lutilisateur
2- Le RB peut tre potentiellement modifi, pour tenir compte de ltat de charge de la
cellule ou de la classe de lutilisateur
3- Finalement, une vrification des ressources UTRAN correspondantes est effectue avant
lallocation.

1.1 RAB Matching

Sans trop sattarder sur cette partie, nous pouvons simplement dire que durant cette tape, le
RNC va slectionner tous les RAB pouvant correspondre au service demand (qui sont marqus
EnabledForRabMatching=True au niveau de lOMC). Par exemple, si le service demand est
PS384DL, lalgorithme de RAB Matching va puiser dans la base OMC et sortir les RAB qui
peuvent tre ligibles, par exemple PS384, PS128, PS64 sils sont tous configurs True.

Vient ensuite la vrification des capacits du mobile, comme le montre lexemple ci-dessous :

4/45
La troisime tape consiste en la slection des canaux de trafic, avec une cohrence UL/DL. Et
cest partir de ce moment l que liRM CAC intervient (et qui concerne uniquement la partie
DL), en se basant sur une table permettant dvaluer :

- la couleur du lien radio de la cellule primaire : base sur CPICH Ec/N0 et CPICH
RSCP reporte dans les messages RRC Measurements qui indiquent les
conditions radio. Les deux couleurs Vert et Rouge reprsentent respectivement
de bonnes et de mauvaises conditions radio.
- La couleur de la cellule: base sur les indicateurs dutilisation de larbre de codes
OVSF DL, de la puissance DL utilise par rapport la puissance disponible, ainsi
que la charge Iub en terme dutilisation de la bande passante. On distingue trois
couleurs: vert, jaune et rouge, le vert est relatif une cellule non charge, et le
rouge indique une cellule charge.

1.2 Algorithme iRM CAC

Cette fonctionnalit est responsable de la traduction du RAB en RB. LiRM CAC propose des
mcanismes prventifs au niveau du CAC, et permet damliorer la capacit du systme en
terme dappels admis par une dgradation de RAB (uniquement les I/B, nintervient ni sur les
Conversational ni sur les Streaming).

Nous allons nous intresser aux interventions de liRM CAC durant les phases dtablissement
et durant les phases de Scheduling Upgrade (un appel PS dgrad pour cause de mauvaises
conditions radio par liRM Scheduling Downgrade et qui, en retrouvant un bon niveau de signal,
devient ligible liRM Scheduling Upgrade pour retrouver son RB initial).

LiRM CAC prend en compte :

Les conditions radio exprimes par une couleur de lien
La congestion de la cellule en puissance et en codes, galement reprsent par une couleur
La charge du lien Iub, commune toutes les cellules dun mme NodeB, exprime par une
couleur
LOLS (Olympic Level service) qui permet de diffrencier le traitement accorder aux
utilisateurs selon quils soient classs dans la catgorie Gold ou Silver ou Bronze
La politique de loprateur, reprsente par la fonction

Target_RAB = F(Link_Color, Cell_Color, Iub Load Color, Reference_RB, OLS)

Cette fonction est matrialise par la table iRM.

Ci-dessous une figure qui rsume lallocation du RB aprs lintervention de liRM CAC :

5/45
Et voici un exemple de table iRM :

6/45
1.2.1 Couleur du lien radio

Pour lvaluation de la couleur du lien radio, lalgorithme se base sur les critres CPICH Ec/No
et RSCP reports par le mobile dans les messages RRC Measurement Report priodiques. La
couleur est soit rouge soit verte.

Les mesures relatives la puissance et la couverture rapportes sont compares des seuils
de dclenchement qui sont les suivants : IrmDlPowerThreshold et
IrmDlCoverageThreshold.

1.2.2 Couleur de la cellule

La dtermination de la couleur de la cellule se base sur les couleurs radio et Iub dcrites ci-
dessous.

1.2.2.1Couleur radio

Lvaluation de cette couleur se base sur les ressources en codes OVSF DL et en puissance DL
utilises. Cest la couleur relative la charge dutilisation des ressources radio

Avec :

7/45
Charge en puissance:

La couleur relative la charge en puissance sexprime partir de la formule suivante :

Chaque couleur est atteinte suite au dclenchement dun seuil paramtrable.

Les deux ingalits suivantes doivent tre respectes pour un usage convenable des seuils :

Suivant la politique mener, il est possible de navoir que deux couleurs en confondant
certains seuils.

Tous ces paramtres sont sous le mme objet figurant dans lexemple ci-dessous :

Charge en codes OVSF DL:

Voici la formule qui donne la charge en codes :

8/45
Avec : nombre de Spreading Factor = 7 (cest la profondeur de larbre).

La corrlation entre couleur et seuils de dclenchement est reprsente par le graphique

suivant, qui reprend le mme principe que celui dcrit pour la charge en puissance :

Un exemple de seuil :

1.2.2.2Couleur de lIub

Sans rentrer dans les dtails des formules de calcul de la charge Iub qui sont assez complexes,
nous pouvons simplement dire que le principe de dtermination de la couleur est similaire
celui utilis pour les codes et la puissance :

Et voici un exemple de seuil :

Il est recommand dutiliser les valeurs suivantes: G2Y=70% et Y2R=90%, ceci pour permettre
davoir trois PS384 sur un E1 (=80% de la charge Iub) sans dclencher ltat rouge.
9/45
1.2.2.3Couleur rsultante

Cest la synthse de la charge en codes, en puissance et en bande passante Iub :

Classification des couleurs : vert < jaune < rouge

1.3 Allocation des ressources

1.3.1 Ressources de transport

Une fois le RB dtermin partir du RAB demand, le RNC va allouer les ressources
ncessaires au transport des donnes, tout en effectuant un contrle dadmission.

1.3.1.1 Ressources Iub

Sans rentrer dans les dtails complexes de la vrification par le RNC des ressources en bande
passante Iub disponibles pour le service demand, il faut juste remarquer que les paramtres
dfinis au niveau des diffrents RB pour dfinir les bandes passantes associes sappuient sur
des recommandations dingnierie et donc ne peuvent tre modifie souhait par loprateur.

1.3.1.2 Ressources Iur

Mme principe que pour les ressources Iub.

1.3.1.3Ressources Iu

Comme pour le cas de lIub, un contrle dadmission AAL2 est effectu pour le domaine CS.

10/45
1.3.2 Puissance DL

Lallocation de la puissance DL se conforme au schma suivant :

Nous nallons pas rentrer dans les dtails de la puissance allouer au premier lien radio ou la
reconfiguration dun lien radio, ce que nous pouvons dire cest que les quations
correspondantes prennent en compte deux algorithmes diffrents, Algo1 et Algo2.

Le CAC opre de la faon suivante :

11/45
Au sein de lUTRAN Nortel, il existe un deuxime critre dadmission oprant juste aprs le CAC
sur la puissance DL, qui est le power-partitioning que nous nallons pas voquer dans cette
tude tant donn quil est dsactiv et pas recommand.

1.3.3 Codes OVSF DL

Le RNC cherche les codes demands en parcourant larbre de haut en bas. Le premier code
libre trouv sera rserv lutilisateur. Les canaux communs reprsentent une charge de 8%
en termes de codes. Ils occupent les positions suivantes :

1.3.4 Ressources RNC-IN

Une fois les ressources radio alloues, le RNC vrifie sil a des ressources pour traiter les RB
allou lutilisateur. Si cest le cas, le processus CAC peut continuer.

1.3.5 Ressources CEM

Le RNC na pas un accs direct aux ressources CEM au niveau des NodeB. Lors de lenvoi du
Radio Link Reconfiguration Prepare, si le NodeB rpond positivement, cest que des ressources
CEM ont bien t alloues pour lappel en cours, sinon le contexte est rejet pour cause de
congestion CEM. LUA5 permettra au RNC davoir une visibilit sur les ressources CEM.

1.3.6 CAC UL

Cet algorithme opre sur le RSSI :

12/45
13/45
2 Etude de la congestion

2.1 Caractrisation du blocage

A chaque fois que le mobile demande des ressources lUTRAN et quil ne les obtient pas, on
est en prsence dune situation de blocage :

Phase de l'appel Cause de blocage Effet Mthodes de dtection

RB Establishment Unsuccess
Manque de ressources
Admission Echec d'admission RL Reconf Unsuccess and Cancel
l'tablissement
RRC Connection Unsuccess

Manque de ressources Appel pas RL Reconf Unsuccess (iRM Reconf)

pour les transitions iRM reconfigur (impact RL Setup Unsuccess (Always ON)
Reconfiguration
(AON Upsize, iRM sur le dbit Compteurs AON/iRM Scheduling
Scheduling Upgrade) utilisateur) failure

Pas de ressources RL pas rajout dans

RL Setup Unsuccess
Mobilit disponibles pour un l'Active Set (risque de
RL Addition Unsuccess
autre RL coupure)

2.2 Ressources impliques

- BTS Channel Element Ressource NodeB

Surveille au niveau NodeB.

Blocage de cette ressource: checs RB ou RL Setup/Addition/Reconfiguration.

- Iub ATM

Peut tre surveill au niveau NodeB (trafic AAL2&AAL5), ou en analysant la charge par BTS au
niveau RNC

Blocage de cette ressource: chec RB.

- Puissance RF Ressource NodeB

Surveill par cellule via le NodeB ou au moyens de compteurs RNC.

Blocage de cette ressource: chec RB.

- OVSF Codes Ressource RNC

Surveille laide de compteurs RNC.

Blocage de cette ressource: chec RB.

14/45
2.3 Moyens disposition pour la dtection

La dmarche curative permet de dtecter les cellules qui prsentent un taux lev de
congestion Radio et Iub, et les BTS qui prsentent un taux lev de congestion CEM.

La charge et la congestion sont surveilles et des actions sont entreprises en se basant sur la
comparaison avec des seuils de dclenchement prdfinis.

En premier lieu vient loptimisation systme pour tirer le meilleur parti de lUTRAN actuel par
un ajustement des paramtres.
Ensuite, et si ce nest pas suffisant, un rajout de composants H/W est ncessaire, CEM ou E1 :
La plupart du temps il nest pas ncessaire de refaire une passe sur le design et la
planification du rseau, il suffit juste dutiliser les mthodes dinstallation.

Ces mthodes doivent tre identifies et adresses aux diffrentes entits en charge.

Pour rsumer, la mthodologie ractive danalyse de la capacit sera la suivante:

Identification de la source de blocage

Dtection et caractrisation

Rsolution par ajustement des paramtres ou par addition de ressources.

2.3.1 Congestion RRC

Le blocage RRC qui nous concerne dans cette tude est un blocage pour cause de puissance
DL, codes OVSF, ressources CEM insuffisantes (pour ltablissement du SRB), ou interfrences
UL.

Compteurs Taux dchec par cause

#404 RRC.FailConnEstab
screening 1 : code DL
Nombre
screening 2 : puissance DL
dchecs
screening 3 : Unspecified (ressources #404.i / #409[cause appel]
RRC
CEM) o i prend la valeur 1, 2, 3 ou 4
screening 4 : RSSI
#409 VS.RRC.AttConnEstab
Tentatives
on compte tous les screenings
RRC

Arbre de dcision:

15/45
 Dtection dchecs
RRC, causes 1, 2, 3 et 4
runies

Traitement
Alarme matrielle Oui
alarme
?

Non

Process dimensionnement hardware

Congestion BB ? Oui
(Ajout de carte BB)

Non

Process dimensionnement hardware

Congestion Iub ? Oui
(Redimensionnement du lien Iub)

Non

- Optimisation des ariens

- Diminution puissance CPICH
Paramtrage - Modif seuils d'admission DL
Congestion Radio Oui Oui
cohrent ? - Passage un PA haute puissance
DL ?
- Ajout de porteuse
Non

Non - Alignement
paramtrage canaux
communs et CAC DL

- Optimisation ariens
Paramtrage - Modif seuil UL
Oui Oui - Cables main/div
cohrent ?
UL ? - Ajout de porteuse

Non

- Aligenment
paramtrage CAC UL

Non

Congestion - Ajout d'arbre de codes secondaire

de codes Oui - Optimisation des ariens
- Ajout de porteuse

2.3.2 Congestion ltablissement ou la reconfiguration du RB

16/45
La solution Nortel ne permet pas davoir le taux de succs dtablissement RAB au niveau
cellule pour le moment (uniquement disponible par RNC). On utilisera donc en remplacement
les formules sur les RB.

Nous numrons dans ce qui suit les causes de congestion ltablissement ou la

reconfiguration du RB qui nous intressent dans cette tude.

2.3.2.1Congestion CEM

Indicateurs lis la charge CEM :

-VS.CEMUsed.Avg(NodeB,Hour) : Moyenne de lutilisation des ressources CEM en %

-VS.CEMUsed.Max(NodeB,Hour) : Max de lutilisation des ressources CEM en %

Avec #10301 : VS.CEMUsed

-Taux dappels chous pour cause de congestion CEM, par cellule et par heure :

#631.3(FDDCell,Hour) / #625.[DlAsConf screenings](FDDCell,Hour)

Avec :
#631: VS.RadioBearerEstablishmentUnsuccess et screening3=Unspecified
#625: VS.RadioBearerSetupRequest

-Les checs dallocation de ressources CEM sont comptabiliss par le compteur suivant qui
donne le pourcentage dchecs par NodeB:

#10302: VS.CEMAllocFail

Tous les cas sont considrs: RL Setup SRB ou TRB, RL Reconfiguration Up or Down
Un arrondi est effectu en prenant la partie entire du pourcentage: si par exemple ce
compteur est calcul 0.8%, laffichage donne 0% !

Recommandation: utiliser la formule de lindicateur ci-dessus et confirmer (si possible) avec la

valeur de CEMAllocFail.

2.3.2.2Congestion puissance DL

Indicateurs de congestion en puissance :

-Taux dappels chous pour cause congestion en puissance, par cellule et par heure :

#631.2(FDDCell,Hour) / #625.[DLAccessStratumConf screenings](FDDCell,Hour)

Avec screening2=UnavailableDlPowerResources

Lorsquon dtecte une congestion radio DL en phase dtablissement du RAB (ou en phase RRC
dcrite plus haut), il faut commencer par effectuer une vrification de cohrence du
paramtrage de puissance des canaux communs et du contrle dadmission DL : si le
paramtrage en place nest pas en phase avec le paramtrage de rfrence, on remettra le
paramtrage de rfrence puis on observera lvolution des indicateurs.

Si le paramtrage est cohrent, on pourra envisager les solutions doptimisation suivantes :

17/45
 Optimisation des ariens : par exemple, tilter un secteur permet de concentrer le trafic
des niveaux de pathloss plus faibles et donc de consommer moins de capacit DL.
Diminution de la puissance du CPICH de 1 ou 2 dB au maximum par rapport la
valeur recommande : cela permet dune part de diminuer la consommation de
puissance par les canaux communs et donc de librer de la ressource pour le trafic
utilisateur, et dautre part de diminuer la couverture DL de la cellule et donc de ne plus
servir les mobiles lointains consommateurs de puissance, librant ainsi de la
capacit. Attention : la modification du niveau des canaux communs devra
saccompagner systmatiquement dune tude design sur la plaque concerne pour
viter des pertes de couverture ou des interfrences.
Modification des seuils dadmission DL : augmenter le seuil de puissance au-del duquel
on refuse les appels ladmission permet dadmettre davantage dappels. On vrifiera
dans ce cas quon ne dgrade pas trop le taux de coupure de la cellule et de ses
voisines (ainsi que le taux de succs dajout de lien en SHO).
Passage un PA haute puissance, ce qui permettra daugmenter la capacit DL et donc
de diminuer la congestion radio DL
Ajout de porteuse, ce qui permettra daugmenter la capacit DL et donc de diminuer la
congestion radio DL

2.3.2.3Congestion codes DL

Indicateurs de congestion en codes :

-Taux dappels chous pour indisponibilit de codes OVSF DL, par cellule et par heure :

#631.1(FDDCell,Hour) / #625.[DLAccessStratumConf screenings](FDDCell,Hour)

Avec screening1=UnavailableDlCodeResources

Si les indicateurs montrent un problme de congestion de larbre de codes (nombre insuffisant

de codes OVSF), on pourra envisager lajout dun arbre secondaire laide dun deuxime
Scrambling Code sur cette cellule. Si cela nest pas possible, on pourra rajouter de la capacit
radio par lajout dune deuxime porteuse ou encore par optimisation des ariens.

2.3.2.4Congestion Iub

Indicateur de congestion Iub :

-Taux dappels chous pour cause de congestion Iub, par cellule et par heure :

[#631.13(FDDCell,Hour) + #631.14(FDDCell,Hour)] / #625.[DlAsConf screenings]

(FDDCell,Hour)

Avec screening13=LackCidIub et screening14=LackBwthIub

2.3.2.5Congestion Iur

Indicateur de congestion Iub :

Indicateur de congestion Iub :

-Taux dappels chous pour cause de congestion Iub, par cellule et par heure :

18/45
 [#631.11(FDDCell,Hour) + #631.12(FDDCell,Hour)] / #625.[DlAsConf screenings]
(FDDCell,Hour)

Avec screening11=LackCidIur et screening12=LackBwthIur

2.3.2.6Congestion suite iRM Scheduling Upgrade

Cest lorsquun RAB PS dgrad pour cause de mauvaises conditions radio retrouve un bon
signal et devient ligible liRM Scheduling Upgrade.

Le compteur utile pour notre tude est le suivant, valable par cellule :

Compteur
#8 VS.RadioLinkReconfigurationPrepareUnsuccess
Echecs
screening 0 : rception de RL Reconf Failure
iRM Sched
screening 3 : RRM Refusal (manque de ressources en codes
Upgrade
et/ou en puissance)

Le taux de succs diRM Scheduling Upgrade est mesur par RNC, il nest pas possible dtablir
un pourcentage dchecs par cellule (si on veut utiliser le compteur #7 VS.
RadioLinkReconfPrepareSuccess au dnominateur, on aura un indicateur faux du fait que les
reconfigurations induites par dautres fonctionnalits comme le Rab Adaptation seront
comptabilises).

On sappuyera donc sur un seuil dalerte pour le compteur ci-dessus.

2.3.2.7Congestion suite aux transitions dtat FACH -> DCH

Les checs de rtablissement de ressources par lAlways-ON pour les utilisateurs inactifs sont
compts de la manire suivante, par cellule :

Compteurs Taux dchecs

#1109 VS.UpsizingUnsuccess
Echecs screenings : tous les DlAsConf se
Upsize AO rapportant des RAB PS
#1109.i / (#1107+#1109).i
#1107 VS.UpsizingSuccess
o i est un screening de RAB PS
Succss screenings : tous les DlAsConf se
Upsize AO rapportant des RAB PS

2.3.2.8Congestion durant les phases de SHO

Pour comptabiliser les checs dtablissement dun nouveau lien radio sur la cellule cible, on
utilise lindicateur suivant :

Compteurs Taux dchecs

19/45
 #2 VS.RadioLinkSetupUnsuccess
screening 3 : RRM Refusal (manque de
Echecs RL ressources en codes et/ou en puissance) #2.i / (#1.j + #2.i)
Setup screening 6 : manque de CID sur lIub
screening 7 : manque de bande o i : screening 3,6 et 7
passante Iub et j: tous les DLAsConf des RAB
#1 VS.RadioLinkSetupSuccess CS et PS
Succss
screenings : tous les RAB CS et PS
RL Setup

2.3.2.9Congestion au niveau du RNC

Le blocage au niveau RNC peut tre dtect laide de lindicateur suivant :

Compteurs Taux dchecs

#631
Echecs RB #631.6 / #625.i
VS.RadioBearerEstablishmentUnsuccess
Setup
screening 6 : manque de ressources RNC
o i: tous les DLAsConf des
Tentatives #625 VS.RadioBearerSetupRequest
RAB CS et PS
RB Setup screenings : tous les RAB CS et PS

2.3.2.10 Arbre de dcision

20/45
 Dtection dchecs RB, Echecs transitions Always-ON Echecs iRM Scheduling
causes 1,2,3,13 et 14 runies FACH -> DCH Upgrade

Alarme matrielle Oui Traitement alarme

?

Non

- Ajout de cartes PSFP

Congestion RNC? Oui - Reparenting NodeB Le compteur peut afficher 0
mme sil y a un fort taux
dchecs (plusieurs petits RAB
accepts) => il faut continuer
Non linvestigation
CEMAllocFail >0 Non

Optionnel Oui
Congestion BB, Ajout CEM (DBBU)
Oui CEMUsed.Max Oui
cause Unspecified
> 70%

Non

Congestion Iub ou Oui Redimensionner Iub, Iur

Iur?

Non

Paramtrage - Diminution puissance CPICH

Congestion Radio Oui Oui - Modif seuils d'admission DL
cohrent ?
DL ? - Passage un PA haute puissance
- Ajout de porteuse
Non

Non - Alignement
paramtrage canaux
communs et CAC DL

- Ajout d'arbre de codes secondaire

Congestion de - Optimisation des ariens
Oui
codes ? - Ajout de porteuse

Profil SHO
Echecs SHO Oui Oui 1
cohrent?

Non
Alignement paramtrage

2.3.3 Congestion HSDPA

Le blocage pour des RAB HSDPA intervient :

-soit ltablissement : en UA4.2 le nombre dutilisateurs tolr est de 20, au-del le CAC
rejette ltablissement de tout autre RAB HSDPA. Cette limite passe 48 en UA5.

-soit en phase de mobilit : tout type de mobilit, que ce soit HSD -> HSD, HSD -> R99, R99 ->
HSD.

Il est noter que certaines dgradations peuvent apparatre, notamment lorsque des paquets
sont ignors, on parle alors d under-run qui intervient surtout lorsque les conditions radio
21/45
changent brutalement, la bande passante Iub diminue drastiquement et que beaucoup
dutilisateurs HSD trafiquent (mme sil ny a que deux, voire quatre qui sont servis en mme
temps durant le mme TTI, suivant le nombre de codes HS-SCCH rservs). Il y a galement la
situation d overload , quand la puissance totale consomme dans la cellule excde 90%.

Evnement Compteur

#10813 VS.HsdpaDiscMACdPDUsTimerExpiry
Situations d under-run #10814
VS.HsdpaDiscTransportBlocksOnMaxRetrans
Puissance PA consomme > 90% #10817 VS.HsdpaPAOverload

2.3.3.1Blocage ltablissement

Quand il intervient, il ny a rien faire, un nouveau RAB HSDPA ne sera admis que lorque le
nombre dutilisateurs est au plus gal 19. Ce blocage peut tre lune des causes dchecs
dune mobilit vers une cellule HSD.

2.3.3.2Congestion en situation de mobilit

Un compteur est disponible, et trois screenings par type de mobilit :

Mobilit Compteurs
#951 VS.HsdpaMobilityUnsuccessful
HSDPA -> R99
screening 2
R99 -> HSDPA screening 1

HSDPA -> HSDPA screening 0

2.3.3.3Arbre de dcision

22/45
 Dtection dchecs de mobilit
HSDPA, screenings 0, 1 et 2

-Si frquence partage, rajouter

une porteuse
HSD -> HSD ou Oui Limite CAC Non -Si HSDPA Overload, utiliser
R99 -> HSD ? HSD? PA haute puissance

Non
Oui Aucune action

HSDPA -> R99? Oui Cf congestions RB

Non
-Activation de l Iub Bandwidth
Limitation
-Redimensionnement Iub (car il
Under-run ? Oui nest pas possible de maitriser
les conditions radio)
-Ajout porteuse

2.4 Analyse dune situation de blocage

Il convient tout dabord de dfinir la priode rfrence pour lanalyse de la congestion.

Communment appele Busy Hour , elle est base sur lheure de la journe la plus charge
en terme de procdure Radio Bearer Setup Request , calcule pour chaque cellule, tous les
jours. Bien sr, cet indicateur diffre dune cellule une autre, dun jour lautre.

Linconvnient ici est que Busy Hour est une notion globale pour CS et PS, alors quen
pratique Busy Hour PSest diffrente de Busy Hour CS

On pourrait penser amliorer la mthode en analysant deux Busy Hour diffrentes (CS&PS),
mais les indicateurs disposition ne permettent pas de sparer ltude en une partie sur le CS
et une autre sur le PS.

Linvestigation commence par la premire phase dtablissement dappels et concerne donc les
congestions RRC (cf arbre de dcision au 3.3.1). Si la congestin napparat pas ce niveau, on
passe lanalyse de la congestion au niveau de ltablissement ou de la reconfiguration de RB
(cf arbre de dcision au 3.3.2.9). Sil sagit de RAB HSDPA, dmarrer lanalyse conformment
larbre de dcision en 3.3.3.3.

23/45
3 Nouveauts UA5

3.1 Downlink iRM

Le principe global ne change pas par rapport lUA4.2, ce qui est nouveau cest lintroduction
de la charge en ressources CEM DL (reprsente par une couleur), qui va influer sur la couleur
NodeB (gale au maximum entre la couleur Iub et celle de CEM).

3.1.1 Charge CEM DL

3.1.1.1Capacit CEM vue en temps rel par le RNC

Un nouveau critre de ressources est dsormais pris en compte en UA5 pour calculer la couleur
dune cellule : lutilisation des ressources de traitement en bande de base.

Pour pouvoir calculer la charge CEM, le RNC a besoin de recevoir des informations sur la
capacit NodeB. Ceci se fait laide du message NBAP Ressource Status Indication. A travers
ce message, le NodeB informe le RNC du crdit CEM (ressources disponibles) ainsi que des lois
de consommation.

Il est noter que cette information concerne uniquement les ressources DBBU (tout ce qui est
DCH et CCH). Pour le HSDPA et E-DCH, il ny a pas de modlisation disponible. Les cartes iCEM
portant que des DBBU ainsi que les CEM Alpha sont de ce fait les seules concernes.

Nous nallons pas rentrer dans les dtails des lois de consommation, par contre il est utile de
savoir dans quels cas le RNC utilise ces lois pour calculer au plus juste les ressources CEM UL et
DL.

Toutes ces procdures donnent lieu un calcul de la consommation de crdits CEM :

24/45
Succs NBAP RL Setup ou RL Addition (les cots SF en UL et DL sont rajouts)

NBAP RL Deletion + toute autre dcision RNC de supprimer en interne un RL sans utiliser une
procdure NBAP (les cots SF en UL et DL sont supprims)

Succs NBAP RL Reconfiguration (les cots SF en UL et DL sont rajouts et les cots

antrieurs sont supprims)

Succs NBAP Common Transport Channel Setup (applicable aux SCCPCH & PRACH)
Succs NBAP Common Transport Channel Deletion (applicable aux SCCPCH & PRACH)
NBAP Cell Delete (this means that all channels in the cell are deleted) : consommation de
crdits ramene 0.
Cell Setup : (applicable uniquement au P-CCPCH qui va avoir un cot donn par son SF)

Une seule procdure nest pas concerne, NBAP Compressed Mode Command.

3.1.1.2Dtermination de la couleur CEM

Trois couleurs sont possibles : vert, jaune et rouge. Le principe est le mme que pour la
puissance ou les codes : des seuils de sparation entre les trois couleurs, dans le sens croissant
et dcroissant de classifocation des couleurs, sont dfinis. La couleur de la cellule est
dtermine de la faon suivante :

La couleur CEM, une fois calcule, est applique toutes les cellules dun mme
LocalCellGroup :

25/45
3.1.2 Paramtres

Il sagit de paramtres pour lactivation de lvaluation de la culeur CEM, et de seuils de

dclenchement pour les couleurs, relatifs une charge dutilisation.

Le paramtre dactivation suivant vaut pour les couleurs UL et DL :

Le parmtre suivant dfinit la couleur CEM DL utiliser par dfaut si le modle nest pas
valide :

Cest justement le paramtre suivant qui permet de configurer ou pas le modle, donc sil est
False cela veut dire que la couleur considrer est la couleur par dfaut (dfinie juste au-
dessus) :

26/45
Tous les seuils configurables sont dfinis ci-dessous :

3.1.3 Compteurs de congestion CEM DL

Tout dabord pour la dtection de cette congestion, on utilise lindicateur suivant, par cellule :

Compteurs Taux dchecs

#631
Echecs RB #631.7 / #625.i
VS.RadioBearerEstablishmentUnsuccess
Setup
screening 7 : pas de ressources CEM DL
o i: tous les DLAsConf des
Tentatives #625 VS.RadioBearerSetupRequest
RAB CS et PS
RB Setup screenings : tous les RAB CS et PS

Pour la caractrisation de la couleur CEM DL, trois compteurs sont disponibles, par cellule :

Un compteur disponible par Local Cell Group peut tre trs utile pour cette tude (mme si la
couleur CEM est une notion globale par NodeB donc sapplique toutes les cellules) :

Avec deux screenings : 0 pour les ressources libres et 1 pour ce qui est utilis. Ce compteur ne
fait par contre pas la distinction entre ressources CEM UL et DL.

27/45
3.2 Uplink iRM

Cest une nouveaut en UA5, base sur deux nouvelles fonctionnalits qui sont lestimation de
la charge CEM UL et de la charge radio UL. Lobjectif, bien entendu, est darriver tablir une
couleur UL de cellule.

3.2.1 Charge CEM UL

Le principe est exactement le mme que pour la charge CEM DL dcrit en 4.1.1, et les
paramtres identiques, part la nomenclature ou il faut remplacer DL par UL.

Lindicateur pertinent pour la dtection de la congestion CEM UL est le suivant :

Compteurs Taux dchecs

#631
Echecs RB #631.8 / #625.i
VS.RadioBearerEstablishmentUnsuccess
Setup
screening 8 : pas de ressources CEM UL
o i: tous les DLAsConf des
Tentatives #625 VS.RadioBearerSetupRequest
RAB CS et PS
RB Setup screenings : tous les RAB CS et PS

Les compteurs caractrisant la couleur CEM UL par cellule sont les suivants :

3.2.2 Charge radio UL

Appele Uplink load, sa caractrisation est essentielle pour :

- les canaux E-DCH, qui sera associe la charge UL non utilise par les canaux non E-DCH

- dterminer la charge UL dans la cellule pour prendre en compte lalgorithme CAC UL bas sur
lUplink load

- dterminer la couleur Uplink load dune cellule qui sera utilis par liRM au niveau RNC.

3.2.2.1Estimation

La charge radio UL est donne par la formule suivante :

RoT reprsente le Rise over Thermal noise et est gal la diffrence entre le RTWP non E-DCH
et la valeur rfrence de RTWP (Received Total Wideband Power).

La valeur rfrence de RTWP est calcule au bniveau NodeB par le module Callp CCM, laide
dun algorithme de self learning, lorsque la charge uplink est nulle. Cette valeur rfrence ne
peut varier de plus de 0,5 dB dun jour lautre.

28/45
Il est noter que la valeur de RTWP non E-DCH inclut la contribution des canaux R99 UL mais
galement la contribution des canaux E-DCH dautres cellules (interfrences extra-cellulaires).

Sans rentrer dans les dtails des formules, nous pouvons dire que des paramtres tels que la
temprature et la constante de Boltzmann interviennent dans le calcul de la charge UL.

La charge UL non E-DCH est transmise par le nodeB au RNC, qui va retrancher -106,1 dBm
(bruit thermique) pour obtenir la valeur de RoT et ainsi arriver calculer la charge UL :

Le bruit thermique est gal la valeur rfrence de RTWP.

3.2.2.2Paramtres

Tout dabord voici le paramtre permettant dactiver la fonctionnalit au niveau NodeB:

On dfinit par objet BTSCell le bruit thermique :

29/45
Et par FDDCell, on indique la limite de RoT ne pas dpasser :

La recommandation serait de garder RoT <= 8 dB sous peine de rendre le systme instable. On
pourrait utiliser un seuil 80% de la charge maximale UL pour le R99 et le trafic E-DCH, par
exemple :

Pour activer le contrle dadmission UL non E-DCH bas sur le RTWP par cellule, on utilise la
paramtre suivant :

Et pour permettre de jouer sur le trafic dadmission pour favoriser ou pas le trafic E-DCH, on
utilise ce paramtre, qui fixe une limite dadmission UL pour tout trafic non E-DCH, par exemple
ci-dessous une valeur de 50% a t retenue :

Il faut bien entendu veiller respecter lingalit suivante lorsquon veut modifier ce
paramtre :

30/45
3.2.2.3Compteurs disponibles

Lestimation de la charge UL est remonte par le compteur suivant :

#10211 Counter_Name: CellULLoad

FRS: 27745 Description: UL load management Standard: No
Apply to: BTSCell Unit: 0.1% Range: 0-1000 Type: LOAD
Meaning: The mean UL Load value
Triggering event: At each Load estimation: fixed period depending on RNC filtering parameter.
First release: UA5.0 Last release: * Family: Radio statistics
3GPPname: VS.CellULLoad
Screening: No
Notes:

Les checs dadmission UL pour cause de charge UL sont reports de la manire suivante :

#10213 Counter_Name: FailedAdmissionDueToULLoad

FRS: 27745 Description: UL load management Standard: No
Apply to: BTScell Unit: EVENT Range: 0-2^31-1 Type: VAL
Meaning: Total number of failed UL admission due to excessive load in the cell
Triggering event: At each UL admission proposed by RNC
First release: UA5.0 Last release: * Family: Radio statistics
3GPPname: VS.FailedAdmissionDueToULLoad
Screening: No
Notes:

3.3 RNC Overload

3.3.1 Principe

Le contrle de saturation est implant au niveau du software et ne peut tre dsactiv. Il

permet, par des mcanismes de filtrage, de soulager le RNC lorsque les ressources sont
sollicites de faon importante. Ce contrle peut agir sur les diffrentes ressources, six niveaux
dalerte sont disponibles sur les cartes logiques Cnode, PMC-OMU et PMC-TMU:

OAM_OV_LEVEL_OK
OAM_OV_LEVEL_MINOR
OAM_OV_LEVEL_MAJOR
OAM_OV_LEVEL_CRITIC
OAM_OV_LEVEL_PLATFORM_CRITIC_1
OAM_OV_LEVEL_PLATFORM_CRITIC_2

Et quatre niveaux pour les cartes logiques Inode, PMC-M, PMC-RAB et PMC-NI:

NO_OVERLOAD
MINOR_OVERLOAD
MAJOR_OVERLOAD
CRITICAL_OVERLOAD

Sachant que la saturation Cnode est gale au maximum de celle des TMU, et que la saturation
Inode est gale au maximum de celle des PMC-M et PMC-RAB, la saturation globale Global

31/45
Overload est le maximum entre celle du Cnode et du Inode (les cartes CP3 grent leur
saturation de faon autonome en arrtant les Call Trace lorsquil y a un risque de congestion).

Lorsquune situation de saturation survient, pour chaque type de procdure (RRC Connection
Request, SCCP connection request/indication, Paging, Uplane admission control, Uplane
background class, Call Trace), chaque carte logique commence effectuer le filtrage adquat
en fonction de son implication dans la procdure, et en fonction de la gravit de la saturation
constate.

3.3.2 Paramtres

Tout dabord, il convient de configurer le niveau dalerte. Le paramtre suivant indique le

niveau aprs lequel le RNC dclenche la situation de Global Overload :

Le paramtre suivant permet de dclencher le filtrage de Paging au niveau TMU lorsque les
conditions saturation MAJOR ou CRITICAL sont atteintes :

Il en va de mme pour les procdures RRC Connection :

32/45
On peut contrler le temps dattente ct mobile (avant une nouvelle demande RRC) suite la
rception du RRC Connection Reject par le paramtre suivant :

Il convient de manipuler ces quatre paramtres avec prcaution et de sappuyer sur les
recommendations conctructeur correspondant des valeurs par dfaut ayant servi valider le
mcanisme dOverload (cest le cas pour les valeurs ci-dessus).

3.3.3 Compteurs

Voici la liste des compteurs utiliss pour surveiller la saturation RNC toutes les chelles,
commencer par ceux renseignant sur lutilisation des Logical Processor :

Les compteurs se rapportant aux Adjunct Processor sont les suivants :

33/45
Dautres mcanismes comme la gestion de la saturation Core Network ou la fonctionnalit
Automatic Cell and Class Barring peuvent galement savrer trs utiles pour viter certaines
congestions.

3.4 Compteurs utiles pour la charge

Dornavant, il est possible davoir une distribution de la puissance DL utilise suivant plusieurs
paliers laide de ces deux compteurs :

34/45
La distribution de RSSI est dsormais disponible en UA5 :

35/45
4 Dmarche prdictive

La dmarche de prdiction dutilisation de ressources CEM et Radio plusieurs semaines

repose sur la tendance macroscopique du trafic ainsi que la tendance au niveau cellule (
condition davoir un volume dappels suffisant).

Dans le dimensionnement, la qualit que lon veut obtenir est troitement lie aux cots des
investissements que lon sautorise. C'est--dire quil faudra dfinir des variables dentre au
niveau macroscopique et microscopique, ainsi que la loi correspondante afin de dclencher au
bon moment laugmentation de capacit (radio ou CEM ou Iub dans notre cas).

Nous pouvons dcrire une dmarche en plusieurs phases :

PHASE1 : Evolution du trafic

Coefficient dvolution du trafic avec prvision un mois : Evo_trafic_NodeB

Sources dinformation : Granularit
1) Volume dappels par semaine Fin
2) Volume dappels Pic Hour du Pic Day de la semaine Fin
3) Volume dappels 2me Pic Hour du Pic Day de la semaine Fin
4) % de congestion CEM ou Radio Moins fin (une ou 2 congestions
par semaine ne permet pas dtablir une prvision)
5) % dgradation Pas disponible par
cellule
6) Charge CEM ou radio moyenne et max Pic Hour du Pic Day de la semaine : Fin
7) Charge CEM ou radio moyenne et max 2me Pic Hour du Pic Day de la semaine :

(Types dinterpolation linaire polynomiale dordre 2 sur 2 mois : 8

valeurs)

Nous retiendrons les solutions 1,2,3,6,7 pour les loi dvolution du

trafic sur un mois partir du jour de vrification des compteurs.
On appellera le coefficient dvolution du trafic cellule Radio :
Evo_trafic_Cell et pour le NodeB, Evo_trafic_NodeB

Evo_trafic_Cell,
Evo_trafic_Node
B

36/45
 PHASE2 : Priode dobservation du trafic actuel et qualit observe

- Sur quelle qualit veut-on sengager ?

o Exemple : Ne pas dpasser un taux global rseau de
congestion Radio ou CEM de 1,5% sur le 2me Pic hour
pour une semaine donne.
o Ne pas dpasser un taux congestion Radio ou CEM de
1,5% sur le 2me Pic hour 5 jours sur 2 semaines

- Quelle est la priodicit de calcul et de vrification :

Hebdomadaire
- Priode dobservation : on prendra par exemple J J-14
- Pour les prdiction, on etabliera une extrapolation sur les 30
jours suivants avec le coefficient de variation du trafic de la

Coefficient de variation du Prdiction de la

trafic sur 8 semaines (J-60) congestion de J J+30

Remarques:

- Pour la partie CEM, on

prendra les congestions en
additionnant les
occurrences de toutes les
cellules du NodeB considr

- Pour la partie Radio, on

prendra les congestions de
la cellule tudie

PHASE3 : Limites atteintes ct CEM out/et ct radio

Utilisation des algorithmes de dtection dcrits dans les logigrammes

Limites atteintes avant un mois ct Limites atteinte avant un mois ct cellule

37/45
4.1 Dfinition des indicateurs impliqus

Indicateur de ltat de charge radio dune cellule

-Ratio de temps durant lequel une cellule est rouge, rapporte la charge en codes et/ou en
puissance, on parle de couleur radio :

#1124 : VS.IrmTimeCellRadioColourRed

Indicateurs lis la dgradation des RAB PS :

-Pas dindicateurs disponibles par cellule pour le taux de RAB PS dgrads par liRM CAC.

Indicateur de ltat de charge Iub

-Ratio de temps durant lequel la bande passante utilise en DL, vue par le RNC, a atteint le
seuil de saturation correspondant la couleur rouge :

#1148 : VS.IrmTimeDlIubTransportColorRed

-Ratio de temps durant lequel la bande passante utilise en DL, vue par le RNC, a atteint le
seuil de saturation correspondant la couleur jaune :

#1155 : VS.IrmTimeDlIubTransportColorYellow

Indicateur de lutilisation des codes OVSF DL

-Nombre de codes libres par type de SF :

#1126 : VS.IrmTimeFreeDlCodesBySpreadingFactor

Les diffrents screenings sont {0,1,2,3,4,5,6} correspondant respectivement aux SF

{4,8,16,32,64,128,256}.

Les valeurs min, max et moyenne sont disponibles. Dans cette tude, nous allons traquer la
valeur minimale de codes libres sur le SF 8 (PS 384 DL) pour voir si cette valeur diminue ou pas
durant la priode dobservation dun mois. Une valeur minimale de 3 qui commence persister
peut tre un bon indicateur de congestion future en codes OVSF.

Indicateur dutilisation de puissance DL

-Ratio puissance utilise par puissance totale disponible, par cellule :

#1002 / Puissance PA

Avec #1002 : VS.AvgTxPower

On pourrait fixer le seuil critique 80% par exemple. Une valeur de cet indicateur persistant au
dessus de 60% indiquerait un charge consquente en terme dutilisation de puissance DL.

Indicateur de ltat de charge des processeurs TMU

38/45
 -Pas de compteurs disponibles pour le RNC1500, qui donnent le pourcentage dutilisation des
processeurs TMU.

Remarques sur les indicateurs :

- Les compteurs de congestion sont difficilement exploitables au niveau microscopique car le

volume la cellule est faible puisque la fonctionnalit Always-ON Cell FACH est active.
Ils pourront tre utilis plus efficacement seulement au niveau macroscopique.

- Les indicateurs de dgradation de RAB ltablissement nimpliquent que le PS et ne sont pas

distribus par cause CEM et radio. Par ailleurs, ils ne sont pas exploitables au niveau cellule.
Citons comme exemple le compteur #1112 : VS.iRMcacDowngradedHighPriority[DlRbSet
screening], qui donne le nombre de RAB PS DL global par RNC qui ont t dgrads par liRM
CAC pour un service PS particulier, pour la classe dutilisateurs les plus prioritaires.

- Les indicateurs disponibles sont discontinus puisquils calculent une couleur.

- Lorsque la congestion radio ou CEM est atteinte, il y a eu une phase intermdiaire avec des
dgradations iRM CAC pour les services PS.

4.2 Arbre de dcision pour la prdiction

CEMUsed.Max dpasse 90% et Couleur jaune persistante,

CEMUsed.Avg suprieur 60% possibilit dapparition de la
frquemment couleur rouge

Oui Non
Extension CEM(DBBU) Indicateurs de charge
CEM atteints Indicateurs de charge
cellule atteints

Action :
Oui
-Vrifier les seuils iRM CAC pour le
lien radio (Ec/No et RSCP) ainsi que Charge en codes et/ou en
pour la charge en codes et en puissance en
puissance. augmentation
-Tuner les paramtres si ncessaire
Non

Couleur Iub rouge de temps en

temps et couleur jaune Charge critique atteinte
persistante pour la bande passante
Iub

Oui Oui

Ajouter un E1 Paramtrage conforme? Vrifier que la fonctionnalit Iub

Bandwidth Limitation est active (utile
surtout pour le HSDPA), ainsi que les

Non
Insuffisant
Repositionner
paramtres: BDE ref
OMC
39/45
5 Conclusion
Ce cahier mtier dcrit les analyses et actions possibles en fonction des algorithmes,
compteurs et paramtres disponibles sur lUTRAN Nortel UA4.2.

Ce document contient galement une vue densemble des nouvelles fonctionnalits disponibles
en UA5 comme lUL iRM, le niveau de charge CEM (une couleur parmi vert/jaune/rouge), la
gestion de la saturation au niveau RNC

Une partie lie aux prochaines exprimentations sera dtaille, et des logigrammes seront mis
en uvre pour la partie prdiction de charge, sappuyant sur les deux niveaux dalerte dfinis.

40/45
41/45
6 Annexes

6.1 Indicateurs OSIRIS

Le fichier Excel en attach donne la liste de toutes les mtriques exploitables pour la
congestion.

E:\
KPIs_QoSCongestionDowngrade_Non contractuels.xls

6.2 Exemple de congestion CEM dtecte et corrige

Le tableau Excel suivant montre un exemple concret de congestion :

date_debut_mesur c10301_Av c10301_Ma c10301_Mi c1030

sn e duree g x n 2
NodeB-IVRY-TREMOULET 14/06/2007 90000 63.57 96 0 85
NodeB-IVRY-TREMOULET 15/06/2007 90000 50.66 98 0 22
NodeB-IVRY-TREMOULET 16/06/2007 90000 27.65 47 17 0
NodeB-IVRY-TREMOULET 17/06/2007 90000 24.60 52 17 0
NodeB-IVRY-TREMOULET 18/06/2007 90000 29.39 57 20 0
NodeB-IVRY-TREMOULET 19/06/2007 90000 25.75 53 17 0
NodeB-IVRY-TREMOULET 20/06/2007 90000 24.24 55 17 0

Les deux lignes en rouge correspondent la dtection de la charge leve en ressources CEM.
Une extension CEM a eu lieu et par consquent, la charge en ressources de traitement en
bande de base a considrablement baiss, et il ny a plus dchecs dallocations de ressources
CEM (compteur #10302 : CEMAllocFail passe zro aprs lintervention).

42/45
6.3 iRM Preemption

6.3.1 Prsentation

Cest un mcanisme similaire celui implment pour liRM CAC (bas sur lvaluation de la
couleur de la cellule), la diffrence prs que la premption utilise ses propres seuils. Nous
pouvons donc dire que ce sont deux mcanismes qui tournent en parallle.

Le principe de cet algorithme consiste dgrader tous les RAB PS DL existants dans une cellule
charge qui a atteint la couleur noire (seuils de dclenchement de la premption). La table
iRM est consulte pour donner le nouveau RAB PS DL utiliser pour tous les appels en cours.
Cependant, lalgorithme a recours au pire des cas (donne de la table iRM correspondant un
mauvais lien radio et une cellule rouge).

Lide serait dutiliser des seuils au-dessus de ceux de liRM CAC pour la sparation entre ltat
Normal et ltat Congested vus par le mcanisme de premption. En voici un exemple pour
la puissance (a vaut galement pour les codes et lIub):

Sachant quil faut respecter lingalit suivante (comme pour les cas iRM CAC) :

Il convient de faire une analyse pralable de limpact de cette fonctionnalit avant de penser
lactiver. La TV Live reprsentant lessentiel du trafic PS DL sur le rseau Orange France 3G
(avec un RAB minimum de 128 Kbps DL exig pour une fluidit optimale), le fait dutiliser cette
fonctionnalit va faire en sorte que lorsquune cellule devient noire et quun nouvel utilisateur
sollicite un service PS, tous les autres utilisant du PS 128DL ou 384 DL seront dgrads en PS64
DL et du coup ils ne pourront plus accder la tlvision dans de bonnes conditions. Bien sr,
le nouvel entrant devrait avoir les ressources ncessaires pour profiter du service.

43/45
6.3.2 Paramtres

Activation de la fonctionnalit, utilisateurs concerns (classes Gold, Silver et Bronze):

Exemple de seuils pour la puissance :

Seuils Iub :

Ici le seuil de 90% permet de passer trois PS384 sur un E1 (80% dutilisation de la bande
passante) sans atteindre ltat Congested.

44/45
6.3.3 Compteurs

Voici les compteurs disponibles par cellule :

Et ceux ayant une granularit RNC :

45/45