These - Optimisation Des Réseaux D'accès Mobiles

Thse
prsente pour obtenir le grade de Docteur

de lcole Nationale Suprieure des Tlcommunications
Spcialit : Informatique et Rseaux
Nicolas DAILLY
Optimisation des Rseaux d'Accs Mobiles
pour les systmes E-GPRS et B3G
Soutenue le 22 juin 2007 devant le jury compos de :

Bijan Jabbari
Xavier Lagrange
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.
Table des matires

Introduction Gnrale......................................................................................................................... 17
Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS.................................19
1. Introduction................................................................................................................................19
2. L'interface Abis..........................................................................................................................20
2.1. Architecture de l'interface Abis..........................................................................................20
2.2. Limitations du systme existant......................................................................................... 21
2.3. Une approche dynamique pour l'interface Abis................................................................. 21
3. Etudes de modles thoriques pour l'interface Abis dynamique............................................... 22
3.1. Modle d'allocation de ressources......................................................................................22
3.2. Rsultats pour deux et quatre classes d'utilisateurs............................................................23
3.3. Dfinition d'un modle de trafic temps rel....................................................................... 27
4. Simulation des performances de l'interface Abis dynamique....................................................35
4.1. Paramtres de simulation................................................................................................... 35
4.2. Performances de l'interface Abis Dynamique forte charge............................................. 39
4.3. Performances de l'interface Abis Dynamique charge oprationnelle..............................43
4.4. Comparaison de diffrentes stratgies d'augmentation de ressources............................... 44
4.5. tude de la taille des piles implmenter au niveau des BTS...........................................46
5. Conclusions................................................................................................................................49
Chapitre II : Handover pour le Transport de Donnes dans les Rseaux E-GPRS............................ 51
1. Introduction................................................................................................................................51
2. Dfinitions................................................................................................................................. 52
2.1. Transfert inter-cellulaire l'initiative du mobile ou contrl par le rseau....................... 52
2.2. Qualit de service...............................................................................................................53
3. Transfert de donnes dans un rseau GPRS.............................................................................. 54
3.1. Pile protocolaire du plan utilisateur du systme GPRS..................................................... 54
3.2. Allocation de ressources sur l'interface radio : la couche MAC........................................ 56
3.3. Fiabilisation de la transmission sur l'interface radio : la couche RLC...............................56
3.4. Fiabilisation de la transmission dans le rseau d'accs : la couche LLC........................... 61
3.5. Fiabilisation de la transmission dans le rseau coeur : le tunnel GTP............................... 63
3.6. Fiabilisation de la transmission de bout en bout................................................................ 63
3.7. Mise en oeuvre des mcanismes de fiabilisation............................................................... 64
3.8. Le contexte PDP et la ngociation des paramtres de QoS............................................... 67
4. Reslection et Handover dans les rseaux cellulaires................................................................70
4.1. Diffrentes approches pour le transfert inter-cellulaire..................................................... 70
4.2. Reslection et handover dans le rseau d'accs E-GPRS...................................................75
4.3. Procdure dtaille de reslection dans le rseau d'accs GPRS....................................... 79
4.4. Procdure dtaille de Handover dans le rseau d'accs E-GPRS.....................................82
5. Simulation des handovers dans le systme GPRS..................................................................... 89
7
Optimisation des Rseaux d'Accs Mobiles pour les Systmes E-GPRS et B3G
5.1. Aperu de la structure du simulateur................................................................................. 89

5.2. Modlisation des quipements rseau................................................................................91
5.3. Modlisation de la pile protocolaire...................................................................................92
5.4. Procdures implments dans le simulateur...................................................................... 93
5.5. Description et paramtres du systme simul.................................................................... 99
6. Performances du transfert inter-cellulaire dans le rseau GPRS............................................. 104
6.1. Transfert inter-cellulaire / intra-BSC............................................................................... 104
6.2. Reslection autonome et assiste, inter-cellulaire / intra-BSC........................................ 112
6.3. Transfert inter-cellulaire / inter-BSC / intra SGSN..........................................................116
6.4. Influence de la taille de la fentre d'mission RLC......................................................... 122
6.5. Conclusions...................................................................................................................... 125
7. Conclusion............................................................................................................................... 125
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr............... 127
1. Introduction..............................................................................................................................127
2. Etude des performance du transfert inter-RAT........................................................................128
2.1. Introduction de la technologie WLAN dans les rseaux cellulaires................................ 128
2.2. Caractristiques des technologies d'accs GPRS et WIFI............................................... 129
2.3. Gestion de la reslection inter-RAT.................................................................................130
2.4. Paramtrage des simulations............................................................................................ 132
2.5. Transfert inter-RAT : WIFI vers GPRS........................................................................... 132
2.6. Transfert inter-RAT : GPRS vers WIFI........................................................................... 139
2.7. Conclusions sur le transfert inter-RAT GPRS/WIFI....................................................... 144
3. Performances de la reslection pour des trafics flux continu ..........................................144
3.1. Introduction...................................................................................................................... 144
3.2. Paramtres des simulations.............................................................................................. 145
3.3. Reslection intra-BSC GPRS...........................................................................................146
3.4. Reslection inter-RAT WIFI/GPRS.................................................................................149
3.5. Reslection inter-RAT GPRS/WIFI.................................................................................151
3.6. Conclusions : impact de la reslection sur un trafic Streaming ................................. 154
4. Conclusion............................................................................................................................... 155
Chapitre IV : Transport de Signalisation SIP
travers un rseau d'accs cellulaire................................................................................................ 157
1. Introduction..............................................................................................................................157
2. Architecture IMS..................................................................................................................... 158
3. Signalisation SIP et SDP..........................................................................................................159
4. Architecture SigComp............................................................................................................. 161
5. Solutions de compression........................................................................................................ 162
5.1. Codage de Huffman......................................................................................................... 162
5.2. Compression LZ77...........................................................................................................165
5.3. Compression LZ78 / LZW............................................................................................... 166
5.4. Compression Deflate........................................................................................................169
6. Amlioration des performances des compresseurs.................................................................. 171
6.1. Conservation d'un contexte de compression.................................................................... 171

6.2. Utilisation d'un dictionnaire............................................................................................. 171
6.3. EPIC................................................................................................................................. 172
7. Performances des solutions de compression sur SIP............................................................... 173
7.1. Compression sans mmoire, sans dictionnaire.................................................................174
7.2. Compression sans mmoire, avec dictionnaire................................................................ 175
7.3. Compression avec mmoire............................................................................................. 176
7.4. Compression Deflate combine....................................................................................... 178
7.5. Etapes d'une compression combine Deflate + EPIC...................................................... 180
7.6. Etapes d'une compression Deflate avec mmorisation d'un message............................. 181
8. Conclusion............................................................................................................................... 182
Conclusion Gnrale........................................................................................................................ 183
1. Contexte de la thse................................................................................................................. 183
2. Contributions........................................................................................................................... 184
3. Perspectives............................................................................................................................. 185
3.1. 3G LTE............................................................................................................................ 185
3.2. Au del de la 3G...............................................................................................................186
Annexe A. Dbits dans le systme GSM/GPRS.............................................................................. 189
Annexe B. MMPP et IPP..................................................................................................................191
1. Prsentation des MMPP...........................................................................................................191
2. Prsentation des IPP.................................................................................................................192
Annexe C. Descriptif du simulateur pour l'tude de l'interface Abis............................................... 195
1. Objets qui composent le simulateur ........................................................................................195
1.1. Les classes du simulateur................................................................................................. 195
1.2. Le noyau du simulateur....................................................................................................196
1.3. La rcupration des statistiques....................................................................................... 196
1.4. La gnration de nombres alatoires................................................................................197
1.5. La gestion des vnements...............................................................................................197
1.6. La gestion des donnes.................................................................................................... 197
1.7. Les modles derreur pour la transmission de donnes................................................... 198
1.8. Modlisation des interfaces Air et Abis........................................................................... 198
1.9. Modlisation des tlphones mobiles...............................................................................199
1.10. Modlisation de la BTS..................................................................................................199
1.11. Modlisation du BSC..................................................................................................... 200
2. Descriptif du comportement des simulateurs...........................................................................200
2.1. Architecture des simulateurs............................................................................................ 200
2.2. La gestion des vnements du simulateur........................................................................202
3. Configuration et utilisation du simulateur............................................................................... 207
3.1. Scnarios de simulation................................................................................................... 207
3.2. Paramtres et rsultats de simulation............................................................................... 208
3.3. Scripts de compilation et de lancement............................................................................209
Annexe D. Droulement d'un change de donnes au niveau RLC et LLC....................................211

1. Droulement d'un change de blocs au niveau RLC............................................................... 211
2. Droulement d'un change de trames au niveau LLC............................................................. 213
Annexe E. Le handover dans les rseaux radio-tlphoniques : GSM.............................................215
Annexe F. Aperu du fonctionnement du protocole TCP/IP........................................................... 217
Annexe G. Solutions de mobilit dans le coeur de rseau cellulaire et au niveau IP......................221
1. Handover inter-SGSN..............................................................................................................221
2. Les solution de mobilit au niveau IP......................................................................................224
2.1. Mobile IP..........................................................................................................................224
2.2. Cellular IP........................................................................................................................ 227
Annexe H. Echanges SIP..................................................................................................................231
1. Appel avort (sans dcrochage)............................................................................................... 231
2. Appel avec dcrochage, puis raccrochage............................................................................... 233
Ressources Documentaires............................................................................................................... 237
Glossaire........................................................................................................................................... 243
10
Index des illustrations

Figure 2.1.1. Interface Abis................................................................................................................ 20
Figure 3.2.1.1. Automate dcrivant les tats du modle 2 classes, 24 slots Air et 30 canaux Abis 24
Figure 3.2.1.2. Probabilit de perte pour deux classes dutilisateurs, charge identique.................. 25
Figure 3.2.2.1. Probabilit de perte pour quatre classes dutilisateurs, charge identique................25
Figure 3.2.3.1. Probabilit de perte des appels de classe 1, charges diffrencies.............................26
Figure 3.2.3.2. Probabilit de perte des appels de classe 2, charges diffrencies.............................27
Figure 3.3.1. Chaine de Markov N serveurs, sans file d'attente (M/M/U/0)................................... 28
Figure 3.3.2. Profil de trafic d'un utilisateur ayant une session en cours........................................... 28
Figure 3.3.3. Modlisation du systme de trafic GPRS temps rel.................................................... 29
Figure 3.3.4. Reprsentation du trafic IPP gnr par un groupe d'utilisateurs................................. 30
Figure 3.3.5. Taux de perte utilisateur et taux de perte paquet (pour diffrents taux d'activit)........32
Figure 3.3.6. Taux de perte utilisateur et taux de perte paquet (pour diffrents niveaux de charge). 33
Figure 3.3.7. Evolution du taux de perte des utilisateurs en fonction de la charge du systme......... 34
Figure 3.3.8. Taux de perte des appels en fonction de la charge du systme.....................................35
Figure 4.1.4.1. Session de trafic HTML............................................................................................. 38
Figure 4.2.1.1. Taux de Transmission forte charge [170, 20, 20]................................................... 40
Figure 4.2.1.2. Temps de transmission forte charge [170, 20, 20].................................................. 40
Figure 4.2.2.1. Taux de Transmission forte charge [140, 50, 20]................................................... 42
Figure 4.2.2.2. Temps de transmission forte charge [140, 50, 20].................................................. 42
Figure 4.3.1. Taux de Transmission faible charge...........................................................................43
Figure 4.3.2. Temps de Transmission faible charge........................................................................ 44
Figure 4.4.1 : Taux de transmission, sans buffer, interface Abis partage.........................................45
Figure 4.4.2 : Temps de transmission, sans buffer, interface Abis partage...................................... 45
Figure 4.4.3 : Taux de transmission, avec buffer, interface Abis ddie........................................... 46
Figure 4.4.4 : Temps de transmission, avec buffer, interface Abis ddie.........................................46
Figure 4.5.1. remplissage moyen des piles des BTS.......................................................................... 47
Figure 4.5.2 : taux de transmission des datagrammes LLC............................................................... 47
Figure 4.5.3 : Temps moyen de transmission des datagrammes LLC................................................48
Figure 2.2.1. Classification de diffrents services en fonction de leur sensibilit aux erreurs et aux
dlais (d'aprs [3GPP 22.105])........................................................................................................... 53
Figure 3.1.1. Couche protocolaire du plan utilisateur GPRS............................................................. 55
Figure 3.7.2.1. Transmission sans erreur d'un paquet IP, sans fiabilisation au niveau LLC..............65
Figure 3.7.2.2. Transmission sans erreur d'un paquet IP, avec fiabilisation au niveau LLC............ 65
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)............................................................................................................................................67
Figure 3.7.2.5. Transmission avec perte d'un paquet IP, avec mcanisme de fiabilisation LLC (cas
dfavorable)........................................................................................................................................ 67
Figure 3.8.1. Procdure d'activation du contexte PDP l'initiative du mobile.................................. 69
Figure 3.8.2. Paramtres d'un contexte PDP actif ............................................................................. 70
Figure 4.2.6.1. Diffrents modes de transfert inter-cellulaires GPRS en fonction du paramtrage du
rseau.................................................................................................................................................. 78
Figure 4.4.3.1. Phase de prparation du handover intra-BSS [3GPP 43.129]....................................84
Figure 4.4.3.2. Phase d'excution du Handover Intra-BSS [3GPP 43.129]....................................... 85
11
Figure 4.4.3.3. Handover optimis : intra-BSC / intra RA [3GPP 43.129].......................................86

Figure 4.4.4.1. Phase de prparation du handover inter-BSS [3GPP 43.129]....................................88
Figure 4.4.4.2: Phase d'xcution du handover inter-BSS [3GPP 43.129]........................................ 88
Figure 5.1.1. Liste des packages du simulateur..................................................................................90
Figure 5.2.1. Equipements du rseau qui ont t modliss...............................................................91
Figure 5.3.1. Modlisation de la pile protocolaire..............................................................................92
Figure 5.4.1.1. Procdure d'attachement au rseau............................................................................ 94
Figure 5.4.2.1. Procdure de dtachement......................................................................................... 95
Figure 5.4.3.1. Procdure de reslection intra-BSC........................................................................... 96
Figure 5.4.4.1. Procdure de reslection inter-BSC / intra SGSN..................................................... 97
Figure 5.4.5.1. Procdure de Handover intra-BSC.............................................................................98
Figure 5.4.6.1. Procdure de Handover inter-BSC / intra-SGSN.......................................................99
Figure 5.5.1.1. Trajectoire d'un mobile au cours d'une simulation...................................................100
Figure 5.5.4.1. Profil de trafic HTTP............................................................................................... 102
Figure 6.1.1. Dure de la procdure de transfert inter-cellulaire......................................................105
Figure 6.1.2. Nombre de blocs RLC perdus au cours d'un transfert inter-cellulaire (diffrence
mis/reus)........................................................................................................................................106
Figure 6.1.3. Nombre de blocs RLC perdus au cours d'un transfert inter-cellulaire (diffrence
gnrs/transmis).............................................................................................................................. 107
Figure 6.1.4. Nombre moyen de blocs RLC transmis par mobiles.................................................. 108
Figure 6.1.5. Temps de transmission des blocs RLC....................................................................... 109
Figure 6.1.6. Nombre de trames LLC perdues au cours d'un transfert inter-cellulaire.................... 110
Figure 6.1.7. Temps de transmission des trames LLC..................................................................... 110
Figure 6.1.8. Nombre de paquets TCP perdus par handover............................................................111
Figure 6.1.9. Temps de transmission des donnes gnres par la couche application................... 112
Figure 6.2.1. Nombre de blocs RLC perdus au cours d'une reslection de cellule (diffrence
mis/reus)........................................................................................................................................113
Figure 6.2.2. Nombre de blocs RLC perdus au cours d'une reslection de cellule (diffrence
gnrs/transmis).............................................................................................................................. 114
Figure 6.2.3. Nombre de trames LLC perdus au cours d'une reslection de cellule........................ 114
Figure 6.2.4. Temps moyen de transmission des trames RLC......................................................... 115
Figure 6.2.5. Temps moyen de transmission des objets de la couche application........................... 115
Figure 6.2.6. Nombre moyen de blocs RLC transmis par mobiles.................................................. 116
Figure 6.3.1. Dure de la procdure de basculement........................................................................117
Figure 6.3.2. Dure de la procdure de transfert inter-cellulaire (hors temps de basculement).......117
Figure 6.3.3. Nombre de blocs RLC perdus au cours d'un transfert inter-BSC (diffrence
mis/reus)........................................................................................................................................118
Figure 6.3.4. Nombre de blocs RLC perdus au cours d'un transfert inter-BSC (diffrence
gnrs/transmis).............................................................................................................................. 119
Figure 6.3.5. Nombre de trames LLC perdus au cours d'un transfert inter-BSC............................. 119
Figure 6.3.6. Nombre de paquets IP perdus au cours d'un transfert inter-BSC................................120
Figure 6.3.7. Temps de transmission des blocs RLC....................................................................... 121
Figure 6.3.8. Temps de transmission des lments de donnes....................................................... 121
Figure 6.4.1. Nombre moyen de bloc RLC perdus par basculement (diffrence mis/reus)..........122
Figure 6.4.2. Nombre moyen de bloc RLC perdus par basculement (diffrence gnr/transmis). 123
Figure 6.4.3. Temps de transmission moyen des bloc RLC............................................................. 124
Figure 6.4.4. Nombre moyen de trames LLC perdus par basculement............................................ 124
Figure 2.1.1: Interconnexion de points d'accs WLAN avec un rseau cellulaire........................... 128
12
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
.......................................................................................................................................................... 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
.......................................................................................................................................................... 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
Figure 7.2.1. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire).. 175
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
Index des tables

Tableau 4.1.1.1. Paramtres de la simulation..................................................................................... 36
Tableau 4.1.2.1. Paramtres de trafic................................................................................................. 37
Tableau 4.1.3.1. Paramtrage des mobiles......................................................................................... 37
Tableau 4.1.4.1. Paramtres de trafic................................................................................................. 38
Tableau 4.2.1.1: Les quatre configurations tudies.......................................................................... 39
Tableau 3.3.1.1. Taille des donnes transmises dans un bloc RLC (d'aprs [3GPP 45.003])............57
Tableau 4.1.5.1. Prise de dcision de reslection, de cellule cible et de basculement....................... 74
Tableau 4.1.5.2. Comparaison des diffrentes approches de transfert inter-cellulaire.......................74
Tableau 4.2.1.1. Evolutions de la normalisation 3GPP concernant le transfert inter-cellulaire GPRS
............................................................................................................................................................ 75
Tableau 5.5.1.1. Temps de transfert des donnes sur les diffrentes interfaces...............................100
Tableau 5.5.3.1. Taille des trames de donnes................................................................................. 101
Tableau 5.5.4.1. Paramtres du modle de trafic HTTP...................................................................103
Tableau 3.2.1. Paramtres de simulation du trafic Streaming.......................................................... 145
Tableau 5.1.1. Frquence d'apparition des diffrents caractres...................................................... 163
Tableau 5.1.2. Etapes de construction d'un arbre de Huffman......................................................... 164
Tableau 5.3.1. Exemple de codage LZW......................................................................................... 167
Tableau 5.3.2. Exemple de dcodage LZW......................................................................................168
Tableau 5.4.2.1. Codes de Huffman statique dans Deflate...............................................................171
Tableau 7.1. Taille (en octets) des messages SIP............................................................................. 173
Tableau 1. Dbits proposs par les systmes GSM/GPRS/EDGE [GSM 05.01].............................190
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
mique de ressources sur cette interface. Ces mcanismes permettent le dploiement de

la technologie E-GPRS tout en prservant la structure de l'interface Abis existante, qui
s'appuie sur une structure de trame MIC.
La seconde partie de cette thse analyse diffrentes approches de handover qui peuvent
tre mises en oeuvre pour assurer la mobilit dans les rseaux E-GPRS. Nous y formulons quelques propositions pour amliorer les performances du basculement et mettre en
place un vritable handover. Certains de ces mcanismes ont t rcemment introduits
dans les normes sur le GERAN. Nous prsentons les volutions rcentes de cette normalisation, puis exposons les rsultats de nos simulations qui permettent de comparer les
performances des diffrents mcanismes. Notre tude montre les gains de performances
tant au niveau des pertes que des dlais obtenus par la prservation des tats de
transmission au niveau RLC, lors du passage d'une cellule une autre.
La troisime partie de cette thse considre le problme des handover inter-systmes.
Nous y avons analys le basculement entre deux technologies d'accs intgres. D'une
part, la technologie cellulaire E-GPRS et d'autre part, la technologie WIFI, aux dbits
plus importants. Nous avons analys l'impact du passage d'une pile protocolaire une
autre, ainsi que de la rupture de dbit. Nous avons propos d'introduire une couche de
convergence au niveau liaison de donnes afin de limiter l'impact du handover au niveau rseau d'accs. Cette troisime partie se focalise, dans un deuxime temps, sur l'analyse des mcanismes de handover mettre en place pour le transfert de donnes en
mode Streaming. Nous y analysons l'intrt de l'activation de la couche de liaison de
donnes dans le cas de transferts avec le protocole UDP.
La gestion des sessions multimdia au sein du rseau IMS repose sur la signalisation
SIP. Cette signalisation, formate sous forme de texte, ncessite d'tre compresse avant
transmission travers le rseau d'accs. Cette compression vise rduire le temps de
transmission de la signalisation travers des bearer bas dbit et conomiser l'utilisation des ressources radio. Nous analysons, dans la quatrime partie de cette thse, diffrentes approches de compression. Nous formulons des recommandations pour la mise
en place de compresseurs performants qui tiennent compte de l'historique de transmission du mobile.
Les rsultats prsents dans cette thse doivent permettre des oprateurs de rseaux et
des constructeurs d'quipements de dterminer les solutions les plus adaptes pour optimiser la qualit de service dans les rseaux d'accs. Ce choix est li aux contraintes de
qualit imposes par les services.
18
Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS
Chapitre I : Allocation dynamique de ressources

sur l'interface Abis E-GPRS
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
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.
Figure 2.1.1. 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
2.2. Limitations du systme existant

Comme on peut le visualiser sur la figure 2.1.1, le trafic provenant de linterface Air
doit tre multiplex sur le faisceau de trames MIC. Dans les systmes GSM et GPRS, la
correspondance est simple. A chaque slot TDMA sur linterface radio correspond un canal 16kbits/s sur linterface Abis. Cette association statique est possible tant que le dbit par slot sur l'interface radio nexcde pas 16 kbits/s.
Dans le systme GSM, le schma de codage le plus lev permet d'atteindre des dbits
de donnes de 14,4 kbits/s/slot (les schmas de modulation et codage, issus de [GSM
05.01] sont repris dans l'annexe A). En GPRS, la norme prvoit un dbit maximum de
21,4 kbits/s/slot en utilisant le schma de codage CS-4. Ce schma noffre cependant
aucune protection des donnes transmises sur l'interface radio.
On a vu que sur linterface Abis, le dbit unitaire propos slve au maximum 16kbits/s. Dans la pratique il faut prvoir une marge supplmentaire pour la supervision de
la liaison MIC. C'est pour cette raison que le CS-3 ne peut tre transmis sur un canal de
16kbits/s en dpit d'un dbit utile par slot radio de 15,6 kbits/s. Le technologie EDGE
autorise des dbits allant jusqu' 61,85kbits/s en utilisant le schma de modulation / codage MCS-9. Le dploiement de EDGE a donc impos la reconfiguration des interfaces
Abis. La politique dallocation des ressources sur cette interface a du tre adapte en
consquence. Certains constructeurs ont adopt des solutions propritaires [Kondra].
D'autres ont prfr prserver l'existant en conservant une structure de trames MIC
[Hk06] et en adaptant la gestion des ressources en consquence : c'est l'approche que
nous nous proposons d'tudier ici.
Un raisonnement rapide conduit considrer le dbit maximal que l'on peut faire passer
sur l'interface radio et mettre en place suffisamment de canaux sur l'interface Abis
pour lcouler. Cela conduit alors surdimensionner l'interface Abis. C'est une stratgie
relativement coteuse pour l'oprateur qui a tout intrt minimiser le nombre de liaisons MIC quil doit mettre en place. L'optimisation de l'utilisation d'un faisceau MIC
peut tre ralise en mutualisant les ressources du faisceau entre plusieurs stations de
base. Ce mode de gestion des ressources peut conduire refuser l'tablissement de nouvelles sessions paquets. Une politique commune de contrle pour l'tablissement de ces
sessions doit alors tre mise en place.
2.3. Une approche dynamique pour l'interface Abis

Afin doptimiser lutilisation des ressources sur linterface Abis, il faut sinterroger sur
la possibilit de mettre en place un mcanisme dallocation dynamique de ressources.
Les systmes GPRS et EDGE offrent des schmas de modulation et codage qui
permettent de transmettre des dbits allant de 9,05 61,85 kbits/s/slot sur l'interface
radio. Le principe de lAbis dynamique consiste associer chaque slot sur linterface
Air, entre 1 et 4 canaux 16kbits/s sur linterface Abis, en fonction du schma de modulation et codage utilis par le mobile. Un circuit temporaire est alors rserv. Sa capa21
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.
3. Etudes de modles thoriques pour l'interface Abis dynamique

3.1. Modle d'allocation de ressources
Nous tablissons ici, un modle bas sur la thorie des files d'attente. Il permet de lier
l'allocation de ressources sur l'interface Abis celle sur l'interface Air.
Dans ce modle, un mobile qui arrive dans le systme demande se voir attribuer 1 slot
sur l'interface Air et de 1 n canaux 16kbit/s sur l'interface Abis. La capacit de transmission multislot des mobiles n'est pas considre ici.
Diffrentes classes d'utilisateurs sont dfinies en fonction du nombre de canaux 16
kbits/s utiliss sur linterface Abis pour chaque slot utilis sur linterface Air. Un utilisateurs qui utilise 1 slot sur linterface Air et n canaux sur linterface Abis appartient la
classe Un .
Soit n le nombre dutilisateurs de la classe Un. On suppose que le taux darriv des utilisateurs suit une loi exponentielle de paramtre n.. De mme pour le temps de service
qui suit une loi exponentielle de paramtre n. On dispose de Na slots sur linterface Air
et Nb canaux 16 kbits/s sur linterface Abis.
Nous considrons qu'un canal est allou pendant tout le temps de la session de communication. On cherche tudier la probabilit de perte de chaque classe dutilisateurs
en fonction de la charge du systme.
22
Les contraintes de ce modle sont alors les suivantes :
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.
3.2. Rsultats pour deux et quatre classes d'utilisateurs

3.2.1. Deux classes dutilisateurs, charge par classe identique
Dans cet exemple, deux classes dutilisateurs sont considres. La premire classe utilise un slot sur linterface Air et un canal 16kbits/s sur linterface Abis tandis que la
seconde classe utilise deux slots sur linterface Air et deux canaux sur linterface Abis.
Il y a 24 slots disponibles sur linterface Air et 30 canaux sur linterface Abis. Pour des
charges quivalentes pour les deux classes, le facteur limitant est donc principalement
linterface Abis.
Pour tudier ce systme, on considre le graphe des tats possibles et on dtermine la
probabilit d'tre dans les tats de blocage. Chaque tat du systme est reprsent par le
couple (1, 2) o est le nombre d'appels de classe i. Les tats du systme respectent
alors les contraintes suivantes :
1 + 2 24
1 + 22 30
Le graphe des tats est reprsent sur la figure 3.2.1.1.
23
Figure 3.2.1.1. Automate dcrivant les tats du modle 2 classes, 24 slots Air et 30 canaux Abis
La figure 3.2.1.2 reprsente le taux de perte des appels de classe 1 et de classe 2 en

fonction de la charge de trafic. Cette dernire est identique pour les deux classes :
1/1=2/2.
La courbe d'Erlang-B pour des appels de classe 1, charge quivalente (1/1+2/2), a
galement t trace titre d'illustration. Dans ce cas, le facteur limitant est exclusivement l'interface Air (Na<Nb). Le nombre maximal de communications que l'on peut
couler est de 24 en simultan.
A charge faible, la courbe des appels de classe 1 offre des performances moins bonnes
que ce qu'on obtient avec Erlang-B. A charge plus leve, c'est la courbe des appels de
classe 1 qui devient meilleure.
Les appels de classe 2 subissent des pertes bien plus importantes que les appels de
classe 1. Pour servir un appel de classe 2, il faut que deux ressources soient disponibles
sur l'interface Abis. Si deux ressources se librent mais qu'un appel de classe 1 arrive
avant, l'appel de classe 2 qui suit sera rejet et la ressource restante ne pourra tre utilise que par un appel de classe 1.
24
Figure 3.2.1.2. Probabilit de perte pour deux classes dutilisateurs, charge

identique
3.2.2. Quatre classes d'utilisateurs, charge par classe identique

A titre d'illustration, la figure 3.2.2.1 prsente les taux de pertes pour quatre classes d'utilisateurs utilisant entre 1 et 4 canaux sur l'interface Abis. Dans cet exemple, nous
considrons une configuration 8 slots sur linterface Air et 16 canaux sur lAbis. Le
blocage peut donc provenir la fois de linterface Air et de linterface Abis. La charge
considre est dfinie en abscisse. Elle est la mme pour les quatre classes dutilisateurs.
Figure 3.2.2.1. Probabilit de perte pour quatre classes dutilisateurs, charge

identique
25
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.
3.2.3. Deux classes dutilisateurs, charges distinctes

On reprend ici un modle deux classes dutilisateurs avec les mmes paramtres que
prcdemment : Na=24 slots et Nb=30 canaux. On fait varier cette fois ci indpendamment la charge des deux classes dutilisateurs. On obtient alors les courbes de probabilit de perte pour les appels de classe 1 (figure 3.2.3.1) et pour ceux de classe 2 (figure
3.2.3.2).
Figure 3.2.3.1. Probabilit de perte des appels de classe 1, charges diffrencies
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.
Figure 3.2.3.2. Probabilit de perte des appels de classe 2, charges diffrencies
3.3. Dfinition d'un modle de trafic temps rel

Description du modle temps rel
On considre ici un systme qui peut accueillir U utilisateurs et qui possde R ressources. Ces R ressources sont partages entre les utilisateurs.
Les utilisateurs arrivent dans le systme suivant un taux darrive et ouvrent une session dont la dure suit une loi exponentielle de paramtre . Quand il y a U utilisateurs
enregistrs dans le systme, on arrte den accepter. Les utilisateurs sont alors rejets et
27
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.
Figure 3.3.1. Chaine de Markov N serveurs, sans file d'attente (M/M/U/0)
Si on note X le nombre d'utilisateurs ayant une session en cours, on a [Ham05][Dec04] :

x
x!
P X =x = U i
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
Application au systme E-GPRS

Le modle de trafic dcrit prcdemment vise modliser une session de transfert de
donnes en mode paquet temps rel. Dans le systme E-GPRS, les utilisateurs sont initialement dtachs du systme. Le mobile doit alors s'attacher au systme, via une procdure GPRS attach . Au cours de cette procdure, le rseau contrle s'il est mme
d'accueillir le mobile. Pour cela, le rseau met en oeuvre une politique de contrle d'admission (CAC Call Admission Control). Le mobile peut alors se voir refuser l'accs au
rseau. Une fois attach au rseau, le mobile dbute une session de communication en
activant un contexte PDP. Au cours de sa session, le mobile alterne entre des priodes
d'inactivit (mode veille paquet ) et des priode de transfert de donnes (mode
transfert paquet ). Une fois sa session termine, le mobile peut quitter le rseau en effectuant une procdure GPRS detach . Comme dans le systme GPRS, les utilisateurs peuvent donc tre dans 3 tats diffrents : hors systme (idle) , attach au systme, mais sans gnrer de trafic (standby) ou attach au systme et gnrant du trafic sur la voie radio (ready) .
Notre modle se restreint au cas temps rel. Pour un mobile ayant une session en cours,
si au moment de l'arrive d'un paquet il n'y a aucune ressource disponible pour le transmettre sur l'interface radio, le paquet est perdu. Il n'y a donc aucune mise en attente des
donnes au niveau du rseau d'accs. Tous ces points sont rsums sur la figure 3.3.3.
Figure 3.3.3. Modlisation du systme de trafic GPRS temps rel
Contraintes sur le systme

A un instant donn, X utilisateurs attachs au systme peuvent vouloir utiliser simultanment Y ressources. Le nombre maximal dutilisateurs attachs au systme tant U et
le nombre de ressources maximal tant R, les contraintes sur le systme sont les
suivantes :
29
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.
Figure 3.3.4. Reprsentation du trafic IPP gnr par un groupe d'utilisateurs
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
On retrouve cette formule dans la dmonstration qui tablit la formule d'Engset

[Ham05]. C'est la probabilit d'avoir Y utilisateurs en cours d'appels parmi une population finie de X utilisateurs.
La probabilit d'tre dans l'tat (X, Y) est donc donne par :
x
y
y
Cx
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
Influence de la capacit daccueil du systme

Le but de cette premire tude est de voir linfluence du nombre dutilisateurs que peut
accueillir le systme sur, dune part, le taux de rejet des utilisateurs et, dautre part, sur
le taux de rejet des communications pour les utilisateurs attachs au systme.
Dans notre modle, nous prenons 8 ressources (R=8). On fait varier la capacit d'accueil
U du systme, c'est dire le nombre maximum d'utilisateurs par ressource. U=R,
variant entre 1 et 10. On impose une faible charge utilisateur au systme, proportionnelle U : /=0,5U.
Sur les figures 3.3.5, nous avons trac le taux de perte utilisateur et le taux de perte paquet en fonction de la charge utilisateur dans le systme. Le taux de perte paquet a t
trac pour trois taux d'activit utilisateur : 10%, 25% et 50%.
/( +)=[0.1, 0.25, 0.5]
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
On notera qu'il ny a aucun rejet dappel d lindisponibilit des ressources lorsque le

nombre dutilisateurs dans le systme est infrieur ou gal au nombre de ressources
disponibles : tout appel entrant trouvera ncessairement une ressource ddie.
Dans le cas o les utilisateurs sont trs actifs, par contre, le taux de perte des paquets
augmente trs rapidement. Pour rduire les pertes de paquets, soit on augmente le
nombre de ressources GPRS, soit on impose une politique d'admission plus drastique.
Moins d'utilisateurs pourront alors tablir une session, mais ceux qui ont une session en
cours bnficieront d'une qualit de service bien meilleure. Notre modle permet donc
d'adapter la politique d'admission en fonction des contraintes de qualit que l'on
s'impose. A titre d'exemple, les figures 3.3.6 prsentent le taux de perte utilisateur et le
taux de perte paquet en fonction du nombre maximum d'utilisateurs accepts par ressource (8 ressources) pour diffrents niveaux de charge utilisateur. Le taux d'activit des
utilisateurs est de 25%.
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
Influence de la charge du systme

Dans cette seconde partie, nous considrons que le nombre maximum dutilisateurs dans
le systme U et la quantit de ressources disponible R sont fixe : on prend R=5 et U=15.
On fait varier la charge des utilisateurs et leur taux dactivit : /=151 et /(
+)=2 avec (1, 2)[0,1 ... 0,9]2.
Le taux de perte des utilisateurs entrant dans le systme, reprsent sur la figure 3.3.7
augmente naturellement avec la charge des utilisateurs et est indpendant de la charge
de trafic.
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
Figure 3.3.8. Taux de perte des appels en fonction de la charge du systme
4. Simulation des performances de l'interface Abis dynamique

Pour valuer les performances de l'interface Abis dynamique pour le systme
GSM/GPRS et E-GPRS, nous avons dvelopp un simulateur qui modlise le rseau
d'accs GSM/GPRS (BSS). Le descriptif de ce simulateur est fourni en annexe (Annexe
C, paragraphes 1, 2 et 3). Les rsultats et les conclusions des diffrentes simulations que
nous avons effectues sont prsents dans cette partie. Nous ne considrerons ici que
l'tude de la transmission dans le sens descendant.
4.1. Paramtres de simulation

