call availability - optimisation
TRANSCRIPT
Call availability
Le ‘Call availability’ ou 'disponibilité d'appel' est défini comme le premier facteur principal
qui identifie la perception de l’utilisateur du réseau UMTS dans l'établissement réussi d'un
appel, Via le processus d'établissement d'appel, l'UE exécute la transition de l'état veille à l'état
Cell_DCH, demandes et accepte la configuration des ressources; l'UTRAN et le réseau coeur allouent
toutes les ressources demandées.
Processus d’émission d’appel
Le processus d'établissement d'appel se compose de différentes procédures en fonction du
type de Session / type de service qui est demandé (par exemple CS ou PS). Les procédures
d’établissement de connexion RRC et RAB sont les principales procédures du coté de
l’UTRAN.
Avec la procédure d’établissement de connexion RRC, l’UE demande des ressources de
l’UTRAN et exécute la transition du stade veille au stade CELL_DCH, et entre dans le mode
UTRAN RRC Connected. L’UTRAN alloue les ressources en termes de liens radio.
Avec la d’établissement de connexion RAB, toutes les ressources sont allouées par le Core
Network et l’UTRAN en terme de Radio Access Bearers (RABs) pendant que l’UE demeure
dans l’état Cell_DCH et accepta l’allocation des ressources.
L’appel est établi que si ces 2 procédures sont complètes avec succès.
Afin de réussir à passer ou recevoir un appel, l’UE doit passer les stades suivants :
- De l’état éteint a l’état veille
- De l’état veille à l’état Cell_DCH
Call setup failures
Les échecs de mise en route d'appel peuvent subvenir pendant la procédure de connexion au
réseau, quant l’UE passe de l’état éteint a l’état en veille, Ces échecs impactent le ‘call
availability’ comme l’utilisateur a besoin que l’UE passe a l’état veille avant de pouvoir tenter
de mettre en route un appel.
Network level access phase
Au cours de la phase d'accès au réseau, l'équipement utilisateur doit effectuer correctement la
procédure de sélection / reselection de cellule ainsi qu'obtenir l'accès au réseau en utilisant la
procédure d'accès aléatoire (Random Access procedure),
La phase d'établissement de connexion RRC
Pendant la phase d'établissement de connexion RRC, l'UE demandes des ressources provenant
du réseau UTRAN et exécute la transition de l'état veille à l'état Cell_DCH et passe en mode
UTRAN RRC Connected. L'UTRAN alloue les ressources en termes de liaisons radio.
La phase d'établissement RAB
Au cours de la phase d'établissement RAB, les ressources demandées sont alloués par le coeur
de réseau et par l'UTRAN en termes de supports d'accès radio (RABs), tandis que l'UE reste
en état Cell_DCH et accepte la configuration des ressources.
Détermination des problèmes d'accessibilité
introduction
Afin de déterminer rapidement si il y a sérieux problèmes dans le réseau UMTS, il est possible
d'analyser le niveau de satisfaction générale, d'un point de vue du réseau, de l'abonné mobile UMTS
au sujet de l'accessibilité du réseau.
PMS / KPI associés
Les PMS / KPI liés sont les suivants:
Le taux d'accessibilité CSV Le taux d'accessibilité CSD Le taux d'accessibilité PSD.
Chacun des KPI dessus est obtenu en multipliant le type de service spécifique RAB Establishment
Success Rate avec le Successful RRC Connection Establishment Rate.
Valeurs de taux d'accessibilité anormales
Lorsque l'une des valeurs de taux d'accessibilité est très faible, ce qui peut être causée par de nombreux différents problèmes. Par conséquent, il est conseillé de localiser le problème en analysant les mesures de performance et des indicateurs de performance clés séparés au cours des phases d'accessibilité d'appels :
• phase d'accès au niveau du réseau• phase d'établissement de connexion RRC • phase d'établissement RAB.
Network level accessibility
Echec de procédure préléminaire
En général, toute procédure d'appel initié via des messages RRC envoyés par l'UE à l'UTRAN est
précédé par deux procédures préliminaires telles que la sélection de cellules / re-sélection et de
détection d'accès aléatoire (Random Access Detection),
La réussite de ces deux procédures est une condition sine qua non pour réussir dans toute procédure
d'appel.
Tant la sélection de cellules / re-sélection et les procédures de détection d' accès aléatoires ne sont
pas visibles sur le réseau avant la réception réussie des messages RRC liées à la procédure d'appel
spécifique. Par conséquent, les défaillances survenant pendant les deux procédures n'affecteront pas
la valeur des indicateurs de performance de connexion RRC,
Recherche de cellule et décodage SIB RRC
Introduction
La recherche de cellule et le décodage de message RRC d'information de diffusion système (RRC
System Information Broadcast (SIB)) précèdent la sélection des cellules et des procédures re-
sélection.
Les deux procédures affectent directement la sélection de cellules et la re-sélection, ainsi quelques
détails sur ceci sont fournis ici.
Processus
En général, le processus de recherche de cellules peut être divisé en trois étapes:
• Synchronisation Slot en utilisant le canal de synchronisation primaire (P-SCH)
• synchronisation de trame et l'identification de groupes de code en utilisant le cannal de
Synchronisation secondaire (S-SCH)
• Identification du code de Scrambling sur le canal de pilote commun primaire (P-CPICH).
P-SCH, the S-SCH and the P-CPICH power settings
Le comportement des algorithmes de recherche de cellules est largement impactée par les réglages
de puissance des trois canaux physiques impliquées dans ce processus: le P-SCH, le S-SCH et le P-
CPICH.
Si des problèmes surviennent lors de la procédure de recherche de cellule dans les zones de bonne
couverture, les réglages de puissance des canaux concernés, définis par les paramètres UTRAN
correspondants, doivent être examinés. Cela pourrait être fait en utilisant le matériel de drive test
permettant la supervision des trois différents stades de recherche de cellules, ce qui permet
d'identifier les causes d'échec de l'opération de recherche de cellule .
Réglage de puissance P-CCPCH
Une fois que l'UE s'est synchronisé avec succès au code de brouillage P-CPICH de la NodeB, il
commence à décoder les messages SIB RRC sur le canal de diffusion (BCH). Le réglage de puissance
pour la P-CCPCH qui transporte l'information BCH, peut affecter le taux de réussite de décodage SIB.
Si cette puissance est trop faible, l'UE pourrait ne pas être en mesure de décoder correctement la SIB
et ne peut donc pas lire les paramètres liés à plusieurs procédures UE tels que la sélection des
cellules et re-sélection, l'accès RACH et le handover.Les problèmes de décodage SIB doivent être
examinées en utilisant un équipement d'essai d'entraînement UE en enregistrant et évaluant le taux
d'erreur de détection SIB.
Sélection de cellule
introduction
Une fois que l'UE a complété avec succès la Recherche cellulaire et le de décodage SIB, il effectue la
sélection de cellules. Au cours de cette procédure, l'UE essaie de trouver une cellule d'un réseau
public mobile terrestre adapté (PLMN) qui satisfait aux critères de sélection cellulaires.
Deux seuils pour la qualité et le niveau du pilote reçu sont utilisés dans
les critères de sélection de la cellule. Les mesures actuelles de l'UE doivent dépasser les seuils avant
que l'UE ne tente d'accéder à cette cellule.
Les deux seuils sont définis en tant que paramètres UTRAN:
sIB3QqualMin
sIB3QRXLevMin
Si les critères de sélection de cellule ne sont pas remplies, l'UE n'accédera pas au réseau sur le RACH
et n'est donc pas visible sur le réseau. Cela peut être dû à des erreurs réglage des paramètres ou a
cause d'une mauvaise couverture
Les symptômes d'échec
Si les critères de sélection ne sont pas remplies, l'UE n' essayera pas de se connecter au réseau, c'est
à dire qu'il n' envoyera pas un message de demande de connexion RRC sur le RACH défini à
"Inscription". Par conséquent, cet échec n'est pas visible à partir du réseau. du côté de l'UE, l'UE reste
sur «Recherche» qui est visualisée à l'écran.
Si l'UE passe à l'état "service limité", la sélection des cellules a été un succès, mais l'UE a soit campé
sur une cellule appartenant à un autre PLMN ou des défaillances eu lieu au cours de la procédure
d'inscription sur la PLMN initialement choisi (par exemple en raison de problèmes de réseau de
coeur).
Tous les problèmes de sélection de cellule ne peuvent être vérifiées qu'en utilisant soit des traces UE
ou en observant que le trafic est plus faible que prévu et que les utilisateurs se plaignent de
problèmes lors de la connexion.
Suggestions destinés aux améliorations
Si des problèmes concernant la sélection de cellules au sein de la zone de couverture du design RF
sont soupçonnés :
Les paramètres relatifs à la sélection de cellules doivent être vérifiées.
Si tous les paramètres sont conformes aux recommandations, devrait être étudié le
comportement en utilisant une mesure UE et l'exécution de la procédure de connexion à
l'endroit où les problèmes de couverture sont observés
Mesurer les valeurs actuelles de pilote Ec et Ec / Io à cet endroit vous permet de juger si les
critères de sélection de cellule devraient être atteints dans cette zone.
Dans certaines circonstances, il peut être indiqué de réduire à la fois la qualité et le niveau
des seuils encore plus loin pour permettre à l'UE de se connecter. Des précautions doivent
également être prises pour veiller à ce que les appels peuvent être maintenus à une qualité
acceptable avec ces baisses des seuils. Sinon, les UE seront autorisés à monter sur le réseau,
mais seront incapable de maintenir une qualité suffisante, et peut entraîner des appels perte
et plus de clients mécontents.
Échecs re-sélection cellulaires (Cell re-selection failures)
Une fois que l’UE est capable de dselectionner une cellule et se connecter au reseau, il lui faut
effectuer la reselection de cellule de manière continue. Si les parametres de reselection ont trop
d’hysterisis il est possible que l’UE accede a une cellule qui ne soit pas la cellule optimiale en terme ‘
interference. D’un autre cote, des valeurs d’hysterisis de reselection de cellule faibles peuvent etre la
source de reselection pingpong.
Si l’UE selectionne une cellule d’un autre URA, l’UE commencera la procedure de mise a jour URA,
pegging the PM counterNumUraUpdateRequest.UraChange.
Deux paramètres importants (sIB3Qhyst2 et sIB3Treselection) diffusees sur le message 3 de la RRC
SIB définissent l'hystérésis de la valeur de mesure Ec / Io et l'hystérésis temps.
Symptômes d'echec
Si les valeurs d'hystérésis sont trop élevés, cela pourrait causer des échecs de configuration d’appel.
Une analyse detaillees des causes root des problemes de reselection ne peut etre effectue que via un
tracage UE. Toutefois, une augmentation du nombre de échecs d'établissement de connexion RRC en
combinaison avec des valeurs élevées d'hystérésis pour la resélection de cellule peut indiquer que
des problemes de reselection de cellule cause ce comportement. Les paramètres doivent être
modifiés en fonction des recommandations pour remédier à ce problème. Une autre mesure de
performance en rapport avec la resélection de cellule est le nombre de requete de mise a jour de
cellule (cell update request) du a la reselection.
Seulement si la resélection apparaît au frontières de la LA ou RA, la cell update sera effectuee.
Néanmoins, cette valeur devrait augmenter pour les valeurs d'hystérésis qui sont configurees trop
bas dans les cellules à la frontière LA / RA comparé à une cellule correctement configuré avec un
trafic similaire.
Suggestions d'amélioration
Avant de commencer l'enquête, il convient de vérifier si tous les réglages de resélection sont
conformes aux recommandations. Si un nombre accru de demandes de mise à jour de cellules sont
observées à une frontière LA / RA, et qu'il soit vérifié par un drive test que l'hystérésis de resélection
est trop petit, les paramètres d'hystérésis doivent être élevés. Après avoir modifié les paramètres de
resélection, il peut être vérifié dans un autre test d'entraînement que l'hystérésis de resélection est
assez élevé et que reselections ping-pong sont extrêmement peu probable.
Les Problèmes de RESÉLECTION qui se traduisent par des taux de réussite d'établissement d'appel
plus faibles (lower call setup success rates) peuvent indiquer un paramètre d'hystérésis qui est trop
élevé. Cela devrait encore être vérifié lors d'un drive test et ensuite vérifier si elle s'est améliorée
après un ajustement des paramètres.
PMS / KPI associés
Les PMS / KPI connexes sont les suivants:
• NumCellUpdateRequest.CellReselect
• NumUraUpdateRequest.UraChange.
Si l'UE sélectionne une cellule dans un autre URA, l'UE va lancer la procédure de mise à jour URA,
pegging the PM counterNumUraUpdateRequest.UraChange. Le nombre de demandes de mise à jour
cellulaire due à resélection is pegged par NumCellUpdateRequest.CellReselect.
Echecs de Procedure d’acces RACH
Vue d'ensemble
La procédure d'accès RACH est utilisé dans les cas suivants:
• Lorsque vous vous connectez au le réseau
• Lors de la mise en place d'un appel
• Lorsque vous répondez à une page
• Lorsque vous effectuez une mise à jour de localisation / mise a jour de la zone de routage.
La procédure RACH a été réalisée avec succès lorsque le message de demande de connexion RRC
est reçu par le RNC au décodage réussi à la noeud B.
procédure RACH
Le RACH est transmis sur la couche physique en deux parties distinctes:
1. Un certain nombre de préambules RACH sont envoyés. La puissance du premier préambule
RACH est relativement faible et est calculée en utilisant le contrôle de puissance en boucle
ouverte.
2. Chacun des préambules RACH suivants sont transmis avec une puissance accrue jusqu'à ce
qu'un accusé de réception (ACK) est reçu sur l'AICH.
3. Après avoir reçu le AICH l'UE émet une partie du message RACH avec un message de
demande de connexion RRC inclus.
Les flux de signalisation d'une procédure de transmission de RACH de base:
Timer settings
Le Guard timer T300 (determine par le parametert300 de l’UTRAN) et N300 (determine par le parametern300 de l’UTRAN) supervisens la transmission du message de demande de connexion RRC du cote de l’UE.
Une configuration pauvre du timer n300 donne une retransmission insuffisante du message RACH, et une configuration pauvre du timer t300 donne une retransmission trop en avance ou trop en retard du message de connexion RACH et ainsi affecte les procedure a l’origine de l’acces RACH (par exemple un etablissement d’appel).
Dès réception du message de demande de connexion RRC au RNC, PM compteur NumRRCConnAttis incrémenté d'une unité. Lorsque l'UE n'est pas en mesure soit se connecter avec succès au réseau ou de réaliser avec succès une mise à jour de localisation, la procédure de sélection / resélection de cellule échoue et l'UE entre dans un état de "service limité".
Symptômes d'echecs
Il ya quatre compteurs de PM qui peuvent aider à identifier les problèmes d'accès RACH: NumRRCConnAtt, NumBadRACHTransBlock, NumGoodRACHTransBlockand et ChannelOccupRateRACH
• NumRRCConnAttis déclenchée sur le RNC après réception du message de demande de connexion RRC indépendant de la cause de la mise en place. Les valeurs basses à un ofNumRRCConnAttare d’un node b particulier est révélatrice de problèmes; néanmoins ce compteur ne peut pas prouver qu'il ya effectivement des problèmes parce les préambules RACH rejetés par le NodeB ne sont pas comptés. Il se peut qu'à un trafic particulier faible de la cellule se traduit par de faibles valeurs de counterNumRRCConnAtt3.
• PM counterNumBadRACHTransBlockandNumGoodRACHTransBlockmay utilisé pour la détermination du rapport entre le nombre de RACH TBs reçu avec un mauvais CRC au nombre total de RACH TBs. Une valeur élevée de ce ratio peut être le signe de problèmes de qualité sur le RACH.
• PM counterChannelOccupRateRACH est le rapport du nombre total de bits transférés sur le RACH par rapport au nombre maximum de bits disponibles pour l'utilisation RACH (taux de service) par période de granularité. Si ce ratio est très élevé les ressources sur le RACH peuvent ne pas être suffisante.
Suggestions d'amélioration
Les correctifs d'amélioration dépendent de la raison détecté de l'échec:
NodeB ne décode pas le préambule RACH
Les raisons possibles:
L'UE n'est pas camper sur une cellule optimale en raison de paramètres de sélection / resélection incorrectes.
En raison de problèmes matériels la sensibilité de la voie RX pourrait être réduite
La puissance du préambule RACH initiale est trop faible. Dans ce cas, il est nécessaire d'augmenter le paramètre UTRAN constantVal
La puissance nécessaire pour la détection de préambule RACH ne dépasse pas physicalRACH.preambleThreshold. Dans ce cas, les trois paramètres MaxRetranPreamble, physicalRACH.preamble ThresholdandpowerRampStep doive être optimisé.
La couverture de RACH du Best Server est trop pauvre en termes de faible Ec / Io qui pourraient être causés par:
la pollution pilote: Dans ce cas, l'environnement RF doit être optimisé, par exemple : tilt de l'antenne, la variation des réglages de puissance des NodeB, etc
La couverture du Best Server est simplement trop faible (faible Ec/N0, RSCP ou pathloss élevé). En cas de problèmes de couverture, il peut être utile d'abaisser le seuil de détection
défini par le paramètre UTRAN physicalRACHpreambleThresholdor pour augmenter la puissance CPICH controlee par le paramètreUTRAN pCPICH.power. Si les augmentations sont faites à la puissance CPICH, alors il faut prendre soin d'équilibrer les puissances pour le reste des canaux (si nécessaire), de sorte qu’une situation ou l'utilisateur détecte et utilise une cellule basée sur la puissance de pilote, mais ayant une puissance de la trafic insuffisantes pour effectuer l'appel ne se pose pas.
L’UE reçoit pas d'accusé de réception sur le AICH
Les raisons possibles:
La puissance de l'AICH déterminé par le paramètre UTRAN aICHPower n'est pas suffisante.
Le AICH est perturbée par d'autres NodeB non RF-optimisés. Dans ce cas, l'environnement RF doit être optimisé par exemple : tilt des Antennes, variation des réglages de puissance des NodeB simples, changement des azimut de l'antenne.
Manque de ressources Node B
L'UE reçoit un accusé de réception négatif sur l'AICH si le NodeB détecte le préambule RACH, mais ne dispose pas de ressources suffisantes pour traiter le message RACH Part.
NodeB ne décode pas le message de RACH
Les raisons possibles:
La puissance maximale autorisée sur le RACH est réglé trop bas. Dans ce cas, les réglages des deux paramètres UTRAN sIB3MaxAllowedULTxPower et sIB4MaxAllowedULTxPower doivent être optimisés
Les réglages de puissance configurant la puissance DPCCH relative du message RACH Part est réglé trop bas. Dans ce cas, les réglages de puissance des physicalRACpreambleThreshold et PowerOffsetPpm doivent être optimisés.
Les réglages de puissance configurant la puissance DPDCH relative du message Part RACH est réglé trop bas. Dans ce cas, ses réglages de puissance des gainFactorBc et gainFactorBd doivent être optimisés.
Echec retransmission du message Part RACH. La Raison possible peut etre une non configuration optimale des paramètres UTRAN t300 et n300.
Analyse d'établissement de connexion RRC
Introduction à l’établissement de la connexion RRC
Procédure d'établissement de connexion RRC
En général, la procédure d'établissement de connexion RRC peut se produire dans différents scénarios tels que:
Connexion au réseau (l'UE est en marche et passe à l'état veille)
Mise à jour de Localisation
Établissement d'appel MO / MT (l'UE passe de l'état inactif à l'état Cell_DCH).
L’ établissement de connexion RRC commence par la réception réussie de la RNC du message de demande de connexion RRC. Cela signifie que la sélection de cellules / re-sélection ainsi que des procédures de Random Access Detection ont été réalisés avec succès.
Etapes d’etablissement d’appel
Dans le cas d'un établissement d'appel provenant d'un mobile, la procédure d'établissement de connexion RRC peut être classée dans les étapes de base suivantes:
1. Call Admission Control (CAC) au niveau du RNC
2. Node B Application Part (NBAP) Configuration de liaison radio (incluant le control de la porteuse et la synchronisation)
3. Configuration de la connexion RRC.
Note: Pour un appel a un mobile se terminant la procédure d'appel et suivit de la procédure random access.
Un exemple d'un mobile est originaire flux d'appels:
PMS / KPI associés
Les PMS / KPI connexes sont les suivants:
NumRRCConnEstFail
NumRRCConnRej
Taux de mise en place de connexion RRC reussit (Successful RRC connections establishment rate.)
Établissement échecs de connexion
Les échecs d'établissement de connexion RRC peuvent se produire pour des raisons suivantes:
Call Admission Control failures
Radio Link Setup failures
Transport Bearer failures
RRC Connection Setup failures
Paging failures
Soft/softer Handover failures at call setup.
La plupart de ces causes d'échec sont normalement associés à de mauvaises conditions RF. Les faibles valeur de KPI RRC Connections Establishment Rate peuvent aussi etre du au echecs de connexion RRC survenant au cours d'autres procédures telles que Network attach, SMS et Localisation jour.
Echec de Contrôle d'admission d’appels (Call admission control failures)
introduction
Le contrôle d'admission des appels (CAC) est utilisé pour prévenir une surcharge du système. Les conditions de charge pour la liaison descendante sont basés sur la puissance d'émission totale de la cellule. La mesure de la charge de liaison montante est la valeur RSSI mesuré par rapport au seuil de bruit qui a été estimée à partir de mesures à long terme.
Si les seuils de charge définis pour les CAC sont dépassées, la demande d'établissemen de connexion RRC est refusée et un message de rejet de connexion RRC avec pour motif ‘congestion’ est envoyé par le RNC à l'UE.
PMS / KPI associés
Les PMS / KPI connexes sont les suivants:
• NumRRCConnRej
• Average transmitted carrier power
• Forward power overload duration
• Maximum transmitted carrier power
• Maximum received signal strength indicator.
NumRRCConnRej valeur anormale
Le déclenchement de CAC peuvent être partiellement surveillée en utilisant le compteur NumRRCConnRejthat PM peut être déclenchée non seulement en cas de CAC, mais aussi en cas de message de rejet de connexion RRC envoyé à l'UE avec un motif non précisé. Si les valeurs de ce compteur indiquent que les situations de surcharge ont eu lieu au cours de longues périodes de temps, le CAC peut être une des raisons pour les problèmes d'établissement d'appel expérimentés.
Mesures de la charge
D'autres compteurs liés à la charge du système tel Forward Power Overload Duration, Average Transmitted Carrier Power, Maximum Transmitted Carrier Power et Maximum Received Signal Strength Indicator peuvent être utilisés pour vérifier que la charge de la cellule est relativement élevé, ce qui augmenterait la probabilité de échecs d'établissement d'appel.
Échec d’etablissement de la liaison radio
introduction
Une fois que le RNC a vérifié que les ressources demandées ont passé la vérification de CAC, le RNC demande au Node B d’allouer ces ressources à travers la procédure de NBAP Radio Link Setup. En général, au moins une liaison radio doit être mis en place, en cas de soft/softer handover à l'établissement d'appel plus d'une liaison radio doit être mis en place.
Cette procédure peut échouer à cause de différentes raisons telles que:
• Pas de ressources de canal de trafic disponibles au NodeB
• Défauts soit dans le NodeB
• défaut dans les liens lub.
Dans tous les cas de défaillance le RNC renvoie à l'UE un message de rejet de connexion RRC avec motif "non spécifié".
Pas de ressources en cannaux de trafic disponible
Afin d'allouer les ressources demandées, le RNC envoie le message Radio Link Setup Request au Node B concerne. A la reception du message Radio Link Setup Request le Node B se réserve les ressources nécessaires et renvoie le message Radio Link Setup Response au RNC.
Si la mise en place d'au moins une liaison radio échoue le noeud B renvoie le message Radio Link Setup Failure au RNC.
Les causes d'échec typiques peuvent être classés comme suit:
• Radio cause au niveau de la couche radio du réseau, par exemple pas de ressources disponibles NodeB le mode de diversite TX demandee pas pris en charge, le nombre de codes de canalisation UL / DL pas pris en charge, UL / DL facteur d'étalement pas pris en charge;
• Cause au niveau de la couche liason de Transport Layer en raison de moyens de transport non disponibles;
• Cause du au Protocole dû à une erreur sémantique;
• Divers Cause, par exemple Défaillance matérielle.
Symptômes d'echecs
Via compteurs de liaison radio PM tel que NumRLSetupFail.NodeBRes et NumRLSetupFail.TransRes, il est au moins possible d’idemtifier l’indisponiblite des liaison radio tout au long de la procedure de mise en place des liaisons raido (qui peut se produire le long de procédures de soft handover ainsi que le long rétablissement d'appel).
Les compteurs NodeB spécifiques tels que Total Channel Element Usage (ce_usage) et Dedicated Channel Element Usage (dedic_ce_usage) fournissent des informations importantes sur le trafic NodeB et indique si la capacité NodeB en termes de disponibilité des ressources physiques est proche de la limite.
Suggestions d'amélioration
En supposant qu'aucune erreur n'a été détectée au NodeB via l'analyse d'alarme, la cause d’échec la plus probable est celle liée à l'indisponibilité des ressources de trafic NodeB. Afin de limiter la survenue de cette cause d'échec, il est également recommandé d’examiner attentivement le plan de dimensionnement du lien en fonction des stratégies d'allocation de liaison.
Comme la demande d’etablissement de liaison radio (Radio Link Setup Request) est transféré du NBAP sur l’lub, la disponibilité des moyens de transport et de transmission est critique pour le succès. L'analyse du trafic axé sur les Node Bs critique doit être fait en regardant aussi les sessions RAB actifs et le trafic soft/softer. Assignation RAB est géré par le Radio Access Network Application Part (RANAP) sur les liens IU, donc les ressources RANAP sur la couche de transport / transmission influe sur la réussite de l'installation de liaison radio.
Les impacts réels pourraient être causés par les paramètres de profil de QoS ATM dans l'UTRAN et le réseau de transport.
Carte de trafic NodeB defectueuse
Les echecs d’etablissement de liaison radio peuvent être causées par une unité de canal défectueux dans la carte UCU. Ouvrez une entité d'alarme de la RNC à laquelle le NodeB est connecté et vérifier si les alarmes pour les cartes UCU sont affichés.
Liens lub en panne
Sur le Service Specific Connection Oriented Protocol (SSCOP) POLL et le STAT Protocol Data Units (PDU) sont envoyés régulièrement en liaison montante et descendante afin de vérifier l'état de la liaison. Le POLL PDU est utilisé pour demander, via une connexion SSCOP, informations sur l'état de l'entité SSCOP pairs. Le PDU STAT est utilisé pour répondre à cette demande de statut (POLL PDU) reçu d'une entité SSCOP pairs. Vérifiez avec un analyseur de protocole relié à lub si ces PDU sont envoyés. Si les PDU ne peuvent être vus, le lien lub doit être vérifiée.
Échec d'établissement de connexion RRC
introduction
Une fois que la procédure d'établissement de liaison radio NBAP a été achevé avec succès et la porteuse de transport a été établi et synchronisée, l'UTRAN initie la procédure d'établissement de connexion RRC pour compléter l'établissement de la connexion RRC.
La mesure de performance NumRRCConnEstFail est utilisée pour enregistrer les échecs survenus au cours de la procédure d’etablissement de connexion RRC. Avant de commencer cette procédure, le Serving RNC (SRNC) attribue une identité temporaire de réseau radio (RNTI - Radio Network Temporary Identity) à l'UE. Si le pool RNTI dans un RNC est hors de portee, l’etablissement de la connexion RRC n'est pas possible. Cela pourrait être le cas si la taille du pool RNTI est inférieur au nombre de mobiles nécessitant RNTI en même temps.
Le processus
A ce stade, le RNC envoie le message d’etablissement de connexion RRC, réinitialise le compteur V30001 et commence sa garde minuterie interne T30001 (déterminé par le paramètre UTRAN uERRCConnSetupGuardTimer). Lorsque le RNC reçoit la configuration le message RRC Connection Setup Complete envoye sur le the Dedicated Control Channel (DCCH) avant que T30001 n’expire, le RNC stop T30001 et l’UE entre en mode CELL DCH.
Si le RNC ne recoit pas le message RRC Connection Setup Complete avant que T30001 n’expire, l e RNC devra recommencer l'envoi du message d’etablissement de connexion RRC sur le Forward Access Channel (FACH) en fonction de l'état du compteur V30001:
Si V30001 <= N30001 (qui est déterminé par le paramètre UTRAN maxRRCConnSetupRetries), le RNC incrément V30001 de un, reinitialise le compteur T30001 et envoie le message d’etablissement de connexion RRC a nouveau.
Si V30001> N30001, le RNC envoie un Message RRC Connection Reject à l'UE, les ressources réservées sur NBAP et ALCAP sont libérés.
La figure suivante montre le flux d'appels d’un cas en échec :
PMS / KPI associés
Les PMS / KPI connexes sont les suivants:
• NumRRCConnEstFail.
Valeur NumRRCConnEstFail anormale
Les raisons possibles pour les échecs de la procédure d’etablissement de connexion RRC:
Configuration non optimale des attributs uERRCConnSetupResponseTimer et maxRRCConnSetupRetries de l’UTRAN
Le message d’etablissement de connexion RRC n’est pas decode correctement du a une mauvaise couverture FACH.
Le RNC ne parvient pas à décoder le message RRC Connection Setup Complete.
Symptômes d'insuffisance
Le compteur PM NumRRCConnEstFail est utilisé pour enregistrer les échecs survenus au cours de la procédure de configuration de connexion RRC. Les causes d’un échec peuvent être indiquées comme suit:
Le message RRC Connection Reject est envoye du RNC a l’UE avec le motif "non spécifié" sur le nombre maximum de message de retransmission RRC Connection Setup etant atteint.
Le message RRC Connection Request est recu au niveau du RNC avec la valeur de l’IE “Protocol error indicator” mis a ‘TRUE’. Ceci indique que le message RRC Connection Setup reçu à l'UE était invalide ou demandee une configuration non prise en charge.
Suggestions d'amélioration
Les corrections proposées dépendront des causes root. Voici les causes possibles et leurs solutions possibles:
Les parametres uERRCConnSetupGuardTimer et maxRRCConnSetupRetries de l’UTRAN ne sont pas configurer de manière optimale. Dans ce cas, il pourrait être utile d'augmenter un ou les deux paramètres selon les dépendances et les paramètres recommandés fournie dans l'UMTS ParCat.
Le message d’etablissement de connexion RRC n’est pas decode correctement du a une mauvaise couverture FACH.les raisons peuvent être:- Pollution pilote: En cas de pollution de l'environnement RF pilote doit êtreoptimisé par exemple tilt de l'antenne, de la variation des paramètres de puissance de NodeBs, etc- La puissance de la FACH déterminé par le parametre UTRAN fACH.maxPower n’est pas suffisante.
Le RNC ne parvient pas à décoder le message RRC Connection Setup Complete. Dans ce cas, l'augmentation de la puissance (défini par le paramètre DPCCH_power_offset) peut être utilisé à la configuration de la liaison radio sur le DCH UL par l'UE peut aider à augmenter la probabilité de décodage réussi. Notez que l'augmentation de la puissance DCH UL peut augmenter interférence UL.
Paging failuresPaging procedureDans le cas d’un appel MT, l’UE en etat veille doit d’abord etre pagging avant l’envoi du message RRCConnection Request. Le message de pagging de type 1 est envoye sur le Paging Channel (PCH) par le core network (ce qui signifie 3G-MSC pour les appels à commutation de circuit ou SGSN pour les appels à commutation de paquets) à toutes les UE appartenant à la même zone de localisation (LA) (dans le cas d'un appel MT CS) ou à la même zone de routage (RA) (dans le cas d'un appel MT PS).
Dans un cas réussi l'UE reçoit et décode correctement le message de pagging et renvoie le message RRC Connection Request avec le motif pertinente a l'UTRAN (ce qui signifie Terminating High Priority Signaling pour les appels PS et Terminating Conversational Call pour les appels vocaux).
Toutefois, il peut arriver que l'UE soit ne reçoit ni ne décode correctement le message de pagging.
Indications PMS / KPILes causes d'échec peuvent être identifiés via le compteur UTRAN NumPageAttDiscard, le trafic PCH peut être évaluée via coomteur ChannelOccupRatePCH.
PMS / KPI associésLes PMS / KPI connexes sont les suivants:• NumPageAttDiscard• ChannelOccupRatePCH.
Les causes possibles d’echecEn général, les causes possibles d’echec sont la congestion sur le canal d'appel (PCH) ou une mauvaise couverture de PCH.
Également des problèmes sur le réseau de transport peuvent influer sur la procédure de pagging comme suit:
• Transport over Iu interfaces RANAP protocol takes care of transmitting the pagingmessages• Transport over Iub interface, the PCH is carried by the AAL2 protocol• Transport over RACH (paging response in uplink direction).• Transport problems over the RACH (paging response in uplink direction).
Dans tous ces cas, l'appel de MT n'est pas terminée avec succès.
Suggestions d'améliorationSi la cause identifiée est une mauvaise couverture PCH, la puissance de la PCH devrait être augmentée via le paramètre pCHPower. Pour augmenter la probabilité de réussite de décodage de la PCH par l'UE, le pilot et les bits de Transport Format Combination Index (TFCI) bits dans la frame S-CCPCH peuvent être transmis à une puissance supérieure par compensation de puissance définies via les paramètres secondaryCCPCH.powerOffset1 et secondaryCCPCH.powerOffset2 respectivement.
Si cette erreur se produit dans le réseau en raison de la congestion PCH, des actions doivent être prises pour améliorer la zone de localisation et le plan de zone de routage. Le Paging CHannel (PCH) est normalement dimensionné de telle sorte qu'il réponde aux besoins de la trafic de pagination normale prévu et les exigences de performance des appels de MT. Un surdimensionnement de la PCH conduit à un gaspillage de ressources.
En outre, la mise en œuvre au sein UTRAN de l'UTRAN mobility state permet une réduction supplémentaire de l'utilisation de la PCH que la pagination peut être fait sur une base cellulaire ou URA (UTRAN enregistrement Area) base plutôt que dans toutes les cellules UTRAN d'un RA ou LA particulier.
RAB establishment analysisintroductionProcédure d'établissement RABDès que la procédure d'établissement de connexion RRC a été achevé, la procédure d'établissement d’appel est finalisée via la procédure d'établissement de RAB.
La procédure d'établissement de RAB est exécutée en cas d'établissement d'appel avec:
• les appels Packet-switched (PS)
• les appels Circuit-switched (CS)
RAB établissement initiateurs
La procédure d'établissement de RAB est initiée par le réseau coeur, ce qui signifie SGSN pour les appels PS ou 3G-MSC pour les appels CS, lors de la réception d'un message montant de transfert direct RRC / RANAP de l'UE demandant soit un Packet Data Protocol (PDP) Context Activation (PS call) ou un Call Setup (CS call). Cette procédure est terminée avec succès lors de la réception de RANAP RAB message de réponse d'affectation au réseau central.
Flux d'appels d'établissement RAB
Un exemple de flux d'appels d’etablissement RAB :
PMS / KPI associés
Les PMS / KPI connexes sont les suivants:
• Total RAB establishment success rate
• Total number of RAB establishment failures.
échecs des tentatives de mise en place RAB
Les principaux composants d'échec des tentatives d'établissement de RAB peuvent être classés comme suit:
• Echecs de commande de support dynamique / Dynamic bearer control failures• échec de reconfiguration de liaison radio / Radio Link Reconfiguration failure• echecs des établissements de liaison radio / Radio Bearer Establishment failures• Les pannes diverses, par exemple le code starvation / Miscellaneous failures, for example Code Starvation.