Qos UMTS

Chapitre III : La qualit de service (QoS) dans le rseau UMTS
42

Introduction
UMTS a t conu pour supporter une grande gamme d'applications avec diffrentes
exigences de la qualit de service. L'approche modulaire adopte par 3GPP fournit la
flexibilit ncessaire pour les oprateurs d'offrir de nouveaux services leurs clients
potentiels et existants.
Dans 3GPP, la qualit de Service (Quality of Service : QoS) fait rfrence la qualit
d'un service perue par l'utilisateur.
Afin dassurer cette qualit de service, le UE et le rseau UTRAN effectuent des
mesures concernant des paramtres bien dtermins permettant ainsi de garantir le bon
fonctionnement du rseau UMTS.

III.1. Concept et architecture de la QoS
III.1.1. Architecture
Les services du rseau UMTS sont des services de bout en bout (dun quipement
terminal TE un autre TE). Un service de bout en bout doit avoir une certaine qualit de
service fournie lutilisateur pour satisfaire sa demande, afin de pouvoir garantir une certaine
qualit de service, des services supports (BS : Bearer Services) sont dfinis entre la source et
la destination dun service. Un service support comporte tous les aspects ncessaires pour
garantir la qualit de service. Ces aspects concernent : le contrle de signalisation, le transport
des donnes utilisateur et la fonction de gestion de la QoS. La figure suivante reprsente
larchitecture en couches des services supports de lUMTS. Chaque service support dun
niveau donn utilise les services offerts par les niveaux infrieurs.

Figure I I I .1: La QoS dans un rseau UMTS

43

III.1.2. Les Services Bearer
III.1.2.1. Le service de bout en bout et le service UMTS Bearer
En partant dun TE vers un autre, le trafic doit parcourir les diffrents services bearer
du rseau. Un TE est connect au rseau UMTS via un MT. Au niveau application, le service
de bout en bout utilise les services bearer du rseau correspondant.

Le service de bout en bout utilis par le TE est ralis par lutilisation dun Service
Bearer Local TE/MT, un Service Bearer UMTS et un Service Bearer Externe. Une varit de
services offerts par loprateur UMTS est dlivre par le Service Bearer UMTS. Cest ce
service bearer qui offre la QoS de lUMTS.

III.1.2.2. Le Service Radio Access Bearer et le Service Bearer Core Network
Le Service Bearer UMTS est scind en deux parties, le Service Radio Access Bearer et
le Service Bearer Core Network. Ces deux services refltent le moyen optimis pour raliser
le service bearer travers la topologie du rseau considr en considrant la mobilit et le
profil des abonns.

Le service radio access bearer assure un transport fiable de la signalisation et des
donnes utilisateur entre le MT et le CN Iu Edge Node en offrant la qualit de service
adquate pour le service bearer UMTS ngoci ou par une QoS par dfaut pour la
signalisation. Ce service est bas sur les caractristiques de linterface radio et maintenu pour
un MT en dplacement.

Les services radio bearer permettent davoir une protection derreur diffrente pour
chaque PDU (Packet Data Unit) en cas de besoin. Dans ce cas, linformation utile du SDU
des donnes utilisateur, transporte par le service radio access bearer, doit correspondre avec
le format de SDU dfini. Pendant ltablissement dun service radio access bearer, le format
exacte du champ dinformation du SDU ainsi que la consistance par sous flot est signale
UTRAN par lintermdiaire dattributs ou de paramtres standardiss (quon va tudier).

Le Service Bearer Core Network du rseau coeur de lUMTS, connecte lUMTS CN
Iu Edge Node avec la passerelle CN (CN Gateway) vers le rseau extrieur. Le rle de ce
service est de contrler efficacement le backbone pour assurer le service bearer UMTS
consenti. Le domaine paquet du coeur de rseau doit supporter des services bearer backbone
diffrents pour une varit de QoS.

44

III.1.2.3. Le Service Radio Bearer et le Service Iu Bearer
Le Service Radio Access Bearer est ralis par le Service Radio Bearer et le Service Iu
Bearer. Le rle du service radio bearer est de couvrir tous les aspects de transport sur
linterface radio. Ce service bearer utilise le service UTRA FDD/TDD.

Pour supporter diffrents types de protection derreur, UTRAN et le TM doivent avoir
la capacit de segmenter/r-assembler les flux de donnes en des sous-flux exigs par le
service radio access bearer. La segmentation/r-assemblage est donne par le format du
champ dinformation signal au moment de ltablissement du radio access bearer. Le service
radio bearer transporte la partie du flux de lutilisateur faisant partie dun sous-flux, selon la
QoS exige par ce sous-flux.

Le service Iu bearer et le service bearer physique assurent le transport entre lUTRAN
et le CN. Pour le trafic paquet Iu bearer doit fournir diffrents services bearer pour une varit
de QoS.

III.1.2.4. Le service Bearer Backbone

Le Service Bearer CN utilise un service bearer backbone gnrique. Le Service Bearer
Backbone couvre les fonctionnalits des deux premires couches et il est slectionn suivant
le choix de loprateur afin de raliser les exigences de QoS du service bearer CN. Le service
bearer backbone nest pas spcifique UMTS mais il peut rutiliser un standard existant
Est un service offert par des rseaux externes, qui peuvent tre UMTS ou non.

III.2. Fonctions de la gestion de la QoS dans lUMTS