4.1.1. Configuration du rseau
Dans les simulations prsentes dans cette partie, nous considrons un rseau de 10 stations de base (BTS). Les interfaces Air associes aux stations de base comportent 17
ressources ddies au transport de voix, 2 ressources dites mixtes , qui sont utilises
pour transporter des donnes mais peuvent tre premptes au besoin pour transporter
du trafic vocal, et 2 ressources exclusivement utilises pour transporter des donnes.
Dans le cas o une pile de transmission est implmente au niveau des BTS, sa capacit
est fixe 4096 bits. Un mcanisme de contrle de flux est alors mis en place entre la
station de base et le BSC. Quand la pile de transmission est remplie, la transmission est
interrompue.
35
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
Nombre de ressources ddies au trafic vocal
17
Nombre de ressources mixtes
Nombre de ressources ddies au trafic data
Taille des buffers dans les BTS
4096 bits
Taux d'erreur bloc (aprs codage)
0,1%
Tableau 4.1.1.1. Paramtres de la simulation
4.1.2. Arrives et dparts des utilisateurs

Nous considrons que l'arrive des utilisateurs s'effectue suivant un processus de Poisson. Un mobile reste en moyenne attach au rseau pendant un temps exponentiel. Le
temps de service prend en compte la fois l'tablissement et le relchement des appels,
l'ouverture ou la fermeture de sessions PDP et la mobilit des terminaux qui quittent les
cellules alors que leur appel ou leur transfert de donnes n'est pas termin.
Pour chaque cellule, nous considrons qu'en moyenne 5 appels sont tablis par minute
et que chaque appel a une dure moyenne de 2 minutes. Pour un nombre de ressources
voix gal 19 - ressource voix + ressources mixtes - cela reprsente un taux de perte
des appels de 0,4%.
La dure moyenne d'une session de donnes est fixe 5 minutes. Le taux d'arrive des
utilisateurs GPRS dpend de la simulation considre.
36
Paramtres
Valeur
Nombre d'appels vocal, par minute et par cellule
Dure moyenne des appels
2 min
Dure d'une session pour le transfert de donnes
5 min
Tableau 4.1.2.1. Paramtres de trafic
4.1.3. Profil des utilisateurs

Nous considrons des utilisateurs dont les mobiles sont capables d'utiliser 4 slots simultanment en voie descendante et un slot en voie montante (capacit multislots 4+1).
Chaque utilisateur utilise l'un des schmas de codage suivant : MCS-2 (13kbits/s) MCS4 (20kbits/s) ou MCS-7 (47 kbits/s). Le nombre de ressources ncessaires sur l'interface
Abis pour transmettre un bloc radio varie suivant le schma de modulation et codage
slectionn : 1 canal pour le codage MCS-2, 2 canaux pour le codage MCS-4 et 3 canaux pour le codage MCS-7.
Les proportions d'utilisateurs utilisant les diffrents schma de codage sont rparties
comme suit : 50% des utilisateurs utilisent le codage MCS-2, 30% le codage MCS-4 et
20% le codage MCS-7.
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
20% MCS-7 47,45 kbits/s

Tableau 4.1.3.1. Paramtrage des mobiles
37
4.1.4. Modle de trafic utilis

Le modle de trafic paquet utilis est celui dfinit par l'ETSI dans le document [ETSI
TR 101 112]. Ce modle correspond la modlisation du comportement d'un utilisateur
lors de la consultation d'un site web. L'utilisateur dmarre un session de consultation.
Pendant cette session, il va charger un certain nombre de pages HTML. Chaque page
HTML va engendrer l'appel de plusieurs objets (images, contenu multimdia, feuilles de
style CSS...). Le profil de trafic est prsent sur la figure 4.1.4.1. Les lois qui rgissent
la taille et les temps entre les appels des diffrentes pages et objets sont rappeles dans
le tableau 4.1.4.1. Ces paramtres ont t choisis conformment au modle [ETSI TR
101 112] et sont adapts aux diffrents dbits des 3 classes de mobiles choisis. Le temps
entre deux sessions de consultation a t rduit de 5 1 minute.
Figure 4.1.4.1. Session de trafic HTML
Paramtres de trafic
Loi
Valeur Moyenne
MCS-2
MCS-7
Temps inter session
Exponentielle
60 sec
60 sec
60 sec
Nombre de pages par session
Gomtrique
Temps entre deux chargements de pages Gomtrique
5 sec
5 sec
5 sec
Nombre d'objets dans une page
Gomtrique
25
25
25
Temps entre l'appel de deux objets
Gomtrique
0,1 sec
0,0625 sec
0,0246 sec
Taille des objets (en octets)
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
Dure de validit d'un paquet IP
Valeur Constante 20 secondes 20 secondes 20 secondes
Tableau 4.1.4.1. Paramtres de trafic
38
MCS-4
4.2. Performances de l'interface Abis Dynamique forte charge

4.2.1. Sans augmentation des capacits de transmission de l'interface Abis
Pour l'tude des performances forte charge, nous considrons un nombre moyen de
sessions de trafic paquet variant entre 0 et 15. Nous considrons une interface Abis qui
possde 170 ressources vocales ddies et 20 ressources utilises pour le transport de
donnes. L'Abis possde galement 20 ressources dites mixtes qui sont utilises pour
couler des communications vocales. Lorsqu'elles ne sont pas utilises, ces ressources
mixtes peuvent tre utilises pour transporter des donnes. Par la suite, nous reprsenteront l'organisation des canaux grce au triplet [voix, mixtes, donnes]. Le premier
chiffre du triplet correspond au nombre de ressources ddies voix, le second au nombre
de ressources mixtes et le dernier, au nombre de ressources ddies au trafic de donnes.
L'Abis considre ici est donc reprsente par le triplet [170, 20, 20].
Nous considrons ici les quatre types de configurations dcrites dans le tableau 4.2.1.1.
Dans les deux premires configurations, l'oprateur met en place les principes de l'Abis
dynamique (Cf. 2.3), sans mise en place de buffer au niveau des BTS : c'est l'approche
micro-circuit . Dans la premire configuration, chaque BTS possde un nombre de
ressources fixes sur l'interface Abis. Dans la seconde configuration, les ressources de
l'interface Abis sont partages entre les BTS en fonction de leurs besoins. Les autres
configurations consistent ajouter des piles au niveau des BTS : c'est l'approche avec
bufferisation . Les ressources sur l'interface Abis sont alors, soit ddies pour chaque
BTS (troisime configuration tudie) soit partages entre les BTS (quatrime configuration).
Abis ddie
Approche micro-circuit
Abis partage
Configuration 1 Configuration 2
Approche avec bufferisation Configuration 3 Configuration 4

Tableau 4.2.1.1: Les quatre configurations tudies
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
Figure 4.2.1.1. Taux de Transmission forte charge [170, 20, 20]
Figure 4.2.1.2. Temps de transmission forte charge [170, 20, 20]
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.
4.2.2. Augmentation des capacits de transmission de l'interface Abis

Pour augmenter les performances de la transmission, il faut augmenter les capacits de
transmission de donnes sur l'Abis. En effet, il y a en gnral plus de canaux utiliss sur
l'interface Abis que sur l'interface Air. Cette augmentation des capacits de l'interface
Abis peut se faire de deux faons diffrentes : soit en augmentant le nombre de ressources ddies data sur l'interface Abis, soit en augmentant la proportion de ressources
mixtes (ressources voix qui, lorsqu'elles sont inutilises, peuvent servir au transport de
donnes).
Augmenter le nombre de ressources ddies data est sans doute le choix le plus simple
et le plus performant. Cependant, ce choix reprsente un cot assez important pour l'oprateur puisqu'il doit dployer de nouvelles liaisons. A contrario, l'augmentation de la
part de ressources data premptables ne ncessite pas d'augmenter les capacits de
l'interface. Cette solution entrane cependant une dynamique beaucoup plus importante
pour la configuration de l'interface Abis. De plus, le gain de capacit n'est pas permanent mais dpend du nombre d'appels voix en cours dans la cellule : on obtient un gain
de performance en moyenne . Pour des charges oprationnelles (moins de 4 utilisateurs actifs par cellule), des configurations [140, 50, 20] (soit 210 canaux) et [170, 20,
40] (soit 230 canaux) prsentent des performances moyennes assez proches.
Les figures 4.2.2.1 et 4.2.2.2 prsentent les taux et les dlais de transmission forte
charge pour des configurations de l'interface Abis de type [140, 50, 20].
41
Figure 4.2.2.1. Taux de Transmission forte charge [140, 50, 20]
Figure 4.2.2.2. Temps de transmission forte charge [140, 50, 20]
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.
4.3. Performances de l'interface Abis Dynamique charge oprationnelle

Cette partie a pour objectif d'tudier les performances de l'interface Abis dynamique
pour des charges de trafic qui correspondent celles que l'on pourrait rencontrer sur un
rseau E-GPRS oprationnel. Tout en conservant les mmes paramtres de simulation
que prcdemment, on se focalise sur des mesures pour un nombre moyen d'utilisateurs
plus faible : de 0 4 par cellule.
Les figures 4.3.1 et 4.3.2 reprsentent les taux et les temps de transmission pour les
deux stratgies avec et sans buffer et pour deux configurations de l'interface Abis :
[170, 20, 20] et [170, 50, 20]. Les ressources tant partages entre les diffrentes BTS.
Figure 4.3.1. Taux de Transmission faible charge
Si on considre les temps de transmission, il est globalement possible de faire les

mmes constatations que prcdemment : la stratgie avec bufferisation offre de
meilleures performances et l'augmentation du nombre de ressources de donnes disponibles n'apporte en moyenne aucune amlioration. On constate cependant une lgre
amlioration des temps de transmission dans la stratgie sans bufferisation lorsque
l'on augmente le nombre de ressources data pouvant tre premptes.
43
Figure 4.3.2. Temps de Transmission faible charge
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.
4.4. Comparaison de diffrentes stratgies d'augmentation de ressources

On considre ici deux ensembles de simulations. Dans le premier ensemble, les ressources de l'interface Abis sont partages entre les diffrentes BTS et on utilise une stratgie micro-circuit (figures 4.4.1 et 4.4.2). Dans le second ensemble, chaque BTS
possde sont propre ensemble de ressources sur l'interface Abis et on utilise une stratgie avec bufferisation (figures 4.4.3 et 4.4.4).
Le but de ces simulations est de comparer les performances d'une configuration o on
augmente la part de ressources data premptables (par transformation de ressources voix
ddies) configuration [140, 50, 20] avec une configuration o l'on augmente simplement le nombre de ressources ddies configuration [170, 20, 40]. On compare ces
deux configuration la configuration de rfrence [170, 20, 20].
Les rsultats montrent que les performances obtenues par les deux politiques d'augmentation des ressources sur les interfaces Air et Abis offrent des performances trs
proches. La stratgie qui consiste augmenter la part de ressources premptables est ce44
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.
Figure 4.4.1 : Taux de transmission, sans buffer, interface Abis partage
Figure 4.4.2 : Temps de transmission, sans buffer, interface Abis partage
45
Figure 4.4.3 : Taux de transmission, avec buffer, interface Abis ddie
Figure 4.4.4 : Temps de transmission, avec buffer, interface Abis ddie
4.5. tude de la taille des piles implmenter au niveau des BTS

Dans les simulations prcdentes, pour l'approche avec bufferisation , nous avons
considr que les piles au niveau des BTS avaient une capacit de 4096 bits. Dans cette
partie, nous allons faire une srie de simulations pour mesurer l'impact de la taille de la
pile sur les performances de la transmission.
46
Pour cela, on considre une configuration [190, 0, X] pour l'interface Abis o X, le

nombre de ressources de donnes, varie entre 0 et 80. On se place forte charge : 10 utilisateurs en moyenne ont une session PDP active dans la cellule. Trois tailles de piles,
d'une capacit de 2048, 4096 et 6144 bits ont t tudies. Les figures 4.5.1, 4.5.2 et
4.5.3 reprsentent respectivement la taille moyenne des piles, les taux et les temps de
transmission.
Figure 4.5.1. remplissage moyen des piles des BTS
Figure 4.5.2 : taux de transmission des datagrammes LLC
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
Entre 30 et 40 canaux, la taille moyenne des piles commence augmenter fortement : le

systme est charg. Dans ce cas, la quantit de donnes qui est coule sur l'interface
Abis est peu prs identique la quantit de donnes que l'interface Air est capable d'couler.
Au del de 40 canaux, l'interface Abis est capable d'couler plus de trafic que l'interface
radio. Les piles au niveau des BTS saturent : il y a congestion.
Figure 4.5.3 : Temps moyen de transmission des datagrammes LLC
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
Chapitre II : Handover pour le Transport de Donnes dans les Rseaux E-GPRS
Chapitre II : Handover pour le Transport de

Donnes dans les Rseaux E-GPRS
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
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
2.2. Qualit de service

Tous les services offerts par les rseaux de donnes ne sont pas sensibles aux mmes
contraintes de qualit de service (QoS Quality of Service). Par exemple, les services
de transmission de donnes sont trs sensibles aux pertes car il faut pouvoir assurer l'intgrit des donnes mais peu sensibles la gigue et aux dlais. Les services de phonie
sont, par contre, beaucoup plus tolrants en terme de dgradation des donnes, mais
imposent une rgularit et des dlais de transmission trs stricts pour assurer la bonne
qualit de la conversation.
Le handover entrane une dgradation des paramtres de qualit de la transmission.
Suivant l'approche adopte, ce ne sont cependant pas les mmes paramtres qui vont
tre impacts. Dans la plupart des approches, plus les pertes sont faibles, plus le cot est
important en terme de dlais, et inversement.
On peut effectuer une classification des services en fonction de leur tolrance aux diffrents paramtres de qualit de service. On distingue ainsi les services de tlphonie et
de visiophonie, les services de streaming audio et vido, les services de transfert de
fichier, les services de messagerie instantane et de messages courts et les services d'change de donnes temps rel (par exemple pour effectuer des jeux en rseaux). Tous
ces services sont rcapituls sur la figure 2.2.1 et classifis suivant leur tolrance aux
pertes et aux dlais.
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
mission est le plus court possible.

Les services de streaming - audio ou vido permettent de transmettre des flux audio
ou vido en lger diffr par rapport au dbut de la transmission. Le terminal commence
par charger en mmoire cache quelques secondes de flux avant de commencer la
diffusion pour l'utilisateur. Le pr-chargement du flux rend ce service plus tolrant aux
dlais de transmission et la gigue puisqu'il ne requiert par d'interaction temps rel
entre l'utilisateur et le serveur. Il ncessite cependant des dbits de transmission suffisamment rguliers pour que le flux vido mis en cache ne se tarisse pas. Dans la pratique, il faut donc que le dbit moyen de la transmission soit suprieur au dbit de diffusion vers l'utilisateur. Ce service tolre donc un handover dont le temps de coupure et
les pertes sont modrs.
Les services de transfert de fichiers sont beaucoup plus sensibles aux pertes que les services audio et vido. Toute perte ou erreur au cours de la transmission vient altrer l'intgrit des donnes transmises. Par contre, ces services sont peu sensibles aux dlais de
transmission et la gigue. Seul le dbit et donc le temps de transfert - peut se rvler
tre une contrainte pour l'utilisateur, surtout si il est factur la dure. Ce service requiert donc un mcanisme de handover sans perte mais n'impose pas de contraintes particulires sur le temps de coupure de la transmission.
Les services de messageries instantanes et de messages courts sont des services de
transfert de donnes courtes dont la dlivrance peut tre plus ou moins retarde. Les services de messageries instantanes tolrent un dlai de dlivrance qui dpasse ceux
imposs par les transmissions vocales : l'aspect temps rel est attnu par le fait qu'il
faut laisser du temps l'utilisateur de taper ses messages sur son clavier. Par ailleurs, la
taille des messages transmis est suffisamment faible pour ne requrir que de trs faibles
dbits. Ce service requiert donc un mcanisme de handover sans perte et dont les temps
de coupure de la transmission sont modrs. Certains services d'changes de donnes
peuvent parfois requrir des dlais de dlivrance trs courts. C'est le cas par exemple
pour des messages d'envoi d'alertes type Push ou pour les jeux vidos en rseau.
Les dplacements et les actions des diffrents joueurs en rseau doivent tre rpercutes
trs rapidement aux autres joueurs afin d'assurer la jouabilit (ou gameplay ) du jeu
vido. Le mode de gestion des vnements du jeu au niveau applicatif aura, dans ce cas
particulier, un impact non ngligeable sur les protocoles mettre en place aux niveaux
infrieurs et sur le choix de la stratgie de handover.
3. Transfert de donnes dans un rseau GPRS

3.1. Pile protocolaire du plan utilisateur du systme GPRS
La pile protocolaire du plan utilisateur du systme GPRS est reprsente sur la figure
3.1.1 [3GPP 23.060].
54
Figure 3.1.1. Couche protocolaire du plan utilisateur GPRS
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
3.2. Allocation de ressources sur l'interface radio : la couche MAC

Le systme GPRS offre un service de transport de donnes en mode paquet sur l'interface radio. Les ressources attribues au systme sont partages dynamiquement entre les
diffrents utilisateurs de la cellule. Quand un utilisateur souhaite transmettre des donnes sur l'interface radio, il doit demander au rseau l'ouverture d'une connexion radio.
Il se voit alors attribuer un contexte de transmission appel TBF Temporary Block
Flow [3GPP 44.060]. L'attribution des TBF se fait par l'intermdiaire des messages
Packet Downlink Assignment pour la voie descendante, Packet Uplink Assignment pour la voie montante et Packet Timeslot Reconfigure pour l'attribution
conjointe de ressources sur les voies montantes et descendantes. Ces messages
contiennent l'identit du TBF : le TFI Temporary Flow Identity. La frquence attribue la transmission (frquence fixe ou squence de saut) ainsi que les slots sur lesquels le mobile va pouvoir mettre et recevoir des donnes. Cette attribution tient
compte des capacits de transmission multislot du mobile.
Les ressources dcrites par le TBF ne sont pas rserves pour le mobile mais partages
entre plusieurs utilisateurs. C'est le PCU Packet Control Unit (parfois intgr au BSC,
parfois au SGSN), qui dcide des mobiles qui vont recevoir et mettre sur chacun des
slots. Le mobile coute tous les blocs transmis sur la voie descendante dans les slots qui
lui sont attribus et ne garde que les blocs qui le concerne. Les trames LLC tant chiffres avant transmission sur l'interface radio, un mobile n'a pas possibilit d'interprter
les informations utilisateur qui ne lui sont pas destines. Dans chaque bloc est galement transmis un numro de TFI. Le mobile qui possde le TBF associ ce TFI est
alors autoris mettre un bloc sur le slot montant correspondant.
Au niveau RR Radio Ressource un mobile qui a au moins un TBF actif est dans le
mode transfert paquet. Quand le mobile n'a pas de TBF ouvert, il est dans le mode veille
paquet. Les tats RR traduisent l'existence d'une connexion entre le mobile et le BSC au
niveau de la couche RLC/MAC du sous systme radio (BSS). Ils ne traduisent pas
ncessairement l'existence d'une connexion en cours des niveaux suprieurs (LLC,
TCP/IP...).
3.3. Fiabilisation de la transmission sur l'interface radio : la couche RLC

3.3.1. Segmentation et rassemblage des trames LLC
La couche RLC fournit un service de segmentation et de rassemblage des trames LLC.
La taille des blocs RLC qui sont gnrs dpend du schma de codage utilis sur l'interface radio.
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
RLC data block size

octets
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
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.
3.3.2. Fiabilisation de la transmission RLC

Nous nous restreindrons ici dcrire le protocole RLC en mode acquitt. Le protocole
de retransmission implment dans la couche RLC est un mcanisme d'acquittement
slectif (Ack/Nack) fentre glissante.
Avant d'tre transmis, chaque bloc radio de donnes est estampill l'aide d'un numro
appel BSN Block Sequence Number. Ce numro est compris entre 0 et SNS-1 et
volue de faon incrmentale. SNS Sequence Number Space est la taille de la
squence de numrotation. SNS a pour valeur 128 en GPRS. En E-GPRS, le SNS est de
taille variable dpendant du schma de modulation/codage utilis. Sa valeur maximale
est de 2048 blocs. Par ailleurs, chaque bloc radio de contrle est estampill avec un
RBSN Reduced Block Sequence Number qui peut prendre la valeur 0 ou 1.
Indicateurs sur l'tat de la transmission :
L'metteur et le rcepteur maintiennent en permanence diffrents indicateurs sur l'tat
de la transmission. Au niveau de l'mtteur, le nombre de blocs en attente d'acquittement ne doit jamais excder la taille de la fentre d'mission : WS - Windows Size. Pour
le systme GPRS; WS correspond 64 blocs (SNS/2). Pour le systme E-GPRS, sa
taille varie entre 64 et 1024 blocs. Cette taille est dfinie au moment de l'ouverture du
TBF et dpend du nombre de slots attribus la transmission sur l'interface radio. Par
exemple, un mobile E-GPRS ayant une capacits multislots 4+1 aura une fentre de
transmission d'au maximum 192 blocs en voie montante et 512 blocs en voie descendante. La taille maximale de la fentre attribuable est fournie dans [3GPP 44.060].
Les indicateurs d'tat de transmission ct metteur sont V(S), V(CS), V(A) et V(B).
V(S) est le BSN du prochain bloc transmettre dans la squence de blocs. V(A) est le
BSN du plus ancien bloc transmis qui n'a pas t acquitt. V(B) est un vecteur de taille
SNS qui indique l'tat d'acquittement de chacun des blocs transmis (acquitt ou non
acquitt). V(CS) et utilis pour la transmission des blocs de contrle et contient la valeur du prochain RBSN transmettre.
Ct rcepteur, les indicateurs de transmission sont V(R), V(Q) et V(N). V(R) est le
BSN du prochain bloc qui suit le plus grand bloc reu dans la squence. V(Q) est le
BSN du plus petit bloc non encore reu. V(N) est un vecteur qui rpertorie l'tat de
rception des blocs de la squence : reu ou non.
Le rcepteur envoie rgulirement des acquittements l'metteur afin de lui indiquer les
blocs retransmettre ou lui permettre de poursuivre la transmission. La politique d'envoi des acquittements n'est pas normalise et est donc du ressort du constructeur. Un
58
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 :
[V ABSN V S ]mod SNS

L'metteur enregistre ensuite l'tat de rception des blocs valides en mettant jour le
vecteur V(B).
Droulement de la transmission
L'metteur envoie les blocs RLC dans l'ordre de la squence et incrmente V(S). Cette
progression s'arrte lorsqu'il n'y a plus de nouveaux blocs transmettre (il n'y a plus de
blocs segments, ni de trames LLC en attente de transmission) ou que la situation de
blocage est atteinte : V(S)=V(A)+WS. Cette situation ne peut tre leve qu' la rception d'un acquittement. Tant qu'il n'aura pas reu d'acquittement, l'metteur va faire de la
retransmission prventive en retransmettant les blocs marqus comme tant non acquitts dans le vecteur V(B). L'metteur retransmet en priorit les plus anciens blocs transmis qui n'ont pas encore t acquitts : il commence donc en gnral par V(A). Notons
ici que le rseau peut demander explicitement un acquittement au mobile et que le mobile peut indiquer au rseau qu'il se trouve dans un tat de blocage.
A la rception d'un acquittement, l'metteur met jour la valeur de V(A) et le vecteur
V(B). Si V(A)V(S), l'metteur reprend la transmission partir du plus ancien bloc
transmis mais non acquitt (gnralement V(A)) ; seuls les blocs non acquitts sont retransmis.
59
Un exemple de transmission au niveau RLC est fournis en annexe D.

Libration ou rupture des TBF
Les TBF sont ouverts par le rseau ou la demande du mobile pour la transmission d'un
nombre limit de blocs (dfinit au moment de l'ouverture du TBF, dans le message d'allocation de ressources). Suivant le droulement de la transmission, le mobile ou le rseau peuvent demander arrter, prolonger ou modifier le TBF : la dcision tant toujours, au final, prise par le PCU.
Pour les TBF downlink, le rseau indique au mobile qu'il souhaite mettre un terme au
TBF en affectant la valeur 1 au champ FBI Final Block Indicator. Le mobile envoie alors un acquittement et si aucune retransmission n'est ncessaire, le TBF est libr.
Pour les TBF uplink, c'est le rseau qui attribue les ressources au mobile. Le mobile
indique dans chaque bloc, le nombre de trames TDMA qui lui sont thoriquement
ncessaires pour finir sa transmission. Le rseau peut prolonger le TBF au besoin (et en
particulier s'il est ncessaire d'effectuer des retransmissions). Le rseau doit annoncer la
fin du TBF en envoyant un acquittement ou le bit FAI Final Ack Indicator est positionn 1.
Outre les conditions normales d'arrt du TBF (parce que le mobile et le rseau n'ont plus
rien transmettre), il peut y avoir rupture du TBF lorsque les conditions radio sont trop
mauvaises ou lorsque le mobile devient inaccessible. Des critres ont t dfinis pour
permettre au rseau de constater la rupture d'un TBF.
Lorsque la fentre d'mission RLC/MAC au niveau du mobile passe dans une situation
de blocage, la couche RLC doit dmarrer le temporisateur T3182. A l'expiration de ce
temporisateur - ayant une valeur par dfaut de 5 secondes - le mobile doit librer les
TBF en cours et dcrmenter le compteur N3102 (valeur maximale par dfaut 4, valeur
maximale possible 32) de PAN_DEC (valeur comprise entre 0 et 7). Lorsque le compteur N3102 passe 0, le mobile doit procder une reslection de cellule. Le compteur
N3102 est incrment de PAN_INC chaque fois que le mobile reoit un acquittement
qui permet d'largir la fentre d'mission.
En cas d'allocation dynamique de ressources en voie montante, chaque fois que le rseau attribue des slots montants (via l'USF Uplink State Flag) au mobile disposant
d'un TBF dj ouvert, le mobile doit redmarrer le temporisateur T3180. Si ce dernier
vient expirer (sa valeur par dfaut tant de 5 secondes), le mobile doit considrer que
le TBF s'est referm En cas d'allocation fixe, le mobile doit dmarrer le temporisateur
T3184 chaque fois qu'il reoit un acquittement. Si ce temporisateur expire (valeur par
dfaut de 5 secondes), le mobile doit considrer que le TBF s'est referm [3GPP
44.060].
60
3.4. Fiabilisation de la transmission dans le rseau d'accs : la couche LLC

La couche LLC [3GPP 44.064] peut tre utilise en mode acquitt ou non acquitt. C'est
gnralement ce dernier mode qui est utilis, la fiabilisation de la transmission tant assur de bout en bout par la couche TCP. La couche LLC n'offre qu'un service de fiabilisation et n'effectue aucune segmentation des SNDCP-PDU.
Le mcanisme de fiabilisation de la couche LLC est bas sur un systme fentre glissante. L'espace de numrotation comporte 512 valeurs (de 0 511) : la fentre d'anticipation comporte donc 256 trames. La taille du champ d'information ne peut excder
1520 octets.
Classification des trames LLC
Il existe 4 types de trames LLC : I, UI, S et U. Les trames I, ou trames dinformation,
servent transporter les donnes utilisateurs. Les trames UI Unconfirmed Information, ou trames d'information non acquittes, servent transmettre des informations sans
acquittement ni vrification du squencement. Les pertes de donnes ne sont pas dtectes mais ces trames sont tout de mme numrotes en squence. Les trames S sont des
trames de supervision. Elles servent transporter des informations de contrle et ne sont
pas numrotes. Les trames U sont des trames non numrotes qui servent au transport
d'informations supplmentaires.
Les trames I contiennent galement des informations de supervision. C'est pourquoi
elles sont parfois appeles trames I+S . Ce mode de contrle de la transmission est
appel piggy-backing .
Les trames non numrotes (U) contiennent un bit P/F (Pool/Final). Si le bit P est positionn 1, l'metteur sollicite une rponse du rcepteur. Le rcepteur doit alors rpondre
dans une trame U dont le bit F est positionn 1.
Les trames I et S contiennent un champ A, qui est positionn 1 si lmetteur souhaite
que le rcepteur envoie un acquittement l'metteur.
Indicateurs sur l'tat de la transmission
Les trame I et UI sont numrotes par un index compris entre 0 511. Lmetteur et le
rcepteur doivent maintenir des variables qui leur permettent de connatre l'tat de la
transmission : numro de la prochaine trame envoyer, numro de la prochaine trame
attendue, statut d'acquittement et de rception des diffrentes trames.
Les trames d'information sont numrotes l'aide du numro de squence N(S). Ct
metteur, V(S) indique le numro de la prochaine trame transmettre en squence et
V(A) est le numro de la premire trame d'information de la squence d'mission qui n'a
pas encore t acquitte. A tout moment, on a :
[V A N S V S V A256] mod 512
61
Ct rcepteur, la variable V(R) indique le numro de la trame en attente de rception.

