Optimisation

Optimisation et qualité de
service du réseau Mobilis
Nicolas LEMARCHAND
SOMMAIRE
1. Utilisation de RNO________________________________________________________4
2. Utilisation de NPA________________________________________________________5
2.1 Présentation de l’outil________________________________________________________5
2.2 Les différents modules________________________________________________________5
2.3 Les indicateurs de qualité de service_____________________________________________9
2.3.1 Définitions préalables____________________________________________________________9
2.3.2 Indicateurs détaillés_____________________________________________________________10
2.3.2.1 Relatifs aux canaux TCH_______________________________________________________10
2.3.2.2 Relatifs aux canaux SDCCH____________________________________________________11
2.3.2.3 Relatifs aux canaux d’accès PCH et AGCH________________________________________12
2.3.2.4 Relatifs aux handovers_________________________________________________________12
2.3.2.5 Relatifs aux causes de Handovers________________________________________________13
2.3.2.6 Relatifs aux bandes d’interférences_______________________________________________15
2.3.3 Différence entre Drop Call et Drop TCH____________________________________________15
2.3.3.1 Drop TCH___________________________________________________________________16
2.3.3.2 Drop Call___________________________________________________________________16
2.3.3.3 Relation Drop Call / Drop TCH__________________________________________________16
2.4 Méthodologie d’optimisation__________________________________________________17
2.4.1 Sortie des alerteurs quotidien_____________________________________________________17
2.4.2 Focalisation sur les indicateurs prioritaires des alerteurs/Détection des BTS à analyser_______18
2.4.3 Sortie des indicateurs généraux des BTS à analyser___________________________________19
2.4.4 Comparaison de ces indicateurs à des seuils d’alarme__________________________________20
2.4.5 Mise en corrélation de ces indicateurs dégradés_______________________________________21
2.4.6 Identification des problèmes / utilisation de fiches d’analyse_____________________________21
2.4.6.1 Précision sur les fiches d’analyse_________________________________________________21
2.4.6.2 Fonctionnement des fiches d’analyse______________________________________________21
2.5 Fiches d’analyse____________________________________________________________23
2.5.1 Fort taux d’échec de Handovers entrants____________________________________________23
2.5.2 Fort taux de Handovers sur qualité descendante______________________________________27
2.5.3 Fort taux de Handovers sur qualité montante_________________________________________31
2.5.4 Fort taux de Handovers sur niveau descendant________________________________________35
2.5.5 Fort taux de Handovers sur niveau montant__________________________________________38
2.5.6 Fort taux de Handovers sur interférences descendantes_________________________________42
2.5.7 Fort taux de Handovers sur interférences montantes___________________________________45
2.5.8 Fort taux d’échec de handovers sortants_____________________________________________48
2.5.9 Temps de communication faible____________________________________________________51
2.5.10 Forte saturation SDCCH_________________________________________________________54
2.5.11 Trafic par HO uniquement________________________________________________________58
2.5.12 Trafic par établissement d’appel uniquement_________________________________________58
2.5.13 Résolution d’un brouillage interne_________________________________________________59
2.5.14 Dimensionnement des canaux d’accès : AGCH, PCH, SDCCH___________________________60
2.5.14.1 Capacité des canaux PCH____________________________________________________60
2.5.14.2 Allocation d’un canal SDCCH_________________________________________________60
2.5.14.3 Interaction SDCCH/AGCH___________________________________________________61
2.5.14.4 Résumé de la configuration des canaux__________________________________________62
2
Introduction
Ce document a pour but de décrire les processus nécessaires à l’optimisation et au

suivi de la qualité de service du réseau GSM Mobilis de la Société Camerounaise de Mobile.
Ces processus ne sont réellement nécessaires que lorsque le déploiement du réseau est en
phase de densification ce qui est maintenant le cas sur Douala et Yaoundé.
Les deux points clés de la bonne gestion de la qualité de service et de son optimisation
sont les suivants :
 Assurer une cohérence totale des bases de données radio avec le terrain. C’est une des
fonctions principales de l’outil Alcatel RNO.
 Détection et correction des BTS présentant des indicateurs de qualité de service mauvais.
Ceci sera réalisé grâce à l’outil NPA.
3
1. Utilisation de RNO
4
2. Utilisation de NPA
2.1 Présentation de l’outil
NPA est un outil d’analyse des performances d’un réseau GSM. Cet outil
permet d’observer les entités suivantes :
- cellules
- MSC/ VLR
- HLR
- LAC
- liens LAPD
- canaux sémaphores 7 (données générées par les BSC et les MSC)
- processeurs BSC, MSC, HLR
- faisceaux téléphoniques (données générées par les MSC)
Cet outil collecte donc les compteurs bruts issus de l’OMC pour en faire des
indicateurs de qualité de service.
2.2 Les différents modules
Lors du lancement de NPA, on voit s’afficher une fenêtre représentant

différents modules dont les principaux sont :
 Daily Operation
 Historical Reporting
 DICO
Pour les deux premiers modules, on a la possibilité de représenter les données sous la
forme de graphiques ou de tableaux grâce aux menus Display, Report et Graph :
 Daily Operation : menus Display, Report et Graph

 Historical Reporting : menus Report et Graph
Le mode Display permet :
 analyse des compteurs d’un élément particulier du réseau

 visualisation graphique valeurs / temps
 jusqu’a trois attributs d’une ou plusieurs tables de la base de données
Le mode Report permet :
 analyse d’un aspect particulier des performances d’un ensemble d’éléments du réseau
 visualisation sous forme de tableau
 recherche et sélection d’éléments
5
Le mode Graph permet :
 analyse d’un aspect particulier des performances d’un élément du réseau

 visualisation graphique des données
DAILY OPERATION
Les principales caractéristiques de ce module sont les suivantes :
 visualisation graphique et tabulaire des compteurs de performances

 données brutes collectées toutes les 15, 30 ou 60 minutes
 analyse des données sur un ou plusieurs jours
Le mode Display permet la visualisation des courbes relatives :
 aux canaux TCH et SDCCH des cellules

 aux HandOvers et aux causes des HandOvers
 au traffic MSC
 aux HandOvers et aux causes des HandOvers des MSC
 aux HLR, VLR
 aux canaux sémaphore 7 gérés par les BSC, MSC et HLR
Le mode Report permet l’obtention de tableaux relatifs :
 au trafic TCH, SDCCH des cellules d’un BSC, d’un MSC, d’une région ou d’une
aréa.
 au trafic des faisceaux
 au trafic des MSC
 aux HandOvers et causes de HandOver au niveau cellules et MSC
Le mode Graph permet la visualisation des graphiques prédéfinis suivants :
 trafic des canaux TCH et SDCCH des cellules

 HandOver au niveau cellules et MSC
 cellules congestionnées ou HS
 mise à jour de localisation et de paging au niveau d’une LAC
 charge des processeurs BSC, MSC ou HLR
6
 trafic TCH de toutes les cellules d’un BSC ou de toutes les cellules du système
 trafic et congestion des faisceaux
 performances des HLR
HISTORICAL REPORTING
Les principales caractéristiques de ce module sont les suivantes :
 visualisation sous forme de rapports et de graphiques

 données résumées au jour, à la semaine ou au mois
 données moyennées à l’heure chargée du jour et à l’heure chargée sur la période
choisie
 étude de l’évolution des performances d’un élément du réseau
Le mode Report permet l’obtention des types de rapport résumés suivants :
 trafic des canaux TCH et SDCCH

 HandOvers
 analyse de congestion TCH et SDCCH
 trafic au niveau MSC
Le mode Graph permet la visualisation de graphiques prédéfinis. La période

d’analyse peut être la Busy Hour de l’élément, la BH du système ou la période totale. Les
principaux types de graphes sont les suivants :
 trafic, appels bloqués ou perdus au niveau des canaux TCH et SDCCH des cellules
 HandOvers et congestion au niveau cellule et BSC
 trafic total du système
 charge des processeurs
 analyse par LAC
7
DICO
Les différents menus intéressants sont les suivants :
 Warning
Ce menu permet de donner la liste des cellules dont les indicateurs dépassent des seuils
d’alarmes de qualité de service. Les indicateurs disponibles sont les indicateurs sur les canaux
TCH et SDCCH, les Handovers entrants et sortants inter ou intra BSC ainsi que les causes de
Handover.
Ce menu fonctionne aussi pour un BSC complet.
 Evolution
Ce menu a exactement la même fonction que les menus Display et Graph des modules Daily
Operation et Historical Reporting c’est à dire qu’il permet d’avoir l’évolution graphique des
différents indicateurs de qualité de service que ce soit heure par heure, jour par jour, semaine
par semaine ou mois par mois pour :
- Les TRX d’une BTS

- une BTS
- un BSC
- une aréa créée par l’utilisateur (ensemble de cellules)
- tout le réseau
 Graphic
Ce menu permet à l’utilisateur de créer ses propres graphiques si jamais il n’était pas
satisfait par ceux proposés dans le menu « Evolution ». Cette fonction est disponible pour une
BTS comme un BSC ou tout le réseau en entier.
 Topologie
La fonction principale de ce menu est de pouvoir connaître la topologie de son réseau

GSM c’est à dire de donner pour chaque cellule :
- son nom
- son CI
- sa LAC de rattachement
- son BSC de rattachement
- son nbre de TRX
 Dimensionning
Ce menu permet de prévoir l’évolution du trafic sur une cellule en utilisant différents
modèles de croissance :
- linéaire
- logarithmique
- exponentielle
8
Il serait d’ailleurs intéressant de voir quel modèle de croissance de trafic convient le
mieux au réseau Mobilis !
 Cell-cell
Ce menu permet en théorie d’avoir les flux de Handovers entrants et sortants d’une BTS
avec toute ses voisines. Ceci ne marche malheureusement pas sur Alcatel car ces compteurs
sont issus des jobs type 26 et 27 qu’on ne peut lancer que sur une seule cellule à la fois.
Les menus Forecasting et Kingfisher sont moins utilisés en optimisation et ne seront

donc pas décrits ici.
2.3 Les indicateurs de qualité de service
2.3.1 Définitions préalables
Trafic : - mesure de l’utilisation des canaux d’un élément du réseau

- valeur en Erlang
Erlang : - unité de mesure de trafic

- valeur moyennée sur une période de temps : moyenne du temps d’occupation
d’un canal téléphonique pendant une heure.
Blocks : - nombre de tentative de prise d’un canal qui ont été rejetées car tous les
canaux sont déjà utilisés.
Dropped Calls : - nombre d’appels pour lesquels il y a eu une coupure intempestive de