Cette section donne une vue sur les fonctionnalits ncessaires pour tablir, modifier
et maintenir le service support UMTS avec la QoS demande. Lallocation de ces fonctions
aux entits de lUMTS doit indiquer les exigences dune entit spcifique pour renforcer les
engagements ngocis de la QoS du service support UMTS. Les fonctions de la gestion de la
QoS de toutes les entits de lUMTS combines doivent assurer la provision du service
ngoci entre les points daccs du service support UMTS.

III.2.1. Fonctions de QoS pour le service support UMTS dans le plan de
contrle

On distingue quatre fonctions de gestion pour le contrle de la QoS pendant
ltablissement dappel ou de la session.

45

III.2.1.1. Gestionnaire de service support

Les diffrents gestionnaires du service support grent les fonctions dtablissement, de
modification et de maintenance du service auquel ils sont responsables. En particulier, le
gestionnaire UMTS BS est responsable de tout change de signalisation gnre par les autres
fonctions comme les requtes de conversion, le contrle daccs, etc. Le gestionnaire de
service peut demander des services aux couches de service infrieures.

III.2.1.2. Fonction de conversion

Cette fonction est situe lextrmit du rseau UMTS, elle convertit les primitives de
service support UMTS en primitives externes correspondantes dans la direction dun rseau
extrieur et/ou de lquipement terminal. La conversion concerne les attributs de service
support UMTS et ceux de la QoS des rseaux externes. Le gestionnaire de service peut inclure
une translation pour convertir les attributs de service et ceux des couches basses utilisant ce
service.

III.2.1.3. Fonction de contrle dadmission ou de capacit

Elle contient les informations sur toutes les ressources disponibles des entits du
rseau et de toutes les ressources alloues au service support UMTS. Elle dtermine aussi
pour chaque service support les demandes ou les modifications si les ressources demandes
peuvent tre alloues par cette entit et peut les rserver pour une ventuelle allocation du
service support UMTS. La fonction vrifie galement la capacit de lentit rseau fournir
par le rseau demand.

III.2.1.4. Fonction de contrle dinscription

Elle vrifie les droits administratifs de lutilisateur du service support UMTS pour
manipuler le service demand avec les attributs spcifis de la QoS.

II.2.2. Fonctions de QoS pour le service support UMTS dans le plan usager

Les fonctions de gestion de la QoS dans le plan usager maintiennent la signalisation et
le trafic dun utilisateur bas sur les attributs de la QoS ngocie pour le service support
UMTS.


46

III.2.2.1. Fonction de mapping (Mapping Function)

Elle fournit chaque unit de donnes avec les marques spcifiques demandes pour
recevoir la QoS promise pour chaque nud.

III.2.2.2. Fonction de classification (Classification Function)

Elle dcide sur le choix dun service particulier parmi les services support UMTS
tablis pour un terminal mobile. Cette fonction assure ladaptation du flux de trafic, elle se
base sur les informations contenues dans len-tte du paquet ou sur dautres caractristiques
du trafic.

III.2.2.3. Gestionnaire de ressource (Trafic Manager)

Il distribue les ressources ncessaires entre les diffrents services partageant les
mmes ressources selon leur besoin en QoS. Exemples de moyens de gestion des ressources
sont lordonnancement, la gestion de la bande passante et le contrle de puissance pour le
service support radio.

III.2.2.4. Conditionneur de trafic (Traffic Conditioner)

Il applique des rgles pour vrifie la conformit du trafic vhicul avec le profil de la
QoS ngocie. Les fonctions de contrle comparent le trafic des units de donnes avec les
paramtres de la QoS. Les units de donnes nobissant pas au profil de la QoS peuvent tre
rejetes ou marques pour tre rejetes en cas de congestion.

III.3. Classes de trafic de la QoS de lUMTS
Lors de la dfinition des classes de la QoS, faisant rfrence aussi aux classes de trafic,
les restrictions et les limites de linterface radio doivent tre prises en compte, do ce nest
pas raisonnable de dfinir un mcanisme complexe comme le rseau fixe cause des
caractristiques derreur de cette interface. Donc le mcanisme de la QoS dans le rseau
cellulaire doit tre robuste et capable de fournir une rsolution raisonnable de QoS.

Les principales contraintes retenues pour la dfinition des classes de services de
lUMTS sont les suivantes :
Le dlai de transfert de linformation ;
La variation du dlai de transfert des informations ;
La tolrance aux erreurs de transmission.

47

III.3.1. Classe conversationnelle
Elle regroupe tous les services bidirectionnels impliquant deux interlocuteurs ou plus
comme la tlphonie, la visiophonie avec un dbit de 32 384 kbps et les jeux interactifs
avec un dbit de 1 kbps. Le dlai de transfert des donnes est de 100 200 ms.
Exemple : la tlphonie, la visiophonie ou des jeux vido constituent des services de classe A.

Figure I I I .2 : la classe A (conversationnelle)

III.3.2. Classe streaming
Cette classe est utilise pour les flux unidirectionnels comme les applications de
diffusion vido ou audio. Il nexiste pas de contraintes strictes sur le dlai de transfert pour
ces applications. Par contre, la variation du dlai est un paramtre important parce quil est
perceptible par lutilisateur. Toutefois, cette contrainte sur la variation du dlai reste tolrante
grce aux tampons du rcepteur qui peuvent amortir les variations du dlai si elles sont
toujours infrieures une limite donne.
Exemple : des services de la classe B sont la vido la demande, la diffusion de programmes
musicaux ou des transferts dimages.