Dans les trames d'information et de supervision, le rcepteur indique le numro de la
prochaine trame attendue par l'metteur. Cet indicateur, appel N(R), sert donc au piggy backing puisqu'il indique que toutes les trames qui ont t envoyes prcdemment
N(R) ont t correctement reues.
Les trames de supervision (S ou I+S) contiennent un bitmap dacquittement (SACK) qui
permet dacquitter un ensemble de trames. Ce bitmap permet dacquitter un maximum
de 256 trames.
Les trames d'information UI sont numrotes l'aide du numro de squence N(U). L'metteur maintient donc une variable V(U) qui contient le numro de la prochaine trame
UI transmettre et le rcepteur maintient une variable V(UR) qui contient le numro de
la prochaine trame UI que l'on devrait normalement recevoir (sous rserve qu'il n'y ait
pas eu de pertes et que les trames soient remises en squence).
Droulement de la transmission
Quand une ou plusieurs trames doivent tres transmises, l'ordre de priorit suivant doit
tre respect :
- Les trames qui doivent tre retransmises
- Les trames qui doivent tre transmises pour la premire fois
- Les trames d'acquittement
Dans chaque message envoy au rcepteur, l'metteur indique s'il souhaite recevoir une
trame acquittement (S ou I+S) : pour cela, il positionne le champ A 1. Quand il s'agit
d'une trame retransmise, l'metteur demande systmatiquement recevoir une trame
d'acquittement.
Pour chaque trame I envoye, l'metteur maintient un compteur sur le nombre de transmissions de la trame et un temporisateur T201. Lorsque le nombre de transmissions
d'une trame atteint la valeur N200 (valeur 3 par dfaut), l'metteur doit effectuer une
procdure de r-tablissement de la connexion. C'est lorsque le temporisateur T201 expire avant que la trame ne soit acquitte que l'metteur doit retransmettre la trame. La
valeur par dfaut du timer T201 dpend du SAPI Service Access Point Identifier utilis, c'est dire de la couche qui va prendre en charge la trame LLC au niveau suprieur. Les SAPI qui correspondent au transfert de donnes utilisateur sont les SAPI 3 et
5 ; les valeurs par dfaut de leur timer T201 sont respectivement de 5 et de 10 secondes.
Lorsque le rcepteur dtecte un trou dans la squence en rception, il doit envoyer un
bitmap d'acquittement l'metteur (trame S ou I+S). A la rception d'un acquittement,
la couche LLC marque les trames correctement acquittes. Toutes les trames non
acquittes qui ont t envoyes antrieurement la dernire trame acquitte doivent tre
considres comme perdues et places en attente de retransmission.
Un exemple d'change de trames au niveau LLC est fournis en annexe D.
62
3.5. Fiabilisation de la transmission dans le rseau coeur : le tunnel GTP

La transmission dans le rseau coeur est assur par le protocole GTP [3GPP 29.060] :
GPRS Tunelling Protocol. Ce protocole assure la transmission, entre le SGSN et le
GGSN, des paquets IP en provenance des couches suprieures. Le protocole GTP opre
au dessus d'un rseau de transport coeur de type IP.
Les premires versions de la norme (release 98 [3GPP 03.60]) offraient la possibilit
l'oprateur de choisir entre un rseau de transport de type UDP/IP donc non fiabilis
et un rseau de transport de type TCP/IP fiabilis.
Les versions suivantes de la norme (release 99 et suivantes [3GPP 23.060]) ne proposent plus qu'un rseau de transport de type IP/UDP lorsque l'utilisateur est reli une
interface radio GSM/EDGE (rseau d'accs GERAN). Il n'y a donc pas de fiabilisation
de la transmission dans le rseau coeur lorsque l'abonn est connect via GPRS. Par
contre, lorsque l'utilisateur est connect via une interface radio UMTS (rseau d'accs
UTRAN), l'oprateur peut choisir le protocole utilis dans son rseau de transport :
UDP/IP ou TCP/IP.
3.6. Fiabilisation de la transmission de bout en bout

La fiabilisation de bout en bout de la transmission entre le mobile et le serveur auquel il
est reli ne relve pas de la normalisation 3GPP. Les mcanismes mis en place pour assurer cette fiabilisation dpendent du type de rseau auquel l'utilisateur souhaite se
connecter. Dans la majorit des cas, il s'agit d'un rseau de type IP ; le protocole de fiabilisation le plus rpandu tant TCP.
On notera par ailleurs que le rseau de donnes auquel le mobile se connecte est gnralement le rseau priv de son oprateur. Ce dernier met ensuite en place des passerelles
vers l'internet. Pour optimiser les performances de son rseau, l'oprateur peut mettre en
place des passerelles proxy qui vont venir diviser la connexion (Split TCP). La fiabilisation n'a alors plus lieu de bout en bout (mobile/serveur externe), mais entre le mobile et
le proxy : qui est alors sous le contrle de l'oprateur. Les protocoles mis en place dans
le rseau oprateur restent, quoi qu'il en soit, de type IP, les protocoles de communications majoritairement utiliss de bout en bout, vu du mobile, restent donc TCP/IP ou
TCP/UDP.
L'annexe F prsente un aperu du fonctionnement du protocole TCP/IP.
63
3.7. Mise en oeuvre des mcanismes de fiabilisation

Dans le systme GPRS, il est possible dimplmenter des protocoles de fiabilisation aux
niveaux RLC et LLC. Lacquittement au niveau RLC permet de fiabiliser la transmission sur l'interface radio, cest dire la liaison entre le mobile et le BSC, tandis que
lacquittement au niveau LLC fiabilise le transport de donnes au niveau du rseau d'accs, entre le mobile et le SGSN. Lactivation de ces mcanismes de retransmission reste
lapprciation des oprateurs.
Lutilisation du protocole TCP/IP sur Internet ajoute un troisime niveau de fiabilisation : de bout en bout, entre le mobile et le serveur. Le serveur auquel l'utilisateur se
connecte n'tant pas forcment sous le contrle de l'oprateur, celui ci ne peut dcider
de l'activation d'un mcanisme de fiabilisation au dessus de la couche IP.
3.7.1. Analyse pratique

Le mcanisme de retransmission au niveau RLC/MAC permet de retransmettre la majorit des donnes errones ou perdues lors de leur transmission sur le mdium radio
[Aji01].
Le mcanisme de retransmission au niveau LLC permet de fiabiliser la connexion entre
le mobile et le SGSN. Cependant, quelques tudes, comme [Qix00] et [Pre02], mettent
en vidence le fait que, dans le cas o le rseau GPRS est interconnect avec un rseau
de type TCP/IP, les mcanismes de retransmission au niveau LLC et au niveau TCP
font souvent double emploi.
Les dlais dattente des acquittements peuvent conduire ce que la couche TCP tente de
rexpdier des paquets non acquitts par le mobile alors que la couche LLC est en train
de les retransmettre. Ce conflit peut mme parfois conduire un rsultat o la mise en
place des acquittements au niveau LLC provoque une diminution des performances de
la transmission. Il faut ici noter que le choix de ces dlais est particulirement dlicat
dans le sens o il nest pas possible pour loprateur de dfinir le temporisateur de retransmission (RTO) du serveur TCP et que le temps de latence du rseau est assez
important. Au niveau LLC, un temporisateur de retransmission (T201) trop court
conduit des retransmissions frquentes au niveau LLC, une valeur dattente trop
grande entrane des retransmissions importantes au niveau TCP et un engorgement inutile du rseau.
La couche LLC peut cependant avoir une utilit si le rseau PDN nimplmente pas de
mcanisme de retransmission (par exemple un rseau bas sur le protocole IP/UDP) ou
dans le cas spcifique du transfert inter-cellulaire (comme nous le montrerons plus tard).
64
3.7.2. Illustration des interactions entre deux mcanismes de fiabilisation

Nous prsentons ici quelques interactions qui peuvent survenir lorsque les mcanismes
de retransmission sont activs aux niveaux LLC et TCP. Nous avons choisi ces deux
mcanismes titre d'illustration, mais ce type d'interaction peut survenir chaque fois que
deux mcanismes de retransmission sont utiliss en parallle : TCP avec LLC, LLC
avec RLC, TCP avec LLC et RLC, TCP de bout en bout avec TCP au niveau de l'interface SGSN-GGSN.
Les figures 3.7.2.1 et 3.7.2.2 prsentent la transmission russie d'un paquet IP dans un
rseau de type GPRS/UMTS, avec et sans mcanisme de retransmission au niveau LLC.
En terme d'change de messages, l'activation de la couche LLC n'a pas d'impact particulier sur la voie descendante. Par contre, sur la voie montante, il est ncessaire de remonter des informations d'acquittement au niveau LLC, ce qui induit du trafic, et donc une
charge supplmentaire.
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
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
La figure 3.7.2.4, prsente le mme scnario de transmission de paquet IP avec perte,

mais avec mise en place du mcanisme de retransmission LLC. Le paquet TCP perdu
est repris grce au mcanisme de retransmission LLC. La reprise de l'erreur est alors
plus rapide que s'il avait fallu attendre l'expiration du RTO. Au niveau TCP, le RTT
Round Trip Time risque d'tre sensiblement plus grand que dans le cas o il n'y a pas
d'erreur de transmission. La mise en place du mcanisme de retransmission LLC peut
donc induire une variation importante du RTT au niveau TCP. Dans la plupart des implmentations de TCP, le calcul du RTO tient heureusement compte de cette variance.
La figure 3.7.2.5 prsente le cas de la perte d'un segment TCP dans le cas o l'interaction entre les couches LLC et TCP conduit une duplication des retransmissions. On assiste ici une perte de paquet IP qui est reprise au niveau LLC. Le paquet arrive au niveau du rcepteur, puis est acquitt (aux niveaux LLC et TCP). Cependant, le RTO expire avant que l'acquittement TCP n'ait le temps d'arriver jusqu'au serveur. Le serveur IP
renvoie donc le paquet IP. Ce dernier va tre nouveau transmis jusqu'au rcepteur, qui
gnrera un second acquittement LLC et un second acquittement TCP (non reprsents
sur la figure). Au lien d'tre transmis deux fois (et acquitt une fois) sur l'interface radio,
le paquet est transmis donc trois fois (et acquitt deux fois).
Cet exemple illustre parfaitement le problme voqu prcdemment du choix du temporisateur T201 (timer 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)
3.8. Le contexte PDP et la ngociation des paramtres de QoS

Pour pouvoir changer des donnes sur un rseau PDN Packet Data Network - externe, le mobile doit s'inscrire auprs d'un point d'accs en demandant la cration d'un
contexte PDP Packet Data Protocol [3GPP 23.060]. Le contexte PDP contient l'ensemble des informations ncessaires au mobile pour communiquer sur le rseau PDP (et
67
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 :
Le type de rseau utilis (IP ou X25 par exemple)
Ladresse PDP du terminal au sein du rseau (adresse IP sur les rseaux IP)
Le nom du point daccs au rseau ou APN Access Point Name
Le NSAPI Network Service Access Point Identifier
Le SAPI Service Access Point Identifier
Ladresse rseau du SGSN auquel est rattach labonn
Les paramtres de qualit de service (QoS)
Les paramtres de fiabilisation de la transmission
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
A tout moment, les diffrents quipements peuvent demander modifier le contexte

PDP en effectuant une procdure de modification du contexte PDP. Cela peut se rvler
utile lorsque le mobile a besoin de ngocier de nouveaux paramtres de transmission ou
que le rseau n'est plus mme d'assurer la qualit de service demande.
Figure 3.8.1. Procdure d'activation du contexte PDP l'initiative du mobile
Etablissement d'un contexte PDP

Afin de fournir un exemple de contexte PDP issu d'un rseau oprateur, nous avons utilis un mobile de trace Sagem OT 96, pour tablir une communication modem vers le
rseau Internet. Le mobile remonte vers le PC auquel il est reli les trames qui circulent
sur l'interface radio. Grce au logiciel VIGIE [Vigie][Dai03] Visualisation et Interprtation de GSM/GPRS pour les Instituts et les Ecoles ces trames sont dcodes et leur
contenu est affich dans les diffrentes fentres de l'application. La figure 3.8.2 prsente
les paramtres d'activation d'un contexte PDP sur le rseau d'un oprateurs franais (certaines informations permettant d'identifier l'oprateur ont t masques).
Cette figure prsente, dans la premire colonne, les paramtres demands par le mobile
et, dans la seconde colonne, les paramtres attribus par le rseau. On peut constater que
le rseau modifie le SAPI demand par le mobile. Le mobile laisse les paramtres de
qualit de service l'apprciation du rseau en mettant leur valeur 0. En rponse, le rseau leur affecte les valeurs qu'il est capable d'assurer : faible priorit, dbit moyen offert pour le mieux, et dbit crte de 64 ko/s (dbit qui est bien suprieur au dbit que
l'on peut atteindre avec le mobile GPRS notre disposition) [3GPP 24.008]. Compte
tenu de ces paramtres, le rseau affecte au mobile la plus faible priorit radio : 4 [3GPP
44.060].
Au niveau de la fiabilisation, le mobile demande ce que la transmission soit en mode
acquitt au niveau radio (RLC), mais non acquitt dans le rseau d'accs (LLC) et dans
le rseau coeur (GTP). Les donnes doivent tre protges au niveau LLC [3GPP
23.060].
69
Figure 3.8.2. Paramtres d'un contexte PDP actif
Les paramtres ncessaires la communication apparaissent galement : le nom du

point d'accs au rseau (APN Access Point Name), l'adresse IP du mobile sur le rseau Internet et les adresses des DNS primaires et secondaires, utiliss pour la rsolution
des URL. A noter que les adresses IP qui apparaissent sont des adresses prives. Le mobile n'est donc pas reli directement internet mais accde au rseau priv de son oprateur.
4. Reslection et Handover dans les rseaux cellulaires

4.1. Diffrentes approches pour le transfert inter-cellulaire
4.1.1. Critres de dclenchement et choix d'une cellule cible
De nombreux facteurs peuvent motiver le dclenchement d'un handover. Ce dernier
peut tre dclench sur des critres radio. C'est le cas lorsque les conditions de transmission se dgradent fortement, voire quand la connexion avec la cellule courante est totalement perdue. Ces critres peuvent galement tre utiliss pour slectionner une cellule
qui offre une qualit de transmission sensiblement plus importante.
L'oprateur peut dclencher des handovers pour des raisons de gestion du rseau. Par
exemple pour faire du dport de charge en faisant migrer des mobiles d'une cellule charge vers une cellule qui l'est moins, ou pour reconfigurer son rseau.
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.
4.1.2. Reslection et Handover dans un rseau de donnes

Dans le cadre des rseaux radio-mobiles tlphoniques [Lag00][Mou92], la procdure
de handover consiste commuter une communication d'une cellule l'autre en minimisant le temps de coupure. Dans le cas des systmes GSM et UMTS [3GPP 23.009], le
handover est systmatiquement l'initiative du rseau. Ce dernier rserve les circuits
ncessaires au rtablissement de la communication dans la cellule cible avant de dclencher le basculement. Le contrle de la connexion est facilit par le fait que la liaison
entre le mobile et le rseau est permanente. Il est ainsi possible de remonter priodiquement des rapports de mesures sur la qualit de la liaison et sur les niveaux de puissance
reue. Un canal de contrle [3GPP 44.003] est d'ailleurs prvu cet effet (SACCH).
Dans un transfert de donnes en mode paquet, la connexion avec le rseau n'est pas
maintenue de faon permanente. Chaque fois que le terminal a des donnes transmettre, des ressources lui sont temporairement affectes. Le contrle de la qualit de la
liaison radio ne peut donc se faire que trs sporadiquement. Il n'y a d'ailleurs pas de ressources rserves pour remonter des mesures. Cette opration, quand elle est mise en
place, occupe donc une partie de la bande passante montante. Pour effectuer le transfert
intercellulaire dans un rseau de donnes, l'approche la plus courante consiste donc
71
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.
4.1.3. Diffrentes approches pour la reslection

La reslection est un processus de changement de cellule dans lequel le mobile doit effectuer lui mme le rtablissement de la transmission dans la cellule cible. En effet,
contrairement ce qui est fait dans le cadre d'un handover, le rseau ne prpare pas l'arrive du mobile dans la cellule cible. Il est possible de distinguer trois types de reslection, suivant le degr d'implication du rseau dans la procdure : la reslection autonome, la reslection commande et la reslection assiste [3GPP 44.060].
La reslection autonome est forcment l'initiative du mobile. C'est ce dernier qui
prend la dcision de reslection et choisit la cellule vers laquelle il va basculer (cellule
cible). Le mobile stoppe alors ses activits dans la cellule courante et bascule vers la
cellule cible. Il doit s'attacher la nouvelle cellule et rserver des ressources avant que
la connexion avec le rseau ne soit rtablie. Cette procdure entrane une suspension de
la transmission qui est relativement longue et les pertes de donnes peuvent tre assez
consquentes. A aucun moment l'ancienne cellule n'est mise au courant par le mobile du
dpart de ce dernier. Les ressources dans l'ancienne cellule sont libres lors de la reconfiguration du rseau, lorsque le mobile s'attache la nouvelle cellule, ou sur des critres qui permettent de dclarer la liaison dfaillante (expiration d'un temporisateur pendant lequel le mobile n'a donn aucun signe d'activit ou par expiration du nombre de
tentatives de transmission dans la cellule).
Dans le cas des procdures de reslection commande ou assiste par le rseau, la dcision de reslection et le choix de la cellule cible peut tre pris par le mobile ou par le rseau. Si c'est le mobile qui prend la dcision, il contacte le rseau pour lui signifier sa
72
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
4.1.5. Rcapitulatif des caractristiques des procdures de reslection et de handover

Le tableau 4.1.5.1 indique, pour chacune des procdures voques, quels sont les quipements l'origine de la dcision de reslection, du choix de la cellule cible et du dclenchement du basculement. La quantit d'informations envoye au mobile est galement indique.
Le tableau 4.1.5.2 fournit une synthse des caractristiques des approches de handover
et de reslection dcrits dans la partie 4.1.
Reslection
autonome
Dcision de
Reslection
Choix
Cellule Cible
Dclenchement
Basculement
Informations envoyes au mobile
Mobile
Mobile
Mobile
aucune
Reslection
commande
Mobile ou Rseau Mobile ou Rseau
Rseau
aucune
Reslection
assiste
Mobile ou Rseau Mobile ou Rseau
Rseau
Tout ou partie des

informations systme
Rseau
Informations systme + ressources

rserves
Handover
Rseau
Rseau
Tableau 4.1.5.1. Prise de dcision de reslection, de cellule cible et de basculement
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
+++
Tableau 4.1.5.2. Comparaison des diffrentes approches de transfert inter-cellulaire
74
4.2. Reslection et handover dans le rseau d'accs E-GPRS

4.2.1. Evolutions de la normalisation E-GPRS
La procdure adopte pour effectuer la reslection de cellule ou le handover est fortement lie la configuration du terminal et du rseau. En effet, les normes ont fortement
volu au fil des versions successives. Le tableau 4.2.1.1 rsume l'volution de la normalisation du 3GPP concernant le transfert inter-cellulaire pour le rseau GPRS.
Release 97, 98, et 99
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
Tableau 4.2.1.1. Evolutions de la normalisation 3GPP concernant le transfert inter-cellulaire GPRS
Les premires versions de la norme Release 97 99 - ne prvoient aucun mcanisme

de handover ou de reslection assiste. Une fois la reslection dcide par le mobile ou
commande par le rseau, le mobile doit se dbrouiller seul pour effectuer la reslection. Il doit rserver les ressources ncessaires au rtablissement de la transmission,
rcuprer les informations systme de la cellule cible. Par ailleurs, s'il change de zone
de routage, il doit effectuer une mise jour de zone de routage. S'il tait en cours de
transmission dans l'ancienne cellule (tat GMM ready) le mobile effectuer une procdure de mise jour de cellule.
Les version 4 et 5 de la norme introduisent la procdure de reslection assiste dans laquelle le rseau prpare la reslection en envoyant au mobile des informations de configuration de la cellule cible. Cette procdure reste cependant optionnelle. Elle ncessite
que le rseau ait accs ces informations et soit mme de les envoyer au mobile. Par
ailleurs, si c'est le mobile qui est l'origine de la dcision de reslection, celui ci doit
informer le rseau de son intention de basculer afin que ce dernier commence envoyer
les informations de configuration de la cellule cible.
La version 6 de la norme, dont les travaux de normalisation viennent de se terminer, introduit le handover pour la transmission de donnes en mode paquet. Dans ce cas, le rseau transmet toutes les informations ncessaires au basculement sur la nouvelle cellule
et rserve un TBF afin de permettre au mobile de reprendre immdiatement sa transmission. Cette procdure est bien entendu optionnelle, compte tenu qu'elle ncessite des
terminaux et un rseau qui permettent la ralisation de cette procdure.
75
4.2.2. Prise de dcision de la reslection en E-GPRS

Dans le systme GPRS, la reslection de cellule peut tre ralise l'initiative du mobile
ou tre commande par le rseau. L'quipement qui contrle le basculement de cellule
est dfini par le paramtre NCO - NETWORK_CONTROL_ORDER [3GPP 45.008].
Trois valeurs peuvent tre associes ce paramtre.
Dans le cas NC-0, c'est le mobile qui prend la dcision de reslection. Il dcide, de faon autonome, de l'instant de basculement. Dans le cas NC-1, le mobile prend lui mme
la dcision de reslection mais remonte tout de mme des mesures vers le rseau. Dans
le cas NC-2, c'est le rseau qui dcide de la reslection de cellule sur la base des rapports de mesure qui lui sont remonts par le mobile. On notera cependant que dans le
cas NC-2, le mobile est autoris effectuer une reslection autonome si le lien descendant vient tre rompu ou que le critre de qualit radio C1 devient ngatif.
Le paramtre NCO est diffus dans les messages SI13 et SI2quat du canal BCCH, dans
le message PSI5 du canal PBCCH et dans le message PSI13 du canal PACCH. Ce paramtre est donc le mme pour tous les mobiles de la cellule. Par dfaut, chaque mobile
adopte le critre NCO diffus sur la voie balise. Le rseau peut cependant commander
individuellement chaque mobile de basculer sur un autre critre [3GPP 44.060]. Pour
cela, le rseau doit envoyer une commande Measurements Reports qui contient,
entre autre, le critre NCO utiliser et la priodicit des remontes de mesures.
Dans le rseau GPRS, il n'existe pas de canal spcifique pour effectuer la remonte des
mesures. Celles-ci s'effectuent donc au sein du canal de trafic. Pour conomiser la bande
passante montante, on a donc tout intrt ne pas remonter systmatiquement des mesures sur le rseau mais commander la remonte de mesures de manire individuelle.
4.2.3. Reslection autonome ou commande en E-GPRS

Dans les premires versions de la norme Release 97, 98 et 99 il n'existe que deux alternatives. La reslection est soit autonome, soit commande par le rseau. Dans les
deux cas, c'est le mobile qui effectue la reslection de cellule. Seule change l'entit qui
prend la dcision : le mobile si il se trouve dans les modes NC-0 et NC-1, le rseau si le
mobile se trouve dans le mode NC-2. Le rseau commande alors la reslection au mobile par l'intermdiaire d'un message PACKET CELL CHANGE ORDER [3GPP
44.060].
L'approche de reslection autonome ne permet pas d'optimiser la procdure de reslection en envoyant par avance au mobile les informations dont il a besoin pour s'attacher
la cellule cible. Par ailleurs, la reslection commande qui ne peut tre ralise que
lorsque le mobile est dans le mode NC-2 - ncessite l'envoi rgulier de rapports de mesures, ce qui utilise une partie de la bande passante montante aux dpends du trafic utilisateur. La reslection assiste permet de rsoudre en partie ces deux problmes.
76
4.2.4. Reslection assiste en E-GPRS

La reslection assiste a t introduite dans version 4 de la norme. Elle consiste, pour le
rseau, envoyer au mobile tout ou partie des informations systme de la cellule cible
dont il a besoin pour effectuer la reslection. Cela permet au mobile de gagner du temps
au moment de son arrive dans la cellule cible, ce qui rduit sensiblement le temps de
coupure. Si le mobile opre en mode NC-2, le rseau envoie les informations systmes
puis commande la reslection. Par contre, si le mobile opre en mode NC-0 ou NC-1,
c'est lui qui est l'origine de la dcision de reslection. Il faut donc que ce dernier notifie cette dcision au rseau afin que les informations systmes lui soient envoyes. C'est
pour cela que le paramtre CCN Cell Change Notification a t introduit [3GPP
44.060].
Le paramtre CCN est diffus sur la voie balise de la cellule courante. S'il est inactif ou
absent, le mobile doit procder une reslection autonome. Si le paramtre CCN est actif et que la cellule cible le permet, le mobile peut dclencher une procdure de reslection assiste.
Si le mobile opre en mode NC-0 ou NC-1 et que la cellule cible permet d'effectuer une
reslection assiste (CCN actif), le mobile doit notifier sa dcision au rseau. Celui-ci
prend alors la main en envoyant un message au mobile lui indiquant que sa demande est
en cours de traitement. Le rseau envoie alors au mobile les informations de configuration de la cellule cible (s'il les possde) puis commande la reslection de cellule. Dans
ce cas, la reslection n'est donc plus autonome, mais dcide par le mobile et commande par le rseau.
Le rseau peut rpondre la demande de reslection du mobile en lui commandant de
passer en mode NC-2. Cela permet alors au rseau de prendre la main et de dcider lui
mme de la cellule reslectionner et du moment de reslection. Cette possibilit revt
un intrt certain puisqu'il permet au rseau de contrler le processus de reslection sans
pour autant obliger le mobile remonter priodiquement des mesures. La remonte de
mesure n'est active qu'au moment o le mobile estime qu'il serait utile de procder
une reslection. Cette dernire possibilit peut galement permettre au rseau d'effectuer
une procdure de handover.
4.2.5. Handover en E-GPRS

La procdure de handover a t introduite dans la version 6 de la norme [3GPP
44.060][3GPP 44.160]. Elle consiste pour le rseau envoyer au mobile les informations de configuration de la cellule cible et, paralllement, rserver des ressources
dans la cellule cible afin d'accueillir le mobile. Une fois ces tches accomplies, le rseau
envoie une commande de handover qui contient, outre l'identit de la cellule cible, le
descriptif de la ressource qui a t rserve (frquence, squence de saut, slots...). Cela
vitant au mobile d'avoir effectuer une rservation de TBF auprs de la cellule cible.
77
4.2.6. Synthse sur la reslection et le handover dans E-GPRS

La figure 4.2.6.1 rsume les diffrents modes de transfert inter cellulaire en fonction des
capacits du mobile et du rseau (support ou non CCN) et du paramtrage radio (mode
de contrle de la reslection, activation du CCN, support de la cellule cible). Un code
couleur permet de visualiser les diffrentes volutions de la norme.
Figure 4.2.6.1. Diffrents modes de transfert inter-cellulaires GPRS en fonction du

paramtrage du rseau
Considrons un mobile (Release 6) qui est initialement en monde NC 0. Si le CCN n'est

pas actif dans la cellule, le mobile effectue une reslection autonome. Il n'a aucune
information sur la cellule cible et doit se dbrouiller seul pour rcuprer les informations qui lui sont ncessaires pour effectuer le basculement. Si le CCN est actif (et qu'il
est possible de faire de la reslection assiste sur la cellule cible choisie par le mobile),
le mobile indique au rseau qu'il souhaite changer de cellule. Le rseau prend alors la
main. Plusieurs possibilits s'offrent lui. Il peut commander immdiatement le basculement de cellule : c'est de la reslection commande. S'il a accs aux informations de
configuration de la cellule cible, le BSC peut en envoyer une partie, ou la totalit au mobile avant de commander le basculement. C'est de la reslection assiste. S'il envoie la
totalit des informations systmes, le BSC peut galement rserver des ressources dans
la cellule cible et commander un handover. Le rseau peut enfin commander le passage
en mode NC-2. Cela permet au rseau de prendre le contrle de la liaison et vient
suspendre, du mme coup, la procdure de de basculement initie par le mobile. Le rseau peut alors, par la suite, dcider de procder un basculement (command, assist,
78
ou par handover).
4.3. Procdure dtaille de reslection dans le rseau d'accs GPRS

4.3.1. Dclenchement et prparation de la reslection
La dcision de reslection est prise en fontion de la valeur du paramtre NCO - soit
par le mobile, soit par le rseau - conformment aux critres dfinis dans [3GPP
45.008]. Si c'est le rseau qui prend la dcision de reslection, celui-ci envoie une commande de reslection au mobile : PACKET CELL CHANGE ORDER [3GPP
44.060][3GPP 44.160].
Lorsqu'une reslection de cellule est dcide par le mobile ou commande par le rseau,
le mobile doit continuer ses oprations sur la cellule courante jusqu' ce qu'il ait acquis
un certain nombre d'informations sur la cellule cible. La faon dont ces informations
vont tre rcupres va dpendre du mode de reslection : autonome ou assist par le rseau.
Dans les premires versions (Release 99 et antrieures) de la norme, la reslection est
forcment autonome. Dans les versions suivantes (Release 4 et suivantes) c'est le paramtre CCN qui va dfinir le mode de reslection. Si le paramtre CCN est inactif ou s'il
n'est pas indiqu, le mobile doit procder une reslection autonome. Si le paramtre
CCN est actif, il faut encore que la cellule cible choisie permette d'effectuer la reslection assiste. La cellule en question doit alors apparatre dans la liste des cellules qui
supportent le CCN (paramtre CCN_SUPPORTED). Cette liste est diffuse, soit dans le
message SI 2quat [3GPP 44.018] si le canal PBCCH n'est pas implment, soit dans le
message PSI 3. Les messages PACKET CELL CHANGE ORDER ou PACKET
MEASURMENT ORDER peuvent galement contenir le paramtre CCN_SUPPORTED. Si le CCN de la cellule courante est actif mais que la liste des cellules voisines qui
supportent le CCN n'est pas indiqu, le mobile doit supposer que toutes les cellules voisines supportent la reslection assiste.
4.3.2. Procdure de reslection autonome

Dans le cas de la reslection autonome [3GPP 44.060], le mobile doit se dbrouiller seul
pour effectuer la reslection. Le mobile doit alors rcuprer les informations de configuration de la cellule cible. Il doit, pour cela, dcoder les canaux BCCH et PBCCH de la
cellule cible. Pour ce faire, il peut suspendre son activit sur la cellule courante
Quand le mobile a rcupr toutes les informations de configuration de la cellule voisine, il doit immdiatement cesser toutes ses activits sur la cellule courante et basculer
sur la cellule voisine. Tous les TBF en cours sont alors abandonns.
79
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.
4.3.3. Procdure de reslection assiste par le rseau

La procdure de reslection assiste par le rseau [3GPP 44.060] doit tre dclenche
par le mobile lorsque la cellule courante supporte le mode CCN et que la cellule cible
choisie est ligible ce mode (Cf. paramtre CCN_SUPPORTED). Lorsque les critres
radio sont trop dfavorables (critre radio C1 devenu ngatif), le mobile est autoris
effectuer une reslection autonome. Il n'est en effet pas possible de maintenir sufisamment longtemps la communication dans l'ancienne cellule afin de procder une reslection assiste.
Le mobile qui veut procder une reslection assiste par le rseau va commencer par
prvenir le rseau de son intention de changer de cellule. Il envoie pour cela un message
PACKET CELL CHANGE NOTIFICATION . Ce message contient l'identit de la
cellule cible, identifi grce l'index ARFCN de sa voie balise et de son BSIC. Ce message doit galement contenir des rapports de mesure sur la cellule choisie et sur les six
meilleures voisines.
Si au bout du temporisateur T3210 (valeur par dfaut 0,3s) le mobile n'a pas reu de rponse du rseau (messages PACKET NEIGHBOUR CELL DATA , PACKET
CELL CHANGE CONTINUE , PACKET CELL CHANGE ORDER ou PS
HANDOVER COMMAND ) il doit renvoyer un message PACKET CELL
CHANGE NOTIFICATION . Si le temporisateur T3208 expire (valeur par dfaut
0,98s), ou si le critre C1 devient ngatif, le mobile doit procder une reslection autonome.
A la rception du message PACKET CELL CHANGE NOTIFICATION , plusieurs
options s'offrent au rseau.
80
Le rseau peut demander au mobile de faire une reslection autonome en envoyant