la communication avant la fin normale de l’appel.
- par causes :
 RFLOSSES : perte de la fréquence radio

 HOLOSSES : coupure sur HandOver sortant
 MISCDROP : autres raisons
Congestion : - temps ou pourcentage de temps pendant lequel tous les canaux d’un élément
du réseau sont occupés.
Mean Holding Time (MHT) : - temps moyen d’occupation d’un canal pour la cellule
considérée.
Busy Hour (BH) : - heure de la journée pour laquelle le trafic est maximum.
Busy Day Busy Hour (BDBH) : - jour et heure de la semaine ou du mois durant lequel le
trafic est maximum. C’est la crête de trafic sur la période.
9
Grade Of Service (GOS) : - valeur de la probabilité de blocage lors d’une tentative de prise
de canal.
- calculé à partir du trafic effectivement écoulé et du nombre de
canaux disponibles.
- utilise les lois d’Erlang B ou d’Erlang C.
Design GOS (DGOS) : - valeur spécifiée par l’utilisateur comme seuil de probabilité de
blocage permettant de calculer la capacité. C’est le niveau de
service requis.
Carried Trafic (Trafic écoulé) : - trafic effectivement écoulé sur les circuits.
Offered Trafic (Trafic Offert) : - trafic qui serait écoulé si les circuits avaient unecapacité
infinie, calculé à partir du trafic effectivement écoulé et des lois
d’Erlang.
Lost Trafic (Trafic perdu) : - trafic offert moins le trafic écoulé.
Critical Trafic (capacité) : -trafic offert pour lequel la probabilité de blocage GOS atteint la
valeur seuil DGOS.
% d’utilisation : - (trafic offert / trafic critique) * 100
La valeur du trafic critique en fonction du nombre de TRX est la suivante :
NOMBRE DE TRX 2 3 4 5 6 7 8
ERLANG 8,2 14,89 21,03 28,25 34,68 41,9 48,33

( GOS 2% )
2.3.2 Indicateurs détaillés
2.3.2.1 Relatifs aux canaux TCH
TCH ASSIGNMENTS ATTEMPTS : tentatives de prise d’un canal TCH
TCH ASSIGNMENTS BLOCKED : tentatives de prise d’un canal TCH qui n’ont pas abouties
car tous les canaux TCH sont occupés.
TCH NORMAL ATTEMPTS : tentatives de prise directe TCH.
TCH HANDOVER ATTEMPTS : tentatives de prise TCH par HandOver.
10
TCH CONGESTION TIME : temps total en secondes pendant lequel tous les canaux TCH de
la BTS sont occupés c’est à dire indisponibles.
TCH SEIZURE DELAY : temps moyen en secondes d’attribution d’un canal TCH.
TCH SEIZURE FAILURES : échecs de prise d’un canal TCH.
TCH SEIZURES : prises réussies d’un canal TCH.
TCH NORMAL SEIZURES : prises directes TCH réussies.
TCH HANDOVER SEIZURES : prises TCH réussies qui se sont faites par HandOver
TCH RF LOSSES : coupures sur canal TCH dues à la perte de la fréquence radio.
TCH OTHER DROPPED : coupures sur canal TCH qui sont dues à d’autres raisons.
TCH TRAFFIC : trafic TCH en Erlang.
TCH MAX BUSY : nombre maximum de canaux TCH occupés à une période donnée.
TCH MEAN HOLDING TIME : temps moyen de prise d’un canal TCH en secondes.
AVAILABLE TCH : nombre de canaux TCH en service à une période donnée.
DEFINED TCH : nombre de canaux TCH dont la BTS est équipée. Ces canaux ne sont
pas forcement tous mis en service.
2.3.2.2 Relatifs aux canaux SDCCH
SDCCH ASSIGNMENTS ATTEMPTS : tentatives de prise d’un canal SDCCH
SDCCH ASSIGNMENTS BLOCKED : tentatives de prise d’un canal SDCCH qui n’ont pas
abouties car tous les canaux SDCCH sont occupés.
SDCCH CONGESTION TIME : temps total en secondes pendant lequel tous les canaux
SDCCH de la BTS sont occupés c’est à dire indisponibles.
SDCCH SEIZURE DELAY : temps moyen en secondes d’attribution d’un canal SDCCH.
SDCCH SEIZURE FAILURES : échecs de prise d’un canal SDCCH.
SDCCH SEIZURES : prises réussies d’un canal SDCCH.
SDCCH RF LOSSES : coupures sur canal SDCCH dues à la perte de la fréquence radio.
SDCCH OTHER DROPPED : coupures sur canal SDCCH qui sont dues à d’autres raisons.
11
SDCCH TRAFFIC : trafic SDCCH en Erlang.
SDCCH MEAN HOLDING TIME : temps moyen de prise d’un canal SDCCH en secondes.
AVAILABLE SDCCH : nombre de canaux SDCCH en service à une période donnée.
DEFINED SDCCH : nombre de canaux SDCCH dont la BTS est équipée. Ces canaux ne
sont pas forcement tous mis en service.
2.3.2.3 Relatifs aux canaux d’accès PCH et AGCH
PAGING ATTEMPTS : nombre de messages de recherche de personne rencontrés sur

l’interface Abis (utilisation du canal PCH).
PAGING FAILURES : nombre de messages de recherche de personne ( utilisation du canal

PCH) qui ont échouées.
IMMEDIATE ASSIGNMENT ATTEMPTS : nombre de canaux requis (y compris les causes

non valides) rencontrés sur l’interface Abis (utilisation du canal RACH)
IMMEDIATE ASSIGNMENT SUCCESSFUL : nombre de messages de commande

d’affectation immédiate rencontrés sur l’interface Abis (utilisation du
canal AGCH)
2.3.2.4 Relatifs aux handovers
SUCCESSFULL INTRA CELL HO : HandOvers intra BTS réussis.
FAILED INTRA CELL HO : échecs de HandOver intra BTS .
INTRA CELL HO RESSOURCE LACKING : échecs de HandOver intra BTS dus à un manque
de ressources c’est à dire que tous les canaux sont déjà occupés.
INTRA CELL HO SEIZURE FAILED : échecs de HandOver intra BTS du coté mobile.
INTRA CELL HO BSS FAILURE : échecs de HandOver intra BTS du coté équipement BSS et
non attribuables au MS.
INTRA CELL HO RETURN TO OLD : échecs de HandOver intra BTS avec retour sur ancien
canal.
SUCCESSFULL INCOMING INTER CELL HO : HandOvers intra BSC entrant réussis.
FAILED INCOMING INTER CELL HO : échecs de HandOver intra BSC entrant.
12
INCOMING INTER CELL HO RESSOURCE LACKING : échecs de HandOver intra BSC
entrant dus à un manque de ressources.
INCOMING INTER CELL HO SEIZURE FAILED : échecs de HandOver intra BSC entrant
du coté mobile.
INCOMING INTER CELL HO BSS FAILURE : échecs de HandOver intra BSC entrant du
coté équipement BSS et non attribuables au MS.
SUCCESSFULL OUTGOING INTER CELL HO : HandOvers sortants intra BSC réussis.
FAILED OUTGOING INTER CELL HO : échecs de HandOver sortants intra BSC.
OUTGOING INTER CELL HO RETURN TO OLD : échecs de HandOver sortants intra BSC
avec retour sur ancien canal.
OUTGOING INTER CELL HO BSS FAILURE : échecs de HandOver sortants intra BSC du
coté équipement BSS et non attribuables au mobile.
SUCCESSFULL INCOMING MSC INTER CELL HO : HandOvers inter BSC entrant réussis.
FAILED INCOMING MSC INTER CELL HO : échecs de HandOver inter BSC entrant.
INCOMING MSC INTER CELL HO RESSOURCE LACKING : échecs de HandOver inter

BSC entrant dus à un manque de ressources.
INCOMING MSC INTER CELL HO SEIZURE FAILED : échecs de HandOver inter BSC
entrant du coté mobile.
INCOMING MSC INTER CELL HO BSS FAILURE : échecs de HandOver inter BSC entrant
du coté équipement BSS et non attribuables au MS.
SUCCESSFULL OUTGOING MSC INTER CELL HO : HandOvers sortants inter BSC

réussis.
FAILED OUTGOING MSC INTER CELL HO : échecs de HandOver sortants inter BSC.
OUTGOING MSC INTER CELL HO RETURN TO OLD : échecs de HandOver sortants inter
BSC avec retour sur ancien canal.
OUTGOING MSC INTER CELL HO BSS FAILURE : échecs de HandOver sortants intra BSC
du coté équipement BSS et non attribuables au mobile.
2.3.2.5 Relatifs aux causes de Handovers
UPLINK QUALITY : demandes de HandOver dues à une qualité montante inadéquate.
UPLINK SIGNAL LEVEL : demandes de HandOver dues à un signal montant inadéquat.
13
UPLINK INTERFERENCE : demandes de HandOver dues à des interférences montantes
DOWNLINK QUALITY : demandes de HandOver dues à une qualité descendante inadéquate.
DOWNLINK SIGNAL LEVEL : demandes de HandOver dues à un signal descendant

inadéquat.
DOWNLINK INTERFERENCE : demandes de HandOver dues à des interferences

descendantes
DISTANCE FROM BTS : demandes de HandOver dues à une distance entre MS et BTS trop
importante.
POWER BUDGET : demandes de HandOver dues à l’algorithme power budget déterminant

une meilleure cellule.
LES TYPES DE HANDOVER EN RESEAU MONOCOUCHE
RXQUAL
HO sur QUALITE HO sur INTERFERENCES
*
HO sur HO sur BETTER CELL
NIVEAU
0 RXLEV
-110 dbm
* * -47 dbm
* : -97 en downlink *: 4 avec SFH * : -65 en downlink

-97 en uplink 3 sans SFH : -70 en uplink
* : Les seuils s’appellent L_RXLEV_DL_H et L_RXLEV_UL_H

* : Les seuils s’appellent L_RXQUAL_DL_H et L_RXQUAL_UL_H
* : Les seuils s’appellent RXLEV_DL_IH et RXLEV_UL_IH
14
2.3.2.6 Relatifs aux bandes d’interférences
MEAN IDLE CHANNELS IN INTERFERENCE BAND 1 : nombre moyen de canaux TCH en

bande d’interférences 1 lorsque le mobile est en mode veille.



MEAN IDLE CHANNELS IN INTERFERENCE BAND 5: nombre moyen de canaux TCH en