Figure I I I .3 : la classe B (streaming).


48

III.3.3. Classe interactive
Cette classe est utilise pour les applications qui ncessitent une interaction entre les
deux extrmits de la communication. Un exemple dapplication de cette classe est la
navigation web. Cette classe est de type transactionnel. Elle ncessite une certaine contrainte
sur le dlai de transfert des paquets parce que lutilisateur attend une rponse dans une
certaine limite de temps. Cette contrainte nest pas stricte puisque ce sont des applications non
temps rel. En revanche, cette classe doit assurer un taux de perte des paquets assez faible
parce que les applications transportes par cette classe sont trs sensibles aux pertes.

Exemple : les services de la classe C sont, entre autres, la navigation sur Internet, le transfert
de fichiers par FTP, le transfert de messages lectroniques ou toutes les applications de
commerce lectronique.

Figure I I I .4 : la classe C (interactive)

III.3.4. Classe background
Cest la classe la moins exigeante en termes de dlai de transfert. Les applications
transportes par cette classe sont des applications dont lutilisateur nattend pas les paquets
dans une certaine limite de temps. La contrainte la plus importante est le taux de perte. Cette
classe est trs sensible la perte de paquets. Les applications e-mail et SMS constituent des
exemples de la classe background.
Exemple : les applications de la classe D sont, entre autre : le transfert de fax, la notification
de message lectronique ou la messagerie de type SMS (Short Message Service).

Figure I I I .5 : la classe D (background)

49

Le tableau suivant illustre les diffrentes classes :

Type de trafic
Dlai de
transmission
Gigue
Taux
derreur
Exemple de service et
applications
Conversationnel Strict < 150 ms Stricte Acceptable
VoIP, vido-tlphonie,
visioconfrence, audioconfrence
Streaming ou flux
continu
Limit < 250 ms Limit Acceptable
Service de diffusion (audio, vido),
actualits, sports
Interactif Limit < 1 s Non Trs faible
Navigation sur le Web, commerce
mobile, cyber-bavardage, jeux
Background ou
arrire-plan
Non Non Trs faible
Courriel, SMS, tlchargement de
BDs, transferts de mesure.

Tableau I I I .1 - Les classes de QoS de lUMTS

III.4. Les diffrences entre ces classes de QoS
La classe de conversation est destine la circulation de donnes sensibles au retard,
alors que la classe Background est insensible au retard.
Les classes Conversation et Streaming sont utiliss pour des applications en temps
rel, donc sensibles aux retards.
Les classes Interactive et Background sont essentiellement destins aux applications
telles que WWW, Email, FTP, et Telnet.
La classe Interactive est principalement utilise pour des applications interactives
comme l'email et le Web interactif, tandis que la classe Background est destin aux
tlchargements de fond d'arrire-plan.
L'algorithme d'ordonnancement donne une plus grande priorit la classe interactive
plutt qu la classe Background.

III.5. Attributs de la Qos
Lors de ltablissement ou la modification du service support UMTS, on doit prendre
en compte plusieurs aspects de la QoS :


50

Classe de trafic : Il faut savoir de quelle classe sagit-il afin de mettre en oeuvre un
mcanisme robuste et capable de fournir une rsolution acceptable de Qos.

Dbit binaire maximum : Cest la limite suprieure que lutilisateur ou lapplication
peut accepter ou fournir. Tous les attributs du service support UMTS peuvent tre
accomplis avec un trafic de dbit maximum suivant les capacits du rseau.

Dbit garanti : Cest le nombre de bits garantis dlivrs par lUMTS divis par la
dure. Il dcrit le dbit que doit garantir le service support UMTS pour un utilisateur
ou une application. Ce paramtre permet aussi de faciliter le contrle dadmission et
lallocation de ressource en UMTS bas sur leurs disponibilits.

Ordre de livraison des squences SDU : Ce paramtre spcifie si les SDU hors
squence sont accepts ou non, perdus ou rordonns suivant les prcisions spcifies.
Taille maximale dun SDU : Cest la taille pour laquelle le rseau satisfait la QoS
ngocie. Ce paramtre est utilis pour le contrle dadmission et la surveillance.

Information sur le format SDU : Elle liste exactement les tailles possibles des SDU.
LUTRAN a besoin de ces informations pour pouvoir oprer en mode transparent du
protocole RLC qui est avantageux pour lefficacit spectrale et les dlais lorsque la
retransmission au niveau du RLC nest pas utilise.

Taux derreur de SDU : Il indique la fraction des SDU perdus ou dtects errons. Il
est utilis pour configurer les protocoles, les algorithmes et les schmas de dtections
derreur, initialement avec lUTRAN.

Taux derreur binaire rsiduel : Cet attribut indique le taux de bits errons non
dtects dans le SDU dlivr. Sil ny a pas de demande de dtection derreurs, cet
attribut indiquera le taux derreur binaire dans le SDU dlivr. Il est aussi utile pour
configurer les algorithmes et les protocoles de linterface radio et la dtection des
erreurs de codage

Livraison des SDU errons : Elle indique si le SDU dtect erron doit tre dlivr
ou abandonn.

51