un message PACKET CELL CHANGE CONTINUE . Dans ce cas, le mobile
doit reslectionner de faon autonome la cellule qu'il avait indiqu dans le message
PACKET CELL CHANGE NOTIFICATION initial.
Le rseau peut commencer diffuser les informations de configuration de la cellule

cible, ncessaires la reslection. Ces informations sont transmises dans une srie
de messages PACKET NEIGHBOUR CELL DATA . Le rseau envoie ensuite
un message PACKET CELL CHANGE CONTINUE pour inviter le mobile
continuer sa reslection de faon autonome.
Le rseau peut commencer diffuser les informations de configuration de la cellule

cible ncessaires la reslection puis envoyer un message PS HANDOVER
COMMAND , indiquant au mobile sur quelle ressource il doit basculer. Il s'agit
alors d'un handover contrl par le rseau.
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.
4.3.4. Procdure de reslection commande par le rseau

La reslection peut tre commande par le rseau lorsque celui-ci opre en mode NC-2
[3GPP 44.060]. Le rseau dcide alors de la cellule vers laquelle le mobile va basculer.
Il peut envoyer des informations au mobile sur la cellule voisine avant de dclencher la
reslection (tout comme dans le cas de la procdure de reslection assiste par le
rseau). Une fois reu l'ordre de basculement ( PACKET CELL CHANGE ORDER ),
le mobile effectue la procdure de reslection de cellule.
4.3.5. Contraintes de temps pour la procdure de reslection

En cas de reslection autonome, aucune contrainte de temps ne semble avoir t dfinie.
Le mobile reslectionne la cellule cible et a tout le temps de le faire.
En cas de reslection commande par le rseau, la rception du message PACKET
CELL CHANGE ORDER , le mobile doit stopper les temporisateurs associs la
couche RLC/MAC et dmarrer le temporisateur T3174 (ayant une valeur par dfaut de
15 secondes). Si ce temporisateur expire avant que la procdure de reslection ait t
complte, le mobile doit dmarrer le temporisateur T3176 (valeur par dfaut : 5 secondes dans la version 99 [3GPP 04.60] de la norme, 15 secondes dans la version 6
[3GPP 44.060]), slectionner l'ancienne cellule et envoyer un message PACKET
CELL CHANGE FAILURE .
81
4.4. Procdure dtaille de Handover dans le rseau d'accs E-GPRS

Cette partie prsente la procdure radio de handover, puis introduit les diffrentes procdures qui permettent la reconfiguration du rseau d'accs dans le cas des handovers
intra-cellulaires, intra et inter-BSC. Le cas du handover inter-SGSN et les solutions de
mobilit inter-rseau font l'objet de l'annexe G.
4.4.1. Procdure radio

Les mcanismes de handover ont t introduits dans la release 6 de la norme [3GPP
44.060][3GPP 44.160][3GPP 43.129]. Leur implmentation est optionnelle (tant du cot
mobile que du cot rseau).
Si le mobile est dans le mode NC2, la procdure de handover peut tre dclenche par le
rseau. Quand le mobile travaille en mode NC0 ou NC1, la procdure de handover peut
tre initi suite la rception d'un message PACKET CELL CHANGE NOTIFICATION envoy par le mobile. Le rseau peut alors demander au mobile de basculer
dans le mode NC2 via un message PACKET MEASUREMENT ORDER .
Une fois la dcision de handover prise, le rseau doit envoyer les informations de configuration de la cellule cible au mobile. Cela est fait via des messages PACKET
NEIGHBOUR CELL DATA , dans lesquels sont encapsuls les messages System
Information de la cellule cible. Une fois les informations de configuration transmises
au mobile, le rseau peut lui envoyer la commande de handover : PACKET HANDOVER COMMAND .
Le message de commande de handover contient le descriptif des ressources attribues
au mobile dans la cellule cible. Cette allocation contient forcment un TBF montant qui
va permettre au mobile d'envoyer le message PS HANDOVER ACCESS . Ces messages permettent au rseau de dtecter l'arrive du mobile dans la cellule cible.
Le message de commande de handover indique galement si le mobile doit maintenir
ses tats de transmission RLC/MAC ou s'il doit crer une nouvelle machine tat (dans
ce cas, les blocs RLC en cours de transmission dans l'ancienne cellule sont perdus).
Compte tenu de l'absence d'interface entre deux BSC et de la difficult que reprsente la
synchronisation de deux automates distants, il est actuellement difficilement envisageable de maintenir l'tat de la transmission au niveau RLC/MAC dans le cas d'un handover inter-BSC.
Pendant la phase de handover, le rseau doit ignorer toute nouvelle demande d'ouverture
de TBF en provenance du mobile. Ceci permet d'viter de gnrer des pertes en initialisant de nouvelles transmissions.
A la rception de la commande de handover, le mobile doit envoyer un acquittement au
rseau si ce dernier le demande (via le champ RRBP). Le mobile doit ensuite suspendre
toute activit dans la cellule courante puis basculer vers la cellule cible et y rtablir sa
82
transmission en envoyant quatre fois le message PS HANDOVER ACCESS sur les

ressources montantes qui lui ont t rserves. Au moment de l'envoi du premier message PS HANDOVER ACCESS , le mobile doit par ailleurs dmarrer le temporisateur T3216 (valeur par dfaut 1 seconde). Si ce timer expire avant rception des
informations de synchronisation envoyes par le rseau (message PACKET PHYSICAL INFORMATION ), le mobile doit considrer que le handover a chou. Il doit
retourner dans son ancienne cellule et envoyer un message PACKET CELL
CHANGE FAILURE contenant la cause de l'chec.
Quand le mobile reoit le message PACKET PHYSICAL INFORMATION , il doit
considrer que le handover a russi et que tous les TBF de son ancienne cellule ont t
librs. Les tats de transmission RLC/MAC doivent tre conservs ou rinitialiss,
conformment aux directives contenues dans le message de commande de handover. Le
mobile doit alors rtablir la transmission et effectuer les procdures GMM ncessaires
sa localisation.
Pendant le droulement du basculement, tous les temporisateurs associs la transmission RLC/MAC continuent de s'couler tout au long de la procdure. Si les temporisateurs T3180, T3190 ou T3192, lis un TBF de l'ancienne cellule expirent, le mobile
doit considrer que ces TBF ont t relchs : ces TBF ne pourront alors pas tre poursuivis dans la nouvelle cellule.
4.4.2. Le handover intra-cellulaire

Le handover intra-cellulaire permet de reconfigurer les ressources attribues un mobile dans une cellule. Ce type de handover a toujours exist dans GPRS. Cela est ralis
trs simplement via les messages qui permettent de reconfigurer les ressources attribues un mobile : PACKET TIMESLOT RECONFIGURE .
4.4.3. Le handover intra BSS

Dans la norme, le BSS Base Station Subsystem est dfini comme tant compos
d'un contrleur de station de base (BSC) et d'un ensemble de BTS. Les termes intraBSS et intra-BSC sont donc ici synonymes.
Deux procdures de handover intra-BSS ont t dfinies. La procdure gnrale est applicable tout handover ayant lieu au sein du mme BSS. Elle n'entrane donc pas de
changement de SGSN. La procdure optimise s'applique lorsque le handover n'entrane
pas de changement de BSC, ni de zone de routage : le handover peut alors tre contrl
localement au niveau du BSC.
83
Phase de prparation du Handover

La phase de prparation de handover (Cf. figure 4.4.3.1) dbute avec la prise de dcision du BSC de dclencher un handover . Le BSC contacte alors de SGSN qui dtermine le type de handover dont il s'agit (intra BSC, inter-BSC, inter-SGSN...). Le
SGSN rpond par un message dans lequel il attribue un nouveau P-TMSI si la cellule
cible se trouve dans une autre zone de routage . Le BSC rserve alors des ressources dans la cellule cible et cre le contexte associ la nouvelle transmission
(contexte dnomm dans la norme et sur la figure 4.4.3.1 Target BSS to Source BSS
Transparent Container ). Le BSC prvient alors le SGSN (5) via une message PS
Handover Request Acknowledge - qu'il est prt pour effectuer le handover. Le SGSN
peut alors dupliquer les trames LLC vers le BSS (1) : un datagramme destination de
l'ancienne cellule et un pour la nouvelle.
Figure 4.4.3.1. Phase de prparation du handover intraBSS [3GPP 43.129]
Phase d'excution du Handover

La phase d'excution du handover est reprsente sur la figure 4.4.3.2. Si le BSC reoit
des donnes du SGSN destination de la nouvelle cellule, il les transmet sans se proccuper du fait que le mobile y est prsent ou non (transmission en aveugle ) . Le
SGSN dclenche ensuite le handover en envoyant un message PS Handover Required
Acknowledge au BSC . A ce stade, le SGSN peut suspendre la transmission de tous
les contexte PDP associs au mobile, il peut galement attendre que les piles de transmission du BSS soient vides avant de dclencher le handover.
On remarquera que le constructeur est libre d'implmenter diffrents comportements au
niveau du SGSN. Ce dernier peut continuer ou non la transmission associe au contexte
PDP. En cas de continuation, il peut dupliquer la transmission des trames. En cas de
84
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.
Figure 4.4.3.2. Phase d'excution du Handover Intra-BSS

[3GPP 43.129]
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
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.
Figure 4.4.3.3. Handover optimis : intra-BSC /

intra RA [3GPP 43.129]
86
Aprs avoir dcid du dclenchement du handover et constat qu'il tait mme de le

prendre lui mme en charge , le BSC rserve des ressources pour le mobile dans la
cellule cible (qui est sous son contrle). Le BSC envoie ensuite la commande de handover au mobile . Les mmes options que dans le cas non optimis peuvent tre retenues concernant la suspension de la transmission et le stockages des donnes. La station
mobile bascule alors vers la cellule cible et indique son accession au canal . Le rseau
envoie au mobile alors les informations d'avance en temps et de contrle de puissance
. Le mobile rtablit sa transmission en envoyant des donnes . Il n'est pas ncessaire
ici d'effectuer une mise jour de zone de routage. Le BSC informe ensuite le SGSN
qu'il vient de procder un handover intra-BSC . Le BSC indique galement dans ce
message quelle est la cellule cible. Le BSC envoie galement un acquittement au mobile
afin de lui indiquer o en est la transmission . Le SGSN envoie alors les trames LLC
destination de la nouvelle cellule, identifie par le BVCI BSSGP Virtual Connection
Identifier.
4.4.4. Handover inter-BSS / Intra-SGSN

Tout comme le handover intra-BSS, le handover inter-BSS est constitu d'une phase de
prparation du handover (qui correspond des changes de signalisation entre les diffrentes entits du rseau en vue de prparer l'accueil du mobile dans la nouvelle cellule
et d'assurer le basculement de la communication) et une phase d'excution (qui sert
dclencher le changement de cellule et effectuer le basculement).
Phase de prparation du Handover
La phase de prparation du handover inter-BSS, reprsente sur la figure 4.4.4.1, est assez semblable celle du handover intra-BSS. La seule diffrence rside dans le fait que
le SGSN va contacter le BSC cible pour lui demander de prparer l'accueil du mobile
(le BSC source et le BSC cible tant cette fois diffrents). Le BSC cible rserve alors
des ressources dans la cellule cible, puis cre un contexte associ au mobile, contexte
dcrit dans le Target BSS to Source BSS Transparent Container . Ce contexte est
alors transmis au SGSN .
87
Figure 4.4.4.1. Phase de prparation du handover inter-BSS [3GPP

43.129]
Phase d'excution du Handover

La phase d'excution du handover est fournie sur la figure 4.4.4.2. Aprs la phase de
prparation, et avant de commander l'excution du handover, le SGSN a la possibilit de
suspendre la transmission et ventuellement attendre que les buffers du BSS source
soient vides. Il peut galement dupliquer la transmission vers les deux BSS.
Figure 4.4.4.2: Phase d'xcution du handover inter-BSS [3GPP 43.129]
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).
5. Simulation des handovers dans le systme GPRS

Un simulateur de rseaux cellulaires de type GPRS a t implment afin d'valuer les
performances des handovers. Cette partie se propose de prsenter le fonctionnement du
simulateur. Cette prsentation dbute par un rapide aperu de la structure du simulateur.
Nous prsentons ensuite les quipements et les interfaces qui ont t modliss, la pile
protocolaire et les procdures implmentes. Enfin, nous terminons par une prsentation
des paramtres de configuration par dfaut qui ont t choisis.
5.1. Aperu de la structure du simulateur

Ce simulateur a t crit en Java, un langage orient objet. Les objets qui ont t raliss
dans le cadre de ce simulateur peuvent tre classs en diffrents groupes, appels packages . La liste des groupes est reprsente sur la figure 5.1.1. Ils permettent de se
faire une ide sur la faon dont est structur le simulateur.
Deux groupes rassemblent les quipements : ceux ct rseau - package equipements - et les mobiles - package mobiles . Quand un mobile est attach au rseau, il
possde dans chaque quipement un contexte sur l'tat de la transmission. Ces contextes
sont contenus dans le package contextes . Des interfaces, issus du package interfaces , permettent de relier les diffrents quipements entre eux. Les lments qui circulent sur les interfaces sont appels messages. Ils sont contenus dans le package messages .
Les diffrentes couches de la pile protocolaire sont modliss grce au objets contenus
dans le package couchetransport . Les donnes qui sont traites par ces couches sont
modlises grce aux objets de la couche donnees . On notera que les packages
couchetransport et donnees sont structurs en sous packages qui permettent de
sparer les diffrentes couches. Par exemple, le sous package couchetransport.rlc
contient les objets qui permettent de modliser le comportement de la couche RLC et le
sous package donnees.rlc contient les objets qui permettent de modliser les blocs
RLC.
89
Figure 5.1.1. Liste des packages du simulateur
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
5.2. Modlisation des quipements rseau

La liste des quipements du rseau GSM/GPRS qui ont t implments est reprsente
sur la figure 5.2.1. Aux deux extrmits du rseau, on trouve le mobile et le serveur. Ils
grent tous les deux la gnration des donnes : en voie montante pour le mobile, en
voie descendante pour le rseau. Les autres quipements assurent le transfert des donnes sur les diffrentes interfaces. Ils assurent le routage des donnes et implmentent
les piles protocolaires ncessaires l'excution et la fiabilisation de la transmission.
Certaines procdures sont implmentes afin de grer l'attachement du mobile, son dtachement et les handovers.
Un point d'accs WLAN a t implment afin de mener des tudes sur le handover
inter-systmes. Ces tudes font l'objet du chapitre III.
Figure 5.2.1. Equipements du rseau qui ont t modliss
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
5.3. Modlisation de la pile protocolaire

La pile protocolaire implmente est reprsente sur la figure 5.3.1. Deux interfaces
radio ont t modlises : une pour GPRS (RLC et MAC-GPRS) et une pour le WLAN
(MAC-WIFI). Les stations mobiles et les contrleurs de stations de base implmentent
bien videmment les deux piles. Les stations de base n'apparaissent pas sur cette pile.
Elles n'implmentent pas de mcanisme de fiabilisation mais servent plutt de relais
entre l'interface filaire qui les relie leur contrleur et l'interface Air qui les relie au mobile.
Le protocole RLC a t implment dans le cas du GPRS conformment au descriptif de
la partie 3.3 . Cette couche [3GPP 44.060] effectue la segmentation et le rassemblage
des datagrammes LLC en blocs RLC dont la taille dpend du schma de codage utilis
sur l'interface radio.
Deux couches LLC ont t dfinies. Celle qui est localise dans le SGSN est note SLLC (SGSN-LLC). Elle correspond la couche LLC du systme GPRS [3GPP 44.064],
dcrite dans la partie 3.4. Une autre est situe au niveau du BSC. Elle est note R-LLC
(Radio-LLC). Ces deux couches alternatives ont la mme fonctionnalit : assurer la fiabilisation du transfert au niveau trame sur l'interface radio. L'intrt de localiser la
couche LLC au niveau du BSC sera mis en vidence par la suite. En mode non acquitt,
ces couches ne servent que de relais. Elles sont transparentes pour la transmission.
Figure 5.3.1. Modlisation de la pile protocolaire
En mode acquitt, le mcanisme de retransmission implment au niveau LLC est un

mcanisme fentre glissante et retransmission slective. Il n'y a pas de mcanisme de
retransmission prventive. Le temps de retransmission est effectu chance d'un timer. La taille de la fentre et la valeur du timer de retransmission sont des paramtres
de notre simulation. Leur choix sera justifi par la suite.
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.
5.4. Procdures implments dans le simulateur

Afin de simuler le comportement du mobile dans le rseau, plusieurs procdures essentielles notre tude ont du tre implmentes : attachement et dtachement du mobile,
reslection intra et inter-BSC, handover intra et inter-BSC. Le dtail de ces procdures
est fourni ici. Elles correspondent des versions simplifies des procdures relles.
Tous les changes de messages, comme les ventuelles phases d'authentification et de
mise jour de localisation n'apparaissent pas. Pour l'tude des pertes et des temps de
coupure, il faut particulirement prter attention aux instants de suspension et de rtablissement des transmissions, ainsi qu'aux phases de libration des contextes associs
aux mobiles.
93
5.4.1. Procdure d'attachement

La procdure d'attachement, prsente sur la figure 5.4.1.1, est dclenche par un mobile lors de son arrive dans le rseau. Le mobile commence par envoyer un message de
demande d'attachement la station de base, message qui est relay au BSC . A ce
stade, la transmission est inactive. Le BSC cre alors un contexte associ ce mobile
puis relaie la demande d'attachement au SGSN . Tous les quipement intermdiaires,
SGSN, GGSN et Serveur, font de mme . Par ailleurs, le serveur active le gnrateur
de trafic associ au mobile, ce qui active galement la transmission vers le mobile. Le
serveur envoie un message de confirmation d'attachement sur le chemin retour . Les
quipements intermdiaire relaient ce message tout en activant la transmission en voie
montante et descendante . A la rception de la confirmation d'attachement, le mobile active la transmission de donnes en voie montante . La transmission duplex est
alors tablie .
Figure 5.4.1.1. Procdure d'attachement au rseau
5.4.2. Procdure de dtachement

La procdure de dtachement prsente sur la figure 5.4.2.1 - s'effectue de manire
analogue la procdure d'attachement. Initialement, le mobile est attach au rseau .
Le mobile peut alors dcid de dclencher le dtachement.
94
Figure 5.4.2.1. Procdure de dtachement
Avant de dclencher le dtachement, on vrifie qu'une autre procdure n'est pas en

cours (par exemple, un handover ou une reslection). Une fois cette vrification effectue, le dtachement peut avoir lieu. Dans le simulateur, la procdure peut tre dclenche immdiatement ou aprs vrification que tous les quipements ont termin leur
transmission vers le mobile. Si des donnes sont encore en cours de transmission, le dtachement est alors report une date ultrieure. L'intrt de cette vrification est de
s'assurer que les pertes mesures sont dues aux erreurs de transmission ou aux autres
procdures comme par exemple les handovers - et non un transfert qui n'aurait pas
abouti avant le dtachement du mobile.
Une fois la procdure de dtachement dcide, le mobile suspend la transmission en
voie montante, puis envoie un message de dtachement la station de base , qui est
relay jusqu'au BSC . Les quipements intermdiaires BSC, SGSN, GGSN
suspendent galement leur transmission vers le mobile et relaient la demande de dtachement . Le serveur dsactive alors la transmission en voie descendante, dtruit
le contexte associ au mobile, et envoie un message de confirmation de dtachement au
GGSN . Les quipements intermdiaires GGSN, SGSN et BSC - dtruisent le
contexte associ au mobile puis relaient le message . A la rception du message
de confirmation de dtachement, le mobile se retire du rseau .
5.4.3. Procdure de reslection intra-BSC

La procdure de reslection intra-BSC est reprsente sur la figure 5.4.3.1. Le mobile
est initialement attach cellule n1 . Lorsqu'il dcide de sa reslection, le mobile
suspend ses activits sur la cellule courante et rcupre les informations de configuration de la station de base n2. Une fois le paramtrage de la cellule rcupr, le mobile
95
demande l'attachement la cellule n2 . La station de base relaie alors le message jusqu'au BSC .
Figure 5.4.3.1. Procdure de reslection intra-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.
5.4.4. Procdure de reslection inter-BSC

La procdure de reslection inter-BSC dcrite sur la figure 5.4.4.1 - dbute comme la
procdure intra-BSC . A la rception de la demande de reslection du mobile ,
le BSC dtecte que la cellule d'origine du mobile n'est pas sous son contrle. Le BSC
contacte alors le SGSN pour demander ce que la communication soit transfre vers
lui : il y a alors une demande de basculement ou de relocalisation - qui est transmise au SGSN. A la rception de cette demande, le SGSN commute la transmission
vers le nouveau BSC et lui envoie un message d'acquittement de basculement . Il
informe ensuite l'ancien BSC du basculement. Ce dernier supprime alors le contexte associ au mobile '. A la rception du message d'acquittement du basculement, le nouveau BSC envoie un message d'acquittement au mobile . Ce dernier ractive alors la
transmission montante . La transmission est alors totalement rtablie.
96
Figure 5.4.4.1. Procdure de reslection inter-BSC / intra SGSN
5.4.5. Procdure de handover intra-BSC

La procdure de handover prsente sur la figure 5.4.1.1 est dclenche par le rseau. Le mobile est initialement attach la BTS n1 . Il remonte de faon priodique
des rapports de mesures qui permettent au BSC d'valuer la qualit du lien radio . Les
rapports de mesures sont relays, sans tre interprts, par la station de base . A la
rception d'un rapport de mesures, le BSC value les diffrents paramtres de qualit de
la liaison qu'il possde et dcide de l'opportunit de transfrer le mobile dans une autre
cellule Il peut alors dcider de dclencher un handover.
Une fois que le BSC a pris la dcision de dclencher un handover pour un mobile donn, il commence par regarder si la cellule cible choisie est sous son contrle. Si c'est le
cas, il s'agit d'un handover intra-BSC. Le BSC rserve alors des ressources sur la cellule
cible, suspend la transmission de donnes, et envoie un message de commande de handover destination du mobile . Ce message est relay de faon transparente par la station de base . A la rception de ce message, le mobile suspend sa transmission montante et bascule vers la cellule cible. Une fois synchronis avec cette dernire, le mobile
envoie un message qui va permettre au rseau de dtecter le basculement et reprend
sa transmission montante. A la rception de ce message, le BSC rtablit la transmission
descendante vers la nouvelle cellule .
97
Figure 5.4.5.1. Procdure de Handover intra-BSC
5.4.6. Procdure de handover inter-BSC

La procdure de handover inter-BSC dcrite sur la figure 5.4.6.1 dbute de la mme
faon que la procdure de handover intra-BSC . Lorsque le BSC prend la dcision
de handover , il constate que la cellule cible choisie n'est pas sous le contrle du
mme BSC. Il contacte donc le SGSN pour demander le basculement de la connexion
vers le BSC cible. A la rception du message de demande de basculement, le SGSN
contacte le BSC cible afin de commander la cration d'un contexte associ au mobile
et la rservation de ressources radio. Une fois la rservation de ressources effectue, le
BSC cible envoie un message d'acquittement au SGSN . Le SGSN bascule alors la
transmission des donnes vers le BSC cible. Il envoie ensuite un message au BSC pour
lui signifier que le BSC cible est prt accueillir le mobile . A la rception de ce message, le BSC suspend la liaison descendante et envoie un message de commande de
handover au mobile . A la rception de ce message, le mobile bascule vers la cellule
cible et envoie un message au nouveau BSC . Ce dernier dtecte alors la prsence du
mobile et active la transmission descendante. A ce stade , la transmission est rtablie.
Le BSC informe le SGSN que la phase de handover est termine. Le SGSN se charge
alors de relayer l'information au BSC d'origine afin que ce dernier supprime le contexte
associ au mobile .
98
Figure 5.4.6.1. Procdure de Handover inter-BSC / intra-SGSN
5.4.7. Reslection commande et assiste

Nous n'avons pas implment ici de procdure spcifique pour la reslection commande ou assiste. Ces procdures restent fondamentalement les mmes que la procdure
de reslection simple, la diffrence prs que l'ordre de dclenchement de la procdure
est envoy par rseau. Toutefois, dans le cas de la reslection assiste, le temps de rcupration des informations systme sera rduit, voire nul. Il faut donc dans ce cas considrer un temps de coupure de la transmission plus rduit.
5.5. Description et paramtres du systme simul

Nous nous proposons ici de prsenter les paramtres de simulation par dfaut qui ont t
choisis. Les simulations qui sont tudies par la suite drivent tous de ce modle de rfrence.
5.5.1. Configuration du rseau

Nous considrerons un rseau deux cellules. Ces deux cellules pourront tre relies au
99
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
SGSN BSC (1 seul BSC)
100 ms
500 kbits/s
SGSN BSC (2 BSC)
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.
Figure 5.5.1.1. Trajectoire d'un mobile au cours d'une simulation
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
5.5.2. Gestion des utilisateurs

On considre deux profils d'utilisateurs. Ils ont tous deux une capacit multislot
4+1 : ils peuvent recevoir sur 4 slots et mettre sur 1 slot. Ces deux profils n'utilisent
cependant pas le mme schma de codage. Le premier groupe d'utilisateurs utilise un
schma de codage offrant un dbit de 13kbits/s (comme MCS-2) et le second groupe, un
schma de codage offrant un dbit de 20kbits/s. On considre un taux d'arriv de un mobile par minute pour chacun de ces deux groupes. Par ailleurs, pour viter la surcharge
du rseau, on limite 20 le nombre de mobiles dans le rseau.
La condition d'arrt du simulateur repose sur le nombre de mobiles que l'on accueille
dans le rseau (sachant que chaque mobile effectue un handover). Quand on a atteint le
nombre de mobiles introduit dans le rseau 10000 par groupe - on stoppe le gnrateur
de mobiles. Une fois que tous les mobiles se sont dtachs, la simulation se termine.
5.5.3. Taille des donnes

Dans la configuration par dfaut, les trames sont acquittes au niveau TCP/IP, non
acquittes au niveaux LLC (S-LLC ou R-LLC), acquitts au niveau RLC. La taille utile
des paquets et de leurs en-ttes sont fournis dans le tableau 5.5.3.1.
Type de Donnes
Champ de donnes utile
Taille de l'en-tte
Paquet TCP/IP ou UDP/IP
11500 bits au maximum
40 bits
Trame S-LLC
Taille paquet IP
40 bits
Trame R-LLC
Taille trame S-LLC
40 bits
Bloc RLC
Dpend du schma de codage
40 bits
Tableau 5.5.3.1. Taille des trames de donnes
La taille maximale du champ de donnes utile d'un bloc RLC est calcule suivant la formule :
Taille Bloc RLC=
Dbit Codage (bits/s)20ms

Taille de l'En-Tte
1000
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
internet (entre le SGSN, le GGSN et le serveur web).
5.5.4. Gnrateurs de trafics

Trois types de gnrateurs de donnes ont t utiliss : un gnrateur dit persistant ,
un gnrateur de trafic de type HTTP et un gnrateur flux continu. Sauf indication
contraire, c'est le gnrateur de trafic persistant qui est utilis dans la plupart des simulations.
Gnrateur de trafic HTTP
Le gnrateur de trafic HTTP est dcrit dans [ETSI TR 101 112]. Ce modle, assez
complexe, a t dfini dans le cadre des tudes qui ont t menes en vue de la normalisation de l'UMTS. Ce modle n'est pas bas sur des mesures relles et les rsultats qu'il
produit sont difficiles tudier de manire analytique [Klem01].
Ce modle vise reproduire le comportement d'un utilisateur sur un rseau mobile. L'utilisateur ouvre et ferme des session. Au cours de sa session, l'utilisateur va consulter
des pages HTML (ou WAP). L'affichage de ces pages requiert le tlchargement des
contenus multimdia qu'elles contiennent : images, frames, feuilles de style, musiques,
vidos... Le profil de trafic obtenu ressemble alors celui de la figure 5.5.4.1.
Figure 5.5.4.1. Profil de trafic HTTP
Les sessions arrivent dans le systme en suivant un processus de Poisson. Le nombre de

pages appeles au cours d'une session, le temps qui s'coule entre deux appels de pages
(ou temps de consultation de la page), le nombre d'objets par page et le temps qui s'coule entre deux appels d'objets suivent une loi gomtrique. Enfin, la taille des objets
d'une page suit une loi de Pareto tronque. Les paramtres de ces lois, tels qu'ils sont dfinis dans [ETSI TR 101 112], sont rappels dans le tableau 5.5.4.1.
Les paramtres de la loi de Pareto tronque (ou Cut Off) conduisent une taille
moyenne des paquets de 480 octets. Les paramtres que l'on peut faire varier sont le
temps d'inter-arriv des sessions et le temps qui spare deux chargements d'objets.
102
Paramtres
Loi
Valeurs
Temps entre deux sessions
Exponentielle
Non prcis
Nombre de pages charges par session
Gomtrique
Valeur moyenne = 5
Temps de consultation d'une page
Gomtrique
Valeur moyenne = 412s
Nombre d'objets par page
Gomtrique
Valeur Moyenne = 25
Temps entre deux chargements d'objets
Gomtrique
Valeur Moyenne < 1s
Taille des objets
Pareto Cut-Off
K=81,5 ;
=1,1 ;
m=66 666 octets
Tableau 5.5.4.1. Paramtres du modle de trafic HTTP
Notons Np le nombre de pages par session, Tp le temps de consultation d'une page, No le

nombre d'objets par page, To le temps qui s'coule entre deux chargements d'objets et S
la taille d'un objet (480 octets). Exprimons Dc le dbit ncessaire au chargement d'une
page et Ds le dbit moyen tout au long d'une session.
Dc=
DS=
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
Gnrateur de trafic flux continu

Pour le gnrateur de trafic dbit constant, on gnre priodiquement, intervalle fixe,
un nouvel objet. La taille de l'objet suit la mme loi de Pareto tronque que les gnrateurs prcdents. Ce type de gnrateur vise simuler un trafic en flux continu (Streaming) qui permet de modliser, par exemple, des trafics vocaux ou du transfert de donnes en streaming, qu'il soit vocal ou vido.
6. Performances du transfert inter-cellulaire dans le rseau GPRS

Cette partie tudie les performances de diffrentes approches de reslection et de handover qui peuvent tre mises en oeuvre pour raliser un transfert inter-cellulaire dans un
rseau GPRS. Aprs un rapide rappel des stratgies tudies, nous analysons les rsultats de diffrentes sries de simulations. Les rsultats nous permettent de souligner les
avantages et inconvnients de chaque approche de transfert inter-cellulaire.
Tout d'abord, nous valuons les performances du transfert inter-cellulaire / intra-BSC.
Nous y valuons en particulier les gains de performance apports par le maintien des
contextes de transmission au niveau RLC. Nous valuons ensuite l'influence du temps
de basculement et de rcupration des informations systmes sur la procdure de reslection. Cette partie permet d'valuer les gains de performances apports par la reslection assiste, o le temps ncessaire au rtablissement de la transmission est plus
faible. La partie suivante est consacre l'valuation des performances du handover
inter-BSC / intra-SGSN. Enfin, la dernire partie analyse l'influence de la taille des buffers de transmission, implments au niveau de la station de base, sur les performances
des procdures de basculement.
6.1. Transfert inter-cellulaire / intra-BSC

Dans cette partie, nous considrons deux cellules relies au mme BSC. C'est le modle
de trafic persistant (Cf. 5.5.4) qui est ici considr. On fait varier le temps de basculement entre 0 et 5 secondes. En cas de reslection, le mobile met 8 secondes pour rcuprer les informations systme et procder une rservation de ressources. Ce choix a
t fait en considrant la priodicit minimale de diffusion de certaines informations
systme : une fois toutes les 32 trames 51 ( 32514,62ms = 7,54s) [3GPP 45.002].
Pour le handover et la reslection, deux approches ont t analyses. Dans la premire
approche, le changement de cellule entrane la perte du contexte RLC associ la transmission. Le TBF est rinitialis et quelques blocs RLC sont perdus. Dans la seconde approche, on maintient les tats de transmission au niveau RLC. Les blocs RLC perdus
lors de la procdure de basculement sont retransmis au moment de la restauration de la
transmission dans la nouvelle cellule.
104
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.
Figure 6.1.1. Dure de la procdure de transfert inter-cellulaire
Pertes aux niveaux MAC et RLC