La BTS effectue périodiquement sur les Time Slots non alloués des mesures du niveau
de champ reçu. Chaque TS est alors classé, suivant cette mesure du bruit résiduel, dans une
bande d’interférence parmi cinq. Ce sont donc des mesures UPLINK. Ces cinq bandes
d’interférence sont définies de la manière suivante :
BAND 1 : champ reçu moyen entre -110 et -100 dBm.
BAND 5 : champ reçu moyen entre -85 et -47 dBm
Ce classement permettra d’allouer en priorité les Time Slots les moins bruités, situés
dans la bande d’interférence la plus basse.
2.3.3 Différence entre Drop Call et Drop TCH
Il est très important de ne pas confondre le taux de coupure d’appel (drop Call) avec le
taux de coupure TCH (drop TCH). Un certain pourcentage de taux de coupure étant souvent
donné comme objectif à un opérateur sur son réseau, il est capital de savoir de quel taux de
coupure on parle.
15
2.3.3.1 Drop TCH
La formule du drop TCH est la suivante :
Nbre de coupures TCH

 Taux de coupure TCH =
Prises TCH par établissement + Prises TCH par HO
2.3.3.2 Drop Call
La formule exacte du drop Call est la suivante :

 Tx de coupure d’appel =
Prises TCH par établissement + HO entrant succès – HO sortant succès
Au dénominateur de cette formule, on compte les communications :
- établies sur la zone et terminées sur la zone

- établies sur la zone et coupées sur la zone
- entrant dans la zone par HO et terminées sur la zone
- entrant dans la zone par HO et coupées sur la zone
On ne compte pas les communications :
- établies sur la zone et sorties de la zone par HO

- entrant dans la zone par HO et sorties de la zone par HO
Il est vrai que sur une zone suffisamment grande, on peut considérer que les succès de
HO entrant sont égaux aux succès de HO sortant. La formule du taux de coupure d’appel peut
alors s’approximer à :

 Tx de coupure d’appel 
Prises TCH par établissement
2.3.3.3 Relation Drop Call / Drop TCH
Sur un réseau monocouche, pour chaque cellule, on a quasiment tout le temps :
- Nbre prises TCH par établissement  Nbre de prises TCH par HO
Dans ces conditions, on peut déduire que :
Tx de coupure d’appel  2 * Tx de coupure TCH
16
Mais attention, cette approximation n’est plus du tout valable pour des cellules de
transit type cellule tunnel où l’approximation « Nbre prises TCH par établissement  Nbre
de prises TCH par HO » est totalement fausse.
Prenons l’exemple d’une cellule dont l’unique fonction est de couvrir un tunnel de
voiture. Il est certain qu'elle fera beaucoup plus de prises par HO que de prises par
établissement. Par exemple sur 100 prises TCH on aura :
- 90 prises TCH par HO

- 10 prises TCH par établissement
Supposons qu’il y a 5 coupures.
On a :
Tx de coupure TCH = et Tx de coupure d’appel =
Il faut donc retenir que le taux de coupure d’appel n’est pas un bon indicateur pour une
cellule de transit !
2.4 Méthodologie d’optimisation
Le processus d’optimisation et de suivi de la qualité de service est le suivant :
1 - sortie quotidienne des alerteurs ou ‘Warning’ des BTS par type de problème.
2 - focalisation sur les indicateurs prioritaires de qualité de service.
3 - sortie de tous les indicateurs des BTS dont les indicateurs prioritaires sont les plus
dégradés.
4 - comparaison des courbes obtenues aux valeurs seuils fixées et déduction de
l’ensemble des indicateurs dégradés.
5 - mise en corrélation de ces indicateurs.
6 - identification des problèmes et des solutions.
7 - validation des corrections apportées.
2.4.1 Sortie des alerteurs quotidien
Chaque jour de la semaine, il faut identifier les 10 BTS dont les indicateurs sont les
plus dégradés. Il y aura donc des listes différentes par type d’indicateurs. Par exemple :
Liste 1 : les 10 BTS dont le % de drop TCH est le plus élevé.

Liste 2 : les 10 BTS dont le % d’échec TCH est le plus élevé
Liste 3 : les 10 BTS dont le % de HO QUAL DL est le plus élevé
Etc…
On verra par la suite qu’il faut se focaliser en priorité sur certaines listes.
17
Pour cela, il faut utiliser le module DICO de NPA. Il faut ensuite aller dans le menu
WARNING et cliquer sur Cell Tresholds. On peut alors sortir les listes par type d’indicateur.
2.4.2 Focalisation sur les indicateurs prioritaires des alerteurs/Détection des

BTS à analyser
Si on a le temps, il est bon de travailler sur l’ensemble de ces liste sorties avec
WARNING. Mais il faut analyser en priorité les indicateurs traduisant une forte dégradation
de la qualité de service pour l’abonné. Il faut donc mettre l’accent en priorité sur les BTS
présentant les problèmes suivants :
- échecs d’établissement d’appels

- coupures de communication
On traitera ensuite les problèmes de légères dégradations de la qualité de la

communication.
Concernant les échecs d’établissement d’appels, on regardera en premier dans les

WARNINGS les indicateurs suivants :
 TCH failure rate : taux de défaillances du canal TCH dues à des problèmes
du BSS ou à des défaillances de la liaison radio. C’est donc une
composition des indicateurs : TCH_fail_BSS_pb et TCH_fail_radio
 TCH congestion rate : taux de défaillances lors d’une commutation du
canal SDCCH au canal TCH (à l’établissement d’appel uniquement) dues à
l’abscence de canal TCH disponible.
 SDCCH failure rate : taux de canaux SDCCH qui n’ont pas été pris avec
succès suite à des problèmes de BSS ou à des défaillances de la liaison
radio. C’est donc une composition des indicateurs : SDCCH_fail_BSS_pb
et SDCCH_fail_radio.
 SDCCH congestion rate : taux d’échecs de prise de canal SDCCH dus à
l’abscence de canal SDCCH disponible.
 coupures SDCCH
On notera que les prises TCH peuvent se faire de deux manières différentes :
- sur prise directe

- sur HandOver entrant
Les prises SDCCH ne se font pas actuellement par HandOver mais uniquement sur
prise directe.
Concernant les coupures de communication, on regardera dans les alerteurs

l’indicateur suivant :
18
 drop call rate : se reporter au paragraphe 2.3.3.2.
Les coupures TCH sont réparties en trois grandes catégories :
- RFLOSSES appelé aussi drop Radio : perte de la fréquence radio

- HOLOSSES : coupure sur HO sortant sans retour sur ancien canal
- MISCDROP : autres raisons
SCHEMA DESCRIPTIF DES COUPURES TCH
Coupures TCH
RFLOSSES MISCDROP HOLOSSES
CONCLUSION :
Pour résumer, on regardera donc en priorité, dans le menu WARNING, les indicateurs
suivants :
 Drop call rate

 TCH failure rate
 TCH congestion rate
 SDCCH failure rate :
 SDCCH congestion rate
 SDCCH drop rate
C’est en regardant tout d’abord ces indicateurs prioritaires que l’on va être amené à
regarder les autres indicateurs dans le but de résoudre les problèmes de forte dégradation de la
qualité de service.
2.4.3 Sortie des indicateurs généraux des BTS à analyser
Le menu WARNING a permis d’identifier les BTS à analyser. Maintenant, pour

pouvoir commencer l’analyse de ces cellules, il faut avoir une « photo » de tous les
indicateurs de ces cellules c’est à dire qu’il faut pour chacune de ces cellules sortir les
indicateurs relatifs :
- Aux canaux TCH

- Aux canaux SDCCH
- Aux Handovers entrants et sortants inter ou intra BSC
- Aux causes de Handovers : %HO QUAL DL, %HO LEV DL etc…
19
Il est important de voir l’évolution de ces indicateurs dans le temps. Pour cela il faut
les observer sur une période d’au moins une semaine.
Pour avoir cette « photo » de tous les indicateurs d’une cellule à analyser, il faut
choisir le module DICO puis utiliser le menu Evolution. Prendre ensuite le sous-menu Cell
puis Global.
2.4.4 Comparaison de ces indicateurs à des seuils d’alarme
Chaque indicateur a un seuil d’alarme à partir duquel on peut penser que cet indicateur
est dégradé. Il convient alors de faire le bilan pour la cellule à analyser de tous ses indicateurs
dégradés. Les indicateurs dégradés seront analysés grâce aux fiches d’analyse définies au
paragraphe 2.5. Les valeurs seuils des indicateurs sont les suivantes :
INDICATEURS SEUILS
TRX Duration <20s
SDCCH Access Failure >25%
SDCCH Congestion >10%
SDCCH Drop >3%
TCH Access Failure >3%
TCH Congestion >2%
Call Drop >3%
HO qualité DN >20%
HO qualité UP >20%
HO interférences DN >5%
HO interférences UP >5%
HO niveau DN >20%
HO niveau UP >30%
HO Better Cell <30%
Echecs HO entrant inter BSC >10%
Echecs HO sortant inter BSC >10%
Echecs HO entrant intra BSC >10%
Echec HO sortant intra BSC >10%
Il faut bien être conscient que ces seuils sont définis pour le réseau Mobilis. En effet,
les seuils à définir sont fonction d’une part du type de cellule macro ou micro ainsi que du
paramétrage par défaut appliqué sur le réseau.
20
2.4.5 Mise en corrélation de ces indicateurs dégradés
Il est souvent difficile de trouver le problème sur une BTS si l’on se contente de
regarder les indicateurs un par un. La dégradation d’un indicateur particulier est parfois liée à
la dégradation d’un autre indicateur. De plus, la dégradation simultanée de certains
indicateurs peut fournir une piste plus précise quand à la cause du problème sur une BTS. Il
faut donc dans la mesure du possible mettre en corrélation les indicateurs dégradés. C’est pour
cela qu’il est important d’avoir une « photo globale » des indicateurs d’une cellule. La mise
en corrélation des indicateurs sera éffectuée à travers les fiches d’analyse décrites au
paragraphe 2.5.
2.4.6 Identification des problèmes / utilisation de fiches d’analyse
2.4.6.1 Précision sur les fiches d’analyse
Tout d’abord, il faut être conscient qu’un problème sur une BTS peut venir d’autre
part que la BTS elle même. Ainsi, il faudra toujours être sûr que l’ensemble du site n’est pas
impacté ou que l’ensemble des BTS d’un BSC, ou même d’un MSC ne sont pas impactées
auquel cas il ne faudra pas s’acharner à essayer de trouver un problème sur la BTS à l’aide
des fiches d’analyse mais investiguer au niveau supérieur.
D’autre part, il faut savoir qu’un indicateur peut être dégradé par plusieurs causes en
même temps. Par conséquent, on sera souvent amené à regarder plusieurs fiches d’analyse
simultanément.
Les fiches d’analyse comportent des schémas logiques d’investigation. Un schéma