Dlai de transfert et gigue : Ce paramtre indique le dlai maximal pour acheminer
toutes les SDU dlivrs durant toute la dure de vie dun service support. Il permet
lUTRAN de dfinir les formats de transport et les paramtres ARQ. Le dlai de
transfert dun SDU arbitraire nest pas aussi significatif car un SDU peut avoir un
temps dattente important dans la file dattente. La gigue est dfinie comme tant la
variation de dlai de bout en bout. Certaines applications (audio et vido) subissent
une distorsion du signal avec de grandes valeurs de gigue.

Priorit de traitement du trafic : Elle spcifie limportance relative de manier tous
les SDU dun service support UMTS par rapport aux SDU dun autre. Avec la classe
interactive, on a besoin de diffrencier entre les qualits du service support, ce qui
permet lUMTS dorganiser en squence le trafic.

Priorit dallocation/maintien : Elle spcifie limportance de lallocation/maintien
dun service support UMTS par rapport aux autres.

Indication de signalisation : Cest un attribut additionnel de la QoS qui est dfini
seulement pour les services interactifs. Il indique la nature de la signalisation.

Le tableau suivant illustre les diffrentes classes de QoS et les attributs leurs tant dfinis :

Tableau I I .2 - Relations entre les classes de service et les attributs

52

III.6. Mcanismes de traitement de la QoS dans lUMTS
Plusieurs mcanismes sont mis en place pour le traitement de la QoS dans un rseau
UMTS. On peut distinguer ces mcanismes selon quils soient effectus au niveau des entits
du CN ou de lUTRAN.

III.6.1. Traitement de la QoS dans le rseau cur
Les caractristiques de la QoS supportes par le rseau coeur de lUMTS dterminent
sa capacit de diffrencier entre les services offerts aux abonns. Cette capacit offerte de
bout en bout assure que les ressources ncessaires sont attribues pour fournir un service
adquat un abonn en conservant lquit aux autres abonns et garantissant la QoS
ngocie.

III.6.1.1. Contrle dadmission dappel CAC (Call Admission Control)
Le CAC est excut sur tous les points de multiplexage (MSC, SGSN, GGSN, etc.)
pour rpondre aux deux questions : le nud peut-il accepter ce nouvel appel ? et le
nud sera-t-il capable de satisfaire aux besoins en QoS du nouvel appel et des appels tablis ?
. Il utilise un concept trs simple et flexible de bande passante quivalente. Le principe est
destimer les ressources rseaux ncessaires pour fournir la QoS demande et dterminer si
ces ressources sont disponibles. Si elles le sont, les ressources ncessaires sont rserves. Si
non, un mcanisme est lanc afin de diminuer la qualit de service (lutilisateur se verra
attribu un dbit plus petit, ou une priorit de traitement moins leve). Le CAC est excut
chaque activation dun contexte PDP (Packet Data Protocol) ou ltablissement dun appel
circuit, chaque fois la QoS est modifie, et durant le handover ou le dplacement du SRNC.

Pour garantir la QoS tous les niveaux, et pas seulement au niveau application, le
CAC prend en compte les ressources disponibles au niveau de la couche de transport IP.

III.6.1.2. Diffrenciation de la QoS entre les quipements utilisateurs
Plusieurs mcanismes sont disponibles pour isoler le trafic provenant de plusieurs
quipements utilisateur UMTS :


53

File dattente de diffrenciation :
Des techniques dordonnancement, tel que WFQ (Weighted Fair Queuing) ou WRR
(Weighted Round Robin), sont utilises pour traiter tout accs contentieux une ressource.
Ces techniques garantissent une bande passante minimale alloue pour chaque contexte PDP.

Les mcanismes de file dattente performants fournissent aussi une fonction de
politique implicite, puisque la bande passante est attribue en proportion la charge de
donnes. Cette fonction nagit que lorsquun lment du rseau est congestionn, souvent en
divisant la bande passante dune faon plus approprie. Elle est obligatoire pour supporter un
engagement sur la qualit de service.

Politique au niveau du GGSN :
Le GGSN est le nud de bordure dans le rseau UMTS, il reoit donc le trafic entrant
et vrifie que le trafic de donnes utilisateur est conforme aux attributs de la QoS du service
support UMTS correspondant. Le GGSN inclut un conditionneur de trafic, qui garantit la
conformit du trafic. Un autre rle du GGSN est de filtrer le trafic entrant selon les TFT
(Traffic Flow Templates), utiliss pour faire la distinction entre diffrents paquets utilisateurs
allant la mme adresse PDP.

III.6.1.3. Diffrenciation de service IP
La diffrenciation de la QoS est ncessaire pour assurer que le trafic UMTS sera
correctement trait sur le rseau. Sur le backbone UMTS, DiffServ est utilis au niveau de la
couche Internet du modle TCP/IP. Typiquement, le champ type de service (IPv4) ou classe
de trafic et tiquette de flux (IPv6) contient un code appel DSCP (Differentiated Services
Code Point) pour identifier et slectionner le PHB (Per-Hop Behavior) particulier quun
datagramme IP recevra un nud donn du rseau. Le DSCP est situ dans len-tte de
chaque paquet.

Lavantage majeur de DiffServ est quil na pas besoin de signalisation supplmentaire
au niveau de la couche IP. Toute linformation ncessaire sur la QoS est dj contenue dans
des messages de signalisation spcifiques lUMTS changs travers le PLMN (Public
Land Mobile Network). Ce protocole est essentiellement utilis pour les applications Internet.
En effet, ces applications nutilisent pas directement les services de lUMTS mais elles

54

utilisent les dfinitions et les attributs de la QoS dInternet qui seront mapps aux attributs de
la QoS UMTS.