Les figures 6.1.2 et 6.1.3 prsentent les pertes de bloc au niveau RLC/MAC.
Les figures 6.1.2 reprsentent la diffrence entre le nombre de blocs mis et le nombre
de blocs reus, ce qui correspond aux pertes au niveau MAC. Sur le lien montant, il y a
trs peu de pertes. En cas de reslection, seul le bloc en cours de transmission sur l'interface Air au moment du basculement peut tre perdu. A noter que dans le cas rel, il est
probable que le mobile termine la transmission du bloc courant avant de dcider du basculement. Les blocs RLC dj parvenus la station de base, quoi qu'il arrive, sont transmis jusqu'au BSC (qui peut ventuellement les ignorer). Lorsque le mobile reoit l'ordre
de handover, il suspend sa transmission montante avant de basculer. Aucun bloc RLC
n'est alors perdu.
105
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
Blocs RLC transmis au cours de la simulation

Les figures 6.1.4 prsentent le nombre de blocs RLC transmis au cours de la simulation.
On peut constater que dans le cas du handover, un plus grand nombre de blocs RLC
sont transmis. En effet, dans ce cas, le temps de suspension de la transmission est plus
court que dans le cas de la reslection. Cela se constate galement par une lgre dcroissance du nombre de blocs transmis lorsque le temps de basculement augmente.
Figure 6.1.4. Nombre moyen de blocs RLC transmis par mobiles
Temps de transmission au niveau RLC

Les figures 6.1.5 prsentent les temps moyens de transmission des blocs RLC. Comme
on peut le constater, les performances en terme de temps de transmission sont trs
proches, quelle que soit la stratgie choisie. Seule la stratgie de reslection, sans rinitialisation de la couche RLC, prsente des performances moindres. Si l'on se concentre
sur le sens descendant, on constate que la stratgie qui prsente les meilleures performances est la reslection simple. D'une part, les blocs perdus ne sont pas retransmis et,
d'autre part, pendant le temps de basculement, le mobile ne gnre aucun trafic. Le rseau est moins charg et les transmissions sont plus rapides.
La reslection sans rinitialisation de la couche RLC engendre des dlais de transmission importants. Quand le mobile bascule, les blocs perdus doivent tre retransmis. La
charge subie par le rseau au moment de la reprise de la transmission est alors son
maximum. Il faut retransmettre les blocs perdus et ventuellement les trames issues des
retransmissions aux niveaux suprieurs (mcanisme de retransmission TCP dans notre
cas). Par ailleurs, les blocs RLC dlivrs aprs le basculement subissent un retard au
moins gal au temps de basculement, ce qui vient fortement dgrader le temps moyen
de transmission.
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).
Figure 6.1.5. Temps de transmission des blocs RLC
Pertes au niveau LLC

Les figures 6.1.6 prsentent le nombre de trames perdues au niveau LLC au cours d'un
handover. Ces courbes sont mettre en regard des figures 6.1.3, qui mesurent les pertes
au niveau RLC. On peut noter que, dans le sens montant, moins d'une trame en
moyenne est perdue. Si au moment du basculement, il n'y avait aucune trame en cours
de transmission, aucun bloc n'a t perdu et, par consquent, aucune trame LLC. Cela
suppose galement que lorsqu'une trame LLC est en cours de transmission sur l'interface radio et qu'un basculement de cellule se produit, beaucoup plus de 6 blocs RLC
peuvent tre perdus. C'est le cas par exemple si le basculement se produit alors que la
trame LLC vient peine d'tre segmente par la couche RLC.
Dans le sens descendant, on observe le mme profil de pertes au niveau LLC qu'au niveau RLC. La perte de 12 blocs en moyenne en cas de handover entrane une perte d'un
peu moins d'une trame en moyenne au niveau LLC. La perte d'un peu moins de 55 blocs
au niveau RLC entrane la perte de 5 6 trames en moyenne au niveau LLC.
109
Figure 6.1.6. Nombre de trames LLC perdues au cours d'un transfert inter-cellulaire
Temps de transmission au niveau LLC

Les figures 6.1.7 prsentent le temps de transmission des trames au niveau LLC. Ces figures mettent bien en vidence le gain de performance obtenu dans le cas d'un handover, o le temps de basculement est plus faible. Le dlais de transmission au niveau
LLC pour les stratgies de reslection souffre du retard de dlivrance induit par la
suspension temporaire mais sensible de la transmission. Dans le cas o la couche
RLC n'est pas rinitialise, le nombre de trames dont la dlivrance est retarde est plus
important et la charge subie au moment de la reprise de la communication est plus leve, d'o des performances plus mauvaises. A noter que dans ce cas, le nombre de
trames retardes, et donc qui viennent impacter les statistiques, sont plus nombreuses du
fait qu'il n'y a aucune perte. Les trames LLC qui sont perdues dans le cas o on rinitialise la couche RLC n'ont aucun impact sur les dlais de transmission.
Figure 6.1.7. Temps de transmission des trames LLC
110
Pertes au niveau TCP

Les figures 6.1.8 montrent le nombre de paquets TCP perdus par handover. Elles dcoulent directement des rsultats prsents sur la figure 6.1.6 relatifs aux pertes au niveau LLC. Les pertes prsentes ici ne concernent que les paquets TCP, et non les
acquittements. C'est pourquoi le nombre de paquets perdu est lgrement plus faible que
le nombre de trames LLC perdues (ces dernires pouvant contenir un paquet TCP ou un
acquittement).
Par ailleurs, est prsent ici la diffrence entre les paquets TCP mis et ceux reus.
Nous n'avons pas prsent la diffrence entre le nombre de paquets gnrs et le nombre
de paquets transmis : dans notre simulateur, nous considrons un mcanisme de retransmission TCP persistant, les pertes sont donc nulles.
Figure 6.1.8. Nombre de paquets TCP perdus par handover
Temps de transmission au niveau Application

Les figures 6.1.9 prsentent le temps de transmission des objets gnrs par la couche
application. Au niveau LLC (Cf. figure 6.1.2), nous avions vu que la stratgie de reslection prsentait un lger avantage en terme de temps de transmission par rapport la
stratgie de reslection avec conservation des tats RLC. Cet avantage est ici perdu
puisque les trames LLC perdues dans le cas de la reslection devront tre retransmises
grce au mcanisme de retransmission TCP. Ceci induit donc un dlai supplmentaire
pour la transmission des objets de la couche application. Bien que ces dlais soient
importants, ils sont cohrent au regard des conditions particulires de l'instant d'observation au moment d'un changement de cellule et de la charge du rseau.
111
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.
6.2. Reslection autonome et assiste, inter-cellulaire / intra-BSC

Dans la partie 6.1, nous avons compar les deux approches de transfert inter-cellulaire,
par handover et par reslection. Pour la reslection, nous avons considr une reslection autonome, o le mobile doit rcuprer la totalit des informations systmes de la
cellule cible avant de pouvoir rtablir la communication. Dans cette partie, nous allons
analyser les performances de la reslection assiste par le rseau, afin d'en mesurer les
avantages.
Pour cela, nous considrons la mme configuration de rseau que dans la partie 6.1.
Cette fois, nous considrons deux valeurs pour le temps de basculement - 2 et 5 secondes et nous faisons varier le temps de reslection entre 0 et 10 secondes.
Quelle que soit la stratgie adopte pour la reslection, le mobile devra forcment changer de cellule, c'est dire se synchroniser avec elle, procder une mise jour de localisation (Cell Update), puis la rservation d'un TBF. Ces tapes prennent raisonnablement 2 secondes. Suivant la stratgie adopte et surtout suivant la quantit d'informations que le mobile a acquis sur la cellule cible avant de procder au basculement le
mobile met plus ou moins de temps pour rcuprer les informations systme. Ce temps
112
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
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
Influence sur les dlais de transmission

Si le temps de coupure a peu d'impact sur les pertes, il n'en va pas de mme pour les dlais de transmission. Les figures 6.2.4 prsentent l'augmentation du dlai de transmission moyen au niveau RLC/MAC. On constate tout d'abord que ce temps de transmission est peu prs stable si on rinitialise les tats de transmission au niveau RLC. Les
blocs non transmis sont alors perdus et n'entrent donc pas dans les statistiques des dlais
de transmission. Par contre, dans le cas o les tats de la couche RLC sont prservs, le
temps de transmission moyen augmente proportionnellement au temps de coupure.
114
Figure 6.2.4. Temps moyen de transmission des trames RLC
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).
Figure 6.2.5. Temps moyen de transmission des objets de la couche application
Influence sur le dbit

En observant, sur les figures 6.2.6, le nombre de blocs RLC transmis par mobiles au
115
cours d'une simulation, on constate une dcroissance du nombre de blocs transmis

lorsque le temps pendant laquelle la transmission est suspendue augmente. On peut ainsi
valuer l'impact du transfert inter-cellulaire sur le dbit rel de l'utilisateur au cours de
sa session.
Figure 6.2.6. Nombre moyen de blocs RLC transmis par mobiles
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.
6.3. Transfert inter-cellulaire / inter-BSC / intra SGSN

Le but de cette partie est d'analyser les performances du transfert inter-BSC / intraSGSN. Pour ce faire, nous avons repris la configuration dfinie pour la partie 6.1, mais
en reliant les BTS deux BSC diffrents. Le nombre de canaux 16 kbits/s sur l'interface Abis ddis au trafic GPRS pour la premire cellule a t port 6 et dans la seconde, 8. Les rsultats obtenus sont compars ceux obtenus dans le cas du transfert
inter-cellulaire / intra BSC (Cf. partie 6.1).
On notera ici que la comparaison ne porte que sur les procdures de basculement avec
r-initialisation de la couche RLC. En effet, dans le cas du transfert inter-BSC, cette
couche n'tant pas localise dans le mme quipement, il n'est pas possible de maintenir
les tats de transmission au cours de la procdure de basculement. Par ailleurs, le transfert intra-BSC est prsent ici titre indicatif. L'architecture du rseau et le nombre de
116
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).
Figure 6.3.1. Dure de la procdure de basculement
Figure 6.3.2. Dure de la procdure de transfert intercellulaire (hors temps de basculement)
117
Pertes au niveau MAC et RLC

Les figures 6.3.3 prsentent le nombre de blocs MAC perdus au cours d'un transfert
inter-cellulaire. Il s'agit de la diffrence entre le nombre de blocs mis et le nombre de
blocs reus. On peut constater que les pertes sont du mme ordre pour le basculement
intra et inter-BSC. Les pertes semblent lgrement plus importantes dans le cas d'une
reslection inter-BSC. Pour le sens montant, la diffrence est trs faible. Comme cela a
dj t voqu prcdemment (Cf. 6.1), ces pertes devraient tre nulles si le mobile ne
quittait pas la cellule au milieu de l'mission d'un bloc. La diffrence de performance
peut s'expliquer par la configuration lgrement diffrente des deux rseaux. Dans le
sens descendant, la diffrence importante est due au fait que le temps de coupure est
plus long. Pendant ce temps, l'ancien BSC continu envoyer les donnes vers l'ancienne
BTS alors que le mobile a dj quitt la cellule.
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)
Pertes au niveau LLC et IP
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
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.
Figure 6.3.6. Nombre de paquets IP perdus au cours d'un transfert inter-BSC
Dlais de transmission au niveau RLC

Considrons maintenant les dlais de transmission. Au niveau RLC (Cf. figure 6.3.7), le
temps de transmission moyen des blocs RLC dans le sens montant est plus faible dans le
cas du transfert inter-BSC que dans le cas du transfert intra-BSC. Ceci s'explique essentiellement par les conditions de trafic qui sont plus favorables. Le temps de coupure de
la transmission pour les mobiles est plus important, ce qui entrane une moindre charge
du rseau. De plus, afin de compenser les gains de performances dus au partage des ressources entre plusieurs cellules sur l'interface Abis (effet Trunk ), plus de ressources
ont t configures pour le transfert de donnes dans le cas du basculement inter-BSC.
Ces diffrences sont cependant moins sensibles dans le sens montant. Ce qui est essentiel retenir est que, compte tenu qu'il n'y a pas conservation des tats de transmission
au niveau RLC/MAC, les dlais de transmission sont proches, quelque soit la stratgie
de basculement adopte : handover ou reslection. Dans le cas de la reslection, on
gagne en dlais cause du fait que plus de donnes sont perdues et que le temps d'inactivit du mobile est plus long, ce qui entrane une moindre charge du rseau.
120
Figure 6.3.7. Temps de transmission des blocs RLC
Temps de transmission au niveau Application

Au niveau application, comme le montre les figures 6.3.8, la stratgie de handover prsente des performances lgrement meilleures que la stratgie de reslection.
Figure 6.3.8. Temps de transmission des lments de donnes
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
cellules ne partagent pas la mme interface A dans le cas du basculement inter-BSC).
6.4. Influence de la taille de la fentre d'mission RLC

Le but de cette partie est d'analyser l'influence de la taille de la fentre d'mission au niveau RLC sur les performances de la transmission. Nous considrons ici les mmes topologies pour le basculement intra et inter-BSC que dans la partie 6.3. Nous considrons un temps de basculement de 2 secondes et un temps de rcupration des informations systmes, en cas de reslection, de 8 secondes. Nous faisons varier la taille de la
fentre de transmission RLC entre 100 et 2000 blocs.
Les figures 6.4.1 prsentent les pertes de blocs MAC au niveau de l'interface radio (diffrence entre le nombre de blocs mis et le nombre de blocs reus). Ces pertes sont indpendantes de la taille de la fentre de transmission. Le nombre de blocs transmis est le
mme mais la frquence de retransmission d'un bloc sera d'autant plus leve que la fentre d'mission comportera un faible nombre de blocs.
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)
Dlais de transmission au niveau RLC

Comme on peut le voir sur les figures 6.4.3, la taille de la fentre d'mission n'a que peu
d'influence sur le dlais de transmission des blocs RLC. On constate juste une lgre
augmentation des dlais de transmission quand la fentre d'mission est petite. Celle-ci
tombe alors en effet plus frquemment dans un tat de blocage. Certains blocs segments doivent alors attendre que l'metteur reoive un acquittement avant de pouvoir tre
transmis.
123
Figure 6.4.3. Temps de transmission moyen des bloc RLC
Pertes au niveau LLC
Figure 6.4.4. Nombre moyen de trames LLC perdus par basculement
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
avantages de l'utilisation du handover par rapport la reslection en terme de temps de

coupure et de pertes. Nous avons galement montr les gains apports par l'utilisation
d'une procdure de reslection assiste par rapport une reslection simple.
Notre proposition, qui consiste maintenir les tats de transmission au niveau RLC
permet d'obtenir des performances bien meilleures en terme de pertes de donnes. Cette
proposition ne peut cependant pas tre mise en place au moment du basculement interBSC compte tenu du fait qu'il n'existe pas de liaison entre les BSC. Une solution similaire a t introduite rcemment dans la norme pour le cas des handover. Elle n'a pas t
reprise dans le cas de la reslection, cela ncessitant une profonde modification de la
gestion des temporisateurs au niveau RLC.
126
Chapitre III : Handover entre Technologies d'Accs : Etude du cas GPRS/WIFI intgr
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
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.
2. Etude des performance du transfert inter-RAT

2.1. Introduction de la technologie WLAN dans les rseaux cellulaires
Le document [3GPP 23.234] analyse les diffrentes solutions envisageables pour introduire la technologie WLAN dans un rseau cellulaire. Les diffrentes approches possibles pour raliser l'interconnexion d'un rseau cellulaire avec des points d'accs WIFI
sont analyses dans [Sam03]. Dans le cas des rseaux cellulaires, quatre configurations
d'interconnexion diffrentes peuvent tre envisages. Elles sont rcapitules sur la figure 2.1.1.
Figure 2.1.1: Interconnexion de points d'accs WLAN avec un rseau cellulaire
Dans le cas de la configuration de couplage Open Coupling , les deux technologies

d'accs - Cellulaire et WIFI - appartiennent deux rseaux administrativement disjoints,
relis entre eux par un rseau IP. Il n'y a aucune fonctionnalit commune aux deux r128
seaux. Dans ce cas, la mobilit doit tre gre au niveau IP.

Dans la solution de couplage Loose Coupling , les deux technologies d'accs sont
relis par un rseau IP commun et ont accs un ensemble de fonctionnalits d'administration communes. Par exemple, un rseau GPRS et un point d'accs WIFI public
relis un mme rseau oprateur peuvent faire appel au mme serveur d'authentification pour autoriser l'accs l'Internet public et au mme serveur de localisation. Les solutions qui assurent la mobilit des utilisateurs sont encore gres au niveau IP. Des
protocoles tels que Mobile IP [RFC 3344][RFC 3485] peuvent ici tre mis en place
pour grer l'itinrance des utilisateurs.
Pour les deux autres solutions, les points d'accs WLAN sont directement intgrs au
rseau d'accs RAN du rseau cellulaire. Dans la solution Tight Coupling (couplage proche), le point d'accs WLAN est reli au SGSN. Le point d'accs est alors vu
comme un rseau d'accs part entire ; rien n'empchant d'ailleurs de substituer ce
point d'accs unique par un rseau complet de points d'accs. Cette solution pourrait, par
exemple, tre utilise dans un aroport o l'abonn peut, au choix, faire transiter ses
communications par les points d'accs WIFI ou par le rseau d'accs cellulaire. Les
fonctions de localisation et d'authentification restent alors gres par le SGSN.
Dans la solution Integrated Access Point le point d'accs WLAN est directement
raccord au rseau d'accs cellulaire. Le point d'accs WLAN est alors vu comme une
station de base ayant une technologie de transmission diffrente. Il est reli un contrleur de station de base. Ce type de configuration peut tre utilis l'intrieur de btiments, comme par exemple des htels. L'utilisateur est alors amen basculer rapidement d'une technologie d'accs l'autre. Il est alors souhaitable que les procdures de
mobilit mises en oeuvre soient efficaces.
Dans notre tude, nous nous focalisons sur les cas o le point d'accs est intgr au rseau d'accs cellulaire. Pour assurer le transfert des transmissions d'une technologie
l'autre, les solutions Tight Coupling et Integrated peuvent faire appel des mcanismes de basculement au niveau de la couche liaison (LLC). La mobilit des utilisateurs est alors transparente pour la couche rseau (IP). Cela permet d'viter de dfinir
des mcanismes complexes de bout en bout qui requirent une reconfiguration au niveau IP (tablissement, relchement de tunnels IP) et peuvent amener des pertes et des
temps de coupures importants.
2.2. Caractristiques des technologies d'accs GPRS et WIFI

Le basculement entre technologies d'accs diffrentes pose des problmes spcifiques.
La pile protocolaire mise en place sur les deux interfaces est souvent diffrente. Par
ailleurs, les caractristiques de la transmission ne sont gnralement pas les mmes
d'une interface l'autre.
129
Diffrence entre piles protocolaires

En GPRS, pour transmettre des donnes sur l'interface radio, celles-ci doivent tre segmentes en blocs RLC dont la taille dpend du schma de codage utilis. Un mcanisme
de retransmission au niveau RLC peut tre implment afin d'assurer la dlivrance correcte des donnes. En WIFI, ce sont des trames, typiquement de la taille d'un paquet IP,
qui sont transmises. Un acquittement au niveau MAC peut tre implment afin d'indiquer la station de base que la trame a correctement t reue. Si, au bout d'un certain
nombre de tentatives, la trame n'a pas t correctement reue, sa transmission est abandonne et les donnes sont dtruites.
Pour les besoins de notre tude, nous avons considr que la couche commune aux deux
interfaces E-GPRS et WIFI tait la couche LLC. Sur l'interface GPRS, ce sont donc
des blocs RLC/MAC issus de la segmentations des trames LLC qui sont transmis.
Sur l'interface WIFI, ce sont directement les trames LLC sans segmentation supplmentaire qui sont transmises. La pile protocolaire correspondante est reprsente sur
la figure 5.3.1 du chapitre II.
Diffrences des caractristiques de la liaison
En condition normale d'utilisation, la technologie WIFI permet d'obtenir des dbits
beaucoup plus importants que le systme GPRS. Les dbits sont de l'ordre du megabit
en WIFI et du kilobit en GPRS. De mme, le temps de latence d'un systme WIFI est
beaucoup plus faible que celui du systme GPRS.
Dans le cadre de cette tude, nous avons modlis l'interface WIFI en considrant
qu'une trame LLC pouvait tre envoye chaque milliseconde. Le basculement d'une
interface l'autre entrane une modification brutale des caractristiques de la liaison
(dbit, taux d'erreur, temps de latence...).
2.3. Gestion de la reslection inter-RAT

La station WIFI n'a pas pour fonction de grer la prsence des utilisateurs. En cas de reslection, le point d'accs WIFI ne dtecte donc pas le dpart d'un mobile. Tant qu'elle
reoit des trames dlivrer, elle tente de les transmettre, puis, en cas d'chec, passe la
suivante. Ce type de comportement peut rapidement entraner la perte d'un grand
nombre de trames. Dans notre tude, nous proposons deux alternatives pour rsoudre ce
problme : par un mcanisme de dtection de prsence ou par l'intermdiaire de la
couche LLC
130
Mcanisme de dtection de prsence

Nous proposons de mettre en place un mcanisme de dtection de prsence. Dans le cas
o une trame ne peut tre dlivre un mobile, le point d'accs informe alors le BSC.
Ce dernier suspend alors la transmission descendant, ce qui permet de limiter les pertes.
Si le mobile a dfinitivement quitt la cellule, seule les trames stockes au niveau du
point d'accs sont alors perdues. Par ailleurs, du fait que la transmission est interrompue, les autres mobiles de la cellule peuvent bnficier de la bande passante ainsi prserve. Les performances d'un tel mcanisme en cas de reslection sont values dans
le cadre de nos simulations.
Afin de se prmunir contre le cas d'un mobile qui serait devenu temporairement indisponible, il est envisageable de mettre en place un mcanisme de paging priodique pouvant tre ralis pendant une courte priode, aprs la suspension.
Utilisation d'une couche de fiabilisation LLC
Nous avons ajout au sein du BSC une couche liaison nomme R-LLC (Cf. figure
5.3.1 du chapitre II). Comme l'ont montr certains travaux [Qix00][Pre02], dans des
conditions normales de transmission, l'implmentation d'une couche LLC n'offre pas
forcment une amlioration sensible des performances de la transmission. Cependant,
nous pensons que cette couche peut prsenter quelques avantages si elle est active au
moment o les performances radio se dgradent, ou quelques instant avant le dclenchement du handover. Cette couche R-LLC, commune aux deux technologie d'accs, reprend l'ide du groupe 802.21 [802.21] selon laquelle, pour assurer un basculement de
technologie transparent pour les couches rseaux, il est ncessaire de dvelopper une
couche liaison gnrique (GLL). Cette couche gnrique tient compte des caractristiques de la transmission aux niveaux physiques et MAC (une communication entre
les couches pouvant tre mise en oeuvre afin de permettre leur collaboration). Le mcanisme de retransmission R-LLC doit permettre d'assurer un basculement inter-RAT
sans pertes.
L'utilisation de cette couche R-LLC, dans le cas du basculement WIFI vers GPRS, peut
galement permettre de rsoudre le problme de la dtection du dpart d'un mobile voqu prcdemment. Si on considre une fentre d'mission large pour la couche R-LLC
(de 256 trames par exemple, comme pour la couche LLC GPRS [3GPP 44.064]), il y a
peu de chance que la transmission se retrouve bloque sur la taille de la fentre. Toutes
les trames transmises pendant la priode de basculement sont alors perdues, puis reprises au niveau de la cellule cible, au moment du rtablissement de la transmission.
Seul le mcanismes de retransmission est donc ici sollicit. Par contre, si on utilise une
fentre d'mission troite, la transmission peut se retrouver bloque ds que le mobile
arrte d'acquitter les trames qu'il reoit. Si le mobile bascule vers une autre cellule, les
pertes se limitent ainsi aux trames de la fentre d'mission. C'est pourquoi nous avons
choisi d'valuer les performances d'un mcanisme de retransmission fentre glissante
comportant un nombre rduit de trames (10 trames). Le temporisateur de retransmission
131
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.
2.4. Paramtrage des simulations

Pour le paramtrage des simulations, nous avons repris la mme configuration que dans
la partie 6.1 du chapitre II en remplaant l'une des stations de base par un point d'accs
WIFI. Le temps ncessaire au basculement varie entre 0 et 10 secondes. Pour la reslection, 8 secondes supplmentaires ont t prvues pour la rcupration des informations systme et la rservation de ressources dans la cellule cible.
2.5. Transfert inter-RAT : WIFI vers GPRS

2.5.1. tude des diffrentes approches pour effectuer le basculement
Nous considrons ici un mobile initialement attach un point d'accs WIFI qui bascule
vers une cellule E-GPRS. Dans ce cas, il n'y a initialement pas de couche RLC qui entre
en jeu, et donc pas de pertes de donnes au niveau RLC dues au basculement. Les dlais
subis au niveau RLC ne sont dus qu'aux conditions de charge constates par le mobile
lorsqu'il arrive dans la cellule cible.
Nous observons la transmission au niveau de la couche R-LLC, localise dans le BSC.
Sur les figure, la lgende +LLC indique que la couche R-LLC est utilise en mode
acquitt.
Pertes au niveau R-LLC
Les figures 2.5.1.1 prsentent la diffrence entre les trames R-LLC mises et celles correctement reues par le mobile. On constate qu'en cas de handover, il n'y a absolument
aucune perte. En effet, dans ce cas, le rseau suspend la transmission descendante avant
de dclencher le basculement. Le mobile fait de mme, en suspendant la transmission
montante avant de changer de cellule. Cependant, le systme WIFI n'a pas t conu
pour permettre ce genre de procdure. Le mobile devrait en effet remonter trs rgulirement des rapports de mesures sur les cellules voisines afin de permettre au rseau de
prendre sa dcision et le rseau devrait envoyer au mobile les informations de la cellule
cible. Une procdure adapte devrait donc tre normalise puis implmente afin de
permettre l'excution d'un handover inter-RAT entre technologies de famille diffrentes
(cellulaires 3GPP / reseaux 802.XX).
132
Les trois procdures de reslection implmentes prsentent des rsultats quelque-peu

diffrents. Dans le sens montant, seule la trame en cours de transmission au moment o
le mobile dclenche le basculement peut ventuellement tre perdue. Ce problme peut
tre assez facilement contourn en s'assurant de terminer la transmission de la trame
LLC avant de procder la reslection. Cette vrification ne peut cependant pas tre
ralise dans les cas de perte totale de la connexion.
Dans le sens descendant, dans le cas de la reslection simple, toutes les trames R-LLC
qui sont transmises sur l'interface radio WIFI aprs que le mobile ait chang de cellule
sont perdues : soit entre 50 et 70 trames suivant le temps ncessaire au basculement.
Dans le cas o le dpart du mobile est dtect, seules les trames envoyes au point d'accs avant que le dpart ne soit notifi au BSC sont perdues. Soit moins d'une dizaine de
trames en moyenne. Dans ces deux cas de reslection, les pertes de trames peuvent tre
reprises au niveau TCP.
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
Figure 2.5.1.2. Nombre de trames R-LLC perdues au cours d'un transfert WIFI vers GPRS (diffrence
gnrs/transmis)
Dlais de transmission au niveau R-LLC

Les figures 2.5.1.3 prsentent les temps moyens de transmission des trames R-LLC.
Dans le sens montant, les diffrentes stratgies se dmarquent peu. Les transmissions
sont rapidement suspendues, ce qui n'entrane pas de dlais particuliers sur le temps de
remise des trames. Dans le sens descendant, par contre, la situation est toute autre. Les
stratgies de handover, de reslection ou de reslection avec dtection qui entranent
la suspension de la transmission ont des performances assez proches. Seule la stratgie
de reslection couple un systme de fiabilisation au niveau LLC entrane une augmentation importante des dlais de transmission. On distingue d'ailleurs assez bien les
priodes d'augmentation des dlais de transmission au moment o le temporisateur LLC
s'annule. Les paquets R-LLC perdus sont alors dlivrs au moment de leur retransmission et quand le mobile a effectivement bascul vers la cellule cible.
Figure 2.5.1.3. Temps de transmission des trames R-LLC
134
Dlais de transmission au niveau application

Les figures 2.5.1.4 prsentent les temps moyens de transmission des objets au niveau
application.
Que l'on considre le sens montant ou le sens descendant, le mme classement peut tre
tablit entre les performances des diffrentes stratgies. Le handover est la stratgie la
plus avantageuse en terme de dlais. Cela s'explique naturellement par le plus faible
temps ncessaire au basculement. Les stratgies de reslection et de reslection
avec dtection du dpart du mobile sont assez proches. Dans les deux cas, les pertes
lies au basculement sont reprises au niveau TCP-IP. La principale diffrence rside
dans le fait que, dans le cas de la reslection simple, il faut parfois attendre que le paquet TCP soit retransmis plusieurs fois avant qu'il ne soit dlivr. Dans le cas o le dpart du mobile est dtect, les paquets TCP retransmis seront tous dlivrs. D'o un lger avantage, dans le sens montant, la stratgie de reslection avec dtection. C'est encore une fois la stratgie de reslection avec mcanisme de retransmission au niveau
LLC qui offre les performances les plus faibles en terme de dlais.
Figure 2.5.1.4. Temps de transmission des objets au niveau application
Nombre de paquets TCP correctement transmis

Les courbes 2.5.1.5 prsentent le nombre moyens de paquets TCP correctement transmis au cours d'une session. Comme on peut le voir, les stratgies sans couche de retransmission LLC sont, de loin, les meilleures. Le mcanisme de retransmission mis en
place au niveau LLC a tendance pnaliser la transmission : d'une part parce que la
transmission peut se bloquer plus rapidement et, d'autre part, parce qu'une partie de la
bande passante est alors utilise pour la transmission des acquittements.
135
Figure 2.5.1.5. Nombre moyen de paquets TCP transmis par mobile
2.5.2. Impact des caractristiques de la couche R-LLC

Le but de cette partie est d'tudier l'impact de certains paramtres de la couche R-LLC
sur les performances de la transmission. Nous avons jusqu'ici considr une couche RLLC dont la taille maximale de la fentre d'mission tait de 20 trames et les temporisateurs de retransmission de 5 secondes. Dans cette section, nous comparons les performances R-LLC pour quatre configurations de la couche R-LLC pour lesquels on considre deux tailles de fentres anticipation (10 ou 20 trames) et deux valeurs de temporisateur pour la retransmission (3 ou 5 secondes).
Les figures 2.5.2.1 reprsentent le nombre moyen de paquets R-LLC perdus au cours
d'un handover. Dans le sens descendant, tous les blocs LLC mis par le BSC aprs que
le mobile ait dclench le basculement sont perdus, jusqu' ce que le mobile rtablisse la
communication dans la cellule cible. Des temps de retransmission courts (3s) conduisent
donc des retransmissions et donc des pertes plus importantes que pour des temporisateurs de retransmission plus longs (5s). De mme, de faibles fentres d'mission (10
trames) conduisent des pertes plus faibles. En cas de perte, la transmission se bloque
plus rapidement et un plus faible nombre de trames est priodiquement retransmis. Cela
revt une certaine importance dans le cas o l'on souhaite optimiser l'utilisation des ressources radio.
136
Figure 2.5.2.1. Nombre moyen de paquets R-LLC perdus par mobile

Les figures 2.5.2.2 prsentent les temps moyens de transmission des paquets R-LLC.
Ces temps sont lgrement plus faibles dans le cas o la fentre de transmission est de
petite taille. En effet, dans ce cas, les fentres de transmission se bloquent plus rapidement, ce qui conduit un engorgement moindre de l'interface radio. Des dlais de retransmission plus importants (5s) conduisent galement un moindre engorgement de
l'interface radio. Il y a alors moins de retransmissions. Cependant, le temps moyen de
blocage de la transmission en cas de perte ou de reprise aprs basculement est alors
plus important. Cela vient contrebalancer les gains de temps ainsi obtenus. Ainsi, si on
souhaite optimiser l'utilisation des ressources radio, on prfrera un dlai de retransmission important. Si on souhaite limiter le temps de blocage de la transmission, on choisira des temporisateurs de transmission plus faibles.
Figure 2.5.2.2. Temps moyen de transmission des paquets R-LLC
137
Nombre de paquets TCP transmis