logique ne peut pas se permettre d’écarter une solution même si celle-ci est peu probable. En
effet, le but de se rapport est aussi de s’adresser à des personnes n’ayant jamais fait de suivi
de la qualité de service et de détection des problèmes sur le réseau à l’aide d’indicateurs. Il est
évident que les personnes connaissant l’optimisation écarteront d’elles mêmes certaines
possibilités improbables sur le schéma d’investigation.
2.4.6.2 Fonctionnement des fiches d’analyse
On ne commence pas à analyser un problème sur une BTS en partant des indicateurs
d’échecs ou de coupures. En effet, ces indicateurs sont les conséquences d’un problème sur le
réseau. Pour analyser les causes de ce problème, on étudiera la dégradation des autres
indicateurs.
Chaque indicateur dégradé fait référence à une fiche d’analyse lui étant consacrée.
Certaines fiches d’analyse peuvent éventuellement renvoyer à d’autres fiches d’analyse.
Une fiche d’analyse est composée d’une partie investigation décrivant la démarche à
suivre pour analyser le problème. Dans le but de résumer la démarche à suivre, un schéma
descriptif de la méthode d’investigation est proposé. Ce schéma pointe vers les différentes
causes possibles de la dégradation de l’indicateur concerné. Chaque cause possible est alors
21
numérotée. Chaque numéro renvoie alors à une action à mener. Cette action peut être de deux
types différents : renvoi vers une autre fiche ou action directe.
Pour résumer, une fiche d’analyse se compose des parties suivantes :
- investigation
- schéma descriptif de la méthode d’analyse
- actions à mener
22
2.5 Fiches d’analyse
2.5.1 Fort taux d’échec de Handovers entrants
Il faut tout d’abord essayer de savoir quelles sont les cellules n’arrivant pas à faire de
Handover sortant vers la cellule concernée par les forts taux de HandOver entrant. Pour cela,
il y a deux possibilités :
- faire une trace K11.
- lancer les jobs type 26 et 27 à l’OMC puis observer les résultats avec NPA :
Daily Operation DisplayCell-Cell Trafic flow

Ou : DICO Cell-Cell
Il faut ensuite regarder de quels types d’échecs il s’agit : Lack Of Res, Radio ou BSS
Pb.
 S’il s’agit d’un manque de ressource (Lack Of Res), les échecs se verront à la fois en
intra BSC et en inter BSC entrant. De plus, toutes les voisines auront des échecs de HO
sortants vers la cellule saturée.
- Si tous les Time slots traffiquent normalement, il s’agit d’une saturation réelle
c’est à dire que le traffic est tout simplement trop élevé par rapport à la
configuration du site.
- Si ce n’est pas le cas, il faut identifier quels sont les TS qui ne traffiquent
pas normalement :
 Tous les TS de la BTS ont ce problème : il est probable qu’il y ait un problème
matériel type combiner, aériens, défaut de sensibilité de réception …
 Tous les TS d’un TRX ont ce problème : il peut s’agir soit d’un problème
matériel sur le TRX soit d’un brouillage sur la FU portée par ce TRX.
 Quelques TS ont ce problème : il s’agit probablement d’un problème de
transcodeur ou d’une mauvaise programmation de la trans.
Pour voir le trafic TS par TS, il faut lancer un job abis type 5 à l’OMC.
 Si c’est l’indicateur BSS Pb qui est impacté, cela signifie qu’il peut y avoir :
- perte du lien Abis au niveau LAPD
- message ‘ remote transcodeur failure’
Par conséquent, il s’agit probablement d’un problème de transcodeur ou de lien Abis

(du type bagot de lien par exemple).
 Si c’est l’indicateur Radio qui est mis en cause, il faut d’abord regarder si les indicateurs
concernant les causes de HO de la cellule sont dégradés :
- si c’est le cas, il peut s’agir des problèmes suivants :
 Problème matériel
 Brouillage
- si ce n’est pas le cas, il faut voir si ce sont des HO fantômes. Ceci correspond au
symptôme suivant : le nombre de succès de HandOvers entrants est constant mais
on a un nombre d’échecs de HandOvers entrants beaucoup plus important. On peut
23
voir ceci en utilisant le module Daily Operation DisplayCell Handover.
C’est à dire qu’il y a des tentatives de HO entrants qui ne viennent pas des voisines
déclarées.
Voici un petit exemple de problème de BSIC générant des HO fantômes sur une
cellule de Paris. Le problème était apparu le 19/12/97 avec la mise en service
proche d’une BTS ayant le même couple BSIC/BCCH. Ce problème a été corrigé
le 24/12/97 par changement de BSIC.
 S’il y a des HO fantômes, il peut s’agir :

 d’un problème de BSIC
 d’un problème lié à une mutation
 s’il n’y a pas de HO fantômes, il doit y avoir un problème de paramétrage sur
les paramètres suivants : HOMARGIN, HOMARGIN_LEV,
HOMARGIN_QUAL, CAUSE_MARGIN_PX et plus rarement sur
LINKFACTOR et LOADFACTOR_X dans le cas ou un paramétrage de
délestage en trafic est activé.
24
SCHEMA RECAPITULATIF DE LA DEMARCHE
Fort taux d’échecs de

HandOvers entrants
Quel type d’échecs ?
BSS Pb
Radio
Lack Of Res
Problème Pb de lien
Voir si les causes transcodeur Abis
de HO dépassent Tous les TS
les seuils tolérés 6 11 traffiquent-ils
normalement ?
OUI
NON
Problème Brouillage
matériel
NON OUI
2
8
Voir si ce sont des
HO fantomes Saturation
réelle
OUI
Sur quelques Sur une FU Sur la BTS

Problème lié à une BSIC à TS complète complète
mutation changer
10 9 Combiner,
Problème Programmation Aériens…
Transcodeur Transmission
4
6 5
NON
TRX
Mauvais Brouillage défectueux
paramétrage
2 3
7
25
Actions :
1- L’action la plus efficace est le rajout de TRX pour pouvoir absorber le trafic offert. Vous
trouverez en annexe un tableau récapitulatif du trafic critique en fonction du nombre de
TRX. Il est aussi possible d’activer la fonctionnalité Directed Retry sur la cellule source.
On peut aussi envisager un paramétrage de délestage en trafic en modifiant l’expression
GRADE(n) grâce aux paramétrages des loadfactor, linkfactor et
CAUSE_MARGIN_X. Ce type de paramétrage de délestage en trafic est extrêmemnt
difficile à régler. Enfin, on peut simplement diminuer le HOMARGIN de la cellule
saturée vers une voisine et parallèlement augmenter le HOMARGIN de la voisine vers la
cellule saturée.
2- Voir la fiche relative aux brouillages internes
3- Envoyer une intervention maintenance pour remplacer le TRX
N.B sur 2 et 3 : pour savoir s’il s’agit d’un brouillage sur la FU portée par le TRX ou le TRX
lui-même, il suffit de mettre la FU concernée sur un autre TRX. C’est rapide et ça permet de
ne pas envoyer une inter maintenance alors qu’il s’agit simplement d’un problème de
brouillage.
4- Envoyer une intervention maintenance
5- Revoir la programmation de la trans.
6- Envoyer une intervention maintenance
7- Remettre des valeurs standards sur les valeurs de :
HOMARGIN = 5
HOMARGIN_LEV = 5
HOMARGIN_QUAL = 5
CAUSE_MARGIN_P2/4 = -7
CAUSE_MARGIN_P3/5 = -5
8- Voir la fiche relative aux causes de Handovers impactées
9- Voir la fiche relative aux problèmes de BSIC
10- Lors des mutations, il arrive que certaines relations de voisinages devant être détruites
(celles correspondant à l’ancienne LAC de rattachement de la cellule) ne le sont pas. Il
faut donc supprimer les anciennes relations correspondant à l’ancienne LAC de
rattachement des cellules voisines mutées et recréer les relations de voisinage avec les
bonnes LAC.
11- Envoyer une intervention maintenance pour vérif de la liaison Abis.
26
2.5.2 Fort taux de Handovers sur qualité descendante
 Rappel sur le déclenchement des HO sur qualité descendante :
La condition d’éxecution de HandOver sur qualité descendante est la suivante :
AV_RXQUAL_DL_HO > L_RXQUAL_DL_H

and AV_RXLEV_DL_HO  RXLEV_DL_IH
and BS_TXPWR = BSTXPWR_MAX
and EN_RXQUAL_DL = TRUE
Le mécanisme est le suivant : chaque SACCH, le MS effectue une moyenne de la

qualité DL appelée AV_RXQUAL_DL_HO. Cette moyenne est effectuée sur une fenêtre de
moyennage appelée A_QUAL_HO (préconisé à 4 SACCHS). Si cette moyenne dépasse un
seuil appelé L_RXQUAL_DL_H (3 sans SFH et 4 avec SFH) alors que la moyenne du champ
downlink AV_RXLEV_DL_HO est plus mauvaise que le seuil de déclenchement de HO sur
interférence RXLEV_DL_IH (préconisé à –65 dbm); alors un HO sur qualité est déclenché.
Pour une meilleure compréhension des différents types de HO, vous pouvez vous reporter au
paragraphe 2.3.2.5.
Pour qu’une cellule cible soit choisie lorsque l’on veut faire un HO sur qualité DL, il
faut que :
1/ AV_RXLEV_NCELL> RXLEV_MIN(n)
2/ AV_RXLEV_NCELL – AV_RXLEV_DL_HO > HO_MARGIN_QUAL + CAUSE_MARGIN_P4
AV_ RXLEV_NCELL : moyenne du niveau de champ mesuré sur une cellule voisine
sur A_PBGT_HO SACCH.
Itineris préconise : HO_MARGIN_QUAL=5 et CAUSE_MARGIN_P4 = -7,

RXLEV_MIN(n) = -97 dbm
Par conséquent, pour qu’une cible soit candidate, il faut :
1/ Que le niveau de champ de la cible soit meilleure que –97 dbm