III.6.2. Traitement de la QoS dans lUTRAN
Le concept fondamental de lUMTS est la sparation entre les fonctionnalits daccs
et les fonctionnalits du CN. LUTRAN fournit une plateforme daccs du MT tous les
rseaux curs et les services rseau. Une fonction de gestion des ressources radio RRM,
distribue entre le terminal, la station de base et le RNC, contrle la QoS sur le lien radio.

Cette fonction consiste en des algorithmes et des procdures de contrle dadmission,
de contrle de charge et de handover.

III.6.2.1. Contrle dadmission radio RAC (Radio Admission Control)
La fonction RAC accepte ou refuse laccs aux ressources radio. Elle intervient chaque
fois que des ressources radio dans une cellule doivent tre partages avec un autre utilisateur
ou un autre service support daccs radio, ou quand un utilisateur change de cellule.

Quand un RAB est tabli, le RNC fait correspondre les attributs de la QoS de ce RAB
aux caractristiques du support radio et invoque ensuite la fonction RAC. Les caractristiques
du support radio demand sont dtermines par la classe de trafic, les besoins en dbit binaire,
les besoins en dlai, les paramtres de priorit du trafic, etc.

Dans le systme UMTS dinterfrence limite, le RAC permet de dterminer si
lacceptation ou non dun nouveau RAB augmentera les interfrences au-del dun niveau
acceptable, rendant possible le maintien dune qualit radio acceptable pour tous les appels
tablis. La charge de trafic doit tre aussi considre : accepter un nouveau RAB ne doit
rduire ni le dbit ni la qualit de service offerts aux autres utilisateurs, en dessous des limites
acceptables. Les demandes qui ne peuvent pas tre acceptes selon ces critres sont rejetes
par lUTRAN ou mises en file dattente si cette possibilit est disponible.

Du point de vue de lutilisateur, il est plus acceptable davoir un appel rejet la phase
de connexion, que dtre coup en pleine conversation parce que le handover na pas t
possible. Une capacit doit donc tre rserve au handover ; le handover et ltablissement
dun appel peuvent tre traits avec diffrentes priorits.


55

III.6.2.2. Gestion et allocation des ressources radio
Des oprations de canalisations et dembrouillages sont ncessaires au niveau
physique radio afin de sparer les diffrentes sources de trafic partageant les mmes
frquences. La fonction dallocation de ressource radio alloue des codes de canalisation et
dembrouillage quand la fonction RAC les demande.

III.6.2.3. Contrle de la charge radio
Cette fonction maintient la stabilit du rseau radio en contrlant la charge, et en
dtectant et traitant les situations de surcharge (c'est--dire quand le rseau fonctionne au-del
de ses ressources). En particulier, le contrle de la charge radio garantit que certains
algorithmes, comme le contrle de puissance, demeurent stable dans lventualit dune
surcharge temporaire. Deux effets peuvent se produire dans de telles situations. Sur la voie
montante, les terminaux mobiles peuvent augmenter leur puissance de transmission pour faire
face laugmentation des interfrences rendant la situation plus mauvaise encore. Un effet
similaire peut se produire sur la voie descendante. Les situations de surcharge radio sont
dtectes en contrlant les niveaux dinterfrence et le volume de trafic. Le contrle de
congestion peut tre ralis en utilisant des algorithmes de prvention en coordination avec le
RAC.

III.6.2.4. Synchronisation et ordonnancement
Les mcanismes de synchronisation sont dfinis dans lUTRAN pour satisfaire aux
besoins en temps pour chaque type de RAB. Lajustement du temps a lieu entre le NodeB et
les RNC pour maintenir le dlai du transfert total travers lUTRAN au-dessous des limites
donnes qui dpendent du type du canal de transport utilis dans lUTRAN, qui lui-mme
dpend des attributs de la QoS du RAB. Par exemple, les services de la parole exigent un
dlai du transfert court, alors que les services de donnes NRT (Non Real Time) peuvent
tolrer des dlais plus grands mais contraignants. Dans le cas du trafic NRT, un contrle de
flux peut avoir lieu entre les nuds de lUTRAN. Pour le trafic sur la voie descendante,
lordonnancement des units de donnes sur linterface radio est contrl par le RNC qui
dfinit le temps effectif de transmission de chaque bloc.

Dans le RNC, ils existent deux files dattente pour la gestion des trafics, voix et
donnes. Lalgorithme de gestion de la file dattente donne une plus haute priorit pour les

56

paquets situs dans la file du trafic voix. La file des donnes nest servie que lorsque la file de
la voix est vide.

III.6.3. Procdure de ngociation de la QoS entre les entits du rseau
Le diagramme suivant montre la manire avec laquelle les diffrents supports radio
sont grs dans le cas o un service de bout en bout est initi dans lquipement utilisateur et
une ngociation de la QoS est effectue.

Lors dune demande de connexion, le mobile transmet au GGSN les paramtres de sa
connexion travers un message PDP context . Ds la rception de ce message, le GGSN
dtermine le NodeB partir duquel il a reu cette demande et transmet les paramtres de la
connexion au RNC correspondant dans un RAB pour quil alloue les ressources ncessaires
lapplication concerne. Le RNC dtermine toutes les connexions servies travers ce NodeB
ainsi que leurs paramtres de connexion. Si les ressources ncessaires pour la nouvelle
connexion ne sont pas disponibles, le RNC excute un algorithme de contrle dadmission et
de nouvelles valeurs des paramtres de connexion sont alors attribues aux diffrentes
applications. Si le paramtre QoS ngociable est activ, une ngociation des paramtres de
connexion est effectue entre lUTRAN et le CN. Dans le cas o le nouveau profil est
accept, le support radio et le lien radio sont tablis entre lUTRAN et lquipement de
lutilisateur. Dans le cas contraire, la connexion choue.