La figure 2.5.2.3 prsente le nombre de paquets TCP transmis par mobile. On constate
que moins de paquets sont transmis dans le cas o la fentre d'mission est petite. En effet, dans ce cas, on atteint plus rapidement l'tat de blocage, ce qui vient interrompre la
transmission. Cela est d'autant plus vrai quand les trames LLC transmettre sont petites
et que l'acquittement qui leur correspond tarde tre correctement transmis. A ce niveau, on ne distingue pas les dlais de retransmission au niveau LLC.
Figure 2.5.2.3. Nombre moyen de paquets TCP transmis par mobile
Dlais de transmission au niveau applicatif

La figure 2.5.2.4 prsente les temps moyens de transmission des objets au niveau application. La encore, on constate que de petites fentres de transmission sont plus pnalisantes en terme de dlais. La transmission se bloquant plus rapidement au niveau RLLC, cela retarde la transmission des donnes de bout en bout. Il faut donc faire un
choix entre optimiser les ressources sur l'interface radio (et utiliser des fentres de
transmission plus faibles) et optimiser les dlais de transmission de bout en bout (et
utiliser des fentres de transmission plus larges). On notera ici que la couche R-LLC a
t activ tout au long de la simulation. Le blocage intempestif de la transmission ne serait pas aussi pnalisant en cas d'activation slective du mcanisme de retransmission RLLC : en cas de conditions radio particulirement mauvaises ou de coupure importantes
durant la phase de handover.
138
Figure 2.5.2.4. Temps moyen de transmission des objets au niveau application
2.6. Transfert inter-RAT : GPRS vers WIFI

Nous considrons ici un mobile initialement attach une station de base GSM/GPRS
et qui bascule vers un point d'accs WIFI, reli au mme BSC. La communication transite initialement travers la couche RLC/MAC GPRS. Au moment du basculement, la
connexion qui existe ce niveau va disparatre, entranant la perte des blocs RLC/MAC
correspondants. Ces pertes sont visibles sur les figures 2.6.1 et 2.6.2.
Figure 2.6.1. Nombre de blocs RLC perdus au cours d'un transfert GPRS vers WIFI (diffrence emis/recus)
139
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)

Les figures 2.6.3 et 2.6.4 prsentent les pertes de donnes au niveau R-LLC. Les pertes
sont proportionnelles celles observes au niveau RLC/MAC. En cas d'activation du
mcanisme de retransmission de la couche R-LLC, tous les blocs mis sont correctement transmis.
140
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)

Les figures 2.6.5 prsentent les temps moyens de transmission des trames R-LLC. On
observe encore une fois une augmentation sensible des dlais de transmission lorsque le
mcanisme de retransmission R-LLC est activ. La reslection et le handover offrent
des performances comparables. La lgre diffrence de dlais est due une charge
moins importante de la cellule cible en cas de reslection ; en moyenne, les mobiles qui
font une reslection suspendent leur transmission plus longtemps et sont donc actifs
moins longtemps dans la cellule cible.
141
Figure 2.6.5. Temps de transmission des trames R-LLC
Pertes au niveau TCP

La figure 2.6.6 reprsente le nombre de paquets perdus au niveau TCP. On retrouve le
mme ordre de grandeur de pertes qu'au niveau LLC (Cf. figure 2.6.4).
Figure 2.6.6. Nombre de paquets TCP perdus au cours d'un transfert GPRS vers WIFI (diffrence mis/reus)
Nombre de paquets TCP correctement reus

La figure 2.6.7 prsente le nombre moyen de paquets TCP correctement reus par mobile. On constate une faible diffrence entre les stratgies par reslection et par handover. Par contre, on constate que l'activation du mcanisme de retransmission au niveau
LLC vient fortement pnaliser la transmission.
142
Figure 2.6.7. Nombre moyen de paquets TCP transmis par mobile
Dlais de transmission au niveau application

Si on observe le temps moyen de transmission des objets gnrs par la couche application (Cf. figure 2.6.8), on constate que la stratgie par handover offre les meilleures performances. Vient ensuite la stratgie par reslection, o les pertes engendres au niveau
du basculement sont reprises par le mcanisme de retransmission TCP. Enfin, la stratgie de reslection associe une retransmission au niveau R-LLC offrent les performances les plus faibles. Cette faiblesse des performances est en grande partie due aux
blocages frquents induits par la couche R-LLC.
Figure 2.6.8. Temps de transmission des donnes gnres par la couche application
143
2.7. Conclusions sur le transfert inter-RAT GPRS/WIFI

Dans cette partie nous avons tudi diffrentes solutions pour raliser le transfert d'une
transmission entre deux technologies d'accs diffrentes : GPRS et WIFI. Nous avons
mis en vidence les problmes spcifiques qui pouvaient se poser. Le changement de
technologie d'accs implique le basculement d'une pile protocolaire une autre et une
diffrence de qualit de service offerte sur la nouvelle interface. Les rsultats issus de
cette tude restent valables pour le basculement entre interfaces ayant un diffrentiel de
dbit important, comme par exemple avec la technologie WIMAX [802.16]. Nous avons
analys les performances de trois stratgies de reslection et d'une procdure de handover.
La procdure de basculement la plus efficace est la stratgie de handover. Elle ncessite
cependant que le rseau soit mme de fournir au mobile les informations qui lui seront
ncessaires pour basculer directement sur la cellule cible, sans subir d'interruptions
importantes.
La procdure de reslection simple conduit des pertes importantes. Dans le sens WIFI
vers GPRS, toutes les trames transmises sur l'interface radio de l'ancienne cellule aprs
le dpart du mobile sont perdues. Dans le sens GPRS vers WIFI, c'est la taille de la fentre au niveau RLC qui va dterminer le nombre de trames LLC qui vont tre perdues.
La mise en place d'un processus qui permet de suspendre la transmission sur la cellule
courante quand le point d'accs WIFI ne dtecte plus la station mobile permet de limiter
les pertes dans le cas de la reslection WIFI vers GPRS.
L'utilisation d'un mcanisme de retransmission au niveau R-LLC permet de limiter les
pertes en fonction de la taille de la fentre d'mission R-LLC. Par ailleurs, le mcanisme
de retransmission permet d'offrir un handover sans pertes, vu des couches suprieures.
Dans le cas o on active cette couche, il faut dterminer avec vigilance le temporisateur
de retransmission. Trop petit, il va entraner des retransmissions intempestives et donc
une charge de trafic supplmentaire dans la cellule. Trop long, il entrane des dlais
importants de reprise de la transmission.
3. Performances de la reslection pour des trafics flux continu

3.1. Introduction
Cette partie tudie les problmes de performances pouvant survenir lors d'un basculement inter-systmes pour du trafic de type streaming. Nous allons comparer trois approches pour la diffusion de ce type de contenu : transport fiabilise avec le protocole
TCP, transport non fiable sur UDP et utilisation d'un mcanisme de fiabilisation au niveau LLC coupl au protocole de transport UDP.
144
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.
3.2. Paramtres des simulations

Dans le cadre de ces simulations, nous considrons un trafic de type Streaming. Pour
chaque mobile, un objet de taille moyenne 480 octets (gnr suivant une loi de Pareto
Cut Off de paramtres K=81,5 ; =1,1 et m=66 666 octets) est gnr toute les 500 ms.
Cela reprsente un dbit moyen de 960 octets/s/mobile. Ce trafic n'est gnr que pour
la voie descendante. En voie montante, aucun trafic ne circule, hormis les ventuels
acquittements ncessaires aux mcanismes de retransmission. Nous ne considrerons
donc, dans l'tude des rsultats, que le transfert dans le sens descendant.
Le but de notre tude est de comparer diffrentes solutions d'empilement protocolaire.
Nous ne considrons que le processus de basculement par reslection. Les mcanismes
de handover entranent en effet des pertes plus faibles, ce qui ne permet pas d'obtenir un
diffrentiel de performances significatif entre les diffrentes solutions tudies.
Le mobile met en moyenne 4 secondes pour rcuprer les informations systme et le
temps ncessaire au rtablissement de la communication dans la cellule cible est variable. Tous ces paramtres sont rcapituls dans le tableau 3.2.1.
Paramtres
Loi
Valeur
Temps entre deux objets
Dterministe
500 ms
Taille d'un objet
Pareto Cut Off
K=81,5
=1,1
m=66 666
Temps de rcupration Uniforme

des informations systme
8
secondes
moyenne : 4 secondes
Temps de basculement
0 10 secondes
Paramtre de la simulation
Uniforme
Taille fentre au niveau LLC
20 trames
Temporisateur de retransmission
5 secondes
Tableau 3.2.1. Paramtres de simulation du trafic Streaming
145
3.3. Reslection intra-BSC GPRS

Pour cette premire srie de simulations, nous avons considr un rseau compos de
deux stations de base GPRS. Le changement de cellule s'effectue par reslection et l'tat
des automates de transmission au niveau RLC est rinitialis au cours du basculement.
Pertes au niveau RLC/MAC
Les figures 3.3.1 prsentent les pertes de blocs au niveau RLC. La figure de gauche prsente la diffrence entre le nombre de blocs mis et le nombre de blocs reus (pertes au
niveau MAC). Cette quantit augmente proportionnellement au temps requis pour effectuer la reslection. La courbe de droite est plus significative. Elle correspond nombre de
blocs perdus au niveau RLC diffrence entre le nombre de blocs gnrs et le nombre
de blocs transmis. On constate que les protocoles qui implmentent des mcanismes de
retransmission (TCP et UDP associ un mcanisme de retransmission au niveau LLC)
entranent moins de pertes que le protocole UDP seul. Dans le cas o un mcanisme de
retransmission est implment dans les couches suprieures, la transmission peut se retrouver bloque, en attente d'acquittement. Moins de trames sont alors envoyes au
BSC. Elles ne sont alors pas segmentes, ni perdues.
Dans le cas o on implmente le mcanisme de retransmission au niveau LLC, le temps
de retransmission tant faible (5s), une trame LLC peut tre mise plusieurs fois, ce qui
fait que le nombre de bloc RLC perdus se rapproche du cas UDP. Dans le cas o on utilise le mcanisme de retransmission de TCP, peu de trames sont mises en parallle et le
temps de retransmission peut tre plus important. Moins de trames sont alors segmentes et moins de blocs RLC sont perdus.
Figure 3.3.1. Nombre moyen de blocs RLC perdues au cours d'une reslection (trafic streaming)
146
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
LLC. Elles sont indpendantes du temps de coupure car, quelque soit leur dure, le
nombre de blocs RLC perdus est fixe.
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.
Figure 3.3.4. Temps de transmission au niveau R-LLC et Application (trafic streaming)
148
3.4. Reslection inter-RAT WIFI/GPRS

Pour les besoins de ces simulations, nous considrons des mobiles initialement attachs
un point d'accs WIFI et qui reslectionnent une station de base GSM/GPRS. Comme
la pile de transmission WIFI ne contient pas de couche RLC, les pertes engendres par
la reslection n'ont lieu qu'au niveau de la couche R-LLC (premire couche commune
aux deux systmes).
Les figures 3.4.1 prsentent les pertes engendres par la procdure de reslection au niveau R-LLC. La premire courbe reprsente la diffrence entre le nombre de trames
mises par le BSC et le nombre de trames reues par le mobile. La seconde reprsente la
diffrence entre le nombre de trames gnres par le systme et le nombre de trames
correctement transmises.
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
t, on perd au maximum le nombre de trames correspondant la taille de la fentre de

transmission (20 trames dans notre cas) et les blocs retransmis successivement (toutes
les 5 secondes dans notre cas) aprs dclenchement du basculement. Bien videmment,
grce ce mcanisme, toutes les trames qui parviennent au BSC sont correctement
transmises jusqu'au mobile.
Le profil des pertes que l'on observe sur la seconde courbe est alors le mme aux niveaux S-LLC et TCP/UDP. Quand le mcanisme de retransmission TCP est utilis, les
pertes sont rcupres ce niveau. Par contre, si on utilise uniquement UDP, les pertes
observes sont dfinitives.
Le mobile gnre des donnes pendant en moyenne 2 minutes et 45 secondes, soit, raison d'un objet toutes les 500ms, environ 330 objets transmettre. On observe des pertes
uniquement dans le cas de l'utilisation du protocole UDP, sans fiabilisation supplmentaire. Compte tenu de la la taille moyenne des objets transmis, le nombre d'objets perdus est trs proche du nombre de trames R-LLC perdues (Cf. figure 3.4.2).
Figure 3.4.2. Nombre moyen de d'objets perdus et transmis au cours d'une reslection (trafic streaming)
Dlais de transmission au niveau LLC et Application

Les figures 3.4.3 prsentent les temps de transmission aux niveaux LLC et application
des diffrentes donnes transmettre. Au niveau LLC, on constate que les deux solutions UDP prsentent des performances bien meilleures que la solution TCP. Par rapport
au cas du basculement de GPRS vers GPRS, on constate une augmentation importante
du dlai de transmission au niveau LLC dans le cas o on utilise le protocole TCP. Ceci
est vraisemblablement d la rupture importante du dbit qui a lieu lorsqu'on bascule
du point d'accs WIFI la cellule GPRS. La couche TCP a alors une fentre d'mission
large : la retransmission des paquets de cette fentre, la suite du basculement, produit
alors un engorgement important.
150
Figure 3.4.3. Temps moyen de transmission des donnes (trafic streaming)
3.5. Reslection inter-RAT GPRS/WIFI

Le scnario tudi ici correspond des mobiles initialement attachs une station de
base GSM/GPRS et qui reslectionnent un point d'accs WIFI intgr au mme BSS.
Les pertes engendres ont lieu au niveau de la premire couche commune aux deux systmes : la couche R-LLC. Cependant, il est tout mme intressant d'valuer le nombre
de blocs RLC/MAC qui, au moment de la reselection, n'ont pas t transmis (Cf. figure
3.5.1).
Pertes au niveau RLC/MAC
Les pertes au niveau MAC (figure de gauche) sont proportionnelles au temps de coupure de la transmission. La diffrence entre le nombre de blocs gnrs et le nombre de
blocs transmis est cependant moins grande dans le cas TCP. Contrairement ce qui se
passe dans le cadre de la couche UDP, la couche TCP interrompt plus tt le transfert de
donnes en attendant de recevoir les acquittements correspondants. Par ailleurs, les temporisateurs de retransmission tant plus long que ceux de la couche LLC, il y a moins de
tentatives de retransmission au niveau IP, et donc au final moins de trames LLC qui
sont mises que dans le cas o on utilise le protocole UDP fiabilis par un mcanisme
de retransmission au niveau LLC.
151
Figure 3.5.1. Nombre moyen de bloc RLC perdus au cours d'une reslection (trafic streaming)

Des pertes au niveau RLC dcoulent les pertes au niveau R-LLC (Cf. figure 3.5.2).
Contrairement ce qui se passe dans le cas du basculement WIFI vers GPRS, le mcanisme de retransmission au niveau RLC vient ici suspendre la transmission et limiter
le nombre de trames LLC perdues pendant le temps du basculement. Le mcanisme de
retransmission TCP engendre un transfert moindre de donnes et donc moins de pertes
que le protocole UDP, pertes qu'un mcanisme de retransmission au niveau LLC est
tout fait mme de corriger.
152
Pertes et transmissions au niveau Application

Les figures 3.5.3 prsentent le nombre d'objets, au niveau application, perdus et correctement transmis. Seul le protocole UDP entrane des pertes, la transmission des donnes
dans les autres scnarios tant fiabilise par des mcanismes de retransmission.
Figure 3.5.3. Nombre moyen de d'objets perdus et transmis au cours d'une reslection (trafic streaming)
Dlais de transmission aux niveaux LLC et application

Les figures 3.5.4 prsentent les temps de transmission aux niveaux LLC et applications.
On retrouve le mme classement en terme de performance que dans les deux cas analyss prcdemment, mais les temps prsents ici sont beaucoup plus faibles que dans le
cas o la cellule cible est une cellule GPRS. Au moment du basculement, pour les deux
scnarios pour lesquels la transmission est fiabilise (UDP+LLC et TCP), les segments
TCP et les trames LLC et leurs retransmissions ventuelles sont stocks. Au moment o la transmission est rtablie dans la cellule WIFI cible, les dbits sont suffisamment importants pour que les donnes mises en attente soient rapidement transmises.
Cela rgle galement le problme d'un ventuel engorgement pouvant se produire dans
la cellule initiale, avant que le basculement ne soit dclench.
153
Figure 3.5.4. Temps moyen de transmission des donnes (trafic streaming)
3.6. Conclusions : impact de la reslection sur un trafic Streaming

Dans cette tude sur les flux streaming , nous avons analys trois scnarios de reslection de cellule : inter cellulaire GPRS, inter-RAT WIFI vers GPRS et inter-RAT
GPRS vers WIFI. Pour ces trois scnarios, nous avons considr trois choix de pile protocolaire diffrents. L'un sans aucune fiabilisation, bas sur une couche UDP, l'un avec
une fiabilisation au niveau LLC et le dernier avec une fiabilisation assur par la couche
TCP.
Pour les trois scnarios, la couche protocolaire sans fiabilisation (UDP seul) semble la
plus performante en terme de dlais. Cette solution engendre la perte de quelques paquets au moment du basculement. Cela se traduit par un engorgement moindre du rseau. Les deux autres scnarios subissent un engorgement d aux paquets mis en attente, aux retransmissions ventuelles qui peuvent se produire (et qui ne se produisent
pas forcment qu'au moment du basculement), ainsi qu'au surplus de trafic engendr par
l'change des acquittements.
Les deux autres scnarios - TCP et UDP associ un mcanisme de retransmission au
niveau LLC n'engendrent aucune perte au niveau application. TCP offre cependant
des performances plus faibles car les pertes et l'expiration du RTO conduisent une rduction de la taille de la fentre d'mission. Celle-ci se retrouve alors bloque, ce qui
augmente les dlais de transmission.
L'utilisation conjointe du protocole UDP un mcanisme de retransmission au niveau
LLC semble donc tre un bon compromis afin d'obtenir une transmission sans pertes au
niveau de l'interface radio. Cette solution est d'ailleurs trs intressante dans le cadre de
services diffuss, o il n'est pas forcment possible de maintenir une fiabilisation entre
le serveur et tous les clients.
154
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
Chapitre IV : Transport de Signalisation SIP travers un rseau d'accs cellulaire
Chapitre IV : Transport de Signalisation SIP

travers un rseau d'accs cellulaire
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
Afin d'assurer un transfert plus rapide de ce type de signalisation travers le rseau

d'accs, il est ncessaire de mettre en place un mcanisme de compression. Cette partie
se propose d'tudier diffrentes approches de compression et de proposer une solution
adapte la compression de signalisation SIP.
Cette partie dbute par une prsentation succincte de l'IMS, du protocole SIP et de
l'architecture de compression SigComp. Nous prsentons les principes de diffrentes
techniques de compression de donnes texte. Nous dtaillerons ensuite quelques techniques qui s'appuient sur la structure des messages SIP pour amliorer les performances
des compresseurs. Nous analysons ensuite les performances de diffrentes combinaisons
de compresseurs appliqus la signalisation SIP. Enfin, nous proposons deux solutions
de compression SIP qui offrent de bonnes performances.
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].
Figure 2.1. Architecture du rseau IMS (d'aprs [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.
3. Signalisation SIP et SDP

Le protocole d'tablissement de session utilis dans le rseau IMS est le protocole SIP
Session Initiation Protocol. C'est un protocole dfini par l'IETF dans [RFC 3261].
SIP est un protocole de cration et de gestion de sessions qui est utilis, entre autre,
pour l'tablissement de communications VoIP. C'est un protocole texte de niveau applicatif. Les messages SIP comportent une partie en-tte et une partie contenu .
159
Dans le cadre de l'tablissement de sessions multimdia, le contenu est dcrit suivant la

syntaxe SDP Session Description Protocol - [RFC 2327]. Cette syntaxe dcrit les
paramtres des mdias associs la session SIP.
A la manire des protocoles du domaine internet (HTTP, SMTP, POP...), les protocoles
SIP et SDP ont une syntaxe dcrite sous forme de texte.
Un message SIP a toujours la mme structure. Il commence par une ligne qui dcrit le
statut du message requte ou rponse et la version du protocole (gnralement
SIP/2.0). Vient ensuite une srie d'tiquettes et de valeurs qui dcrivent le contenu de la
requte. L'tiquette est spare de sa valeur par le symbole : . Deux points successifs
( .. ) permettent de passer l'tiquette suivante. Quatre points sucessifs ( ....
marquent la sparation entre l'en-tte SIP et le contenu SDP. Le descripteur de flux multimdia SDP est format suivant le mme principe. Un exemple de message d'initialisation de session message INVITE est fourni ci aprs.
INVITE sip:0616771297@137.194.3.73 SIP/2.0..
Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000073fa00000
038..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: 1 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)....
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..
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
trouvent du ct du rcepteur. Une fois le message dcompress, ce dernier est transmis

la couche application qui, en retour, indique l'identifiant de transaction. Ce dernier
permet l'UDVM de mettre jour le contexte de compression / dcompression.
Pour assurer le bon fonctionnement de cette architecture, il faut bien s'assurer que
l'UDVM implmente l'algorithme et possde les informations ncessaires la dcompression.
Figure 4.1. architecture de la couche SigComp (d'aprs [RFC 3320])
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
La construction de l'arbre conduit regrouper les caractres B et E au sein d'un

arbre BE de poids 2, puis le caractre F et l'arbre BE au sein d'un arbre de poids
4... Soit les tapes dcrites dans le tableau suivant :
163
Arbres initiaux
B=1, E=1, F=2, H=2, C=3, D=3, A=4, G=4
Regroupement des arbres B et E. On obtient un arbre BE de

poids 2
BE=2, F=2, H=2, C=3, D=3, A=4, G=4
Regroupement des arbre BE et F. On obtient un arbre BEF de

poids 4, que l'on reclasse.
H=2, C=3, D=3, BEF=4, A=4, G=4
Regroupement des arbres H et C. On obtient un arbre HC de

poids 5, que l'on reclasse.
D=3, BEF=4, A=4, G=4, HC=5
Regroupement des arbres D et BEF. On obtient un arbre DBEF

de poids 7
A=4, G=4, HC=5, DBEF=7
Regroupement des arbres A et G. On obtient un arbre AG de

poids 8
HC=5, DBEF=7, AG=8
Regroupement des arbres HC et DBEF. On obtient un arbre

HCDBEF de poids 12
AG=8, HCDBEF=12
L'arbre final est le rsultat du regroupement des deux arbres

restants
AGHCDBEF=20
Tableau 5.1.2. Etapes de construction d'un arbre de Huffman
On obtient alors l'arbre de Huffman suivant :
Figure 5.1.1. Arbre de Huffman
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].
5.2. Compression LZ77

La mthode de compression LZ77 a t dfinie en 1977 par Jacob Ziv et Abraham Lempel [LZ77][Wiki-LZ77]. Son principe est relativement simple. Le compresseur parcours
la phrase compresser. Chaque fois que le compresseur dtecte une chane de caractres
antrieurement prsente dans la phrase, il la remplace par la longueur de la chane et la
distance laquelle cette chane a t dtecte.
Prenons l'exemple de la phrase suivante :
ABCDEFABCDFCDEFBCDFC
Les chanes de caractres en gras souligns sont dj prsentes, en position antrieure, dans la phrase. On peut alors leur substituer le couple longueur/distance qui leur
correspond. Par exemple, la longueur de la chane ABCD est de 4 et 6 caractres sparent les deux occurrences de cette chane. La compression amnera donc remplacer
la seconde chane ABCD par le couple longueur/distance <4,6>. Soit la phrase compresse suivante :
ABCDEF<4,6>F<4,9>B<4,8>
Il faut bien entendu permettre au dcodeur de distinguer les caractres des couples longueurs/distances. Nous verrons par la suite comment cela est implment dans la solution de compression Deflate . Avec cet algorithme, on ne code pas des chanes de
moins de 3 lettres car cela n'apporte aucun gain. A la place d'une lettre il faut en effet
substituer 2 codes : la longueur et la distance.
Cet algorithme ne ncessite pas la construction d'un dictionnaire compliqu. Il suffit
simplement de garder en mmoire l'historique des caractres dj transmis. LZ77 requiert malgr tout un temps d'initialisation pendant lequel peu de donnes sont compresses. Il faut en effet qu'une chane de caractres ait dj t transmise une fois avant
qu'elle ne soit substitue par un code plus court. Cette compression peut tre utilise
dans le cadre de flux de donnes puisque les octets sont envoys au fur et mesure de la
transmission. Contrairement au cas du codage de Huffman (non fixe) o il faut d'abord
lire le flux de donnes en entier avant de le coder.
165
5.3. Compression LZ78 / LZW

Les principes de la mthode de compression LZ78 ont t noncs en 1978 par Jacob
Ziv et Abraham Lempel [LZ78][Wiki-LZ77]. Terry A. Welch a propos une implmentation de cette mthode adapte la compression de donnes en vue de leur stockage
[LZW84][Wiki-LZW]. Un brevet, dpos dans certains pays (notamment en Amrique
du Nord) par la socit Unisys, a longtemps restreint l'utilisation de cette mthode de
compression. LZ78/LZW est notamment utilis dans le cadre de la compression d'images GIF.
Le principe de la compression consiste stocker des squences successives de deux
symboles et leur associer un code. L'algorithme est initialis en associant des codes
successifs chaque lettre de l'alphabet utilise. Ensuite, le flux est parcouru. A chaque
tape, on recherche dans le dictionnaire le code associ au motif le plus long que l'on
peut trouver. Un nouveau motif est alors cr. Il est compos du motif trouv et de la
lettre qui suit dans le flux. Un nouveau code est alors associ ce motif.
Reprenons l'exemple du codage de la phrase :
ABCDEFABCDFCDEFBCDFCD
Pour initialiser l'algorithme, on associe le code 1 A , 2 B et ainsi de
suite jusque 6 F. Les tapes successives de la compression sont dcrites dans le tableau 5.3.1.
Le message compress est alors :
1-2-3-4-5-6-7-9-6-9-11-8-4-15-4
La dcompression se fait en recomposant le dictionnaire au fur et mesure de la dcompression. Le processus de dcompression est fournit dans le tableau 5.3.2. On retrouve
le message original dans la seconde colonne du tableau 5.3.2.
Dans LZW, chaque fois qu'un motif est reconnu, un nouveau motif - compos du motif
reconnu et de la lettre qui suit - est ajout au dictionnaire. La taille des motifs dans le
dictionnaire volue donc en fonction de la frquence de rptition des diffrents motifs.
Si de longues squences se rptent peu frquemment, elles risquent de ne jamais tre
reprsentes sous forme de motif. En ce sens, l'algorithme est moins efficace que LZ77.
Par contre, il est trs efficace pour coder des motifs courts de 2 ou 3 caractres qui
se rptent frquemment. Dans LZ77, ces petits motifs ne sont pas cods puisqu'ils ne
conduisent pas un gain d'espace. Il faut en effet au moins les remplacer par au moins
deux caractres : une longueur et une distance. LZW requiert une priode d'initialisation, le temps que des motifs se rptent, avant que l'algorithme LZW ne commence
tre efficace.
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)
Tableau 5.3.1. Exemple de codage LZW
167
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
Tableau 5.3.2. Exemple de dcodage LZW
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
5.4. Compression Deflate

La solution de compression Deflate [RFC 1951] consiste en l'utilisation conjointe du
principe de compression LZ77 et des mthodes de codage de Huffman.
5.4.1. Compression LZ77 dans Deflate

Les caractres considrs en entre de Deflate sont des caractres ASCII cods sur 8
bits (valeurs allant de 0 255). A la sortie de LZ77, les caractres et les longueurs sont
cods sur 9 bits. Les codes associs aux caractres sont les mmes que dans le codage
ASCII.
Les codes associs aux longueurs sont compris entre 257 et 285. Suivant le code, 1 5
bits supplmentaires lui sont associs. Les longueurs sont comprises entre 3 (code 257)
et 258 (code 285). Une table permet de retrouver la valeur de la longueur partir du
code et des bits supplmentaires Celle-ci peut tre rsume comme suit :
Si code 264, alors longueur=code-256

Si 265 code 284 alors
nbrBitsSupplmentaires=(code-261)/4
longueur=(code-256)+valeur(BitsSupplmentaires)
Si code=285, longueur=258
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 :
Si code 3, alors distance=code+1

Si 4 code 29 alors
nbrBitsSupplmentaires=(code-2)/2
distance=code+valeur(BitsSupplmentaires)
169
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}
5.4.2. Codage de Huffman dans Deflate

A la sortie de LZ77 on a donc des caractres et des longueurs cods sur 9 bits. Les longueurs sont suivies par des bits supplmentaires et une distance. Le codage de Huffman
n'est appliqu qu'aux symboles de 9 bits, les autres symboles ne subissent pas de codage
supplmentaire.
Comme on l'a vu, pour les symboles de 9 bits, seules les valeurs allant de 0 287 sont
utilises. C'est donc les seules valeurs qui vont tre prises en compte dans l'arbre de
Huffman. Cela rduit le nombre de symboles coder, et donc la taille de l'arbre et la
longueur moyenne du code, par rapport au cas o on devrait coder 512 valeurs. Le document [RFC 1951] ne dfinit que l'arbre de codage statique. Dans le cadre de compression adaptative, l'arbre n'est pas dfini et varie d'un bloc de donnes l'autre.
Pour la construction de l'arbre dans le cadre de Deflate, il faut classer les caractres en
fonction de la longueur de leur code, par ordre croissant (les codes les plus courts prcdent les codes les plus longs). A longueur de code gale, les caractres sont classs dans
l'ordre lexicographique (ordre du code ASCII).
Par exemple, pour l'arbre de Huffman tudi prcdemment, les codes associs aux diffrents caractres ont pour longueur :
l(A)=2, l(B)=5, l(C)=2, l(D)=3, l(E)=5, l(F)=4, l(G)=2 et l(H)=3
On numrote ensuite les symboles en fonction de la longueur de leur code, en commenant par les caractres de code le plus court. On incrmente de 1 chaque symbole.
Chaque fois que l'on passe un codage de longueur plus leve, l'incrmentation est suivit de dcalages des bits vers la gauche afin d'attendre la taille de code requise. Dans le
cadre de notre exemple, on obtient les codes suivants :
A=00, G=01
C=100, D=101, H=110
F=1110
B=11110, E=11111
De cette faon, pour dfinir le codage, il suffit d'indiquer pour chaque caractre quelle
est la longueur du code associ. Dans notre exemple, pour l'alphabet ABCDEFGH; il
suffit de transmettre le vecteur [2, 5, 3, 5, 4, 2, 3]. Le dcodeur reconstruit alors ais170
ment le code en suivant les rgles nonces prcdemment.

Dans le cas du codage de Huffman statique, Deflate utilise les codes dfinis dans le tableau 5.4.2.1. Les caractres de l'alphabet ASCII sont cods sur 8 bits, ceux de l'alphabet ASCII tendu gnralement moins usits - sur 9 bits. Les faibles longueurs sur 7
bits et les longueurs leves sur 8bits.
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
Tableau 5.4.2.1. Codes de Huffman statique dans Deflate
6. Amlioration des performances des compresseurs

6.1. Conservation d'un contexte de compression
Le grand dfaut des solutions de compression comme LZ77 ou LZW est qu'elles ne
commencent produire leurs effets qu'au moment o de la redondance apparat dans la
squence compresser. Au cours d'un change, certaines informations se retrouvent
d'un message l'autre. Une solution pour amliorer la compression est de conserver tout
ou partie de l'historique de la session et de prendre en compte les messages dj transmis pour compresser le message courant. Cette approche est trs efficace, mais il est
ncessaire de s'assurer que l'metteur et le rcepteur ont bien reu tous les messages qui
prcdent et que ces messages sont classs dans le bon ordre. Cela est facile vrifier
quand la transaction est de type question/rponse : l'metteur met la mme question
tant qu'il n'a pas reu la rponse, tout message dupliqu est limin. Par contre, cela est
plus difficile contrler dans le cas d'une transaction plus complexe ou plusieurs messages peuvent tre transmis en parallle (ce qui est le cas dans le cadre d'une transaction
SIP). Par ailleurs, cette solution n'apporte aucune amlioration de la compression des
premiers messages, pour lesquels il n'existe aucun historique de transmission. Or, ce
sont souvent ces premiers messages qui ont la plus grande taille.
6.2. Utilisation d'un dictionnaire