2/ Que le niveau de champ de la cible ne soit pas plus de 2 dB plus mauvais que la source.
N.B : Lorsque l’on considère des répartitions de cause de HO, il est bon d’avoir en tête que la
baisse d’une cause de HO conduit inévitablement à la hausse d’une autre et vice et versa. Par
conséquent, la modification des seuils de déclenchement des HO sur niveau peut par exemple
entraîner une évolution de la répartition des HO sur qualité DL.
Par conséquent, avant d’aller plus loin dans l’analyse de la cause du fort taux de HO
sur qualité DL, il faut vérifier les seuils suivants :
- L_RXQUAL_DL_H
- A_QUAL_HO
- L_RXLEV_DL_H, RXLEV_DL_IH
- HOMARGIN_QUAL, HOMARGIN_LEV, HOMARGIN
27
 Une fois le paramétrage vérifié, il faut savoir s’il s’agit d’une cellule isolée. Pour cela,
deux moyens sont possibles :
- utiliser l’outil de prédiction ATOLL
- faire une mesure TEMS
 si c’est une cellule isolée, le problème peut venir d’une mauvaise couverture radio.
 si ce n’est pas une cellule isolée, il peut s’agir d’un brouillage interne ou d’un problème
matériel.
Pour déterminer si le problème provient d’un brouillage interne ou d’un problème

matériel, on peut suivre la démarche suivante :
1/ Lancer un job abis type 11 et observer pour chaque TRX la répartition de la qualité
en fonction du niveau de champ. Ceci permet d’identifier quels sont les TRX ou fréquences
associées pour lesquels la courbe est anormale (dégradation de la qualité à niveau de champ
correct).
2/ Ensuite, il faut essayer de faire une petite manipulation à l’OMC : basculer la
fréquence suspectée sur un autre TRX. Ceci permet de savoir s’il s’agit d’un brouillage
interne sur la fréquence portée par le TRX ou d’un problème sur le TRX lui-même.
3/ Pour essayer de voir si il y a un brouillage, on peut aussi voir la planification des
fréquences sous ATOLL pour essayer d’identifier le lieu du brouillage et le brouilleur
théorique. On pourra alors faire une mesure terrain TEMS si l’on a une idée du lieu du
brouillage.
28
Fort taux de
HO QUAL DL
Voir si les paramètres

L_RXQUAL_DL_H,
AQUAL_HO …sont
corrects ?
OUI NON
Mauvais
paramétrage
Voir si la cellule est isolée en
regardant sous ATOLL ou en 1
faisant une mesure TEMS
Cellule
isolée
Manque de
Cellule non couverture
isolée
2
Etude de la planification des Lancement d’une mesure Basculer les fréquences

fréquences sous ATOLL + TEMS d’identification suspectées d’être brouillées
lancement et analyse d’un Job d’un possible brouillage sur d’autres TRX
Abis type 11 interne
Est-ce donc un
brouillage interne ?
OUI
NON
Brouillage Problème
interne matériel
3 4
29
Actions :
1- Corriger le paramétrage en le mettant aux valeurs standards préconisées par France
Telecom.
2- Les actions possibles pour remédier à un trou de couverture sont les suivantes :
- augmenter la puissance d’émission de la BTS en touchant le paramètre

BS_TX_PWR_MAX. Attention, il faut toujours respecter l’équilibre du bilan de
liaison.
- Détilter certains sites
- Attendre la mise en service d’une nouvelle BTS
3- Voir la fiche relative à la correction des brouillages internes
4- Si on distingue nettement qu’un TRX est plus impacté que les autres, il est vraisemblable
que celui-ci soit défectueux et donc il faudra le remplacer. Si tous les TRX sont impactés,
il s’agit plutôt d’un problème sur les aériens mais c’est plus rare.
30
2.5.3 Fort taux de Handovers sur qualité montante
 Rappel sur le déclenchement des HO sur qualité montante :
La condition d’éxecution de HandOver sur qualité montante est la suivante :
AV_RXQUAL_UL_HO > L_RXQUAL_UL_H

and AV_RXLEV_UL_HO  RXLEV_UL_IH
and MS_TXPWR = MS_TXPWR_MAX
and EN_RXQUAL_UL = TRUE
Le mécanisme est le suivant : chaque SACCH, la BTS effectue une moyenne de la

qualité UL appelée AV_RXQUAL_UL_HO. Cette moyenne est effectuée sur une fenêtre de
moyennage appelée A_QUAL_HO (préconisé à 4 SACCHS). Si cette moyenne dépasse un
seuil appelé L_RXQUAL_UL_H (3 sans SFH et 4 avec SFH) alors que la moyenne du champ
uplink AV_RXLEV_UL_HO (effectuée sur A_LEV_HO SACCH) est plus mauvaise que le
seuil de déclenchement de HO sur interférence RXLEV_UL_IH (préconisé à –65 dbm); alors
un HO sur qualité montante est déclenché. Pour une meilleure compréhension des différents
types de HO, vous pouvez vous reporter au paragraphe 2.3.2.5.
Pour qu’une cellule cible soit choisie lorsque l’on veut faire un HO sur qualité UL, il
faut que :
2/ AV_RXLEV_NCELL – AV_RXLEV_DL_HO > HO_MARGIN_QUAL + CAUSE_MARGIN_P2
Itineris préconise : HO_MARGIN_QUAL=5 et CAUSE_MARGIN_P2 = -7,


2/ Que le niveau de champ de la cible ne soit pas plus de 2 dB plus mauvais que la source.
 Une fois le paramétrage vérifié, il faut savoir si le bilan de liaison est équilibré en lançant
un job abis type 11 à l’OMC pour voir l’écart de champ entre les échantillons uplink et
downlink. L’équilibre du bilan de liaison est fonction du gain de l’antenne, de la présence
de LNA, de diversité, de la puissance d’émission de la BTS et du mobile ainsi que des
sensibilités de réception de la BTS et du MS. Le seul paramètre ajustable pour équilibrer
le bilan de liaison est la puissance d’émission de la BTS en réglant le paramètre
BSTXPWR_MAX qui représente l’atténuation par rapport à la puissance maximale
d’émission de la BTS. Cette puissance maximale en sortie de baie dépend évidemment des
pertes engendrées par les modules ANX(duplexeur) et ANY (combiner).
Remarque importante : à l’heure actuelle sur le réseau mobilis, toutes les BTS ont un
BSTXPWR_MAX à O c’est à dire qu’elles émettent toutes à leur puissance maximale quelle
que soit la configuration des sites. Il faudrait donc recalculer et vérifier les équilibres de bilans
de liaison.
31
 Si le bilan de liaison est équilibré, il s’agit d’un brouillage externe. Ceux-ci
peuvent être dus à de multiples sources. Les exemples connus sont :
- VHF de ELF à Douala

- Portiques de surveillance de magasins à Paris
- Téléphones sans fils non agréés à Paris
Dans ce cas là, on aura aussi des canaux TCH bruités dans les bandes 2, 3, 4 ou 5. Ces
indicateurs sont disponibles avec NPA dans le module Daily Operation DisplayCell
Interference Band. Pour plus d’info concernant ces indicateurs, il faut se reporter au
paragraphe 2.3.2.6 relatif aux indicateurs de bandes d’interférences.
 Si le bilan de liaison n’est pas équilibré, il faut regarder si ce déséquilibre est

visible sur tous les TRX :
- Si ce n’est pas le cas, il s’agit vraisemblablement d’un problème de TRX
- S’il est déséquilibré sur tous les TRX, il ya deux possibilités :
1- Paramétrage du BSTXPWR_MAX non adapté à la configuration du

site (type d’antenne, présence de LNA, de diversité)
2- Problème d’aériens
32
Fort taux de HO
QUAL UL

L_RXQUAL_UL_H,
AQUAL_HO …sont
corrects ?
OUI NON
Vérifier l’équilibrage du Mauvais

bilan de liaison en lançant un paramétrage
job abis type 11 à l’OMC
1
Bilan de liaison Bilan de liaison

équilibré non équilibré
Brouillage Le déséquilibre
externe touche-t-il toutes
les fréquences ?
2
OUI NON
Le paramétrage du
BSTXPWR_MAX est-il conforme Problème
à la configuration du site ? matériel sur
TRX
OUI NON
Mauvais
Problème paramétrage du
d’aériens BSTXPWR_MAX
5
4
33
Actions :
Telecom.
2- Faire une plainte officielle à l’organisme responsable de la gestion des fréquences et

changer la fréquence.
3- Envoyer une intervention maintenance pour vérification du TRX
4- Recalculer le bilan de liaison et en déduire la bonne valeur du BSTXPWR_MAX à mettre à

l’OMC
5- Envoyer une intervention maintenance pour vérification de la chaîne de réception.
34
2.5.4 Fort taux de Handovers sur niveau descendant
 Rappel sur le déclenchement des HO sur niveau descendant :
La condition d’éxecution de HandOver sur niveau descendant est la suivante :
AV_RXQUAL_DL_HO  L_RXQUAL_DL_H
and AV_RXLEV_DL_HO < L_RXLEV_DL_H
and BS_TXPWR = BSTXPWR_MAX
and EN_RXLEV_DL = TRUE
Le mécanisme est le suivant : chaque SACCH, le MS effectue une moyenne du niveau de

champ DL. Cette moyenne, appelée AV_RXLEV_DL_HO, est calculée sur une fenêtre de
moyennage de longueur A_LEV_HO ( préconisé à 4 SACCH). Si cette moyenne dépasse le
seuil L_RXLEV_DL_H (préconisé à –97 dbm) tout en ayant une qualité meilleure que le seuil
L_RXQUAL_DL_H, alors une demande de HO sur niveau DL est effectuée.
Pour qu’une cellule cible soit choisie lorsque l’on veut faire un HO sur niveau DL, il
faut que :
2/ AV_RXLEV_NCELL – AV_RXLEV_DL_HO > HO_MARGIN_LEV + CAUSE_MARGIN_P5
Itineris préconise : HO_MARGIN_LEV=5 et CAUSE_MARGIN_P5 = -5,


2/ Que le niveau de champ de la cible soit au moins aussi bon que celui de la source
 Une fois les vérifications concernant le paramétrage des Handovers effectuées, il convient
de savoir si la cellule est isolée. Pour cela, on peut utiliser ATOLL et faire une mesure
TEMS.
 Si la cellule est isolée, il s’agit d’un problème de couverture insuffisante c’est à

dire qu’il n’y a pas assez de recouvrement avec les cellules voisines.
 Si la cellule n’est pas isolée, c’est qu’il manque simplement des déclarations de
voisinages pour pouvoir sortir correctement de la cellule.
35
Fort taux de
HO LEV DL

L_RXLEV_DL_H,
ALEV_HO …sont corrects ?
OUI NON
Vérifier la cellule est isolée en