Figure I I I .6 : Gestion des diffrents supports et ngociation de la QoS

57

III.7. Les paramtres Radio mesurables
III.7.1. Les mesures effectus par UE
Les composants de mesures fournissent un support pour les mesures intrieures
spcifiques de lUE L3 RRC ainsi que le reportage des mesures pour UTRAN. Le composant
RRC utilise Cell RSCP et les mesures de EC/N0 pour les procdures de slection et re-
slection des cellules et aussi pour le contrle de puissance boucle ouverte. Il a besoin aussi
de mesures du BER pour le contrle de puissance boucle extrieur. LUTRAN requis les
mesures priodiquement ou bien pour un vnement de la gestion de handover, contrle de
radio bearer ou bien UE positionnement. Ces mesures suivent les mesures de timing des
cellules et mettent jour les relatives timing de la cellule utilise par RRC au mme temps
que les mesures changent. Le composant de mesure maintien les informations sur les cellules
qui doivent tre mesures, partage les mesures avec le composant de slection / re-slection
de cellule et les informations sont fournis UE dans SIB11 (System Information Block),
SIB12 et les messages de contrles sont utiliss pour spcifier les mesures qui doivent tre
effectues.

III.7.2. Gnral
Les rapports et les mesures de contrle sont utiliss par UTRAN pour contrler les
mesures que doit effectuer lUE. Le processus est trs versatile et permet plusieurs mesures
avec diffrents caractristiques dtre reportes, modifies et ralises au mme temps dans
les tats de RRC, les mesures sont contrler par SIB11, SIB12 et les messages de contrle de
mesures reus par RRC. Dans le mode idle, les informations de contrle de mesures sont lues
partir SIB11 dans FACH alors que SIB12 est utilis dans les modes paging. Les messages
de contrle de mesures sont utiliss dans tous les modes connects. Chaque mesure a une
unique identit, type, objet, quantit de mesure, quantit reports, validit, mode et des
identits additionnelles.

Les types de mesures suivants sont supports :
Les mesures intra-frquences : mesures sur les canaux physiques en DL effectues sur
la mme frquence dActive Set.
Les mesures inter-frquences : mesures sur les canaux physiques en DL effectues sur
des frquences diffrentes de celle dActive Set.
Les mesures interRAT : mesures sur les canaux physiques en DL appartenant un
autre rseau daccs radio GSM par exemple.

58

Les mesures de volume de trafic : sont effectues sur le trafic en UL.
Les mesures de qualit : mesures des paramtres de qualits en DL.
Les mesures intrieures du UE
Les mesures de positionnement dUE
Les rapports de mesures RACH

Les cellules sont groupes suivant trois exclusifs sets :
Active set dfini comme le set des cellules utilises pour la connexion courante,
ces cellules sont impliques dans le mcanisme de soft handover.
Neighbour set (Monitored set) est dfini comme le set des cellules pour lesquelles
lUTRAN doit effectuer les mesures pour une situation particulire (comme
handover) et que leur valeur Ec/Io nest pas suffisamment importante pour tre
incluses dans la liste Active set.
Le set dtect est dfini par les cellules dtectes par UE qui ne sont ni dans le set
active ni dans le set moniteur.

III.7.3. Les mesures de la couche physique
Ces mesures sont effectues dans la couche physique puis reportes vers la couche
RRC de UE ou bien UTRAN.

III.7.3.1. CPICH RSCP
Cette mesure est utilise pour lvaluation du handover, contrle de puissance boucle
extrieure, contrle de puissance boucle ouverte en UL et pour le calcul du pathloss. Il est
dfini comme la puissance du code de signal reu RSCP (Received Signal Code Power). La
puissance reue pour un code est mesure sur le canal CPICH primaire de la cellule. La valeur
de la puissance est entre -115 dBm et -40 dBm.

III.7.3.2. UTRAN Carrier RSSI
Cette mesure est pour lvaluation du handover inter frquence. Il est dfini comme la
puissance de la largeur de bande incluant le bruit thermique et le bruit gnr par le rcepteur.
Le rang pour UTRAN Carrier RSSI est entre -101 dBm et -25 dBm.


59

III.7.3.3. GSM Carrier RSSI
Cette mesure est pour le handover entre UTRAN et le GSM. Il est dfini comme RSSI
(Received Signal Strength Indicator). Cest la puissance reue de la bande troite sans celui de
la largeur de bande du canal. Il est fourni par la porteuse BCCH du GSM.

III.7.3.4. CPICH_Ec/Io
Cette mesure est pour la procdure de slection/re-slection de cellule ou bien pour
lvaluation du handover. Lnergie reue par chip est divise par la densit de puissance de
la bande.

Cette mesure est fournie par le canal CPICH primaire. Le rang du CPICH_Ec/Io est entre -24
dBm et 0 dBm.

III.7.3.5. UE transmitted power
Cette mesure est la puissance totale transmise par UE dans une porteuse. Le point de
rfrence pour la puissance transmise dUE est le connecteur de lantenne. Cette mesure varie
au tour de 21 dBm.