Une autre solution pour amliorer les performances de la compression est d'utiliser un
171
dictionnaire de compression, connu de l'metteur et du rcepteur. Ce dictionnaire doit

contenir les chanes de caractres que l'on rencontre le plus frquemment dans les messages SIP.
Le principe de compression consiste alors intgrer le dictionnaire au contexte de compression du message. Le dcompresseur effectue le traitement inverse, en utilisant le
mme dictionnaire. Seul le message compress est alors transmis au rcepteur. Ce
principe est dcrit sur la figure 6.2.1.
Figure 6.2.1. Principe de la compression avec dictionnaire
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.
7. Performances des solutions de compression sur SIP

Pour valuer les performances des diffrentes solutions de compression sur la signalisation SIP, nous avons considr deux changes SIP, rcuprs sur une plate forme de test
dveloppe l'ENST. Le premier change est un appel avort (sans dcrochage). Le second, un appel avec dcrochage, puis raccrochage. L'authentification de l'appelant est
ralise dans les deux cas. Ces changes sont tous deux composs de 9 messages : Invite, 407, Ack, Invite, Trying, 200ok, Ack, Bye et 200Ok. Ces messages correspondent
l'change dcrit sur la figure 7.1. Nous avons numrot ces messages de 1 9. Le
contenu des messages, pour les deux changes, est fournit en annexe H.
Figure 7.1. Echange SIP entre le terminal et le P-CSCF
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
Appel sans rponse
793
559
392
951
458
767
394
396
351
Appel avec dcrochage
798
562
397
958
461
770
397
399
354
Tableau 7.1. Taille (en octets) des messages SIP
173
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 .
7.1. Compression sans mmoire, sans dictionnaire

Les figures 7.1.1 prsentent les performances des compresseurs LZ77, LZW et Deflate.
Les messages sont compresss indpendamment les uns des autres. Aucun dictionnaire
comportant les chanes les plus courantes dans un message SIP n'est utilis. La figure de
droite reprsente la taille, en octet, des messages avant et aprs compression.
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.
7.2. Compression sans mmoire, avec dictionnaire

Les figures 7.2.1 prsentent les performances des compresseurs LZ77 et Deflate avec et
sans dictionnaire. On peut ici constater l'effet que peut avoir le dictionnaire sur les performances des compresseurs. Le gain de compression supplmentaire apport par le dictionnaire est d'environ 20%, ce qui vient plus que doubler les performances des compresseurs. Les taux de compression obtenus varient ainsi entre 30 et 50%.
L'avantage de cette mthode de compression avec dictionnaire est qu'elle est simple
mettre en place. Pour peu que le compresseur et le dcompresseur se soient mis d'accord
sur le dictionnaire utiliser, cette mthode ne gnre aucun trafic pour synchroniser le
compresseur et le dcompresseur. Par contre, le dictionnaire doit tre adapt au type de
donnes transportes ici SIP. Une volution du protocole doit amener une modification des dictionnaires pour conserver de bonnes performances de compression. Cette solution de compression l'aide d'un dictionnaire n'est donc pas du tout dynamique.
Figure 7.2.1. Performances des compresseurs LZ77 et Deflate (avec utilisation de dictionnaire)
175
7.3. Compression avec mmoire

Dans cette partie, nous examinons les solutions de compression qui prennent en compte
les informations contenues dans les messages transmis prcdemment. La premire solution est une solution de compression EPIC, qui consiste supprimer les champs qui
n'ont pas t modifis depuis le message prcdent, puis reconstituer le message au niveau du dcompresseur. La seconde solution que nous avons tudie consiste compresser le message en intgrant dans le contexte de compression les messages prcdemment transmis. Cela revient utiliser une mthode par dictionnaire dont le contenu du dictionnaire est constitu des messages de la session.
Les figures 7.3.1 prsentent les performances de solutions de compression ne prenant en
compte qu'un seul message : le message transmis juste avant le message courant. On
constate que la solution EPIC prsente des performances analogues, voire lgrement
meilleures, que les solutions de compression LZ77 et Deflate. Par contre, EPIC n'apporte aucune compression sur le premier message, dont la taille est pourtant l'une des
plus leve. EPIC est galement peu efficace pour la compression du message 4. C'est le
plus gros message. Il contient, de ce fait, un grand nombre d'informations supplmentaires par rapport au message prcdent.
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
Les figures 7.3.2 prsentent les performances de solutions de compression prenant en

compte tous les messages de la session prcdemment transmis. Les performances pour
les messages 1 et 2 sont identiques celles des courbes 7.3.1 : le message 2 a pour seul
prdcesseur, le message 1, qui n'a, lui mme, aucun prdcesseur. Au del de deux
messages, les performances du compresseur sont stables, autour de 90%.
L'utilisation du contenu du ou des messages qui prcdent pour effectuer la compression
n'est cependant pas sans poser quelques problmes. Il ne faut pas qu'il y ait d'quipements intermdiaires qui aient besoin de dcompresser le message. Si c'est le cas, il faut
absolument que tous les messages de la session transitent par ce mme quipement.
Dans le cadre de la compression EPIC, le champ VIA , comportant des informations
destination des quipements intermdiaires, n'est pas compress. Dans le contexte de
notre tude, ce problme ne se pose pas, la connexion tant point point entre le mobile
et le P-CSCF.
Plus problmatique est le squencement des messages. Il faut en effet s'assurer que l'metteur et le rcepteur utilisent le mme contexte de compression/dcompression. Un
systme doit donc permettre de dtecter les messages intermdiaires manquants ou les
messages dupliqus. Il donc ncessaire de marquer les messages afin de contrler l'tat
du dcompresseur avant d'effectuer la dcompression. Par ailleurs, la compression rend
inaccessible certaines informations qui permettent de savoir quel est le contexte de dcompression qui doit tre utilis. Un marqueur doit galement permettre de savoir quel
est le dcompresseur utiliser. Ce marqueur peut tre bas sur un identifiant de session,
un peu la manire du NSAPI [3GPP 44.065] qui identifie le contexte PDP.
SIP est un protocole bas sur un change entre le mobile et le serveur. Dans le cas du
compresseur qui n'utilise qu'un seul message pour la compression, il est envisageable de
compresser le message transmettre uniquement l'aide du dernier message reu. De
cette faon, on est certain que le rcepteur possdera le message ncessaire la dcompression puisque c'est lui qui a envoy le message qui servi la compression. Il faut
cependant mettre en place un identifiant des messages afin d'indiquer au dcompresseur
quel est le message qui a t utilis pour la compression.
177
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.
7.4. Compression Deflate combine

Nous avons analys plusieurs solutions de compression bases sur le maintien d'un
contexte au niveau de l'metteur et du rcepteur. Toutes ces solutions sont compatibles
avec l'algorithme de compression de texte Deflate . Le but de cette partie est de comparer les diffrentes combinaisons de compression qui utilisent Deflate
Les figures 7.4.1 et 7.4.2 prsentent les performances des diffrentes solutions de compression associes Deflate. Nous considrons ici les compression avec mmoire, sans
dictionnaire. Les compressions avec mmoire utilisant, en plus, un dictionnaire de compression, sont analyses par la suite.
Figure 7.4.1. Performance de compression de Deflate (sans dico)
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
nu des champs tandis que l'utilisation du dictionnaire conduit la suppression du nom

des champs les plus courants.
Figure 7.4.2. Taux de compression de Deflate (sans dico)
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.
Figure 7.4.3. Performance de compression de Deflate (avec dico)
Dans le cas on on prend en compte un message prcdemment transmis pour effectuer

la compression, le dictionnaire apporte un gain d'environ 5 10% partir du second
message. Par contre, dans le cas o on prend en compte toute l'historique de la session,
le dictionnaire n'apporte plus de gain sensible de performances partir du troisime
message. Le dictionnaire amliore les performances de la compression EPIC. L'utilisa179
tion conjointe d'EPIC et du dictionnaire amliore les performances de la compression

EPIC. Cette solution reste cependant en de des performances obtenues en mmorisant
les messages prcdemment transmis. EPIC et le dictionnaire ont des effets complmentaires. EPIC supprime le contenu des en-ttes dj transmis tandis que le dictionnaire
supprime le nom des en-ttes les plus courants.
Figure 7.4.4. Taux de compression de Deflate (avec dico)
7.5. Etapes d'une compression combine Deflate + EPIC

Dans cette partie, nous dcomposons les diffrentes tapes d'une compression EPIC,
combine une compression Deflate avec dictionnaire. Sur le message original, on applique donc une compression EPIC, puis la compression LZ77 avec dictionnaire, puis
finalement, un codage de Huffman statique. Les figures 7.5.1 prsentent la taille et le
taux de compression des messages la sortie de chaque tape de la compression.
EPIC n'apporte pas de compression au premier message. Pour les messages suivants,
EPIC apporte une rduction de la taille des enttes des messages SIP. EPIC ne compresse pas le contenu SDP des messages. La compression apporte par EPIC est trs variable, entre 10 et 40% (0% pour le premier message). LZ77 apporte un taux de compression bien plus important. L'utilisation du dictionnaire permet d'obtenir de meilleures
performances de compression pour le premier message. Les taux de compression
subissent les mme fluctuations qu' la sortie d'EPIC, mais de faon plus attnue. Les
taux de compressions obtenus sont compris entre 50 et 70%. Enfin, le codage Huffman
statique apporte une surcompression d'environ 5%. Ce faible gain apport par le codage
de Huffman s'explique par le fait que le message a dj t sensiblement compress au
cours des deux tapes de compression prcdentes.
180
Figure 7.5.1. Contribution des diffrentes solutions de compression (EPIC + Dico + Deflate)
7.6. Etapes d'une compression Deflate avec mmorisation d'un message

Cette partie prsente la dcomposition d'une compression Deflate qui utilise un dictionnaire et le prcdent message transmis pour effectuer la compression. Les deux tapes
de la compression sont LZ77 et le codage statique de Huffman. Comme on peut le voir
sur la figure 7.6.1, la majeure partie du gain de compression est apport par l'algorithme
LZ77. Le codage de Huffman apporte une surcompression d'environ 5%. Les performances de compression du premier message restent faibles du fait qu'aucun message ne
permet d'initialiser le contexte de compression.
Figure 7.6.1. Contribution des diffrentes solutions de compression (Dico + 1 message + Deflate)
181
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
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
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.
Figure 3.1.1. Architecture de l'E-UTRAN [3GPP 36.300]
Cette nouvelle architecture du rseau d'accs va conduire la dfinition de nouvelles

procdures de handover, bases sur des techniques de transfert de contextes entre stations de base, de soft handover et de multihoming. Des mcanismes performants de dialogue entre couches devront galement tre mis en place.
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
Annexe A. Dbits dans le systme GSM/GPRS
Annexe A. Dbits dans le systme GSM/GPRS
189
Type of channel
f ull rate speech TCH
enhanced f ull rate speech TCH
net bit rate(kbit/s)

13
12,2
half rate speech TCH
5,6
Adaptiv e f ull rate speech TCH (12.2 kbit/s)
12,2
10,2
7,95
7,4
6,7
5,9
5,15
4,75
Adaptiv e half rate speech TCH (7.95 kbit/s)
7,95
7,4
6,7
5,9
5,15

data E-TCH (43,2 kbit/s)
4,75
43,5
32,0
29,0
14,5
12,0
data TCH (14,4 kbit/s)

data TCH ( 2,4 kbit/s)
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
Tableau 1. Dbits proposs par les systmes

GSM/GPRS/EDGE [GSM 05.01]
190
Annexe B. MMPP et IPP
1. Prsentation des MMPP

Un MMPP Modulated Markov Poisson Process est un processus de poisson dont le
taux d'arriv varie suivant un processus de Markov. Ce processus peut tre utilis dans
le cadre de la thorie des files d'attente. Prenons lexemple dune file dattente pouvant
contenir jusqu 4 clients servis par un seul serveur, le taux darriv des clients dans la
file dattente est not et linverse du temps de traitement moyen est not . Le processus de Markov correspondant peut alors tre modlis par lautomate reprsent sur la
figure 1.1.
Figure 1.1. Chane de Markov un seul serveur et de capacit 4 (M/M/1/4)
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.
Figure 1.2. Modulation des taux d'arriv et de dpart des utilisateurs
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
Lautomate rsultant est alors reprsent sur la figure 1.3.
Figure 1.3: Automate rsultant : File MMPP/M/1/4 module
2. Prsentation des IPP

Les IPP Interrupted Poisson Process forment un sous ensemble particulier des
MMPP dans lequel lun des tats de lautomate qui rgit les taux darriv entrane un arrt total darriv de clients. LIPP le plus simple est lIPP deux tats : Marche/Arret reprsent sur la figure 2.1.
Figure 2.1. Automate de

trafic IPP
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
Figure 2.2. Profil de trafic gnr l'aide d'une IPP
193
Annexe C. Descriptif du simulateur pour l'tude de l'interface Abis
Annexe C. Descriptif du simulateur pour l'tude de

l'interface Abis
1. Objets qui composent le simulateur

Le simulateur vnements discret implment dans le cadre de cette tude a t dvelopp partir d'un modle objets. Les diffrents objets qui composent le simulateur
interagissent alors entre eux pour simuler le comportement des diffrents quipements.
1.1. Les classes du simulateur

Le simulateur a t crit en langage Java. Cette partie prsente larchitecture des diffrents objets implments pour ce simulateur.
Larchitecture des classes de ce simulateur se veut assez proche de larchitecture du
systme quil modlise : le BSS du systme GSM/GPRS. En consquence, chaque quipement (Mobile, BTS, BSC) et chaque interface (Air, Abis) possde une classe ddie.
Certaines classes sont implmentes dans diffrentes versions afin de pouvoir comparer
des implmentations diffrentes dun mme modle. Cest le cas par exemple des modles de trafic. Des patrons de classes, appeles interfaces dans le langage Java, ont
alors t dfinis afin de pouvoir aisment manipuler les diffrentes implmentations
dun mme modle. Une classe qui implmente une interface Java doit implmenter
toutes les mthodes dfinies dans linterface. Ainsi, par exemple, les classe MobilesData
et MobilesVoix implmentent toutes deux la mme interface Mobile.
Dans la suite de ce document, tous les objets Java seront souligns et les interfaces
mises en italique. Une documentation Java, gnre laide de loutil Javadoc, accompagne cette prsentation. On y trouvera un descriptif dtaill de chacune des mthodes
implmentes.
195
1.2. Le noyau du simulateur

Deux classes principales permettent de grer le noyau du simulateur. La premire
classe, appele Simulateur, permet de configurer le scnario simuler. Cette classe gre
en plus lcriture des rsultats vers linterface de sortie : cran pour un scnario unique,
fichier pour une srie de simulations.
Le scnario simuler est dfinit dans la mthode scenario , qui reoit un paramtre
que lon peut faire varier dans le cadre dune srie de simulations. Dans cette mthode,
il faut crer les diffrents objets du simulateur dans un certain ordre logique afin de pouvoir lier les objets entre eux. Il faut ainsi commencer par dfinir la pile dvnement, le
BSC puis les gnrateurs de mobiles. Dans le cas des gnrateurs de mobiles EGPRS, il
faut galement leur associer les gnrateurs de donnes. La cration des BTS entranant
la cration dune interface Air, il faut lui associer un modle derreur.
Dans la mthode main , il est possible de faire appel trois mthodes diffrentes :
passageSimple , passageLineaire ou passageMultithread .
La mthode passageSimple est utilise lors de la ralisation dune seule simulation.
Les informations renvoyes par le simulateur sont alors affiches lcran.
La mthode passageLinaire excute plusieurs fois la mme simulation en faisant
varier le paramtre pass en argument de la mthode simulation . Les rsultats de la
simulation sont alors crits dans des fichiers sous forme de donnes tabulaires.
La mthode passageMultithread effectue la mme opration que dans la mthode
passageLineaire , sauf que plusieurs simulations sont lances simultanment, et non
plus les unes la suite des autres. Il est possible, en modifiant des constantes dans la
mthode passageMultithread de modifier le nombre de simulations lances simultanment pour les adapter aux performances de la plate-forme sur laquelle tourne le simulateur. Le lancement de simulations en parallle ncessite de faire appel la classe
ThreadSimulateur.
1.3. La rcupration des statistiques

Afin de rcuprer des informations sur un objet, il faut que ce dernier implmente
linterface Statistique. Linterface Statistique impose dimplmenter la mthode
getStats qui retourne un ensemble de mesures, sous forme dun objet Properties. Ces
mesures sont ensuite traites au sein de la classe Simulateur.
Les fichiers de sortie gnrs par la classe Simulateur sont placs dans le rpertoire
mesures . Le nom des fichiers comporte la date et lheure de lancement de la simulation, suivie du nom de lobjet do proviennent les mesures.
196
1.4. La gnration de nombres alatoires

La classe NombreAleatoire est ddie la gnration de nombre alatoires suivant les
diffrentes lois qui sont utilises par le simulateur. Cette classe recours la classe
Random qui permet de gnrer des nombres pseudo-alatoire rparties suivant une loi
uniforme.
1.5. La gestion des vnements

Un vnement est un objet qui implmente linterface Evenement. Cette interface
impose dimplmenter deux mthodes : une mthode getDate et une mthode action . La mthode getDate retourne la date de survenue de lvnement. La mthode action excute la tache que doit raliser lobjet Evenement.
Les objets qui implmentent cette interface sont des objets actifs au sein du simulateur.
Ce sont les objets GenerateurMobile, Mobile, GenerateurData, BSC et BTS.
Tous les objets Evenement sont classs dans un chancier, gr par la classe PileEvenement. Cette classe est une pile dans laquelle les vnements sont insrs en fonction
de leur date de survenue, de sorte que le premier lment de la pile soit le premier
vnement dclencher. Pour faire voluer le simulateur, il suffit donc de dpiler le premier vnement de la pile et de dclencher la mthode action. Le dclenchement de
cette action retourne un vnement qui doit tre son tour insr dans la pile. Le cycle
recommence jusqu ce que la fin de la simulation soit atteinte.
1.6. La gestion des donnes

Les donnes gnres par les mobiles se prsentent gnralement sous forme de paquets
IP. Ces paquets sont segments par les couches LLC et RLC afin de produire des blocs
qui pourront tre transmis sur linterface radio.
Afin de reproduire ce mcanisme, deux classes ont t cres : la classe PaquetIP et la
classe BlocRLC.
Les paquets IP sont gnrs par les classes qui implmentent linterface GenerateurData. Ils sont alors placs dans une objet appel PilePaquet, dans lattente dtre segments
puis transmis. Les paquets IP sont placs dans la pile en fonction de leur date de
premption. Ainsi, le premier paquet de la pile est celui dont la date dchance est la
plus proche. Les paquets dont la date dchance est dpasse sont dtruits. Ils sont
alors considrs comme perdus.
Lorsque des ressources sont disponibles, un paquet est dpil de la pile IP. Il est alors
segment via lappel de la mthode segmente . Une pile de BlocRLC est alors pro-
197
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.
1.7. Les modles derreur pour la transmission de donnes

Un modle derreur est une classe qui implmente linterface ModeleErreur. Cette interface impose dimplmenter la mthode sansErreur qui renvoie un boolen pour indiquer si le bloc qui lui est pass en paramtre est en erreur ou pas.
Le mcanisme de reprise sur erreur est gr comme suit : au niveau de la transmission,
un bloc en erreur ne sera pas transmis au rcepteur, il ne sera donc pas acquitt par ce
dernier. Quand le rcepteur dtecte quun bloc na pas t acquitt, il initialise un compteur sur un nombre de timeslots. A chaque fois quun timeslot est coul, le compteur
est dcrment. Lorsque le compteur arrive zro, lensemble des blocs non acquitts
(et donc en erreur) sont rintgrs au dbut de la pile des blocs transmettre.
1.8. Modlisation des interfaces Air et Abis

Les interface Air et Abis permettent de grer les ressources attribuables pour la transmission. Linterface Air est implmente grce la classe InterfaceAir. La cration de
chaque BTS entrane la cration dun objet InterfaceAir. Linterface Abis est implmente grce la classe InterfaceAir, elle est cre au moment de la cration du BSC.
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.
1.9. Modlisation des tlphones mobiles

Les tlphones mobiles implmentent linterface Mobile. Cette interface impose dimplmenter trois mthodes : attachement , detachement et getBTS . Deux types
de mobiles ont t implments, les mobiles voix classe MobileVoix - et les mobiles
de donnes classe MobileData.
Lattachement dun mobile vocal consiste prendre une ressource sur linterface Air et
une ressource sur linterface Abis. Si aucune ressource nest disponible, lappel est rejet. Le dtachement consiste librer les ressources utilises.
Lattachement dun mobile de donnes consiste juste une inscription auprs de la BTS
et du BSC. Aucune ressource nest rserve. On dit que le mobile ouvre une session.
Des conditions de rejet douverture de session peuvent tre implmentes au niveau de
la BTS et du BSC (il faut pour cela modifier les mthodes BTS.add et BSC.add
qui rgissent les conditions douverture de session). La procdure de dtachement du
mobile data est assez complique mettre en oeuvre car elle impose de se ds-inscrire
auprs de la BTS et du BSC, de supprimer les paquets et les blocs qui entrent dans le
cadre dune communication avec ce mobile. Tout cela, en maintenant un dcompte
prcis de la quantit de donnes perdues. La mise en oeuvre prcise de la procdure de
dtachement dpend en grande partie de la prsence ou de labsence de buffers au niveau de la BTS. Elle sera prsent plus en dtails dans la partie 2 de cette annexe.
1.10. Modlisation de la BTS

Dans le simulateur, les BTS se chargent de contrler lattribution des ressources sur les
interfaces radio. Elles jouent galement un rle de relais entre linterface Air et linterface Abis. Cette fonction de relaie est surtout importante lorsque lon considre le cas
o la BTS est implmente avec bufferisation.
Afin de grer la transmission sur linterface Air, la BTS met priodiquement des jetons
aux mobiles qui souhaitent transmettre des donnes. Ces jetons reprsentent des droits
dmission de blocs sur linterface Air. Lalgorithme de distribution des jetons dpend
de la politique de dordonnancement mise en place.
199
1.11. Modlisation du BSC

Le BSC contrle ladmission des mobiles entrant dans le systme. Il se charge galement du partage entre les diffrentes BTS des ressources disponibles sur linterface
Abis. Comme pour linterface Air, les ressources sont distribues sous forme de droits
dmission. La principale diffrence est que la BTS rceptrice des jetons doit tenir
compte du fait que certains blocs RLC ncessitent plusieurs jetons pour tre transmis.
En effet, si sur linterface Air, chaque priode de 20ms le mobile est capable de transmettre autant de bloc quil dispose de slots, sur linterface Abis, il faut tenir compte de
la taille des blocs. Pendant 20ms, sur un canal 16kbits/s, on ne peut transmettre que
320 bits au maximum (voire un petit peu moins dans la ralit). Il faut donc parfois plusieurs jetons pour transmettre un seul bloc sur lAbis.
2. Descriptif du comportement des simulateurs

Cette partie dcrit le comportement des deux simulateurs qui ont t crits. Le premier
simule l'approche micro-circuit , c'est dire, sans bufferisation au niveau de la BTS.
Le second, l'approche avec bufferisation . Cette partie fait, dans une large mesure, rfrence aux objets dcrits dans la partie 1. Nous n'aborderons ici que la partie transmission des donnes. La partie gnration des donnes utilisateurs n'est pas dtaille ici. Le modle utilis pour la gnration des donnes relve de la partie exploitation du simulateur et sera dcrite en mme temps que les rsultats d'exploitation du
simulateur.
2.1. Architecture des simulateurs

Le systme simuler a une architecture arborescente trois tages : la racine est le
BSC, les nuds sont forms par les BTS et les feuilles sont les mobiles. A cause de
cette architecture, il nest pas vident de scinder totalement BTS, BSC et mobiles. En
effet, pour chaque mobile inscrit dans le systme, il faut que les BTS et le BSC
maintiennent un contexte sur le mobile. Un contexte tant dfinit comme tant des
informations sur ltat du mobile. Dans la ralit, ce contexte est tablit, dune part via
un change de signalisation entre le mobile et le rseau et dautre part, via la rcupration dinformations dans les VLR et le HLR. La synchronisation entre ltat rel du mobile et le contexte contenu au sein du BSC est loin dtre vident et requiert lutilisation
de procdures de signalisation performantes.
Dans le simulateur, et afin de faciliter son implmentation, le mobile et son contexte
sont confondus. Il en va de mme pour les BTS. La principale consquence de ce choix
dimplmentation rside dans la position des piles dmission et de rception. Pour l'approche micro-circuit , toutes les piles de transmission qui concernent un mobile sont
200
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.
Figure 2.1.1. Positions des piles pour l'approche micro-circuit
Figure 2.1.2. Positions des piles pour l'approche avec bufferisation

201
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.
2.2. La gestion des vnements du simulateur

C'est la faon dont sont grs les vnements qui va dfinir le comportement du simulateur. Dans ce simulateur, un vnement est un objet qui implmente linterface Evenement. Les objets qui implmentent cette interface sont : le BSC (BSC), les BTS (BTS),
les mobiles (MobileData et MobileVoix), les gnrateurs de mobiles (GenerateurMobileData et GenerateurMobileVoix), et les gnrateurs de trafic (comme par exemple GenerateurTrafficHTTP).
Les vnements sont empils dans un pile (PileEvenement) en fonction de la date laquelle ils doivent tre dclenchs. Le simulateur dpile chacun des vnement dans
l'ordre o ils doivent tre excuts et excute la mthode action . Cette mthode va
effectuer un certain nombre de traitements qui peuvent tre l'origine de la cration de
nouveaux vnements. Ces derniers sont alors insrs dans la pile. Grce ce principe
l'horloge du simulateur avance au fur et mesure du dclenchement des vnements. La
pile dvnement est initialise avec les vnements suivants : BSC, BTS, GenerateurMobileData et GenerateurMobileVoix. La figure 2.2.1 prsente le mcanisme d'volution du simulateur.
Figure 2.2.1. Gestion des vnements
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.
2.2.1. Actions dclenches par lvnement GenerateurMobileVoix

Le gnrateur de mobiles voix doit produire des mobiles de voix. Lors de lappel de la
mthode action, deux procdures peuvent tre dclenches : larrt du gnrateur de
donnes et la cration dun nouveau mobile.
Larrt du gnrateur de mobile entrane la suppression du gnrateur de mobile de la
pile.
Lors de la cration dun nouveau mobile. Celui ci est ensuite attach au rseau. Lattachement dun mobile entrane la rservation dune ressource au niveau de linterface
Air et de linterface Abis. Pour chacune des interfaces, si le nombre de ressources partages est insuffisant, une ressource mixte est associe au mobile. Si aucune ressource
mixte nest disponible, lappel est rejet. Dans ce cas, le mobile ne sera pas ajout la
pile dvnements : il sera perdu.
Le gnrateur de mobiles voix calcule ensuite la date darrive du prochain mobile data
dans le systme. La date o lvnement sera de nouveau appel est calcule et le gnrateur de mobile est rintroduit dans la pile dvnements.
2.2.2. Action dclenche par lvnement MobileVoix

La seule action que produit un mobile de voix est son dtachement. Le mobile libre
alors les ressources quil utilise sur les interfaces Air et Abis. Le mobile est supprim et
nest donc pas rintroduit dans la pile dvnements.
2.2.3. Actions dclenches par lvnement GenerateurMobileData

Le gnrateur de mobiles data fonctionne de la mme faon que le gnrateur de mobiles voix. La principale diffrence rside dans le fait que lattachement dun mobile de
donnes nentrane aucune rservation de ressources sur les interfaces.
Des conditions pour lattachement dun mobile de donnes dans le systme peuvent tre
dfinies au niveau des BTS et du BSC. Si un mobile est rejet, il ne sera pas introduit
dans la pile dvnements : il sera alors perdu.
A chaque mobile de donnes est associ une liste de gnrateurs de donnes. Ces der203
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.
2.2.4. Actions dclenches par lvnement MobileData

Lappel de la mthode action sur les mobiles de donnes peut entraner trois types
doprations : la gnration de donnes, la suppression de paquets IP dont la date arrive
chance et le dtachement du mobile.
La gnration de donnes est ralise par les gnrateurs de donnes qui sont empils
dans une pile dvnements contenue localement dans le mobile de donnes. Une fois
les donnes gnres, le gnrateur de donnes est r-empil dans cette pile dvnements locale. Cette gestion par pile locale des gnrateurs de donnes permet dassocier
plusieurs modles de trafic un mme mobile : par exemple, il est possible dimplmenter en parallle un modle de trafic http et un modle de type transfert de mail. Les
actions dclenches par les vnements gnrateurs de donnes dpendent du type de
gnrateur qui est implment.
La suppression des paquets IP dont la date arrive chance est dclenche par lappel
de la mthode actualiserPile de la classe PilePaquet.
Le dtachement dun mobile data est plus compliqu que le dtachement dun mobile de
voix. Cela est du la ncessit de bien faire le dcompte des blocs et des paquets IP qui
sont perdus du fait du dtachement du mobile.
Dans le sens montant, les paquets IP qui sont encore dans la pile dmission du mobile
sont perdus. Les blocs RLC/MAC non encore mis ou non encore acquitts sont galement considrs comme perdus. Les blocs non encore acquitts sont considrs comme
perdus car les blocs sont acquitts immdiatement par le rcepteur qui les reoit : BSC
dans l'approche micro-circuit , BTS dans l'approche avec bufferisation . Les blocs
envoys mais non acquitts sont donc, soit perdus, soit en cours de transmission : dans
ce cas, le mobile est sorti du systme avant davoir transmis le bloc en entier. Les paquets IP qui ont donn lieu la gnration de ces blocs sont galement considrs
comme perdus.
Dans le cas de l'approche avec bufferisation , on considrera que, dans le sens montant, il ny a aucune perte au niveau de la BTS. En effet, tout bloc arriv la BTS pourra
tre relay jusquau BSC, quand bien mme le mobile serait partit. Cela simplifie galement limplmentation puisquil nest pas besoin de trier les blocs RLC en attente
dmission dans la pile de la BTS. Dans labsolu, cela engendre une lgre perte de performance en voie montante au niveau de linterface air puisque des blocs RLC/MAC
qui ne permettront pas de recomposer un paquet IP complet sont inutilement transmis.
Dans la pratique, cette perte est cependant ngligeable compte tenu du fait que cest sur
la voie descendante de linterface Abis que se posent les problmes de congestion.
Dans le sens descendant, le dpart dun mobile entrane la perte des paquets en attente
de transmission et de tous les blocs non acquitts. Les paquets dont certains blocs ont
t perdus sont dcompts comme perdus.
204
2.2.5. Action dclenche par la BTS

La BTS n'implmente l'interface Evenement que dans l'approche avec bufferisation .
La seule action dclenche par la BTS consiste actualiser la pile de paquets en rception lorsque le temps de validit de lun des paquets est coul.
2.2.6. Action dclenche par le BSC

Le BSC dclenche la mme srie daction toutes les 20 millisecondes. Cette srie daction se droule en trois phases : indication aux interfaces Air et Abis que la priode est
termine, contrle de la retransmission, distribution des droits dmission aux diffrentes BTS.
Fin de la priode de transmission
Lindication aux interfaces Air et Abis que la priode de 20 millisecondes est termine
permet de signifier que les diffrents blocs en cours de transmission ont fini dtre mis.
Les interfaces Air distribuent alors leurs blocs montant aux BTS et les blocs descendant
aux mobiles. Le rcepteur dtecte si le bloc est arriv avant que le mobile ne se soit dtach de la cellule. Dans ce cas, le bloc est considr comme perdu et nest donc pas
acquitt. Les blocs reus correctement sont acquitts et comptabiliss. Un paquet IP est
considr comme reus lorsque tous les blocs qui le compose ont t correctement reus. Dans le cas de l'approche micro-circuit , les BTS transmettent directement les
blocs aux BSC. Dans l'approche avec bufferisation , les blocs sont stocks dans les
piles des BTS (il n'y a alors aucune intervention de l'objet interface Abis ).
Dans le cas avec bufferisation , linterface Abis distribue ses blocs descendants aux
BTS et ses blocs montants aux BSC. Si, au moment de la rception du bloc par la BTS,
le mobile destinataire est toujours attach la BTS, le paquet est acquitt et est bufferis
en attente de transmission sur linterface Air.
Lorsque le BSC reoit un bloc, il le comptabilise et lacquitte. Un paquet IP est considr comme reu lorsque tous les blocs qui le composent ont t correctement reus. A la
rception dun acquittement, les diffrents rcepteurs suppriment les blocs acquitts de
leurs pile de blocs en attente dacquittement.
Erreurs et contrle de la retransmission
Les blocs transmis sur l'interface Air peuvent tre transmis avec erreur . C'est le modle d'erreur implment au niveau de l'interface Air qui dtermine si le bloc est correc205
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
chacune des BTS.