terme de couverture avec Mauvais
ATOLL ou en faisant une mesure paramétrage
TEMS
1
Cellule non
isolée Cellule
isolée
Manque de
déclaration de Problème de
voisinage couverture
2
3
36
Actions :
Telecom.

liaison.
Attention : l’isolement d’une cellule en terme de couverture peut être simplement parfois dû
à une panne sur une cellule voisine.
3- Rajouter les voisinages qui ont l’air utiles d’après ATOLL et surtout d’après la mesure
TEMS.
37
2.5.5 Fort taux de Handovers sur niveau montant
 Rappel sur le déclenchement des HO sur niveau montant :
La condition d’éxecution de HandOver sur niveau montant est la suivante :
AV_RXQUAL_UL_HO  L_RXQUAL_UL_H
and AV_RXLEV_UL_HO < L_RXLEV_UL_H
and MS_TXPWR = MSTXPWR_MAX
and EN_RXLEV_UL = TRUE
Le mécanisme est le suivant : chaque SACCH, la BTS effectue une moyenne du niveau de
champ UL. Cette moyenne, appelée AV_RXLEV_UL_HO, est calculée sur une fenêtre de
moyennage de longueur A_LEV_HO ( préconisé à 4 SACCH). Si cette moyenne dépasse le
seuil L_RXLEV_UL_H alors que la qualité est meilleure que le seuil L_RXQUAL_UL_H ;
alors une demande de HO sur niveau UL est effectuée.
Pour qu’une cellule cible soit choisie lorsque l’on veut faire un HO sur niveau UL, il
faut que :
2/ AV_RXLEV_NCELL – AV_RXLEV_DL_HO > HO_MARGIN_LEV + CAUSE_MARGIN_P5
Itineris préconise : HO_MARGIN_LEV=5 et CAUSE_MARGIN_P3 = -5,


2/ Que le niveau de champ de la cible soit au moins aussi bon que celui de la source
N.B : le paramétrage du seuil L_RXLEV_UL_H est différent suivant que la cellule est
équipée de LNA ou non.
 Une fois le paramétrage vérifié, il faut voir l’équilibre du bilan de liaison en lançant un job
abis type 11 à l’OMC.

- S’il est déséquilibré sur tous les TRX, il ya deux possibilités :
1/ Paramétrage du BSTXPWR_MAX non adapté à la configuration du

site (type d’antenne, présence de LNA, de diversité)
2/ Problème d’aériens
38
 Si le bilan de liaison est équilibré, il faut ensuite voir si la cellule est isolée en
terme de couverture
- Cellule isolée : le problème vient certainement d’une mauvaise couverture

radio
- Cellule non isolée : le problème vient probablement d’un manque de

déclaration de voisinage.
39
Fort taux de
HO LEV UL

L_RXLEV_UL_H,
ALEV_HO … sont
corrects ?
NON
OUI
Mauvais
paramétrage
Vérifier l’équilibrage du 1
bilan de liaison en lançant un

Le déséquilibre
touche-t-il toutes
Voir si la cellule est isolée en les fréquences ?
regardant sous ATOLL ou
en faisant une mesure
TEMS
OUI NON
Le paramétrage du Problème
BSTXPWR_MAX est-il conforme matériel sur
à la configuration du site ? TRX
Cellule Cellule 6
non isolée isolée
OUI NON
Manque de Mauvaise Mauvais

déclarations couverture Problème paramétrage du
de voisinages radio d’aériens BSTXPWR_MAX
2 3 4
5 40
Actions :
Telecom.
2- Rajouter les voisinages utiles manquants. Le meilleur moyen est d’aller faire une mesure
terrain avec TEMS.

liaison.
Attention : l’isolement d’une cellule en terme de couverture peut être simplement parfois dû
à une panne sur une cellule voisine.
4- Envoyer une intervention maintenance pour vérifier la chaîne des aériens. Si la cellule est
équipée de LNA, il s’agit quasi systématiquement des LNA qui sont en panne ou non
connectés.
5- Recalculer le bilan de liaison et corriger la valeur du BSTXPWR_MAX.
41
2.5.6 Fort taux de Handovers sur interférences descendantes
 Rappel sur le déclenchement des HO sur interférences descendantes :
La condition d’éxecution de HandOver sur interférences descendantes est la suivante :
AV_RXQUAL_DL_HO > L_RXQUAL_DL_H

and AV_RXLEV_DL_HO > RXLEV_DL_IH
and EN_INTRA_DL = TRUE
Le mécanisme est le suivant : chaque SACCH, le MS effectue une moyenne de la qualité

AV_RXQUAL_DL_HO. Si cette moyenne de qualité est pire que le seuil
L_RXQUAL_DL_H alors que le niveau de champ DL est meilleur que le seuil
RXLEV_DL_IH ( -65 dbm); alors un HO sur interférence est déclenché.
Les HO sur interférences sont des HO intracell c’est à dire que l’on reste sur la même
cellule mais que l’on change simplement de TRX. Il est donc évident que les HO sur
interférence n’ont plus aucun intérêt en saut de fréquence en bande de base. Les HO sur
interférence sont visibles avec NPA en utilisant le module Daily Operation  Display 
Cell Handover  Intra Cell HO.
 Après avoir vérifié le paramétrage, il s’agit soit d’un brouillage (interne ou externe) soit
d’un problème matériel sur un TRX.
Pour déterminer si le problème provient d’un brouillage ou d’un problème matériel, on

peut suivre la démarche suivante :
1/ Lancer un job abis type 11 et observer pour chaque TRX la répartition de la qualité
en fonction du niveau de champ. Ceci permet d’identifier quels sont les TRX ou fréquences
associées pour lesquels la courbe est anormale (dégradation de la qualité à niveau de champ
correct).
2/ Ensuite, il faut essayer de faire une petite manipulation à l’OMC : basculer la
fréquence suspectée sur un autre TRX. Ceci permet de savoir s’il s’agit d’un brouillage sur la
fréquence portée par le TRX ou d’un problème sur le TRX lui-même.
3/ Pour essayer de voir si il y a un brouillage interne, on peut aussi voir la planification
des fréquences sous ATOLL pour essayer d’identifier le lieu du brouillage et le brouilleur
théorique. On pourra alors faire une mesure terrain TEMS si l’on a une idée du lieu du
brouillage.
Remarque importante : avec le paramétrage actuel, les HO sur interférences descendantes se

déclenchent si la qualité est mauvaise alors que le niveau de champ est meilleur que –65 dbm
ce qui est un excellent niveau de champ. Par conséquent, il est extrêmement rare d’avoir un
brouillage interne à ce niveau de champ ou alors c’est qu’on a commis une grosse erreur de
planification de fréquence. Il peut donc s’agir d’un brouillage externe (très rare) et plus
probablement d’un problème matériel.
42
Fort taux de HO sur

interférences DL

RXLEV_DL_IH,
L_RXQUAL_DL_H sont
corrects ?
NON
OUI
Mauvais
paramétrage
Le problème est-il
identifié sur tous les 1
TRX ?
OUI
NON
Problème
d’aériens Basculer la fréquence
susceptible d’être
brouillée sur un autre
2
TRX
La qualité s’est-elle
améliorée ?
NON
OUI
Etude de la planification des
fréquences sous ATOLL +
mesure TEMS de brouilleur
interne Le problème
venait du TRX
Un brouillage interne 3
a-t-il été détecté ?
OUI NON
Brouillage Brouillage
interne externe
4 5
43
Actions :
Telecom.
2- Envoyer une intervention maintenance pour vérifier les aériens. Ce problème est assez rare.
3- Faire changer le TRX par la maintenance.
4- Voir la fiche relative à la correction des brouillages internes.
5- Détecter le brouillage externe avec un analyseur de spectre. Faire une plainte officielle à
l’organisme censé s’occuper de l’attribution des fréquences.
44
2.5.7 Fort taux de Handovers sur interférences montantes
 Rappel sur le déclenchement des HO sur interférences montantes :
La condition d’éxecution de HandOver sur interférences montantes est la suivante :
AV_RXQUAL_UL_HO > L_RXQUAL_UL_H

and AV_RXLEV_UL_HO > RXLEV_UL_IH
and EN_INTRA_UL = TRUE
Le mécanisme est le suivant : chaque SACCH, la BTS effectue une moyenne de la qualité
AV_RXQUAL_UL_HO. Si cette moyenne de qualité est pire que le seuil
L_RXQUAL_UL_H alors que le niveau de champ UL est meilleur que le seuil
RXLEV_UL_IH ( -70 dbm); alors un HO sur interférence UL est déclenché.
 Après avoir vérifié que le paramétrage était bien conforme au modèle standard, il faut
s’assurer que le bilan de liaison est bien équilibré en lançant un job abis type 11 à l’OMC.
 S’il est équilibré, il peut s’agir d’un brouillage externe à détecter en branchant un
analyseur de spectre à la BTS sur la sortie Rxdiv.

- S’il est déséquilibré sur tous les TRX, il s’agit vraisemblablement d’un
problème d’aérien.
N.B : On peut parfois observer des brouilleurs externes en regardant l’allure des bandes
d’interférences en mode idle. En effet, il arrive, lorsque les brouilleurs émettent de manière
discontinue, que l’on voit des pics d’interférences en bande 5. Ces bandes d’interférences sont
visibles avec NPA en utilisant le module Daily OperationDisplay Cell
InterferenceMean Idle Channels In Interference Band X.
45
Fort taux de HO sur

interférences montantes

RXLEV_UL_IH,
L_RXQUAL_UL_H …sont
corrects ?
OUI NON
Vérifier l’équilibrage du Mauvais

bilan de liaison en lançant un paramétrage
1

Brouillage Le déséquilibre
externe touche-t-il toutes
les fréquences ?
2
OUI
NON
Problème Problème
d’aériens matériel sur
TRX
4
3
46
Actions :
Telecom.
2- Faire une plainte officielle à l’organisme responsable de la gestion des fréquences et

changer la fréquence.
3- Envoyer une intervention maintenance pour vérification du TRX
4- Envoyer une intervention maintenance pour vérification de la chaîne de réception.
47
2.5.8 Fort taux d’échec de handovers sortants
Il faut tout d’abord essayer de savoir vers quelles cellules les échecs de handovers
sortants se produisent. Pour cela, il y a deux possibilités :
- faire une trace K11.
- lancer les jobs type 26 et 27 à l’OMC puis observer les résultats avec NPA :
Daily Operation DisplayCell-Cell Trafic flow

Ou : DICO Cell-Cell
Il faut ensuite regarder de quels types d’échecs il s’agit : Returns, Radio ou BSS Pb.
 Si le taux de Returns est important, il s’agit très vraisemblablement d’un problème sur la
