Professional Documents
Culture Documents
Nicolas DAILLY
Optimisation des Rseaux d'Accs Mobiles
pour les systmes E-GPRS et B3G
Prsident
Rapporteurs
Sami Tabbane
Philippe Godlewski
Examinateur
Thanh Luu Ha
Philippe Martins
Directeur de thse
Anne
mes parents
Remerciements
Cette thse n'aurait pu aboutir sans le soutien et les encouragements, au quotidien, des
personnes qui m'ont accompagnes pendant ces quelques annes.
Je tiens remercier, en premier lieu, mon directeur de thse, M. Philippe Martins, pour
m'avoir propos cette thse et m'avoir guid jusqu' son aboutissement. Je le remercie
de m'avoir donn toute libert de dmarche et de moyens pour mener mes travaux.
Je lui suis reconnaissant pour la confiance, l'coute et le soutien qu'il m'a tmoign tout
au long de la ralisation de cette thse.
Je souhaite galement remercier le professeur Philippe Godlewski pour les changes
trs enrichissants que j'ai pu avoir avec lui. Sa grande exprience, ses points de vue originaux et son sens critique m'ont permis d'largir ma vision du domaine des rseaux.
Je remercie les professeurs Xavier Lagrange et Sami Tabbane d'avoir accept la lourde
charge d'tre rapporteurs de cette thse. Je remercie galement le professeur Bijan Jabbari d'avoir accept de prsider le jury de cette thse ainsi que M. Thanh Luu Ha, pour
sa participation au jury.
Je remercie galement les enseignants chercheurs du dpartement INFRES, et plus particulirement MM. Laurent Decreusefond et Nicolas Puech, qui m'ont, plusieurs reprises, tmoign de leur soutien.
Je garderai un excellent souvenir de tous les doctorants et stagiaires qui se sont succds
en C234, et en particulier M. Axel Dumeur, M. Talal Ackar Diab et Melle Carle Lengoumbi. Les changes que j'ai pu avoir avec eux ont contribu une meilleure avance
de mes travaux.
La bonne humeur et l'ambiance qui rgne au sein du dpartement INFRES ont contribu
me laisser un excellent souvenir de mon passage au sein de l'ENST. Je remercie le
personnel et les tudiants de l'cole pour tout ce qu'ils m'ont apport.
Pour complter ces remerciements, je me dois de remercier mes amis anciens de l'ESIEE-Amiens - qui m'ont accompagn pendant ces quelques annes sur Paris. Merci
donc Michael, Igor, Olivier et Benjamin pour toutes les activits que nous avons pu
faire ensemble.
En dernier lieu, je tiens adresser un grand merci mes parents, pour avoir toujours cru
en moi et m'avoir soutenu tout au long de mes tudes. Je remercie galement Anne
dont la patience a souvent t mise rude preuve - pour le soutien qu'elle m'a apport.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
10
11
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 2.5.1.1. Nombre de trames R-LLC perdues au cours d'un transfert WIFI vers GPRS
(diffrence emis/recus)..................................................................................................................... 133
Figure 2.5.1.2. Nombre de trames R-LLC perdues au cours d'un transfert WIFI vers GPRS
(diffrence gnrs/transmis)........................................................................................................... 134
Figure 2.5.1.3. Temps de transmission des trames R-LLC.............................................................. 134
Figure 2.5.1.4. Temps de transmission des objets au niveau application.........................................135
Figure 2.5.1.5. Nombre moyen de paquets TCP transmis par mobile..............................................136
Figure 2.5.2.1. Nombre moyen de paquets R-LLC perdus par mobile............................................ 137
Figure 2.5.2.2. Temps moyen de transmission des paquets R-LLC.................................................137
Figure 2.5.2.3. Nombre moyen de paquets TCP transmis par mobile..............................................138
Figure 2.5.2.4. Temps moyen de transmission des objets au niveau application.............................139
Figure 2.6.1. Nombre de blocs RLC perdus au cours d'un transfert GPRS vers WIFI (diffrence
emis/recus)........................................................................................................................................139
Figure 2.6.2. Nombre de blocs RLC perdus au cours d'un transfert GPRS vers WIFI (diffrence
gnrs/transmis).............................................................................................................................. 140
Figure 2.6.3. Nombre de blocs R-LLC perdus au cours d'un transfert GPRS vers WIFI (diffrence
mis/reus)........................................................................................................................................141
Figure 2.6.4. Nombre de blocs R-LLC perdus au cours d'un transfert GPRS vers WIFI (diffrence
gnrs/transmis).............................................................................................................................. 141
Figure 2.6.5. Temps de transmission des trames R-LLC................................................................. 142
Figure 2.6.6. Nombre de paquets TCP perdus au cours d'un transfert GPRS vers WIFI (diffrence
mis/reus)........................................................................................................................................142
Figure 2.6.7. Nombre moyen de paquets TCP transmis par mobile.................................................143
Figure 2.6.8. Temps de transmission des donnes gnres par la couche application................... 143
Figure 3.3.1. Nombre moyen de blocs RLC perdues au cours d'une reslection (trafic streaming) 146
Figure 3.3.2. Nombre moyen de trames R-LLC perdues au cours d'une reslection (trafic streaming)
.......................................................................................................................................................... 147
Figure 3.3.3. Nombre moyen d'objets perdus et transmis au cours d'une reslection (trafic
streaming)......................................................................................................................................... 147
Figure 3.3.4. Temps de transmission au niveau R-LLC et Application (trafic streaming).............. 148
Figure 3.4.1. Nombre moyen de trames R-LLC perdues au cours d'une reslection (trafic streaming)
.......................................................................................................................................................... 149
Figure 3.4.2. Nombre moyen de d'objets perdus et transmis au cours d'une reslection (trafic
streaming)......................................................................................................................................... 150
Figure 3.4.3. Temps moyen de transmission des donnes (trafic streaming)...................................151
Figure 3.5.1. Nombre moyen de bloc RLC perdus au cours d'une reslection (trafic streaming)... 152
Figure 3.5.2. Nombre moyen de trames R-LLC perdues au cours d'une reslection (trafic streaming)
.......................................................................................................................................................... 152
Figure 3.5.3. Nombre moyen de d'objets perdus et transmis au cours d'une reslection (trafic
streaming)......................................................................................................................................... 153
Figure 3.5.4. Temps moyen de transmission des donnes (trafic streaming)...................................154
Figure 2.1. Architecture du rseau IMS (d'aprs [3GPP 23.002])....................................................158
Figure 4.1. architecture de la couche SigComp (d'aprs [RFC 3320]).............................................162
Figure 5.1.1. Arbre de Huffman ...................................................................................................... 164
Figure 6.2.1. Principe de la compression avec dictionnaire............................................................. 172
Figure 7.1. Echange SIP entre le terminal et le P-CSCF..................................................................173
Figure 7.1.1. Performances des compresseurs LZ77, LZW et Deflate (sans utilisation de
dictionnaire)......................................................................................................................................174
13
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 7.2.1. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire).. 175
Figure 7.3.1. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire).. 176
Figure 7.3.2. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire).. 177
Figure 7.4.1. Performance de compression de Deflate (sans dico).................................................. 178
Figure 7.4.2. Taux de compression de Deflate (sans dico)...............................................................179
Figure 7.4.3. Performance de compression de Deflate (avec dico)..................................................179
Figure 7.4.4. Taux de compression de Deflate (avec dico).............................................................. 180
Figure 7.5.1. Contribution des diffrentes solutions de compression (EPIC + Dico + Deflate)...... 181
Figure 7.6.1. Contribution des diffrentes solutions de compression (Dico + 1 message + Deflate)
.......................................................................................................................................................... 181
Figure 3.1.1. Architecture de l'E-UTRAN [3GPP 36.300]...............................................................186
Figure 1.1. Chane de Markov un seul serveur et de capacit 4 (M/M/1/4).................................. 191
Figure 1.2. Modulation des taux d'arriv et de dpart des utilisateurs............................................ 191
Figure 1.3: Automate rsultant : File MMPP/M/1/4 module......................................................... 192
Figure 2.1. Automate de trafic IPP................................................................................................... 192
Figure 2.2. Profil de trafic gnr l'aide d'une IPP........................................................................ 193
Figure 2.1.1. Positions des piles pour l'approche micro-circuit ................................................. 201
Figure 2.1.2. Positions des piles pour l'approche avec bufferisation ..........................................201
Figure 2.2.1. Gestion des vnements.............................................................................................. 202
Figure 1.1. Exemple de transmission au niveau RLC...................................................................... 211
Figure 2.1. Dialogue au niveau LLC entre deux Emetteurs / Rcepteurs........................................ 213
Figure 1. Les diffrents types de handover GSM.............................................................................215
Figure 1. Couche protocolaire du protocole TCP/IP........................................................................ 217
Figure 2. Exemple dchange TCP..................................................................................................219
Figure 3. Exemple d'change TCP (avec segmentation).................................................................. 220
Figure 1.1. Phase de prparation du handover inter-SGSN [3GPP 43.129].....................................221
Figure 1.2. Phase d'excution du handover inter-SGSN [3GPP 43.129]......................................... 223
Figure 2.1.2.1. Station mobile dans son rseau nominal.................................................................. 225
Figure 2.1.3.1. Solution Mobile IP avec Foreign Agent............................................................ 226
Figure 2.1.4.1. Solution Mobile IP sans Foreign Agent............................................................. 226
Figure 2.2.1.1. Exemple de topologie d'un rseau implmentant Cellular IP ............................ 228
Figure 2.2.2.1. Cellular IP : situation initiale................................................................................... 229
Figure 2.2.2.2. Cellular IP : situation intermdiaire......................................................................... 229
Figure 2.2.2.3. Cellular IP : situation finale..................................................................................... 230
14
15
Introduction Gnrale
Introduction Gnrale
Les rseaux de tlcommunications ont subi de profondes mutations ces dernires annes. Les technologies de communications lectroniques tiennent dsormais une place
majeure dans l'organisation de nos activits. Jusqu' la fin des annes 90, les rseaux de
tlcommunications taient spcialiss entre, d'un cot, les rseaux tlphoniques et, de
l'autre, les rseaux de donnes. Les interconnexions entre ces deux types de rseaux
taient par ailleurs limites.
L'une des volutions majeures des rseaux de tlphonie a t le dploiement du systme GSM. Ce dernier a permis d'offrir un service de tlphonie mobile performant et
abordable. Les utilisateurs se sont habitus pouvoir tlphoner de partout, sans subir
d'interruption de leurs communications au cours de leurs dplacements. Paralllement,
les rseaux de donnes ont galement subi d'importantes volutions, comme en tmoigne le succs du rseau Internet et des offres d'accs haut dbit. Au fur et mesure
de l'augmentation des dbits offerts, les utilisateurs ont adopt de nouveaux services. Au
dpart restreint la consultation de pages texte et de services de messagerie, le rseau
Internet permet dsormais d'accder de nombreux contenus multimdia. Le dveloppement des services de voix sur IP (VoIP) a amorc un rapprochement entre le domaine
des rseaux et celui de la tlphonie.
La prochaine tape de cette volution consiste permettre l'accs aux contenus multimdia travers un terminal mobile. D'ores et dj, tout abonn mobile peut accder aux
services de base de l'Internet : consultation de pages WAP, envoi et rception de MMS
ou de mails. Ces services ne rpondent cependant pas tous les besoins des utilisateurs.
Les nouveaux services comme le tlchargement de fichiers musicaux ou la diffusion de
vidos la demande ncessitent d'amliorer la qualit de service offerte par les rseaux
mobiles. L'augmentation des capacits de transmission, au niveau des sous-systmes
radio, passe par l'utilisation de techniques de modulation plus performantes, mais aussi
par une optimisation des rseaux d'accs cellulaires. La mise en place de services
temps rel ncessite de rduire le temps de transfert de la signalisation travers les
rseaux d'accs mobiles. Par ailleurs, les utilisateurs, habitus aux systmes de tlphonie mobiles, souhaitent pouvoir bnficier de la mme libert de dplacement. Des mcanismes performants de handover et de reselection doivent donc tre implments pour
assurer la continuit des services multimdia.
La technologie E-GPRS s'appuie sur l'architecture des rseaux d'accs GSM existants.
Cependant, l'introduction de schmas de codage qui offrent des dbits plus importants
(jusqu' 61,85kbits/s/slot) ncessite de revoir la gestion des ressources sur l'interface
Abis. La premire partie de cette thse tudie diffrents mcanismes d'allocation dyna-
17
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
18
1. Introduction
La technologie E-GPRS Enhanced General Packet Radio Service est conue pour
amliorer lefficacit du transport de donnes en mode paquet sur linterface Air du systme GSM/GPRS. L'augmentation des dbits possibles sur l'interface radio a des rpercussions sur le transport de donnes sur l'interface Abis. Dans le systme GSM, lallocation des ressources sur lAbis repose sur une association statique entre les ressources de
linterface Air et celles de lAbis. Cette approche est adapte pour un service de voix
comme GSM, o les dbits la sortie des vocodeurs sont rguliers et limits. Elle n'est
plus adapte dans le cadre du dveloppement des services de donnes en mode paquet
tels que dans E-GPRS o l'utilisation des ressources radio est trs sporadique. Par
ailleurs, les schmas de modulation et de codage permettent d'atteindre des dbits qui
dpassent les capacits de transmission dun canal de linterface Abis, soit 16kbits/s.
L'introduction de technologies telles que E-GPRS, qui supporte thoriquement des dbits allant jusqu' 61kbits/s par slot radio, doit donc saccompagner dune modification
de la politique dattribution des ressources sur linterface Abis.
Ce chapitre se propose d'tudier les performances de deux approches d'allocation dynamique de ressources sur l'interface Abis. Elles permettent d'couler du trafic des dbits
dpassant 16kbits/s sans changer la structure de trame de l'interface Abis. Deux approches sont ici considres. La premire, appele approche micro-circuit , consiste
associer chaque slot de l'interface Air, un ou plusieurs slots sur l'interface Abis. La seconde, consiste dissocier la transmission sur les interfaces Air et Abis en ajoutant une
mmoire tampon (on utilisera le terme buffer par la suite) au niveau des stations de
bases (BTS). Cette solution sera, par la suite, appele approche avec bufferisation .
Lvaluation des performances de ces approches est ralise par simulation.
Dans ce chapitre, nous prsentons l'interface Abis telle qu'elle est spcifie dans le cas
GSM, puis nous proposons deux approches dynamiques qui permettent de faire voluer
cette interface. Nous tablissons ensuite un modle thorique permettant d'analyser le
trafic engendr par des utilisateurs utilisant un nombre de ressource diffrent sur les
interfaces Air et Abis. Nous prsentons galement un modle pour l'analyse d'changes
temps rel sur un rseau GPRS. Enfin, aprs avoir prsent notre modle de simulation,
nous comparons diffrentes approches d'interface Abis dynamique et analysons diffrentes configurations qui permettent d'amliorer les performances de transmission.
19
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
2. L'interface Abis
2.1. Architecture de l'interface Abis
Linterface Abis relie les stations de bases (BTS Base Tranceiver Stations) leurs
contrleurs (BSC Base Station Controler). Cette interface, normalise au dbut des annes 90, utilise une liaison MIC comme support de transmission. Elle permet dcouler
la fois de la signalisation et le trafic utilisateur. Il y a gnralement plusieurs BTS
relies chaque BSC et les trames MIC sont souvent partages entre les diffrentes
BTS. La figure 2.1.1 prsente l'architecture de l'interface Abis.
Une trame MIC est une trame TDMA divise en 32 canaux de 64 kbits/s (au niveau
physique) [GSM 08.04]. Dans le systme GSM, plusieurs canaux de trafic sont multiplexs sur un mme slot de la trame MIC [GSM 08.20]. Typiquement, le canal MIC de
64kbits/s est divis en 4 sous canaux (substreams) de 16 kbits/s. La norme [GSM
08.20] indique quil est possible de mettre en place des sous canaux de 8 kbits/s. Par
contre, ce nombre de sous canaux est limit 4. La trame MIC mise en place sur linterface Abis est compose de 128 canaux 16 kbits/s.
Une partie de ces canaux 16kbits/s tant utilise pour le dialogue entre les BTS et le
BSC et pour le transport des informations de contrle qui sont diffuses dans les
cellules, le nombre de canaux utilisables pour transporter le trafic utilisateur est lgrement infrieur. Ce nombre dpend, du nombre de BTS relies au BSC par ce faisceau,
du nombre de porteuses et de circuit de trafic configur dans les cellules, et du nombre
de liaisons MIC mises en place dans le faisceau.
20
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
cit dpend du nombre de slots radio attribus au mobile, du schma de modulation/codage utilis et du nombre de canaux 16kbits/s affects la transmission sur l'Abis.
Cette approche sera appele par la suite approche micro-circuit .
Cette approche rend cependant la politique dallocation des ressources plus complexe et
demande loprateur dtre attentif la manire dont il dimensionne linterface Abis
afin d'viter les engorgements et dcouler un maximum de trafic tout en satisfaisant
aux besoins dun maximum dutilisateurs. De plus, il est sans doute possible damliorer les performances de la transmission en mutualisant lutilisation des ressources de
donnes entre plusieurs BTS.
Une seconde approche consiste scinder la transmission en deux phases : transmission
sur linterface Air puis transmission sur linterface Abis. Cette approche ncessite alors
ladjonction de piles (ou buffers) au niveau des BTS afin de permettre le stockage des
trames en attente de transmission. C'est pourquoi cette approche sera dnomme par la
suite approche avec bufferisation
Cette tude vise comparer les deux stratgies d'allocation dynamique de ressources approche micro-circuit et approche avec bufferisation . Les principaux lments
tudis sont les impacts sur les dlais de transmission et sur les taux de donnes transmises et perdues. Une tude sur la taille des buffers implmenter au niveau des BTS a
galement t mene. Tous ces aspects sont valus par simulation et font l'objet de la
partie 4.
iN a
i =1
n
ii N b
i =1
L'tude des diffrents tats de ce systme de Markov permet de calculer les probabilits
stationnaires et les probabilits de blocage associes.
1 + 2 24
1 + 22 30
Le graphe des tats est reprsent sur la figure 3.2.1.1.
23
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 3.2.1.1. Automate dcrivant les tats du modle 2 classes, 24 slots Air et 30 canaux Abis
25
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Une des limites de ce type de modlisation est qu'elle conduit une augmentation rapide de la taille de l'espace d'tat. L'augmentation du nombre de ressources ou l'augmentation du nombre de classes considres se traduit par une augmentation importante de
la complexit du modle et du temps ncessaire sa rsolution. A titre d'exemple, pour
Na=24 slots et Nb=30 canaux, il faut considrer un graphe comportant 235 tats pour
modliser le systme 2 classes. Pour 4 classes d'utilisateurs, le nombre d'tats s'lve
2683. Cela rend difficile le raffinement du modle afin de prendre en compte des paramtres supplmentaires comme la capacit multislot des mobiles.
26
Si on reprend les mmes paramtres, mais en fournissant 31 canaux sur linterface Abis,
on constate un profil de courbe assez diffrent pour un taux de charge faible des appels
de classe 1. Dans le cas o uniquement 30 canaux sont disponibles (Cf. figure 3.2.3.1),
quand la charge des appels de classe 2 est forte et que la charge des appels de classe 1
est trs faible, il est peu probable qu'un appel de classe 1 trouve des ressources disponibles quand il arrive : sa probabilit de perte est alors un peu plus importante. Dans le
cas o on met en place 31 canaux sur l'interface Abis, seuls 30 slots seront utiliss par
des appels de classe 2, le slot restant ne pourra alors tre utilis que pour couler des appels de classe 1. Le taux de pertes pour de trs faibles charges d'appels de classe 1 est
alors beaucoup plus faible. Choisir un nombre de canaux impair permet donc de favoriser les appels de classe 1 dans le cas du modle deux classes.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
ils ne peuvent pas ouvrir de nouvelles sessions. L'arrive et le dpart des utilisateurs
peuvent donc tre modliss par un automate de type M/M/U/0, comme reprsent sur
la figure 3.3.1.
i!
i=0
; =
Les utilisateurs ayant une session en cours alternent entre des phases d'inactivit pendant lesquelles ils n'utilisent aucune ressource - et des phases d'activit - pendant lesquelles ils utilisent une des R ressources. La phase d'inactivit a une dure qui suit une
loi exponentielle de paramtre , la phase d'activit a une dure qui suit une loi exponentielle de paramtre . Ce type de trafic suit donc un modle de type IPP Interrupted Poisson Process (Cf. Annexe B), comme reprsent sur la figure 3.3.2. Les paquets
ont un taux darrive et la dure moyenne d'mission vaut 1/.
Figure 3.3.2. Profil de trafic d'un utilisateur ayant une session en cours
Le taux d'activit des utilisateurs est alors donn par la formule suivante :
1
1 1
28
29
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Y X U et Y R.
Construction de lautomate
Chaque tat du systme est dcrit par le couple de valeurs (X, Y) qui reprsente le
nombre dutilisateurs ayant une session ouverte et le nombre dutilisateurs ayant des
donnes en cours de transmission. L'espace d'tat est l'ensemble des couples (X, Y) qui
satisfait aux contraintes Y X U et Y R. Larrive et le dpart des utilisateurs sont
dcris par les paramtres et tandis que le trafic utilisateur est dcrit par les paramtres et . La figure 3.3.4 fournit une reprsentation de l'automate correspondant
ce systme.
Le gnrateur infinitsimal associ cet automate permet d'tudier le taux de perte des
utilisateurs et le taux d'appels courts rejets.
30
Si on note X le nombre d'utilisateurs ayant une session en cours et Y le nombre d'utilisateurs, parmi les X, en train de transmettre, on a :
C yx y
P Y = y X = x=
; =
C ix i
i=0
x!
P X =x , Y = y= P x , y= U i R
; = ; =
i ! C ix i
i=0
i=0
La probabilit de perte d'un utilisateur entrant dans le systme est donne par la formule
d'Erlang [Dec04].
U
U!
P perte utilisateur=P X =U = U i
i!
i=0
La probabilit de perte d'un paquet pour cause d'indisponibilit des ressources est donne par la formule :
0 si x R
P perte paquet X = x= xR P x , R si xR
R
xi P x , i
i=0
Soit :
U
P perte paquet =
P perte paquet X = j
j =0
j= R1
jR P j , R
R
ji P j ,i
i=0
31
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 3.3.5. Taux de perte utilisateur et taux de perte paquet (pour diffrents taux d'activit)
La premire courbe, permet de vrifier que le taux de perte des utilisateurs diminue sensiblement ds lors qu'on augmente la capacit d'accueil du systme. Ce taux de perte est
relativement faible. Il y a donc trs peu d'utilisateurs perdus cause de la politique d'admission.
Sur la seconde courbe, on visualise l'augmentation du taux de perte des paquets lorsque
la proportion d'utilisateurs par slot augmente. Avec les paramtres que nous avons
considrs, on constate que lorsque les utilisateurs sont peu actifs - taux d'activit de
10% et 25% - on peut accepter un nombre lev d'utilisateurs dans le systme sans que
cela ait un impact sensible sur le nombre de paquets perdus. Si on se fixe un seuil de tolrance de 1% de pertes paquet, dans le cas d'un taux d'activit de 10%, on peut accepter
jusqu' 8 utilisateurs par ressource, soit 64 utilisateurs. Pour un taux d'activit de 25%,
on peut en accepter 3, soit 24 utilisateurs.
32
Figure 3.3.6. Taux de perte utilisateur et taux de perte paquet (pour diffrents niveaux de charge)
La charge globale utilisateur a ainsi une influence la fois sur le taux de perte des utilisateurs et sur le taux de perte des paquets. La politique d'admission limite le nombre
d'utilisateurs qui entrent dans le systme. Les pertes sont alors rduites. Pour un faible
taux d'utilisateurs admis par ressource, le systme est toujours saturation de sa capacit d'accueil. C'est pourquoi il y a peu de diffrences entre les trois courbes de perte paquets pour un faible nombre d'utilisateur admis. Par contre, quand le systme peut accueillir un plus grand nombre d'utilisateurs, il sature moins frquemment. Le nombre
d'utilisateurs moyen dans le systme est alors d'autant plus grand que la charge est leve. On retrouve cette diffrence au niveau du nombre de paquets perdus. Pour des
charges de 30 et 40 Erlangs, on constate d'ailleurs qu'au del de 8 utilisateurs par ressource, le taux de perte des utilisateurs est ngligeable. Tous les utilisateurs qui se prsentent l'entre du systme sont servis et le taux de perte des paquets est stable.
33
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 3.3.7. Evolution du taux de perte des utilisateurs en fonction de la charge du systme
Le taux de perte des paquets, reprsent sur la figure 3.3.8, dpend la fois de la charge
dappels et de la charge utilisateur du systme. En effet, plus il y a dutilisateurs qui
souhaitent entrer dans le systme, plus le nombre moyen dutilisateurs dans le systme
est lev.
Grce ces courbes, on peut visualiser les zones tolrables en termes d'chec d'tablissement de sessions et en termes de pertes de paquets pour diffrentes charges.
34
35
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Dans ces simulations, nous considrerons des interfaces Abis comportant trois types de
ressources : voix, data et mixtes. Diffrentes rpartitions de ces ressources sont tudies.
Nous comparons par ailleurs les performances du cas o chaque BTS possde son
propre ensemble de ressource sur l'Abis et du cas o les ressources de l'Abis sont partages entre plusieurs BTS.
Pour le transport de donnes sur l'interface Air, nous avons considr un taux d'erreur
bloc de 0.1% aprs codage.
Tous ces paramtres sont rcapituls dans le tableau 4.1.1.1 :
Paramtres
Valeur
Nombre de BTS
10
17
4096 bits
0,1%
36
Paramtres
Valeur
2 min
5 min
Paramtres
Valeurs
Capacit multislot
des mobiles
4+1
Schmas de
codage utiliss
Proportion Schma
Dbit
50% MCS-2
13 kbits/s
30% MCS-4
19,4 kbits/s
37
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Paramtres de trafic
Loi
Valeur Moyenne
MCS-2
MCS-7
Exponentielle
60 sec
60 sec
60 sec
Gomtrique
5 sec
5 sec
5 sec
Gomtrique
25
25
25
Gomtrique
0,1 sec
0,0625 sec
0,0246 sec
Pareto Cut-Off
=1,1
=1,1
=1,1
k=81,5
k=81,5
k=81,5
m=66 666
m=66 666
m=66 666
38
MCS-4
Abis ddie
Approche micro-circuit
Abis partage
Configuration 1 Configuration 2
La figure 4.2.1.1 prsente le taux de transmission des paquets IP (LLC-PDU) pour les 4
configurations et la figure 4.2.1.2 prsente leur temps moyen de transmission. Les
pertes sont dues l'expiration de la date de validit des paquets IP.
39
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
On constate tout d'abord que les configurations dont les ressources sur l'interface Abis
sont partages entre toutes les BTS prsentent de meilleures performances par rapport
aux configurations o chaque BTS possde son propre ensemble de ressources ddies.
Ce rsultat s'explique assez simplement. Dans le cas o chaque BTS possde son propre
ensemble de ressources, si l'une des BTS, un instant donn, n'utilise pas toutes ses ressources, celles-ci ne peuvent tre utilises par d'autres BTS. Dans le cas o les ressources sont partages, les ressources auxquelles une BTS a droit et qu'elle n'utilise pas
peuvent tre utilises par d'autres BTS qui ont des besoins plus importants. Ce partage
de ressources a donc pour effet d'augmenter le nombre moyen de ressources utilises sur
l'interface Abis.
40
On constate galement qu' trs forte charge (plus de 10 contextes PDP actifs dans une
cellule), le bnfice du partage est trs faible. En effet, dans ce cas, chaque BTS utilise
quasiment chaque instant sa part de ressources : il n'y a presque plus de ressources inutilises redistribues d'autres BTS.
Le partage des ressources de l'interface Abis trs forte charge n'apporte qu'un trs
faible gain de performances. Il faut cependant noter que ce type de charge ne correspond pas aux configurations d'un rseau oprationnel. Un oprateur qui aurait besoin
d'couler autant de trafic devra donc ncessairement augmenter en consquence le
nombre de ressources data disponibles dans les cellules.
Si on compare les stratgies avec ou sans mise en place de piles au niveau des BTS, on
peut constater que la stratgie avec bufferisation est meilleure, en terme de taux de
transmission, que la stratgie micro-circuit (sans buffer). Nanmoins, pour des
charges moyennes (moins de 5 contextes PDP actifs dans la cellule), le gain en terme de
taux de transmission de la stratgie avec bufferisation n'est pas trs significatif. Dans
les simulations ralises dans [Dai05], avec 100% de mobiles MCS4, la stratgie sans
bufferisation se rvle mme lgrement meilleure. A forte charge, la stratgie avec
bufferisation est bien meilleure en terme de taux de transmission, mais ce gain de performance se traduit par une forte augmentation des dlais de transmission. Cette stratgie n'est donc pas adapte pour des trafics temps rel.
41
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
On constate alors que les stratgies avec bufferisation sont toujours plus performantes
en terme de taux de transmission que les stratgies micro-circuit . En terme de temps
de transmission la stratgie avec bufferisation n'est plus aussi pnalisante que dans le
cas o les capacits de transmission de l'interface Abis n'avaient pas t augments (Cf.
4.2.1). A forte charge, la stratgie avec bufferisation gnre toujours des temps de
transmission importants. A charge oprationnelle, le temps de transmission de cette stratgie se rvle lgrement meilleur que le temps de transmission de l'approche sans bufferisation.
42
On peut galement constater que le gain de performance induit par le partage des ressources de l'interface Abis entre toutes les BTS est trs faible. Le gain de performance
obtenu par l'augmentation de la proportion de ressources premptables sur l'interface
Abis est donc prdominant par rapport au gain de transmission apport par la mutualisation des ressources.
43
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
On constate que pour de telles charges, la stratgie avec bufferisation est toujours
meilleure que la stratgie sans bufferisation . Dans le cas de la stratgie avec bufferisation , augmenter le nombre de ressources sur l'interface Abis n'augmente que trs
faiblement les performances moyennes de la transmission. Ainsi, le gain de performance lorsque l'on augmente la part de ressources premptables est insensible. Cela
s'explique par le fait que globalement les ressources de l'interface Abis sont sous utilises. Par consquent, mme sans augmenter le nombre de ressources alloues au transport de donnes, il y a gnralement suffisamment de ressources sur l'interface Abis
pour couler le trafic.
pendant plus intressante sur un plan conomique puisqu'elle ne ncessite pas d'augmenter le nombre de ressources sur l'interface Abis : l'oprateur n'est donc pas oblig de
dployer de nouvelles trames MIC.
45
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
46
Dans un premier temps, pour un nombre de canaux sur l'interface Abis compris entre 0
et 30, l'interface Abis n'est pas capable d'couler le trafic en provenance de la BTS. Tout
le trafic qui arrive au niveau des BTS est coul par les interfaces radio. La taille
moyenne des piles n'augmente que trs progressivement.
47
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Comme on peut le constater sur les figures 4.5.2 et 4.5.3, il n'est pas utile d'augmenter
normment les capacits des piles de transmission. Les performances des interfaces
4096 et 6144 bits sont trs proches. La taille de la pile implmenter dpend donc essentiellement du trafic que les interfaces Air et Abis sont capables d'couler. Le stockage permet de rguler la transmission (et donc de faire face aux ventuelles variations
de disponibilit des ressources) mais il est inutile de stocker des blocs qui ne pourront
tre transmis qu'au bout d'une trop longue priode de temps. Plus que la taille des buffers, c'est l'quilibre entre les capacits de transmission des interfaces Air et Abis qui va
permettre d'assurer les meilleures performances de transmission. Cet quilibre n'est pas
facile valuer puisqu'il dpend des caractristiques des mobiles qui sont en cours de
communication dans le rseau (classe multislot et surtout schma de codage utilis).
48
5. Conclusions
La technologie E-GPRS a t normalise afin de permettre l'augmentation des capacits
de transmission de donnes des terminaux mobiles GSM/GPRS. Cette technologie
ncessite de modifier l'interface Abis afin de supporter des dbits variables et suprieurs
16 kbits/s.
Ce chapitre propose deux mcanismes d'allocation dynamique de ressources sur l'interface Abis. Ces mcanismes visent rutiliser les interfaces du rseau d'accs existantes
en prservant leur structure sous forme de trame MIC.
Les tudes thoriques qui ont t menes fournissent une analyse succincte du type de
trafic engendr par les utilisateurs et soulignent quelques aspects prendre en compte
pour l'tude de l'interface Abis : profil des utilisateurs (classe multislot et schma de
modulation/codage utiliss), allocation conjointe de ressources sur les interfaces Air et
Abis...
Le modle de rseau d'accs GSM/GPRS qui a t implmente dans notre simulateur
est ensuite prsent. Nous dtaillons les principaux paramtres pris en compte ainsi que
le scnario de simulation qui nous sert de rfrence. Plusieurs types de configuration
sont ainsi examins en comparaison de ce modle de rfrence.
Cette tude a permis d'analyser les performances des deux approches d'interface Abis
que nous avons proposes. Nous avons mis en vidence diffrents paramtres de configuration qui permettent d'amliorer les performances de transmission.
Un oprateur qui souhaiterait mettre en place une interface Abis dynamique a intrt
augmenter les capacits de transmission de la liaison en mutualisant les ressources
disponibles entre plusieurs stations de base. Il peut galement amliorer les capacits de
transmission de l'interface Abis en augmentant le nombre de ressources disponibles
pour la transmission de donnes. Cela peut se faire en augmentant le nombre de ressources de donnes ddies ou le nombre de ressources mixtes (ressources vocales qui,
inutilises, peuvent servir transporter des donnes). Dans le cas o l'oprateur augmente les capacits de transmission de l'interface Abis, il peut se rvler intressant d'amliorer l'utilisation des ressources en dissociant la transmission sur l'interface Air de la
transmission sur l'interface Abis. Cela ncessite cependant l'adjonction de piles de transmission au niveau des stations de base. La bonne valuation de la taille des piles
mettre en place est alors un point critique afin d'viter un engorgement de l'interface Air
ou de l'Abis.
Cette tude avait pour objectif de permettre un oprateur de dterminer la meilleure
stratgie pour mettre en place une interface Abis dynamique et dployer la technologie
E-GPRS sur son rseau.
49
1. Introduction
Les systmes radio-mobiles ont t conus pour assurer l'itinrance des utilisateurs sur
un territoire dimension nationale voire internationale. Avec les systmes de tlphonie
de seconde gnration, les utilisateurs ont, par ailleurs, t habitus bnficier d'un
service de mobilit leur permettant de changer de cellule en cours de communication
sans subir d'interruption. Le dveloppement des technologies pour la transmission de
donnes ncessite de concevoir des mcanismes de transferts inter-cellulaires qui
permettent d'assurer la continuit des transmissions, tout en satisfaisant diffrentes
contraintes de qualit de service.
Deux mcanismes permettent d'effectuer le transfert inter-cellulaire : la reslection
dans laquelle le mobile prend une part active au mcanisme de basculement et le handover dans laquelle le rseau dirige l'ensemble du processus. Les performances de ces
deux approches et de leurs variantes dpendent fortement de la pile protocolaire et
des mcanismes de transmission et de fiabilisation mis en place. Le but de cette partie
est de prsenter les mcanismes de segmentation, rassemblage et de fiabilisation qui
interviennent au niveau du rseau d'accs GPRS (protocoles RLC et LLC) et de fournir
une synthse sur les rcentes volutions de la normalisation des procdures de handover. Nous nous attachons particulirement analyser l'impact du transfert inter-cellulaire sur la transmission et tudier les modifications qui peuvent tre apportes afin
d'en amliorer les performances. Nous proposons en particulier un mcanisme qui
permet de limiter les pertes de donnes au niveau des couches basses. Ce mcanisme
consiste prserver les tats de transmission aux niveau RLC et LLC au moment du
basculement. Les performances des mcanismes de basculement que nous tudions sont
valus par simulation.
Cette partie dbute par une prsentation rapide des diffrentes approches pour le transfert inter-cellulaire dans un rseau radio-mobile. Une classification de diffrents trafics
en fonction de leurs contraintes de qualit de service est galement ralise. Nous prsentons ensuite les mcanismes de fiabilisation des donnes dans le rseau GPRS, et les
interactions qui peuvent rsulter de leur activation. Nous poursuivons par une description dtaille des diffrentes approches de reslection et de handover. Nous prsentons
finalement notre modle de simulation avant d'introduire nos rsultats et nos conclusions.
51
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
2. Dfinitions
2.1. Transfert inter-cellulaire l'initiative du mobile ou contrl par le rseau
Dans un systme radiomobile [Lag00], les utilisateurs se dplacent librement sur un territoire donn. Pour assurer la continuit du service, l'oprateur rpartit donc des stations
de base sur le territoire couvrir. Au cours de son dplacement, un abonn va passer
sous la couverture de diffrentes stations de bases. Lorsque le mobile est en veille
c'est dire qu'il n'y a pas d'appels tlphoniques ou de session de transfert en cours le
changement de cellule n'a aucun impact pour l'utilisateur. Seul un change ponctuel peut
avoir lieu entre le mobile et le rseau pour maintenir la localisation du mobile et assurer
la fonction d'itinrance. Lorsque l'utilisateur est actif c'est dire qu'il est en cours de
communication tlphonique ou en cours de transfert de donnes le changement de
cellule ncessite le r-tablissement de la transmission dans la nouvelle cellule. Cette
procdure est appele transfert intercellulaire, soit en anglais Handover ou Handoff.
La dcision de changement de cellule peut tre l'initiative du mobile elle est alors
appele reslection - ou tre commande par le rseau. Pour prendre la dcision du
changement de cellule et choisir la cellule cible, le rseau doit avoir des informations
sur la faon dont le mobile peroit son environnement radio. Pour ce faire, il est ncessaire de maintenir une connexion avec le mobile afin d'changer des informations de
contrle et notamment des rapports de mesures - qui vont permettre la prise de dcision. C'est pourquoi le changement de cellule l'initiative du rseau n'a lieu, dans la
plupart des systmes, que lorsque le mobile est en communication.
La reslection de cellule, contrle par le mobile, a l'avantage d'tre plus simple
mettre en oeuvre [Zha03]. Elle ne ncessite pas de systme de contrle complexe au niveau du rseau coeur. Ce type d'approche est souvent utilis dans le cas des handovers
inter-systmes, et plus particulirement quand les deux systmes ne sont pas contrls
par le mme oprateur.
Le processus de handover, entirement contrl par le rseau, est plus compliqu
mettre en oeuvre. Il offre cependant l'oprateur la possibilit de contrler plus finement le fonctionnement de son rseau et le service fourni l'utilisateur. Le rseau peut
prparer le handover en rservant des ressources pour accueillir le mobile dans la cellule
cible. Le rseau peut galement commencer rediriger les donnes vers la cellule cible,
ce qui permet de rduire les temps de coupure. Par ailleurs, ce type de handover permet
au rseau de commander le changement de cellule pour des raisons d'administration :
contrle de la charge du rseau, rpartition des utilisateurs dans les diffrentes cellules
en fonction des services demands...
52
Figure 2.2.1. Classification de diffrents services en fonction de leur sensibilit aux erreurs
et aux dlais (d'aprs [3GPP 22.105])
Les services de tlphonie et de visiophonie sont assez tolrants en terme de pertes car
l'utilisateur final ne peroit pas forcment l'effet de la perte de quelques chantillons de
parole ou d'image. S'il peut percevoir une dgradation de son service ou des micro-coupures, celles-ci sont suffisamment faibles pour qu'il puisse continuer bnficier de son
service. Par contre, les services de tlphonie requirent des dlais de transmission assez
courts et des dbits rguliers afin que la communication soit perue comme tant simultane. L'ITU [ITU-G.114] recommande des dlais de transmission infrieur 150ms
pour une bonne qualit de communication; et infrieur 400ms pour une qualit acceptable. Ce service, requiert donc un handover pour lequel le temps de coupure de la trans53
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
54
La couche MAC [3GPP 44.060] permet de grer le partage des ressources de l'interface
radio entre les diffrents utilisateurs GPRS d'une cellule.
La couche RLC [3GPP 44.060] offre un service de fiabilisation de la transmission sur
l'interface radio (entre le mobile et le BSC). C'est aussi cette couche qui s'occupe de la
segmentation et du rassemblage des trames LLC. La taille des blocs dpend du schma
de codage utilis par le mobile et le rseau. Cette couche peut tre utilise en mode
acquitt ou non.
La couche LLC [3GPP 44.064] offre un service de fiabilisation de la transmission au
sein du rseau d'accs (entre le mobile et le SGSN). Cette couche n'offre aucun service
de segmentation. La taille maximale d'un LLC-SDU est de 1520 octets.
La couche SNDCP [3GPP 44.065] offre un service de multiplexage des diffrents protocoles de communication qu'elle dessert, un service de compression et dcompression et
un service de segmentation et rassemblage des PDP-PDU en LLC-PDU. C'est cette
couche qui assure que les LLC-PDU ne dpasseront pas la taille de 1520 octets,
quelque-soit le protocole utilis dans le rseau auquel l'utilisateur se connecte.
Initialement, le systme GPRS a t conu pour assurer un service d'accs diffrents
types de rseaux de donnes en mode paquet (IP, ATM, X25...). Ce rseau de donnes
porte le nom gnrique PDN Packet Data Network et le protocole qu'il implmente
est le protocole PDP Packet Data Protocol. La figure 3.1.1 ne reprend que la couche
IP [RFC 791] qui est actuellement le protocole utilis pour l'interconnexion avec le rseau Internet. Cette couche IP peut tre associe plusieurs protocoles de transmission,
gnralement UDP [RFC 768] ou TCP [RFC 793] (comme reprsent sur la figure).
55
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
56
La norme distingue les data blocs, qui sont le rsultat de la segmentation des trames
LLC et les radio blocs, qui sont les blocs de donnes qui sont rellement transmis sur
l'interface radio. Un radio bloc est constitu d'un entte suivi par un ou deux data blocs.
Channel
Coding
Scheme
bits
CS-1
22
176
CS-2
32
256
CS-3
38
304
CS-4
52
416
MCS-1
22
176
MCS-2
28
224
MCS-3
37
296
MCS-4
44
352
MCS-5
56
448
MCS-6
74
592
MCS-7
2x56
2x448
MCS-8
2x68
2x544
MCS-9
2x74
2x592
Tableau 3.3.1.1. Taille des donnes transmises dans un bloc RLC (d'aprs [3GPP 45.003])
Les schmas de codage permettent des dbits variants entre 9,05 kbits/s (CS-1 GPRS) et
61,85 bits/s (MCS-9 EGPRS) [3GPP 45.001] . Les schmas de codage CS Coding
Scheme sont utiliss pour GPRS et les MCS Modulation and Coding Scheme - sont
utiliss dans EDGE. La taille du contenu des data blocs RLC transmis varie entre 176 et
572 bits. Le tableau 3.3.1.1 indique la taille des lments de donnes transmis dans
chaque bloc en fonction du schma de codage utilis. Il faut noter que les schmas de
codage MCS-7, 8 et 9 permettent en ralit la transmission de deux blocs de donnes
RLC, soit un maximum de 1284 bits. En cas de retransmission, l'metteur peut choisir
un schma de codage des blocs radio plus contraignant afin d'augmenter la fiabilit de la
transmission (cela peut par exemple tre utilis dans le cas o la qualit de la transmission se dgrade de faon importante).
57
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Ces blocs radio sont ensuite transmis jusqu' la station de base qui va porter la taille des
radio blocs une taille fixe de 456 bits pour des transmissions GMSK (schmas de codage CS et MSC 1 4) et 1392 bits (soit 464 symboles) pour des transmissions 8-PSK
(schma de codage MCS 5 9) [3GPP 45.003]. Ces blocs permettent alors de former les
bursts qui sont transmis sur l'interface radio.
acquittement contient deux indicateurs : un SSN et un RBB. Le SSN - Starting Sequence Number - est le numro du premier bloc de la squence d'acquittement. Le RBB
Received Block Bitmap est un vecteur (ou bitmap) contenant l'tat de rception de
WS blocs de la squence : reu ou non reus.
Evolution des indicateurs d'tat
V(A) et V(S) sont initialiss 0 lors de l'ouverture du TBF. Chaque fois qu'un bloc doit
tre transmis, il est estampill avec V(S), puis V(S) est incrment suivant la formule :
V S V S 1 mod SNS
Au niveau du rcepteur, un bloc qui arrive est considr valide si son BSN est compris
entre V(Q) et V(Q)+WS (au modulo SNS prs). Un bloc non valide est rejet. Si le BSN
du bloc a pour valeur V(Q), V(Q) prend la valeur BSN du plus petit bloc non encore
reu. Si le bloc est valide, il est marqu comme reu au niveau du vecteur V(N). Si son
BSN est suprieur ou gal V(R), V(R) prend pour valeur BSN+1.
V R BSN 1mod SNS
Le rcepteur gnre un acquittement comme suit : Il affecte la valeur de V(R) au SSN et
indique, dans le RBB, l'tat de rception des blocs allant de V(R)-1 V(R)-WS (au modulo SNS prs). Ainsi, l'tat de rception de tous les blocs de la squence sont transmis
l'metteur.
Lorsque l'metteur reoit un acquittement, il considre tous les bits du RBB partir du
SSN. L'metteur vrifie alors que tous les BSN indiqus dans le RBB sont valides, c'est
dire compris dans la fentre d'mission. Soit l'intervalle suivant :
59
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
60
61
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
62
63
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
64
Figure 3.7.2.1. Transmission sans erreur d'un paquet IP, sans fiabilisation au
niveau LLC
Figure 3.7.2.2. Transmission sans erreur d'un paquet IP, avec fiabilisation au
niveau LLC
65
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
La figure 3.7.2.3 prsente la transmission avec perte d'un paquet IP. Au bout d'un temps
RTO, le serveur, n'ayant pas reu d'acquittement, renvoie le paquet sur le rseau.
Figure 3.7.2.3. Transmission avec perte d'un paquet IP, sans mcanisme de
fiabilisation LLC
66
Figure 3.7.2.4. Transmission avec perte d'un paquet IP, avec mcanisme de
fiabilisation LLC (cas favorable)
Figure 3.7.2.5. Transmission avec perte d'un paquet IP, avec mcanisme de
fiabilisation LLC (cas dfavorable)
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
en particulier l'adresse PDP du mobile). L'ouverture du PDP contexte entrane galement la ngociation des paramtres de qualit de service associs au mobile [Dai03].
Les principales informations contenues dans le contexte PDP sont les suivantes :
Ladresse PDP du terminal au sein du rseau (adresse IP sur les rseaux IP)
Le SAPI [3GPP 44.064] permet didentifier au niveau de la couche LLC le type de service qui est utilis. Ce SAPI permet didentifier les couches suprieures la couche 3
qui devront rassembler et traiter les LLC-PDU. Dans le cas o la couche LLC est utilise en mode acquitt, la valeur du SAPI dtermine la valeur du temporisateur de retransmission T201.
Le NSAPI [3GPP 44.065] a pour but de diffrencier au sein du mobile les diffrentes
sessions qui sont actives. Il permet d'identifier le contexte PDP et la couche SNDCP qui
traite les LLC-PDU.
Les paramtres de qualit de service contiennent quand eux les dbits moyens et crtes
affects la communication ainsi que deux indicateurs de priorit : l'un pour la communication de bout en bout (classe de prcdence), et l'autre sur l'interface radio (priorit radio).
Les paramtres de fiabilisation de la transmission indiquent si les mcanismes de retransmission sur l'interface radio (RLC), dans le sous systme radio (LLC) et dans le rseau coeur (GTP) sont actifs ou non.
Les paramtres de qualit de service et de fiabilisation ne sont dfinis qu'entre le mobile
et le GGSN. Ils ne traduisent pas la qualit de la transmission de bout en bout, mais ont
tout de mme un impact important sur la qualit de service.
Lorsque le mobile ou le rseau demandent l'ouverture d'un contexte PDP, ils doivent
prendre en compte des paramtres qu'ils dsirent pour la transmission de bout en bout
pour le choix des paramtres qu'ils demandent dans le contexte PDP.
La procdure d'tablissement du contexte PDP, l'initiative du mobile, est reprise sur la
figure 3.8.1 [3GPP 23.060]. Le mobile demande les paramtres qu'il souhaite associer
au contexte. Si le SGSN ou le GGSN ne sont pas mme de fournir ces paramtres, la
demande de contexte PDP est rejete.
68
69
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
70
Un changement de cellule peut galement tre dcid afin d'obtenir une meilleure qualit de service (en terme de dbit, de temps de latence, de priorit, d'tendue de couverture...). L'utilisateur peut choisir de changer de systme pour des raisons de scurit,
afin d'effectuer des transactions sensibles sur des rseaux auxquels il a confiance. Cela
peut, par exemple, tre le cas d'un utilisateur qui basculerait d'un point d'accs WIFI
un point d'accs UMTS pour effectuer des transactions bancaires. L'utilisateur peut galement basculer afin de bnficier de services offerts non disponibles sur son systme
actuel. Il peut ainsi, par exemple, basculer d'un rseau GSM un rseau UMTS afin de
bnficier du service de visiophonie. Un autre critre important pour l'utilisateur est le
cot de connexion. Un utilisateur peut ainsi demander basculer d'un rseau GSM vers
un point d'accs DECT domestique lorsqu'il arrive son domicile.
Les facteurs qui permettent de juger de la qualit de la transmission sont bass sur des
mesures effectues au niveau de la couche physique : comparaison des niveaux d'mission et de rception des signaux (RXLEV), de la qualit du signal (RXQUAL) et du
taux d'erreur bit (BER). Les couches suprieures peuvent galement tre amenes rinitialiser leurs transmissions si elles constatent des taux d'erreur, des dlais et des retransmissions trop importants. C'est le cas par exemple pour la couche RLC/MAC du
systme GPRS o le TBF doit tre rinitialis quand la fentre de transmission est bloque pendant une priode de temps qui excde le temporisateur T3182 (valeur par dfaut de 5 secondes) [3GPP 44.060].
Conjointement la prise de dcision de handover, le mobile ou le rseau doivent choisir
vers quelle cellule ou systme le mobile va basculer. Les mmes types de critres que
pour la prise de dcision du handover entrent alors en jeu dans le choix de la cellule
cible.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
laisser le mobile prendre lui mme la dcision de basculement : c'est l'approche par reslection.
L'approche par reslection offre une plus grande autonomie au terminal et est plus
simple mettre en oeuvre du point de vue des procdures. Il n'est pas ncessaire de prparer le rseau pour le basculement. Le mobile s'attache une nouvelle cellule, sans
mme prvenir l'ancienne, et demande le rtablissement de la transmission dans la nouvelle cellule.
De faon analogue ce qui est fait dans le systme GSM [Lag00], on peut distinguer
dans le rseau GPRS les transferts inter-cellulaire/intra-BSC, inter-BSC/intra-SGSN et
inter-SGSN. Les solutions adoptes pour raliser le basculement sont sensiblement diffrentes suivant le niveau de basculement considr. Les basculements qui ont lieu au
sein d'un mme rseau d'accs (GERAN ou UTRAN) sans changement de SGSN
mettent en jeu des crations et basculements de contexte au niveau RLC. Les basculements qui impliquent un changement de SGSN ncessitent la reconfiguration de la
transmission dans le rseau coeur. Une procdure, dite de relocalisation [3GPP 29.060],
permet alors de transfrer le tunnel GTP d'un SGSN l'autre. Lorsque le terminal reslectionne un autre rseau, le processus de basculement de la transmission doit se faire
au niveau des protocoles de transport IP. On peut par exemple citer le cas d'un utilisateur ayant un terminal GPRS/WIFI et qui, arriv dans son entreprise, quitterait le rseau
GPRS de son oprateur pour s'attacher au rseau local.
dcision. C'est alors le rseau qui prend la direction des oprations et commande au mobile de changer de cellule. Le rseau est donc systmatiquement mis au courant de la
procdure de basculement. Le choix de la cellule cible peut tre dcid par le mobile ou
par le rseau.
Dans le cas de la reslection commande par le rseau, le mobile peut choisir une ou
plusieurs cellules cibles et les indiquer au rseau, ou laisser totale libert de choix ce
dernier. Si c'est le rseau qui choisit la cellule cible, celle-ci sera indique dans le message de commande. Si, le message de commande de reslection ne comporte pas de
cellule cible, le choix de cette dernire revient au mobile. Une fois la commande envoye, la procdure se droule de la mme manire que dans le cas de la reslection autonome.
La reslection assiste par le rseau vise aider le mobile effectuer la reslection. Le
mobile ne peut choisir la cellule cible que si c'est lui qui prend la dcision de reslection. Il indique alors la cellule cible qu'il a choisie ou une liste de cellules cibles
dans le message qu'il envoie au rseau pour lui signifier sa dcision. Une fois la cellule
cible choisie, le rseau transmet au mobile tout ou partie des informations systme dont
il a besoin pour s'attacher la nouvelle cellule.
Les tableaux prsents dans la partie 4.1.5 rcapitulent les principales caractristiques
de ces trois processus de reselection.
4.1.4. Le handover
Dans le cas du handover, c'est le rseau qui contrle toute la procdure de basculement
de cellule. Une fois que le rseau a pris la dcision de handover, il contacte les quipements chargs du contrle de la cellule cible pour y rserver des ressources en vu de
l'accueil du mobile. Le rseau envoie ensuite une commande de handover au mobile qui
bascule directement sur les ressources qui lui ont t rserves. Il est ainsi possible d'viter la longue phase de rservation de ressources, par le mobile, sur la cellule cible. Le
temps de coupure de la transmission est alors fortement rduit.
En cas de rupture brutale de la connexion avec la cellule d'attachement, seule la procdure de reslection autonome est possible. On peut citer, pour exemple, le cas voqu
dans [Xia04] par le groupe de travail 802.21. Un utilisateur regarde un film sur un ordinateur portable en tant reli un rseau local 802.3. Pour se dplacer, l'utilisateur dbranche le cble qui le relie au rseau ethernet. Pour pouvoir continuer la diffusion du
film, l'ordinateur doit alors effectuer une reslection pour rtablir sa connexion avec un
rseau sans fil de type WLAN.
Le dveloppement des systmes CDMA et des terminaux intgrant plusieurs
metteurs/rcepteurs permet le dveloppement de techniques de soft-handover. Dans ce
type de handover, le rseau commence par tendre la diffusion de la communication
dans la cellule cible. Pendant cette phase, le terminal est alors attach plusieurs
cellules. Ensuite, le rseau stoppe la transmission dans la cellule initiale et le mobile
continue sa communication dans la nouvelle cellule. Ce type de handover permet donc
un transfert inter-cellulaire sans coupure de la communication.
73
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Reslection
autonome
Dcision de
Reslection
Choix
Cellule Cible
Dclenchement
Basculement
Mobile
Mobile
Mobile
aucune
Reslection
commande
Rseau
aucune
Reslection
assiste
Rseau
Rseau
Handover
Rseau
Rseau
Degr d'autoDegr de
nomie du
Contrle du
terminal
rseau
Temps de
coupure
Pertes
Complexit
de la procdure
Reslection
autonome
+++
long
importantes
Reslection
commande
+++
long
importantes
++
Reslection
Assiste
++
++
moyen
moyennes
+++
Handover
+++
court
faibles
+++
74
Release4 et 5
Release 6
Reslection autonome
Obligatoire
Obligatoire
Obligatoire
Reslection commande
Obligatoire
Obligatoire
Obligatoire
Reslection assiste
Non Spcifi
Optionel
Optionel
Handover
Non Spcifi
Non Spcifi
Optionel
75
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
76
77
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
ou par handover).
79
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Arriv dans la nouvelle cellule, le mobile doit demander l'ouverture d'un TBF pour rtablir sa transmission. Il doit galement effectuer une procdure de mise jour de cellule
pour signifier son changement de cellule.
80
Le rseau peut galement envoyer un message PACKET MEASURMENT ORDER , indiquant au mobile qu'il doit basculer dans le mode NC-2. La procdure de
reslection est alors abandonne. C'est le rseau qui reprend le contrle de la transmission et commande ventuellement au mobile de faire un handover.
Si la procdure de reslection est commande par le rseau (mode NC-2), celui-ci peut,
pour assister le mobile, envoyer des informations de configuration des cellules voisines
dans des messages PACKET NEIGHBOUR CELL DATA avant d'envoyer la commande PACKET CELL CHANGE ORDER .
Une fois que le mobile a reu le message PACKET CELL CHANGE CONTINUE ,
le mobile doit reprendre le contrle de la procdure de reslection. S'il lui manque des
informations ncessaires au basculement, il doit les rcuprer en dcodant la voie balise
de la cellule cible. Il peut pour cela suspendre l'coute des canaux de la cellule courante.
Une fois qu'il a obtenu toutes les informations ncessaires la reslection, le mobile
doit cesser immdiatement toutes ses activits dans la cellule courante et basculer vers
la cellule cible. Dans cette dernire, le mobile doit effectuer une procdure pour ouvrir
un TBF afin de rtablir la transmission.
81
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
82
83
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
suspension, il peut attendre que les piles de transmission du BSS soient vides avant de
dclencher le handover. On notera galement que la duplication des trames par le SGSN
n'est pas utile dans le cas o le BSC est capable de maintenir un contexte de transmission unique, au niveau RLC, pour la cellule d'origine et la cellule cible.
A la rception du message , le BSC interrompt les flux uplink dont les trames doivent
tre dlivres en squence. Les flux uplink qui n'ont pas cette contrainte de squencement peuvent tre maintenus. Le BSC envoie ensuite la commande de handover au mobile . Le BSC ayant d, au pralable, transmettre au mobile les informations de configuration de la cellule cible qui sont ncessaires l'excution du handover (Cf. 4.4.1). Le
BSC peut ensuite continuer sa transmission jusqu' ce qu'il n'ai plus de trames LLC
transmettre.
A la rception de la commande de handover , le mobile doit stopper toutes ses activits dans la cellule courante. Cependant d'aprs la norme [3GPP 44.060], le mobile peut
quand mme avoir acquitter le message de handover avant de procder au basculement, ce n'est donc que lorsque ce message a t acquitt que le mobile peut rellement
cesser toute activit dans la cellule courante.
Suivant la classe de qualit de service associe au flux de donnes, le mobile peut alors
stocker ou supprimer les donnes qui deviennent ligibles la transmission (la suppression pouvant se rvler ncessaire pour assurer certains trafics temps rels). A noter ici
que suivant le contenu de la commande de handover, les tats de transmission au niveau
RLC devront tre prservs : il serait alors peu cohrent de prserver ces tats tout en
supprimant volontairement des donnes par ailleurs.
85
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le mobile bascule ensuite vers la cellule et les ressources qui lui ont t attribues dans
la cellule cible (ces ressources sont indiques dans le message de handover). Le mobile
envoie ensuite un message d'accs au canal qui permet au rseau de dtecter l'arrive du
mobile dans la nouvelle cellule . Ce message correspond en ralit 4 burst d'accs.
Le rseau envoie ensuite au mobile les informations d'avance en temps qui vont lui
permettre de se synchroniser avec le rseau .
Il faut noter que les phases et ne sont pas ncessaires si les cellules sources et
cibles sont synchronises entre elles. Dans ce cas, les informations de synchronisation
avec la nouvelle cellule sont transmises dans la commande de handover.
Aprs s'tre synchronis avec le rseau, le mobile peut rtablir les transmissions pour
lesquels des TBF ont t rservs. Il doit galement mettre jour sa localisation
(mise jour de cellule ou de zone de routage). A la rception, dans la nouvelle cellule,
des premiers blocs RLC/MAC correct, le BSC indique l'achvement du handover au
SGSN .
Version optimise du handover pour le cas intra-BSC / intra RA
L'implmentation de cette version optimise du handover intra BSS (Figure 4.4.3.3) est
optionnelle. Elle ne peut s'appliquer qu'au cas o le mobile ne change ni de BSC, ni de
zone de routage. Elle conduit une simplification du dialogue entre le BSC et le SGSN
qui n'est prvenu du changement de cellule qu'une fois le handover ralis.
86
87
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
88
Le SGSN indique au BSC source que le BSC cible est prt accueillir le mobile. Il
transmet pour cela un message PS Handover Required Acknowledge qui contient le
descriptif du contexte associ au mobile dans le BSC cible (le Target BSS to Source
BSS Transparent Container ) . La procdure suit ensuite les mmes principes que
ceux du handover intra-BSS (Cf. 4.4.3).
89
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le package mobilite contient les diffrents modles de mobilit qui sont utiliss
pour calculer les dplacements des mobiles. Le package transmission permet de
fournir les modles d'erreurs qui pourront tre utiliss sur le canal radio ou sur les diffrentes interfaces.
Le package evenements permet de grer la pile des vnements dclenchs dans le
simulateur. Le package aleatoire est utilis pour gnrer des variables alatoires.
Le package gui permet de fournir une interface graphique minimaliste pour le simulateur (plan du rseau et bouton de mise en pause). Le package sonde est utilis pour
le calcul et la rcupration des statistiques de la simulation.
Enfin, le package topologies contient les diffrentes configurations de rseau que
l'utilisateur du simulateur peut utiliser ou construire. Le coeur du simulateur est gr par
la classe Noyau qui permet de lancer les simulations.
90
Les diffrentes interfaces du rseau coeur (NSS) ont t modlises par des liaisons sans
contraintes de capacit. La dure de transmission sur chacune des interfaces doit tre dfinie au moment de la cration de la topologie du rseau. Le temps d'mission des donnes dpend du dbit sur l'interface.
L'interface Abis et l'interface Air ont t modlises comme dans le chapitre I, suivant
l'approche d'interface Abis dynamique avec bufferisation . A cet effet, un buffer de
20 blocs RLC montants et 20 blocs RLC descendant a t mis en place au niveau des
stations de base. Le nombre de canaux 16kbits sur l'interface Abis et le nombre de
slots sur l'interface Air doivent tre dfinis au moment de la cration de la topologie du
rseau.
L'interface Air WIFI a t modlise comme tant une interface haut dbit qui
permet la transmission d'une trame LLC chaque milliseconde.
91
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
92
Les couches UDP/IP et TCP/IP effectuent la segmentation en trames des donnes qui
proviennent de la couche application. La couche UDP permet un transport de donnes
non fiabilis travers le rseau tandis que TCP assure le transport des donnes en mode
acquitt.
Dans la ralit, UDP ne fait pas de segmentation. En GPRS, c'est la couche de convergence SNDCP [3GPP 44.065] qui segmente les paquets IP qui font plus de 1520 octets
(Cf. 3.1).
Un modle simplifi de la couche TCP a t implment. Seul le mcanisme de slow
start a t implment. La taille de la fentre d'mission est initialise 2 trames
TCP. Chaque fois qu'une trame non duplique est acquitte, on incrmente de 1 la
taille de la fentre d'mission. Lorsque qu'un temporisateur de retransmission associ
un paquet expire, la taille de la fentre de retransmission est rinitialise.
Le temps avant r-mission d'une trame non acquitt est appel RTO Retransmission
Time Out. Il est calcul en fonction du RTT - Round Trip Time - qui est le temps coul entre l'mission d'un segment et son acquittement. Le paramtre SRTT - Smooth RTT
- permet d'obtenir une valeur lisse du RTT. Il est recalcul, chaque acquittement reu,
suivant la formule [RFC 793] :
SRTT =SRTT 1RTT
avec un facteur de lissage que nous avons fix 0,8. Le RTO est alors calcul suivant
la formule suivante :
RTO=min RTO max , max RTO min , SRTT
Nous avons fix la valeur du RTOmin une seconde et celle du, RTOmax 60 secondes.
Le facteur permet de prendre en compte la variance du dlai de transmission. Nous
avons fix sa valeur 1,3.
La couche application est charge de gnrer du trafic. Dans notre modle, elle gre
les diffrents gnrateurs de donnes qui sont associs au mobile. Le type de trafic gnr est dfini au moment du paramtrage de la simulation.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
94
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
demande l'attachement la cellule n2 . La station de base relaie alors le message jusqu'au BSC .
Ce dernier dtermine alors si la cellule d'origine du mobile est sous son contrle. Si c'est
le cas, le basculement est intra-BSC. Le BSC enregistre alors la nouvelle localisation du
mobile, envoie un message d'acquittement de mise jour de localisation et bascule la
transmission vers la nouvelle cellule . La station de base relaie alors le message vers
la station de base n2 . A la rception de l'acquittement, le mobile rtablit la transmission montante . La transmission est alors totalement rtablie.
96
97
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
98
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
mme BSC ou des BSC diffrents suivant le type de handover tudi (intra ou interBSC). Le dlai de propagation des donnes entre les diffrents quipements est donn
dans le tableau 5.5.1.1. A ce temps de transfert, il faut ajouter le temps d'mission des
donnes. Celui ci dpend du dbit des diffrentes interfaces (lui aussi rappel dans le tableau 5.5.1.1).
Interface
Temps Transfert
Dbit
Serveur GGSN
50 ms
500 kbits/s
GGSN SGSN
75 ms
500 kbits/s
100 ms
500 kbits/s
100 ms
300 kbits/s
Tableau 5.5.1.1. Temps de transfert des donnes sur les diffrentes interfaces
La trajectoire du mobile au cours de la simulation suit la schmatique dcrite sur la figure 5.5.1.1.
Le mobile commence par s'inscrire dans la cellule A en effectuant une procdure d'attachement . Le mobile se dplace alors vers la seconde cellule. A la frontire des deux
cellules , le transfert inter-cellulaire est dcid et la procdure de basculement dbute.
Au point , la procdure de basculement est termine, la communication est rtablie. A
l'tape , le mobile et le serveur cessent de gnrer du trafic, le mobile continu alors de
transmettre les donnes restantes. A l'tape , le mobile quitte le rseau aprs avoir effectu une procdure de dtachement.
Typiquement, dans le rseau considr, le mobile reste entre 60 et 90 secondes dans la
cellule A puis bascule dans la cellule B. Le gnrateur stoppe alors au bout de 1 minute
et 30 secondes. Le mobile se dtache ensuite au bout de 5 minutes (sauf s'il n'a pas totalement termin la transmission de ses donnes).
La premire cellule GPRS est configure avec 4 slots ddis au trafic de donnes GPRS
et la seconde avec 6 slots. L'interface Abis possde 10 canaux 16 kbits. Chaque BTS
possde un buffer dont la capacit est de 20 blocs RLC en voie montante, et autant en
voie descendante.
100
Type de Donnes
Taille de l'en-tte
40 bits
Trame S-LLC
Taille paquet IP
40 bits
Trame R-LLC
40 bits
Bloc RLC
40 bits
La taille maximale du champ de donnes utile d'un bloc RLC est calcule suivant la formule :
Taille Bloc RLC=
La taille des trames d'acquittement est gale la taille de leurs en-ttes. La taille des
messages de contrles (qui sont utiliss dans le cadre des diffrentes procdures) dpend
de l'interface sur lequel il est transmis : 120 bits sur l'interface Radio/Abis, 300 bits sur
l'interface Gb (entre le BSC et le GGSN), 800 bits sur l'interface Gn et dans le rseau
101
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
102
Paramtres
Loi
Valeurs
Exponentielle
Non prcis
Gomtrique
Valeur moyenne = 5
Gomtrique
Gomtrique
Valeur Moyenne = 25
Gomtrique
Pareto Cut-Off
K=81,5 ;
=1,1 ;
m=66 666 octets
N oS
N o1T o
N p NoS
N p 1T pN p N o1T o
Dc est la valeur fournie dans la norme. C'est le dbit instantan au moment du chargement. Cependant, le trafic Ds engendr par le mobile est bien moindre. Pour obtenir des
charges de trafic plus ralistes, il faut absolument rduire le temps de consultation d'une
page. En effet, il est peu probable que quelqu'un mette 412 secondes pour analyser une
page HTML, qui plus est une page WAP.
Gnrateur de trafic Persistant
Le gnrateur de trafic Persistant vise modliser un transfert important de donnes,
sans contrainte de temps rel, comme cela peut tre le cas lorsque l'on fait du trafic de
type FTP. On considre ici une couche application qui a toujours un ensemble de donnes (ou objet) transmettre. La taille des objets considrs suit une loi de Pareto tronque de mmes paramtres que pour le trafic HTTP (K=81,5, =1,1, m=66 666 octets).
Cette couche n'entrane pas d'engorgement de la couche application puisque les donnes
sont gnres au fur et mesure de leur transmission.
103
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Les rsultats des simulations sont fournis pour les sens montant (uplink) et descendant
(downlink). Ils dpendent de la dure de basculement.
Analyse des temps de basculement et de la dure des procdures
Les figures 6.1.1 prsentent la dure de la procdure de transfert inter-cellulaire. La premire figure prsente la dure globale de la procdure. La diffrence de temps entre les
procdures de handover et de reslection est essentiellement due aux 8 secondes ncessaires au mobile pour rcuprer les informations systmes de la cellule cible en cas de
reslection. Cette courbe traduit surtout le temps de coupure de la transmission. Dans la
seconde figure, le temps de basculement et de rcupration des informations systme a
t soustrait. Il ne reste plus alors que le temps d'change de signalisation ncessaire la
ralisation des procdures. On note alors que les procdures de reslection sont beaucoup plus rapides compte tenu du fait qu'elle sont plus simples du point de vue de l'change de signalisation.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Les rsultats pour le sens descendant sont plus significatifs. En cas de handover, le rseau suspend la transmission descendante : aucun bloc RLC n'est alors perdu. Par
contre, en cas de reslection, le rseau ne dtecte pas immdiatement le dpart du mobile. Le rseau continu donc mettre des blocs RLC dans l'attente de recevoir des
acquittements. Quand la couche RLC dtecte un tat de blocage, le temporisateur T3182
(valeur par dfaut de 5 seconde) est dclench. A son expiration, la couche RLC est rinitialise et le compteur N3102 (valeur par dfaut 4) est dcrment. Ce n'est que
lorsque le compteur N3102 atteint 0 que le rseau considre que le mobile n'est plus
dans la cellule [3GPP 44.060]. Dans le cas de notre simulateur, la transmission continue
tant que le mobile n'a pas t dtect dans la nouvelle cellule. Cela peut donc prendre
bien plus de 5 secondes. Le nombre de blocs transmis et perdus est donc plus faible
dans la ralit. Comme nous le verrons par la suite, cela ne porte cependant pas
consquence sur la validit de nos rsultats.
Figure 6.1.2. Nombre de blocs RLC perdus au cours d'un transfert inter-cellulaire (diffrence mis/reus)
Les figures 6.1.3 reprsentent la diffrence entre le nombre de blocs RLC gnrs et le
nombre de blocs RLC correctement transmis. Une trame LLC prise en charge par la
couche RLC est segmente avant transmission. Les blocs gnrs sont alors mis en attente. En cas de changement de cellule, la transmission est interrompue. Si la couche
RLC n'est pas rinitialise, la transmission est reprise dans la cellule cible et aucune
perte n'est dplorer. Par contre, si la couche RLC est rinitialise, les blocs de la fentre de transmission sont perdus ainsi que les blocs segments mais non encore transmis. Dans le sens montant, entre 5 et 6 blocs RLC sont perdus, que l'approche de basculement retenue soit la reslection ou le handover. Dans le sens descendant, seul une dizaine de blocs sont perdus dans le cas du handover et une cinquantaine dans le cas de la
reslection. Si l'on rapproche ces rsultats de la figure 6.1.1, on note que les blocs perdus en cas de reslection sont ceux de la fentre de retransmission (dont la taille est
fixe 64 blocs dans le cas de notre simulateur) ; un peu moins en moyenne car les
couches suprieures n'ont pas forcment suffisamment de donnes transmettre pour
remplir la fentre d'mission. Ce nombre est quasiment indpendant de la dure pendant
laquelle la transmission est interrompue puisqu'il faut moins d'une demi seconde pour
transmettre 64 blocs sur l'interface radio. Les imprcisions de notre modle mises en
106
vidence au niveau de la figure 6.1.1 n'ont donc pas d'impact notable sur le volume rel
des pertes. Dans le cas du handover, il n'y a aucune perte au niveau de la transmission
puisque celle-ci est interrompue avant de procder au basculement. La dizaine de blocs
perdus en moyenne correspond donc aux blocs RLC, issus de trames LLC segmentes,
mais qui n'ont pas encore t transfrs sur l'interface radio. Pour limiter ces pertes, et
dans le cas o les conditions radio le permettent, il serait envisageable d'attendre que la
transmission de ces blocs soit termine avant que le rseau n'envoie l'ordre de handover.
Cette option est voque dans la norme. Elle reste du ressort du constructeur qui doit
grer convenablement la procdure de handover et refuser les demandes d'ouverture de
nouveaux TBF qui peuvent avoir lieu pendant cette priode.
Figure 6.1.3. Nombre de blocs RLC perdus au cours d'un transfert inter-cellulaire (diffrence gnrs/transmis)
En cas de handover, c'est le rseau qui indique si le mobile doit ou non maintenir ses
tats de transmission RLC/MAC. Si ceux-ci doivent tre maintenus, la norme [3GPP
44.060] prcise que les temporisateurs associs la couche RLC doivent continuer de
s'couler pendant la phase de basculement : il faut donc absolument que ce basculement
s'effectue en moins de 5 secondes pour que cette stratgie soit efficace.
En cas de reslection, la norme n'offre pas la possibilit de maintenir les tats
RLC/MAC. Compte tenu de la dure ncessaire au mobile pour rcuprer les informations systme de la cellule cible, il n'est pas envisageable de maintenir les tats
RLC/MAC tout en poursuivant l'coulement des temporisateurs associs. Une solution
possible serait alors de figer les tats RLC/MAC et les temporisateurs associs, le temps
de procder la reslection. Pour cela, il faut que le rseau soit inform du dbut de la
procdure. Cela ne peut tre fait que dans le cas de la reslection assiste par le rseau.
Dans cette procdure, le mobile informe pralablement le rseau de son intention de
procder une reslection et le rseau acquitte cette information en envoyant un message qui dclenche le basculement.
107
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
108
Dans le cas du handover, on devrait avoir la mme diffrenciation entre les deux stratgies avec ou sans rinitialisation que dans le cas de la reslection. Ces diffrences
sont cependant nettement moins marques du fait que peu de blocs sont perdus au cours
du handover. Leur retransmission n'engendre pas un trafic supplmentaire sensible et le
temps de basculement tant trs court, il n'influe pas sur le dlai moyen de transmission
des blocs.
On notera que les temps de transmission obtenus avec le simulateur semblent correspondre aux mesures effectues par Ericsson et voques dans [Hk06]. Dans cet article, le RTT au niveau RLC dans le sous systme radio est d'environ 150ms (temps de
traitement reaction time - par le BSC compris).
109
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 6.1.6. Nombre de trames LLC perdues au cours d'un transfert inter-cellulaire
110
111
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 6.1.9. Temps de transmission des donnes gnres par la couche application
Conclusion
Dans cette partie, nous avons analys diffrentes approches pour la ralisation du basculement intra-BSC. La stratgie de basculement par handover prsente les meilleures performances, que ce soit en terme de temps de coupure que de pertes. Nous avons montr
que le maintien des tats de transmission au niveau RLC permet d'assurer un basculement sans pertes. Cela se paye cependant par une lgre augmentation des dlais de
transmission, une fois la transmission rtablie.
de rcupration des informations systme manquantes a alors un impact sur les performances de la procdure de reslection. Ce temps est directement li la priodicit de
diffusion des informations systme dans la cellule cible.
Pour l'interprtation de ces courbes, un faible temps de rcupration des informations
systme correspond une procdure de reslection assiste par le rseau. Ce dernier
transmet en effet pralablement toutes les informations systme ncessaires au mobile.
Les temps de rcupration plus levs correspondent au cas o le rseau n'a envoy aucune ou une partie seulement - des informations systmes. Le mobile doit alors attendre au pire la priodicit minimale de diffusion de ces informations (7,54s [3GPP
45.002]). Le temps d'attente moyen augmentant avec le nombre de message d'information rcuprer.
Impact sur les pertes de donnes
Les figures 6.2.1 prsentent le nombre de blocs MAC perdus au cours d'une reslection
en fonction du temps ncessaire la rcupration des informations systme. Cette
quantit correspond la diffrence entre le nombre de blocs mis et le nombre de blocs
reus. Dans le sens montant, les pertes prsentent le mme profil, quelque soit le temps
de coupure. Par contre, dans le sens descendant, la quantit de blocs RLC perdus augmente en fonction du temps ncessaire au basculement.
Figure 6.2.1. Nombre de blocs RLC perdus au cours d'une reslection de cellule (diffrence mis/reus)
Les figures 6.2.2 prsentent les pertes de blocs RLC dues au basculement inter-cellulaire (diffrence entre les blocs gnrs et ceux rellement transmis). On se rend compte
ici que ces pertes sont quasiment indpendantes de la dure de basculement. Dans les
deux cas, on perd les blocs contenus dans la fentre d'mission et ceux, issus de la segmentation des trames LLC, qui n'ont pas t transmis. A noter tout de mme une lgre
augmentation du nombre de blocs perdus en voie descendante. En effet, si la fentre
d'mission n'est pas bloque et qu'une nouvelle trame LLC arrive pendant la phase de
basculement, celle-ci sera alors segmente et donc perdue.
113
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 6.2.2. Nombre de blocs RLC perdus au cours d'une reslection de cellule (diffrence gnrs/transmis)
De ces rsultats dcoulent les figures 6.2.3 qui prsentent une lgre croissance au niveau LLC des trames perdues pour le sens montant.
Figure 6.2.3. Nombre de trames LLC perdus au cours d'une reslection de cellule
Les dlais de transmission au niveau applicatif, prsents sur les figures 6.2.5, ne
permettent pas de mettre en vidence une diffrence majeure entre les deux stratgies
(avec ou sans rinitialisation de la couche RLC). Les pertes engendres par la rinitialisation des tats de transmission au niveau RLC devant tre corriges par la couche TCP.
Par contre, on observe une nette augmentation du temps moyen de transmission des objets gnrs par la couche application.
A noter que dans tous les cas, ces temps sont suprieurs ceux obtenus avec un basculement par handover (comme tudi sur la figure 6.1.9).
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Conclusions
Cette partie a permis d'analyser l'influence du temps de coupure sur la procdure de reslection. Cela permet de mesurer les bnfices apports par la procdure de reslection
assiste. Cette procdure devrait conduire rduire les temps ncessaires la rcupration des informations systme au moment de la reslection. La rduction du temps de
coupure a une influence sensible sur tous les critres d'valuation de la procdure :
pertes, dlais et dbits.
ressources attribu aux communications GPRS tant diffrents, il n'est pas possible de
comparer de manire rigoureuse les performances de la reslection intra et inter-BSC.
Dure des procdures
Les figures 6.3.1 et 6.3.2 montrent la dure de la procdure de transfert intercellulaire,
entre le moment o le transfert est dcid et le moment o la communication est rtablie. Sur ces courbes, on constate que les procdures de transfert inter-BSC sont plus
longues que les procdures de transfert intra-BSC. La diffrence est d'autant plus visible
sur la figure 6.3.2 qui traduit le temps ncessaire l'change de la signalisation (sans
prendre en compte le temps de basculement).
117
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 6.3.3. Nombre de blocs RLC perdus au cours d'un transfert inter-BSC (diffrence mis/reus)
Les figures 6.3.4 reprsentent les pertes au niveau RLC : diffrence entre le nombre de
blocs RLC gnrs et le nombre de blocs RLC transmis. L encore, la diffrence entre
les basculements intra et inter-BSC est trs faible. Dans les deux cas, c'est la totalit de
la fentre d'mission qui est perdue. Dans le cas de la reslection, dans le sens descendant, plus de blocs sont perdus. Le temps que le mobile effectue le basculement et que
le rseau se reconfigure, plus de trames LLC parviennent au BSC et sont segmentes
pour tre transmises. Dans le cas du handover, le rseau se reconfigure avant le dclenchement du basculement. Les pertes au niveau RLC se limitent alors aux seuls blocs
non encore transmis.
118
Figure 6.3.4. Nombre de blocs RLC perdus au cours d'un transfert inter-BSC (diffrence gnrs/transmis)
Figure 6.3.5. Nombre de trames LLC perdus au cours d'un transfert inter-BSC
Les figures 6.3.5 prsentent le nombre de trames LLC perdues au cours d'un transfert
inter-cellulaire. Ces figures permettent de constater la diffrence en terme de pertes
entre un handover intra et un handover inter-BSC. Dans le sens montant, la diffrence
n'est pas trs sensible. Seules les trames LLC segmentes sont perdues au moment de la
rinitialisation de la couche RLC. Dans le sens descendant, par contre, la diffrence est
beaucoup plus sensible. Dans le cas du handover intra BSC, seules les trames LLC segmentes, mais non transmises, sont perdues. Les trames parvenues au BSC qui n'ont pas
t segmentes sont transmises au moment du rtablissement de la transmission. Dans le
cas du basculement inter-BSC, toutes les trames LLC parvenues au BSC - ou qui y parviennent aprs le dclenchement du basculement - sont perdues. On observe la perte
d'environ 6 trames supplmentaires dans le cas du basculement inter-BSC par rapport
119
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
un mme basculement intra-BSC. On notera cependant que ces pertes peuvent varier
sensiblement en fonction de la politique mise en oeuvre pour la gestion des flux de donnes. Dans notre cas, nous informons le SGSN ds que plus de deux trames LLC pour
un mobile donn - sont en attente de transmission dans un quipement. Une gestion des
flux plus fine devrait entraner la diminution de ces pertes, mais demande une plus
grande ractivit du rseau et peut induire des dlais de transmission supplmentaires
dans des conditions normales de trafic.
De ces pertes dcoulent le nombre de paquets IP perdus cause du basculement (Cf. figure 6.3.6). Ces pertes sont reprises pas le mcanisme de retransmission de TCP.
120
Conclusion
Cette partie nous a permis de comparer les performances des stratgies de reslection et
de handover dans le cas du basculement inter-BSC. Le handover reste la stratgie de
basculement la plus efficace, tant en terme de pertes que de temps de coupure. Cette
tude nous a galement permis de comparer les performances obtenues pour les basculements intra et inter-BSC, mme si la comparaison n'est pas scrupuleusement exacte du
fait des diffrences de configuration entre les deux simulations (entre autre, les deux
121
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 6.4.1. Nombre moyen de bloc RLC perdus par basculement (diffrence mis/reus)
Les figures 6.4.2 prsentent la diffrence, au niveau RLC, entre le nombre de blocs gnrs et le nombre de blocs transmis. Dans le sens montant, ces pertes sont encore une
fois indpendantes de la taille de la fentre d'mission. La transmission est en effet
suspendue au moment du basculement. Seuls les blocs issus de la trame LLC en cours
de transmission sont donc perdus. Par contre, dans le sens descendant, l'influence de la
taille de la fentre d'mission est beaucoup plus sensible. Assez logiquement, les pertes
sont d'autant plus faibles que la fentre d'mission est petite. Quand la fentre d'mission est petite, les pertes correspondent presque l'ensemble de la fentre (seuls les
quelques blocs transmis avant le dclenchement du basculement ne sont pas perdus).
122
Quand la fentre d'mission est plus large, celle-ci ne se remplit pas forcment compltement. Cela s'explique par le fait que nous utilisons des mobiles de classes multislot
4+1. Un mobile met alors 4 blocs RLC dans le sens descendant et 1 slot dans le sens
montant par priode de 20 ms. Pendant la dure du basculement 10 secondes - il peut
donc mettre au maximum 500 blocs et en recevoir 2000. Or, le mobile stoppe naturellement sa transmission montante et, en moyenne, il ne recevra pas autant de blocs
compte tenu du fait que plusieurs mobiles (quatre en moyenne) se partagent la ressource. Si on considre les figures 6.4.1, on note en effet que le mobile ne reoit que
700 blocs en moyenne pendant la dure basculement (et non 2000). Le nombre de donnes perdues dpend fortement de l'instant de basculement. Si la fentre est quasiment
pleine et que l'metteur est en attente de rception d'un acquittement, les pertes seront
faibles. Les blocs perdus sont des blocs dupliqus dans le cadre d'une retransmission
prventive. Par ailleurs, les couches suprieures n'ont pas systmatiquement suffisamment de donnes transmettre pour remplir totalement la fentre. Un acquittement peut
tre mis avant par le rcepteur qui dtecte une retransmission cyclique prventive du
fait que la couche LLC n'a plus rien transmettre. Une fois le basculement effectu,
tous les blocs gnrs sont perdus. Il n'y a cependant pas forcment suffisamment de
trame LLC segmenter pour remplir l'ensemble de la fentre et ceux, quand bien mme
la couche TCP effectue des retransmissions. Le nombre de blocs perdus finit donc par
se stabiliser. A noter que ce niveau de stabilisation dpend forcment du comportement
des couches de transmission localises au dessus de la couche RLC et des capacits de
transmission mises disposition du mobile par le rseau.
Figure 6.4.2. Nombre moyen de bloc RLC perdus par basculement (diffrence gnr/transmis)
123
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Les figures 6.4.4 prsentent le nombre moyen de trames LLC perdues par basculement.
Ce nombre dcoule directement du nombre de bloc RLC perdus.
Conclusion
Cette partie nous a permis d'valuer l'influence de la taille de la fentre d'mission au niveau RLC. On constate que des fentres d'mission trop petites conduisent un blocage
trop rapide de la transmission tandis que des fentre d'mission trop grandes n'amliorent pas les performances. La taille de la fentre d'mission doit tre choisie avec
soin, en fonction des capacits multislots (c'est dire en fonction du dbit RLC) des
mobiles.
124
6.5. Conclusions
Dans cette partie, nous avons valu les performances des procdures de reslection et
de handover intra et inter BSC. Quelque-soit le type de basculement, il ressort que la
procdure de handover est plus efficace que la procdure de reslection, que ce soit du
point de vue des pertes de donnes que des dlais de transmission. Par ailleurs, la procdure de handover induit un temps de coupure de la transmission plus faible. Elle est cependant plus difficile mettre en place que la procdure de reslection.
Pour le cas du transfert inter-cellulaire intra-BSC, nous avons propos de maintenir les
tats de transmission au niveau RLC afin de limiter les pertes au moment du basculement et de reprendre plus rapidement la transmission. Les rsultats montrent que cette
stratgie augmente sensiblement les performances des procdures de handover et de reslection en rduisant les pertes de donnes. Cela entrane cependant une lgre augmentation des dlais de transmission du fait que moins de trames sont perdues, ce qui
engendre une charge plus importante du rseau.
En cas de coupure longue, le maintien des tats de transmission au niveau RLC ncessite de revoir la politique de gestion des temporisateurs qui dcident de la rupture de la
transmission. C'est pourquoi ce maintien n'a t propos que dans le cas du handover.
Ce maintien n'est pas non plus possible dans le cas o le handover est inter-BSC. En effet, cela ncessiterait de pouvoir transfrer et de synchroniser les tats de transmission
d'un BSC l'autre, processus qu'il est difficile concevoir actuellement.
La reslection assiste permet de rduire fortement les temps de coupures mais n'a
qu'une trs faible influence sur les pertes. L'ensemble des blocs de la fentre de transmission RLC, non encore transmis au moment du handover, est perdu. La taille de la fentre de transmission au niveau RLC n'a que trs peu d'impact sur les dlais de transmission mais a un effet sensible sur les pertes. Une taille de fentre plus faible aura en
effet pour consquence de rduire le nombre de blocs RLC/MAC perdus. Cela risque
cependant d'augmenter les cas de blocage lorsque des blocs errons ont t dtects en
dbut de squence.
7. Conclusion
Cette partie visait prsenter les diffrentes stratgies possibles pour raliser un transfert inter-cellulaire qui soit gr au niveau des couches basses des rseaux radio-cellulaires. Nous avons prsent les mcanismes de fiabilisation au niveau RLC et LLC utiliss dans les rseaux radio-mobiles et mis en vidence les interactions qui pouvaient
avoir lieu entre ces diffrent mcanismes. Nous avons ensuite dress un tat des lieux de
la normalisation des mcanismes de reslection et de handover pour les donnes dans
les rseaux cellulaires EGPRS. Nous avons dcrit les mcanismes de basculement et
mis en vidence les principaux temporisateurs mis en jeu. Nous avons ensuite valu
diffrentes stratgies de basculement intra et inter-BSC. Nous avons mis en vidence les
125
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
126
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
1. Introduction
De nombreux travaux sont actuellement mens en vue d'assurer la mobilit des utilisateurs en leur permettant de changer de technologie d'accs (RAT Radio Access Technologie) au cours d'une communication. Le groupe de travail 802.21 [802.21] se
consacre l'tude des solutions apporter pour assurer la mobilit des utilisateurs entre
rseaux inter-connects et pouvant utiliser diffrentes technologies d'accs. Ces proccupations sont aussi partages par les membres de la communaut MESA [MESA] qui
souhaitent dfinir un systme qui permette l'inter-fonctionnement des rseaux de tlcommunication existant dans le cadre d'oprations de scurit civile.
Certains rseaux cellulaires apportent dj des fonctions de basculement automatique
(ou handover) entre technologie radio htrognes. A titre d'exemple, le dual mode 2G3G apporte dj cette fonctionnalit pour les services de tlphonie entre les systmes
GSM et UMTS [3GPP 23.009]. Les normes 3GPP dfinissent galement des mcanismes de reslection qui permettent le rtablissement automatique des transmissions
lors du basculement entre des rseaux d'accs UMTS et EDGE [3GPP 24.008].
Le changement de technologie d'accs peut conduire une modification des caractristiques du service offert. Par exemple, un utilisateur qui passe d'un rseau UMTS un
rseau EDGE alors qu'il transfre des donnes peut constater une chute de son dbit. A
l'inverse, un utilisateur qui regarde un film en streaming sur UMTS peut basculer, au
moment de son arrive dans un lieu public, sur un point d'accs WIFI qui lui permet de
bnficier d'un dbit plus important, et ventuellement d'une meilleure qualit d'image
et de son.
Dans la partie II, nous avons tudi les mcanismes de handover et de reslection au
sein d'une mme technologie d'accs, pour le systme E-GPRS. Ce chapitre se propose
d'tudier le basculement entre points d'accs de technologies diffrentes. Pour les besoin
de cette tude, nous nous focalisons sur le basculement entre la technologie E-GPRS et
la technologie WIFI [Pej04][802.11].
Ce chapitre dbute par une prsentation des diffrentes approches qui peuvent tre
adoptes pour utiliser conjointement les technologies cellulaires E-GPRS/UMTS et les
technologies WIFI dans un mme rseau. Nous proposons par la suite diffrentes solu127
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
tions pour amliorer les performances du basculement entre les technologies d'accs EGPRS et WIFI. Nous analysons les rsultats de simulations obtenus et fournissons
quelques conclusions.
Dans une seconde partie, nous nous focalisons sur le cas particulier des transmissions en
streaming . Nous analysons l'impact de la reslection intra et inter-RAT sur les pertes
et les dlais dans le cas des transmissions TCP et UDP. Dans le cas de UDP, nous proposons d'activer la couche LLC afin de permettre la ralisation de transferts inter-RAT
sans pertes.
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
129
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
130
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
est fix par dfaut 5 secondes (une des deux valeurs par dfaut de la norme GPRS
LLC [3GPP 44.064]). Une partie de notre tude permettra de justifier ces valeurs. Nous
comparerons en effet les performances de cette approche pour diffrentes tailles de fentre et diffrents temporisateurs.
132
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Figure 2.5.1.1. Nombre de trames R-LLC perdues au cours d'un transfert WIFI vers GPRS (diffrence emis/recus)
Dans le cas o un mcanisme de retransmission au niveau R-LLC est utilis, la transmission reste bloque sur la fentre : seules les trames de la fentre d'mission sont rellement perdues. Cependant, toutes les 5 secondes, les trames non acquittes sont rmises, ce qui entrane un profil de pertes en escalier. Ces r-missions engorgent inutilement l'interface radio du point d'accs initial, mais permettent une reprise de la transmission plus rapide sur la nouvelle cellule.
Les figures 2.5.1.2 prsentent les pertes de trames au niveau R-LLC : diffrence entre
les trames qui devait tre transmises et celles qui ont t correctement dlivres. On retrouve les mme pertes que sur la figure 2.5.1.1, mis part le cas o on utilise un mcanisme de retransmission au niveau R-LLC qui conduit ce qu'il n'y ait aucune perte.
Les courbes des pertes au niveau LLC (couche LLC localise dans le SGSN) et au niveau TCP (mesures effectue au niveau du SGSN) prsentent exactement le mme profil.
133
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 2.5.1.2. Nombre de trames R-LLC perdues au cours d'un transfert WIFI vers GPRS (diffrence
gnrs/transmis)
134
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
135
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
136
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
137
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
138
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Figure 2.6.1. Nombre de blocs RLC perdus au cours d'un transfert GPRS vers WIFI (diffrence emis/recus)
139
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Les figures 2.6.1 montrent la diffrence entre le nombre de blocs mis et le nombre de
blocs reus. Les rsultats obtenus sont comparables au cas d'un handover GPRS/GPRS
avec rinitialisation des contextes RLC (Cf. chapitre II). Dans le cas du handover, aucune perte n'a lieu puisque la transmission est suspendue avant que le basculement ne
soit dclench.
Les figures 2.6.2 illustrent les pertes de blocs au niveau RLC/MAC : diffrences entres
les blocs qui ont t gnrs et ceux qui ont t correctement transmis. On retrouve les
mmes ordres de grandeur de pertes que dans le cas du basculement GPRS/GPRS, avec
rinitialisation de la couche RLC/MAC. On constate que les stratgies par reslection
engendrent des pertes sensiblement plus importantes du fait que le basculement est dtect beaucoup plus tardivement. En effet, tant que le basculement n'a pas t dtect,
les trames LLC qui arrivent au niveau du BSC pour tre transmises sont segmentes en
blocs RLC. On notera que, pour un trafic persistant, le nombre de blocs perdu est indpendant du temps de reslection. Il est born par la taille de la fentre d'anticipation
RLC.
Figure 2.6.2. Nombre de blocs RLC perdus au cours d'un transfert GPRS vers WIFI (diffrence gnrs/transmis)
140
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Figure 2.6.3. Nombre de blocs R-LLC perdus au cours d'un transfert GPRS vers WIFI (diffrence mis/reus)
Figure 2.6.4. Nombre de blocs R-LLC perdus au cours d'un transfert GPRS vers WIFI (diffrence gnrs/transmis)
141
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 2.6.6. Nombre de paquets TCP perdus au cours d'un transfert GPRS vers WIFI (diffrence mis/reus)
142
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Figure 2.6.8. Temps de transmission des donnes gnres par la couche application
143
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
L'objectif de cette tude est d'analyser les performances, en cas de handover, de ces trois
approches de fiabilisation. Nous analysons ces approches dans le cas du handover intraRAT GPRS et inter-RAT GPRS-WIFI. Nos conclusions permettront de dterminer
quelle est l'approche la plus adapte en fonction des contraintes de qualit de service
imposes par la transmission : dlais de dlivrance et tolrance aux pertes.
Paramtres
Loi
Valeur
Dterministe
500 ms
K=81,5
=1,1
m=66 666
8
secondes
moyenne : 4 secondes
Temps de basculement
0 10 secondes
Paramtre de la simulation
Uniforme
20 trames
Temporisateur de retransmission
5 secondes
145
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 3.3.1. Nombre moyen de blocs RLC perdues au cours d'une reslection (trafic streaming)
146
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Figure 3.3.2. Nombre moyen de trames R-LLC perdues au cours d'une reslection (trafic streaming)
Au niveau R-LLC (Cf. figure 3.3.2), les pertes de trames sont proportionnelles aux
pertes au niveau RLC. L'ajout d'un mcanisme de retransmission au niveau LLC permet
de reprendre les pertes provoques par la reslection de cellule. On retrouve le mme
profil de pertes au niveau IP.
Caractristiques de la session au niveau Application
Figure 3.3.3. Nombre moyen d'objets perdus et transmis au cours d'une reslection (trafic streaming)
Au niveau application, le nombre d'objets perdus et transmis est reprsent sur les figures 3.3.3. Dans le cas d'UDP, les pertes sont proportionnelles aux pertes au niveau
147
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
LLC. Elles sont indpendantes du temps de coupure car, quelque soit leur dure, le
nombre de blocs RLC perdus est fixe.
Dlais de transmission au niveau R-LLC
Les figures 3.3.4 prsentent les temps de transmission aux niveaux LLC et application.
Le temps de transmission le plus faible est obtenu avec le protocole UDP seul. Ce protocole entrane la perte des donnes qui sont mises au moment du basculement, ce qui
n'entrane pas d'engorgement du rseau et donc, limite les dlais de transmission. L'ajout
d'une couche de retransmission au niveau LLC entrane des dlais supplmentaires. Les
donnes qui sont transmises au cours du basculement sont stockes et leur transmission
subit un dlai supplmentaire qui comprend le temps qui s'coule avant la fin du basculement et le temps de traitement des autres paquets mis en attente prcdemment. Il y a
donc un lger engorgement de la transmission juste aprs que le basculement ait eu lieu.
Dans le cas o on utilise TCP, l'engorgement est beaucoup plus important. D'une part, il
faut attendre que les premiers paquets aient t acquitts avant d'envoyer les suivants,
d'autre part, aprs basculement, le rseau subit un engorgement important d au fait
que, au cours du basculement la couche TCP a pu retransmettre plusieurs fois un
mme paquet. Compte tenu de la charge du rseau, la couche TCP n'est ici pas adapte
pour couler un trafic aussi important, ce qui conduit de gros engorgements et des dlais de transmission peu tolrables.
148
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Figure 3.4.1. Nombre moyen de trames R-LLC perdues au cours d'une reslection (trafic streaming)
Le mcanisme de transmission TCP est celui qui engendre le moins de pertes au moment de la reslection. Cela s'explique par le fait que le mcanisme TCP attend que les
trames soient correctement reues avant d'en envoyer de nouvelles. Si les trames envoyes sont perdues, TCP va les retransmettre l'expiration d'un temporisateur. Ainsi,
en cas de pertes de trames, le flux de donnes se rduit et les pertes sont alors plus limites. Dans le cas d'UDP, au contraire, il n'y a pas de contrle de flux. Toutes les trames
transmises par le BSC pendant la phase de basculement sont perdues et comme il n'y a
aucun mcanisme de retransmission, les pertes constates ne sont pas rcupres. Dans
le cas o on met en place un mcanisme de retransmission au niveau LLC, le nombre de
trames perdues pendant la phase de basculement semble encore plus important. En rali149
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 3.4.2. Nombre moyen de d'objets perdus et transmis au cours d'une reslection (trafic streaming)
150
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
151
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 3.5.1. Nombre moyen de bloc RLC perdus au cours d'une reslection (trafic streaming)
Figure 3.5.2. Nombre moyen de trames R-LLC perdues au cours d'une reslection (trafic streaming)
152
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
Figure 3.5.3. Nombre moyen de d'objets perdus et transmis au cours d'une reslection (trafic streaming)
153
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
154
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
4. Conclusion
Ce chapitre nous a permis d'aborder le problme de la reslection et du handover dans le
cas du basculement inter technologies d'accs.
Nous avons analys et compar les performances de trois stratgies de reslection et
d'une procdure de handover dans le cas du basculement inter-RAT GPRS WIFI. Il ressort de cette tude que la stratgie de basculement par handover est de loin la plus efficace et terme de pertes et de dlais, mais elle ncessite de mettre en place des mcanismes de contrle importants (notamment pour diffuser des informations systme et
procder la rservation de ressources). La stratgie de reslection conduit des pertes
et des dlais de basculement important. Dans le cas du basculement inter-RAT WIFI
vers GPRS; Les pertes peuvent cependant tre limites en mettant en place un mcanisme permettant de notifier le dpart ou plutt l'absence d'activit - du mobile dans
la cellule courante. Par ailleurs, la mise en place d'un mcanisme de retransmission au
niveau d'une couche LLC commune aux deux interfaces permet de raliser un basculement sans pertes en reprenant la transmission l o elle en tait dans la nouvelle cellule.
Cette couche LLC constitue par ailleurs une solution trs efficace pour assurer une reslection sans pertes dans le cas o les couches suprieures travaillent en mode non
acquitt, comme dans le cas du trafic streaming IP/UDP. En comparaison, UDP seul
entrane des pertes consquentes tandis que TCP induit des dlais de transmission plus
importants.
155
1. Introduction
Les rseaux de tlcommunications mobiles possdent actuellement un coeur de rseau
divis en deux domaines : un domaine circuit, utilis pour le transport des communications tlphoniques, et un domaine paquet, utilis pour le transport de donnes. Tous les
rseaux de tlcommunications subissent actuellement de profondes transformations.
Celles-ci devraient permettre de transporter la voix directement sur le rseau de donnes
en suivant les principes de la technologie VoIP Voice over IP. Ces volutions entrent
dans le cadre de la convergence des rseaux : fusion des domaines circuits/paquets et
meilleure interconnexion des rseaux fixes/mobiles.
Afin de grer les appels vocaux travers un rseau de donnes une nouvelle architecture
de contrle doit tre dploye. Cette architecture est appele IMS IP Multimdia Subsystem [Cam06]. Elle doit permettre de grer des sessions de communication vocales et
des sessions multimdia. Cette architecture intgre des passerelles avec les rseaux de
tlphonie commuts, qu'ils soient mobiles (PLMN) ou fixes (PSTN). C'est une architecture de service qui permet d'offrir tous les services d'un rseau de tlcommunication
moderne : confrences tlphoniques et vido-confrences, fonction rpondeur, appels
multiples, transferts d'appels... Cette architecture se veut volutive afin de permettre aux
oprateurs de dployer facilement de nouveaux services.
Le dploiement de l'IMS devrait permettre aux oprateurs de raliser des conomies
substantielles puisqu'il ne sera plus ncessaire de dployer et de maintenir le domaine
circuit de leurs rseaux. Les communications vocales et les transferts de donnes transiteront alors tous par le domaine paquet. Par ailleurs, l'IMS devrait permettre de faciliter
le roaming en permettant aux utilisateurs d'accder aux services auxquels ils sont abonns, quelque-soit le rseau d'accs qu'ils empruntent. La notion mme d'oprateur se
voit alors profondment modifie : ce n'est plus forcment le mme oprateur qui assurera le transport de l'information, la gestion de l'abonn et la fourniture du service.
Dans les rseaux IMS, les sessions multimdia sont contrles grce au protocole SIP Session Initiation Protocol. C'est un protocole de signalisation de niveau application.
Les messages de signalisation SIP sont rdigs au format texte. Ce format est donc trs
diffrent du format de signalisation binaire utilis couramment dans les rseaux de tlcommunications (codage de type BER/PER). Les messages de signalisation SIP sont de
taille sensiblement plus leve que les messages de signalisation binaire.
157
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
2. Architecture IMS
L'architecture IMS IP Multimdia Subsystem est conue pour fournir un service de
gestion de sessions de transport multimdia. Cette architecture permet galement la
gestion des communications VoIP ( voix sur IP ) travers le domaine paquet des rseaux cellulaires. L'architecture IMS est compose d'un ensemble de passerelles et de
serveurs qui sont dploys au sein du rseau IP priv de l'oprateur, au del du GGSN.
Par ailleurs, cette architecture de contrle de sessions multimdia permet l'utilisateur
de bnficier des services multimdia auquel il est abonn, indpendamment du rseau
d'accs par lequel il transite. Cette caractristique entre dans le cadre de la convergence
des rseaux. La figure 2.1 prsente l'architecture d'un rseau IMS [3GPP 23.002].
158
Le CSCF Call Session Control Function est un quipement qui permet de grer les
diffrentes sessions utilisateur. Une session multimdia peut faire appel plusieurs
CSCF lorsque le rseau d'accs, le rseau d'attachement ou le service demand par l'utilisateur sont situs dans des rseaux diffrents. Le CSCF peut tre dcompos en trois
fonctions : Proxy (Proxy-CSCF), Interrogation (Interrogating-CSCF) ou Serveur (Serving-CSCF).
Le P-CSCF est le point d'accs au rseau IMS. Il est situ la sortie du rseau d'accs
du mobile. Cet quipement est charg de grer l'enregistrement de l'utilisateur auprs de
l'I-CSCF et d'offrir le service demand par l'intermdiaire du S-CSCF.
Le I-CSCF est situ dans le rseau nominal de l'abonn. Cet quipement permet d'assurer l'enregistrement et l'authentification de l'utilisateur. Il contrle l'accs au service demand et dsigne un S-CSCF charg de grer la session multimdia.
Le S-CSCF se situe dans le rseau qui offre le service l'abonn. Cet quipement contrle la session multimdia qui permet d'offrir le service l'utilisateur. Le S-CSCF est
reli des serveurs et des passerelles vers des rseaux de tlphonie et d'autres rseaux multimdia. Ces passerelles doivent permettre une transmission du contenu et de
la signalisation. Elles assurent par exemple le transcodage vocal et la traduction de la signalisation tlphonique vers SIP.
Le MGCF dialogue avec le S-CSCF pour tablir et contrler les supports de transmission qui vont permettre le transport d'appels VoIP.
L'IMS-MGW IMS Mdia Gateway assure la passerelle entre le rseau commut et
le rseau IMS. Il assure la conversion des flux audio. Il dialogue avec le MGCF pour
contrler la ressource.
Le MRF Multimdia Ressource Function est divis en deux entits. Le MRFC
MRF Controller et le MRFP MRF Processor. Le MRFC contrle la session multimdia, et en particulier sa topologie puisqu'il s'agit gnralement d'un pont de
confrence. Il dialogue avec le S-CSCF et le MRFP. Le MRFP intgre des fonctions de
transcodage et de multiplexage.
Le HSS Home Subscriber Server - est la base de donnes utilisateur. Elle contient le
profil de chaque abonn, et notamment les informations d'authentification et d'autorisation d'accs aux diffrents services. Le HSS est localis dans le rseau nominal de l'abonn.
159
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le codage des messages de signalisation sous forme de texte diffre fortement des codages binaires utiliss dans les rseaux de tlphonie. Un codage comme le PER, utilis
dans l'UMTS, permet de coder des messages de contrle de faon trs compacte. La
taille d'une message de contrle dans un rseau mobile est de l'ordre de la centaine d'octets. En contrepartie de sa compacit, ce codage est complexe dcoder. Le processus
de codage et dcodage requiert le dveloppement de parseurs binaires.
160
Des messages de type texte , comme SIP, sont plus facilement interprtables et les
parseurs sont plus simples dvelopper. Par contre, suivant leur contenu et les options
actives par l'utilisateur, la taille de ces messages peut devenir trs importante. Par
exemple, le message SIP prcdent comporte 768 caractres, soit cinq fois la taille d'un
message de signalisation GSM. Ces 768 octets sont par ailleurs encapsuls dans des
trames TCP ou UDP, qui viendront grossir la quantit de donnes transmettre.
Avec un codage binaire, le contenu des messages est normalis l'avance. Tout message non conforme au format normalis peut tre cart par l'oprateur, qui contrle ainsi la nature et la taille des messages transmis. Avec des protocoles comme SIP, la signalisation transmise sur l'interface radio est gnre par l'utilisateur, le P-CSCF et le serveur multimdia. A aucun moment le rseau d'accs ne contrle la nature des informations ou la taille des messages transmis. La gestion d'une session multimdia peut donc
tre l'origine d'un trafic important sur l'interface radio. Trafic sur lequel l'oprateur qui
gre le rseau d'accs n'exerce en thorie aucun contrle.
Dans le cadre du dploiement de la technologie IMS, la capacit des supports de transmission de signalisation sera trs certainement limite. Un oprateur peut difficilement
se permettre d'allouer des canaux haut dbit pour couler de la signalisation. Une valuation des performances de SIP travers l'interface radio bas dbit mobile est fournie
dans [RFC 3322].
4. Architecture SigComp
Afin d'amliorer les performances de transmission de la signalisation SIP, nous souhaitons mettre en place une solution de compression au niveau du rseau d'accs, entre le
P-CSCF et le mobile. Le document [RFC 3320] dcrit les principes d'un compresseur /
dcompresseur universel appel SigComp. Celui-ci peut tre utilis pour la compression
de signalisation SIP. L'architecture de compression SigComp est dcrite sur la figure
4.1.
Le principe du compresseur est assez simple. La couche application situe au dessus
du compresseur transmet un message avec un identifiant de transaction. Le message
est alors trait par un dispatcher qui transmet le message au compresseur associ la
session. Ce compresseur est adapt au type de message qui est chang dans la session.
Il possde ventuellement un contexte de compression qui lui permet de compresser le
message en fonction des changes qui prcdent. Le compresseur consulte le contexte
de compression associ la transaction, compresse donc le message, met jour le
contexte de compression, puis renvoie le message au dispatcher. C'est ce dernier qui
dlivre alors le message la couche de transport.
Au niveau du rcepteur, le message est rceptionn par un dispatcher. Ce dernier envoie
le message un dcompresseur universel (UDVM Universal Decompressor Virtual Machine) qui se charge de dcompresser le message. Ce dcompresseur doit dterminer quel algorithme appliquer pour assurer la dcompression. Il peut aller puiser
certaines informations dans les contextes de compression / dcompression qui se
161
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
5. Solutions de compression
5.1. Codage de Huffman
Cette technique de codage de textes a t dfinie par David Huffman en 1951
[Huff51][Wiki-Huff]. Cette technique consiste associer chaque motif (ou caractre)
d'un texte un code binaire dont la longueur est inversement proportionnelle la
frquence d'apparition du motif dans le texte. Ce codage est d'autant plus performant
qu'il existe une variance importante entre la frquence d'apparition des diffrents caractres.
Pour utiliser la technique de codage de Huffman dans le cadre de la compression de
donnes, il faut construire un dictionnaire gnralement reprsent sous forme d'un
arbre binaire qui permet de retrouver le code associ chaque caractre. Pour cela, il
faut parcourir le texte afin de calculer le nombre d'occurrences de chacun des caractres.
Pour assurer la dcompression, il faut galement stocker l'alphabet utilis dans l'en-tte
du fichier, ce qui, pour de petits fichiers, attnue fortement les bnfices du codage de
162
Huffman. Une solution alternative consiste utiliser un alphabet prdfini (codage statique), connu de l'metteur et du rcepteur. Cette solution vite d'avoir transmettre l'alphabet, mais l'effet de compression n'est plus assur. Avec certains fichiers, le codage
de Huffman partir d'un alphabet prdfini peut entraner une augmentation de la taille
du fichier. C'est le cas lorsque le fichier coder contient uniquement des caractres dont
le code, dans l'alphabet considr, est plus long que la moyenne.
Dans le cadre d'une transmission, on ne connat pas forcment l'avance les caractres
qui devront tre transmis. Il n'est alors pas possible de construire un arbre de Huffman
adapt au contenu transmis. Il existe cependant des mthodes dites adaptatives
[Gal78] qui permettent de construire puis modifier l'arbre de compression en fonction
des caractres nouvellement transmis. Ces mthodes ncessitent de transmettre les modifications de l'arbre de compression au dcodeur.
Construction de l'arbre
Il existe plusieurs mthodes pour construire l'arbre de codage de Huffman. La plus
simple consiste classer les caractres suivant leur frquence d'apparition dans le texte.
Chaque caractre forme alors un arbre une feuille (le caractre) auquel est associ un
poids (la frquence d'apparition du caractre).
Tant que l'on a plusieurs arbres, l'algorithme consiste regrouper les deux arbres dont le
poids est le plus faible au sein d'un arbre dont le poids est la somme du poids des deux
sous arbres. Le sous arbre gauche est alors identifi par un 0 et l'arbre droit par un 1.
L'arbre ainsi cr est ensuite rintgr dans la liste.
Soit la phrase coder :
ABCDEFGHAAACCDDGGGFH
L'alphabet est compos de 8 lettres : A, B, C, D, E, F, G et H. Il est donc possible de coder chaque lettre de l'alphabet sur 3 bits. A=001, B=010, C=011, ... H=111. Il faut alors
60 bits pour coder la phrase. En appliquant l'algorithme de Huffman, on peut cependant
coder la phrase sur moins de bits.
Le tableau 5.1.1 prsente la frquence d'apparition de chacun des caractres.
Caractre A B C D E F G H
Frquence 4 1 3 3 1 2 4 2
Tableau 5.1.1. Frquence d'apparition des diffrents caractres
163
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Arbres initiaux
AG=8, HCDBEF=12
AGHCDBEF=20
Le code associ chaque caractre se lit directement sur l'arbre. C'est le chemin qui
mne de la racine de l'arbre au caractre considr. Soit, dans notre exemple, les codes
164
suivants : A=00, B=11100, C=101, D=110, E=11101, F=1111, G=01 et H=100. En utilisant ce codage, le message original est alors cod l'aide de 54 bits, soit un taux de
compression de 10% par rapport un codage fixe sur 3 bits.
Si on utilise le mme arbre de compression sur un autre message, cela peut amener
une expansion de la taille du code. Par exemple ABCDEFGHBBBBCCCDDDGF
sera cod sur 71 bits au lien de 60 avec un codage fixe.
Le codage de Huffman est trs efficace pour compresser des contenus texte. Cependant,
comme on a pu le voir, l'utilisation d'un arbre de Huffman inadapt peut amener un accroissement de la taille des donnes codes (en comparaison un codage statique). Par
ailleurs, la dcompression requiert un traitement bit bit afin de progresser dans
l'arbre et de procder la dcompression. Ce type de traitement est plus complexe raliser que l'interprtation de codes de taille fixe [LZW84].
165
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
166
Lettre Lue
Motif compos
Dictionnaire
Code envoy
A=1
B=2
<1, 2>
7=<1, 2>
1 (pour A)
C=3
<2, 3>
8=<2, 3>
2 (pour B)
D=4
<3, 4>
9=<3, 4>
3 (pour C)
E=5
<4, 5>
10=<4, 5>
4 (pour D)
F=6
<5, 6>
11=<5, 6>
5 (pour E)
A=1
<6, 1>
12=<6,1>
6 (pour F)
B=2
<1, 2>=7
C=3
<7, 3>
13=<7, 3>
7 (pour AB)
D=4
<3, 4>=9
F=6
<9, 6>
14=<9, 6>
9 (pour CD)
C=3
<6, 3>
15=<6, 3>
6 (pour F)
D=4
<3, 4>=9
E=5
<9, 5>
16=<9,5>
9 (pour CD)
F=6
<5, 6>=11
B=2
<11, 2>
17=<11, 2>
11 (pour EF)
C=3
<2, 3>=8
D=4
<8, 4>
18=<8, 4>
8 (pour BC)
F=6
<4, 6>
19=<4, 6>
4 (pour D)
C=3
<6, 3>=15
D=4
<15, 4>
20=<15, 4>
15 (pour FC)
4 (pour D)
167
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Code lu
Motif associ
Dictionnaire
AB=7
BC=8
CD=9
DE=10
EF=11
AB
FA=12
CD
ABC=13
CDF=14
CD
FC=15
11
EF
CDE=16
BC
EFB=17
BCD=18
15
FC
DF=19
FCD=20
Dans [LZW84], Terry A. Welch propose d'utiliser des codes de taille fixe de 12 bits, ce
qui autorise des dictionnaires comportant 4096 motifs (en comptant les 256 motifs de
l'alphabet ASCII). Il est galement possible d'utiliser des motifs de taille variable. Dans
ce cas, on commence par des motifs 8 bits. Chaque fois qu'il faut tendre l'espace de
numrotation, il faut mettre un zro. Par exemple, si les codages sont raliss sur 8 bits
et que l'on doit mettre un code 264, on met tout d'abord un 0 (pour passer un codage
sur 9 bits) puis le code 264 (cod sur 9 bits). Tous les motifs suivants sont alors cods
sur 9 bits, jusqu' ce qu'on doive mettre un code suprieur 511. Dans le cas o on utilise ce type de codage, le dictionnaire est initialis avec les codes de la tables ASCII incrments de 1, ce qui permet de librer la valeur 0. Les caractres ASCII sont alors cods entre 1 et 256.
168
On peut noter ici qu'on utilise pas toute la plage possible de valeurs permises par les 9
bits de codage. Les lettres sont codes de 0 255 et les longueurs de 257 285. Les valeurs de 286 511 ne sont donc pas utilises. Nous verrons l'intrt de ne pas utiliser
toute la plage de valeurs possible dans le cadre du codage de Huffman qui suit. La valeur 256 est rserve. Elle permet de dlimiter diffrentes sections d'un document cod.
Les longueurs sont suivies par une distance. Les distances sont codes sur 5 bits auxquels on ajoute ventuellement des bits supplmentaires (13 bits supplmentaires au
maximum). Les distances sont comprises entre 1 (code 0) et 32768 (code 29 + 13 bits
supplmentaires). Une table permet de retrouver la valeur de la distance partir du code
et des bits supplmentaires. Celle-ci peut tre rsume comme suit :
169
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le format gnral d'un couple longueur/distance est donc reprsent comme suit :
[9 bits de longueurs]
{0 5bits supplmentaires}
[5 bits de distance]
{0 13 bits supplmentaires}
Symboles
Taille du code
Valeurs du code
0 143
8 bits
00110000 10111111
144 255
9 bits
110010000 111100101
256 279
7 bits
0000000 0010111
280 287
8 bits
11000000 11000111
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le document [RFC 3485] fournit un dictionnaire qui peut tre utilis pour amliorer la
compression de messages SIP/SDP. Cette solution de compression l'aide d'un dictionnaire ne ncessite pas de conserver l'historique de la transaction. Ses effets se font alors
ressentir ds le premier message transmis. Cette solution d'amlioration de la compression peut tre utilise conjointement n'importe quel algorithme de compression.
6.3. EPIC
EPIC Efficient Protocol Independent Compression est une solution protocolaire de
compression de messages SIP propose par Siemens dans [EPIC01]. Le principe de ce
protocole consiste reprer les champs des messages SIP invariants d'un message
l'autre, les supprimer au niveau de l'metteur et les rintroduire au niveau du rcepteur. Les champs qui varient sont, quand eux, compresss l'aide d'une solution de
compression sans pertes.
Ce principe de compression est souvent utilis dans le cadre des transmissions sans fil
point point. Il n'est pas toujours possible d'utiliser ce principe de compression dans le
cas o les noeuds intermdiaires qui ne sont pas forcment toujours les mmes - ont
besoin des informations contenues dans l'en-tte des messages SIP pour, par exemple,
router le message jusqu' son destinataire.
L'inconvnient de ce type de compression est que les premiers messages, ou les messages totalement diffrents des prcdents, ne sont pas du tout compresss. Par ailleurs,
il faut absolument que le dcompresseur puisse savoir quelle session il a affaire afin
172
de recomposer le message SIP avec les bons champs d'en-tte. La compression EPIC
ncessite donc d'ajouter un identifiant sur la session SIP en cours.
La taille des messages SIP avant compression est fournie dans le tableau 7.1. La taille
de ces messages ne diffre presque pas d'un scnario l'autre.
N message
793
559
392
951
458
767
394
396
351
798
562
397
958
461
770
397
399
354
173
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Pour tre transports travers le rseau E-GPRS/UMTS, ces messages seront encapsuls dans des trames TCP ou UDP. Si on prend en compte l'tablissement des sessions
TCP ou UDP, la quantit relle de donnes transmises pour transmettre ces messages
SIP est bien plus importante. Surtout dans le cas d'une transmission TCP qui ncessite
d'tablir pralablement une connexion puis d'changer rgulirement des informations
d'acquittement.
Si on considre un canal pour le transport de signalisation dont le dbit est de 8kbits/s,
l'mission de tous les messages sur l'interface radio ncessite plusieurs secondes. Cela
ne prend pas en compte le temps de transmission de ces messages dans le rseau coeur,
ni le temps de traitement de ces informations par le mobile ou le serveur. Par ailleurs,
avant de pouvoir ngocier une session multimdia, le mobile doit procder plusieurs
changes avec le rseau d'accs afin de s'enregistrer, s'authentifier et ngocier les supports de transmission ncessaires pour l'change des messages SIP.
Pour assurer un temps d'tablissement des sessions de SIP qui ne soit pas trop lev, il
est ncessaire de rduire le temps d'mission en compressant les messages SIP.
La diffrence entre les tailles de messages pour les deux changes tant peu significative, nous considrons uniquement, dans la suite de cette tude, la premire srie de
messages : appel sans rponse .
Figure 7.1.1. Performances des compresseurs LZ77, LZW et Deflate (sans utilisation de dictionnaire)
174
On constate que la solution de compression Deflate est la plus performante, avec des
taux de compression variant entre 20% et 30%.
Les compresseurs sont d'autant plus performants que les messages sont de taille importante. Cela s'explique par le fait que la probabilit que le message contienne de la redondance d'informations est d'autant plus importante que le message est de grande taille.
On constate galement que pour les messages de petite taille, notre implmentation du
compresseur LZW est plus performante que LZ77. Ceci s'explique par le fait que LZ77
ne traite que les chanes de 3 caractres et plus, tandis que LZW rduit galement la
taille des motifs de 2 caractres qui se rptent.
Figure 7.2.1. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire)
175
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Figure 7.3.1. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire)
Dans le cas o on intgre le message prcdent dans le contexte de compression, on observe des gains de performances assez importants pour les algorithmes LZ77 et Deflate.
La seule exception tant le premier message, qui ne bnficie pas de l'effet d'un message
prdcesseur. La compression du message 4 est encore une fois peu performante. Le
message 3 est assez court. Seul les enttes du message 3 participent alors la compression du message 4.
176
Figure 7.3.2. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire)
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le dernier problme de ces solutions de compression est leur sensibilit aux erreurs.
Une erreur qui intervient en cours de transmission, risque de se rpercuter plusieurs fois
dans un message. Dans les solutions de compression qui se basent sur les messages prcdemment transmis, cette caractristique est encore plus critique. Une erreur introduite
sur une adresse IP au moment de la transmission du premier message conduira ce que
cette mme adresse IP soit errone dans tous les messages qui suivent. Il faut donc s'assurer de la fiabilit de la transmission, surtout au niveau de l'interface radio. Cela
conduit invitablement utiliser des schmas de codage trs protecteurs, et donc diminuer le dbit utile des transmissions de signalisation.
On constate que, pour le premier message, seul l'utilisation d'un dictionnaire de compression permet d'amliorer le niveau de compression. Pour les messages suivants, les
solutions de compression rutilisant les informations contenues dans les messages prcdents sont, de loin, les meilleures. La mmorisation de tous les messages de la session
permet d'obtenir les meilleures performances. L'utilisation du protocole EPIC ou d'un
dictionnaire produisent des compressions sensiblement gales. EPIC supprime le conte-
178
Les figures 7.4.3 et 7.4.4 prsentent les performances des diffrentes solutions de compression Deflate utilises conjointement avec un dictionnaire. Le dictionnaire
amliore sensiblement les performances de compression du premier message.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
180
Figure 7.5.1. Contribution des diffrentes solutions de compression (EPIC + Dico + Deflate)
Figure 7.6.1. Contribution des diffrentes solutions de compression (Dico + 1 message + Deflate)
181
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
8. Conclusion
Ce chapitre nous a permis d'aborder un des problmes pos dans le cadre des futures
volutions des rseaux mobiles paquets. Nous nous sommes focaliss sur les problmes
d'tranglement et de dlais qui pouvaient intervenir au niveau du rseau d'accs pour la
transmission de signalisation SIP.
Nous avons analys diffrentes solutions de compression qui pouvaient tre mises en
oeuvre pour compresser la signalisation SIP. Certaines sont trs performantes, mais
peuvent conduire des rptitions d'erreur assez importantes. Nous avons extrait de nos
analyses deux solutions de compression qui offrent de bonnes performances. La premire solution supprime puis restaure les informations dj transmises dans l'en-tte des
messages SIP. On compresse alors le rsultat avec un dictionnaire de compression prdfini et l'algorithme Deflate. La seconde solution consiste utiliser Deflate en intgrant
les messages prcdemment transmis dans le contexte de compression.
Il ressort de nos rsultats qu'il est possible d'atteindre des taux de compression assez
importants pour les messages SIP. Il n'est cependant pas possible de contrler prcisment la taille des messages. Par ailleurs, tous les algorithmes de compression proposs
sont peu performants sur la compression du premier messages. Les mcanismes de compression ne pouvant tre totalement adapts avant la transmission des informations caractrisant l'change. Seul l'utilisation d'un dictionnaire reprenant les principales chanes
de caractres rencontrs dans SIP permet d'amliorer un peu le taux de compression du
premier message.
182
Conclusion Gnrale
Conclusion Gnrale
1. Contexte de la thse
Les services multimdia sont actuellement en plein essor sur les rseaux radio-mobiles.
De nouveaux services comme la messagerie instantane, le tlchargement de musique, la tlvision sur mobile et la vido la demande rencontrent un succs croissant. Les oprateurs cherchent anticiper les futurs usages de leurs rseaux. Des modifications plus ou moins profondes des rseaux actuels se rvlent cependant ncessaires
afin de pouvoir offrir de nouveaux services. Pour les oprateurs, il s'agit de faire voluer
leurs rseaux tout en prservant une partie des architectures existantes. Cela permettant
d'assurer la bonne transition entre les diffrentes technologies et de minimiser les nouveaux cots de dploiement.
Le dveloppement des services multimdia ncessite d'amliorer les performances des
rseaux d'accs radio-mobiles. Il est ncessaire d'accrotre les dbits offerts aux utilisateurs, tout en diminuant le temps de propagation des donnes travers le rseau d'accs.
Il faut galement pouvoir fournir un vritable service de handover aux utilisateurs. Un
abonn doit pouvoir se dplacer librement dans les zones couvertes par son oprateur
sans que cela ait d'impact sur son service, notamment au moment o il change de
cellule. Des mcanismes de handover doivent donc tre mis en place afin de minimiser
la dure d'interruption du service et les pertes au moment du changement de cellule.
Plusieurs technologies d'accs sont actuellement dployes dans les rseaux cellulaires.
Le dploiement des systme UMTS s'effectue tout en maintenant le systme GSM. Par
ailleurs, de nouvelles technologies d'accs, dfinies en dehors du 3GPP, vont tre peu
peu interconnectes aux rseaux cellulaires. C'est le cas, entre autre, des technologies
WIFI et WIMAX. L'utilisateur doit pouvoir accder tous ses services, quelque soit la
technologie d'accs laquelle il a recours. Des procdures de handover entre technologies d'accs diffrentes doivent tre dfinies pour assurer la mobilit des utilisateurs
dans des rseaux htrognes.
L'architecture IMS IP Multimdia Subsystem a t normalise pour faciliter le dploiement et la gestion de services multimdia. Cette architecture repose sur un rseau
de transport IP. La gestion de la signalisation dans ce rseau est base sur le protocole
SIP Session Initiation Protocol.
Le protocole SIP, dfinit par l'IETF, a dans un premier temps t dploy sur des rseaux fixes. Afin de permettre l'tablissement rapide de sessions de service multimdia,
il faut absolument rduire le temps de transfert des messages SIP travers le rseau
183
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
d'accs mobile. Cela passe par une augmentation des dbits de transmission ainsi que
par une diminution des temps de latence et de propagation dans le rseau d'accs. L'utilisation de mcanismes de compression adapts permet galement de rduire le temps
de transmission des messages SIP, tout en optimisant l'utilisation des ressources du rseau d'accs.
2. Contributions
Cette thse traite de l'optimisation des performances des rseaux d'accs mobiles EGPRS. Elle se dcompose en quatre chapitres.
Dans le premier chapitre, nous fournissons une analyse du transfert de donnes sur
l'interface Abis GPRS et formulons des proposition pour permettre dans le cadre du
dploiement de la technologie EDGE d'accrotre les dbits de transmission. Une premire approche nous a conduit dfinir un modle analytique qui prend en compte l'allocation dynamique de ressources en mode circuit sur l'interface Abis, et un autre modle permettant d'analyser les caractristiques d'un trafic temps rel. Dans un second
temps, nous avons analys les performances de deux politiques d'allocation dynamique
de ressources. L'approche micro circuit consiste a allouer dynamiquement des circuit de taille variable sur les interfaces radio et Abis. L'approche avec bufferisation
consiste effectuer la transmission en deux tapes : d'abord sur l'interface Abis, puis sur
l'interface radio. Cette dernire approche ncessite la mise en place de tampons (ou buffers) au niveau de la station de base. Les rsultats de nos simulations montrent les bnfices apports, en terme de dlais et de dbits, par l'approche avec bufferisation. Ils
permettent galement d'valuer la taille des buffers mettre en place au niveau des stations de base.
Dans le second chapitre, nous dtaillons la problmatique du handover au sein du rseau
GPRS. Le dtail des mcanismes de retransmission utilis dans le systme GPRS est ensuite rappel. Les interactions qui peuvent avoir lieu entre les diffrents mcanismes de
retransmission sont prsentes. Nous exposons ensuite le dtail des mcanismes de reslection et de handover qui ont t rcemment normaliss pour le systme E-GPRS.
Dans la dernire partie de ce chapitre, nous prsentons les performances des mcanismes de reslection et de handover dans les cas intra et inter BSS. Nous comparons
les performances de ces deux mcanismes de basculement. Le handover se rvle plus
performant en terme de temps de coupure. Les pertes et les dlais de transmission sont
alors plus faibles. Pour amliorer les pertes, nous proposons de maintenir les tats de
transmission au niveau RLC au moment du basculement. Ces tats doivent tre utiliss
pour initialiser le nouveau TBF ouvert dans la cellule cible. Cette proposition a t
rcemment introduite, pour le cas du handover, dans la version 6 de la norme. D'aprs
nos simulations, cette solution assure un basculement sans pertes. La transmission est
suspendue le temps de raliser le basculement ; les donnes sont mises en attente. Ceci a
pour consquence d'augmenter lgrement les dlais de transmission et l'engorgement
184
Conclusion Gnrale
du rseau.
Le troisime chapitre de cette thse traite du basculement entre technologies d'accs diffrentes. Dans le cadre de cette tude, nous nous sommes focaliss sur un basculement
entre une station de base et un point d'accs WLAN, intgr au mme BSS. Nous analysons les performances des basculements par handover et reslection. Pour rduire les
pertes au moment du basculement, nous proposons d'introduire une couche de convergence au niveau LLC. Les rsultats de nos simulations montrent les bnfices apports,
en terme de pertes, par l'activation d'un mcanisme de retransmission au niveau LLC.
Cela entrane cependant une augmentation sensible des dlais de transmission et une diminution du dbit utile.
La seconde partie de ce chapitre se focalise sur les stratgies de handover intra et inter
technologies d'accs dans le cas de trafic Streaming . Nous valuons les performances de la procdure de reslection pour diffrentes options d'empilement protocolaires. Nos rsultats montrent les pertes importantes qui peuvent rsulter de l'utilisation
du protocole UDP. Dans ce cas, nous proposons de mettre en place un mcanisme de retransmission au niveau LLC. Ce dernier viens limiter les pertes au moment du handover, mais augmente sensiblement l'engorgement et les dlais de transmission. Cette solution reste malgr tout plus avantageuse que l'utilisation du protocole TCP.
Le dveloppement de services multimdia travers un rseau d'accs radio ncessite de
mettre en place des protocoles de signalisation la fois lgers, performants et volutifs.
Le quatrime chapitre de cette thse analyse les solutions de compression pour la signalisation SIP, utilise dans l'architecture IMS. Ces solutions visent rduire la dure
d'mission des messages SIP sur l'interface radio. SIP est un protocole au format
texte . Dans ce chapitre, nous prsentons diffrentes solutions existantes pour la
compression de messages au format texte , puis nous proposons plusieurs approches
adaptes la compression des messages SIP. Ces solutions reposent sur l'utilisation d'un
dictionnaire, la maintenance d'un contexte de transmission, et la solution de compression DEFLATE. Notre analyse est base sur des traces d'tablissement de session SIP,
ralises sur un rseau exprimental.
3. Perspectives
3.1. 3G LTE
Le 3GPP mne actuellement une rflexion pour dfinir un systme de radio communication de nouvelle gnration. Le groupe de travail LTE Long Term Evolution - travaille
l'laboration d'un nouveau rseau d'accs : l'E-UTRAN Evolved UTRAN. Le groupe
SAE System Architecture Evolution traite quant lui des volutions de l'architecture
du rseau coeur. La technologie d'accs sera base sur une modulation OFDM. L'architecture E-UTRAN est prsente sur la figure 3.1.1 [3GPP 36.300]. La conception du r185
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
seau d'accs sera totalement diffrente de ce qui existe dans les rseaux GPRS / UMTS.
Les contrleurs de stations de bases (BSC / RNC) vont disparatre et leurs fonctions de
contrle seront ramenes au niveau des stations de base, rebaptises eNodeB Evolved
NodeB. Celles-ci seront relies entre elles par un rseau de transport IP. Un quipement
MME/UPE Mobility Management Entity / User Plane Entity remplacera le SGSN.
3.2. Au del de la 3G
L'architecture des rseaux de future gnration (B3G / 4G) reste dfinir. Les travaux
actuels ne s'orientent cependant pas vers un systme unique, mais plutt vers la coexistence de technologies d'accs multiples. Le GSM est dj utilis pour assurer la
continuit de services UMTS en dehors des zones couvertes par les technologies 3G.
Les systmes WIFI et WIMAX peuvent tre utilises pour accder l'Internet haut dbit
sans fil. Des architectures d'interconnexion et d'inter fonctionnement entre diffrents rseaux sont tudies par diffrents groupes de normalisation, comme l'IEEE et le 3GPP
[3GPP 23.234]. Le problme du handover entre rseaux d'accs de technologies diffrentes constitue le prochain dfit relever pour offrir une relle continuit de service
aux utilisateurs. Le groupe IEEE 802.21 [802.21] s'attache rsoudre le problme de la
prparation du handover : diffusion des informations de configuration de l'environnement radio multi-technologies, dfinition de primitives pour la prise de dcision et le
dclenchement des handovers. Les procdures de reslection ou de handover qui de186
Conclusion Gnrale
vront tre mises en places ne sont cependant pas encore dfinies. Plusieurs procdures
seront vraisemblablement dfinies en fonction de la qualit de service requise par l'application, de l'architecture du rseau, des capacits du mobiles et des contraintes radio.
187
189
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Type of channel
f ull rate speech TCH
enhanced f ull rate speech TCH
5,6
12,2
10,2
7,95
7,4
6,7
5,9
5,15
4,75
7,95
7,4
6,7
5,9
5,15
4,75
43,5
32,0
29,0
14,5
12,0
3,6
PDTCH/F (CS-1)
9,05
PDTCH/F (CS-2)
13,4
PDTCH/F (CS-3)
15,6
PDTCH/F (CS-4)
21,4
PDTCH/H (CS-1)
4,53
PDTCH/H (CS-2)
6,7
PDTCH/H (CS-3)
7,8
PDTCH/H (CS-4)
10,7
PDTCH/F (MCS-1)
10,6
PDTCH/F (MCS-2)
13
PDTCH/F (MCS-3)
16,6
PDTCH/F (MCS-4)
19,4
PDTCH/F (MCS-5)
24,05
PDTCH/F (MCS-6)
31,25
PDTCH/F (MCS-7)
47,45
PDTCH/F (MCS-8)
57,05
PDTCH/F (MCS-9)
61,85
PDTCH/H (MCS-1)
5,3
PDTCH/H (MCS-2)
6,5
PDTCH/H (MCS-3)
8,3
PDTCH/H (MCS-4)
9,7
PDTCH/H (MCS-5)
12,03
PDTCH/H (MCS-6)
15,63
PDTCH/H (MCS-7)
23,73
PDTCH/H (MCS-8)
28,53
PDTCH/H (MCS-9)
30,93
190
Dans les modles de chanes de Markov moduls, les coefficients et peuvent tre
moduls de faon ce que le taux darriv varie au cours du temps. La valeur des coefficients et est alors dfinie par une seconde chane de Markov. Si on prend une
chane de Markov deux tats avec des transitions 1 et 2, on obtient l'automate reprsent sur le figure 1.2.
La ralisation dun processus MMPP conduit combiner les deux processus, de taille
respective N et M, afin de construire un processus rsultant qui sera de taille NM.
191
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Ce type de processus permet de modliser des processus qui ne gnrent aucun trafic
pendant une certaines priode, puis un trafic plus dense, mais pas forcment continu,
pendant dautres priodes. Les IPP permettent de produire des modles de trafic pour
des flux de donnes de type HTTP. Ces flux de trafic sont en effet caractriss par la gnration de trafic paquet lorsquun utilisateur demande le tlchargement dune page et
par une absence de trafic lorsque lutilisateur consulte la page quil vient de tlcharger.
La figure 2.2 reprsente un exemple de profil de trafic gnr partir d'une IPP deux
tats (marche/arrt) pour un utilisateur qui effectue plusieurs sessions de trafic successives.
192
193
195
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
196
197
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
duite. Cette pile est la fois stocke au sein du paquet IP et insre dans un objet PileBloc qui gre la pile de transmission des BlocRLC.
La segmentation d'un Paquet IP consiste le dcouper en bloc de taille fixe, dpendant
du dbit/slot que supporte le mobile sur l'interface Air. Un en-tte de taille fixe est ajout aux blocs lors de la segmentation. La taille de cet en-tte est dfinit par la variable
Simulateur.EN_TETE_RLC_MAC .
Lobjet PileBloc contient deux piles : une pile de blocs envoyer et une pile de blocs en
attente dacquittement. Les blocs en attente dacquittement sont ceux qui ont t envoys mais qui nont pas t acquitts par le rcepteur.
Lorsque le rcepteur reoit un bloc, il lacquitte. Le bloc est alors supprim de la pile
dmission de lmetteur. Dans le cas du simulateur avec bufferisation , si le rcepteur est une BTS, le bloc est simplement plac dans la pile dmission vers lquipement
suivant : vers le BSC si la transmission se fait dans le sens montant, vers le mobile dans
le cas contraire.
Le rcepteur Mobile ou BSC qui reoit un bloc lacquitte puis marque le bloc
comme reu dans le paquet IP. Lorsque le nombre de blocs reus atteint le nombre de
blocs segments, le paquet est considr comme totalement reu.
On notera ici que, contrairement au paquets IP, les blocs nont pas de date de premption. Une fois segments, les paquets sont envoys, mme si leur date de premption arrive chance.
198
Les interface Air et Abis grent trois types de ressources : les ressources ddies, les
ressources partages et les ressources mixtes. Les ressources ddies sont des ressources
qui sont attribues exclusivement des mobiles pour faire de la transmission en mode
circuit. Cest typiquement des ressources qui seront rserves des mobiles pour faire
du trafic vocal. Les ressources partages sont destines tre partages entre les diffrents utilisateurs pour faire du trafic de donnes en mode paquet. Les ressources
mixtes sont, galement destines couler majoritairement du trafic de donnes en
mode paquet mais elles peuvent tre premptes au besoin par le systme pour couler
du trafic vocal lorsque le nombre de ressources ddies est insuffisant.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
positionnes au niveau des mobiles, que ce soit dans le sens montant ou dans le sens
descendant. La figure 2.1.1 fournie un descriptif du systme. Il s'agit d'une prsentation
logique pour le stockage des contextes, la transmission effective des paquets s'effectuant
du mobile vers le BSC pour le sens montant, et inversement.
Dans l'approche avec bufferisation , le positionnement des piles dpend du sens de
transmission. Toutes les explications qui suivent sont reprises sur la figure 2.1.2.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Pour le sens montant, la pile dmission des paquets IP se trouve dans le mobile. Une
pile dmission de bloc RLC/MAC se trouve galement dans le mobile, et une autre
dans la BTS pour assurer la bufferisation des paquets en attendant leur transmission.
Pour le sens descendant, une pile de paquets IP et une pile de blocs RLC/MAC en direction de chaque BTS devrait tre implment dans le BSC ; et une seconde pile de blocs
RLC/MAC devrait tre implment au niveau des BTS. Dans le simulateur, la gestion
des contextes fait que la pile de paquets IP dans le sens descendant est implmente au
niveau de la BTS. Les piles de blocs RLC/MAC sont implmentes dans les BTS pour
la transmission BSC vers BTS et dans les mobiles pour la transmission BTS vers mobiles.
202
Certains vnements, comme par exemple les mobiles, possdent leur propre pile d'vnements interne. Il y a donc plusieurs piles d'vnements dans le simulateur. Cela introduit plus de souplesse dans le sens o les piles d'vnements sont plus courtes, donc
plus facile grer et que tous les vnements qui concernent un mobile donn sont regroup dans une mme pile.
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
niers sont activs lors de lappel du constructeur du mobile. Cette activation ralise en
ralit une copie des diffrents gnrateurs de donnes et les initialises.
204
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
tement transmis (et dans ce cas, il est livr au rcepteur ) ou est perdu (dans ce cas, le
bloc en erreur n'est pas livr et c'est l'metteur qui dclenchera la r-mission du fait
qu'il n'a pas reu d'acquittement).
Le contrle de la retransmission consiste vrifier qu lissu de la priode de transmission, tous les blocs ont bien t acquitts. Si, pour chaque metteur, la pile des blocs en
attente dacquittement nest pas vide, un compteur est initialis. Ce compteur est dcrment la fin de chaque priode de 20 millisecondes. Lorsque ce compteur atteint la valeur nulle, lensemble des blocs qui nont pas t acquitts est rintroduit en tte de la
pile des blocs transmettre. La valeur initiale du compteur correspond la constante
Simulateur.INTER_ACK .
Distribution des droits de transmission
La distribution des droits de transmission appels galement jetons est la phase qui
assure le partage des ressources de linterface Abis entre les diffrentes BTS et des ressources des interfaces Air entre les diffrents mobiles. L'algorithme de distribution des
jetons dpend du type d'approche utilis.
Approche microcircuit
Lalgorithme de distribution des droits de transmission est assez simple. Dans un premier temps, le BSC rparti les jetons entre les diffrentes BTS au prorata du nombre
ressources data disponibles sur les interfaces Air. Les jetons sont alors envoys aux
BTS qui les redistribuent aux mobiles en fonction de leur capacits. Si le nombre de jetons est insuffisant pour utiliser plein les capacits dun mobile, les jetons sont redonnes au BSC. A lissu de cette phase, les jetons qui nont pas t utiliss sont distribus
aux BTS en fonction de leurs besoins. Cette distribution consiste prendre une BTS au
hasard, lui donner tous les jetons restant, puis de rcuprer les jetons quelle na pas utilis pour les donner la BTS suivante
Cette distribution en deux temps au prorata du nombre de ressources disponibles puis
sous forme de round robin permet dimplmenter un mcanisme qui soit assez simple
et rapide pour ne pas trop augmenter le temps de simulation.
Approche avec bufferisation
La distribution des jetons sur linterface Abis s'effectue en plusieurs phases. Le BSC
commence par rcuprer des informations sur les diffrentes BTS : nombre de slots data
sur linterface Air et nombre de blocs en attente de transmission. Une premire rpartition des ressources disponibles sur linterface Abis est alors effectue au prorata du
nombre de slots data utilises sur chacune des interface Air et en fonction des besoins
de chaque BTS. Les ressources non attribues sont alors rparties de faon gale entres
les BTS qui ont des blocs transmettre. Les jetons sont alors effectivement alloues
206
207
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
208
209
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Plusieurs scripts ont t raliss afin de faciliter la manipulation des diffrents lments
du projet dans un environnement Windows. Les scripts permettent de compiler et
dexcuter le projet, de gnrer les documentations du simulateur et de mettre en place
un systme de sauvegarde.
Le script compile permet de compiler lensemble du projet. Les fichiers .class
rsultant de cette compilation sont placs dans le rpertoire classes .
Le script lanceur excute la simulation pralablement compile et dvie laffichage
de sortie vers un fichier de log, dat et plac dans le rpertoire mesures . Le script
lanceur2 excute la simulation sans dtourner laffichage. On utilisera lun ou lautre
de ces lanceurs en fonction de la simulation lance et des besoins de dbogage de la simulation. On notera galement quil est ncessaire dadapter le script lanceur en
fonction du systme dexploitation Windows utilis.
Le script Jdoc gnre la documentation Java du simulateur. La documentation est
alors gnre dans le rpertoire doc de larborescence de dveloppement.
Enfin, le script sauvegarde ralise une copie du rpertoire src (sources) dans le
rpertoire backup_simu . Le nom du rpertoire source est alors modifi pour contenir
la date de la sauvegarde. Tout comme le script lanceur , ce script doit tre modifi en
fonction de la version de Windows utilise.
210
211
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
La figure 1.1 prsente le droulement d'un change de blocs RLC conformment au processus dcrit dans la partie . A titre d'illustration, nous avons considr un espace de numrotation de 8 blocs (SNS=8), ce qui permet une fentre d'mission d'au maximum 4
blocs (WS=4). On considre un transfert de 10 blocs RLC (de l'metteur vers le rcepteur) et les acquittements correspondants. Le TBF considr permet de transmettre 3
blocs de donnes en mission avant de recevoir un bloc d'acquittement. Ces hypothses
sont bien entendu simplificatrices mais permettent de reprsenter le mcanisme d'change.
L'intgralit de l'change est prsent : les tats de l'metteur et du rcepteur sont donc
initialiss 0. Les vecteurs V(B) et V(N) comportent 8 positions correspondant aux 8
blocs de l'espace de numrotation. Pour V(B), l'tat 0 correspond un bloc non acquitt
et l'tat 1 un bloc acquitt. Pour V(N), ces tats correspondent des blocs non reus
ou reus. Seul 4 blocs sont considrs un instant donn : les blocs correspondants la
fentre d'mission ou de rception. Pour faciliter la lecture de la figure, les bits correspondant dans V(B) et V(N) ont t mis en gras .
La transmission dbute par 3 blocs qui sont transmis puis immdiatement acquitts.
V(S) est incrment lors de la transmission d'un bloc et V(R) lors de sa rception.
Comme il n'y a pas de trou dans la squence, V(Q) est galement incrment : la fentre
de rception V(N) se dcale alors d'une position.
A la rception du premier acquittement, l'metteur est mis au courant que le rcepteur
attend le bloc n3 et que tous les blocs qui le prcdent ont t correctement reus. V(A)
prend alors la valeur 3 - l'metteur attend dsormais l'acquittement du bloc n3 - et la fentre d'mission V(B) volue en consquence.
La perte du bloc n4 produit un trou dans la squence de rception. A la rception du
bloc n5, V(Q) reste bloqu 4 tandis que V(R) passe 6. Par contre, dans le vecteur
V(N), le bloc n4 est marqu comme tant non reu . L'acquittement envoy indique
alors que le bloc n6 est en attente de transmission et que le bloc n4 n'a pas t correctement reu (les 4 bits du RBB correspondent l'tat de rception des blocs n5 2).
A la rception de cet acquittement, l'metteur renvoie le bloc 4 puis reprend la transmission l o elle en tait en transmettant les blocs 6 et 7. La perte de l'acquittement suivant
entrane le blocage de la fentre : V(S) a atteint la valeur V(A)+WS. L'metteur, en attendant de recevoir un acquittement, fait de la retransmission cyclique prventive en reprenant la transmission des blocs non acquitts partir de V(A). Il renvoie donc les
blocs n4, 6 et 7 (le bloc n5 ayant t correctement transmis et ayant t acquitt prcdemment). Ces blocs sont ensuite nouveau acquitts par le rcepteur : ce dernier dtecte la ncessit d'envoyer un acquittement du fait qu'il reoit des blocs qu'il a prcdemment reu (transmissions dupliques).
Il reste 2 blocs transmettre : l'metteur les envois dans les 2 premiers slots disponibles.
N'ayant rien transmettre dans le troisime slot, l'metteur fait de la retransmission cyclique prventive en envoyant nouveau le bloc n0. Les blocs sont ensuite acquitts
par le rcepteur, ce qui termine la transmission.
212
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
ci a t mis avant leur rception par l'quipement n2. La trame N(S)=m+4 est perdue
au cours de la transmission. A la rception de la trame N(S)=m+5, le rcepteur n'incrmente pas V(R) mais mmorise tout de mme la bonne rception de la trame.
A la rception de la trame N(S)=m+3, l'quipement n2 note la bonne rception de la
trame N(S)=n en incrmentant la variable V(A). De mme, la rception de la trame
N(S)=n+1, l'quipement n1 enregistre la bonne rception des trames N(S)=m
N(S)=m+2 en affectant la variable V(A) la valeur m+3.
L'quipement n1 n'a, ce stade, pas connaissance de la perte de la trame N(S)=m+4, il
continu donc son transfert en mettant les trames N(S)=m+6, m+7 et m+8. L'quipement n2, quand lui, a dtect un trou dans la squence de rception. Il va donc
mettre une trame I+S qui va contenir un bitmap d'acquittement (SACK). N(R)=m+4
acquitte la bonne rception de la trame N(S)=m+3. Le premier bit du SACK est positionn 0, ce qui indique que la trame N(S)=m+4 a t perdue ; le second bit est positionn 1, ce qui indique que la trame N(S)=m+5 a t correctement reue.
A la rception de cette trame, le rcepteur n2 devrait normalement r-mettre la trame
N(S)=m+4 puis continuer normalement sa transmission en attendant un nouvel acquittement. Dans l'change prsent ici, la trame N(S)=n+2 est cependant perdue au cours de
la transmission...
L'quipement n2 n'a toujours pas reu le message N(S)=m+4. Il renvoie alors une
trame I+S dans lequel il indique que les trames N(S)=m+5 m+8 ont t correctement
reues mais que le message N(S)=m+4 est toujours manquant. L'quipement n1, qui n'a
toujours pas reu d'acquittement (et donc ignore toujours la perte du message
N(S)=m+4) continu sa transmission en envoyant la trames N(S)=m+9. Ensuite, le temporisateur T201 de la trame N(S)=m+4 expire. L'quipement n1 renvoie alors la trame
N(S)=m+4. Le temporisateur T201 de la trame N(S)=m+5 expire son tour : l'metteur
n2 renvoie donc galement cette trame.
L'arrive de la trame N(S)=n+3 au niveau de l'quipement 2 permet d'acquitter la bonne
rception des trames N(S)=m+5 m+8. Si cet acquittement n'tait pas arriv, il y aurait
eu expiration successive des temporisateur T201 associs ces trames, ce qui aurait
entran leur rmission. La transaction devrait alors se poursuivre ainsi : l'quipement 1
transmet les trames N(S)=m+10 et suivantes en indiquant que la trame N(S)=n+2 est
manquante. L'quipement 2, quand lui, va transmettre la trame d'information
N(S)=n+4 qui va indiquer qu'il est en attente de la trame N(S)=m+10. Par la suite, et
aprs rception de la trame N(S)=m+10, il renverra la trame N(S)=m+2 manquante.
214
Dans le systme GSM, on peut distinguer 5 types de handover [3GPP 23.009] (Cf. figure 1) : intra-cellulaire, inter-cellulaire/intra BSC, inter-BSC/intra MSC, inter-MSC et
les handover subsquents.
215
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le handover intra-cellulaire est utilis pour attribuer au mobile une autre ressource que
celle o il opre, mais sans changer de cellule. Ce handover a t initialement dfinit
pour permettre au mobile de changer la frquence sur laquelle il opre lorsque celle-ci
est brouille. L'utilisation de techniques de saut de frquences diminue cependant le recours ce type de handover. Le handover intra-cellulaire peut galement tre utilis pour
rorganiser les ressources dans la cellule, et permettre par exemple de librer plusieurs
slots adjacents afin de les affecter pour un service GPRS.
Dans le handover inter-cellulaire/intra-BSC, le mobile migre vers une cellule sous le
contrle du mme BSC. Lorsque le BSC prend la dcision de handover, il rserve des
ressources pour le mobile dans la cellule cible. Il envoie ensuite une commande de handover au mobile. Ce dernier bascule alors vers la nouvelle cellule, sur la ressource qui
lui est indiqu. Il ralise alors un accs via un burst court qui permet au BSC de dtecter
le basculement. Ce dernier commute alors la communication vers la nouvelle cellule et
libre les ressources de l'ancienne cellule.
La philosophie du handover inter-BSC/intra MSC reste la mme. Le BSC de la cellule
dans laquelle se trouve le mobile prend la dcision de handover. Il contacte alors le
MSC afin que ce dernier contacte le BSC de la cellule cible et rserve les ressources
ncessaires au basculement. Une fois la rservation effectue, le MSC prvient le BSC
cible que le handover peut tre dclench. Une fois que le mobile a bascul, le BSC de
la nouvelle cellule prvient le MSC qui commute la communication vers le nouveau
BSC et la nouvelle cellule.
Le handover inter-MSC ncessite l'tablissement d'un circuit entre les deux MSC pour
relayer la communication. Le MSC sur lequel l'appel a t initialement tabli est appel
MSC ancre. Le MSC qui relaye l'appel est appel MSC-relais. Une fois que le mobile a
bascul, le MSC ancre commute la communication de l'ancien BSC vers le MSC relais.
Ce dernier commute alors la communication vers le nouveau BSC. Le MSC ancre
conserve le contrle global de la communication jusqu' ce que l'appel se termine. En
particulier, le MSC ancre conserve le contrle de la facturation de l'appel et, d'un point
de vue fonctionnel, le mobile reste localis sous le MSC ancre. A l'issu de l'appel, le
mobile devra donc procder une mise jour de localisation.
Le handover subsquent est un handover inter-MSC qui a lieu alors qu'un handover
inter-MSC a dj eu lieu. Dans ce cas, c'est encore le MSC ancre qui contrle le handover et tablit un circuit vers le nouveau MSC relais. Le handover subsquent s'effectue
donc suivant le mme principe que le handover inter-MSC, les MSC relais n'ayant qu'un
rle passif dans le contrle du processus de handover.
216
Mcanisme de retransmission
TCP est un protocole a transmission de segments. Un segment tant un flux d'octets qui
peut tre segment par les quipements intermdiaires. Le mcanisme de retransmission
utilis par TCP est un mcanisme de transmission de type fentre glissante avec
acquittement non slectif. Les acquittements sont transmis au sein de trames TCP
suivant le principe du piggy backing .
Plusieurs variables sont utiliss du cot metteur et rcepteur pour caractriser chaque
liaison (une liaison tant caractrise par une adresse IP et un numro de port). Les donnes transmises sont identifies par le numro de squence correspondant au premier
octet transmis dans le segment.
217
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
La taille des numros de squence est cod sur 32 bits. La taille des fentres est cod sur
16 bits et volue suivant l'tat de congestion du rseau.
Un segment est valide si RCV.NXT SEG.SEQ < RCV.NXT+RCV.WND et RCV.NXT SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND.
Un acquittement est
RCV.NXT+RCV.WND.
valide
si
RCV.NXT
SEG.SEQ+SEG.LEN-1
<
Le mcanisme de retransmission TCP est rgul par un temporisateur : RTO Retransmission Time Out. Si au bout du RTO, un segment na pas t acquitt, il sera rexpdi. TCP ne prendra donc pas linitiative de retransmettre le paquet avant lexpiration de
ce temporisateur.
On notera que lacquittement slectif (SACK) nest pas voqu dans [RFC 793] (protocole TCP de base). Il est donc fort probable que plusieurs squences soient retransmises
inutilement au cours du processus de retransmission. De mme, le squenage tant gr
octet par octet, cela entrane la transmission dun surcrot dinformation par rapport
une transmission qui serait gr trame par trame, comme au niveau LLC.
218
Cet change [Ros03] est un exemple de transmission avec perte d'un segment TCP. TCP
est un protocole de transmission qui gre un flux d'octets. Dans chaque segment, le protocole peut transmettre jusqu' MSS Maximum Segment Size - octets (la valeur du
MSS tant fixe l'ouverture de la connexion). Au dpart, N octets, sont transmis (N
MSS). M octets supplmentaires parviennent ensuite la couche TCP, qui les envoie
sur le rseau (MMSS). Ces M octets sont perdus et ne parviennent pas au rcepteur. A
la rception des N premiers octets, le rcepteur acquitte la rception des N premiers
octets (en indiquant l'metteur qu'il est en attente des octets X+N+1). L'metteur envoie par la suite K octets supplmentaires (MMSS). Lorsqu'il les reoit, le rcepteur
envoie un acquittement qui indique qu'il n'a toujours pas reus les octets suivant X+N.
Au bout du temps RTO, l'metteur n'ayant toujours pas reu d'acquittement, il retransmet MSS octets partir de X+N+1. Le segment ainsi retransmis contient les M octets
prcdemment perdus. Quand il les reoit, le rcepteur acquitte avoir reu les M octets
en question, ainsi que les K suivants.
Ce principe de gestion de flux d'octets permet de retransmettre les donnes partir de la
squence qui a t perdue. Il offre la possibilit aux quipements intermdiaires de segmenter les paquets TCP sans pour autant venir perturber le mcanisme de retransmission. Cet aspect tant illustr sur la figure 1.
219
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
220
1. Handover inter-SGSN
Cette partie dcrit la procdure de handover inter-SGSN [3GPP 43.129].
Phase de prparation du handover
La phase de prparation du handover inter-SGSN (Cf. figure 1.1)commence par la prise
de dcision du handover (1) et la demande de prparation du handover auprs du SGSN
(2). Le SGSN (not sur la figure old SGSN ) dtecte que la cellule cible est dservie
par un autre SGSN. Le SGSN contacte alors le SGSN cible (3) (not New SGSN ) et
lui transmet la liste des contextes PDP actifs ainsi que les contextes de mobilit qui
contiennent des clefs d'identification et de chiffrement.
221
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Les PDP contextes sont configurs au niveau du nouveau SGSN. Si le SGSN n'est pas
mme de supporter certains des SAPI utilis par un contexte PDP, il ne doit pas rserver
de ressources pour celui-ci. A la fin du basculement, le SGSN devra demander explicitement la modification ou la fermeture des PDP contextes concerns. Si le nouveau
SGSN ne supporte pas l'algorithme de chiffrement utilis par l'ancien SGSN, le nouveau
SGSN devra transmettre le nouvel algorithme la station mobile. Cela est fait au moment de la mise jour de zone de routage qui est effectue la suite du handover.
Le SGSN cible effectue alors la rservation de ressources dans le BSS cible (4, 5, 6 et 7)
puis il indique au SGSN initial que le handover peut tre dclench (8).
Phase d'excution du handover
Aprs la phase de prparation du handover, les PDU sont transmis au SGSN qui peut les
dupliquer et les transfrer jusqu'au nouveau SGSN (2) (Cf. figure 1.2).
Si la transmission est acquitt au niveau LLC, les trames LLC sont stockes au niveau
du SGSN avec leur numro de squence. Il faudra attendre la fin du handover pour rtablir la transmission. Si la transmission n'est pas acquitte, les trames LLC sont soit envoyes vers le BSS pour tres transmises (en aveugle) (3), soit stockes dans le SGSN,
soit ignores (et donc supprimes).
Le SGSN dclenche ensuite le handover (4), aprs avoir ventuellement suspendu la
transmission et attendu que le BSS ne contienne plus de donnes transmettre. Si
l'ordre de dlivrance des GTP-PDU doit tre prserv, le SGSN transfert les tats de
transmissions associs la couche GTP au nouveau SGSN (4a). Ce message requiert un
acquittement (4b).
Le BSC envoie ensuite la commande de handover au mobile (5) qui bascule alors vers
la nouvelle cellule et envoie un burst accs sur la ressource qui lui a t indique (6), ce
qui permet au rseau de calculer l'avance en temps et de l'indiquer au mobile (6). Si les
contexte de transmission au niveau LLC/SNDCP sont maintenus, une fois la connexion
rtablie avec le BSS, le mobile envoie un message afin de rtablir la connexion avec le
SGSN (7, 7a). Le mobile rtablit ensuite les transmissions associes aux contextes PDP
pour lesquels des ressources ont t rservs dans la nouvelle cellule.
Le nouveau BSC indique la fin du handover au nouveau SGSN (8). Le SGSN demande
alors la mise jour des contextes PDP associs au mobile auprs du GGSN. Celui-ci envoie alors directement les paquets GTP destination du nouveau SGSN (9).
Si les contextes de transmission au niveau LLC/SNDCP ont t rinitialiss, le SGSN
effectue une ngociation avec le mobile pour rtablir la transmission (10, 10a). Le
SGSN prviens ensuite l'ancien SGSN que les transmissions avec le mobile ont t rtablies (11). L'ancien SGSN arme alors un temporisateur au bout duquel il va cesser de
transfrer les donnes vers le nouveau SGSN. L'ancien SGSN prviens galement l'ancien BSS afin de librer les ressources associes au mobile (12).
222
La procdure ci dessus est prsent en squence. La plupart des actions peuvent cependant tre effectues en parallle. La procdure de mise jour (13 20) qui termine cette
procdure doit, en ralit, tre initie ds que le mobile a obtenu les informations d'avance en temps (6). Nous n'entrerons pas dans le dtail de cette procdure qui sort du
champ de ce document.
223
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
2.1. Mobile IP
Deux versions du protocole Mobile IP ont t dfinies : l'une [RFC 3344] pour la
version 4 du protocole internet (IPv4) et l'autre [RFC 3775] pour la version 6 (IPv6).
Ces deux protocoles sont trs proches dans leur principe, la version pour IPv6 exploitant
les capacits d'adressages plus importantes que permet le protocole.
permettre au mobile de ne pas demander une nouvelle adresse IP, cet quipement a
disparu dans la version IPv6 de la spcification.
225
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Grce au Foreign Agent , la station mobile n'a pas besoin de changer d'adresse IP.
Cela prsente un intrt certain pour les rseaux de type IPv4 o le nombre d'adresses
disponibles est limit.
226
Cette solution sans Foreign Agent ncessite un nombre d'adresses plus important
que la solution avec Foreign Agent puisque le mobile se voit attribuer deux adresses
IP. Cette solution est celle qui a t retenue dans le cadre d'IPv6.
2.2. Cellular IP
Le mcanisme Cellular IP [Val98][Val99][Rou02] a t conu pour offrir une solution de mobilit dans un sous rseau local. Ce mcanisme permet d'assurer la mobilit
d'un terminal qui change frquemment de point d'accs.
Cellular IP peut tre utilis seul, mais il a t essentiellement conu pour tre coupl
avec Mobile IP dans le cadre dune gestion hirarchique de la mobilit. Mobile
IP grant la macro-mobilit (mobilit entre domaines) et cellular IP reprenant une partie du concept cellulaire pour grer la micro-mobilit (mobilit l'intrieur d'un domaine).
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Le sous rseau doit tre mme de router les paquets de la passerelle jusqu la station
mobile. Pour cela, des tables de routage doivent tre maintenues dans quelques-uns
des noeuds du rseau (par forcment tous).
La passerelle met priodiquement un signal balise (beacon signal) qui va tre transmis
de station en station. Chaque station qui implmente une table de routage indique partir de quel port dentre elle a reu le paquet et r-met le paquet vers tous les ports de
sortie. Cela permet dtablir quel est la route la plus courte, en terme de dlai de traverse du rseau, pour atteindre chacun des quipements.
Quand un mobile souhaite mettre des donnes vers le rseau, il commence par envoyer
un message de signalisation lintention de la passerelle. Ce paquet permet dtablir la
route quempruntera tous les paquets envoys par le mobile. Chaque station implmentant une table de routage doit alors ajouter une entre dans sa table indiquant ladresse
IP du mobile et ladresse de lquipement partir duquel le paquet a t reu.
Pour pouvoir grer plus facilement les aspects de mobilit, deux tables sont en ralit
implments dans les quipements qui assurent le routage. Le Paging Cache et le
Routing Cache .
Le Paging Cache permet de connatre grossirement la position du mobile afin
de pouvoir lui demander de se signaler lorsque des donnes doivent lui tre transmises.
Le Paging Cache doit tre mis jour suivant une priode de lordre de la
frquence de migration des mobiles . Ses entres ne sont valables que pendant une
priode appele PC-timeout . Ce cache nest pas forcment implment dans tous les
quipements qui assurent le routage. Les mobiles en veille doivent mettre priodiquement des messages paging-update packet .
Le Routing Cache permet de router prcisment les paquets jusquau mobile. Ce
cache doit tre prsent dans un plus grand nombre dquipements. La route qui se
trouve dans le Routing Cache est tablie grce au routage des paquets dans le sens
mobile vers la passerelle . En renversant la route, il est alors possible de router les
paquets dans le sens passerelle vers le mobile . La route nest tablie que pendant
une courte priode, le mobile doit donc envoyer rgulirement des donnes dans le sens
montant sil souhaite pouvoir continuer recevoir dans le sens descendant. En TCP,
cela se fait automatiquement grce lenvoie des acquittements, en UDP, le mobile doit
envoyer des messages routing-update afin dassurer la prennit de la route. Les ent228
res dans le routing cache sont automatiquement dtruites au bout dun temps RCtimeout .
La station mobile change de point d'accs et s'attache au noeud D (Cf. figure 2.2.2.2).
La station envoie alors un paquet destination de la passerelle afin d'tablir la route. Ce
paquet va transiter par les noeuds D, C et A. Seul les noeuds D et C vont mettre jour
leur table de routage. Le noeud C va maintenir et transmettre les paquets vers les deux
routes (vers les points d'accs G et D) le temps que la liaison C, E, G expire (au bout du
temps d'inactivit RC-timeout ).
Au final, l'expiration de la route C, E, G, le rseau arrive la situation dcrite sur la figure 2.2.2.3.
229
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Dans Cellular IP , les pertes de donnes sont dues aux paquets transmis sur l'ancienne route alors que le mobile a chang de point d'accs et que la nouvelle route n'a
pas t rtablie.
230
2. 407
SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000073fa00000038;received=137.194.3.73..From: "unknown"<sip:test2@sip.enst.fr>;tag=66462515062..To:
<sip:0616771297@137.194.3.73>;tag=as5448b713..Call-ID: 878868ED-AD654A74-9D66-37DAB3FC72F6@137.194.3.73..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY..Contact: <sip:0616771297@137.194.16.250>..Proxy-Authenticate:
Digest realm="asterisk", nonce="5fa439a3"..Content-Length: 0....
3. ACK
ACK sip:0616771297@137.194.3.73 SIP/2.0..Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000073fa00000038..Content-Length: 0..Call-ID: 878868ED-AD65-4A74-9D66-37DAB3FC72F6@137.194.3.73..CSeq: 1 ACK..From: "unknown"<sip:test2@sip.enst.fr>;tag=66462515062..Max-Forwards: 70..To:
231
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
<sip:0616771297@137.194.3.73>;tag=as5448b713..User-Agent:
SJphone/1.60.289a (SJ Labs)....
4. INVITE
INVITE sip:0616771297@137.194.3.73 SIP/2.0..Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000003f500000
039..Content-Length: 337..Contact:
<sip:test2@137.194.3.73:5060>..Call-ID: 878868ED-AD65-4A74-9D66-37DAB3FC72F6@137.194.3.73..Content-Type: application/sdp..CSeq: 2 INVITE..From: "unknown"<sip:test2@sip.enst.fr>;tag=66462515062..Max-Forwards: 70..To: <sip:0616771297@137.194.3.73>..User-Agent:
SJphone/1.60.289a (SJ Labs)..Proxy-Authorization: Digest
username="test2",realm="asterisk",nonce="5fa439a3",uri="sip:0616771297
@137.194.3.73",response="65c0ebd0dcfe73e5bf367cd44ad2118b"....v=0..o=3359434714 3359434714 IN IP4 137.194.3.73..s=SJphone..c=IN IP4
137.194.3.73..t=0 0..a=direction:active..m=audio 49156 RTP/AVP 3 97 98
8 0 101..a=rtpmap:3 GSM/8000..a=rtpmap:97 iLBC/8000..a=rtpmap:98
iLBC/8000..a=fmtp:98 mode=20..a=rtpmap:8 PCMA/8000..a=rtpmap:0
PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-11,16..
5. TRYING
SIP/2.0 100 Trying..Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000003f500000
039;received=137.194.3.73..From:
"unknown"<sip:test2@sip.enst.fr>;tag=66462515062..To:
<sip:0616771297@137.194.3.73>..Call-ID: 878868ED-AD65-4A74-9D66-37DAB3FC72F6@137.194.3.73..CSeq: 2 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY..Contact: <sip:0616771297@137.194.16.250>..Content-Length:
0....
6. 200OK
SIP/2.0 200 OK..Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000003f500000
039;received=137.194.3.73..From:
"unknown"<sip:test2@sip.enst.fr>;tag=66462515062..To:
<sip:0616771297@137.194.3.73>;tag=as221eaabf..Call-ID: 878868ED-AD654A74-9D66-37DAB3FC72F6@137.194.3.73..CSeq: 2 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY..Contact: <sip:0616771297@137.194.16.250>..Content-Type: application/sdp..Content-Length: 265....v=0..o=root 3644 3644 IN IP4
137.194.16.250..s=session..c=IN IP4 137.194.16.250..t=0 0..m=audio
12254 RTP/AVP 3 0 8 101..a=rtpmap:3 GSM/8000..a=rtpmap:0
PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephoneevent/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -..
232
7. ACK
ACK sip:0616771297@137.194.16.250 SIP/2.0..Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000012bf00000
03c..Content-Length: 0..Call-ID: 878868ED-AD65-4A74-9D66-37DAB3FC72F6@137.194.3.73..CSeq: 2 ACK..From: "unknown"<sip:test2@sip.enst.fr>;tag=66462515062..Max-Forwards: 70..To:
<sip:0616771297@137.194.3.73>;tag=as221eaabf..User-Agent:
SJphone/1.60.289a (SJ Labs)....
8. BYE
BYE sip:test2@137.194.3.73:5060 SIP/2.0..Via: SIP/2.0/UDP
137.194.16.250:5060;branch=z9hG4bK18aa9ece;rport..From:
<sip:0616771297@137.194.3.73>;tag=as221eaabf..To:
"unknown"<sip:test2@sip.enst.fr>;tag=66462515062..Contact:
<sip:0616771297@137.194.16.250>..Call-ID: 878868ED-AD65-4A74-9D66-37DAB3FC72F6@137.194.3.73..CSeq: 102 BYE..User-Agent: Asterisk PBX..MaxForwards: 70..Content-Length: 0....
9. 200OK
SIP/2.0 200 OK..Via: SIP/2.0/UDP 137.194.16.250:5060;rport=5060;received=137.194.16.250;branch=z9hG4bK18aa9ece..Content-Length: 0..Call-ID:
878868ED-AD65-4A74-9D66-37DAB3FC72F6@137.194.3.73..CSeq: 102
BYE..From: <sip:0616771297@137.194.3.73>;tag=as221eaabf..Server: SJphone/1.60.289a (SJ Labs)..To:
"unknown"<sip:test2@sip.enst.fr>;tag=66462515062....
233
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
2. 407
SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP
137.194.3.76;rport;branch=z9hG4bK89c224a90000004e4490334100005c3200000
0f0;received=137.194.3.76..From:
"unknown"<sip:test1@sip.enst.fr>;tag=1321520914..To:
<sip:0609365123@137.194.36.169>;tag=as3221e3e1..Call-ID: F5337719913E-41CD-8381-3772340A7DAF@137.194.36.169..CSeq: 1 INVITE..UserAgent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY..Contact: <sip:0609365123@137.194.16.250>..Proxy-Authenticate: Digest realm="asterisk", nonce="1166f92c"..Content-Length:
0....
3. ACK
ACK sip:0609365123@137.194.36.169 SIP/2.0..Via: SIP/2.0/UDP
137.194.3.76;rport;branch=z9hG4bK89c224a90000004e4490334100005c3200000
0f0..Content-Length: 0..Call-ID: F5337719-913E-41CD-8381-3772340A7DAF@137.194.36.169..CSeq: 1 ACK..From: "unknown"<sip:test1@sip.enst.fr>;tag=1321520914..Max-Forwards: 70..To:
<sip:0609365123@137.194.36.169>;tag=as3221e3e1..User-Agent:
SJphone/1.60.289a (SJ Labs)....
4. INVITE
INVITE sip:0609365123@137.194.36.169 SIP/2.0..Via: SIP/2.0/UDP
137.194.3.76;rport;branch=z9hG4bK89c224a90000004e44903342000072b900000
0f1..Content-Length: 337..Contact:
<sip:test1@137.194.3.76:5060>..Call-ID: F5337719-913E-41CD-83813772340A7DAF@137.194.36.169..Content-Type: application/sdp..CSeq: 2
INVITE..From: "unknown"<sip:test1@sip.enst.fr>;tag=1321520914..MaxForwards: 70..To: <sip:0609365123@137.194.36.169>..User-Agent: SJphone/1.60.289a (SJ Labs)..Proxy-Authorization: Digest
username="test1",realm="asterisk",nonce="1166f92c",uri="sip:0609365123
@137.194.36.169",response="01659fc991d9684a5c709d8843a85ac0"....v=0..o
=- 3359289793 3359289793 IN IP4 137.194.3.76..s=SJphone..c=IN IP4
137.194.3.76..t=0 0..a=direction:active..m=audio 49168 RTP/AVP 3 97 98
8 0 101..a=rtpmap:3 GSM/8000..a=rtpmap:97 iLBC/8000..a=rtpmap:98
iLBC/8000..a=fmtp:98 mode=20..a=rtpmap:8 PCMA/8000..a=rtpmap:0
PCMU/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-11,16..
5. TRYING
SIP/2.0 100 Trying..Via: SIP/2.0/UDP
137.194.3.76;rport;branch=z9hG4bK89c224a90000004e44903342000072b900000
0f1;received=137.194.3.76..From:
"unknown"<sip:test1@sip.enst.fr>;tag=1321520914..To:
234
6. 200OK
SIP/2.0 200 OK..Via: SIP/2.0/UDP
137.194.3.76;rport;branch=z9hG4bK89c224a90000004e44903342000072b900000
0f1;received=137.194.3.76..From:
"unknown"<sip:test1@sip.enst.fr>;tag=1321520914..To:
<sip:0609365123@137.194.36.169>;tag=as4962e6ad..Call-ID: F5337719913E-41CD-8381-3772340A7DAF@137.194.36.169..CSeq: 2 INVITE..UserAgent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY..Contact: <sip:0609365123@137.194.16.250>..ContentType: application/sdp..Content-Length: 265....v=0..o=root 3644 3644 IN
IP4 137.194.16.250..s=session..c=IN IP4 137.194.16.250..t=0 0..m=audio
17334 RTP/AVP 3 0 8 101..a=rtpmap:3 GSM/8000..a=rtpmap:0
PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephoneevent/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -..
7. ACK
ACK sip:0609365123@137.194.16.250 SIP/2.0..Via: SIP/2.0/UDP
137.194.3.76;rport;branch=z9hG4bK89c224a90000004e449033420000441e00000
0f4..Content-Length: 0..Call-ID: F5337719-913E-41CD-8381-3772340A7DAF@137.194.36.169..CSeq: 2 ACK..From: "unknown"<sip:test1@sip.enst.fr>;tag=1321520914..Max-Forwards: 70..To:
<sip:0609365123@137.194.36.169>;tag=as4962e6ad..User-Agent:
SJphone/1.60.289a (SJ Labs)....
8. BYE
BYE sip:test1@137.194.3.76:5060 SIP/2.0..Via: SIP/2.0/UDP
137.194.16.250:5060;branch=z9hG4bK01391e4a;rport..From:
<sip:0609365123@137.194.36.169>;tag=as4962e6ad..To:
"unknown"<sip:test1@sip.enst.fr>;tag=1321520914..Contact:
<sip:0609365123@137.194.16.250>..Call-ID: F5337719-913E-41CD-83813772340A7DAF@137.194.36.169..CSeq: 102 BYE..User-Agent: Asterisk
PBX..Max-Forwards: 70..Content-Length: 0....
9. 200OK
SIP/2.0 200 OK..Via: SIP/2.0/UDP 137.194.16.250:5060;rport=5060;received=137.194.16.250;branch=z9hG4bK01391e4a..Content-Length: 0..Call-ID:
F5337719-913E-41CD-8381-3772340A7DAF@137.194.36.169..CSeq: 102
BYE..From: <sip:0609365123@137.194.36.169>;tag=as4962e6ad..Server: SJphone/1.60.289a (SJ Labs)..To:
235
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
"unknown"<sip:test1@sip.enst.fr>;tag=1321520914....
236
Ressources Documentaires
Ressources Documentaires
[Aji01] W. Ajib, P. Godlewski, Acknowledgment Procedures at Radio Link Control Level in GPRS, ACM/Baltzer Mobile Networks and Applications Journal/ Wireless Networks Journal (MONET/WINET) Kluwer edition, pp. 237 247, May 2001.
[Cam06] Gonzalo Camarillo, Miguel A. Garcia-martin, The 3G IP Multimedia Subsystem (IMS): Merging the Internet And the Cellular Worlds, John Wiley & Sons Inc,
fvrier 2006.
[Dai03] Nicolas Dailly, Dveloppement en Java dune Plate-forme Pdagogique GSM /
GPRS, Mmoire de fin d'tudes ingnieur et DEA, Telecom-Paris, ESIEE-Amiens, Universit de Technologie de Compigne, Juin 2003
[Dai05] Nicolas Dailly, Philippe Martins, Philippe Godlewski, Evaluation des performances de lAbis Dynamique pour E-GPRS, CFIP'05, Bordeaux, Mars 2005
[Dec04] Laurent Decreusefond, lments de thorie des files d'attente, Support de cours
de l'ENST, Paris, 2004-2005
[Dia04] Talal Achkar Diab, Philippe Martins, Comparison of Eifel and standard versions of TCP over GPRS in the presence of radio link disconnections, Rapport de
recherche, ENST-Paris, 2004
[EPIC01] Richard Price, Robert Hancock, Stephen McCann, Mark A West, Abigail Surtees, Paul Ollis, Signaling Compression for ROHC <draft-price-rohc-signaling-epic00.txt>, Internet Draft, Siemens, 2001
[Gal78] Robert G. Gallagher, Variations on a theme by Huffman. IEEE Transaction on
Information Theory, Novembre 1978, 668-674
[Hk06] Hkan Axelsson, Peter Bjrkn, Peter de Bruin, Stephan Eriksson, Hkan Persson, GSM/EDGE continued evolution, Ericsson review, janvier 2006.
[Ham05] Hamadoun I. Tour, Handbook Teletraffic Engineering, ITC, Janvier 2005
[Huff51] David Huffman, A method for the construction of minimum-redundancy codes,
Proceedings of the I.R.E., pp 1098-1102, septembre 1952.
[Jour03] Benjamin Jourdain, Probabilits et Applications, Ecole Nationale des Ponts et
Chausses, Marne-la-Valle, 2003. [http://cermics.enpc.fr/~jourdain/proba1a/poly-proba.pdf]
[Klem01] A. Klemm, C. Lindemann, and M. Lohmann, Traffic Modeling and Characterization for UMTS Networks, Globecom, Internet Performance Symposium, San An-
237
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Ressources Documentaires
[ITU-G.114] ITU-T Recommendation G.114, One way transmission time, May 2000
[3GPP 03.60] 3GPP TS 03.60 V7.9.0, 3rd Generation Partnership Project ; Technical
Specification Group Services and System Aspects ; Digital cellular telecommunications
system (Phase 2+) ; General Packet Radio Service (GPRS) ; Service description ; Stage
2 (Release 1998), septembre 2002
[3GPP 04.60] 3GPP TS 04.60 V8.26.0 ; 3rd Generation Partnership Project; Technical
Specification Group GSM/EDGE Radio Access Network ; General Packet Radio Service (GPRS) ; Mobile Station (MS) - Base Station System (BSS) interface ; Radio Link
Control/ Medium Access Control (RLC/MAC) protocol (Release 1999), janvier 2005
[GSM 04.64] 3GPP, TS 04.64 v8.7.0, General Packet Radio Service (GPRS); Mobile
Station Serving GPRS Support Node (MS-SGSN); Logical Link Control (LLC) layer
specification (release 99), Decembre 2001
[GSM 05.01] 3GPP, TS 05.01 v8.7.0, Technical Specification Group GSM/EDGE
Radio Access Network; Physical layer on the radio path; General description (release
99), Avril 2003
[GSM 08.04] 3GPP TS 08.04 V8.0.1, Technical Specification Group GSM/EDGE
Radio Access Network; Base Station System - Mobile-services Switching Centre (BSS MSC) interface Layer 1 specification (Release 99), Mai 2002
[GSM 08.20] 3GPP TS 08.20 V8.3.0, Technical Specification Group Core Network;
Digital cellular telecommunications system (Phase 2+); Rate adaption on the Base Station System Mobile-services Switching Centre (BSS - MSC) interface (Release 99),
Mars 2001
[GSM 08.51] 3GPP TS 08.51 V8.0.1, Technical Specification Group GSM EDGE
Radio Access Network; Base Station Controller - Base Transceiver Station (BSC - BTS)
interface; General aspects (Release 99), Mai 2002
[3GPP 22.105] 3GPP TS 22.105 V6.4.0 ; 3rd Generation Partnership Project ; Technical Specification Group Services and System Aspects ; Service aspects; Services and
service capabilities (Release 6), septembre 2005
[3GPP 23.002] 3GPP TS 23.002 V6.8.0 ; 3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Network architecture (Release
6), juin 2005.
[3GPP 23.009] 3GPP TS 23.009 V6.1.0 ; 3rd Generation Partnership Project ; Techni239
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
cal Specification Group Core Network and Terminals ; Handover procedures (Release
6), juin 2005
[3GPP 23.060] 3GPP TS 23.060 V6.11.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service
(GPRS); Service description; Stage 2 (Release 6), Dcembre 2005
[3GPP 23.234] 3GPP TS 23.234 V6.7.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP system to Wireless Local
Area Network (WLAN) interworking; System description (Release 6), Dcembre 2005
[3GPP 24.008] 3GPP TS 24.008 V6.11.0, 3rd Generation Partnership Project ; Technical Specification Group Core Network and Terminals ; Mobile radio interface Layer 3
specification ; Core network protocols ; Stage 3 (Release 6), Dcembre 2005
[3GPP 29.060] 3GPP TS 29.060 V6.11.0, 3rd Generation Partnership Project ; Technical Specification Group Core Network and Terminals ; General Packet Radio Service
(GPRS) ; GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 6),
Dcembre 2005
[3GPP 36.300] 3GPP TS 36.300 V0.9.0, 3rd Generation Partnership Project ; Technical Specification Group Radio Access Network ; Evolved Universal Terrestrial Radio
Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (EUTRAN) ; Overall description ; Stage 2 (Release 8), mars 2007.
[3GPP 43.129] 3GPP TS 43.129 V6.6.0, 3rd Generation Partnership Project ; Technical Specification Group GERAN ; Packet-switched handover for GERAN A/Gb mode ;
Stage 2 (Release 6), Janvier 2006
[3GPP 44.003] 3GPP TS 44.003 V6.1.0, 3rd Generation Partnership Project ; Technical Specification Group GSM EDGE Radio Access Network ; Mobile Station - Base
Station System (MS - BSS) Interface ; Channel Structures and Access Capabilities
(Release 6), Novembre 2004.
[3GPP 44.018] 3GPP TS 44.018 V6.16.0, 3rd Generation Partnership Project ; Technical Specification Group GSM/EDGE Radio Access Network ; Mobile radio interface
layer 3 specification ; Radio Resource Control (RRC) protocol (Release 6), janvier
2006.
[3GPP 44.060] 3GPP TS 44.060 V6.16.0, 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network, General Packet Radio
Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link
Control/Medium Access Control (RLC/MAC) protocol (Release 6), Janvier 2006
[3GPP 44.064] 3GPP TS 44.064 V6.1.0, 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Station - Serving GPRS Support Node
(MS-SGSN); Logical Link Control (LLC) layer specification; (Release 6), Septembre
2005
[3GPP 44.065] 3GPP TS 44.065 V6.4.0, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Station (MS) - Serving
GPRS Support Node (SGSN); Subnetwork Dependent Convergence Protocol (SNDCP);
(Release 6), Juin 2006
[3GPP 44.160] 3GPP TS 44.160 V6.5.0 ; 3rd Generation Partnership Project ; Techni240
Ressources Documentaires
cal Specification Group GSM/EDGE Radio Access Network ; General Packet Radio
Service (GPRS) ; Mobile Station (MS) - Base Station System (BSS) interface ; Radio
Link Control/Medium Access Control (RLC/MAC) ; protocol Iu mode (Release 6),
Juillet 2004.
[3GPP 45.001] 3GPP TS 45.001 V6.7.0; 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE ; Radio Access Network ; Physical layer on the
radio path ; General description (Release 6), Novembre 2005
[3GPP 45.002] 3GPP TS 45.002 V6.12.0, 3rd Generation Partnership Project ; Technical Specification Group GSM/EDGE ; Radio Access Network ; Multiplexing and multiple access on the radio path (Release 6), Novembre 2005
[3GPP 45.003] 3GPP TS 45.003 V6.9.0 ; 3rd Generation Partnership Project ; Technical Specification Group GSM/EDGE ; Radio Access Network ; Channel coding
(Release 6), Janvier 2006
[3GPP 45.008] 3GPP TS 45.008 V6.15.0, 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE; Radio Access Network; Radio subsystem link
control (Release 6), Novembre 2005
[ETSI TR 101 112] ETSI, TR 101 112 v3.2.0, Universal Mobile Telecommunications
System (UMTS); Selection procedures for the choice of radio transmission technologies
of the UMTS, Avril 1998.
[RFC 768] IETF, RFC 768, UDP ; User Datagram Protocol, IETF, Aout 1980
[RFC 791] IETF, RFC 791, IP ; Internet Protocol ; protocol specification, Septembre
1981
[RFC 793] IETF, RFC 793, TCP ; Transmission Control Protocol ; protocol specification, Septembre 1981
[RFC 1951] P. Deutsch - Aladin Entreprises, RFC 1951, DEFLATE Compressed Data
Format Specification version 1.3, Mai 1996.
[RFC 2327] Network Working Group, RFC 2327, SDP: Session Description Protocol,
Avril 1998.
[RFC 3261] Network Working Group, RFC 3261, SIP: Session Initiation Protocol,
IETF, Juin 2002.
[RFC 3320] Network Working Group, RFC 3320, Signaling Compression, IETF, janvier 2003
[RFC 3322] H. Hannu (Ericsson), RFC 3322, Signaling Compression (SigComp) Requirements & Assumptions, IETF, Janvier 2003
[RFC 3344] C. Perkins - Nokia Research Center, RFC 3344, IP Mobility Support for
Ipv4, IETF, Aout 2002
[RFC 3485] Network Working Group, RFC 3485, The Session Initiation Protocol (SIP)
and Session Description Protocol (SDP) Static Dictionary for Signaling Compression
(SigComp), IETF, Fvrier 2003.
241
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
[RFC 3775] D. Johnson, C. Perkins, J. Arkko, RFC 3775, Mobility Support in Ipv6,
IETF, Juin 2004.
[MESA] Site du projet MESA : http://www.projectmesa.org/
[802.11] Site du groupe de travail 802.11 WLAN : http://www.ieee802.org/11/
[802.16] Site du groupe de travail 802.16 WIMAX : http://www.ieee802.org/16/
[802.21] Site du groupe de travail 802.21 : http://www.ieee802.org/21/index.html
[Wiki-LZW] Wikipedia, http://en.wikipedia.org/wiki/LZW
[Wiki-LZ77] Wikipedia, http://en.wikipedia.org/wiki/LZ77
[Wiki-Huff] Wikipedia, http://en.wikipedia.org/wiki/Huffman_coding
[Vigie] Site web du projet Vigie, http://www.rennes.enst-bretagne.fr/~xlagrang/Vig_public/
242
Glossaire
Glossaire
243
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
Network (RNIS)
MS : Mobile Station
NS : Network Service
244
Glossaire
P-CSCF : Proxy-CSCF
PCU : Packet Control Unit
PDN : Packet Data Network
PDP : Packet Data Protocol
PDU : Protocol Data Unit
PER : Packet Encoding Rules
PLMN : Public Land Mobile Network
POP : Post Office Protocol
PSI : Packet System Information
PSTN : Public Switched Telephone
Network
P-TMSI : Packet TMSI
RF : Radio Frequency
RFC : Request For Comments
RR : Radio Ressource
TR : Technical Recommandation
245
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
TS : Technical Specification
VLR : Visitor Location Register
UDP : User Datagram Protocol
UMTS : Universal Mobile Telecommunications System
URL : Uniform Ressource Locator
246
WS : Window Size