III.7.4. Les paramtres significatifs
Dans le rseau UMTS, trois lments lis aux particularits de la WCDMA peuvent
avoir un impact sur la qualit de service. Il sagit des problmes de brouillage du canal pilote
(pilot channel pollution), de la mauvaise configuration de la fentre de recherche (search
window configuration) ou de la couverture fluctuante en fonction de la charge des cellules.

Pour les paramtres Radio, daprs nos tudes, essentiellement, les paramtres qui
donnent une indication sur le niveau de la qualit radio dans la cellule de service. Ces
paramtres sont :
le rapport signal bruit (Ec/Io)
le rapport (Eb/No) qui reprsente la qualit du lien radio
FER (Frame Error Rate).

Mais les valeurs seuils des paramtres Eb/No et FER varient selon le type de service et
le nombre dutilisateurs servis dans la cellule courante.
CPICH_Ec/Io = CPICH_RSCP/UTRA carrier
RSSI


60

En effet, le mobile doit atteindre une valeur cible de Eb/No pour quil puisse pouvoir
accder au rseau. Pour atteindre cette valeur cible, le mobile doit mettre avec une certaine
valeur de puissance spcifie par le processus de contrle de puissance.

Pour chaque service, le rseau spcifie une valeur cible de Eb/No pour avoir une
bonne qualit de service.
Pour le service voix (12,2 kbit/s) : Eb/No cible = 5 dB, FER = 3 %
Pour le service de classes interactives (64 kbit/s) : Eb/No cible = 3 dB, FER=1%
Pour le service de classe conversationnel (144 kbit/s) : Eb/No cible= 1,5 dB,
FER=2%

III.8. Les techniques dvaluation de la QoS
Pour la mise jour de ltat de fonctionnement du rseau, plusieurs outils danalyses
de la QoS, sont mis en place. La comparaison des indicateurs obtenus par ces techniques et les
paramtres de seuil, permet lidentification des origines des problmes. Ces techniques se
basent sur des analyses de linterface radio (Drive Test) et sur des analyses systmes
(compteurs OMCR).

III.8.1. Drive test
La mthode de mesure du drive test consiste la caractrisation prcise des canaux
radio. Cette technique danalyse permet la rcupration dune trace des mesures faites par le
mobile diffrents instants.
Le drive test nous offre une srie de mesures en mode circuit ou paquet, dont les principales
sont :
Longitude, latitude (X, Y):le systme de localisation GPS nous donne les coordonns
de chaque point de mesure.
UARFCN: UMTS Radio Absolute Frequency Channel Number.
SC: Scrambling code number.
LAC: Location Area Code.
CI : Identit de la cellule.
RA: Routing Area Code.
URA: UTRAN Registration Area.
CPICH_power : la puissance en dBm sur le canal de contrle P-CPICH.
MAX_TX_power : la puissance maximale transmise pour la cellule.

61

CPICH_RSCP.
Ec/Io.
SIR : Rapport signal sur interfrence.
BLER % : Taux derreur des blocs.
UTRA carrier RSSI.
SHO State.
SHO Event Success Rate.

Le drive test nous permet aussi de faire la mesure de certains indicateurs spcifiques
au mode paquet et dont quelques un sont rcapituls dans les tableaux suivant :

Indicateurs d'accs au rseau UMTS
Description Calcul

Taux d'indisponibilit de
la couverture UMTS

Nombre de points de mesures o le service est indisponible /
nombre de points de mesures

Taux d'chec
dtablissement de la
connexion UMTS

Nombre dchec de tentatives dactivation de PDP Context /
Nombre de tentatives dactivation du PDP Context

Dure moyenne de
ltablissement de la
connexion UMTS

La dure de ltablissement de la connexion UMTS est la
mesure de lintervalle de temps entre le clic de composer aprs
le lancement de la connexion modem et laffichage de
connexion tablie

Dure moyenne de
dconnexion

La dure de dconnexion UMTS est la mesure de lintervalle
de temps entre le clic sur le bouton dconnecter et la
disparition de la bote de dialogue de la connexion du modem
UMTS.

Tableau I I I .3 - I ndicateurs d'accs au rseau UMTS


62

Indicateurs du service WEB
Description Calcul

Taux d'chec du service
Web

Nombre de sries o une page au moins na pas t charge
correctement / Nombre de sries effectues avec Connexion
Modem UMTS ralise (coupures exclues)

Dure moyenne de
chargement dune page

La dure de chargement dune page est la mesure de
lintervalle de temps entre la validation de lURL dans
lexplorateur internet et de laffichage du message termin
en bas gauche, la page tant correctement et intgralement
charge.

Taux de coupure de la
connexion durant le
service Web

Nombre de coupures de la connexion modem UMTS /
Nombre de connexions modem UMTS ralises

Dbit apparent du
service Web

Somme des tailles des pages charges / Somme des dures de
chargement.
Tableau I I I .4 - I ndicateurs du service WEB

III.8.2. Compteurs OMC-R
Lune des principales fonctions de lOMC-R est la gestion de performance. Les
mesures de performance sont bases sur la collection des compteurs calculs par les entits du
rseau travers linterface ltf-R reliant lOMC-R et le RNC et linterface ltf-B entre OMC-R
et Node B. Ces mesures sont fondamentalement utilises pour quatre types de besoin :
loptimisation et la planification efficace du rseau
les statistiques
linvestigation dtaille dun problme pass
lanalyse temps rel