cellule cible qu’il faudra comprendre par analyse de ses indicateurs. Il faudra en
particulier s’intéresser aux causes de handovers de la cellule cible pour détecter un
éventuel brouillage ou trou de couverture. Les Returns correspondent à un échec de
handover avec retour sur ancien canal c’est à dire qu’il n’y a pas de coupure de
communication.
 Si c’est l’indicateur BSS Pb qui est impacté, cela signifie qu’il peut y avoir :
- perte du lien Abis au niveau LAPD
- message ‘ remote transcodeur failure’
Par conséquent, il s’agit probablement d’un problème de transcodeur ou de lien Abis

(du type bagot de lien par exemple).
 Si le taux de Radio est important, il faut vérifier la bonne qualité de service de la cellule
cible et de la cellule source par analyse de leurs indicateurs. Si les deux cellules semblent
avoir des indicateurs nominaux, il s’agit alors peut-être simplement d’un problème de
paramétrage des relations de voisinages de la source vers la cible : HOMARGIN,
HOMARGIN_QUAL, HOMARGIN_LEV, LINKFACTOR, CANDIDATE_CELL_PRIO.
48
Taux d’échecs de
HandOver sortants
important
Quel est le type

d’échec
majoritaire ?
RADIO
BSS Pb
Problème Vérifier la bonne qualité

Transcodeur ou de service de la cellule
Returns lien abis cible par analyse de ces
indicateurs
1
Cellule cible Cellule cible

malade correcte
Les taux de HandOvers

Problème sur cellule cible sortants sur qualité, niveau ou
à analyser et résoudre par interférences sont-ils trop
analyse de ses indicateurs élevés sur la cellule source?
NON OUI
Problème de Problème sur la cellule

paramétrage des source à analyser en étudiant
HandOvers les causes des HandOvers
sortants
3
4
49
Actions :
1- Vérifier la liaison abis pour détecter d’éventuel problèmes type bagot de liens…
2- Analyser les indicateurs de la cellule cible en particulier ses causes de handovers. Le

problème le plus fréquent est que la cellule cible est brouillée. Ceci se verra au travers
d’un fort taux de HO sur qualité downlink.
3- Remettre le paramétrage par défaut. Il faut vérifier les HOMARGIN,

HOMARGINQUAL, HOMARGINLEV ainsi que leur CAUSE_MARGIN_BUDGET_X
associé. Il faut faire en particulier attention au HO sur qualité qui est un type de HO
critique et qui génère donc beaucoup d’échec de HO.
50
2.5.9 Temps de communication faible
 Il faut tout d’abord observer si les temps de com faibles concernent la BTS complète, un
TRX particulier ou quelques TS simplement.
 Si les temps de com sont faibles sur toute la BTS, il s’agit d’un problème matériel type
combiner, chaîne des aériens, défaut de sensibilité de réception, manque de puissance
d’émisssion…
 Si les temps de com sont faibles sur tout un TRX, il faut voir s’il s’agit d’un problème
matériel sur le TRX lui-même ou plutôt d’un problème de fréquence c’est à dire d’un
brouillage interne ou externe. Pour cela, il faut basculer la fréquence soupçonnée sur
un autre TRX. Si le problème disparaît c’est vraisemblablement que le TRX était
défectueux. S’il ne disparaît pas, c’est que c’est bien un problème de fréquence.
Il faut dès lors faire une petite étude sous ATOLL et faire une mesure TEMS de
détection de brouillage interne. Si aucun brouillage interne n’a été détecté, il faudra
faire une recherche de brouillage externe à l’aide d’un analyseur de spectre.
 Si les temps de com ne sont faibles que pour quelques TS, il s’agit soit d’un problème
de transcodeur soit d’un problème de programmation de la trans ABIS.
51
Temps de
communication
faibles
Sur la BTS Sur quelques

complète TS Sur une FU
complète
Problème matériel
type combiner, Problème Mauvaise Basculer la fréquence
chaîne des aériens, transcodeur programmation de susceptible d’être
défaut sensibilité la transmission brouillée sur un autre
de réception 2 ABIS TRX
1 3
La qualité s’est-elle
améliorée ?
NON
OUI
Etude de la planification des Le problème

fréquences sous ATOLL + venait du TRX
mesure TEMS de brouilleur
interne 4
Un brouillage interne
a-t-il été détecté ?
OUI NON
Brouillage Brouillage
interne externe
5 6
52
Actions :
1- Envoyer une intervention maintenance.
2- Idem
3- Vérifier la bonne programmation de la transmission.
4- Demander à la maintenance de changer le TRX.
5- Voir la fiche relative à la résolution des brouillages internes
6- Utiliser un analyseur de spectre pour détecter le brouillage externe.
53
2.5.10 Forte saturation SDCCH
 Il faut tout d’abord vérifier le bon dimensionnement du nombre de blocs AGCH réservés.
En effet, un problème d’écoulement sur l’AGCH peut conduire à une sur-allocation en
canaux SDCCH. Pour cela, il faut vérifier le paramètre BS_AG_BLK_RES. Ce paramètre
est fonction du nombre de TRX et de la configuration du BCCH : combiné ou non
combiné. Pour bien comprendre l’intéraction entre les AGCH et les SDCCH, vous pouvez
vous reporter au paragraphe 2.5.14 relatif au dimensionnement des canaux d’accès.
 Il faut ensuite vérifier si le nombre de SDCCH disponibles sur la cellule est en accord
avec la règle de dimensionnement. Le tableau récapitulatif du nombre de SDCCH en
fonction du nombre de TRX se trouve dans le paragraphe 2.5.14 relatif au
dimensionnement des canaux d’accès. pour voir le nombre de SDCCH disponible sur la
cellule, il faut utiliser NPA et le module Daily Operation  Display  Cell Ressource
Usage  Available SDCCH.
 Si le nombre de canaux SDCCH disponible n’est pas en règle avec le nombre de

TRX qui devraient fonctionner, il peut s’agir :
- d’un TRX portant du SDCCH en panne

- d’une mauvaise configuration des Time Slots
 Si le nombre de SDCCH disponible est correct, le problème vient soit d’un trafic
simplement trop élevé par rapport au nombre de TRX (et donc de canaux SDCCH)
soit d’une saturation provenant de « spurious RACH ».
Les spurious RACH peuvent être de deux types :
- Neighboring Cell RACH

- Neighboring HO ACCESS
Neighboring Cell RACH
Ce cas se produit lorsqu’un mobile envoie un « Channel Request » à une cellule A

(FBCCH_A, BSIC_A ) et que ce « Channel Request » est aussi reçu par une cellule B (F BCCH_B,
BSIC_B) avec :
FBCCH_B = FBCCH_A  1
Et : BSIC_B = BSIC_A
Neihgboring HO ACCESS
Ce cas se produit lorsqu’un mobile fait un « HO ACCESS » vers une cellule A et que
ce « HO ACCESS » est aussi reçu par une cellule B avec :
FBCCH_B = fréquence d’un TRX de A  1
Et : BSIC_B = TSC_A
54
Le burst d’accès envoyé par un mobile pour un HO ACCES à le même format que
celui employé pour un CHANNEL REQUEST. Par conséquent, la cellule B prend cela pour
un CHANNEL REQUEST.
55
Forte sturation
SDCCH
Le paramètre
BS_AG_BLK_RES est-il
conforme à la règle de
dimensionnement ?
NON
OUI
Mauvais
dimensionnement
des AGCH
1
Le nombre de AVAILABLE
SDCCH est-il en accord
avec la règle de
dimensionnement ?
NON
OUI
TRX portant du Mauvaise

Le trafic des SDCCH en configuration des
abonnés justifie-t-il panne TS en SDCCH
la saturation ?
2 3
NON OUI
Nombre de
Les FU portant le TRX insuffisant
SDCCH/8 sont-
elles brouillées ? 4
OUI NON
Brouillage Neighboring
Neighboring HO ACCESS
Cell RACH
5
7
6
56
Actions :
1- Voir l’annexe relative au dimensionnement des canaux d’accès
2- Envoyer une intervention maintenance pour remplacer le TRX
3- Voir l’annexe relative au dimensionnement des canaux d’accès
4- Rajouter des TRX. La correspondance entre le trafic offert et le nombre de TRX

nécessaire pour l’écouler en ayant une probabilité de blocage inférieure à 2% dans le
paragraphe 2.3.1
5- Voir la fiche relative aux brouillages internes
6- Changer la fréquence ou le BSIC
7- Idem
57
2.5.11 Trafic par HO uniquement
Il peut s’agir des deux problèmes suivants :
 La cellule est barrée : le paramètre CELL_BAR_ACCESS est activé. La cellule ne pourra

prendre des coms que sur Handover.
 La cellule n’a pas de canaux SDCCH. On peut par exemple penser à des cellules dont le
BCCH est décombiné et dont aucun autre Time Slot ne dispose de SDCCH/8. Il s’agit
donc d’une erreur de configuration des IT.
Le cas le plus fréquent est que la cellule est barrée.
2.5.12 Trafic par établissement d’appel uniquement
Si la cellule n’a aucune prise TCH par Handover entrant, il doit s’agir d’erreurs dans
les déclarations de voisinages qui entrent vers notre cellule. Les déclarations de voisinages
contiennent les informations suivantes :
- LAC : les erreurs de LAC se produisent souvent au moment des changements de

LAC.
- fréquence BCCH erronée
- BSIC erroné
Enfin, il faut veiller aux valeurs des NCC_permitted sur les voisines. Si les
NCC_permitted des voisines n’acceptent pas la valeur du NCC utilisé sur notre cellule,
les HO entrants sur notre cellule ne seront pas possibles.
Pour rappel : BSIC = NCC + BCC
58
2.5.13 Résolution d’un brouillage interne
Il faut avant toute action être le plus sûr possible qu’il s’agit véritablement d’un
brouillage interne. Pour celà, il est obligatoire de faire une mesure avec TEMS. Pour avoir
une idée un peu plus précise du lieu du brouillage et du brouilleur potentiel, on peut
éventuellement faire une étude de la planification des fréquences sous ATOLL.
Pour rappel, les brouillages n’ont lieu en théorie que lorsque un certain seuil de C/I est atteint.
Les rappports de protection donnés par la norme sont :
- C/I > 9 db en co-canal