A la rception des jetons, les BTS consomment les jetons pour envoyer les blocs sur
linterface Abis. Chaque jeton reprsente lutilisation dun canal 16kbits/s. Certains
blocs peuvent excder la taille de 16kbits/s. Si la BTS dispose de suffisamment de jetons, ces blocs peuvent tre transmis en parallle sur plusieurs canaux 16 kbits/s. Sinon, elle doit les transmettre en srie, sur un intervalle de temps multiple de 20ms. Ce
mcanisme est alors simul par un stockage des jetons au niveau de la BTS. Ainsi, si la
BTS ne dispose pas de suffisamment de jetons pour transmettre un bloc, les jetons seront stocks pour tre utiliss au cours de la priode suivante.
Une fois les blocs envoys sur linterface Abis, la BTS alloue les droits de transmission
aux diffrents mobiles de linterface Air qui sont en cours de transmission. Si, la fin
de lallocation, des jetons sont encore disponibles, la BTS active la transmission dun
mobile en attente de transmission. A la rception de leurs droits de transmission, les
mobiles dclenchent lenvoie dautant de blocs sur linterface Air quils ont reus de jetons.
3. Configuration et utilisation du simulateur

3.1. Scnarios de simulation
Les scnarios de simulations sont dfinis au sein de la classe Simulateur. La mthode
main de cette classe permet de faire appel trois types de traitement : passageSimple , passageLinaire ou passageMultithread .
Le passage simple permet deffectuer une simulation. Les rsultats de la simulation sont
alors affichs dans la fentre de contrle. Ces rsultats peuvent galement tre dvis
vers un fichier texte via lutilisation dun script de lancement (Cf. 3.3).
Les passage linaire et multi-thread permettent deffectuer plusieurs fois la mme simulation en faisant voluer un paramtre. Les rsultats sont envoys vers des fichiers identifis par leur date de cration et situs dans le rpertoire mesures de larborescence
de dveloppement. Dans le passage linaire, les simulations sont lances les unes la
suite des autres. Dans le passage multi-thread, plusieurs simulations sont lances en
parallle.
Le scnario de la simulation lanc est dfini au sein de la mthode Simulateur.scenario . Tous les paramtres qui dfinissent la simulation doivent donc tre dfinis dans
cette mthode. Il faut donc y crer la pile dvnement du simulateur, le BSC, les BTS,
les gnrateurs de mobiles, les gnrateurs de donnes et les modles derreur. Les gnrateurs de mobiles doivent galement tre ajouts la pile dvnements du simulateur.
207
3.2. Paramtres et rsultats de simulation

De nombreux paramtres vont influer sur le comportement du simulateur et vont
permettre de comparer divers scnarios de simulation. Ces paramtres peuvent tre modifis lors de la cration des diffrents objets du simulateur ou par une modification du
comportement du simulateur (modification du code source).
3.2.1. Paramtres de simulation

Simulateur
w Dure de la simulation
Modle derreur (ModeleErreurSimple)
w Taux derreur bloc sur linterface
BTS
w Nbre de canaux ( 16 kbits/s) ddis sur linterface Abis (appels voix)
w Nbre de canaux mixtes sur linterface Abis (communication data, premptable pour couler du traffic voix).
w Nbre de canaux partags sur linterface Abis (communication data exclusivement).
w Modle derreur associer linterface Air
BSC
w Nbre de canaux ( 16 kbits/s) ddis sur linterface Air (appels voix)
w Nbre de canaux mixtes sur linterface Air (communication data, premptable pour couler du traffic voix).
w Nbre de canaux partags sur linterface Air (communication data exclusivement).
Mobiles voix
w Taux darrive
w Dure moyenne dune communication
Mobiles Data
w Taux d'arrive
w Dure moyenne de rsidence dans le systme
w Profil du trafic de donnes
w Dbit/slot
w Capacit multi-slot du mobile (uplink & downlink)
Profil du trafic de donnes
w Paramtres des modles de trafic utiliss
208
3.2.2. Paramtres modifiables via une modification du code source

Taille maximale des buffers du BSC
Mode dattribution des droits de transmission (jetons)
Changement de cellule dun mobile en cours de communication
Dure du temps de rfrence (20ms par dfaut)
Taille de len-tte RLC/MAC
Dbit/slot sur linterface Abis
Temps d'envoi des acquittements ngatifs
3.2.3. Rsultats de simulation
Les fichiers de rsultats renvoys par le simulateur sont tous placs dans le rpertoire
mesures . Ils sont identifis par la date de lancement de la simulation.
Les paramtres de sortie que renvoie le simulateur sont les suivants :
Statistiques Globales :
w Appels Voix acceptes
w Appels Voix perdus
w Taux de perte appels voix
w Mobiles Data
Statistiques en fonction du sens de la transmission :
w Paquets gnres
w Paquets perdus par premption
w Paquets perdus cause du dpart dun mobile
w Paquets transmis
w Taux de paquets perdus par premption
w Taux de paquets perdus cause du dpart dun mobile
w Taux de paquets transmis
w Temps de transmission dun paquet (entre sa gnration et sa rception complte)
w Temps de transmission dun paquet (entre le dbut de sa transmission et sa rception
complte)
w Blocs gnrs
w Blocs perdus cause du dpart dun mobile
w Blocs transmis
w Taux de blocs perdus cause du dpart dun mobile
w Taux de transmission des blocs
w Temps de transmission dun bloc
w Taille moyenne de la pile au sein du BSC
3.3. Scripts de compilation et de lancement
209
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
Annexe D. Droulement d'un change de donnes au niveau RLC et LLC
Annexe D. Droulement d'un change de donnes

au niveau RLC et LLC
1. Droulement d'un change de blocs au niveau RLC
Figure 1.1. Exemple de transmission au niveau RLC
211
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
Annexe D. Droulement d'un change de donnes au niveau RLC et LLC
2. Droulement d'un change de trames au niveau LLC

Exemple de transmission de trames LLC
La figure 2.1 prsente un change de trames LLC entre deux quipements.
L'metteur/rcepteur n1 met trois fois plus de trames que le n2 : cela est notamment
vrifi dans le cas des transmissions radio-mobiles o l'utilisateur bnficie de capacits
de transmission plus importantes en rception qu'en mission. L'change prsent ici est
cependant quelque-peu simplificateur puisque la dure d'mission des trames dpend de
nombreux facteurs : taille des trames, taux de codages, taux d'erreurs au niveau
RLC/MAC au cours de la transmission radio...
Figure 2.1. Dialogue au niveau LLC entre deux Emetteurs / Rcepteurs
Au dbut du transfert, l'quipement n1 a dj transfr m trames qui ont t acquittes

(V(A)=V(S)=m) et a reu n trames (V(R)=n). De mme, l'quipement n2 a transmis
avec succs n trames et en a reu m. L'quipement n1 va alors transmettre successivement trois trames (N(S)=m, m+1 et m+2) tandis que le n2 va en transmettre une seule
(N(S)=n). A chaque nouvelle trame transmise, l'metteur incrmente V(S). Lorsque le
rcepteur reoit la trame numrote telle que N(S)=V(R), il affecte V(R) la valeur de
la premire trame LLC qui, dans l'ordre de la squence, n'a pas encore t reue.
Aprs rception de la premire trame en provenance de l'quipement n2 (N(S)=n),
l'quipement n1 continu son transfert en mettant les trames N(S)=m+3, m+4 et m+5.
Les trois trames prcdentes n'ont pas t acquittes par la trame N(S)=n puisque celui213
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
Annexe E. Le handover dans les rseaux radio-tlphoniques : GSM
Annexe E. Le handover dans les rseaux radiotlphoniques : GSM

Dans les rseaux tlphoniques commuts, un circuit est rserv de bout en bout dans le
rseau pour transmettre la communication. Le transfert inter-cellulaire impose de rserver des ressources dans la nouvelle cellule et de commuter l'appel dans cette nouvelle
cellule, en tablissant et librant ventuellement des liens dans le rseau coeur.
Dans le rseau GSM [Lag00], le handover est uniquement l'initiative du rseau : la
dcision tant prise par le contrleur de la station de base dont dpend le mobile.
Durant la phase de basculement, quelques chantillons de voix sont perdus, engendrant
une micro coupure de la communication. Celle-ci est cependant peu audible pour l'utilisateur.
Figure 1. Les diffrents types de handover GSM
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
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
Annexe F. Aperu du fonctionnement du protocole TCP/IP
Annexe F. Aperu du fonctionnement du protocole

TCP/IP
Le protocole TCP [RFC 793][Mar03] offre un service orient connexion au dessus du

protocole IP. Un mcanisme de retransmission lui est associ. Cette partie se propose de
prsenter succinctement le mcanisme de retransmission TCP et les possibilits offertes
par ce protocole afin de limiter ou de sadapter la congestion. Elle sattachera galement prsenter quelques unes des problmatiques souleves par lutilisation du protocole TCP sur les rseaux radio-mobiles.
Figure 1. Couche protocolaire du protocole TCP/IP
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
Du cot de lmetteur, les principales variables sont :
SND.UNA : premier numro de squence envoye mais non acquitte
SND.NXT : prochain numro de squence mettre
SND.WND : taille de la fentre dmission
Du cot du rcepteur, les principales variables sont :
RCV.NXT : Numro de la squence attendue
RCV.WND : taille de la fentre de rception
Chaque message comporte un certains nombre dinformation qui permettent dassurer le

bon fonctionnement du protocole :
SEG.SEQ : Numro de squence du segment
SEG.LEN : Taille de la squence contenue dans le segment
SEG.ACK : Numro de squence de la dernire squence correctement reue
SEG.WIN : Taille de la fentre de rception du rcepteur.
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
Annexe F. Aperu du fonctionnement du protocole TCP/IP
Exemple d'change de segments TCP
Figure 2. Exemple dchange TCP
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
Figure 3. Exemple d'change TCP (avec segmentation)
Taille de la fentre d'anticipation et temporisateur de retransmission

L'une des caractristiques principales de TCP est que la taille de la fentre d'anticipation
et le RTO ne sont pas fixes. Ils varient dans le temps et dpendent fortement des conditions de trafic dans le rseau.
Le RTO est calcul en fonction du RTT. Le RTT Round Trip Time est le temps qui
s'coule entre le moment o un segment est mis et le temps o l'acquittement correspondant est reu.
La taille de la fentre d'anticipation varie en fonction des pertes qui peuvent survenir au
cours de la transmission. TCP est un protocole qui a t conu pour des rseaux relativement fiables, comme par exemple des rseaux locaux d'entreprises. Lorsqu'une
congestion survient dans le rseau, les quipements intermdiaires qui routent les paquets peuvent tre amens en liminer certains de faon a ne pas saturer leurs buffers
et garantir des dlais de livraison acceptables. Le mcanisme de transmission de TCP
suppose donc qu'une perte est due de la congestion dans le rseau et il rduit donc sa
fentre d'mission. Cette caractristique n'est pas sans poser problme dans les rseaux
sans fils o les pertes peuvent tre relativement importantes lorsque les conditions radio
sont assez mauvaises et dans le cas de handover.
220
Annexe G. Solutions de mobilit dans le coeur de rseau cellulaire et au niveau IP
Annexe G. Solutions de mobilit dans le coeur de

rseau cellulaire et au niveau IP
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.
Figure 1.1. Phase de prparation du handover inter-SGSN [3GPP 43.129]
221
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.
Figure 1.2. Phase d'excution du handover inter-SGSN [3GPP 43.129]
223
2. Les solution de mobilit au niveau IP

Les solutions de mobilit au niveau IP doivent permettre d'assurer la mobilit des utilisateurs qui changent de point d'accs au rseau IP. Dans un rseau GPRS/UMTS, le
point d'accs au rseau est le GGSN. L'utilisateur sera amen changer de GGSN uniquement s'il change de rseau. Ces solutions doivent galement permettre un utilisateur initialement attach GPRS qui migre vers un autre technologie d'accs Internet
comme par exemple un point d'accs WIFI public.
Les deux principales solutions de mobilit qui ont t proposs sont Mobile IP et
Cellular IP .
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.
2.1.1. Principe du protocole Mobile IP

Lorsquil communique sur un rseau IP, un mobile possde une adresse IP. Cette
adresse dtermine quel domaine et sous-domaines est rattach la station mobile. Le
domaine et dtermin grce la classe dadresse et les sous-domaines sont dtermins
grce des masques de rseau. L'adressage dans un rseau IP forme donc une structure
arborescente.
Un mobile en itinrance en dehors de son domaine ne peut normalement pas recevoir de
donnes la mme adresse IP. En effet, les donnes qui lui sont destines vont tre routes vers le domaine dtermin par le masque de sous rseau de ladresse IP. Il faut
donc mettre en place un processus qui va permettre de rediriger les paquets lorsque le
mobile est en itinrance en dehors de son domaine de rattachement. Cest ce que se propose de faire le protocole Mobile IP .
Le protocole Mobile IP se base sur deux quipements qui vont permettre dassurer
le routage des donnes indpendamment du domaine dans lequel se trouve le destinataire. Un Home Agent est ajout au sein du domaine auquel le mobile est attach.
Cet quipement est un routeur qui va se charger de transfrer le paquets jusquau rseau
visit.
Un autre quipement, appel Foreign Agent , peut tre ajout au rseau visit. La
communication entre le Home Agent et le Foreign Agent se faisant via un tunnel
IP (encapsulation de datagrammes IP dans dautres paquets IP). Ce Foreign Agent doit
224
permettre au mobile de ne pas demander une nouvelle adresse IP, cet quipement a
disparu dans la version IPv6 de la spcification.
2.1.2. Illustration du protocole Mobile IP

Pour illustrer le fonctionnement du protocole Mobile IP, nous allons nous appuyer sur
l'exemple fournit sur la figure 2.1.2.1. Une station mobile (STA) ayant pour IP
187.192.145.25 et situe dans son sous-rseau nominal 187.192.145.* dialogue avec le
serveur 216.234.116.34. Cette station va alors migrer vers le sous rseau 187.192.217.*.
Figure 2.1.2.1. Station mobile dans son rseau nominal
Les paquets en provenance du serveur et destination du mobile arrivent au niveau du

Home Agent (qui peut par exemple tre un routeur d'accs au rseau). Ce dernier
transfert alors les paquets jusqu' la station mobile. Les paquets envoys par la station
mobile, quand eux, peuvent transiter directement de la station vers le serveur.
2.1.3. Cas o le sous-rseau d'accueil possde un Foreign Agent

Dans le cas o le rseau visit possde un Foreign Agent (FA), la station mobile
(STA) s'enregistre auprs du Foreign Agent et rcupre son adresse IP. La station
mobile contacte alors son Home Agent pour lui indiquer auprs de quel Foreign
Agent il est inscrit. Le Home Agent enregistre alors la localisation du mobile. Le
rseau est alors configur comme illustr sur la figure 2.1.3.1.
Les paquets en provenance du serveur vont alors arriver au niveau du Home Agent ,
qui va les transfrer au niveau du Foreign Agent . Ce dernier les dlivre alors la
station mobile. Par contre, la station mobile peut trs bien continuer transmettre ses
donnes directement au serveur.
225
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.
Figure 2.1.3.1. Solution Mobile IP avec Foreign Agent
2.1.4. Cas o le sous-rseau d'accueil ne possde un Foreign Agent

Dans le cas o le rseau ne possde pas de Foreign Agent , le mobile doit obtenir une
adresse IP dans le rseau visit (visited IP). Une fois cette adresse obtenue, il contacte
son Home Agent afin de lui indiquer sa nouvelle adresse. A ce stade, la station mobile possde deux adresses : celle de son rseau nominal (Home IP) et celle du rseau
visit (Visited IP). Le rseau est alors configur comme illustr sur la figure 2.1.4.1.
Figure 2.1.4.1. Solution Mobile IP sans Foreign Agent
Suivant cette configuration, les paquets en provenance du serveur parviennent au

Home Agent qui les redirige alors directement vers la station mobile. La station mobile peut continuer envoyer directement ses paquets vers le serveur, mais pour assurer
le fonctionnement du mcanisme de re-routage, doit indiquer dans le champ expditeur
l'adresse IP qu'elle avait dans son rseau nominal (Home IP).
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.1.5. Considration sur Mobile IP

Dans Mobile IP , les pertes sont dues au paquets envoys par le serveur vers le
Home Agent alors que le mobile n'est plus accessible l'adresse enregistre dans ce
dernier. Cela correspond au temps que le mobile met s'enregistrer dans le nouveau rseau visiter et mettre jour sa localisation dans le Home Agent .
Le protocole Mobile IP est assez efficace lorsque les mobiles ne changent pas trop
souvent de domaine. La frquence de reconfiguration des tables de correspondance
Mobile/Home Agent/Foreign Agent est alors assez faible. Par contre, si le mobile
est amen changer trs frquemment de domaine, la frquence des mises jour peut
tre assez handicapant car chaque changement de cellule induit un temps de reconfiguration pendant lequel le Mobile ne peut plus recevoir de donnes. Cest en partie pour
palier ces problmes que la solution Cellular IP a t propos.
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).
2.2.1. Principe du protocole Cellular IP

Dans Cellular IP , chaque mobile se trouve dans une zone desservie par une passerelle laquelle sont relis des routeurs et des stations de base. Chaque station de base
dessert une zone appele cellule (Cf. figure 2.2.1.1)
Dans ce type de rseau, tout le trafic engendr par les stations mobiles doit obligatoirement transiter via la passerelle. Le mobile est identifi par son adresse IP complte : le
protocole ne tient pas compte de la hirarchisation que peut contenir ladresse IP. Ainsi,
le mobile est totalement libre de se dplacer, sans changer d'adresse, dans le sous rseau
dlimit par la passerelle.
227
Figure 2.2.1.1. Exemple de topologie d'un rseau implmentant Cellular IP
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 .
2.2.2. Illustration de la mobilit cellular IP

Prenons le cas d'une station mobile initialement attache au point d'accs G (Cf. figure
2.2.2.1). Les paquets transitent par les noeuds G, E, C et A.
Figure 2.2.2.1. Cellular IP : situation initiale
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 ).
Figure 2.2.2.2. Cellular IP : situation intermdiaire
Au final, l'expiration de la route C, E, G, le rseau arrive la situation dcrite sur la figure 2.2.2.3.
229
Figure 2.2.2.3. Cellular IP : situation finale
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
Annexe H. Echanges SIP
1. Appel avort (sans dcrochage)

1. INVITE
INVITE sip:0616771297@137.194.3.73 SIP/2.0..Via: SIP/2.0/UDP
137.194.3.73;rport;branch=z9hG4bK89c20349000000264492695a000073fa00000038..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: 1 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)....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..
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
<sip:0616771297@137.194.3.73>;tag=as5448b713..User-Agent:
SJphone/1.60.289a (SJ Labs)....
4. INVITE
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
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
039;received=137.194.3.73..From:
<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
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:
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....
2. Appel avec dcrochage, puis raccrochage

1. INVITE
137.194.3.76;rport;branch=z9hG4bK89c224a90000004e4490334100005c3200000
0f0..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: 1
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)....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..
233
2. 407
SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP
0f0;received=137.194.3.76..From:
<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
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:
4. INVITE
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
234

<sip:0609365123@137.194.36.169>..Call-ID: F5337719-913E-41CD-83813772340A7DAF@137.194.36.169..CSeq: 2 INVITE..User-Agent: Asterisk
PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:0609365123@137.194.16.250>..Content-Length: 0....
6. 200OK
SIP/2.0 200 OK..Via: SIP/2.0/UDP
<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
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:
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
"unknown"<sip:test1@sip.enst.fr>;tag=1321520914....
236
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
tonio TX, Novembre 2001.

[Kondra] Thierry Kondratuk, Qualit de Service dans les Rseaux Mobiles 2G, Notes de
cours du master RSEE, Universit Paul Varlaine, Metz.
[Lag00] Xavier Lagrange, Philippe Godlewski, Sami Tabbane; Rseaux GSM, Hermes,
Paris, 2000
[LZ77] Jacob Ziv, Abraham Lempel, A Universal Algorithm for Sequential Data Compression, IEEE Transactions on Information Theory, Mai 1977.
[LZ78] Jacob Ziv, Abraham Lempel, Compression of Individual Sequences via Variable-Rate Coding, IEEE Transactions on Information Theory, septembre 1978
[LZW84] Terry A Welch, A technique for High-Performance Data Compression, Computer, vol 17.
[Mar03] Philippe Martins, TCP et les rseaux mobiles, support de cours, ENST-Paris,
2003
[Mou92] Michel Mouly, Marie Bernadette Pautet, The GSM system for mobile communications, Cell & Sys , 1992.
[Oye05] Oyedapo Olufemi, Martins Philippe, Lagrange Xavier. VIGIE : A learning tool
for cellular air interfaces (GSM, GPRS, UMTS, WiFi). The IPSI BgD Transactions on
Internet Research, 2005, Vol. 1, N 2
[Pej04] Pejman Roshan, Jonathan Leary, Rseaux WiFi : Notions fondamentales, Pearson Education, Aout 2004.
[Pre02] K. Premkumar and A. Chockalingam, Performance of LLC and TCP on GPRS
Uplink with RLC Slot Level Retransmission, http://citeseer.nj.nec.com/premkumar01performance.html, 2002
[Qix00] Qixiang Pang, Amir Bigloo, Victor C. M. Leung et Chris Scholefield, Performance Evaluation of Retransmission Mechanism in GPRS Networks, IEEE, 2000
[Rou02] Nicolas Rouhana et Eric Horlait, CIRP : Cellular IP Reservation Protocol,
CFIP, Montral, Mai 2002.
[Ros03] David Ros, TCP : Protocole de Contrle de Transmission, support de cours,
ENST-Bretagne, 2003 [http://www.rennes.enst-bretagne.fr/~dros/]
[Sam03] R. Samarasinghe, V. Friderikos, A.H. Aghvami, Analysis of Intersystem Handover: UMTS FDD & WLAN, London Communications Symposium, 8th-9th Septembre
2003
[Seu00] Seurre, Savelli, Pietri; EDGE for mobile Internet; Artech House, Boston, 2000
[Tan03] Andrew Tanenbaum, Rseaux, Pearson Education, mai 2003
[Val98] AValk, A. Campbell, J. Gomez, Internet Draft, Cellular IP, Ericsson, Columbia University, Novembre 1998.
[Val99] Andras G. Valko, "Cellular IP: A New Approach to Internet Host Mobility''
ACM Computer Communication Review, January 1999.
[Vig03] Nicolas Dailly, Philippe Martins, Xavier Lagrange, Plate forme pdagogique
VIGIE, site internet avec exemple de traces : http://www.rennes.enst-bretagne.fr/~xla238
grang/Vig_public/index.html, Juillet 2003

[Xia04] Xiaoyu Liu, Youn-Hee Han, Considerations regarding L2&L3 Schemes in
802.3/802.11 Handover, Samsung, Juillet 2004
[Zha03] Wenhui Zhang, Juergen Jaehnert, Klaus Dolzer, Design and Evaluation of a
Handover Decision Strategy for 4th Generation Mobile Network, IEEE Vehicular Technology Conference (VTC), Jeju (Korea), April 2003
[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
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
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
[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
3GPP : 3rd Gnration Partnership

Project
8-PSK : 8-Phase Shift Keying
AMRT : accs Multiple Rpartition
dans le Temps (TDMA)
AP : Access Point
APN : Access Point Name
ARFCN : Absolute Radio Frequency
Channel Number
ASCII : American Standard Code for
Information Interchange
ASN.1 : Abstract Syntax Notation 1
CAC : Call Admission Control

CCN : Cell Change Notification
CDMA : Code Division Multiple
Access
CS-x : Coding Scheme nx
CSCF : Call Session Control Function
CSS : Cascading Style Sheet
DECT : Digital Enhanced Cordless
Technology
DNS : Domain Name Server
ATM : Asynchronous Transfer Mode

AUC : Authentification Center
BCCH : Broadcast Control Channel
EDGE : Enhanced Data rates for

Global Evolution
BER : Block Error Rate
E-GPRS : Enhanced General Packet

Radio Service
BER : Basic Encoding Rules
EIR : Equipment Identity Register
BSC : Base Station Controler
ENST : Ecole Nationale Suprieure

des Tlcommunications
BSIC : Base Station Identity Code

BSN : Block Sequence Number
BSS : Base Station Subsystem
BSSGP : Base Station Subsystem
GPRS Protocol
EPIC : Efficient Protocol Independent Compression

ETSI : European Telecommunication
Standarts Institute
BTS : Base Transceiver Station
FAI : Final Ack Indicator
BVCI : BSSGP Virtual Connection

Identifier
FBI : Final Block Indicator
243
FSK : Frequency Shift Keying
Network (RNIS)
FTP : File Transfert Protocol
ISUP : ISDN User Part

IWF : Interworking Function
GERAN : GSM / EDGE Radio

Access Network
GGSN : Gateway GPRS Support
Node
LAN : Local Area Network

LLC : Logical Link Control
GLL : Generic Link Layer

GMM : GPRS Mobility Management
GMSC : Gateway Mobile Switching
Centre
GMSK : Gaussian Minimum Shift
Keying
GPRS : General Packet Radio Service
GSM : Global System for Mobile
communications
MAC : Medium Access Control

MCS-x : Modulation and Coding
Scheme nx
MGCF : Media Gateway Controller
Function
MIC : Modulation par Impulsion et
Codage (PCM)
MMS : Multimedia Messaging Service
GTP : GPRS Tunnelling Protocol
MRFC : Multimedia Resource Function Control
HLR : Home Location Register
MRFP : Multimedia Resource Function Processor
HSS : Home Subscriber Server
MS : Mobile Station
HTML : Hypertext Markup Language
MSC : Mobile Switching Centre
HTTP : Hypertext Transport Protocol
MUX : Multiplexeur / Dmultiplexeur

NCO : Network Control Order
I-CSCF : Interrogating Call Session

Control Function
NCx : Network Control Cell Reselection Mode x
IETF : Internet Engineering Task

Force
NSAPI : Network Service Access

Point Identifier
IMS : IP Multimdia Subsystem
NS : Network Service
IMSI : International Mobile Subscriber Identity
NSS : Network Sub-System
IMS-MGW : IMS Media Gateway

IP : Internet Protocol
IPP : Interrupted Poison Process
ISDN : Integrated Service Digital
244
PACCH : Packet Associated Control

Channel
PBCCH : Packet Broadcast Control
Channel
Glossaire
PCM : Pulse Code Modulation
RXQUAL : Received Signal Quality
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
SAPI : Service Access Point Identifier

SACCH : Slow Associated Control
Channel
SACK : Selective Acknowledgement
S-CSCF : Serving-Call Session Control Function
SDP : Session Description Protocol
SDU : Service Data Unit
SGSN : Serving GPRS Support Node
SI : System Information
SigComp : Signalling Compression
SIP : Session Initiation Protocol
QoS : Quality of Service
S-LLC : SGSN LLC

SMS : Short Message Service
RAN : Radio Access Network

RAT : Radio Access Technologie
SMTP : Simple Mail Transfer Protocol
RBB : Received Block Bitmap
SNDCP : Sub-Network Dependant

Convergence Protocol
RBSN : Reduced Block Sequence

Number
SNS : Sequence Number Space
RF : Radio Frequency
RFC : Request For Comments
SRTT : Smooth RTT

SS7 : Signalling System n7
SSN : Starting Sequence Number
RLC : Radio Link Control

R-LLC : Radio LLC
RNIS : Rseau Numrique Intgration de Service (ISDN)
RNC : Radio Network Controller
TBF : Temporary Block Flow

TCP : Transmission Control Protocol
RR : Radio Ressource
TDMA : Time Division Multiple

Access (AMRT)
RTC : Rseau Tlphonique Commut
TFI : Temporary Flow Identity
RTO : Retransmission Time-Out
TMSI : Temporary Mobile Subscriber Identity
RTT : Round Trip Time
TR : Technical Recommandation
RXLEV : Received Signal Level
TRX : Transmitter / Receiver
245
TS : Technical Specification
VLR : Visitor Location Register
UDP : User Datagram Protocol
UMTS : Universal Mobile Telecommunications System
URL : Uniform Ressource Locator
246
VoIP : Voice over IP

WAP : Wireless Application Protocol
WIFI : Wireless Fidelity
USF : Uplink State Flag
WLAN : Wireless LAN
UTRAN : UMTS Terrestrial Radio

Access Network
WS : Window Size

These - Optimisation Des Réseaux D'accès Mobiles

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

These - Optimisation Des Réseaux D'accès Mobiles

Загружено:

Авторское право:

Доступные форматы

Thse

prsente pour obtenir le grade de Docteur

Spcialit : Informatique et Rseaux

Soutenue le 22 juin 2007 devant le jury compos de :

Table des matires

5.1. Aperu de la structure du simulateur................................................................................. 89

6.1. Conservation d'un contexte de compression.................................................................... 171

Annexe D. Droulement d'un change de donnes au niveau RLC et LLC....................................211

Index des illustrations

Figure 4.4.3.3. Handover optimis : intra-BSC / intra RA [3GPP 43.129].......................................86

Index des tables

mique de ressources sur cette interface. Ces mcanismes permettent le dploiement de

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

Chapitre I : Allocation dynamique de ressources

Figure 2.1.1. Interface Abis

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

2.2. Limitations du systme existant

2.3. Une approche dynamique pour l'interface Abis

3. Etudes de modles thoriques pour l'interface Abis dynamique

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

Les contraintes de ce modle sont alors les suivantes :

3.2. Rsultats pour deux et quatre classes d'utilisateurs

La figure 3.2.1.2 reprsente le taux de perte des appels de classe 1 et de classe 2 en

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

Figure 3.2.1.2. Probabilit de perte pour deux classes dutilisateurs, charge

3.2.2. Quatre classes d'utilisateurs, charge par classe identique

Figure 3.2.2.1. Probabilit de perte pour quatre classes dutilisateurs, charge

3.2.3. Deux classes dutilisateurs, charges distinctes

Figure 3.2.3.1. Probabilit de perte des appels de classe 1, charges diffrencies

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

Figure 3.2.3.2. Probabilit de perte des appels de classe 2, charges diffrencies

3.3. Dfinition d'un modle de trafic temps rel

Figure 3.3.1. Chaine de Markov N serveurs, sans file d'attente (M/M/U/0)

Si on note X le nombre d'utilisateurs ayant une session en cours, on a [Ham05][Dec04] :

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

Application au systme E-GPRS

Figure 3.3.3. Modlisation du systme de trafic GPRS temps rel

Contraintes sur le systme

Figure 3.3.4. Reprsentation du trafic IPP gnr par un groupe d'utilisateurs

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

On retrouve cette formule dans la dmonstration qui tablit la formule d'Engset

Influence de la capacit daccueil du systme

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

On notera qu'il ny a aucun rejet dappel d lindisponibilit des ressources lorsque le

Influence de la charge du systme

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

Figure 3.3.8. Taux de perte des appels en fonction de la charge du systme

4. Simulation des performances de l'interface Abis dynamique

4.1. Paramtres de simulation

Nombre de ressources ddies au trafic vocal

Nombre de ressources mixtes

Nombre de ressources ddies au trafic data

Taille des buffers dans les BTS

Taux d'erreur bloc (aprs codage)

Tableau 4.1.1.1. Paramtres de la simulation

4.1.2. Arrives et dparts des utilisateurs

Chapitre I : Allocation dynamique de ressources sur l'interface Abis E-GPRS

Tous ces paramtres sont rcapituls dans le tableau 4.1.2.1 :

Nombre d'appels vocal, par minute et par cellule

Dure moyenne des appels

Dure d'une session pour le transfert de donnes

Tableau 4.1.2.1. Paramtres de trafic

4.1.3. Profil des utilisateurs