Les mesures des compteurs au niveau de lOMC (remonts par les Nodes B lOMC-
R) sont faites sur un intervalle de temps prcis et sont lies un vnement survenu dans le
rseau. Elles servent aux calculs des indicateurs cls de performance KPI (Key Performance
Indicators) du rseau par combinaison de ces compteurs selon des formules bien dtermines.
Lanalyse de ces indicateurs est trs essentielle pour la supervision de la qualit de service.


63

III.9. KPI (Key Performance Indicators)
toute phase du cycle de vie du rseau, l'analyse QoS suie un processus de drill-
down. Au sommet, il y a un nombre rduit de critres de QoS qui rsument l'accomplissement
de la QoS lutilisateur final. Ce sont ces critres qui sont appels Key Performance
Indicators (KPI).

Les KPI valuent fondamentalement la performance dun service suivant : le volume
du trafic dans le rseau, l'accessibilit au rseau, le maintien de l'appel, la qualit du service
Enduser, le trafic rseau, le comportement du Soft et Hard Handover.
Dans RNO ces KPI sont compils soit par RNC ou par zone cellulaire. Au moyen de Drive
Tests, ces indicateurs sont compils sur campagnes d'appels rptitifs, sur la rgion de service.

Volume de trafic

Indicateurs

Description

RRC connection request

Volume de demandes de connexion RRC, y compris tous les
accs au rseau (RAB, SMS, NAS, etc.)

Call setup request for voice,
visio and PS

Volume de demandes d'tablissement RAB (pour chaque RAB
CS et PS et pour chaque dbit de donnes UL et DL), a reflte
le trafic utilisateur sur l'air et sur UTRAN.

Tableau I I I .5 - I ndicateurs du volume de trafic
Maintien de l'appel

Indicateurs

Description

Radio Call Drop Rate for
voice, visio and PS services

Le taux de coupure dappels sur linterface radio.

System Call Drop Rate
for CS and PS services

Le taux total de coupure dappels dtectes par
UTRAN (incluant radio call drop).

Tableau I I I .6 - Indicateurs du maintien de lappel


64

Comportement du Soft Handover

Indicateurs

Description

Users with 1, 2, 3 or 4 radio
Links

La distribution de Active Set dans le rseau.

Soft and Softer HO rates

Le rapport dutilisateurs en Soft et Softer Handover.

Tableau I I I .7 - I ndicateurs Soft Handover
Comportement du Handover

Indicateurs

Description

Inter-RAT HO success
Rate

Taux de succs de HO 3G 2G pour le service de la voix.

Emergency HO success rate

Taux de succs de HO durgence 3G 2G pour le service
de la voix.
Tableau I I I .8 - I ndicateurs Handover

Les KPI sont extraits pour le rseau entier comme un tableau en premier lieu. Puis, le
Processus de Drill-Down consiste mieux dtailler KPI, dtecter la mauvaise cellule, heure
de pointe et correspondant les problmes de QoS avec la situation du rseau.
Ce processus consiste donc dtecter un comportement erratique au niveau du rseau
en premier lieu, puis s'approfondir dans une analyse plus dtaille par :
dterminer les cellules avec le comportement le plus mauvais
traquer l'volution de toutes les heures des cellules les plus mauvaises

Si un des KPI dpassent les seuils fixs par loprateur, le superviseur du rseau
remarque quun problme est parvenu au niveau de la fonctionnalit quassure cet indicateur.
Gnralement, la cause de ce problme peut tre un problme de couverture, interfrence,
insuffisance de capacit, mauvais paramtrage du rseau
Par exemple si le taux de coupure de lappel est suprieur 2% alors on a un problme
de maintien dappel qui peut tre caus par la mauvaise couverture, linterfrence, problme
lors du handover (dans ce cas on consultera les taux de succs de handover) ou un mauvais
paramtrage du rseau. Aussi si le taux de succs de ltablissement dun service est infrieur

65

95%, dans ce cas on a un problme daccs au rseau caus par la capacit, linterfrence ou
un problme de paramtrage du rseau.
Le tableau suivant illustre les seuils de quelques KPI :

Indicateurs Seuils
Taux de perte des sessions < 5%
Taux de retransmission des sessions < 5%
Taux dtablissement des sessions > 95%
Taux de coupures sessions RNC 2%
Taux des sessions russis > 95%
Taux de coupures sessions radio 2%
Taux de coupures dappels (call drop) 2%
Taux dtablissement dappels (call setup) >95%
Taux dappels russis (call success) >95%
Taux dchec de handover 2%
Tableau I I I .9 - Seuils KPI

Conclusion
Dans ce chapitre, nous avons analys la notion de qualit de service et les
caractristiques de ce concept. Nous avons galement analys les attributs de la QoS. Dans la
dernire partie nous avons identifi les paramtres radio mesurables du rseau UMTS comme
ils ont t normaliss par le 3GPP. Et nous avons expliqu les mthodes dvaluation de
performances et les principaux indicateurs de qualit de service que permet dassurer chaque
mthode. Ensuite, nous avons numr les divers KPI qui peuvent tre affects un tel
rseau.

Qos UMTS

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Qos UMTS

Hochgeladen von

Copyright:

Verfügbare Formate

Chapitre III : La qualit de service (QoS) dans le rseau UMTS

Das könnte Ihnen auch gefallen