- C/I > -9 db en adjacent
Quand le brouillage a été clairement identifié, il faut être sûr que le brouillage n’est
pas simplement dû au fait que l’on tire la communication beaucoup trop loin sur la cellule
brouillée alors que l’on aurait dû partir de cette cellule beaucoup plus tôt. Si c’est le cas,
plusieurs explications sont possibles :
- la relation de voisinage est bien déclarée mais il est impossible de passer en

HandOver sur la cellule ( congestion de la cellule cible ...)
- absence de déclaration de voisinage. Il faut alors la faire.
N.B : Dans ces cas là, il vaut mieux essayer de résoudre le problème à la source et ne pas
demander le changement de fréquence car on risque de créer un brouillage autre part.
Cependant, si la solution à apporter n’est pas envisageable immédiatement on peut toujours
demander le changement de fréquence.
Solutions possibles pour résoudre un brouillage interne:

1/ Demander un changement de fréquence
2/ Baisser la puissance d’émission de la BTS brouilleuse
3/ Demander de tilter plus pour confiner la couverture et éviter les résurgences.
4/ Déclarer une relation de voisinage en sens unique de la cellule brouillée vers la

brouilleuse.
59
2.5.14 Dimensionnement des canaux d’accès : AGCH, PCH, SDCCH
Les problèmes de dimensionnement des canaux d’accès peuvent conduire à faire échouer
des appels alors que des ressources TCH sont disponibles ou à les surdimensionner alors que
la cellule sature en canaux de trafic. De plus, du point de vue de l’abonné, cela conduit à une
hausse du taux d’échec d’établissement d’appel sans qu’un message “réseau occupé” ne
l’informe de la raison de l’échec.
Ce document décrit brièvement le mécanisme des canaux d’accès et fournit une règle de
dimensionnement de ces canaux en fonction du nombre de TRX activé par cellule.
2.5.14.1 Capacité des canaux PCH
La capacité maximum de paging est de 4 pagings par blocs CCCH alloué au PCH. La
capacité maximum théorique du nombre de pagings par heure peut alors se calculer par la
formule :
où :  est le nombre moyen de pagings par bloc (4), nPCH le nombre de bloc de la
multitrame51 alloués au paging et T est la durée d’une multitrame (235,8 ms).
Des simulations montrent que pour avoir une bonne probabilité d’acheminement des
messages de pagings, il faut que la charge réelle des canaux ne dépasse pas 50% de la charge
maximum théorique. Au delà, la BTS n’aura pas la capacité d’envoyer tous les messages,
augmentant ainsi la probabilité d’échec d’établissement d’appel entrant.
On obtient alors le tableau suivant :
Nb de blocs PCH 1 2 3 4 5
Nb pagings heure 30534 61069 91603 122137 152672
Pour un dimensionnement classique des zones de LAC, 2 canaux de pagings par cellule sont
suffisants d’après les statistiques.
2.5.14.2 Allocation d’un canal SDCCH
Tout commence par l’envoi d’un Channel Request par un mobile. A la réception du
message sur le RACCH, le BSC demande à la BTS d’activer un canal s’il y en a de
disponible. Un Immediate Assignement contenant le descriptif du canal est envoyé à la BTS
qui doit le retransmettre sur l’interface Air vers le mobile. Si aucun bloc n’est disponible, le
message est stocké dans une file d’attente. Dans le cas où un bloc serait immédiatement
disponible, la durée entre l’envoi du Channel Request et la réception du Immediate
Assignement par le mobile est d'environ 150 ms.
60
En cas de non réception d’un Immediate Assignement ou d’un Immediate Assignment
Reject, le téléphone de l’abonné va ré-émettre une demande de canal. Le mobile envoie
jusqu’à 2 répétitions (Max-retrans=2) séparés par un intervalle aléatoire en slot RACCH. La
durée entre deux répétitions est comprise dans l’intervalle [S, S+T-1] où T est le paramètre
Tx-integer et S une valeur constante définie par la norme : 55 si le canal BCCH est combiné et
41 sinon.. Chaque répétition est interprétée par le réseau comme une nouvelle demande et
entraîne une nouvelle allocation de ressource SDCCH. Un problème d’écoulement sur
l’AGCH entraîne donc une sur-allocation de canaux SDCCH non saisis et conduit à renforcer
la saturation sur l’AGCH et les SDCCH.
2.5.14.3 Interaction SDCCH/AGCH
Contrairement aux PCH où le nombre de messages est le même pour toutes les
cellules, le besoin en AGCH est propre à chaque cellule et dépend de ses caractéristiques :
nombre d’usagers en mode veille, frontières de zones de LAC.
La fonction des canaux AGCH est de transmettre les messages Immediate Assignment
en vue d’allouer un SDCCH. Il existe donc une relation entre le nombre de canaux SDCCH
configurés sur la cellule et le nombre de canaux AGCH nécessaires pour pouvoir les affecter.
Chaque bloc AGCH peut transmettre un ou deux Immediate Assignment. Le nombre
minimum de canaux AGCH pour allouer les SDCCH est donc de :
où : est le nombre de SDCCH configurés sur la cellule

est le temps moyen d’allocation d’un SDCCH
est la durée d’une multitrame
On a alors le tableau suivant :
NB SDCCH 12 24 28 32
NB AGCH 1 1 2 2
Il faut noter que ce tableau donne le nombre minimum de canaux AGCH nécessaire à
l’allocation des SDCCH. Cependant, si la demande n’est pas régulière dans le temps, un
afflux de demandes SDCCH ne pourra pas être envoyé par la BTS immédiatement. Les
messages sont alors stockés dans une file d’attente. Si le message est mis en file d’attente, on
augmente la probabilité que le MS envoie des répétitions du Channel Request ce qui conduit à
une allocation multiple de SDCCH et donc augmente le taux d’échec de prise SDCCH et
l’indisponibilité des canaux SDCCH.
Le tableau ci-dessous donne le nombre minimum de canaux AGCH nécessaire à

l’allocation des canaux SDCCH sans avoir de risque de saturation :
61
Nb SDCCH 12 16 20 24 28
NB AGCH 1 2 2 2 3
2.5.14.4 Résumé de la configuration des canaux
Nb de TRX 1 2 3 4 5 6
CCCH_CONF Combiné Combiné Combiné Non Non Non
Combiné Combiné Combiné
Nb de SDCCH 4 12 12 16 24 24
BS_AG_BLK_RES 1 1 1 5 5 5
62

Optimisation

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Optimisation

Transféré par

Droits d'auteur :

Formats disponibles

Optimisation et qualité de

service du réseau Mobilis

Ce document a pour but de décrire les processus nécessaires à l’optimisation et au

2.1 Présentation de l’outil

2.2 Les différents modules

Lors du lancement de NPA, on voit s’afficher une fenêtre représentant

 Daily Operation : menus Display, Report et Graph

Le mode Display permet :

 analyse des compteurs d’un élément particulier du réseau

Le mode Report permet :

 analyse d’un aspect particulier des performances d’un élément du réseau

Les principales caractéristiques de ce module sont les suivantes :

 visualisation graphique et tabulaire des compteurs de performances

Le mode Display permet la visualisation des courbes relatives :

 aux canaux TCH et SDCCH des cellules

Le mode Report permet l’obtention de tableaux relatifs :

Le mode Graph permet la visualisation des graphiques prédéfinis suivants :

 trafic des canaux TCH et SDCCH des cellules

Les principales caractéristiques de ce module sont les suivantes :

 visualisation sous forme de rapports et de graphiques

Le mode Report permet l’obtention des types de rapport résumés suivants :

 trafic des canaux TCH et SDCCH

Le mode Graph permet la visualisation de graphiques prédéfinis. La période

Les différents menus intéressants sont les suivants :

- Les TRX d’une BTS

La fonction principale de ce menu est de pouvoir connaître la topologie de son réseau

Les menus Forecasting et Kingfisher sont moins utilisés en optimisation et ne seront

2.3 Les indicateurs de qualité de service

2.3.1 Définitions préalables

Trafic : - mesure de l’utilisation des canaux d’un élément du réseau

Erlang : - unité de mesure de trafic

Dropped Calls : - nombre d’appels pour lesquels il y a eu une coupure intempestive de

 RFLOSSES : perte de la fréquence radio

Lost Trafic (Trafic perdu) : - trafic offert moins le trafic écoulé.

% d’utilisation : - (trafic offert / trafic critique) * 100

La valeur du trafic critique en fonction du nombre de TRX est la suivante :

ERLANG 8,2 14,89 21,03 28,25 34,68 41,9 48,33

2.3.2 Indicateurs détaillés

2.3.2.1 Relatifs aux canaux TCH

TCH ASSIGNMENTS ATTEMPTS : tentatives de prise d’un canal TCH

TCH NORMAL ATTEMPTS : tentatives de prise directe TCH.

TCH HANDOVER ATTEMPTS : tentatives de prise TCH par HandOver.

TCH SEIZURE FAILURES : échecs de prise d’un canal TCH.

TCH SEIZURES : prises réussies d’un canal TCH.

TCH NORMAL SEIZURES : prises directes TCH réussies.

TCH TRAFFIC : trafic TCH en Erlang.

AVAILABLE TCH : nombre de canaux TCH en service à une période donnée.

2.3.2.2 Relatifs aux canaux SDCCH

SDCCH ASSIGNMENTS ATTEMPTS : tentatives de prise d’un canal SDCCH

SDCCH SEIZURE FAILURES : échecs de prise d’un canal SDCCH.

SDCCH SEIZURES : prises réussies d’un canal SDCCH.

AVAILABLE SDCCH : nombre de canaux SDCCH en service à une période donnée.

2.3.2.3 Relatifs aux canaux d’accès PCH et AGCH

PAGING ATTEMPTS : nombre de messages de recherche de personne rencontrés sur

PAGING FAILURES : nombre de messages de recherche de personne ( utilisation du canal

IMMEDIATE ASSIGNMENT ATTEMPTS : nombre de canaux requis (y compris les causes

IMMEDIATE ASSIGNMENT SUCCESSFUL : nombre de messages de commande

2.3.2.4 Relatifs aux handovers

SUCCESSFULL INTRA CELL HO : HandOvers intra BTS réussis.

FAILED INTRA CELL HO : échecs de HandOver intra BTS .

SUCCESSFULL INCOMING INTER CELL HO : HandOvers intra BSC entrant réussis.

FAILED INCOMING INTER CELL HO : échecs de HandOver intra BSC entrant.

SUCCESSFULL OUTGOING INTER CELL HO : HandOvers sortants intra BSC réussis.

FAILED OUTGOING INTER CELL HO : échecs de HandOver sortants intra BSC.

* : -97 en downlink : 4 avec SFH : -65 en downlink