UNIVERSIT DE MONTRAL

ARCHITECTURES 3GPP ET VOLUTION VERS IPV6

MAXIME DE ROUCY DE FLACOURT DPARTEMENT DE GNIE INFORMATIQUE ET GNIE LOGICIEL COLE POLYTECHNIQUE DE MONTRAL

MMOIRE PRSENT EN VUE DE LOBTENTION DU DIPLME DE MATRISE S SCIENCES APPLIQUES (GNIE INFORMATIQUE) FVRIER 2011

c Maxime de Roucy de Flacourt, 2011.

UNIVERSIT DE MONTRAL

COLE POLYTECHNIQUE DE MONTRAL

Ce mmoire intitul:

ARCHITECTURES 3GPP ET VOLUTION VERS IPV6

prsent par: DE ROUCY DE FLACOURT, Maxime en vue de lobtention du diplme de: Matrise s Sciences Appliques a t dment accept par le jury dexamen constitu de:

Mme. BELLACHE, Martine, Ph.D., prsidente M. PIERRE, Samuel, Ph.D., membre et directeur de recherche M. QUINTERO, Alejandro, Doct., membre

iii

mes parents, Rmi et toute ma famille.

iv REMERCIEMENTS

Je voudrais particulirement remercier mon directeur de recherche, le professeur Samuel Pierre, pour son support et son encadrement durant mon cursus de matrise. Je tiens aussi remercier Yves Lemieux, charg de mon encadrement au sein de la socit Ericsson, pour son aide et son soutien, ainsi que Suresh Krishnan spcialiste snior chez Ericsson pour ses rponses claires et prcises. Parmi les membres du Laboratoire de Recherche en Informatique Mobile (LARIM), je tiens particulirement remercier Stphane Ouellette pour ses conseils et ses rponses mes nombreuses questions. Merci, encore, tous les membres du LARIM pour leur aide, entre autres Mral Shirazipour, Georges Abou Khalil et Anglo Rossi. Parmi les stagiaires avec qui jai t amen travailler, je tiens particulirement remercier Mehdi Hamdoun dont le travail ma t trs utile.

v RSUM

Dans les rseaux mobiles de troisime gnration, le trac de voix est spar du trac de donnes. Dans les rseaux de quatrime gnration, tout le trac passe par un unique rseau. Les technologies utilises dans la 4e gnration (4G) sont des volutions de celles dveloppes pour General Packet Radio Services (GPRS) et nutilisent que trs peu les capacits du protocole Internet Protocol (IP) (prsent sur le plan de donnes). La norme IP version 6 (IPv6), nalise en dcembre 1998, dnit le nouveau standard du protocole IP. Elle simplie le protocole et augmente ses fonctionnalits, elle facilite notamment le support de la mobilit. Aujourdhui les principaux protocoles tendant IPv6 ou lutilisant pour fournir de la mobilit sont Mobile IPv6 (MIPv6) et Proxy Mobile IPv6 (PMIPv6). Malgr cette volution de IP, le rseau 4G dvelopp par le consortium Third generation partnership project (3GPP) utilise, pour grer la mobilit des usagers, le protocole GPRS Tunneling Protocol (GTP) dvelopp la base pour GPRS. Il gre aussi en partie la Quality of Service (QoS) sur le rseau cur Evolved Packet Core (EPC). Les techniques de QoS permettent de direntier les tracs transitant sur le rseau et de leur appliquer des restrictions et/ou priorits direntes. Ces techniques sont gnralement utilises sur des rseaux susceptibles dtre saturs, ce qui est le cas dans les rseaux mobiles. Elles sont donc trs importantes sur le rseau Evolved Packet System (EPS) dautant plus que celui-ci transporte du trac de voix. Le trac de voix est critique, car la fonction premire des rseaux mobiles est de connecter des tlphones cellulaires au Public Switched Telephone Network (PSTN). Le rseau doit aussi permettre un accs un dorsal IP couramment appel Internet, en thorie nimporte quel type de trac peut y circuler : vido, web, File Transfer Protocol (FTP), Peer-to-Peer (P2P), etc. Dans le protocole GTP des tunnels sont crs pour chaque usager, appel User Equipment (UE), les tunnels dun mme UE ayant chacun une QoS dirente. Mais tous les paramtres de QoS ne sont pas appliqus par le protocole GTP, certains comme la priorit de transmission (forwarding priority ) doivent tre grs par les couches infrieures du rseau. Les techniques de QoS utiliser ne sont pas dnies par 3GPP, en revanche des documents comme le 23.401 [8] mentionnent Dierentiated Services (DiServ) comme exemple. Le protocole PMIPv6 a lavantage sur MIPv6 de ne pas modier les fonctionnalits de la couche IPv6 du nud mobile. De base il nutilise quun tunnel entre un Mobile Access Gateway (MAG) et un Local Mobility Anchor (LMA) (voir section 2.2.3 pour plus dexplications) pour acheminer le trac de tous les terminaux attachs au MAG. Lutilisation dun seul tunnel empche la direntiation des tracs et donc lutilisation des mthodes de

vi QoS classiques. Cest pourquoi Hui et al. [70] propose de modier le protocole PMIPv6 pour permettre la cration dun tunnel par ux, de faon permettre lapplication de rgles de QoS direntes. En nous inspirant de ces modications nous pouvons donc transformer le protocole PMIPv6 de faon ce quil supporte les mmes fonctionnalits que GTP User data tunneling (GTP-U). Le protocole IPv6 est actuellement gr par quasiment tous les systmes dexploitation et les adresses IP version 4 (IPv4) encore disponibles disparaissent rapidement, nous avons donc considr que le rseau EPS utilise uniquement le protocole IPv6. Partant de ce principe et ayant remarqu quIPv6 peut tre utilis pour grer la mobilit des usagers, nous avons cherch maximiser son utilisation. Nous proposons donc deux nouvelles architectures du rseau EPC utilisant une version de PMIPv6 lgrement modie pour supporter la gestion de plusieurs tunnels entre un MAG et un LMA, la manire de GTP. tant donn le peu de bande passante dont disposent ces rseaux mobiles compars aux rseaux daccs laires et le caractre critique de certains tracs quils vhiculent, nous avons d vrier que nos modications ne rduisent pas les performances du rseau du point de vue des usagers. Pour ce faire nous avons implment dans le simulateur Network Simulator version 2 (NS-2) les architectures EPS dcrites dans les documents 23.401 [8] et 23.402 [9] ainsi que celles que nous proposons. Au vu des rsultats nous pouvons dire que larchitecture 23.401 [8] ore de meilleures performances que toutes les autres. Cependant, 23.402 [9] a t dveloppe pour rpondre une problmatique dordre politique, survenant lors de lajout dun rseau daccs non dvelopp par 3GPP au rseau cur. Cette architecture, sur laquelle nous nous sommes bass, peut donc tre mise en place dans nimporte quel environnement contrairement la 23.401 [8]. Grce aux simulations nous pouvons dire que les modications que nous avons apportes ne modient pas, voire amliorent lgrement, les performances de larchitecture 23.402 [9]. En conclusion nous conseillons aux oprateurs dsirant mettre en place un rseau 4G utilisant une des architectures proposes par 3GPP, dutiliser 23.401 [8] (tant donn ses meilleures performances) si cela leur est politiquement possible. Sinon dutiliser lune des architectures bases sur 23.402 [9] que nous proposons.

vii ABSTRACT

In third generation mobile network, the voice trac is separated from the data trac. In fourth generation all goes through a unique network. Technologies used in 4G network evolved from those developed for GPRS, they dont use IPs capacity. IPv6 norm, released in 1998, describes the new standard for IP protocol. It simplies the way IP works and increases its functionality, notably mobility integration were facilitated. Today MIPv6 and PMIPv6 are leaders protocols to include mobility in IPv6. Even with those evolutions, 3GPPs 4G network still uses GTP (rstly developed for GPRS) to manage its users mobility; but GTP also manages some part of the QoS mechanism. QoS techniques permit dierentiating network ows and apply some restrictions and/or priorities to them. Those techniques are usually used when the network can be congested, which is the case for mobile network. So they are important for EPS network, specially since it carries voice trac. Voice trac is critical since the one of the rst goals of mobile network is to allow cellular phone to connect to the PSTN. The network must also provide facilities to the users to them to access an IP backbone, which means that theoretically all sorts of trac can be presented, video, web, FTP, P2P, etc. GTP protocol creates tunnels for each user, called UE, each tunnel of a UE has a dierent QoS. But all the QoS parameters arent applied by GTP, some (like the forwarding priority) need to be applied by underlying stack. 3GPP doesnt specify the QoS techniques used by stacks under GTP. However, it mentions DiServ as an example in the document 23.401 [8]. PMIPv6 protocol has the advantage against MIPv6 that it doesnt need the mobile node to have a modied IPv6 stack. Its basic version uses one tunnel between an LMA and a MAG (see section 2.2.3) to carry all tracs from and to mobiles nodes attached to this MAG. The use of a unique tunnel prevents the use of common QoS techniques like DiServ since it hardeners the dierentiation of trac ows. Thats why Hui et al. [70] suggest to modify PMIPv6 in order to create one tunnel by ow. So by applying small modications to PMIPv6 (inspired by Hui et al. [70] suggestions) we should be able to support the same functionalities as GTP-U. Currently, near all the operating systems have an IPv6 stack and the number of IPv4 addresses still unallocated is decreasing quickly. So we decided to assume that EPS network only uses the IPv6 protocol. As IPv6 can be used to manage some part of QoS and mobility through PMIPv6, we searched to increase its use in EPC. So we suggest two new architectures based on 23.402 [9] for EPC network, which used a modied version of PMIPv6 to support the creation of several tunnels between a MAG and an LMA and to match GTP-U functionalities.

viii However, due to the lack of bandwidth in such network and the criticism of voice trac, we had to check that our suggestion doesnt damage the network performances from the users point of view. To test these performances, we implement architecture 23.401 [8], 23.402 [9] and those that we propose. The results of our simulations show that 23.401 [8] has the best performances. However, this architecture suers from some political problems and cant be built in every situation. Thats why 3GPP released the 23.402 [9] architecture which has the advantage to politically support a larger scale of access networks. For our work, we based our architecture on 23.402 [9]. Simulations show that we dont damage and sometimes we even improve the performances of 23.402 [9]. To conclude, we advise operators wishing to build 4G networks based on 3GPP architectures to use the 23.401 [8] if its possible. But if, for political reason, they cant use 23.401 [8] to consider ours since their performances are better and they improve the use of IPv6.

ix TABLE DES MATIRES

DDICACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REMERCIEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RSUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TABLE DES MATIRES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTE DES TABLEAUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTE DES FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTE DES ALGORITHMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTE DES SIGLES ET ABRVIATIONS . . . . . . . . . . . . . . . . . . . . . . . LISTE DES ANNEXES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPITRE 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Dnitions et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 lments de la problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Objectifs de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Plan du mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPITRE 2 ANALYSE DES RSEAUX MOBILES . . . . . . . . . . . . . .

iii iv v vii ix xii xiv xix xx xxx 1 1 4 5 5 6 6 7 7 9 13 14 19 20 28

2.1 Dnitions et concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Advanced Mobile Phone System . . . . . . . . . . . . . . . . . . . . . 2.1.2 Global System for Mobile communications . . . . . . . . . . . . . . . 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 General Packet Radio Services . . . . . . . . . . . . . . . . . . . . . . Enhanced Data rates for GSM Evolution . . . . . . . . . . . . . . . . Universal Mobile Telecommunications System . . . . . . . . . . . . . Worldwide Interoperability for Microwave Access . . . . . . . . . . . Long Term Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Mobilit IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

x 2.2.1 2.2.2 2.2.3 Mobile IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 29 31 36 36 37 37 38 38 42

2.3 DiServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Le marquage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 CHAPITRE 3 La classication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le Trac Conditionning aussi appel Policing . . . . . . . . . . . . . Active Queue Management . . . . . . . . . . . . . . . . . . . . . . . . Le Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rsum et Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROPOSITION DVOLUTION VERS UNE UTILISATION PLUS AVANCE DIPv6 . . . . . . . . . . . . . . . . . . . . .

44 44 45 48 49 51 53 57 60 67 68 68

3.1 Larchitecture 23.401 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Larchitecture 23.402 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Proxy Mobile IPv6 multi-tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Larchitecture 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Larchitecture 404 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Performance du rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Le taux de perte de paquets . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 CHAPITRE 4 La gigue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VALUATION ET ANALYSE DES PERFORMANCES DES DIFFRENTES ARCHITECTURES . . . . . . . . . . . . . . . 4.1 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 Scnario simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scnario charg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70 70 70 74 78 78 79 79 82 84 85

4.1.3 Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Implmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Network Simulator version 2 . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 4.2.3 4.2.4 4.2.5 Plan de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Aware Support Node . . . . . . . . . . . . . . . . . . . . . . . Bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rseau radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi 4.2.6 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.7 Dierentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S1-AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liens Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 90 91 91 93 93 95 97 97 103 104 104 105 106 107 115

CHAPITRE 5 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Synthse des travaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Limitations de la solution propose . . . . . . . . . . . . . . . . . . . . . . . 5.3 Amliorations futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RFRENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ANNEXES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xii LISTE DES TABLEAUX

Tableau 2.1 Tableau 2.2 Tableau 4.1 Tableau 4.2 Tableau 4.3 Tableau G.1 Tableau G.2 Tableau G.3 Tableau G.4 Tableau G.5 Tableau G.6 Tableau G.7 Tableau G.8 Tableau G.9 Tableau G.10 Tableau G.11 Tableau G.12 Tableau G.13 Tableau G.14 Tableau G.15 Tableau G.16 Tableau G.17 Tableau G.18 Tableau G.19 Tableau H.1 Tableau H.2 Tableau H.3 Tableau H.4 Tableau H.5 Tableau H.6 Tableau H.8 Tableau H.7

Caractristiques des classes de QoS utilises en UMTS . . . . . . . . QCI standardis du rseau LTE . . . . . . . . . . . . . . . . . . . . Comparaison des dures des principales procdures entre les architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparaison entre SCTP, TCP et UDP . . . . . . . . . . . . . . . . Taille des options du protocole PMIPv6 . . . . . . . . . . . . . . . . Taille des IE du protocole GTP . . . . . . . . . . . . . . . . . . . . . Taille des informations du IE ULI du protocole GTP . . . . . . . . . Create Session Request . . . . . . . . . . . . . . . . . . . . . . . . . Create Session Response . . . . . . . . . . . . . . . . . . . . . . . . Delete Session Request . . . . . . . . . . . . . . . . . . . . . . . . . Delete Session Response . . . . . . . . . . . . . . . . . . . . . . . . . Modify Bearer Request . . . . . . . . . . . . . . . . . . . . . . . . . Modify Bearer Response . . . . . . . . . . . . . . . . . . . . . . . . Update Bearer Request . . . . . . . . . . . . . . . . . . . . . . . . . Update Bearer Response . . . . . . . . . . . . . . . . . . . . . . . . Create Bearer Request . . . . . . . . . . . . . . . . . . . . . . . . . Create Bearer Response . . . . . . . . . . . . . . . . . . . . . . . . . Bearer Resource Command . . . . . . . . . . . . . . . . . . . . . . . Delete Bearer Request . . . . . . . . . . . . . . . . . . . . . . . . . . Delete Bearer Response . . . . . . . . . . . . . . . . . . . . . . . . . Create Indirect Data Forwarding Tunnel Request . . . . . . . . . . . Create Indirect Data Forwarding Tunnel Response . . . . . . . . . . Delete Bearer Command . . . . . . . . . . . . . . . . . . . . . . . . Delete Indirect Data Forwarding Tunnel Response . . . . . . . . . . Taille des AVP du protocole Diameter . . . . . . . . . . . . . . . . . Update Location Request . . . . . . . . . . . . . . . . . . . . . . . . Update Location Answer . . . . . . . . . . . . . . . . . . . . . . . . Authentication Information Request . . . . . . . . . . . . . . . . . Authentication Information Answer . . . . . . . . . . . . . . . . . . Insert Subscriber Data Request . . . . . . . . . . . . . . . . . . . . . Credit-Control-Request . . . . . . . . . . . . . . . . . . . . . . . . . Insert Subscriber Data Answer . . . . . . . . . . . . . . . . . . . . .

17 27 74 94 98 185 186 187 188 188 188 189 190 191 191 192 192 193 193 193 194 194 195 195 196 205 205 205 206 206 206 206

xiii Tableau H.9 Tableau H.10 Tableau H.11 Tableau H.12 Tableau H.13 Tableau H.14 Tableau H.15 Tableau H.16 Tableau H.17 Tableau H.18 Credit-Control-Answer . . . . . . . . . . . . . . . . . . . . . . . . . Indication of IP-CAN Session Establishment : connexion . . . . . . . Indication of IP-CAN Session Establishment/Modication : cration, modication ou suppression de bearer . . . . . . . . . . . . . . . . . Acknowledge IP-CAN Session Establishment . . . . . . . . . . . . . Re-Auth-Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . Re-Auth-Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy and Charging Rules Provision . . . . . . . . . . . . . . . . . . Acknowledge Policy and Charging Rules Provision . . . . . . . . . . Gateway Control Session Establishment . . . . . . . . . . . . . . . . Gateway Control Session Modication : cration, modication ou suppression de bearer . . . . . . . . . . . . . . . . . . . . . . . . . . 208 209 210 210 211 212 212 213 214 215

xiv LISTE DES FIGURES

Figure 1.1 Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 2.5 Figure 2.6 Figure 2.7 Figure 2.8 Figure 2.9 Figure 2.10 Figure 2.11 Figure 2.12 Figure 2.13 Figure 2.14 Figure 2.15 Figure 2.16 Figure 2.17 Figure 2.18 Figure 2.19 Figure 2.20 Figure 2.21 Figure 2.22 Figure 2.23 Figure 3.1 Figure 3.2 Figure 3.3 Figure 3.4 Figure 3.5 Figure 3.6 Figure 3.7 Figure 3.8

Architecture propose par 3GPP . . . . . . . . . . . . . . . . . . . . . Architecture simplie dun PLMN GSM . . . . . . . . . . . . . . . . Architecture des rseaux GPRS . . . . . . . . . . . . . . . . . . . . . Couches de protocoles du plan de donnes dans le rseau GPRS . . . Couches de protocoles du plan de contrle dans le rseau GPRS . . . Architecture logique du rseau UMTS . . . . . . . . . . . . . . . . . . Protocoles radio UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . Architecture de bearer utilise dans UMTS . . . . . . . . . . . . . . . Architecture logique du rseau WiMAX . . . . . . . . . . . . . . . . . Architecture simplie du rseau LTE . . . . . . . . . . . . . . . . . . Schma gnral du rseau EPS . . . . . . . . . . . . . . . . . . . . . . Communication MIPv4 avec FA CoA . . . . . . . . . . . . . . . . . . Communication MIPv4 avec co-located CoA . . . . . . . . . . . . . . Communication MIPv6 avec optimisation de routage . . . . . . . . . .

3 8 10 10 11 15 18 18 20 21 22 30 30 31

Ensemble des lments du rseau PMIPv6 (Proxy Mobile IPv6 Domain ) 33 Attache dun MN un domaine PMIPv6 . . . . . . . . . . . . . . . . 34 Communication simple dans un rseau PMIPv6 . . . . . . . . . . . . 34 Handover dans un domaine PMIPv6 . . . . . . . . . . . . . . . . . . . Filtre de Seau Jeton . . . . . . . . . . . . . . . . . . . . . . . . . . . Filtre srTCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Filtre trTCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mthodes de gestion des les dattente Drop Tail et RED . . . . . . . Mthode de gestion de le dattente WRED . . . . . . . . . . . . . . Chemin dun paquet en sortie dun routeur DiServ Edge . . . . . . . Couches de protocoles du plan de donnes dans un EPS . . . . . . . . Schma reprsentatif des bearers GTP dans larchitecture 23.401 . . . Couches de protocoles utilises sous GTP . . . . . . . . . . . . . . . . En-tte GTP-U utilis dans le plan de donnes . . . . . . . . . . . . . En-tte GTP-C utilis dans le plan de contrle . . . . . . . . . . . . . En-tte classique dun IE dans le protocole GTP-C . . . . . . . . . . . Couches de protocoles du plan de donnes dans un EPS suivant larchitecture 23.402 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 38 39 39 40 40 43 45 45 46 47 47 48 48

Schma reprsentatif des bearers GTP et GRE dans larchitecture 23.402 49

xv Figure 3.9 Figure 3.10 Figure 3.11 Figure 3.12 Figure 3.13 Figure 3.14 Figure 3.15 Figure 3.16 Figure 3.17 Figure 3.18 Figure 3.19 Figure 3.20 Figure 3.21 Figure 3.22 Figure 3.23 Figure 3.24 Figure 3.25 Figure 3.26 Figure 3.27 Figure 3.28 Figure 4.1 Figure 4.2 Figure 4.3 Figure 4.4 Figure 4.5 Figure 4.6 Figure 4.7 Figure 4.8 Figure 4.9 Figure 4.10 Figure 4.11 Figure 4.12 En-tte du protocole Diameter . . . . . . . . . . . . . . . . . . . . . . En-tte classique dun AVP dans le protocole Diameter . . . . . . . . Structure classique du protocole Diameter . . . . . . . . . . . . . . . . Couches de protocoles utilises sous Diameter . . . . . . . . . . . . . . Exemple dutilisation de PMIPv6 avec plusieurs tunnels . . . . . . . . Option Service Flow Identier de PMIPv6 . . . . . . . . . . . . . . . Option Service Flow Description de PMIPv6 . . . . . . . . . . . . . . Option GRE Key de PMIPv6 . . . . . . . . . . . . . . . . . . . . . . 50 50 51 51 52 52 52 52

Cration dun tunnel spcique un service dans larchitecture PMIPv6 53 En-tte IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Option Trac Flow Template propose pour PMIPv6 . . . . . . . . . 55 Option Packet Filter propose pour PMIPv6 . . . . . . . . . . . . . . Option Flow Label de PMIPv6 . . . . . . . . . . . . . . . . . . . . . . Couches de protocoles du plan de donnes dans un EPS suivant larchitecture 403 propose . . . . . . . . . . . . . . . . . . . . . . . . Compltion de bearer ddi non GBR avec UE QoS unaware . . . . . Couches de protocoles du plan de donnes dans un EPS suivant larchitecture 404 propose . . . . . . . . . . . . . . . . . . . . . . . . Compltion de bearer ddi non GBR avec UE QoS unaware . . . . . Destruction de bearer ddi avec UE QoS unaware . . . . . . . . . . . S1 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S1 Handover avec changement de SGW . . . . . . . . . . . . . . . . . Architecture du rseau simul . . . . . . . . . . . . . . . . . . . . . . 56 57 58 59 60 61 62 64 66 71

Dlai moyen du trac de voix entre le SASN et le UE . . . . . . . . . 72 Dlai moyen du trac de voix, la connexion et la relve ayant t dcales 73 Architecture du rseau simul (version charge) . . . . . . . . . . . . . 75 Gigue du trac de voix entre le SASN et les UE . . . . . . . . . . . . Taux de perte de paquets global du trac de voix entre le SASN et les UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation des direntes composantes dun nud dans le simulateur NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 78 80

Diagramme des principales classes de notre simulateur . . . . . . . . . 81 Diagramme des classes reprsentant les donnes changes par les nuds 82 Diagramme dobjet du SASN dans notre simulateur . . . . . . . . . . Diagramme des classes reprsentant les bearers de notre simulateur . . Diagramme dobjet reprsentant le scheduling des bearers . . . . . . . 83 84 85

xvi Figure 4.13 Figure 4.14 Figure 4.15 Figure 4.16 Figure 4.17 Figure 4.18 Figure 4.19 Figure 4.20 Figure 4.21 Figure 4.22 Figure 4.23 Figure 4.24 Figure 4.25 Figure 4.26 Figure 4.27 Figure 4.28 Figure A.1 Figure A.2 Figure A.3 Figure A.4 Figure A.5 Figure A.6 Figure A.7 Figure A.8 Figure A.9 Figure A.10 Figure A.11 Figure A.12 Figure A.13 Figure A.14 Figure A.15 Figure A.16 Figure A.17 Diagramme des classes utilises dans la simulation du lien radio . . . Reprsentation des direntes composantes dun lien dans le simulateur NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme des classes gnrant les traces . . . . . . . . . . . . . . . . En-tte du protocole SCTP . . . . . . . . . . . . . . . . . . . . . . . . En-tte des chunks de passage de donnes et dacquittement du protocole SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . En-tte commun tous les paquets NAS . . . . . . . . . . . . . . . . En-ttes relatifs ESM dans le protocole NAS . . . . . . . . . . . . . En-tte relatif EMM dans le protocole NAS . . . . . . . . . . . . . . Format des donnes contenues dans un paquet de contrle PMIPv6 (Mobility Header ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy Binding Update . . . . . . . . . . . . . . . . . . . . . . . . . . Option Access Technology Type de PMIPv6 . . . . . . . . . . . . . . . Option Hando Indicator de PMIPv6 . . . . . . . . . . . . . . . . . . Option Mobile Node Identier de PMIPv6 . . . . . . . . . . . . . . . Option Prex Information de PMIPv6 . . . . . . . . . . . . . . . . . Proxy Binding Update utilis . . . . . . . . . . . . . . . . . . . . . . . Proxy Binding Acknowledgement . . . . . . . . . . . . . . . . . . . . Compltion de bearer ddi GBR avec UE QoS aware . . . . . . . . . Compltion de bearer ddi GBR avec UE QoS unaware . . . . . . . . Compltion de bearer ddi non GBR avec UE QoS aware . . . . . . . Compltion de bearer ddi non GBR avec UE QoS unaware . . . . . Connexion dun UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cration de bearer ddi avec UE QoS aware . . . . . . . . . . . . . . Cration de bearer ddi avec UE QoS unaware . . . . . . . . . . . . Destruction de bearer ddi avec UE QoS aware . . . . . . . . . . . . Destruction de bearer ddi avec UE QoS unaware . . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS aware . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS unaware . . . . . . . . Rduction de bearer ddi non GBR avec UE QoS aware . . . . . . . Rduction de bearer ddi non GBR avec UE QoS unaware . . . . . . S1 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S1 Handover avec changement de SGW . . . . . . . . . . . . . . . . . X2 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X2 Handover avec changement de SGW . . . . . . . . . . . . . . . . . 86 88 89 95 96 96 96 97 97 98 99 99 99 99 100 101 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132

xvii Figure B.1 Figure B.2 Figure B.3 Figure B.4 Figure B.5 Figure B.6 Figure B.7 Figure B.8 Figure B.9 Figure B.10 Figure B.11 Figure B.12 Figure B.13 Figure B.14 Figure B.15 Figure B.16 Figure C.1 Figure C.2 Figure C.3 Figure C.4 Figure C.5 Figure C.6 Figure C.7 Figure C.8 Figure C.9 Figure C.10 Figure C.11 Figure C.12 Figure C.13 Figure C.14 Figure D.1 Figure D.2 Figure D.3 Figure D.4 Figure D.5 Figure D.6 Compltion de bearer ddi GBR avec UE QoS aware . . . . . . . . . Compltion de bearer ddi GBR avec UE QoS unaware . . . . . . . . Compltion de bearer ddi non GBR avec UE QoS aware . . . . . . . Compltion de bearer ddi non GBR avec UE QoS unaware . . . . . Connexion dun UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cration de bearer ddi avec UE QoS aware . . . . . . . . . . . . . . Cration de bearer ddi avec UE QoS unaware . . . . . . . . . . . . Destruction de bearer ddi avec UE QoS aware . . . . . . . . . . . . Destruction de bearer ddi avec UE QoS unaware . . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS aware . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS unaware . . . . . . . . Rduction de bearer ddi non GBR avec UE QoS aware . . . . . . . Rduction de bearer ddi non GBR avec UE QoS unaware . . . . . . S1 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S1 Handover avec changement de SGW . . . . . . . . . . . . . . . . . X2 Handover avec changement de SGW . . . . . . . . . . . . . . . . . Compltion de bearer ddi GBR avec UE QoS aware . . . . . . . . . Compltion de bearer ddi GBR avec UE QoS unaware . . . . . . . . Compltion de bearer ddi non GBR avec UE QoS aware . . . . . . . Cration de bearer ddi avec UE QoS aware . . . . . . . . . . . . . . Cration de bearer ddi avec UE QoS unaware . . . . . . . . . . . . Destruction de bearer ddi avec UE QoS aware . . . . . . . . . . . . Destruction de bearer ddi avec UE QoS unaware . . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS aware . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS unaware . . . . . . . . Rduction de bearer ddi non GBR avec UE QoS aware . . . . . . . Rduction de bearer ddi non GBR avec UE QoS unaware . . . . . . S1 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S1 Handover avec changement de SGW . . . . . . . . . . . . . . . . . X2 Handover avec changement de SGW . . . . . . . . . . . . . . . . . Compltion de bearer ddi GBR avec UE QoS aware . . . . . . . . . Compltion de bearer ddi GBR avec UE QoS unaware . . . . . . . . Compltion de bearer ddi non GBR avec UE QoS aware . . . . . . . Connexion dun UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cration de bearer ddi avec UE QoS aware . . . . . . . . . . . . . . Cration de bearer ddi avec UE QoS unaware . . . . . . . . . . . . 134 135 136 137 138 139 140 141 141 142 142 143 143 144 145 146 148 149 150 151 152 153 154 155 156 156 157 158 159 160 162 163 164 165 166 167

xviii Figure D.7 Figure D.8 Figure D.9 Figure D.10 Figure D.11 Figure D.12 Figure D.13 Figure E.1 Figure E.2 Figure E.3 Figure E.4 Figure E.5 Figure E.6 Figure E.7 Figure F.1 Figure F.2 Figure F.3 Figure F.4 Figure F.5 Figure F.6 Figure F.7 Figure F.8 Figure F.9 Figure F.10 Figure F.11 Destruction de bearer ddi avec UE QoS aware . . . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS aware . . . . . . . . . . Rduction de bearer ddi GBR avec UE QoS unaware . . . . . . . . Rduction de bearer ddi non GBR avec UE QoS aware . . . . . . . Rduction de bearer ddi non GBR avec UE QoS unaware . . . . . . X2 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X2 Handover avec changement de SGW . . . . . . . . . . . . . . . . . Dbit du trac vido . . . . . . . . . . . . . . . . . . . . . . . . . . . Dlai moyen du trac vido entre le SASN et le UE . . . . . . . . . . Dlai moyen du trac de voix entre le SASN et le eNodeB . . . . . . . Gigue du trac de voix entre le SASN et le UE . . . . . . . . . . . . . Goodput du trac FTP . . . . . . . . . . . . . . . . . . . . . . . . . . Taux de perte de paquets du trac de voix entre le SASN et le UE . . Taux de perte de paquets du trac FTP entre le SASN et le UE . . . Dlai moyen du trac vido entre le SASN et les UE . . . . . . . . . . Dlai moyen du trac de voix entre le SASN et les UE . . . . . . . . . Dlai moyen du trac vido entre le SASN et les eNodeB . . . . . . . Dlai moyen du trac de voix entre le SASN et les eNodeB . . . . . . Gigue du trac vido entre le SASN et les UE . . . . . . . . . . . . . Dbit global du trac vido . . . . . . . . . . . . . . . . . . . . . . . . Goodput global du trac FTP . . . . . . . . . . . . . . . . . . . . . . Goodput global du trac web . . . . . . . . . . . . . . . . . . . . . . . Taux de perte de paquets global du trac vido . . . . . . . . . . . . Taux de perte de paquets global du trac web . . . . . . . . . . . . . Taux de perte de paquets global du trac FTP . . . . . . . . . . . . . 168 169 170 171 172 173 174 175 176 176 177 177 178 178 179 180 180 181 181 182 182 183 183 184 184

xix LISTE DES ALGORITHMES

Algorithme 1 Algorithme 2 Algorithme 3

Scheduler utilis sur le RAN pour distribuer la bande passante entre les UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduler utilis sur le RAN pour servir les bearers . . . . . . . . Slection du paquet sortant par notre algorithme DWBBRR . . .

87 87 92

xx LISTE DES SIGLES ET ABRVIATIONS

AAA ACQ AF AF AKA AMBR AMPS APN APN-OI ARP ARQ ASN ASN-GW ASP AuC AVP BA BBRR BCE BG BMC BSC BSS BSSGP BTS BS BU BULE

Authentication, Authorization, and Accounting Active Queue Management Assured Forwarding Application Function Authentication and Key Agreement Aggregate Maximum Bit Rate Advanced Mobile Phone System Access Point Name Access Point Name Operator Identier Allocation and Retention Priority Automatic Repeat reQuest Access Service Network ASN Gateway Application Service Provider Authentication Center Attribute Value Pairs Binding Acknowledgement bit-by-bit Round-Robin Binding Cache Entry Boarder Gateway Broadcast/Multicast Control Base Station Controller Base Station Subsystem BSS GPRS Protocol Base Transceiver Station Base Station Binding Update Binding Update List Entry

xxi CBQ CDMA CGF CGI CK CN CoA CPU CQI CSN CSG DF DFT DFTS-OFDM DiServ DL DPI DRR DS-CDMA DSCP DWBBRR EBI ECGI ECN EDGE EF EGPRS EIR EMM eNodeB Class Based Queueing Code Division Multiple Access Charging Gateway Functionality Cell Global Identier Condentiality-Key Correspondent Node Care of Address Central Processing Unit Channel-Quality Indicator Connectivity Service Network Closed Subscriber Group Default Forwarding Discrete Fourier Transform DFT-spread OFDM Dierentiated Services Downlink Deep Packet Inspection Decit Round-Robin Direct Sequence CDMA dierentiated services codepoint Decit Weighted bit-by-bit Round-Robin EPS Bearer ID EUTRAN Cell Global Identier Explicit Congestion Notication Enhanced Data rates for GSM Evolution Expedited Forwarding Enhanced GPRS Equipment Identity Register EPS Mobility Management Evolved Node B

xxii EPC EPS ESM ETSI EUL EUTRAN FA FDD FDM FDMA FIFO FQ FQ-CSID FTP F-TEID GBR GERAN GGSN GMLC GMM/SM GMSC GMSK GNU GPRS GRE GSM GSN GTP GTP-C GTP-U Evolved Packet Core Evolved Packet System EPS Session Management European Telecommunications Standards Institute Enhanced Uplink evolved UMTS Terrestrial Radio Access Network Foreign Agent Frequency Division Duplexing Frequency Division Multiplexing Frequency Division Multiple Access First In First Out Fair Queueing Fully-qualied PDN Connection Set Identier File Transfer Protocol Fully-Qualied Tunnel Endpoint Identier Guaranteed BitRate GSM EDGE RAN Gateway GPRS Support Node Gateway Mobile Location Center GPRS Mobility Management & Session Management Gateway MSC Gaussian Minimum Shift Keying GNU is Not Unix General Packet Radio Services Generic Routing Encapsulation Global System for Mobile communications GPRS support node GPRS Tunneling Protocol GTP Control GTP User data tunneling

xxiii GTPv0 GTPv1 GTPv2-C GTPv1-U GUI HA HAA HoA HARQ HLR HNP HPLMN HSDPA HS-DSCH HSPA HSUPA HSS HTB HTML HTTP HTTPS IANA ICMP ICMPv6 IE IEEE IETF IK IMEI IMS GTP rst stage GTP second stage, rst version for EPS GTP-C version 2 GTP-U version 1 Graphic User Interface Home Agent Home Agent Address Home Address Hybrid ARQ Home Location Register Home Network Prex Home Public Land Mobile Network High-Speed Downlink Packet-Data Access High Speed Downlink Shared channel High Speed Packet Access High-Speed Uplink Packet-Data Access Home Subscriber Server Hierarchical Token Bucket HyperText Markup Language HyperText Transfer Protocol HyperText Transfer Protocol Secured Internet Assigned Numbers Authority Internet Control Message Protocol Internet Control Message Protocol version 6 (ICMP pour IPv6) Information Element Institute of Electrical and Electronics Engineers Internet Engineering Task Force Integrity-Key International Mobile Equipment Identity IP Multimedia Subsystem

xxiv IMSI IMT-2000 IntServ IP IP-CAN IPDV IPPM IPSec IPv4 IPv6 IR ISDN ITU LAN LARIM LBI LDPC LLC LLQ LMA LMAA LQC LTE MAC MAG MBR MCC ME MEI MIMO International MS Identity International Mobile Telecommunications 2000 Integrated services Internet Protocol IP Connectivity Access Network IP Packet Delay Variation IP Performance Metrics Working Group Internet Protocol Security IP version 4 IP version 6 Incremental Redundancy Integrated Services Digital Network International Telecommunication Union Local Area Network Laboratoire de Recherche en Informatique Mobile Linked EPS Bearer ID Low-Density Parity-Check Logical Link Control Low Latency Queueing Local Mobility Anchor Local Mobility Anchor Address Link Quality Control Long Term Evolution Medium Access Control Mobile Access Gateway Maximum BitRate Mobile Country Code Mobile Equipment ME Identity Multiple Input Multiple Output

xxv MIP MIPv4 MIPv6 MME MN MNC MPLS MS MSC MSISDN MT NAI NAP NAS NSAPI NSP NS-2 NS-3 OFDM OFDMA OMC OSI OTcl PAA PAPR PBA PBU PCC PCEF PCRF Mobile IP Mobile IPv4 Mobile IPv6 Mobility Management Entity Mobile Node Mobile Network Code Multiprotocol Label Switching Mobile Subscriber Mobile Switching Center MS ISDN Number Mobile Terminal Network Access Identier Network Access Provider Non-Access Stratum Network layer Service Access Point Identier Network Service Provider Network Simulator version 2 Network Simulator version 3 Orthogonal Frequency-Division Multiplexing Orthogonal Frequency-Division Multiple Access Operations and Maintenance Center Open Systems Interconnection Object Tool Command Language PDN Address Allocation Peak-Average-Power Ratio Proxy Binding Acknowledgement Proxy Binding Update Policy and Charging Control Policy and Charging Enforcement Function Policy and Charging Rules Function

xxvi PDCP PDN PDP PDU PFu PFi PFID PGW PHB PLMN PMIPv6 PPP PQ PRO PS PSK PSTN PTI P2P QAM QCI QoS QPSK RADIUS RAI RAN RAT RED RFC RLC Packet Data Convergence Protocol Packet Data Network Packet Data Protocol Protocol data unit Policy Function Packet Filter Packet Filter Identier Packet Data Network Gateway Per-Hop Behavior Public Land Mobile Network Proxy Mobile IPv6 Point to Point Protocol Priority Queueing Procedure Packet Switched Phase-Shift Keying Public Switched Telephone Network Procedure Transaction Id Peer-to-Peer Quadrature Amplitude Modulation QoS Class Identier Quality of Service Quadrature PSK Remote Authentication Dial-In User Service Routing Area Identity Radio Access Network Radio Access Type Random Early Detection Request for Comments Radio Link Control

xxvii RNC RR RRC RTP SAE SAI SASN SC-FDMA SCTP SDU SF SFI SFQ SGSN SGW SIM SMS SNDCP SOFDMA SPI srTCM SSH STN S1-AP TA TAI TAD TBF Tcl TCP Radio Network Controller Round-Robin Radio Resource Control Real Time Protocol System Architecture Evolution Service Area Identier Service Aware Support Node Single-carrier FDMA Stream Control Transmission Protocol Service Data Unit Service Flow Service Flow Identier Stochastic Fairness Queueing Serving GPRS Support Node Serving Gateway Subscriber Identity Module Short Message Service Sub Network Dependent Convergence Protocol Scalable OFDMA Security Parameters Index single-rate, three-color marker Secure Shell Session Transfer Number S1 Application Protocol Timing Advance Tracking Area Identity Trac Aggregate Description Token Bucket Filter Tool Command Language Transmission Control Protocol

xxviii TD-CDMA TDD TDMA TEID TFT TID ToS trTCM TSN UCI UDP UE UE-AMBR ULA ULI ULR UMTS USIM UTRA-FDD UTRAN UTRA-TDD VoIP VLR VoD VPLMN WBBRR W-CDMA WFQ WiMAX WLAN Time Division CDMA Time Division Duplex Time Division Multiple Access Tunnel Endpoint Identier Trac Flow Template Tunnel Identier Type of Service two-rate, three-color marker Transmission Sequence Numbers User CSG Information User Datagram Protocol User Equipment UE Aggregated Maximum BitRate Update-Location-Answer User Location Information Update-Location-Request Universal Mobile Telecommunications System Universal subscriber identity module UMTS Terrestrial Radio Access - Frequency Division Duplexing UMTS Terrestrial Radio Access Network UMTS Terrestrial Radio Access - Time Division Duplexing Voice over IP Visitors Location Register Video on Demand Visited Public Land Mobile Network Weighted bit-by-bit Round-Robin Wideband Code Division Multiple Access Weighted Fair Queueing Worldwide Interoperability for Microwave Access Wireless Local Area Network

xxix WRED WRR XMPP 3GPP 4G Weighted Random Early Detection Weighted Round-Robin Extensible Messaging and Presence Protocol Third generation partnership project quatrime gnration

xxx LISTE DES ANNEXES

Annexe A Annexe B Annexe C Annexe D Annexe E Annexe F Annexe G Annexe H Annexe I

Diagrammes de squences de larchitecture 23.401 . . . . . . . . . . . Diagrammes de squences de larchitecture 23.402 . . . . . . . . . . . Diagrammes de squences de larchitecture 403 . . . . . . . . . . . . Diagrammes de squences de larchitecture 404 . . . . . . . . . . . . Rsultats des simulations avec un seul UE . . . . . . . . . . . . . . . Rsultats des simulations avec mille UE . . . . . . . . . . . . . . . . Tailles des messages GTP . . . . . . . . . . . . . . . . . . . . . . . . Tailles des messages Diameter . . . . . . . . . . . . . . . . . . . . . . Exemple dapplication de QoS sous GNU/Linux . . . . . . . . . . . .

115 133 147 161 175 179 185 196 216

1 CHAPITRE 1 INTRODUCTION

Les rseaux cellulaires sont classs par gnration et actuellement ceux de deuxime et troisime gnrations sont les plus courants. Avec la croissance dInternet, le besoin dorir des services habituellement rservs aux rseaux laires comme le streaming audio ou vido ou le web browsing, augmente. Les rseaux 3G ont t dvelopps dans le but daugmenter la capacit de transmission des donnes et ainsi amliorer le confort des usagers utilisant des services multimdia. Cependant, la capacit des rseaux mobiles est encore limite par rapport celle des accs traditionnels laires. Leurs dveloppement est donc toujours trs actif et la 4e gnration est actuellement en prparation. Nous avons tudi les architectures des rseaux 4G proposes par le consortium 3GPP et cherch les amliorer. Dans ce chapitre nous allons dnir quelques concepts de base, puis nous prsenterons notre problmatique et nos objectifs de recherche. Nous nirons en dtaillant le plan de ce mmoire. 1.1 Dnitions et concepts de base

Avec le dveloppement important qua connue ces derrires annes linformatique mobile et le march des tlphones cellulaires, de plus en plus de services sont oerts sur ces plateformes. Les rseaux mobiles ont d voluer pour permettre le transport dautres types de tracs que celui de voix. Aujourdhui les rseaux 3G sont adapts la transmission de voix et de donnes (e.g. web, FTP, Extensible Messaging and Presence Protocol (XMPP)), mais ceux-ci restent spars, cela implique une gestion plus complexe des rseaux. Dans la nouvelle gnration de rseau mobile, la 4G, il est prvu de considrer tout le trac, y compris la voix, comme du trac de donnes et de le faire passer sur un mme rseau commutation de paquets. Dans la 4G il ny a donc plus de rseaux commutation de circuits. Pour acheminer le trac, les protocoles IPv4 (dni par Postel [88]) et/ou IPv6 (dni par Deering et Hinden [56]) sont utiliss, cependant ils ne spcient pas de systme de priorisation des types de tracs. IPv4 contient un champ Type of Service (ToS) renomm Trac Class en IPv6, et maintenant divis en dierentiated services codepoint (DSCP) et Explicit Congestion Notication (ECN) respectivement dni par Nichols et al. [80] et Ramakrishnan et al. [91]. Ces champs indiquent la politique de QoS qui devrait tre applique aux paquets, mais pas

2 la manire de lappliquer, si bien quaujourdhui la majorit des applications et des routeurs ne les traitent pas. Ce problme nest pas trs important tant que le rseau reste assez rapide pour quaucune congestion ne survienne. Mais les rseaux mobiles sont trs limits en terme de bande passante par rapport aux rseaux cbls classiques. Les dirents types de tracs nont pas les mmes exigences en matire de bande passante, taux de perte de paquets, dlai, IP Packet Delay Variation (IPDV), etc. La vido non interactive peut supporter un dlai entre le serveur et le rcepteur assez important sans que lutilisateur ne soit gn ; en revanche, ce trac est trs sensible aux pertes de paquets. Une perte, ne serait-ce que de 0,5 % des paquets peut se traduire par une dgradation importante de la qualit de limage [76]. Le trac de voix est sensible au dlai, mais peut supporter un taux de perte de paquets plus important (jusqu 1 % selon Wallingford [100, chap. 9]). Un transfert de document ne require pas de fortes contraintes sur le dlai, mais une bande passante leve est prfrable. Les mcanismes qui permettent de traiter diremment les paquets suivant leur contenu sont appeles techniques de QoS. Dans les rseaux mobiles 4G, pour orir une qualit de service comparable celle de la tlphonie traditionnelle en plus de permettre laccs aux rseaux de donnes (communment appel Internet), le consortium dindustriels 3GPP propose dutiliser un systme de bearer. Les bearers sont des tunnels ayant chacun leurs paramtres de QoS [63, 73]. Le document 23.401 [8] propose une architecture utilisant des bearers GTP (protocole dvelopp par 3GPP). GTP se divise en deux branches, GTP-U et GTP Control (GTP-C) ; GTP-U est destin encapsuler les paquets IP [24], il gre les fonctions associes aux bearers (dbit maximum, priorit, etc.). GTP-C est destin envoyer des donnes de contrle relatives aux bearers [22] (cration, destruction, modication), il est notamment utilis pour grer la mobilit des usagers. Les rseaux mobiles 4G ont aussi t prvus pour supporter plusieurs types de rseaux daccs, tels que evolved UMTS Terrestrial Radio Access Network (EUTRAN) ou Worldwide Interoperability for Microwave Access (WiMAX). Il est politiquement dicile de faire accepter un oprateur de connecter son rseau daccs WiMAX un rseau utilisant GTP tant donn que ce protocole appartient au consortium 3GPP (ce nest pas un standard Internet Engineering Task Force (IETF)), qui comme mentionn plus haut est un consortium dindustriels. Il a donc t dcid de proposer une nouvelle architecture utilisant les protocoles Generic Routing Encapsulation (GRE) [64] et PMIPv6 [65] sur la partie partage du rseau, cette architecture est dcrite dans le document 23.402 [9]. GRE est un protocole dencapsulation, il ne gre pas la signalisation et le trac de contrle comme GTP ; le protocole Diameter

3 [48, 74] est utilis lorsquil sagit de transfrer ce genre dinformations. Le protocole PMIPv6 permet de grer la mobilit des usagers. Larchitecture basique dun rseau PMIPv6 se compose dunits mobiles, de plusieurs MAG et dun LMA. Les usagers se dplacent dun MAG lautre sans quils puissent le dtecter, tout leur trac transite via le LMA. Les paquets sont donc encapsuls entre le MAG courant et le LMA, respectivement le Serving Gateway (SGW) et le Packet Data Network Gateway (PGW) dans larchitecture 23.402 [9]. Il nexiste quun seul tunnel entre un MAG et un LMA pour tous les usagers connects au MAG. tant donn que larchitecture 23.402 [9] nutilise plus GTP entre le SGW et le PGW, 3GPP considre quil ny a plus de bearer entre eux. Cependant, chaque bearer GTP a t remplac par un tunnel GRE, nous considrons donc les tunnels GRE comme des bearers pour plus de simplicit. GRE possde un champ Key de quatre octets permettant de remplacer le champ Tunnel Endpoint Identier (TEID) dont GTP se sert pour direntier les bearers. Les deux architectures proposes dans les documents 23.401 [8] et 23.402 [9] sont schmatises la gure 1.1.

(a) Architecture propose dans 23.401 [8]

(b) Architecture propose dans 23.402 [9]

Figure 1.1 Architecture propose par 3GPP Hui et al. [70] proposent de modier PMIPv6 pour permettre la cration de plusieurs tunnels entre le MAG et le LMA. Ils utilisent, comme 3GPP dans larchitecture 23.402 [9], le protocole GRE pour direntier les tunnels. Le but de cette modication est de permettre la direntiation de tracs et donc de faciliter lapplication de politiques (e.g. de QoS) diffrentes. Nous pouvons remarquer une similitude avec le modle GTP, dailleurs Hui et al. [70] proposent dutiliser les Trac Flow Template (TFT) utiliss par 3GPP dans le protocole GTP (un TFT permet didentier une session, une connexion).

4 1.2 lments de la problmatique

La premire architecture dveloppe par le consortium 3GPP est dcrite dans le document 23.401 [8] cependant, du fait de la prsence de GTP entre le SGW et le PGW, le consortium fut contraint de dvelopper une nouvelle architecture dveloppe dans le document 23.402 [9]. Ces changements ayant t dcids en majorit sur la base de critres politiques. Du fait des capacits limites des rseaux mobiles, la maitrise des ressources alloues chaque usager et chaque type de trac est trs importante. Les smartphones sont de plus en plus courants et sont maintenant capables de grer un grand nombre dapplications et de types de tracs. La vido est aussi apparue sur les plateformes mobiles et suscite de plus en plus dintrt. Ces nouveaux facteurs accentuent le besoin dutiliser les ressources du rseau de la manire la plus ecace possible de faon maximiser les performances. Dans ce contexte nous pouvons nous demander si les changements apports larchitecture 23.401 [8] dans 23.402 [9] ont aect les performances du rseau du point de vue de lusager. Un des objectifs du passage la quatrime gnration de rseau mobile est lutilisation du protocole IP pour tous les types de trac et lutilisation dun rseau unique. Cependant, le protocole IP nest que peu utilis dans larchitecture 23.401 [8] qui utilise GTP. Dans larchitecture 23.402 [9], par rapport 23.401 [8], entre le SGW et le PGW GTP a t remplac par PMIPv6 et GRE. Le protocole PMIPv6 a toutefois t modi de faon ce que le MAG (en loccurrence le SGW) nait aucun lien avec la couche IP du Mobile Node (MN) (ou UE). Le routeur par dfaut du MN est le PGW qui est le LMA de larchitecture PMIPv6 ce qui est contraire ce qui est dcrit dans son Request for Comments (RFC) [65, sec. 3]. De plus le protocole GRE nest pas gr par la couche IP ou PMIPv6 comme on pourrait le croire aprs la lecture de Muhanna et al. [78]. Nous pouvons nous demander sil est possible dutiliser les caractristiques de IPv6 de faon plus avance et si cela a un impact sur les performances ressenties par lutilisateur. Hui et al. [70] proposent une extension PMIPv6 pour permettre lutilisation de plusieurs tunnels entre un MAG et un LMA. Chaque tunnel encapsulant le trac dun seul service pour un terminal, de cette faon il est possible dappliquer des techniques de QoS au tunnel et ainsi prioriser ce quil transporte. Cette volution permettrait de transfrer la gestion des bearers au niveau IP, au protocole PMIPv6. GRE nest utilis dans larchitecture 23.402 [9] que pour remplacer le champ TEID permettant de direntier les bearers dans GTP. Dans len-tte du protocole IPv6 il existe un champ appel ow label de 20 bits dont lutilisation nest pas encore dnie. Un RFC [41] est dailleurs en cours de rdaction pour tenter den prciser les utilisations. Nous pouvons nous demander sil est possible dutiliser ce champ en remplacement de

5 GRE. Et si cela est possible, quels impacts auraient cette modication sur les performances du rseau ressenties par lusager. 1.3 Objectifs de recherche

Lobjectif principal de ce mmoire est dvaluer et comparer les performances des architectures 23.401 [8] et 23.402 [9] proposes par le consortium 3GPP. Nous allons aussi proposer et valuer des changements apporter ces architectures pour essayer dutiliser au mieux les caractristiques du protocole IPv6 et limiter lutilisation de GTP et GRE. Lvaluation des direntes architectures se fera sur la base des performances du rseau au niveau du terminal. Dune manire plus spcique nous visons les objectifs suivants : valuer les performances de larchitecture 23.402 [9] par rapport 23.401 [8], et ce du point de vue des terminaux, cest--dire que seules les performances constates sur les paquets circulant sur le plan de donnes nous intressent ; proposer et valuer un moyen de coner la gestion des bearers entre le SGW et le PGW au protocole PMIPv6 dans larchitecture 23.402 [9] ; proposer et valuer un moyen de saranchir de GTP-U au prot de PMIPv6 ; crer des simulateurs capables dvaluer des mtriques de performance pour les architectures 23.401 [8], 23.402 [9] et pour les architectures modies que nous proposons. 1.4 Plan du mmoire Suite lintroduction, ce mmoire se poursuit avec le chapitre 2 dressant un historique non exhaustif des technologies utilises dans les rseaux mobiles. Au chapitre 3, nous exposons nos propositions de modication des architectures EPC de 3GPP aprs quoi nous dvoilons et comparons les performances obtenues avec et sans modication. Le chapitre 4 dcrit les simulateurs et outils utiliss pour obtenir les rsultats. Enn, la conclusion synthtise le travail de recherche eectu lors de cette matrise en faisant ressortir les principales contributions apportes ; nous y abordons aussi les possibles recherches futures susceptibles de dcouler de ce travail.

6 CHAPITRE 2 ANALYSE DES RSEAUX MOBILES

Avant de pouvoir exposer nos propositions nous pensons quil est prfrable de dcrire les direntes technologies employes par les rseaux mobiles. Nous allons donc tout dabord les passer en revue ; nous nous attarderons sur les rseaux cellulaires en dtaillant leur volution de la premire la dernire gnration (la 4G). Nous introduirons direntes techniques permettant de grer la mobilit au niveau IP, en premier lieu sur IPv4 ce qui nous permettra ensuite dexpliquer plus facilement celles utilisant IPv6. Pour nir nous expliquerons le fonctionnement de larchitecture de QoS DiServ. 2.1 Dnitions et concepts de base Les rseaux dits mobiles sont des rseaux dont les terminaux sont amens se dplacer. Il existe plusieurs types de ces rseaux, les plus connus tant les Wireless Local Area Network (WLAN) (e.g. les rseaux Wi-Fi), et les rseaux cellulaires. Les rseaux cellulaires sont gnralement classis en plusieurs gnrations dcrivant leur niveau de technicit et leur apparition chronologique. Wi-Fi : Les rseaux Wi-Fi sont des rseaux WLAN respectant les spcications de la norme 802.11legacy dveloppe par lorganisme Institute of Electrical and Electronics Engineers (IEEE). Il existe plusieurs amendements cette norme dont les plus connus sont 802.11a, b, g et n. Chacun de ces amendements dnit un sous-type de Wi-Fi. Lacronyme Wi-Fi dsigne aussi un ensemble de protocoles utiliss dans ce type de rseau. Cellulaire : Les rseaux cellulaires courants sont appels Public Land Mobile Network (PLMN), chacun de ces rseaux est mondialement identi par un Mobile Country Code (MCC) et un Mobile Network Code (MNC). Ils sont gnralement connects au PSTN pour permettre leurs usagers de communiquer avec les autres PLMN et dappeler des numros xes. Parfois ces rseaux sont aussi connects Internet, notamment dans les dernires gnrations de rseaux cellulaires ( partir de la 2,5G). Il existe une multitude dalgorithmes, de normes et de protocoles concernant les rseaux cellulaires. Nous allons dcrire les plus connus par ordre dappartenance aux direntes gnrations.

7 2.1.1 Advanced Mobile Phone System

La technologie Advanced Mobile Phone System (AMPS) fait partie de la famille des rseaux cellulaires 1G. chaque communication est alloue une bande de frquences (principe Frequency Division Multiple Access (FDMA)) ce qui permet de facturer le client en fonction de la dure dappel. La voix est transmise de manire analogique sur le canal radio ce qui rend la communication trs sensible au bruit, mais aussi susceptible dtre intercepte et espionne. 2.1.2 Global System for Mobile communications

Les rseaux Global System for Mobile communications (GSM) appartiennent aux rseaux cellulaires 2G, lacronyme GSM dsigne aussi un codec de compression de signal audio utilis justement dans ces rseaux. Cette norme utilise le principe de la commutation de circuit i.e. un chemin physique est rserv par chaque connexion/communication, cest la mthode la plus ancienne utilise pour les communications rseau. Larchitecture du PLMN GSM est schmatise la gure 2.1, elle est relie au PSTN et contient plusieurs types de nuds dcrits par Eberspcher et al. [61] et Pierre [86] : Base Transceiver Station est une antenne rseau monte sur une station de base, elle est en liaison physique avec le Mobile Terminal (MT). Base Station Controller est un contrleur de Base Transceiver Station (BTS), il gre la bande passante, les ressources radio et contrle la procdure de relve entre deux BTS. Mobile Switching Center est charg daiguiller les tracs de donnes et de contrle aux dirents nuds et fonctions du rseau. Il gre la localisation des MT en coordination avec le Visitors Location Register (VLR), laiguillage des appels (commutation de circuit), la scurit en coordination avec le Authentication Center (AuC) et la mobilit des MT (gestion des relves ). Home Location Register est une base de donnes contenant toutes les informations relatives aux MT appartenant au PLMN de loprateur ; par exemple : la zone (correspondant un VLR) courante o se trouve le MT. Elle est unique dans le PLMN. Visitors Location Register est une base de donnes contenant les informations relatives au MT se trouvant dans la zone quil dessert avec son Mobile Switching Center (MSC). Elle contient entre autre la BTS sur laquelle se trouve le MT. Authentication Center est une base de donnes contenant les informations de scurit des MT du PLMN. Equipment Identity Register est une base de donnes contenant une liste de tous les International Mobile Equipment Identity (IMEI) des MT enregistrs sur le PLMN.

Figure 2.1 Architecture simplie dun PLMN GSM Le rseau daccs GSM utilise la fois les techniques Time Division Multiple Access (TDMA) et FDMA, il spare le trac downlink du uplink par Frequency Division Duplexing (FDD) comme dcrit par Eberspcher et al. [61]. La bande de frquences utilise initialement est celle des 900 MHz soit 890 915 MHz pour le trac uplink et 935 960 pour le dowlink, cette bande ft ensuite tendue de 10 MHz soit 880 915 et 925 960. Il existe aujourdhui une dizaine de types de GSM allant du GSM-380 au GSM-1900, le deuxime nombre correspondant la bande de frquences. Pour partager un mme canal frquentiel entre plusieurs usagers la technique TDMA alloue des time-slots chaque usager sur la frquence voulue. Une trame TDMA contient 8 time-slots et les frquences de transmission et de rception dun terminal peuvent changer chaque time-slot. La BTS doit aussi mesurer et informer le MT du temps de propagation des trames appeles Timing Advance (TA) ; cette valeur doit tre comprise entre 0 et 63 symboles, ce qui correspond une dure limitant le rayon des cellules GSM 35 km. D aux contraintes du terrain, certaines zones ne sont pas couvertes par toutes les frquences. Pour les terminaux faible vitesse, les zones de coupure peuvent dpasser les 20 ms, ce qui correspond au temps de transmission dun bloc de donnes GPRS. Quels que soient le dcalage et les bits alatoires ajouts, toutes les donnes seront perdues. Pour remdier ce problme, le terminal change souvent de frquence de transmission et de rception. Un terminal GSM peut tre dans deux tats dirents, le mode ddi est le mode du terminal durant les appels ou lorsquil y a change dinformation avec le rseau. Le terminal

9 entre dans le mode idle lorsquil na plus besoin daucune ressource ddie (aucun change avec le rseau), dans ce mode il continue cependant recevoir des notications des BTS et peut dcider deectuer une relve. Dans le mode idle le rseau sait dans quelle zone se trouve le terminal, mais ignore sur quel BTS il est attach. En revanche, dans le mode ddi, tant donn quil y a change de donnes, le rseau est oblig de connatre prcisment la position du mobile. On peut remarquer que malgr sa popularit GSM est une technologie vieillissante amene disparaitre dans les prochaines annes. En dcembre 2009 Karsten Nohl dchira et dvoila le code source utilis par les tlphones GSM ; puis Chris Paget expliqua, lors de la Defcon de juillet 2010, une mthode de fabrication faible cot (1500 $) dun espion/intercepteur de communication GSM. 2.1.3 General Packet Radio Services

Le rseau GSM ore la possibilit dinitier ou de recevoir des appels tlphoniques comme avec un tlphone xe ; il ore aussi la possibilit denvoyer des Short Message Service (SMS) (originellement prvu pour envoyer des messages de service). Nanmoins, il est assez limit face la demande croissante de technologies lies au rseau Internet (e.g. mail, web), cest pourquoi lEuropean Telecommunications Standards Institute (ETSI) standardisa une extension au rseau appele GPRS schmatise la gure 2.2 (cette extension est maintenant standardise par le consortium 3GPP). Elle est dcrite et correspond la version 97 des spcications de GSM. Elle permet de supporter la transmission de donnes par paquet (commutation de paquets), notamment le protocole IP et ainsi la connexion du mobile Internet. Les couches de protocoles utilises sont reprsentes la gures 2.3 et 2.4. La couche Radio Link Control (RLC) possde une fonctionnalit Automatic Repeat reQuest (ARQ) de transmission able . On peut remarquer que la couche Logical Link Control (LLC) permet dorir une scurit de transmission importante aux couches suprieures, cependant RLC ore dj des fonctionnalits ARQ et les applications ncessitant des canaux ables utilisent le protocole de transport Transmission Control Protocol (TCP). Comme il est expliqu par Brand et Aghvami [47] LLC nest pas ncessaire et a t supprime des volutions de GPRS notamment Universal Mobile Telecommunications System (UMTS). GPRS est couramment considre comme faisant partie des rseaux cellulaires 2,5G. Sa premire version (spcication GSM version 97) permet datteindre des dbits thoriques de 40 Kbps en downlink et 14 Kbps en uplink [35]. Les versions ultrieures (version 98 et 99) orent quant elles, un dbit thorique maximal de 171 Kbps [35] (valu en pratique

10

GMSC E MSC/VLR A BSS Um MT Gn Gp Gs Gb SGSN D Gr Gn Ga Gf Gd C HLR Gc GGSN Ga CGF Gi PDN

SGSN

GGSN

EIR

(a) coupl avec un rseau GSM [4]

(b) architecture logique

Figure 2.2 Architecture des rseaux GPRS

Application IP SNDCP LLC RLC MAC couche physique GPRS UE Um RLC MAC couche physique GPRS BTS / BSC BSSGP Network Service L1 Gb SNDCP LLC BSSGP Network Service L1 SGSN GTP UDP IP L2 L1 Un IP GTP UDP IP L2 L1 GGSN Ui

Figure 2.3 Couches de protocoles du plan de donnes dans le rseau GPRS (inspire de Brand et Aghvami [47])

11

GMM/SM LLC RLC MAC couche physique GPRS UE Um RLC MAC couche physique GPRS BTS / BSC BSSGP Network Service L1 Gb

GMM/SM LLC BSSGP Network Service L1 BTS / BSC

Figure 2.4 Couches de protocoles du plan de contrle dans le rseau GPRS (inspire de Brand et Aghvami [47]) 60 Kbps [47]). Les modications les plus notables sont (voir gure 2.2b) : lajout du Serving GPRS Support Node (SGSN) ; lquivalent commutation de paquets du MSC. Il enregistre la position des terminaux et assure des fonctions de scurit et dauthentication. lajout du Gateway GPRS Support Node (GGSN) ; lquivalent commutation de paquets du Gateway MSC (GMSC). Il est linterface entre le rseau mobile GPRS et dautre Packet Data Network (PDN). lvolution du Home Location Register (HLR) pour supporter les informations ncessaires au rseau GPRS ; lvolution logicielle des Base Station Controller (BSC) [44] pour supporter linterface Gb ; lvolution matrielle et logicielle des BTS [44] pour supporter les nouveaux canaux physiques. La technologie GPRS malgr son dbit assez faible au regard des connexions Internet actuelles fut dploye dans de nombreux rseaux. En eet un de ses grands avantages est dutiliser une partie de larchitecture GSM, dont le rseau daccs, ce qui diminue grandement son cot de dploiement pour les oprateurs disposant dj de ce rseau. Pour la gestion de la mobilit, les tats que peut prendre le terminal sont grs indpendamment des tats GSM [47]. Il en existe trois : idle le rseau ne connait absolument pas la position du terminal. standby le rseau connait la position du terminal en terme de routing area. Cest lquivalent GPRS de ltat idle de GSM. ready le rseau connait exactement la position du terminal.

12 Le rseau GPRS ntant pas prvu pour fournir des services temps rel, il na pas t jug intressant dimplmenter un mcanisme de soft-handover. Le handover se fait donc par dconnexion/reconnexion et peut entraner des pertes de paquets. Les tats cits plus haut ne concernent que la gestion de la mobilit, il en existe dautres types comme par exemple Packet Data Protocol (PDP) inactivate et activate. Un contexte PDP dnit une connexion au rseau, une session dun usager. Il est reprsent par une structure de donnes prsente sur le Mobile Subscriber (MS), le SGSN et le GGSN. Il contient par exemple le International MS Identity (IMSI) du MS et le Network layer Service Access Point Identier (NSAPI) qui tous deux forment un Tunnel Identier (TID) (aussi appel TEID), il peut aussi inclure ladresse du MS, son type (e.g. IP, Point to Point Protocol (PPP)), et le prol de QoS utilise [1]. Dans les premires versions de GPRS (version 97 et 98 des spcications GSM) un seul contexte PDP peut tre activ par adresse de MS [1, sec. 9.1][6, sec. 9.1.2.1] ; un MS peut cependant possder plusieurs contextes PDP non activs. Certains MS peuvent supporter plusieurs connexions simultanes (ils possdent plusieurs adresses) ce qui leur permet davoir plusieurs contextes PDP activs simultanment [89]. Du fait de lapparition de nombreux nouveaux services relatifs la commutation de paquets et de la raret de la bande passante, il a t ncessaire dintroduire une notion de QoS au rseau. Les informations dnissant la QoS utiliser par le MS sont contenues dans les contextes PDP, cependant un seul de ces contextes peut tre actif sur un MS un instant donn. Une direntiation est donc eectue entre les tracs des usagers, mais pas entre les types de tracs dun mme MS. Dans les nouvelles versions de GPRS un TFT a t ajout au contexte PDP ce qui permet de direntier plusieurs contexte PDP ayant la mme adresse de MS. Il est alors possible de dnir un contexte PDP par service et non plus par connexion au rseau, chaque contexte contenant la politique de QoS appliquer au service en question. Plusieurs contextes PDP peuvent alors tre activs simultanment sur un MS, ce qui permet de faire de la QoS par service et non plus par usager. GPRS Core Network Le rseau cur du rseau GPRS est principalement compos du SGSN et du GGSN, ces deux nuds sont des GPRS support node (GSN). GGSN Comme dcrit plus haut, il est lquivalent du GMSC du rseau GSM, il peut aussi tre vu comme lquivalent du Home Agent (HA) de larchitecture Mobile IP (MIP). Il assure la mobilit des usagers dans le sens o il connait le SGSN sur lequel se trouve actuellement le MS et aiguille les paquets en consquence. Il attribue et distribue les

13 adresses des MS, authentie les usagers et comptabilise leur trac. Il applique aussi les paramtres (e.g. de QoS) spcis par les contextes PDP actifs. SGSN Il aiguille les paquets et gre une partie de la mobilit en enregistrant le MSC courant des usagers. Comme le GGSN, il authentie les usagers et comptabilise leur trac. Ces deux nuds encapsulent et dcapsulent les paquets qui transitent entre eux en utilisant le protocole GTP. Ce protocole gre aussi la mobilit des MS. Il utilise lui-mme le protocole de transport User Datagram Protocol (UDP). Il existe plusieurs types de GTP (pour plus de dtails, voir la section 3.1.1) : GTP-C transporte certaines donnes sur le plan de contrle. GTP-U encapsule les paquets sur le plan de donnes. Des Boarder Gateway (BG) peuvent tre installs dans les rseaux curs GPRS pour permettre linterconnexion entre dirents PLMN. Entre ces PLMN, le protocole GTP est utilis [44] ; aussi des accords sont gnralement passs entre les oprateurs concernant la traduction des paramtres des contextes PDP, notamment pour les paramtres des QoS. Le rseau cur de GPRS dni dans les spcications 97 de GSM est aussi utilis (avec quelques amliorations) avec les rseaux daccs UMTS Terrestrial Radio Access Network (UTRAN) et Enhanced Data rates for GSM Evolution (EDGE). 2.1.4 Enhanced Data rates for GSM Evolution

Les rseaux GSM/GPRS ont eux-mmes volu grce la technologie EDGE permettant daugmenter considrablement les dbits disponibles, cette volution est couramment considre comme appartenant aux rseaux mobiles 2,75G [47, 35]. EDGE aussi appel Enhanced GPRS (EGPRS), est dcrit dans la version 99 des spcications GSM (reprisent depuis par le consortium 3GPP). Cest une alternative aux couteux rseaux 3G bass sur UMTS qui ncessitent une mise niveau de toute larchitecture du rseau. Les technologies GPRS et EDGE peuvent partager les mmes spectres de frquence, les oprateurs nont donc pas se procurer de nouvelles licences pour migrer vers ce systme comme cest le cas avec la technologie UMTS (dont le prix des licences atteint jusqu cinq milliards deuros en France). EDGE introduit lutilisation dun nouveau type de modulation en plus de Gaussian Minimum Shift Keying (GMSK) utilis dans GPRS, le 8 Phase-Shift Keying (PSK). Grce ce type de modulation, un terminal EDGE est capable datteindre un dbit thorique de 384 Kbps (171 Kbps pour GPRS) [47, 35], ce dbit restant infrieur ce quil est possible datteindre en UMTS. Dans la nouvelle version EDGE Evolution, ce dbit est pass 1,3 Mbps en downlink et 653 Kbps en uplink ; le dlai est aussi pass sous la barre des 100 ms [35].

14 Cependant, du fait du support de cette nouvelle modulation les tlphones GPRS ne sont pas compatibles avec EDGE et les BTS doivent subir une mise jour, larchitecture du rseau restant la mme. Un autre apport de EDGE est la cration de nouveaux Link Quality Control (LQC) combinant ladaptation des liens utiliss dans GPRS avec une technique dIncremental Redundancy (IR), inclut dans la mthode de retransmission Hybrid ARQ (HARQ) de type deux. Le problme du choix du schma de codage est important, en eet si on choisit un schma trop scuritaire, de la bande passante sera gaspille du fait de la forte redondance. Si on choisit un schma de codage non scuritaire on maximise la bande passante, mais si une trame est perdue alors le dlai et la bande passante se dtriorent. Lide de la technique IR de type 2 est de conserver les trames errones et de ne retransmettre que les parties de cette trame utiles la reconstruction de la squence correcte. Ainsi beaucoup de bande passante est sauvegarde. Si la bande passante tait la seule valeur maximiser, la technique adopter consisterait toujours commencer la transmission dune trame en utilisant le schma de codage le moins scuritaire. Si une erreur se produit, le systme retransmet les informations errones ainsi que les donnes suivantes, mais en utilisant un schma de codage plus scuritaire. Le systme recommence ces tapes jusqu ce que les donnes soient correctement transmises. Cependant, cette mthode engendre un dlai trs important tant donn que la transmission commence toujours avec le schma de codage le moins rsistant, les retransmissions peuvent donc tre trs nombreuses avant quune trame soit correctement transmise. La mthode utilise par EDGE utilise le principe nonc au paragraphe prcdent, mais nutilise pas le schma de codage le plus sensible aux pertes pour commencer. En se basant sur le nombre de retransmission des trames prcdentes, soit la qualit actuelle du lien, le rseau choisit le niveau de redondance (le schma de codage) utilis pour la premire transmission [47]. 2.1.5 Universal Mobile Telecommunications System

Le rseau UMTS (reprsent gure 2.5) est une volution du rseau GPRS, il appartient au rseau cellulaire 3G, cest un standard dvelopp par le consortium 3GPP dans les documents 23.101 [5] et [37]. Il suit les spcications International Mobile Telecommunications 2000 (IMT-2000) de lInternational Telecommunication Union (ITU) dans le sens o il utilise le standard radio Wideband Code Division Multiple Access (W-CDMA). Il existe cependant de nombreux types dUMTS et tous nutilisent pas W-CDMA. Dans ce nouveau rseau, les anciens BSC sont remplacs par des Radio Network Controller (RNC) et les BTS par des NodeB. Une des volutions notables apporte par les NodeB est

15 le support de plusieurs cellules radio par une seule entit physique. UTRAN est le rseau daccs utilis, il en existe deux types : UMTS Terrestrial Radio Access - Frequency Division Duplexing (UTRA-FDD) et UMTS Terrestrial Radio Access - Time Division Duplexing (UTRA-TDD). UTRA-FDD utilise le standard W-CDMA se servant de la technique Direct Sequence CDMA (DS-CDMA). Ce type de rseau daccs fait passer les informations ascendantes sur une frquence dirente de celles descendantes (principe du FDD) et permet lutilisation dune mme frquence par plusieurs usagers grce lutilisation de codes de codages dirents (principe du Code Division Multiple Access (CDMA)). UTRA-TDD utilise le standard Time Division CDMA (TD-CDMA), qui utilise le principe Time Division Duplex (TDD) pour sparer le trac ascendant du trac descendant. Le fait de permettre lutilisation des techniques FDD et TDD induit un contrle plus n des bandes de frquences allouer. Par exemple, si loprateur ne dispose que de trs courtes bandes de frquences, il prfrera surement utiliser la technique TDD qui vite de trop les diviser.
PSTN GMSC C AuC H HLR E D F MSC/VLR G/E MSC/VLR IuCs A BSC Abis BTS Abis BTS NodeB Uu ME UTRAN Iubis Gs Gb IuPS RNC Iubis NodeB Iur RNC EIR Gr Gt SGSN Gn Gc GGSN Gi PDN

Figure 2.5 Architecture logique du rseau UMTS (inspire de 3GPP [37]) Le standard W-CDMA a volu et une extension appele High Speed Packet Access (HSPA) est apparue, elle vise surtout augmenter la capacit du rseau daccs. Elle se compose de deux modules High-Speed Downlink Packet-Data Access (HSDPA) et High-Speed

16 Uplink Packet-Data Access (HSUPA) (ou Enhanced Uplink (EUL)) amliorant respectivement les performances en downlink et uplink. Avec W-CDMA simple, le dbit downlink peut atteindre environ 400 Kbps, tandis quavec HSDPA celui-ci peut atteindre 7,2 Mbps (voir 14 Mbps avec un terminal adapt). HSPA+ est une autre volution introduisant notamment la technologie Multiple Input Multiple Output (MIMO) et pouvant atteindre 42 Mbps en downlink et 11 Mbps en uplink. On peut remarquer que HSDPA peut tre install sans que HSUPA soit prsent, on peut donc avoir un systme semi-HSPA . Le module HSDPA introduit un nouveau canal logique nomm High Speed Downlink Shared channel (HS-DSCH) ayant la particularit dtre partag entre tous les terminaux dune mme cellule. Ainsi la bande passante est mieux rpartie ; celle non utilise par un terminal nest pas perdue puisquelle peut tre utilise par les autres. Il est prfrable davoir un canal avec beaucoup de dbit partag entre plusieurs usagers plutt que plusieurs petits canaux attribus un un chaque terminal. Ce partage de canal nest pas eectu de faon triviale comme avec une le First In First Out (FIFO) par exemple, mais utilise une mthode de scheduling trame par trame base sur la qualit de rception des UE. Pour chaque nouvelle trame, chaque UE envoie un rapport sur la qualit de sa rception (appel Channel-Quality Indicator (CQI)), le NodeB dcide alors lequel dentre eux recevra cette trame et quelle quantit de donnes y stocker [54]. Le dlai est aussi amlior grce lutilisation dune mthode HARQ base sur les NodeB et non le RNC comme cest le cas pour EDGE. Le module HSUPA apporte approximativement les mmes modications en uplink : scheduling, HARQ, etc. Partager le canal downlink est ais tant donn que tous les paquets passent par le NodeB avant dtre envoys par ondes radio. Le NodeB peut facilement choisir sur quel UE envoyer des donnes. En revanche, cela est plus dlicat en uplink tant donn que plusieurs UE peuvent envoyer des informations en mme temps sans passer par un point central. La solution utilise dans HSUPA est de placer le scheduler dans le NodeB, cela implique que les UE envoient rgulirement un rapport sur ltat de leurs buers et notient le NodeB lorsquils veulent envoyer de nouvelles donnes. Contrairement HSDPA, o un seul UE la fois est adress par le NodeB, plusieurs UE peuvent envoyer des donnes en mme temps, ce qui peut provoquer des interfrences. Le scheduling eectu par le NodeB permet de sassurer que les signaux sont toujours dcodables, que les interfrences ne sont pas trop fortes. Bien que les nouveaux canaux uplink se comportent comme des canaux partags du fait du scheduling, ils sont en fait ddis ; cest le taux dinterfrence au NodeB qui est partag par les UE [54]. Deux nouveaux types de relve sont introduits [47] : softer handover dsigne le passage dune cellule une autre gr par le mme NodeB. Le UE est alors connect par plusieurs canaux parallles, chacun allou une cellule

17 spcique. Ce handover na pas dimpact sur larchitecture UTRAN tant donn quil ny a pas de changement de NodeB. soft handover dsigne le passage dune cellule une autre gr par des NodeB dirents. Le UE est alors connect deux NodeB en mme temps ce qui implique la prsence du lien Iur (cf. gure 2.5) pour les synchroniser (dans le cas o elles nappartiennent pas au mme RNC). Les terminaux ne sont plus appels MT mais UE, ils contiennent dsormais un module didentication Universal subscriber identity module (USIM) volution du Subscriber Identity Module (SIM) utilis dans GSM. Pour augmenter les performances du rseau radio, les couches LLC et Sub Network Dependent Convergence Protocol (SNDCP) sont remplaces par une couche Packet Data Convergence Protocol (PDCP), charge entre autre de compresser les en-ttes IP. Comme les rseaux GPRS et EDGE, UMTS dispose de mthodes de QoS (gure 2.6). Cependant, les prcdents rseaux ntaient pas prvus pour supporter des tracs temps rel, ils ne possdaient que des mthodes de gestion de QoS assez basiques [47]. Dans UMTS, la QoS est gre indpendamment pour chaque service grce un systme de bearer. Un bearer est un tunnel par lequel passent les donnes du ou des services pour lequel il a t construit, chaque bearer possdant sa propre QoS. UMTS dispose de plusieurs couches relatives au bearer comme le montre la gure 2.7. Pour lutilisateur, le service de QoS apparait comme tant de bout en bout. Un des buts du systme sa cration tait dtre intelligible et simple congurer, de ce fait seul quatre classes de QoS ont t dnies, le tableau 2.1 donne leurs caractristiques. Chaque classe possde des attributs comme le dbit maximum, le dbit garanti, la priorit dallocation et de rtention (voir 23.107 [6] pour plus de dtails). Tableau 2.1 Caractristiques des classes de QoS utilises en UMTS Classes Caractristiques exemples dapplication conversation peu de gigue peu de dlai voix streaming peu de gigue streaming vido interactive peu de dlai peu de derreur web best eort peu de perte mail, download

Les trois principaux protocoles utiliss dans le rseau UTRAN sont : Radio Resource Control (RRC), RLC et Medium Access Control (MAC) (voir gure 2.6). Le protocole RRC gre le plan de contrle du rseau daccs et notamment les procdures de connexion, les mesures de qualit du lien radio, les bearers, les procdures de scurit et les dcisions de

18

plan Contrle

plan Donne

RRC Contrle

bearers radio

L3

signalisation des bearers radio RLC canaux logiques MAC

PDCP

BMC

Contrle

L2

canaux de transports physique L1

Figure 2.6 Protocoles radio UTRAN (inspire de Brand et Aghvami [47])

bearer UMTS

bearer RAN

Core Network bearer

bearer radio

bearer daccs RAN

backbone bearer

Figure 2.7 Architecture de bearer utilise dans UMTS (inspire de 23.107 [6])

19 handover. Le protocole MAC gre lenvoi des donnes sur la couche physique en tenant compte des paramtres que lui fourni le protocole RRC, il gre notamment le scheduling des donnes. Le protocole RLC ore trois types de transfert aux couches suprieures [47] : transparent Les donnes sont envoyes sans ajout den-tte relative au protocole RLC. Aucune modication nest eectue sur les donnes, il est cependant possible dutiliser la fonctionnalit de segmentation/r-assemblage. Les donnes ne sont pas garanties darriver destination, il est aussi possible que des erreurs soient prsentes dans les paquets remonts aux couches suprieures. unacknoledged Les donnes ne sont pas garanties darriver destination, mais celles qui arrivent sont garanties dtre exemptes derreur. acknoledge Les donnes sont garanties darriver destination, sans erreur. 2.1.6 Worldwide Interoperability for Microwave Access

WiMAX est un protocole de communication sans l donnant son nom au rseau daccs lutilisant, il fait partie des standards de lIMT-2000. Comme le Wi-Fi il a t dvelopp par lorganisme IEEE. Il dsigne tous les rseaux respectant la norme 802.16. lheure actuelle, par ordre chronologique, nous connaissons 802.16a, 802.16d, e et m. La premire version rellement utilise est la 802.16d, mais cette version ne supporte pas la mobilit. La version suivante possde cette fonctionnalit, cest pourquoi nous nous y intressons dans notre tude. Pour supporter la mobilit entre plusieurs Access Service Network (ASN) le rseau se base sur la technologie IP et utilise Mobile IPv4 (MIPv4) (en mode proxy ou simple) ou MIPv6 [87, 103]. Avant que la technologie Long Term Evolution (LTE) narrive maturit WiMAX tait vu comme le futur des rseaux mobiles. Dsormais LTE a pris lavantage dans le domaine des technologies 4G. En eet, bien qu lheure actuelle les deux technologies aient des performances comparables, LTE a lavantage dtre un descendant direct des rseaux 3G courants. Certaines parties de larchitecture des anciens rseaux peuvent donc tre rutilises ou mises jours. WiMAX quant lui possde une architecture (reprsente gure 2.8) et utilise des mthodes direntes de ce qui se fait dans les rseaux 3G. Actuellement la technologie WiMAX (802.16e) permet dobtenir au maximum 144 Mbps en downlink et 35 Mbps en uplink. La prochaine version (802.16m) prvoit de supporter jusqu 1 Gbps en downlink. Le passage la version 802.16e a apport de nombreuses amliorations la norme, comme : la gestion des soft et hard handover (ncessaire au support de la mobilit) ; lutilisation de mthode HARQ ; le support de technologie MIMO ;

20
NAP Visited NSP Home NSP

BS R1 MS BS

ASN ASN-GW R3 proxy AAA R4 HA

R2

R2

CSN PFu R5

Home AAA

CSN PFu

BS

ASN ASN-GW

R3 autre ASP ou internet autre ASP ou internet

BS contrle et donnes donnes

Figure 2.8 Architecture logique du rseau WiMAX (inspire de WiMAX Forum R [102]) un meilleur systme de QoS ; lutilisation de la mthode de protection contre les erreurs de transmission Low-Density Parity-Check (LDPC) ; lutilisation de Scalable OFDMA (SOFDMA) (ce qui rend cette version incompatible avec la 802.16d). On remarque certaines similitudes avec HSPA comme lutilisation de mthode HARQ ou de MIMO, ils utilisent aussi tous deux les modulations Quadrature PSK (QPSK) 16-Quadrature Amplitude Modulation (QAM) et 64-QAM. En revanche, leurs techniques de transmission radio sont direntes ; HSPA utilise une mthode base sur CDMA tandis que WiMAX utilise SOFDMA (driv de Orthogonal Frequency-Division Multiplexing (OFDM)). OFDM est une technique qui consiste allouer chaque utilisateur un grand nombre de sous canaux de frquence espacs de faon tre orthogonaux. Grce cette mthode lutilisation spectrale du canal est bien meilleure quavec une Frequency Division Multiplexing (FDM) classique. Orthogonal Frequency-Division Multiple Access (OFDMA) utilise aussi la division temporelle pour sparer les donnes des terminaux, comme dans HSPA la modulation des canaux est adapte dynamiquement en fonction de la qualit du lien observ. 2.1.7 Long Term Evolution

La technologie LTE, inclus dans le rseau EPS reprsent la gure 2.9 est une volution du rseau daccs 3G UMTS. Elle a t dveloppe et standardise par le consortium 3GPP,

21 sa premire version est parue en dcembre 2008 [36]. Bien que certains industriels aient dclar que LTE se trouve dans la catgorie des rseaux 4G, il ne satisfait pas entirement aux spcications de lETSI ; il est donc plus juste de parler de 3,9G ou presque 4G.
S12 UTRAN SGSN S3 GERAN MME S1-MME UE LTE-Uu EUTRAN S6a HSS S11 S1-U SGW S5/S8 PCRF Gx PGW Rx SGi IP Services S4

Figure 2.9 Architecture simplie du rseau EPS (inspire de 23.401 [8]) Le terme LTE dsigne la technologie radio utilise dans le rseau daccs EUTRAN, celuici est prvu pour tre attach au rseau cur EPC dvelopp par le groupe de travail System Architecture Evolution (SAE). Le rseau au complet (EUTRAN plus EPC) est appel EPS. Une nouvelle version de LTE appele LTE advance correspondant la version 10 des spcications est en cours de dveloppement 1 . Cette version appartiendra rellement la catgorie 4G et sera totalement compatible avec la technologie LTE actuelle. Les performances couramment attribues au rseau LTE sont de 100 Mbps minimum en downlink et 50 Mbps minimum en uplink (avec un terminal de catgorie 3) avec un dlai daller-retour de moins de 10 ms (minimum de 1 ms) [36, 77]. Ces paramtres correspondent au but que stait x le projet son lancement, soit multiplier par trois ou quatre le dbit en downlink et par trois le dbit uplink compar HSPA. La taille des cellules a elle aussi augment, pouvant aller jusqu 100 Km en zone rurale [77] ; bien quil soit possible de maximiser le dbit en utilisant de hautes frquences (jusqu 2,4 GHz). Chaque cellule pouvant supporter au minium jusqu 200 UE. Le projet LTE, en plus de stre focalis sur le passage la 4G, a cherch simplier larchitecture du rseau mobile, aussi bien au niveau du rseau daccs que du rseau cur. En eet, le rseau daccs nomm EUTRAN ne contient plus quun seul nud, le Evolved Node B (eNodeB) et trois interfaces : S1-MME, S1-U et X2 qui est optionnel. S1-U et S1MME peuvent tre combines en une seule interface S1 reliant le rseau daccs EUTRAN au rseau cur EPC. Linterface X2 relie deux eNodeB entre eux et est optionnelle. Il est donc possible de ramener le rseau daccs un seul nud reli au EPC par une seule interface 2 .
1. Certains documents sont dj disponibles, mais ils sont encore susceptibles de changer. 2. Un eNodeB peut tre connect plusieurs Mobility Management Entity (MME).

22 Le EPC contient beaucoup de fonctionnalits pouvant tre regroupes en plusieurs nuds physiques. Larchitecture complte dun rseau EPS est reprsente la gure 2.10. Le Service Aware Support Node (SASN) nest pas un nud dcrit par 3GPP, cest un produit dvelopp par Ericsson pour prendre en charge une partie des fonctions Policy and Charging Enforcement Function (PCEF) et Assured Forwarding (AF) ; nous lavons reprsent car il est prsent dans nos simulateurs (ayant t dvelopp en partenariat avec Ericsson). Le EPC est compatible avec de nombreuses technologies daccs en plus de EUTRAN. Les anciennes installations des rseaux GSM, EDGE, et UMTS peuvent tre rattaches au rseau EPC et la mobilit des usagers entre ces technologies est supporte. Les rseaux WiMAX peuvent aussi sattacher au EPC. Cependant, WiMAX est un standard de lIEEE et il est politiquement dicile de faire transiter le trac issu de ce rseau dans un tunnel utilisant le protocole GTP qui nest pas un standard de lIETF et qui est dvelopp par le consortium 3GPP. Cest pourquoi le document 23.402 [9] prvoit de remplacer le protocole GTP par PMIPv6 et GRE entre les nuds SGW et PGW.

Figure 2.10 Schma gnral du rseau EPS La partie basique du EPC est compose de cinq nuds (quatre selon certaines sources) : PGW Il connecte le rseau EPC avec le rseau extrieur appel PDN. Il gre la mobilit des UE dans le sens o il agit comme le LMA dun rseau PMIPv6, il authentie et autorise les UE se connecter en leur associant une adresse. Il se charge aussi de leur crer des bearers conformes avec leurs contrats et la politique du rseau (dont le Policy and Charging Rules Function (PCRF) a la charge). tant le point de liaison entre le PLMN et le PDN le PGW fait aussi la correspondance entre les QoS utiliss dans ces rseaux. Il applique les politiques de QoS des bearers comme les Maximum BitRate (MBR), les APN-AMBR, les Guaranteed BitRate (GBR), etc. Dans la norme 23.402 [9] il nexiste plus de rel bearer entre le SGW et le PGW dans le sens o GTP a t remplac par PMIPv6 et GRE. Le PGW ne gre donc plus la cration de bearers, cependant il possde toujours les TFT ncessaires pour ltrer et router les tracs dans les bearers. En eet il est toujours charg dappliquer les politiques de QoS des bearers, chaque tunnel GRE correspondant un bearer (voir gure 3.8). Le PGW est aussi

23 charg de comptabiliser le trac des UE 3 en vue de leurs facturations [73]. SGW Il est en bordure du rseau daccs, il route les paquets downlink vers le eNodeB courant du UE. Il gre la mobilit des UE dans le sens o il peut tre vu comme le MAG du systme PMIPv6 [73]. Dans la norme 23.401 [8] il gre la correspondance entre les bearers GTP SGW-PGW et eNodeB-SGW. Dans la norme 23.402 [9] on considre quil contient les TFT des bearers, car ceux-ci nexistent plus sur linterface S5/S8. Cependant, tant donn quil a un tunnel GRE par bearer, ses TFT ne sont en fait que des correspondances dtiquettes. Le SGW gre aussi linterfaage du EPC avec les rseaux daccs ; en eet la technologie EUTRAN nest pas la seule pouvoir se connecter au EPC. Il peut tre li plusieurs PGW pour permettre aux UE dtre connects simultanment dirents PDN. Dans le cas o le UE est en mode idle le SGW peut tre amen mettre en cache les paquets downlink lui tant destins, le temps pour le MME de rveiller le UE et de construire les bearers radio. MME Il incorpore certaines parties du SGSN nayant pas t places dans le SGW. Il y a un MME par SGW. Il gre toutes les fonctions du plan de contrle (il nest dailleurs pas sur le plan de donnes) relatives aux UE (via la couche Non-Access Stratum (NAS) dont il est le nud terminal) et aux bearers [73]. Il authentie les UE sur le rseau et le rseau auprs deux (procdure Authentication and Key Agreement (AKA)), en plus de grer le cryptage des communications. Il route les demandes de cration de bearer provenant du PGW ou du UE et gre la ngociation de leur QoS associe. Lorsque le UE est en tat idle et quune requte lui est destine, cest au MME dindiquer au SGW o se trouve le UE ; il gre donc la mobilit du UE [73]. Il est aussi responsable du choix du SGW la connexion des UE ou lors de handover entre deux eNodeB ncessitant un changement de rseaux cur (changement de SGW ou PGW). Le MME est li au Home Subscriber Server (HSS) pour pouvoir authentier les UE et enregistrer leurs tats et leurs localisations, il est aussi charg dallouer aux UE un identiant temporaire lors de leur connexion. Il gre au niveau du plan de contrle la mobilit entre les dirents rseaux daccs possibles. HSS Cest une base de donnes stockant les informations sur les sessions des UE, comme la QoS laquelle ils ont souscrit. Le HSS fait aussi partie des nuds grant la mobilit du UE dans le sens o il enregistre leur localisation pour le MME ou dautres nuds de technologie dirente comme le SGSN [81]. PCRF Il gre la QoS et les politiques de facturation sur le EPS. Il se trouve sur le plan de contrle et ne fait donc que notier les autres nuds des dcisions quil prend. Selon
3. Un UE peut tre connect plusieurs PGW la fois.

24 Olsson et al. [81] il ne fait pas partie du EPC, contrairement Lescuyer et Lucidarme [73] qui le mentionnent dans leur liste. Dans les rseaux UMTS et ses prdcesseurs, une grande partie de la gestion du rseau daccs (adaptation des canaux, gestion de la QoS, etc.) seectue dans le RNC (3G) ou le BSC (2G). Comme nous lavons dit, le rseau EUTRAN ne comporte quun seul nud, le eNodeB ce qui le rapproche plus des rseaux WLAN comme Wi-Fi et WiMAX [73]. En plus de simplier larchitecture, cela permet damliorer les capacits du rseau, notamment le dlai. Les retransmissions de paquets perdus et les paquets de contrle nont plus se rendre jusquau RNC ou BSC ; ils sont directement traits par le eNodeB [73]. Comme le NodeB de UTRAN, le eNodeB de EUTRAN est capable de grer plusieurs cellules logiques. Il gre entirement le lien radio [73] : modulation, dmodulation : il utilise, comme HSDPA et WiMAX, les modulations QPSK, 16QAM et 64QAM ; codage, dcodage ; contrle des ressources : cration, modication ou destruction de bearer (dirig par le MME), allocation de nouveaux canaux, etc. gestion de la mobilit radio : dcision de lancer une procdure de handover et choix de son type : utilisant linterface X2, ou S1 ; compression et chirement des en-ttes IP sur linterface radio ; gestion de la dtection et correction derreur de transfert au niveau de la couche 2 du modle Open Systems Interconnection (OSI) ; slection du MME du UE au moment de sa connexion. Linterface X2 entre deux eNodeB est optionnelle et ne sert que lors des handovers, elle permet de diminuer le taux de perte de paquets et le dlai. Lors dun handover utilisant linterface S1 les paquets de lancien eNodeB doivent tre re-routs vers le nouveau eNodeB via le SGW. Ce passage par linterface S1 se trouvant dans le chemin de nombreuses autres communications oblige le SGW a crer des tunnels temporaires de redirection [8]. En plus de prendre plus de ressources sur le rseau, cela empche le SGW de librer rapidement les ressources alloues entre lui et lancien eNodeB. Grce linterface X2, le trac arrivant lancien eNodeB est re-rout directement vers le nouveau eNodeB. Il ny a pas de rservation de ressource supplmentaire entre lancien eNodeB et le SGW. Linterface X2 servant exclusivement au handover les risques de congestion sont trs faibles et donc les chances de perdre un paquet sont moins importantes quen utilisant S1. Une grande volution apporte par le rseau LTE est labandon complet de la mthode de commutation de circuits utilise dans les rseaux GSM pour acheminer la voix. Absolument toutes les donnes passent par le rseau EPC utilisant la commutation de paquets. Ce choix

25 dutiliser la Voice over IP (VoIP) simplie encore larchitecture du rseau mobile et sa gestion, mais apporte aussi des contraintes. Transfrer de la voix sur IP est aujourdhui trs courant, mais la qualit observe peut tre trs variable suivant la charge que subit le rseau. Les rseaux mobiles servant principalement orir un service de tlphonie il serait mal vu que celui-ci ne soit pas de bonne qualit. Le rseau LTE utilise donc des techniques de QoS permettant de direntier les services et notamment la VoIP de manire prioriser au maximum ses paquets et viter une dgradation des communications tlphoniques. Comme dans les rseaux UMTS chaque service peut possder un bearer [62], cependant plusieurs services ou connexion peuvent emprunter le mme bearer, un bearer peut ne pas tre allou un et un seul service [29]. Dans LTE il existe plusieurs types de bearer : Dfaut Chaque UE sa connexion cre son unique bearer par dfaut, celui-ci est toujours prsent, mme quand le UE est en mode idle. Tous les tracs provenant ou allant au UE et qui nappartiennent aucun autre bearer passent par celui-ci. Ddi Ils sont crs, modis ou dtruits la demande du UE ou du rseau. Ils sont gnralement rservs un service en particulier, mais rien nempche un oprateur de rgler les TFT des UE pour que plusieurs connexions, plusieurs types de trac ou plusieurs services passent par un mme bearer. Il existe deux sous-types de bearer ddi : non-GBR Leur dbit est limit par les Aggregate Maximum Bit Rate (AMBR) (voir ci-dessous). GBR Ils possdent des paramtres de QoS supplmentaires (voir ci-dessous) et leurs bandes passantes nest pas limites par les AMBR. Dans le rseau EPC, la bande passante est divise en deux ou en trois suivant la juridiction du pays. Aux tats-Unis par exemple, il est interdit de couper une communication tlphonique en cours, mais il est obligatoire de pouvoir faire des appels de dtresse (mme quant le rseau est congestionn). Les oprateurs sont donc obligs de conserver une partie de la bande passante libre pour les appels durgence ventuels. Dans dautres pays, il est autoris de couper une communication en cas durgence, toute la bande passante peut donc tre exploite. Lors dun appel durgence, les services de faibles priorits sont alors susceptibles dtre coups. Une partie de la bande passante est rserve aux bearers GBR. Si cette portion est totalement utilise, il est impossible de crer de nouveaux bearers GBR, mme si aucun bearer non-GBR nest cr. Chaque bearer ddi possde les paramtres de QoS suivants : Allocation and Retention Priority (ARP) Il dsigne la priorit du bearer par rapport aux autres, au moment de sa cration, ou de la cration dun autre. Par exemple, les

26 services durgence possdent un bearer avec ARP trs lev, ils leur sont donc possible de se crer mme quand le rseau est congestionn, voire de couper dautres bearers ayant un ARP plus faible. QoS Class Identier (QCI) Il dnit toutes les contraintes de QoS (except en terme de dbit) que doit respecter le bearer. Neuf QCI, reprsents dans le tableau 2.2, sont standardiss mais les oprateurs ont la possibilit de crer leurs propres QCI. Cependant, il est conseill dutiliser en priorit celles prdnies, car elles sont valides chez tous les oprateurs et peuvent tre traites sur tous les rseaux sans ncessit de roaming agrement. Les bearers ddis GBR possdent en plus les paramtres suivants : GBR Correspond au dbit rserv pour le bearer, cette bande passante lui est garantie, cest une limite basse. MBR Correspond au dbit maximum autoris du bearer, elle nest pas garantie, cest une limite haute. Actuellement (dans la version 9 des spcications 3GPP) il est toujours gal au GBR, mais les futures versions prvoient dautoriser lutilisation de valeurs direntes. Les bearers non GBR partagent deux paramtres de QoS appartenant au UE [8] : UE AMBR Ce paramtre nest utilis que dans le eNodeB, il permet de limiter la bande passante global dun UE. La bande passante de tous les bearers non GBR (bearer par dfaut inclus) doit tre infrieur cette valeur. Les bearers GBR ne sont pas concerns par cette restriction. Access Point Name (APN) AMBR Un UE peut tre connect plusieurs PDN, ou sous-rseaux (subdivision sur un mme PDN). Chacun de ces accs se fait sur un APN qui dsigne de faon unique un rseau. Grce ce paramtre, il est possible de limiter la bande passante dun UE sur un APN spcique, il nest utile qu lentre de chaque APN et donc sur le PGW. Un UE peut donc possder plusieurs APN AMBR. Par exemple il peut tre connect sur les APN Internet et rseau de lentreprise , lintranet de sa compagnie tant surdimensionn son APN AMBR est trs lev. Sur lAPN Internet le UE se verra attribu un APN AMBR correspondant au prix du contrat quil a souscrit avec son oprateur. Les bearers peuvent tre crs par le rseau ou par le UE. Rendre le UE incapable de demander la cration dun bearer (UE QoS unaware ) ore lavantage de rendre les terminaux plus simples. Par exemple lorsque le terminal veut lancer un appel tlphonique il communique les informations ncessaires (personne joindre) au AF pour que celui-ci le mette en

27 Tableau 2.2 QCI standardis du rseau LTE (inspir de Olsson et al. [81]) QCI 1 2 3 4 5 6 7 8 9 Non GBR Type de bearer GBR Priorit 2 4 3 5 1 6 7 8 9 dlai maximum 100 ms 150 ms 50 ms 300 ms 100 ms 300 ms 100 ms 300 ms 300 ms taux de perte de paquets maximum 102 103 103 106 106 106 103 106 106 Exemple de service VoIP vido bidirectionnel (conversationnel) jeu en temps rel vido en streaming de type VoD, non conversationnel signalisation IMS streaming vido bas sur TCP (HTML 5), web voix et vido en streaming temps rel (live ), jeu interactif streaming vido bas sur TCP (HTML 5), web

communication VoIP avec linterlocuteur. Le AF a donc conscience de la cration dun nouveau service sur le rseau, il peut donc informer le PCRF qui va lancer une procdure de cration de bearer ddi pour la VoIP. Une autre possibilit est dutiliser la technique du Deep Packet Inspection (DPI) sur le plan de donnes pour analyser en temps rel les types de tracs relatifs chaque UE. Cest ce que fait le SASN de Ericsson. Par exemple si un nouveau trac vido est dtect, le PCRF est contact et de la mme manire que pour le AF, un nouveau bearer est cr. Il est aussi possible de combiner les techniques, rendre le UE QoS aware pour certains services et laisser le rseau grer les autres. Dans les normes de LTE il nest pas spci comment le rseau doit procder pour respecter le QCI des bearers. Le choix de la technique de QoS utilise (DiServ, Integrated services (IntServ) avec ou sans Multiprotocol Label Switching (MPLS), etc.) est laiss au choix de loprateur. Interface Radio Linterface Radio, comme cest le cas en UMTS, peut utiliser les techniques de duplexage FDD et TDD ce qui permet de tirer parti de nombreuses plages de frquence, mme trs restreintes. Comme WiMAX, elle utilise des techniques de duplexage bases sur OFDM : Singlecarrier FDMA (SC-FDMA) aussi appele DFT-spread OFDM (DFTS-OFDM) en uplink et

28 OFDM en downlink. La technique SC-FDMA permet de rsoudre un problme li OFDM appel Peak-Average-Power Ratio (PAPR). En downlink les eNodeB sont assez puissants pour contrer ce problme et viter son apparition, en revanche en uplink les UE ont des capacits limites en terme de Central Processing Unit (CPU) et de batterie (voir Lescuyer et Lucidarme [73] pour plus de dtails). LTE supporte MIMO en uplink et downlink ce qui lui permet de multiplier par quatre lecacit spectrale et par dix le nombre dusagers par cellule, compar aux premires versions dUMTS [36]. 2.2 Mobilit IP

Dans les rseaux IP, certaines extensions au protocole permettent de grer directement la mobilit des usagers. 2.2.1 Mobile IPv4

MIPv4 est le plus vieux (2002 [85]) des protocoles de gestion de mobilit que nous allons dcrire. Son architecture se compose des nuds suivants : MN Il se dplace sur le rseau et doit explicitement supporter le protocole MIPv4. Correspondent Node (CN) Il est xe ou mobile et communique avec le MN. Il ne supporte pas forcment MIPv4. HA Cest le point dencrage du MN sur le rseau source. Foreign Agent (FA) Cest un intermdiaire appartenant au rseau visit. Ce nud est optionnel si le MN est capable de supporter la technique co-located Care of Address (CoA). Initialement le MN dcouvre son HA grce au message Internet Control Message Protocol (ICMP) Agent Advertisement dius par celui-ci, sollicit ou non par un message ICMP Agent Solicitation envoy par le MN. Le MN lance alors une procdure denregistrement et dauthentication avec le HA aux termes desquelles il recevra son adresse permanente appele Home Address (HoA). Le HA cre une entre pour le MN dans sa table de correspondance entre les HoA et les CoA (une correspondance tant appele mobility binding ). Le CoA du MN est son adresse temporaire lors de ses dplacements, pour linstant (dans le rseau home ) elle est gale au HoA. Lorsque le MN se dplace il dtecte le changement de rseau, soit de faon autonome, soit en recevant un des messages ICMP Router Advertisement dius par le FA. Il senregistre et sauthentie alors auprs de lui et reoit une adresse temporaire, la CoA (gnralement

29 dtermine grce au Router Advertisement reut). Le MN envoie une requte de mise jour de mobility binding appele Binding Update (BU). Le HA enregistre la CoA du MN, ds lors tous les paquets arrivants sur le HA destination de ladresse HoA sont encapsuls dans un tunnel destination du CoA [85]. Dans le cas normal, cest--dire lorsque le CoA du MN est ladresse du FA et que la mthode de routage triangulaire est utilise, lorsque le tunnel est tabli, les donnes du MN destines au CN sont achemines jusquau FA par un protocole de routage autre que IP (gnralement un protocole de niveau deux tout simplement). Le FA les envoie sur le rseau, ces paquets ayant pour IP source le HoA et pour destination ladresse du CN, ils sont aiguills vers le CN. Les donnes du CN destines au MN sont routes vers le HA tant donn que pour le CN ladresse IP du MN est son HoA. Le HA les encapsule dans un tunnel destination du FA qui les dcapsule et les envoie au MN (toujours sans utiliser le protocole IP entre FA et MN). La gure 2.11a schmatise ces changes. Le fait que le FA envoie directement les donnes du MN vers le CN peut poser problme. Le HoA nappartient pas au rseau du FA, il se peut donc quun rewall rejette les paquets du MN sortant du FA en direction du MN. Pour pallier ce problme, il est possible dutiliser la technique de lencapsulation retour (reverse tunneling ) qui consiste encapsuler les donnes provenant du MN sur le FA jusquaux HA. Cette technique est schmatise la gure 2.11b. Il est aussi possible pour le MN de se passer du nud FA en utilisant un co-located CoA ; les utilisations de cette technique sont schmatises la gure 2.12. Cette mthode a cependant le dsavantage de ncessiter deux adresses publics IPv4 pour chaque MN, le HoA et le CoA ; les adresses IPv4 se font de plus en plus rares (lInternet Assigned Numbers Authority (IANA) devrait cesser de distribuer ses adresses IPv4 dbut 2011 [101, sec. 1]). 2.2.2 Mobile IPv6

Le protocole IPv6 possde lui aussi une extension (ou protocole part entire) appele MIPv6 permettant de grer la mobilit. Ici nous ne nous intresserons pas la scurit du protocole largement dtaille par Johnson et al. [72], Patel et al. [83] et Devarapalli et Dupont [59], mais plutt aux quelques dirences avec MIPv4. Larchitecture MIPv6 est semblable celle de MIPv4, mais ne comporte pas de FA. La pnurie dadresses problmatiques pour la technique co-located CoA de MIPv4 ne touche pas le protocole IPv6 (qui a dailleurs t conu dans le but de pallier cette pnurie). MIPv6 utilise par dfaut le lencapsulation bidirectionnelle (bidirectional tunneling ) quivalent du reverse tunneling de MIPv4 [72]. Cette mthode ne ncessite pas le support de MIPv6 par le CN. Au niveau de larchitecture et de lchange de donnes, elle ressemble la mthode dencapsulation retour avec co-located

30

CN src : CN dst : HoA HA

src : HoA dst : CN

src : CN dst : HoA routage niveau 2 FA MN src : HoA dst : CN routage niveau 2

src : CN dst : HoA src : HAA dst : CoA

(a) routage triangulaire

CN src : HoA dst : CN HA src : HoA dst : CN src : CoA dst : HAA src : CN dst : HoA src : CN dst : HoA src : HAA dst : CoA FA src : HoA dst : CN routage niveau 2

src : CN dst : HoA routage niveau 2 MN

(b) encapsulation retour

Figure 2.11 Communication MIPv4 avec FA CoA

CN src : CN dst : HoA HA

src : HoA dst : CN

src : HoA dst : CN

CN src : CN dst : HoA HA

src : CN dst : HoA src : HAA dst : CoA MN

MN src : CN dst : HoA src : HAA dst : MN

src : HoA dst : CN src : CoA dst : HAA

(a) routage triangulaire

(b) encapsulation retour

Figure 2.12 Communication MIPv4 avec co-located CoA

31 CoA de MIPv4 schmatise la gure 2.12b. Si le CN supporte le protocole MIPv6, une mthode doptimisation du routage (route optimization ) peut tre utilise. Elle permet damliorer la distance parcourue par les paquets de donnes, mais aussi de limiter les risques de congestion du niveau du HA [72]. Dans ce cas, mme si le HA est toujours contact lors des procdures de scurit ou pour mettre jour les mobility binding, le trac de donnes ne transite plus par lui. Un BU est envoy par le MN au CN pour linformer dun ventuel dplacement et le CN conserve lui-mme une table de mobility binding. Les donnes du MN destination du CN sont envoyes avec ladresse source CoA, le CN rpond en utilisant le CoA comme adresse de destination, mais fournit aussi le HoA dans un nouveau type den-tte (type 2 routing header ). La gure 2.13 schmatise cet change.
CN src : CoA dst : CN MN src : CN dst : CoA type 2 : HoA HA

Figure 2.13 Communication MIPv6 avec optimisation de routage

2.2.3

Proxy Mobile IPv6

Le protocole PMIPv6 utilise les avantages du protocole IPv6 pour apporter la mobilit aux usagers. Contrairement MIPv6 qui se base sur les terminaux pour grer leur mobilit [72], PMIPv6 se base entirement sur le rseau, les usagers doivent simplement possder une pile IPv6 normale [65]. Il est aussi possible dutiliser PMIPv6 avec certaines parties du rseau en IPv4, mais nous ne nous intresserons pas cette proprit ici. PMIPv6 reprend une grande partie du protocole MIPv6 et introduit un nouveau nud appel MAG grant la mobilit la place du MN. Les messages utiliss dans MIPv6 comme le BU, renomm Proxy Binding Update (PBU), et le Binding Acknowledgement (BA), renomm Proxy Binding Acknowledgement (PBA), sont rutiliss avec quelques options en plus. Le LMA de MIPv6 est rutilis et agrment de quelques fonctions ce qui permet de grer sur un mme rseau les MN supportant MIPv6 et ceux qui ne le supportent pas. Le nouveau nud MAG a les rles suivants [65] : Il est responsable de la dtection de dplacement du MN ; Il gre la communication sur le plan de contrle avec le LMA ; Il fait croire au MN quil est dans son rseau dorigine en lui envoyant des router advertisement contenant son/ses Home Network Prex (HNP) ;

32 Il route et encapsule les paquets du MN vers son LMA, et inversement, il dcapsule les paquets provenant du LMA et les route vers les MN. Lorsquun MN se connecte au domaine PMIPv6, le MAG le dtecte ; il peut par exemple intercepter un message Internet Control Message Protocol version 6 (ICMPv6) Router Solicitation envoy par le MN (mais ce nest pas optimal). La mthode de dtection du MN nest pas spcie par Gundavelli et al. [65]. Au lieu denvoyer tout de suite un message Router Advertisment au MN, comme le ferait un routeur IPv6 normal, le MAG informe le LMA du MN de cette connexion. Il interroge donc une base de donnes locale ou distante contenant le Policy Prole du MN ; tous les MAG et les LMA doivent avoir accs cette base de donnes ou en avoir une copie locale. Ce Policy Prole contient au minimum lidentiant du MN et son LMA. Il envoie alors ce LMA un message PBU contenant le ag P introduit par PMIPv6 (ce ag a pour but dindiquer au LMA que cette connexion utilise le protocole PMIPv6 plutt que MIPv6), lidentiant du MN et quelques options utiles comme le Hando Indicator (voir section 4.3.6). Le LMA met jour sa table de correspondance appele Binding Cache. Celle-ci contient toutes les informations ncessaires au maintien des sessions de mobilit des MN. Les informations spciques PMIPv6 sont [65] : un ag indiquant que le MN utilise PMIPv6 ; lidentiant du MN ; lidentiant de couche liaison OSI du MN, cet identiant doit tre constant tout au long de la session. Il peut tre gal zro si la technologie daccs ne peut pas fournir didentiant. ladresse IPv6 link local que doivent utiliser les MAG pour communiquer avec le MN. Ce nest pas ladresse du MN mais ladresse source que les MAG doivent adopter pour faire croire au MN quil est toujours dans le mme rseau (cf. paragraphe 2.2.3). la liste des HNP du MN, ils peuvent tre congurs de faon statique dans le Policy Prole ou tre gnrs dynamiquement par le LMA la connexion de celui-ci ; linterface que le LMA doit utiliser pour correspondre avec le MAG, et donc le tunnel dans lequel les paquets destins au MN doivent tre encapsuls ; la technologie daccs actuellement utilise par le MN ; la date denvoi du dernier PBU reu si celui-ci contenait loption Timestamp ou la date de rception sil ne la contenait pas. Cette valeur permet au LMA de traiter les PBU dans leur ordre chronologique (un vieux PBU arrivant sur le LMA est tout simplement rejet). Aprs avoir vri lidentit et les droits du MN, accept le PBU et cr son Binding Cache Entry (BCE) (mise jour du Binding Cache du MN) le LMA envoie un message

33 PBA au MAG pour lui indiquer quil peut continuer la squence dattachement. Si le tunnel bidirectionnel entre le LMA et le MAG nexiste pas, alors celui-ci est cr. Ces tunnels peuvent tre crs dynamiquement la connexion des MN ou tre congurs de faon statique la mise en place du domaine PMIPv6. Il ne peut en exister quun par couple LMA-MAG, aussi les donnes de tous les MN connects un MAG empruntent le mme. Leurs point daccs sont les Proxy-CoA et les Local Mobility Anchor Address (LMAA). Lorsque le MAG reoit le PBA il cre sa partie du tunnel et met jour ses tables de routage pour faire en sorte que les donnes du MN y transitent. Il envoie aussi au MN ses HNP via un message Routeur Advertisment. La gure 2.14 schmatise un domaine PMIPv6 avec deux LMA et deux MAG.
LMA1 LMAA1 LMA2 LMAA2

Proxy-CoA1 MAG1 MN-HNP1 MN1 MN-HNP2 MN2

Proxy-CoA2 MAG2 MN-HNP3, MN-HNP4 MN3

Figure 2.14 Ensemble des lments du rseau PMIPv6 (Proxy Mobile IPv6 Domain ) [65]

Adresse link local Ladresse source du message ICMPv6 Routeur Advertisment est une adresse link-local fournie par le LMA ou congure statiquement sur le MAG. Tous les messages du rseau que reoit le MN doivent avoir cette adresse comme source, de cette faon le MN ne peut dtecter les changements de rseaux. Si cette adresse est congure statiquement alors elle doit tre la mme pour tous les MAG. Lorsque le MN reoit le Routeur Advertisment il enregistre ses HNP et congure un HoA partir de ceux-ci ; comme cest le cas dans le protocole IPv6 [56]. Le rseau ne connait que les HNP du MN, seul celui-ci connait son HoA. La procdure dattachement du MN est schmatise la gure 2.15. Lorsque le rseau a complt son enregistrement, le MN peut communiquer avec lextrieur via le MAG quil considre comme un routeur IPv6 normal. Le MAG aiguille les donnes vers le LMA via le tunnel, le LMA dcapsule les donnes pour les envoyer sur le rseau externe. Les paquets provenant de lextrieur et destination du MN empruntent le chemin inverse. La gure 2.16 schmatise cette communication ; nous pouvons remarquer que celle-ci ressemble en tout point une communication utilisant le protocole MIPv4 avec encapsulation retour et FA CoA schmatis la gure 2.11b.

34

MN attachement

MAG

LMA

dtection de lattachement cas 1 Router Solicitation dtection de lattachement cas 2 rcupration du Policy Prole PBU acceptation du PBU, cration du BCE (mise jour du Binding Cache ), cration du tunnel (sil nexiste pas), allocation de MNHNP (sil ne sont pas inclus dans le Policy Prole ) PBA acceptation du PBA, cration du tunnel (sil nexiste pas) et mise jour des tables de routage tunnel bidirectionnel Router Advertisment conguration de ladresse IPv6

Figure 2.15 Attache dun MN un domaine PMIPv6 (inspir de Gundavelli et al. [65])

src : CN dst : MN-HoA CN src : MN-HoA dst : CN LMA

src : CN dst : MN-HoA src : LMAA dst : Proxy-CoA MAG src : MN-HoA dst : CN src : Proxy-CoA dst : LMAA

src : CN dst : MN-HoA MN src : MN-HoA dst : CN

Figure 2.16 Communication simple dans un rseau PMIPv6 (inspire de Gundavelli et al. [65])

35 Handover Lorsquun MN se dplace dun MAG lautre un handover est eectu dans le domaine PMIPv6. Cest un hard handover cest--dire que le MN se dtache du rseau pour ensuite sattacher au nouveau MAG (lors dun soft handover le terminal mobile sattache au nouveau rseau avant de se dtacher de lancien). Le MN se dtache de lancien MAG qui dtecte ce changement et informe le LMA par un PBU possdant un lifetime de zero (cf. gure 4.27). la rception de ce message le LMA met jour la BCE du MN, rpond au MAG par un PBA et lance un compte rebours. Si le LMA ne reoit pas dautre information concernant ce MN avant la n du compte rebours, il supprime la BCE et considre le MN comme hors du domaine PMIPv6. Le MN se lie au nouveau MAG qui lance une procdure dattache comme dcrite prcdemment. Si ce MAG est capable de dterminer si le MN provient dun handover ou sil eectue sa connexion initiale au domaine, il doit en informer le LMA grce loption Hando Indicator du PBU (voir section 4.3.6). la rception du nouveau PBU le LMA arrte les comptes rebours et met jour le BCE du MN, il enregistre en particulier le nouveau Proxy-CoA. Il renvoie au MAG les HNP, ladresse link-local utiliser et les autres informations utiles via un message PBA. Mais contrairement au cas o le MN se connecte pour la premire fois, il ne gnre pas de donnes dynamiquement, toutes les informations envoyes dans le PBA sont tires du BCE du MN. De cette faon le MAG peut congurer un environnement en tout point gal celui du prcdent MAG. Le Router Advertisment envoy au MN est donc le mme que ceux envoys par lancien MAG, la couche IPv6 du MN ne dtecte aucun changement de rseau. La gure 2.17 schmatise cette procdure.
MN dtachement de lancien MAG dtection du dtachement PBU de dtachement acceptation du PBU, lancement dun compte rebours PBA attachement au nouveau MAG Routeur Solicitation attachement du MN au nouveau MAG (voir gure 2.15) Routeur Advertisment conservation du HoA et des HNP ancien MAG LMA nouveau MAG

Figure 2.17 Handover dans un domaine PMIPv6 (inspir de Gundavelli et al. [65])

36 2.3 DiServ

Dans les spcications 23.401 [8] et 23.402 [9], les mcanismes de QoS ne sont spcis que pour la couche OSI no 7 : Application. Il est prcis que le trac doit tre spar dans dirents bearers ayant chacun leurs propres caractristiques de QoS. Dans nos simulateurs nous avons implment les MBR, GBR et UE Aggregated Maximum BitRate (UE-AMBR) au niveau des applications GTP, la bande passante des bearers ne peut donc pas excder une certaine valeur xe par lutilisateur. Cependant, cela ne garantit pas que les paquets passants par les bearers GBR ne soient pas rejets cause de la charge des bearers non-GBR. Pour supporter les caractristiques des QCI comme la priorisation, les contraintes de dlai, etc. il est conseill 4 dans 23.401 [8] et 23.402 [9] dutiliser une architecture DiServ. DiServ (dnie par Blake et al. [45] et Nichols et al. [80]) est une architecture permettant de faire de la QoS, cest--dire de direntier les paquets les uns des autres et de les prioriser/ ralentir/rejeter en consquence. Les paquets IPv4 et IPv6 possdent des champs DSCP (inclus dans le champ ToS en IPv4 et dans le champ Trac Class en IPv6 comme indiqu par Nichols et al. [80]) permettant de spcier quelle classe de service ils appartiennent. Typiquement dans une architecture de ce type, les routeurs situs dans la zone DiServ classient les paquets en fonction de leurs DSCP pour les mettre dans des les dattente. Un algorithme vient ensuite enlever les paquets des les dattente pour les envoyer sur le lien. Les routeurs en bordure de zone DiServ, en plus de faire ce travail, marquent les paquets. Il y a donc plusieurs tapes bien distinctes dans cette architecture : Le marquage (sur les routeurs de bordures) ; La classication ; Le Trac Conditionning qui peut remarquer/rejeter le paquet ; La mise en le dattente qui peut rejeter le paquet ; Le Scheduling qui dtermine le prochain paquet sortir sur le lien. 2.3.1 Le marquage

Le marquage des paquets se fait sur les routeurs en bordure de zone DiServ, il peut tre bas sur les ports, les adresses IP, ou encore utiliser une technique de DPI (comme il est prvu pour le SASN). Le DPI permet de classer un paquet suivant toutes les informations quil pourrait contenir, par exemple, lapplication destinataire du paquet ou le type de donne contenu (texte, vido, son, etc.), certains outils de DPI permettent mme de dcrypter les connexions chires (e.g. HyperText Transfer Protocol Secured (HTTPS)). Une fois que le paquet a t analys, son champ DSCP est chang pour reter la politique de QoS qui doit
4. Les exemples donns mentionnent lutilisation de DiServ.

37 lui tre applique. DiServ dnit trois principaux types de politiques appeles Per-Hop Behavior (PHB) [43] : Default Forwarding (DF) est utilis pour les tracs sans rel importance, il correspond au Best Eort. En dnitive aucun traitement spcial nest eectu sur ces paquets. Assured Forwarding (AF) comme dcrit par Heinanen et al. [67] ce PHB est utilis pour garantir que le trac en de dune certaine limite de bande passante sera achemin et que les paquets ne seront pas rordonns. Le trac au-del de la limite de bande passante a une forte probabilit dtre achemin, sans pour autant en tre garanti. Il est conseill pour les tracs de confrence multimdia, de streaming et pour les services ncessitants une faible latence. Expedited Forwarding (EF) comme dcrit par Davie et al. [55] ce PHB est utilis pour garantir que le trac ait un faible dlai, un faible IPDV et un faible taux de perte de paquets. Comme le AF, il garantit le passage des paquets en de dune certaine valeur de bande passante, mais garantit aussi que les paquets ne seront pas retards par le routeur courant au-del dune certaine limite ; un IPDV maximum est assur. Ce PHB est recommand pour le trac VoIP. 2.3.2 La classication

Le classieur spare les paquets en fonction de leurs DSCP et les envoie au policer correspondant. Chaque nud DiServ en possde un. 2.3.3 Le Trac Conditionning aussi appel Policing

Le Trac Conditionning sassure que le trac dont il a la charge ne dpasse pas une certaine bande passante (dans la plupart des cas). Il peut remarquer ou rejeter (drop ) les paquets non conformes. Les dirents types de Trac Conditionning mentionns par Babiarz et al. [43] sont 5 : le seau jetons (token bucket ) appel sr+ts, reprsent la gure 2.18 ; le single-rate, three-color marker (srTCM) dcrit par Heinanen et Guerin [68] et reprsent la gure 2.19 ; le two-rate, three-color marker (trTCM) dcrit par Heinanen et Guerin [69] et reprsent la gure 2.20. Les actions dcrites dans ces schmas peuvent tre un re-marquage, une transmission, un rejet du paquet, ou une combinaison de deux de ces actions. Babiarz et al. [43] conseille
5. Tous sont disponibles sous NS-2.

38 dutiliser un seau jetons pour le trac EF et srTCM ou trTCM pour les dirents types de tracs AF ; le trac DF quant lui ne passe dans aucun policer.

Figure 2.18 Filtre de Seau Jetons (inspir de Menoncin [76])

2.3.4

Active Queue Management

Pass le Trac Conditionning les paquets passent par un algorithme de rejet (il y a un module de rejet par policer ). Ces modules servent contrler la taille des les dattente dans lesquelles seront mis les paquets. Les principaux modules sont : Drop Tail dont le fonctionnement est schmatis la gure 2.21a ; Random Early Detection (RED) dcrit par Braden et al. [46] et dont le fonctionnement est schmatis la gure 2.21b ; Weighted Random Early Detection (WRED) dont le fonctionnement est schmatis la gure 2.22. Cest une volution de RED dveloppe par Cisco qui permet de distinguer, pour une mme le dattente, les paquets de DSCP dirent et dy associer des paramtres RED distincts (maxp, minth, maxth) [52]. 2.3.5 Le Scheduling

Le scheduling dnit la manire dont les les dattente sont servies. Les types dalgorithmes voqus par Babiarz et al. [43] sont Priority Queueing (PQ) (aussi appel PRIO) et Rate Queuing dont on mentionne Weighted Fair Queueing (WFQ) et Weighted RoundRobin (WRR). Lalgorithme PRIO consiste servir en premier les les congures avec la priorit la plus forte ; tant quil y a des paquets dans cette le aucune des autres nest servie.

39

Figure 2.19 Filtre srTCM (inspir de Menoncin [76])

Figure 2.20 Filtre trTCM (inspir de Menoncin [76])

40

(a) Drop Tail

(b) RED

Figure 2.21 Mthodes de gestion des les dattente Drop Tail et RED

Figure 2.22 Mthode de gestion de le dattente WRED

41 Cet algorithme est utile si lon souhaite quun type de trac passe avant tous les autres, mme si celui-ci risque de sapproprier toute la bande passante. En eet, il existe un risque de famine des les de basses priorits. Dans un environnement dentreprise ou dans le cas de structures plus grandes, ce risque nest pas envisageable 6 . Cest pourquoi ce type de le est associ un limiteur de bande passante (Rate Limiter ) [104]. Pour dcrire lalgorithme WFQ comme expliqu par Vega Garcia et Huitema [98] il est plus judicieux dexpliquer le fonctionnement de Round-Robin (RR) et WRR en premier. Lalgorithme basique RR consiste servir successivement les les dattente les unes aprs les autres. Par servir nous entendons prendre un paquet et lenvoyer sur le lien. Cet algorithme pose problme lorsque deux les ont des paquets de tailles moyennes direntes, la le ayant les paquets les plus grands se verra attribuer une plus grande partie de la bande passante. Pour remdier cela il existe lalgorithme WRR associant chaque le un poids que nous appellerons P . Lorsquune le est servit elle envoie P paquets sur le lien. De cette faon on peut associer un poids plus important aux les dont on sait que la taille moyenne des paquets est petite. Lalgorithme le plus quitable en terme de partage de bande passante est le bit-by-bit Round-Robin (BBRR), il sapparente au RR dans le sens o il sert tour tour chaque le. Cependant, au lieu denvoyer un paquet chaque service il nenvoie quun bit du paquet. Cet algorithme est bien sr impossible raliser tant donn quil fragmente chaque paquet en blocs de un bit. Weighted bit-by-bit Round-Robin (WBBRR) est une variante de BBRR o chaque le possde un poids P et chaque service correspond lenvoi de P bits sur le lien. Il permet de conserver lquit du BBRR toute en distribuant de faon non gale la bande passante aux direntes les. Il nest pas ralisable en pratique de part la fragmentation des paquets quil implique. Le but de lalgorithme WFQ dcrit par Vega Garcia et Huitema [98] et dvelopp par Cisco, est de simuler lalgorithme WBBRR ; il nenvoie pas des bits, mais des paquets. chaque paquet est associ un nombre, lenvoi se faisant dans un ordre croissant en fonction de cette valeur. Ce nombre reprsente le numro du tour (nombre de tours eectus depuis le lancement de lalgorithme) au cours duquel serait servi le paquet si lalgorithme WBBRR avait t utilis. Lorsquun paquet arrive dans une le, on dtermine son nombre associ Ni en fonction du poids de la le , de la taille du paquet Pi , du nombre Ni1 associ au paquet suivant dans la le et R le nombre de tour quaurait fait lalgorithme WBBRR (sil avait t utilis) au moment o le paquet est arriv. La formule adapte partir de la formule de lalgorithme
6. Except dans le cas de trac relatif la scurit, par exemple : une communication tlphonique vers le 911.

42 Fair Queueing (FQ) de Vega Garcia et Huitema [98], est la suivante : Ni = max (Ni1 , R) + P (2.1)

Cependant, mme si cet algorithme permet de rpartir la bande passante de faon quitable entre les direntes les dattente, il ne permet pas de garantir un dlai maximum comme il est demand pour le PHB EF. Pour cette raison Cisco a dvelopp une autre caractristique de le appele Low Latency Queueing (LLQ), celle-ci sapparente une le prioritaire de lalgorithme PRIO [42], mais comporte une limite de bande passante permettant dviter la famine des autres les [51, 50, 57, 75]. Les 7 les LLQ sutilisent dans un environnement WFQ. Lalgorithme Decit Round-Robin (DRR) dcrit par Shreedhar et Varghese [95] permet lui aussi de faire du partage quitable de ressources. Il sapparente un RR dans le sens o les les sont servies tour tour, mais servir signie cette fois lattribution dun certain quantum de bits. Les les possdent une variable gale la somme des bits servis depuis lenvoi du dernier paquet. Lorsque cette valeur devient suprieure la taille du premier paquet de cette le alors celui-ci est envoy et lalgorithme est arrt jusqu ce que le paquet ait t transmis sur le lien. Il est possible dassoci un quantum de un bit aux les de faon simuler le BBRR, mais cela demande lexcution dun nombre important de tours ce qui implique une forte charge CPU. Nous avons appel Decit Weighted bit-by-bit RoundRobin (DWBBRR) une variante de DRR dans laquelle toutes les les possdent un poids P (gnralement infrieur dix) et o le quantum DRR associ une le est gal P bits (voir section 4.2.7 pour plus de dtails). 2.3.6 Rsum et Notes

Le schma de la gure 2.23 reprsente toutes les tapes par lesquelles passe un paquet en sortie dun routeur DiServ de bordure. Certains algorithmes nont pas t reprsents pour simplier le schma ou parce quils sont incompatibles entre eux (par exemple les algorithmes de Scheduling PRIO et WFQ). Dans un routeur DiServ central (ou Core ) la seule dirence aurait t la suppression du module de marquage au tout dbut de la chane. titre dinformation le noyau Linux permet lui aussi de faire de la QoS, mais la gestion des les dattente est lgrement dirente de celle utilise dans NS-2 et les routeurs Cisco [76]. En eet, le schma le plus appropri pour dcrire le module de QoS du noyau Linux serait celui dun arbre dans lequel les feuilles seraient les les dattente avec leurs modules
7. On utilise gnralement quune le LLQ, mais il est tout de mme possible den crer plusieurs.

43

Figure 2.23 Chemin dun paquet en sortie dun routeur DiServ Edge (inspir de Menoncin [76]) Active Queue Management (ACQ), et chaque fourche reprsenterait un module de Trac Conditionning ainsi quun Classier. Actuellement le noyau Linux dispose des ACQ suivants : b-FIFO et p-FIFO qui sont des les FIFO simples (le b pour Byte et le p pour paquet ne servant qu logger de faon dirente la charge de la le) ; pfo_fast (le par dfaut des interfaces) qui contient trois sous-les servies par lalgorithme PRIO ; cette le classie elle-mme les paquets dans ses sous-les de manire respecter les spcications de Almquist [40] ; Token Bucket Filter (TBF) est un seau jetons simple ; Stochastic Fairness Queueing (SFQ) permet de rpartir quitablement la bande passante entre les direntes connections, les dirents ux quelle contient. Quelques modules de Scheduling (qui peuvent tre plusieurs sur une mme interface) : PRIO ; DRR ; Class Based Queueing (CBQ) dont les fonctionnalits sont trop nombreuses pour tre dcrites ici ; Hierarchical Token Bucket (HTB) qui possde moins de fonctionnalit que CBQ, mais qui est beaucoup plus facile congurer. Pour avoir plus de dtails sur ces dirents types de les et algorithmes, nous conseillons la lecture de inetdoc LINUX [71]. Un exemple de conguration se trouve lannexe I.

44 CHAPITRE 3 PROPOSITION DVOLUTION VERS UNE UTILISATION PLUS AVANCE DIPv6

Comme nous lavons expliqu prcdemment, contrairement aux 3G, le trac de voix partage le mme chemin que les autres dans les rseaux mobiles 4G. Cependant, malgr lutilisation du protocole IP, le rseau est toujours gr en grande partie par GTP, qui fut dvelopp initialement pour GPRS (2.5G). Dans le cadre de cette matrise, nous avons cherch utiliser au maximum les possibilits oertes par la couche IP et ainsi rduire lusage dautres protocoles comme GTP ou GRE. Nous avons considr que tous les terminaux utilisent IP version 6. Les rseaux mobiles ncessitent une attention particulire en ce qui concerne les performances et donc les techniques de QoS employer. Ils sont limits en ressources et lapparition de nouvelles formes de mdias sur les tlphones cellulaires (e.g. la vido) les soumet des contraintes importantes. Le phnomne sest ampli dans les rseaux 4G du fait du passage de la voix sur IP, utilis par les autres types de trac. Les changements proposs seront tests sur la base des performances du rseau au niveau des terminaux. Dans ce chapitre nous allons dtailler le fonctionnement des architectures 23.401 [8] et 23.402 [9] proposes par 3GPP. Puis nous exposerons les suggestions de Hui et al. [70] pour modier le protocole PMIPv6 ; ce qui nous permettra dintroduire les architectures 403 et 404 que nous proposons. Nous nirons en dcrivant les direntes mtriques de performances que nous avons utilises pour valuer nos modications. 3.1 Larchitecture 23.401

Dans larchitecture 23.401 [8] la QoS est gre et applique grce des tunnels appels bearers (voir section 2.1.7) ; ceux-ci tant grs par le protocole GTP. Ce systme mis en place par 3GPP apporte une certaine scurit tant donn que les bearers GBR sont grs de faon dirente des non GBR. Par exemple, la bande passante des liens est divise, une partie pour les GBR et le reste pour les non GBR. De plus la bande passante des bearers GBR, comme son nom lindique, est rserve. Larchitecture 23.401 [8] est reprsente la gure 1.1a et les couches de protocoles utilises sur le chemin de donnes la gure 3.1. La gure 3.2 donne une vue schmatique

45 des dirents types de bearers GTP et du paramtre AMBR 1 . Dans chaque bearer passe un ou plusieurs services, les non GBR sont limits par les UE-AMBR et APN-AMBR, ce qui nest pas le cas des GBR. Les diagrammes de squences des procdures auxquelles nous nous sommes intresss, sont reprsents dans lannexe A.
Application IP PDCP RLC MAC couche physique LTE UE LTE-Uu PDCP RLC MAC couche physique LTE eNodeB GTP-U UDP/IP L2 L1 S1-U GTP-U UDP/IP L2 L1 SGW GTP-U UDP/IP L2 L1 S5/S8 IP GTP-U UDP/IP L2 L1 PGW SGi

Figure 3.1 Couches de protocoles du plan de donnes dans un EPS (inspir de 23.401 [8])

Figure 3.2 Schma reprsentatif des bearers GTP dans larchitecture 23.401

3.1.1

GTP

Comme mentionn dans la section 1.1 le protocole GTP se divise en deux domaines dapplication. Il agit dans le plan de donnes pour encapsuler les paquets des usagers ; et
1. Le AMBR nest pas un tunnel comme on pourrait le croire la vue de ce schma.

46 dans le plan de contrle pour grer la mobilit et les bearers. Il intervient au dessus du protocole UDP comme reprsent la gure 3.3.
. . . GTP UDP IP L2 L1 GTP entity GTP-based interface . . . GTP UDP IP L2 L1 GTP entity

Figure 3.3 Couches de protocoles utilises sous GTP GTP fut initialement dvelopp pour les rseaux GPRS. Le consortium 3GPP lamliora ensuite pour le rendre compatible avec UMTS ; cette version appele GTP second stage, rst version for EPS (GTPv1) 2 est dcrite dans le document 29.060 [16]. 3GPP continua dapporter des amliorations au protocole pour permettre son utilisation dans le rseau EPS et partir de la version 8 de ses spcications, spart clairement le protocole GTP en GTP-U version 1 (GTPv1-U) dcrit dans 29.281 [24], et GTP-C version 2 (GTPv2-C) dcrit dans 29.279 [23]. GTP-U est utilis sur les interfaces S1-MME et S5/S8, le GTP-C est utilis sur S11, S5/S8 et X2 si celle-ci existe (voir gure 2.10). GTP User data tunneling Sur le plan de donnes len-tte GTP est de taille variable, il comporte les ags PN, S et E qui indiquent la prsence de champs optionnels. Le ag S est x zro par les nuds eNodeB, SGW et PGW. Le ag PN est activ lors de relves inter-technologiques (vertical handover ). Le ag E est activ lorsque le paquet contient une autre extension, nous ne lutilisons pas dans le cas dune simple encapsulation de paquet. Il existe aussi les ags P et T, nous avons choisi de toujours xer P zro (il permet dactiver le PiggyBacking ). Le ag T permet de direntier le trac de donnes du trac de contrle. En rsum, sur le plan de donnes len-tte du protocole GTP fait 8 octets (voir schma 3.4).
2. La premire version tant dsigne par GTP rst stage (GTPv0).

47
0 Flags 32 TEID 64 Data 8
Version Message

16 Type

24 Length

32

Figure 3.4 En-tte GTP-U utilis dans le plan de donnes (inspir du document 29.281 [24]) Le champ TEID reprsent dans le schma 3.4 identie le bearer emprunter sur le chemin GTP ; un chemin correspondant deux IP et deux ports UDP. GTP-C Len-tte du protocole GTP-C contient une partie commune tous les messages de contrles, schmatise la gure 3.5 ; cet en-tte fait 12 octets.
0 Flags 32 TEID 64 Sequence Number 96 IE(s) Spare 8
Version Message

16 Type

24 Length

32

Figure 3.5 En-tte GTP-C utilis dans le plan de contrle (inspir du document 29.274 [22]) Les Information Element (IE) sont des informations utiles au message, par exemple dans un message de contrle Create Session Request , un IE Radio Access Type (RAT) Type et un ou plusieurs IE Fully-Qualied Tunnel Endpoint Identier (F-TEID) seront inclus. Le format gnral dun IE est reprsent la gure 3.6. Les dirents messages de contrle du protocole GTP-C et les IE sont trop nombreux pour tre tous dcrits ici, on peut cependant les trouver dans les documents 29.060 [16] et 29.274 [22].

48
0 Type 32 IE Specic Data 8 16 Length 24 32

Instance Spare

Figure 3.6 En-tte classique dun IE dans le protocole GTP-C (inspir de 29.274 [22]) 3.2 Larchitecture 23.402 Larchitecture 23.402 [9] est une volution de la 23.401 [8], le principe des bearers reste le mme mais linterface S5/S8 a chang. Elle est reprsente la gure 1.1b, les couches de protocoles utilises sur le chemin de donnes sont exposes la gure 3.7 et un schma reprsentatif des bearers est disponible la gure 3.8. Les diagrammes de squences des procdures de cette architecture auxquelles nous nous sommes intresss, sont reprsents dans lannexe B.
Application IP PDCP RLC MAC couche physique LTE UE LTE-Uu PDCP RLC MAC couche physique LTE eNodeB GTP-U UDP/IP L2 L1 S1-U GTP-U UDP/IP L2 L1 SGW GRE IP L2 L1 S5/S8 IP GRE IP L2 L1 PGW SGi

Figure 3.7 Couches de protocoles du plan de donnes dans un EPS suivant larchitecture 23.402 [9] Le protocole GRE permet de remplacer GTP-U pour encapsuler les paquets et direntier les bearers. Ces tunnels GRE sont eux mme encapsuls dans un tunnel PMIPv6 entre le SGW faisant oce de MAG et le PGW faisant oce de LMA. Larchitecture PMIPv6 a dj t prsente la section 2.2.3. Cependant nous pouvons remarquer la gure 3.7 que le protocole PMIPv6 a t modi. Dans le RFC de PMIPv6 [65] il est dcrit que le MAG doit tre le routeur par dfaut du MN (sous entendu pour la couche IP). Or la couche IP du UE est en relation avec celle du PGW et non celle du SGW, le routeur par dfaut du UE est donc le PGW qui est le LMA dans larchitecture PMIPv6.

49

Figure 3.8 Schma reprsentatif des bearers GTP et GRE dans larchitecture 23.402 Comme dcrit la section 3.1.1, le protocole GTP se divise en deux branches, le GTP-U et le GTP-C. Le GTP-U qui encapsule les paquets de donnes a t remplac par GRE entre le SGW et le PGW. Cependant GRE ne permet pas de transmettre des informations de contrle. Les informations qui transitaient via GTP-C sur le lien S5/S8 ne peuvent plus emprunter le mme chemin. Un nouveau lien a donc t cr entre le PCRF et le SGW, sur lequel est utilis le protocole Diameter. 3.2.1 Diameter

Le protocole Diameter, dcrit par Calhoun et al. [48], est utilis dans le EPS pour transporter des informations de contrle sur les liens S6a, Gx et Rx. Il est le successeur du protocole Remote Authentication Dial-In User Service (RADIUS), do il tire son nom (voir Olsson et al. [81]). Il a lavantage dtre trs facilement modiable et volutif. En eet, un en-tte Diameter contient une partie basique obligatoire, pouvant contenir plusieurs Attribute Value Pairs (AVP) que lorganisme utilisateur du protocole peut dnir comme il veut du moment quil ait reu un identiant de lIANA. Plusieurs messages, AVP, sont aussi dnis de faon native dans Diameter. Nous avons reprsent len-tte de base ainsi que le schma dun AVP dans les gures 3.9 et 3.10. Un ensemble dAVP dnit une application, il existe par exemple lapplication NAS dnie par lIETF, celles utilises sur les liens Gx, S6a et Rx (cf. gure 2.10) dveloppes par le consortium 3GPP, etc. Un schma de la structure de Diameter est reprsent la gure 3.11. Les dirents messages et AVP Diameter utiliss sur linterface S6a sont dcrits dans

50

0 Version 32
Command Flags

16

24

32

Message Length Command Code Application ID

64 96 Hop-by-Hop Identier 128 End-to-End Identier 160 AVP(s)

Figure 3.9 En-tte du protocole Diameter (inspir de Calhoun et al. [48])

16 AVP Code

24

32

32 Flags 64 Vendor ID (optionel) 96 Data AVP Lenght

Figure 3.10 En-tte classique dun AVP dans le protocole Diameter (inspir de Calhoun et al. [48])

51 le document 29.272 [21], ceux de linterface Gx sont dans le document 29.212 [18] et ceux de Rx sont dans 29.214 [19].

Figure 3.11 Structure classique du protocole Diameter (inspir de Olsson et al. [81]) Diameter se place au dessus de TCP ou Stream Control Transmission Protocol (SCTP) comme reprsent la gure 3.12. La taille de ces messages est dcrite section 4.3.2.

Diameter TCP ou SCTP IP L2 L1 Diameter entity Diameter-based interface

Diameter TCP ou SCTP IP L2 L1 Diameter entity

Figure 3.12 Couches de protocoles utilises sous Diameter

3.3

Proxy Mobile IPv6 multi-tunnel

Hui et al. [70] propose une volution du protocole PMIPv6 pour permettre le dploiement de plusieurs tunnels entre un MAG et un LMA. Dans cette architecture, chaque service possde son propre tunnel, ce qui permet de direntier les tracs entre le MAG et le LMA et ainsi de faciliter la mise en place de techniques de QoS comme DiServ. La gure 3.13 donne un exemple dutilisation de PMIPv6 avec plusieurs tunnels par MN. Pour dployer les tunnels, ils introduisent deux nouvelles options PMIPv6 : Service Flow Identier et Service Flow Description reprsentes aux gures 3.14 et 3.15. Ils utilisent le protocole GRE pour direntier les tunnels, notamment grce au champ key du BCE quils proposent. Pour diuser ces clefs, ils utilisent loption GRE Key de PMIPv6 prsente la gure 3.16.

52
MN : [ SFI1, HNP, uplink GRE Key, downlink GRE Key ] MN : [ SFI2, HNP, uplink GRE Key, downlink GRE Key ]

LMA

SF1

SF2

domaine PMIPv6

SF2 MAG SF1 MN

Figure 3.13 Exemple dutilisation de PMIPv6 avec plusieurs tunnels (inspir de Hui et al. [70])
0 Type 32 Service Flow Identier 64 Service Flow Description option Reserved 8 Length 16 Status 24 PRO 32
Reserved

Figure 3.14 Option Service Flow Identier de PMIPv6 [70, sec 3.1]
0 Option Type 32 Type Service Flow Description 8 Length 16 24 Reserved 32

Figure 3.15 Option Service Flow Description de PMIPv6 [70, sec 3.2]
0 Type 32 GRE Key Identier 64 8 Length 16 24 Reserved 32

Figure 3.16 Option GRE Key de PMIPv6 [78, sec 6.1]

53 Le MAG analyse le trac et dclenche une procdure de cration de tunnel lorsquun nouveau ux, quune nouvelle connexion, est dtect comme reprsent la gure 3.17.
MN attachement Router Solicitation Router Advertisment MAG PBU / PBA tunnel bidirectionnel par dfaut le MN est attach Dmarrage dun nouveau service PBU (Service Flow) PBA (Service Flow) tunnel bidirectionnel spcique pour le service donnes donnes LMA

Figure 3.17 Cration dun tunnel spcique un service dans larchitecture PMIPv6 (inspir de Hui et al. [70, sec 2])

3.4

Larchitecture 403 Dans le cadre de cette matrise nous avons essay de maximiser lutilisation du protocole

IPv6, ce qui se traduit indirectement par une minimisation de lutilisation de GTP et GRE. Nous nous sommes tout dabord bass sur larchitecture 23.402 [9] et lavons modie de faon transfrer la gestion des bearers PMIPv6. Nous nous sommes donc servi du draft de Hui et al. [70] que nous avons modi de faon mimer le comportement des mthodes actuelles de gestion des bearers. Dans ce draft chaque service possde son propre tunnel. Cependant un bearer (pour les architectures 23.401 [8], 23.402 [9]) peut tre partag entre plusieurs services, par exemple le bearer par dfaut dun UE est emprunt par tous les services qui nont pas de priorit particulire. Les bearers ddis peuvent aussi faire transiter plusieurs tracs, et donc plusieurs services, requrant la mme priorit. Dans un premier temps, nous avons donc cr de nouvelles options PMIPv6 permettant de dployer des tunnels pour plusieurs services. Le protocole GTP utilise des TFT pour dcrire le trac passant par un bearer [4, sec 15.3]. Un TFT est un ensemble de Packet Filter (PFi) identis par des Packet Filter Identier (PFID) (unique dans un mme TFT) et ayant chacun une priorit appele prcdence. Les valeurs de prcdence des PFi dnissent lordre dans

54 lequel ils doivent tre valus. Un PFi est une combinaison des caractristiques suivantes : adresse du CN et masque de sous rseau ; Next Header (tant donn notre choix de ne considrer que lIPv6) ; intervalle de port, cot UE ; intervalle de port, cot CN ; Security Parameters Index (SPI) pour Internet Protocol Security (IPSec) ; Trac Class IPv6 et masque (voir gure 3.18) ; Flow Label IPv6 (voir gure 3.18). Les PFi permettent disoler les tracs des dirents services du UE. Le protocole GTP-C possde un IE ddi au transport de TFT [10, sec 10.5.6.12]. Il contient notamment : un TFT operation code permettant de dcrire laction appliquer la rception de ce IE. Il peut indiquer par exemple la cration dun nouveau TFT, le remplacement, la modication ou la suppression dun ancien TFT, etc. le nombre de PFi quil inclut ; une liste de PFi contenant uniquement des PFID si laction dcrite plus haut correspond une suppression de PFi dun TFT existant. Sinon chaque lment de cette liste est compos de : un PFID ; la prcdence du PFi ; la taille de la description ; la description du PFi (combinaison de caractristiques dcrites plus haut). Nous avons donc reproduit ce schma pour larchitecture PMIPv6 quelques dirences prs. Nous avons tout dabord cr une option Trac Flow Template schmatise la gure 3.19. Cette option contient un champ Procedure (PRO) correspondant au operation code GTP et un champ Status tir de loption Service Flow Identier reprsent la gure 3.14. Nous ny avons pas directement inclus les PFi comme dans GTP car cela nous permet de spcier autant de PFi que ncessaires pour une seule option TFT. En eet pour GTP comme pour PMIPv6 la taille dune option est dcrite sur un octet, ce qui la limite un maximum de 255 octets. Or la description dun PFi peut prendre jusqu soixante octets (en IPv6), ce qui limite donc un IE TFT quatre PFi dans le pire des cas. La solution adopte par GTP dans le cas o loption TFT est trop courte, est de rpartir tous les PFi dun TFT dans plusieurs IE TFT. Un TFT nest donc pas forcment dcrit par un seul IE. Nous avons prfr crer deux options direntes, une pour la description du TFT (ou plutt de laction appliquer un TFT) et une pour chaque PFi. Loption TFT est donc forcment suivie dune ou plusieurs options PFi sur lesquelles elles sappliquent. Loption PFi reprsente la gure

55 3.20 permet de dcrire les caractristiques dun PFi, elle correspond loption Service Flow Description laquelle nous avons ajout le PFID de GTP (ou le Service Flow Identier (SFI) de loption Service Flow Identier dcrit par Hui et al. [70]) et sa valeur de prcdence. Seul le champ PFID est obligatoire, en eet lors dune suppression de PFi dun TFT la description complte du PFi nest pas ncessaire, seul son identiant sut.
0 Version 32 Payload Length 64 Next Header Hop Limit 8 Trafc Class 16 24 Flow Label 32

Source Address

192

Destination Address

320

Figure 3.18 En-tte IPv6 (inspir de [56, sec 3])

0 Type 32

8 Length

16 Status

24 PRO

32
Reserved

Figure 3.19 Option Trac Flow Template propose pour PMIPv6 Hui et al. [70] utilise loption GRE Key reprsente la gure 3.16, introduite par Muhanna et al. [78]. Cependant celle-ci a t prvue pour permettre lidentication de destination, par exemple dans le cas o le LMA est connect plusieurs rseaux ayant les mmes plages dadresses IP (e.g. deux rseaux Local Area Network (LAN) utilisant la plage 10.0.0.0/24). GRE peut aussi encapsuler un trs grand nombre de protocoles ; mais cette

56
0 Option Type 32 Type 64 PFi Description 8 Length 16 PFID 24 32

PFi precedence

Figure 3.20 Option Packet Filter propose pour PMIPv6 fonctionnalit ne nous est pas utile tant donn que seul IPv6 transite dans les bearers, tel que prsent aux gures 3.1 et 3.7. Daprs Gundavelli et al. [65, sec. 6.10.2] la mthode dencapsulation prconise pour PMIPv6 est IPv6-In-IPv6 (dcrit par Conta et Deering [53]) cest dire que le Protocol data unit (PDU) IP du paquet encapsul devient le Service Data Unit (SDU) IP du paquet nal. Lutilisation de GRE na rien dobligatoire, nous avons donc utilis une encapsulation IPv6-In-IPv6 ; il fallait donc un nouveau moyen de distinguer les bearers. Len-tte IPv6 reprsent la gure 3.18 possde un champ Flow Label nayant pas encore dutilit concrte, la seule contrainte est quil doit arriver au destinataire avec la valeur xe par le nud source (il peut tre chang sur le trajet du moment quil soit remis linitial la n). Il pourrait tre intressant de lutiliser pour distinguer les dirents tunnels PMIPv6 entre un MAG et un LMA. Ce champ fait vingt bits, ce qui permet de distinguer environ un million de tunnels. Les entreprises dveloppant le EPS considrent quune ville comme Montral (approximativement 1 700 000 habitants) ncessite approximativement 30 SGW. Chaque couple bearer /UE possde un QCI unique, et il existe neuf QCI prdnis par le consortium 3GPP. Si lon suppose que tous les habitants de Montral sont connects au rseau LTE de faon quitablement rpartie, et quils utilisent chacun neuf bearers (un par QCI) cela fait environ 510 000 bearers par SGW. Limiter le nombre de bearer par SGW un million nest donc pas aberrant. Nous avons donc dcid dutiliser le champ Flow Label dIPv6 pour direntier les tunnels entre un MAG et un LMA. Cest dire que chaque tunnel possde un identiant de 20 bits unique pour le MAG, celui-ci est inclus dans le champ Flow Label de len-tte des paquets IPv6 encapsulant. Pour le dployer entre le MAG et le LMA nous avons cr une nouvelle option Flow Label pour le protocole PMIPv6. Cette option est reprsente la gure 3.21. tant donn que les mobility header doivent avoir une taille multiple de huit octets nous avons prfr ajouter un padding de 12 bits pour que cette option fasse huit octets. Si la limitation du nombre de bearers un million par SGW devient problmatique, lutilisation de GRE reste possible. Nous avons dcid de btir notre modle en utilisant le Flow Label dIPv6 comme identiant des bearers cependant cet identiant peut tre facilement

57 remplac par une clef GRE. Le modle utilisera alors loption GRE Key du mobility header PMIPv6 plutt que loption Flow Label.
0 Type 32 Flow Label 64 Reserved 8 Length 16 24 Reserved 32

Figure 3.21 Option Flow Label de PMIPv6 Pour supporter plusieurs tunnels entre un LMA et un MAG Hui et al. [70] tendent les Binding Update List Entry (BULE) et BCE avec un PFID et une description de PFi. tant donn les transformations apportes, nous avons ajout aux BULE du MAG et aux BCE du LMA : un Flow label ; une liste de PFi dont chacune des entres contient : un PFID ; une valeur de prcdence ; un identiant dcrivant le type de description du PFi, trois de ces types sont prdnis dans le document 23.060 [4, sec 15.3.2.0]. Hui et al. [70] utilisent les mmes types de base que ceux dnis par 3GPP. une description du PFi (combinaison de caractristiques). Sur le MAG le Flow Label identie de faon unique le tunnel, sur le LMA en revanche le couple HNP/Flow Label est lidentiant. Nous avons dni les modications apporter au protocole PMIPv6 pour permettre un dploiement de tunnel mimant les bearers prsents dans les architectures 23.401 [8] et 23.402 [9]. Nous allons maintenant prciser les modications apporter ces architectures pour utiliser ces nouvelles fonctionnalits. 3.4.1 Squence

Nous nous sommes bass sur larchitecture 23.402 [9] car elle inclut dj une portion du rseau cur utilisant une version de PMIPv6 remanie. Dans un premier temps nous navons modi que linterface S5/S8 (SGW-PGW) qui utilise dj PMIPv6, et avons appel cette nouvelle architecture 403. Nous avons transform le SGW en un routeur IP pour quil apparaisse comme un vrai MAG. Les crations/modications/destructions de bearers sont maintenant gres au niveau PMIPv6. Nous avons supprim GRE car il ne nous est dsormais

58 plus utile. Les couches de protocoles du plan de donnes de larchitecture 403 sont reprsentes la gure 3.22.
Application IPv6 PDCP RLC MAC couche physique LTE UE LTE-Uu PDCP RLC MAC couche physique LTE eNodeB GTP-U UDP/IPv6 L2 L1 S1-U GTP-U IPv6 (PMIPv6) UDP/IPv6 L2 L1 SGW L2 L1 S5/S8 L2 L1 PGW SGi IPv6 (PMIPv6) IPv6 IPv6

Figure 3.22 Couches de protocoles du plan de donnes dans un EPS suivant larchitecture 403 propose Il nous a aussi fallu modier les diagrammes de squences des direntes procdures de larchitecture 23.402 [9] impliquant les bearers (voir Annexe B). Ces nouveaux diagrammes de squences sont reprsents dans cette section et dans lannexe C. Dans les procdures de compltion de bearer (ajout dun service), reprsentes aux gures B.1 B.4, nous avons ajout un change PBU/PBA au niveau PMIPv6 au moment o le tunnel GRE est modi dans larchitecture 23.402 [9]. Les diagrammes de squences de ces nouvelles procdures sont reprsents aux gures 3.23 et C.1 C.3. La bande passante des liens, la rservation et la limitation du dbit des tracs sont encore gres par le SGW, le PGW et le eNodeB et ne peuvent pas tre administres directement par PMIPv6. Nous avons donc gard les autres messages de contrle de ces procdures pour dployer les informations comme les politiques de facturations, les limitations appliquer aux tracs, les rservations de bande passante, etc. Le LMA/PGW attend de recevoir les messages PBU et Policy and Charging Rules Provision respectivement du MAG/SGW et du PCRF avant denvoyer le PBA et laccus de rception. De cette faon, nous nous assurons quun tunnel nest cr que lorsque toutes les informations le concernant sont arrives sur le PGW. La procdure de connexion reprsente la gure B.5 na pas t modie en apparence, cest dire que les mmes messages sont envoys. Cependant, nous avons ajout au PBU de connexion une option Flow Label pour spcier lidentiant du bearer par dfaut. Les procdures de cration de bearer reprsentes aux gures B.6 et B.7 ont t modies de la mme manire que celles de compltions (voir gures C.4 et C.5). Les procdures de destruction et de rduction de bearer, reprsentes aux gures B.8 B.13, ont t modies

59 de faon inclure un change de PBU/PBA au moment o le tunnel GRE est modi dans larchitecture 23.402 [9] (voir gures C.6 et C.11). La rduction ou destruction eective du bearer se fait au dbut de la procdure car elle na pas lieu dtre rejete contrairement une cration ou une compltion. Le PGW attend toujours de recevoir les informations du SGW et du PCRF pour rpondre.
UE eNodeB MME SGW PGW PCRF SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Control and QoS Rules Provision Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Response Politic SASN Ack Response Politic

Figure 3.23 Compltion de bearer ddi non GBR avec UE QoS unaware Les procdures de relve sans changement de SGW avec ou sans interface X2 (liant deux eNodeB) ne changent pas. En eet aucun modication ny est eectue entre le SGW et le PGW. En revanche, si le eNodeB de destination ne possde pas assez de bande passante restante pour accueillir tous les bearers du UE, il y a destruction des bearers de plus faible ARP. Dans ce cas nous avons inclus une destruction de tunnel PMIPv6 comme lors dune destruction de bearer normal (cf. gure B.14). Dans le cas de relve avec changement de SGW reprsente aux gures B.15 et B.16 nous avons modi les PBU/PBA utiliss pour crer la connexion entre le nouveau SGW et le PGW et pour dtruire lancienne (voir gures C.13 et C.14). Dans notre architecture le PBU de connexion est complt doptions TFT, PFi et Flow Label ncessaires la cration de tous

60 les anciens tunnels qui nont pas t dtruits par la relve. Il y a donc une option TFT et une option Flow Label par tunnel, chaque TFT tant suivi dune liste de PFi (incluant les champs optionnels) dcrivant tous les services passant par le tunnel correspondant. Pour dtruire la connexion entre lancien SGW et le PGW nous avons ajout un change de PBU/PBA de dconnexion. Nous navons pas complt ces messages doption particulire et avons utilis ceux dcrits par Gundavelli et al. [65]. En eet le but de ces messages est dinformer le LMA/PGW que le UE nest plus rattach lancien SGW, il ny a pas de notion de bearer. Comme pour les architectures 23.401 [8] et 23.402 [9] nous avons cr un simulateur mimant le comportement de 403. Cependant nous nous sommes demands si les changements apports pouvaient tre tendus jusquau eNodeB. Nous avons donc imagin une nouvelle architecture appel 404. 3.5 Larchitecture 404 Dans cette architecture (volution de la 403) nous avons tendu le domaine PMIPv6 aux eNodeB. Pour correspondre au fonctionnement de GTP nous avons install un LMA sur le SGW (en plus du MAG dj prsent) et un MAG sur chaque eNodeB. Les eNodeB deviennent donc des routeurs IPv6. Les couches de protocoles sur le chemin des paquets de donnes sont reprsentes la gure 3.24. Nous avons utilis les mmes options PMIPv6 que celles utilises dans larchitecture 403.
Application IPv6 PDCP RLC MAC couche physique LTE UE LTE-Uu PDCP IPv6 (PMIPv6) RLC MAC couche physique LTE eNodeB L2 L1 S1-U L2 L1 SGW L2 L1 S5/S8 L2 L1 PGW SGi IPv6 (PMIPv6) IPv6 (PMIPv6) IPv6 (PMIPv6) IPv6 IPv6 IPv6 IPv6

Figure 3.24 Couches de protocoles du plan de donnes dans un EPS suivant larchitecture 404 propose Pour les procdures de compltion 3 de bearer, nous avons ajout un change de PBU/ PBA entre le eNodeB et le SGW pour modier le tunnel au niveau PMIPv6. Les nouveaux
3. Ajout dun service un bearer dj existant.

61 diagrammes de squences sont reprsents aux gures 3.25 et D.1 D.3. Comme pour larchitecture 403 nous avons fait en sorte que la modication du tunnel PMIPv6 se fasse au mme moment que celle du bearer GTP dans larchitecture 23.402 [9]. Le SGW attend de recevoir le PBU et le Update Bearer Response avant de continuer la procdure, de cette faon nous nous assurons que le bearer est modi si et seulement si toutes les informations le concernant sont disponibles sur le SGW (MBR, type, TFT, ARP, etc.).
UE eNodeB MME SGW PGW PCRF SASN SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Control and QoS Rules Provision Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Response Politic SASN Ack Response Politic

Figure 3.25 Compltion de bearer ddi non GBR avec UE QoS unaware De la mme manire les diagrammes de squences des procdures de cration de bearer ddi pour les UE QoS aware et unaware ont t modis et sont reprsents aux gures D.5 et D.6. Le SGW attend la rception du PBU et du message Create Bearer Response avant de continuer. Pour la cration et la compltion de bearer, laction (cration ou modication eective) est eectue en n de procdure car elle est susceptible dtre rejete du fait de la rservation de bande passante. Pour la connexion du UE, nous avons ajout un change PBU/PBA lactivation nale du bearer (voir gure D.4). Tout comme prcdemment, le SGW attend la rception du PBU

62 et du message Create Bearer Response avant de continuer. Les procdures de destruction de bearer reprsentes aux gures 3.26 et D.7, ont t modies pour supprimer le tunnel PMIPv6 au moment o le eNodeB envoie laccus de rception signiant la destruction du bearer radio. La suppression ne se fait pas la rception de la requte mais de la rponse, en eet dans le document 23.401 [8] il est indiqu que le SGW dtruit ses bearers la rception du Delete Bearer Response (dans le cas o lon utilise seulement GTP). Cependant, le bearer entre le SGW et le PGW est supprim au dbut de la procdure car dans le 23.402 [9] il est indiqu que le PGW peut tre noti de la destruction du bearer en mme temps que le SGW. Nous avons donc choisi de parallliser la notication du SGW et du PGW, ce qui implique la suppression du bearer sur le PGW en dbut de procdure. Pour suivre cette logique nous avons choisi de dtruire le tunnel SGW-PGW avant que le SGW ne reoive le message Delete Bearer Response du MME.
UE eNodeB MME SGW PGW PCRF SASN SASN Inform Service Stop Ack SASN Inform Service Stop Gateway Control and QoS Rules Provision Proxy Binding Update (destruction) Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Proxy Binding Update (destruction) Delete Bearer Response Proxy Binding Ack (destruction) Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (destruction)

Figure 3.26 Destruction de bearer ddi avec UE QoS unaware Les procdures de rduction 4 de bearer, reprsentes aux gures D.8 D.11, ont t modies de la mme faon que celle de destruction. La dirence est que les PBU/PBA ne
4. Suppression dun service, PFi dun bearer.

63 contiennent pas une demande de destruction 5 mais de modication de TFT. Ils contiennent donc des options TFT avec un champ PRO x Delete packet lters from existing TFT 6 et des options PFi dsignant les ltres supprimer. Concernant la procdure de relve sans interface X2 et sans changement de SGW reprsente la gure 3.27, plusieurs changements ont t apports. Dans cette gure, les messages en rouge, incluant che et texte, sont ceux ajouts par rapport la procdure de larchitecture 23.402 [9] reprsente la gure B.14. Les messages dont seule la che est en rouge sont ceux qui ont t dplacs. Nous avons dsactiv la possibilit de faire une redirection indirecte car PMIPv6 ne le supporte pas. Le eNodeB source naurait pas t en mesure de dlivrer les paquets arrivs aprs la resynchronisation du UE ce qui aurait pu engendrer des pertes de paquets. Nous avons donc dcid de changer trs tt ladresse de destination des bearers du UE sur le SGW, avant mme la resynchronisation du UE avec le eNodeB de destination. Les paquets arrivant cet eNodeB sont mis en cache comme cest le cas dans les architectures prcdentes ; une fois que le UE est connect au nouveau eNodeB, le cache est vid et le paquet envoy au UE. Pour dplacer le changement dadresse de destination des bearers nous avons dcal lchange de Modify Bearer Request /Response entre le MME et le SGW au moment o le MME reoit le Handover Request Ack du eNodeB de destination. Dans le cas o le Handover Request Ack est ngatif le SGW nest pas noti et la relve nest pas faite. Au moment o le MME reoit le Handover Request Ack celui-ci prend connaissance des bearers conserver et rejeter ; le eNodeB de destination a connaissance de la relve et a prpar un cache pour recevoir les paquets du UE. Il est donc possible de changer le chemin des paquets downlink du UE sur le SGW ce moment. En mme temps une procdure PMIPv6 de cration des nouveaux tunnels entre le eNodeB destination et le SGW, est lance par le eNodeB. Le SGW attend davoir reu le Modify Bearer Request et le PBU pour changer les adresses des bearers, de cette faon nous nous assurons que le SGW possde toutes les informations concernant les bearers. Nous avons aussi choisi de dplacer la procdure de destruction de bearer avec le message Modify Bearer Request car dans la documentation de larchitecture 23.401 [8], son lancement accompagne ce message. Lorsque le UE se dsynchronise du eNodeB source, cet eNodeB envoie un PBU de dconnexion au SGW de faon entriner linformation de dplacement du UE du prcdent PBU envoy par le eNodeB destination. Une fois que le UE est synchronis avec le eNodeB destination, comme pour les architectures 23.401 [8] et 23.402 [9], un compte rebours est lanc la n duquel toutes les ressources associes au UE sont libres sur le eNodeB source.
5. Une demande de destruction de bearer ne contient aucune option TFT, loption Flow Label est susante. 6. Delete packet lters from existing TFT = 5 , si lon prend la norme du document 24.008 [10].

64

UE

eNodeB Source

eNodeB Destination Handover Required

MME

SGW

PGW

PCRF

SASN

Handover Request Handover Failure Handover Preparation Failure Pas assez de bw dans le eNodeB destination ou sur le SGW cot eNodeB destination pour crer le Bearer par default

Proxy Binding Update (connection + bearer) Handover Request Ack Delete Bearer Command Gateway Control and QoS Rules Request SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Gateway Control and QoS Rules Reply Si un bearer t rejet Proxy Binding Update (destruction) Policy and Charging Rules Provision Proxy Binding Ack (destruction) Gateway Control and QoS Rules Ack Policy and Charging Rules Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Modify Bearer Request Proxy Binding Ack (connection + bearer) Modify Bearer Response Handover Command Handover Command Proxy Binding Update (termination) Proxy Binding Ack (termination) Handover Conrm Handover Notify lancement du timer expiration du timer UE Context Release Command UE Release Context Complete

Figure 3.27 S1 Handover

65 Les bearers qui nont pas pu tre ports sur le nouvel eNodeB sont supprims grce la mme procdure que celle utilise dans larchitecture 403. Pour la procdure de relve sans interface X2 avec changement de SGW reprsente la gure 3.28 nous avons ajout un change de PBU/PBA entre le SGW et le PGW lors du dtachement du UE de lancien eNodeB et donc de lancien SGW. Le message Modify Bearer Request est aussi suivi dune procdure de connexion/cration de bearers, entre le SGW et le PGW comme cest le cas lors de ce type de relve dans larchitecture 23.402 [9]. En ce qui concerne la procdure de relve avec interface X2 sans changement de SGW reprsente la gure D.12 la prsence de linterface X2 nous autorise changer le Proxy CoA 7 du UE sur le SGW aprs que celui-ci ait chang de eNodeB. En eet linterface X2 permet de rediriger les paquets directement du eNodeB source vers le eNodeB destination, o ils seront mis en cache en attendant que le UE se resynchronise. Nous avons donc prfr conserver lordre des messages de larchitecture 23.402 [9], ce qui veut dire que les paquets ne sont redirigs vers le eNodeB destination quau moment o le UE se dtache du eNodeB source. Du fait de lajout de PMIPv6 entre le eNodeB et le SGW, nous avons ajout des changes de messages PBU/PBA. Comme pour la procdure de relve prcdente nous y avons ajout un change accompagnant le message Modify Bearer Request pour changer le Proxy CoA des bearers du UE sur le SGW. Un autre, lanc par le eNodeB source en toute n de procdure vient entriner ce changement. La procdure de relve avec interface X2 et changement de SGW est reprsente la gure D.13. Par rapport celle sans changement de SGW, nous avons ajout un change de PBU/PBA de dconnexion entre le SGW source et le PGW au moment o le SGW reoit le PBU de dconnexion du eNodeB source. De cette faon, les tunnels entre ce eNodeB, le SGW et le PGW sont supprims lun aprs lautre. Les messages PBU et PBA entre le SGW destination et le PGW ont t modis pour contenir les informations ncessaires la cration des bearers, cest dire une option TFT par bearer et une liste de PFi. Nous navons pas rattach lenvoi du PBU de dconnexion de lancien SGW la rception du message Delete Session Request comme cest le cas dans larchitecture 403. Nous avons prfr lattacher la rception du PBU de dconnexion du eNodeB source pour rester au niveau PMIPv6. Ce que nous ne pouvions pas faire dans larchitecture 403 tant donn que le lien S1-U tait gr par GTP. Nous avons implment les architectures dcrites prcdemment dans le simulateur NS-2 pour pouvoir les comparer et les avons opposes en fonction des performances du rseau au
7. Adresse de destination des bearers.

66

UE

eNodeB Source

eNodeB Destination Handover Required

MME Source

MME Destination

SGW Source

SGW Destination

PGW

PCRF

Forward Relocation Request Create Session Request Create Session Response Handover Request Proxy Binding Update (connection + bearer) Handover Request Ack procdure de destruction de bearer Modify Bearer Request Proxy Binding Acknowledgement (connection + bearer) Gateway Control Session Establishment Acknowledge Gateway Control Establishment Proxy Binding Update (connection + bearer) Proxy Binding Acknowledgement (connection + bearer) Modify Bearer Response Forward Relocation Response Handover Command Handover Command Proxy Binding Update (termination) Proxy Binding Update (termination) Proxy Binding Ack (termination) Proxy Binding Ack (termination) Handover Conrm Handover Notify Forward Relocation Complete Notication lancement du timer Forward Relocation Complete Acknoledge expiration du timer UE Context Release Command Delete Session Request UE Release Context Complete Gateway Control Session Termination Acknowledge Gateway Control Termination Delete Session Response Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure 3.28 S1 Handover avec changement de SGW

67 niveau du UE. Pour ce faire nous avons recherch quelles seraient les meilleures mtriques utiliser. 3.6 Performance du rseau

Pour comparer ecacement les performances des rseaux simuls nous avons besoin de plusieurs mtriques. Paxson et al. [84] explique les bases dune bonne mtrique rseau, ainsi que quelques caractristiques respecter. Par exemple, pour une unit utilisant les bits, les prxes sont en base dix et non en base deux, e.g. 1 kbits = 1000 bits et non 1024 bits comme cela aurait pu tre le cas dans le domaine des units de stockages. Shalunov et Swany [94] ont proposs, par le biais du working group IP Performance Metrics Working Group (IPPM), plusieurs mtriques destines lutilisateur nal, ces mtriques se veulent simples comprendre et facilement implmentables. Parmi ces mtriques on retrouve : le dlai mdian, dni plus particulirement par Almes et al. [38] ; le taux de perte de paquets, aussi dni par Almes et al. [39] ; ltalement du dlai (delai spread ), tir dun calcul sur le dlai mdian, couramment apparent la gigue (jitter ). Dans les premires versions de notre logiciel, nous avons utilis ces mtriques mais beaucoup de personnes du LARIM et dEricsson se sont tonns de certaines dnitions, entre autre pour la gigue. Certains problmes se posaient avec les mtriques proposes par Shalunov et Swany [94]. En eet ces mtriques nont pas t conues pour sappliquer des types de tracs rels comme nous en avons dans notre simulateur. Beaucoup ncessitent davoir une source de paquets dbit constant, les paquets ayant tous la mme taille, ce qui pose problme, e.g. pour la vido. Lorsque nous avons dcid de r-implmenter le systme de traces de NS-2 comme dcrit la section 4.2.6, nous avons dcid de conserver les types de mtriques dcrites prcdemment, cependant nous en avons choisi au calcul plus simple : le dlai moyen sur un temps donn, sans considration de la taille des paquets.
in

D (t, T ) =
i=i0

d (i)

(3.1)

O D (t, T ) est le dlai moyen au temps t sur la priode T ; d (i) est le dlai du paquet i ; i0 est le premier paquet pass aprs le temps t T et in est le dernier paquet pass avant le temps t.

68 le taux de perte de paquets sur un intervalle de temps donn (voir section 3.6.1). P (t, T ) = np (t, T ) n (t, T ) (3.2)

O P (t, T ) est le taux de perte de paquets au temps t sur la priode T ; np (t, T ) le nombre de paquets passs entre t et t T et perdus ; n (t, T ) le nombre de paquets passs entre t et t T . la gigue, comme dni par Schulzrinne et al. [93] ; nous ne calculons cette mtrique que pour les tracs temps rel (voir section 3.6.2). le dbit (throughput ). in s (i) (3.3) T hroughput (t, T ) = i=i0 T O T hroughput (t, T ) est le dbit au temps t sur la priode T et s (i) est la taille totale du paquet i. le dbit au niveau application (goodput ) ; seulement pour les applications utilisant le protocole TCP, comme les protocoles HyperText Transfer Protocol (HTTP) ou FTP dans notre simulation. Le dbit au niveau application au temps t est gal la somme des bits arrivs la couche application du rcepteur entre les temps t T et t, divise par T . 3.6.1 Le taux de perte de paquets

Nous utilisons le taux de perte de paquets en suivant la dnition de Almes et al. [39, sec 2.4], cest dire que nous ne prenons pas de limite de dlai maximum pour considrer un paquet comme perdu. Un paquet est considr comme perdu si et seulement sil est rejet quelque part dans le rseau. Dans nos simulations nous avons calcul ce taux quentre le SASN et les UE. Nous ne voulions pas que des paquets perdus lextrieur du rseau soient comptabiliss. 3.6.2 La gigue

La gigue est une mtrique assez spciale dans le sens o lon trouve normment de dnitions direntes dans les documents de lIETF. Pour Demichelis et Chimento [58], la gigue est appele IPDV et correspond la dirence entre les one-way-delay (dnie par Almes et al. [38]) des paquets slectionns. Elle est dnie par Shalunov et Swany [94] comme tant la dirence entre le troisime et premier quartile des one-way-delay des paquets slectionns. Nous avons considr que la gigue ntait une mtrique pertinente que dans le cas de

69 tracs temps rel. Nous avons dcid dutiliser la gigue dnie par Schulzrinne et al. [93, sec 6.4.1] qui est utilise par le protocole Real Time Protocol (RTP), spcialement adapt aux tracs temps rel. Pour un paquet i on dnit une valeur de gigue J (i) gale : J (i) = J (i 1) + (|D (i 1, i)| J (i 1)) 16 (3.4)

o D (i 1, i) est le dlai, comme dni par Almes et al. [38], entre le paquet i et le paquet i 1 prcdent. Soit : D (i, j ) = (Rj Sj ) (Ri Si ) lenvoi de ces mmes paquets. (3.5)

o Ri et Rj sont les temps auxquels sont arrivs les paquets i et j , et Si et Sj les temps

70 CHAPITRE 4 VALUATION ET ANALYSE DES PERFORMANCES DES DIFFRENTES ARCHITECTURES

Maintenant que nous avons dtaill les architectures proposes et dj existantes, nous allons analyser leurs performances respectives. Pour ce faire nous devons aussi expliquer le fonctionnement de nos simulateurs et des scnarios utiliss. Dans ce chapitre nous allons donc commencer par dtailler notre premier scnario, peu charg, et nous analyserons les rsultats obtenus sur les quatre architectures 23.401 [8], 23.402 [9], 403 et 404. Nous ferons ensuite de mme pour notre deuxime scnario dans lequel la charge du rseau est plus importante. Dans les deux dernires sections nous dtaillerons limplmentation de nos simulateurs et les techniques utilises pour imiter les principaux protocoles utiliss. 4.1 4.1.1 Rsultats Scnario simple

Pour pouvoir comparer les performances des direntes architectures EPS, nous les avons implmentes dans le simulateur NS-2. Nous avons utilis deux scnarios, le premier est trs basique, il contient un seul UE et deux eNodeB 1 . t = 1s le UE dmarre une communication de voix utilisant le codec GSM (environ 15 Kbps), une seconde plus tard il lance la visualisation dun lm en streaming. Nous avons pris la trace du lm Mr Bean encod en H.264, le codec peut utiliser une compression Low, Medium ou High suivant les performances du rseau (taux de perte de paquets, gigue et dlai). La seconde suivante le UE dmarre son navigateur web et lance une requte HTTP. La dure de vie dune page web a t xe une minute, sa taille 150 Ko et lintervalle entre les requtes 30 secondes. Nous avons choisi des valeurs xes de faon ce que le scnario ne change pas dun simulateur, dune architecture, lautre. Trente secondes aprs stre connect le UE eectue une relve sur le second eNodeB et vingt secondes plus tard, lance un tlchargement FTP. Chaque connexion dure cent secondes. Nous avons cr ce scnario en essayant de runir les principaux types de tracs susceptibles dtre rencontrs sur le EPS. La voix utilise un bearer GBR marqu avec la classe DiServ EF, la vido et le web utilisent des bearers non GBR respectivement marqus AF4 et AF1, le trac FTP passe par
1. Nos simulateurs sont limits de faon statique un MME, un SGW, un PGW, un SASN et un PCRF.

71 le bearer par dfaut marqu avec DF. Le UE est QoS aware ce qui permet de sassurer que les services assigns un bearer rejet ne soient pas lancs. Si le UE tait QoS unaware, les tracs relatifs aux services dont les bearers auraient t rejets passeraient par le bearer par dfaut, ce qui fausserait les rsultats. Nous avons utilis des liens dun gigabit par seconde et dune longueur denviron 300 mtres (1 s de dlai) pour les interfaces S1-U et S1-MME. Tous les autres liens du rseau cur utilisent des interfaces de 10 Gbps. Concernant les distances nous avons considr que le SASN tait dans la mme armoire que le PGW, leur lien nest donc que de quelques mtres (dlai de 10 ns) ; terme le SASN doit tre intgr au PGW. Le MME et le SGW sont proches (de lordre du kilomtre) tout comme le PGW et le PCRF. Mais tant donn la raret des PGW nous avons prfr mettre une grande distance, de lordre de la centaine de kilomtre, entre le PGW et le SGW. Les liens extrieurs au EPS ont t surdimensionns (1 Tbps entre le SASN et le nud core ) pour ne pas reprsenter un goulot dtranglement. Un schma du rseau simul est reprsent la gure 4.1.
MME eNodeB 1 UE eNodeB 2 serveur vido serveur voix serveur FTP serveur web SGW 402,3,4 PGW SASN core PCRF HSS

Figure 4.1 Architecture du rseau simul Les rsultats de ce scnario simple sont prsents lannexe E. On remarque la gure E.1 quil ny a aucun changement en ce qui concerne le dbit. Les dbits des tracs de voix, web et FTP nont pas t reprsents, car ils sont, eux aussi, exactement gaux dune architecture lautre. Le dlai et donc la gigue, ont t calculs entre le SASN et le UE de faon ne pas tre inuencs par la portion du rseau extrieur larchitecture EPS. Pour la mme raison le taux de perte de paquets est calcul entre le SASN et le UE. Le dlai moyen du trac vido reprsent la gure E.2 ne change pas dune architecture lautre, il en va de mme pour les tracs web et FTP. En revanche on remarque que le trac de voix (gure 4.2) a un dlai trs lgrement plus lev (5 s) au dmarrage de la connexion sur larchitecture 23.401 [8] que sur les autres, puis plus bas (de 20 s en moyenne) aprs la relve. En fait il existe aussi un cart de dlai entre la 23.401 [8] et les autres pour les tracs

72 vido, web et FTP mais celui-ci est imperceptible par rapport lamplitude des courbes, il est de lordre de la microseconde.
401 402 403 404 1.52

1.515

dlai en millisecondes

1.51

1.505

1.5

1.495

1.49

1.485 10 20 30 40 50 60 temps en secondes 70 80 90 100

Figure 4.2 Dlai moyen du trac de voix entre le SASN et le UE Cette dirence nest pas due au changement dencapsulation entre les architectures 23.401 [8] et 23.402 [9]. En eet, daprs la gure E.3 reprsentant le dlai entre le SASN et le eNodeB pour le trac de voix, nous remarquons que cest la courbe de la 404 qui sort du groupe. En fait le dcalage observ la gure 4.2 est d aux dirences de temps de connexion et de cration dun bearer ddi. Ce temps est trs similaire voire gal entre les 23.402 [9], 403 et 404 du fait de la paralllisation des messages PMIPv6 avec lancienne signalisation. En revanche la cration de linterface Gxc (SGW-PCRF) a ajout quelques millisecondes ces procdures. Les transferts de donnes ne dmarrent donc pas en mme temps dans larchitecture 23.401 [8] que dans les autres. Le scheduling des bearers radio downlink se faisant toutes les millisecondes sur les eNodeB, un changement du temps de dmarrage de la connexion peut entrainer une variation du dlai, celle-ci tant infrieur une milliseconde. Dailleurs on remarque que la connexion de voix dmarre t = 0.131783 dans larchitecture 23.401 [8] et t = 0.131761 dans toutes les autres, ce qui nous conforte dans notre hypothse. Si on retarde de vingt microsecondes la connexion du UE sur la 23.402 [9] le dlai du trac de voix passe en dessous de 1,5 ms avant la relve. En dcalant la relve de cent microsecondes sur la 23.401 [8] et de 250 microsecondes sur la 23.402 [9] le dlai de 23.401 [8] se maintient au dessus et

73 celui de 23.402 [9] au dessous de 1,5 ms (voir gure 4.3). Une amlioration ou dtrioration du dlai infrieur une milliseconde lorsque le rseau ne comporte que peu de UE ne peut donc pas tre attribu avec certitude au changement darchitecture.
401 402 dcalage de quelques centaines de microsecondes de la relve et de la connexion 1.52

1.515

Dlai en millisecondes

1.51

1.505

1.5

1.495

1.49

1.485 10 20 30 40 50 60 temps en secondes 70 80 90 100

Figure 4.3 Dlai moyen du trac de voix, la connexion et la relve ayant t dcales Certains auront peut-tre remarqu que nous avons coup 2 les graphiques du dlai et de la gigue du trac de voix. Dans nos simulateurs, pour pouvoir dtecter la n dune communication UDP ou RTP, les applications utilisant ces protocoles envoient un paquet spcial de petite taille (20 octets) servant de marqueur de n . Cette technique fonctionne bien pour un trac vido mais le trac de voix est trs stable (son dbit est xe) et utilise des paquets de petites tailles. Le dlai de notre paquet de n vient donc perturber le dlai moyen de la connexion de voix, de plus cette moyenne est calcule toutes les cinq secondes et seulement dix paquets (de voix) sont envoys aprs la centime seconde. Nous navons pas voulu reprsenter cette augmentation brutale de dlai car elle ne traduit en rien une quelconque dgradation de la qualit de la communication. Elle traduit simplement une astuce dimplmentation pour contourner les restrictions intrinsques NS-2. La gigue des tracs vido, web, FTP et voix (reprsente gure E.4) est identique dune architecture lautre. Il en va de mme pour le dbit et le goodput (voir gure E.5). Le taux
2. Normalement ces graphiques vont jusqu t = 105s

74 de perte de paquets est nul (voir gures E.6 et E.7) ce qui nest pas surprenant tant donn que ce scnario ne comporte quun UE. Au tableau 4.1, la seule procdure dont la dure change de plus dune milliseconde est la procdure de destruction de bearer pour les UE QoS aware. Cette perte de performance nest pas relative nos modications tant donn quelle sobserve entre les architectures 23.401 [8] et 23.402 [9]. De plus le temps de destruction dun bearer nest pas une variable critique, le temps de cration dun bearer ou le temps de relve sont beaucoup plus importants. Tableau 4.1 Comparaison des dures des principales procdures entre les architectures dure (en ms) dune cration de destruction bearer de bearer 3.111 3 3.102 5 3.102 5 3.102 5 2.084 2 2.084 2 2.084 2 2.084 2

Architecture 401 402 403 404 401 402 403 404

type aware aware aware aware unaware unaware unaware unaware

connexion 8.101 8.101 8.101 8.101 8.101 8.101 8.101 8.101

relve 500 500 500 500 500 500 500 500

En conclusion, des rsultats de ce premier scnario nous pouvons dire que nos modications napportent pas de changement signicatif des performances par rapport larchitecture 23.402 [9], dans le cas dun rseau faiblement charg. Les performances des 23.401 [8] et 23.402 [9] sont tout fait similaires. On note toutefois que la procdure de destruction prend deux millisecondes de plus dans la 23.402 [9]. Pour tester ces architectures avec une charge plus importante, nous avons dvelopp un nouveau scnario. 4.1.2 Scnario charg

Dans ce nouveau scnario nous avons repris la mme conguration que prcdemment, les liens ont les mmes caractristiques, en revanche le rseau daccs contient dix eNodeB sur lesquels mille UE se connectent (voir gure 4.4). Les UE sont rpartis alatoirement 3 et quitablement entre tous les eNodeB. Par quitablement nous entendons que si le scnario
3. La graine de la squence alatoire est la mme dune architecture lautre.

75 contient n UE et m eNodeB numrots de 1 m alors le eNodeB i possde xi UE avec : xi = o yi =

1 0

n + yi m si i n sinon n m m

(4.1)

Les milles UE se connectent progressivement au rythme dun par seconde. Ils se comportent tous comme celui du premier scnario ; ils lancent successivement une communication VoIP, un trac vido, un trac web et un tlchargement FTP. Ils font une relve trente secondes aprs stre connect.
MME UE 1000 eNodeB 10 SGW PGW SASN core 402,3,4 PCRF HSS

serveur vido

serveur voix

serveur FTP

serveur web

Figure 4.4 Architecture du rseau simul (version charge) Lors des simulations, les architectures 23.402 [9], 403 et 404 se sont comportes exactement de la mme faon en ce qui concerne la gestion des bearers. Tous les UE nayant pas russi se connecter dans larchitecture 23.402 [9] ont aussi t rejet dans la 403 et la 404 et vice versa. Il en va de mme pour les bearers rejets leur cration ou lors dune relve. En revanche quelques divergences sont apparues entre la 23.401 [8] et les autres partir de la 850e seconde. Le UE numro 965 (devant se connecter la 965e seconde) a t accept dans larchitecture 23.401 [8] et rejet dans les autres. Les bearers rservs au trac de voix des UE 847 et 862 ont t rejets lors des procdures de relves (environ aux secondes 880 et 890) dans les 23.402 [9], 403 et 404 et accepts dans la 23.401 [8]. En revanche les bearers des tracs vidos des UE 965 et 902 et le bearer du trac de voix du UE 965 ont t rejets (lors de leur cration) dans la 23.401 [8] et accepts dans les autres. Ces dirences sont dues au paramtrage du scnario plus quaux performances des architectures elles mme, en eet les bearers rservent exactement les mmes bandes passantes dans toutes les architectures. Le temps dexcution des procdures coupl aux instants de lancement de celles-ci font que la

76 conguration du rseau peut tre dirente dune architecture lautre un instant donn. Par exemple un UE qui se connecte peut arriver sur un eNodeB supportant dj dix ou onze UE suivant larchitecture. Beaucoup de facteurs entrent en compte, comme la rapidit dexcution des procdures, le rejet ou lacceptation des prcdents UE et de leurs bearers, linstant de connexion, de relve, etc. tant donn ces divergences, une dirence de performance observe partir de la 850e seconde non incluse (880 pour tre exact) ne peut pas tre impute avec certitude aux modications apportes tant donn que la charge dans le rseau nest plus la mme. Tel que reprsent la gure F.1, le dlai du trac vido est identique dans les direntes architectures, avec une lgre dirence entre la 23.401 [8] et les autres partir de la 900e seconde incluse. Il en va de mme pour les tracs de voix (reprsents la gure F.2), web et FTP. Pour avoir plus de dtails sur ces rsultats nous avons observ le dlai au niveau du eNodeB, les modications portant sur la portion de rseau entre le eNodeB et le PGW. Pour la vido (voir gure F.3), le web et le FTP les courbes se superposent (except un artefact t = 1000). Pour le trac de voix, du fait quil passe par la le DiServ de plus haute priorit, que ses bearers sont GBR et que ses paquets sont de petites tailles, le dlai ne varie que trs peu (de lordre de la microseconde) au cours de la simulation. Lamplitude des courbes est donc moins grande ce qui nous permet de distinguer les trs faibles dirences de dlai entre les architectures. Tel que reprsent la gure F.4, les courbes des 23.402 [9], 403 et 404 sont presque parallles, ce qui peut paraitre normal tant donn que les architectures 403 et 404 sont bases sur la 23.402 [9] et reprennent en grande partie ses diagrammes de squences. Le dlai de la 404 est le plus bas sur 80% du temps que dure la simulation. Cela est d au fait que loverhead des paquets y est moins grand (les paquets sont directement encapsuls dans IPv6). On peut aussi remarquer quen quatre points partir de la 750e seconde, le dlai de la 23.401 [8] est le plus bas (de lordre dune microseconde). Bien quil y ait un lger cart entre ces courbes, celui-ci reste de lordre de la microseconde, ce qui est ngligeable. Les dirences observes sur les courbes des gures F.1 et F.2 sont donc dues au rseau daccs (identique sur toutes les architectures). Concernant le dlai nous pouvons donc dire que les performances des direntes architectures sont identiques. Les dbits sont similaires dune simulation lautre (voir gure F.6). Il en va de mme pour le goodput comme le montre les gures F.7 et F.8. Concernant la gigue (gures F.5 et 4.5) on remarque que, comme pour le dlai, les performances sont identiques entre les architectures 23.402 [9], 403 et 404. En revanche, celles de la 23.401 [8] sont nettement meilleures ; partir de la 650e seconde la gigue du trac vido sur la 23.401 [8] est en moyenne infrieure de

77 3,5 ms par rapport aux autres, avec une dirence maximum de 6,5 ms. Pour le trac de voix, la gigue est en moyenne infrieure de 1,7 ms avec une dirence maximum de 5 ms. Ces divergences surviennent avant la 850e seconde il ny a donc aucun doute sur la supriorit de larchitecture 23.401 [8]. En revanche, la gigue des 403 et 404 ne changent pas par rapport la 23.402 [9], nos modications nont donc pas eu dimpact visible.
401 402 403 404 16 14 12 Gigue en millisecondes 10 8 6 4 2 0 100 200 300 400 500 600 temps en second 700 800 900 1000 1100

Figure 4.5 Gigue du trac de voix entre le SASN et les UE En ce qui concerne le taux de perte de paquets, celui-ci est nul pour les tracs vido, web et FTP comme le montrent les gures F.9 F.11. En revanche celui du trac de voix reprsent la gure 4.6 est non nul et atteint un maximum de 1 % au dbut du scnario (150e seconde) pour les 23.402 [9], 403 et 404. Selon Wallingford [100, chap. 9], un rseau de VoIP ne doit pas sourir dun taux de perte de paquets suprieur 1 %, nous sommes donc la limite de lacceptable. Une augmentation des caches des bearers GBR associs au trac de voix serait envisager sur ces architectures. En revanche le taux de perte de paquets ne dpasse jamais les 0,25 % dans la 23.401 [8], mme sil est suprieur celui des autres entre la 500e et la 850e seconde. Si lon compare les architectures 23.402 [9], 403 et 404 nous observons que les 403 et 404 perdent lgrement moins de paquets lors des pics de pertes ; mais cela reste ngligeable (environ 0,02 % de dirence). Nous pouvons donc dire que nos modications naectent pas les performances du rseau en ce qui concerne le taux de perte de paquets et que les

78
401 402 403 404 1

Taux de pertes de paquets en %

0.8

0.6

0.4

0.2

0 100 200 300 400 500 600 temps en second 700 800 900 1000 1100

Figure 4.6 Taux de perte de paquets global du trac de voix entre le SASN et les UE performances de larchitecture 23.401 [8] sont meilleures que celles des autres. 4.1.3 Synthse

Ces rsultats nous indiquent que les modications que nous avons apportes larchitecture 23.402 [9] dans 403 et 404 nont pas ou trs peu aect les performances du rseau au niveau du UE. Les faibles dirences entre les 23.402 [9], 403 et 404 tant des amliorations en faveur de la 403 et la 404. Il semble que larchitecture 23.401 [8] ait de meilleures performances que les autres en ce qui concerne la gigue et le taux de perte de paquets ; celle-ci est donc prfrable pour les oprateurs. Cependant, si pour des raisons politiques loprateur doit abandonner le protocole GTP sur linterface S5/S8, par exemple pour intgrer un rseau daccs WiMAX, nous lui conseillons dutiliser larchitecture 403 voire 404. Celles-ci utilisant de faon plus pousse les avantages dIPv6 que 23.402 [9]. 4.2 Implmentation

Pour valuer limpact de nos propositions nous avons dvelopp quatre simulateurs bass sur NS-2 reprsentant chacun une architecture.

79 4.2.1 Network Simulator version 2

NS-2 est un simulateur de rseau open source, il supporte un nombre considrable de protocoles, mais possde aussi de nombreuses restrictions que nous avons d contourner. Aujourdhui une nouvelle version majeure du simulateur est disponible, Network Simulator version 3 (NS-3) ; elle pallie un grand nombre de dfauts des prcdentes. Malheureusement lorsque NS-3 est arriv maturit nous tions dj trop avanc dans limplmentation de nos simulateurs pour envisager une migration. De plus son architecture est trs dirente de celle des versions prcdentes. NS-2 se base sur les langages de programmations C++ et Object Tool Command Language (OTcl). Le noyau est en C++ et les scnarios 4 sont en OTcl de cette faon une modication du scnario ne ncessite pas une re-compilation du logiciel. Chaque classe OTcl doit avoir une classe correspondante en C++, et chaque instanciation dun objet OTcl entraine la cration dun objet C++. Lide est bonne, mais la liaison entre le C++ et le Tool Command Language (Tcl) entraine une plus grande complexit du code C++ 5 . Dans NS-2 il ny a pas de notion de couche de protocole, il existe des objets de type Application qui sont chargs de gnrer les tracs et des Agent qui simulent toutes les couches infrieures. Lutilisation dApplication nest pas obligatoire, par exemple le trac FTP se rsume lenvoi dun maximum de paquets TCP jusqu la rception dune commande stop , un Agent sut. La gure 4.7 reprsente larchitecture C++ dun nud simple. Dans les sections suivantes nous allons dcrire quelques-unes des classes et mthodes dveloppes dans le cadre de cette matrise. 4.2.2 Plan de contrle

Dans la ralit le plan de contrle est compos de plusieurs protocoles coupls entre eux. Pour simplier notre code et du fait de labsence de couches distinctes dans NS-2 nous navons pas implment ces lments de faon spare. Nous avons cr une application par UE, par eNodeB et par nud du EPC. Ces application sont charges de simuler le comportement de tous les protocoles au-dessus de TCP ou UDP, utiliss sur ces nud. Chacune possde sa propre classe drivant au minimum de ApplicationEPS. Celles grant des bearers drivent de la classe ApplicationBearer. La gure 4.8 reprsente le diagramme de classe de ces applications et des principales classes quelles utilisent. Chaque application possde au moins un Agent lui permettant denvoyer des donnes sur le rseau. Dans le EPC celles de contrle utilisent les protocoles de transport UDP, TCP
4. La dnition des nuds, de la topologie du rseau, des tracs, etc. 5. Dans NS-3 il est possible dcrire le code et les scnario en C++, une liaison avec Python est possible, mais reste optionnelle

80

Figure 4.7 Reprsentation des direntes composantes dun nud dans le simulateur NS-2 (inspir de The VINT Project [97, sec 5.1]) et/ou SCTP. Le protocole SCTP, que nous simulons grce au code du TCP, est dcrit la section 4.3.3. Les Agent UDP et TCP ne peuvent normalement pas envoyer de donnes 6 (UDP le peut, mais avec de nombreuses restrictions) mais simplement un certain nombre doctets, nous avons donc d modier leurs implmentations. Nous avons fait voluer UDP pour quil puisse envoyer des donnes 6 plus grande que la taille maximum dun paquet, simulant ainsi la segmentation au niveau de la couche IP. Comme nous lavons dit un Agent prend en charge toutes les couches de protocoles situes sous lapplication. Nous avons aussi cr une nouvelle classe appele TcpAppAgent drive de lagent TCP standard permettant dutiliser ce protocole pour envoyer des objets C++. Nous lutilisons sur les liens S1-MME, S6a, Gx et Rx. Chaque application possde une mthode process_data dans laquelle aboutissent toutes les donnes 6 reues par ses agents. Dans cette mthode nous faisons un tri des donnes en fonction de leur type (correspondant au nom du message dans la ralit) et nous appliquons les changements qui lui sont relatifs. Par exemple, pour une donne de type PACKET_ENCAPSULE_DATA, le paquet quil contient est extrait, on en dtermine la destination, on le r-encapsule dans une nouvelle donne du mme type et on lenvoie la prochaine application sur le chemin menant cette destination. Une donne de type DELETE_BEARER_REQUEST_DATA dclenchera une procdure de suppression des informations et des objets simulant le comportement du bearer concern sur le nud courant.
6. Par donne jentends ici : objet C++.

81

Figure 4.8 Diagramme des principales classes de notre simulateur (celles que nous avons implmentes)

82 Il existe plusieurs classes permettant de reprsenter des donnes ; les principales tant : BearerManagementData reprsente des donnes de contrle, elle est utilise dans toutes les squences de cration/modication/destruction de bearer. UELocationData reprsente des donnes de localisation du UE (contrle), elle est utilise principalement dans les squences de relve. PacketEncapsuleData reprsente un paquet encapsul, elle est utilise sur le plan de donnes. Ces classes drivent toutes de AppDataExtended ajoutant quelques fonctionnalits la classe AppData de NS-2. Par exemple la rception dune donne, lapplication na pas accs au paquet layant transport, il ny a donc pas de moyen de connatre sa source. Nous avons donc ajout une adresse source dans AppDataExtended pour essayer de pallier ce problme. La gure 4.9 reprsente le diagramme de classe de ces types de donnes.

Figure 4.9 Diagramme des classes reprsentant les donnes changes par les nuds

4.2.3

Service Aware Support Node

Le SASN est un appareil dvelopp par Ericsson permettant deectuer une partie du travail du PCEF et du Application Function (AF). Les paquets qui transitent par le SASN ne sont pas encapsuls et ne lui sont donc pas destins. Comme le PGW en downlink et le UE en uplink, il doit capturer ses paquets an de pourvoir les traiter. Dans le schma

83 reprsent la gure 4.7 nous pouvons remarquer que les paquets ne remontent au niveau des agents que si leur IP de destination est celle du nud courant. Nous avons donc d modier larchitecture du SASN, du PGW et des UE pour permettre la remonte de tous les paquets. Nous dcrivons ici le SASN mais le principe est le mme sur le PGW et le UE. La gure 4.10 donne une vue des objets prsents dans le SASN, les principales classes utilises tant dcrites la gure 4.8.

Figure 4.10 Diagramme dobjet du SASN dans notre simulateur Pour pouvoir capter les paquets downlink et uplink dans le SASN nous avons modi la classe Classifier. De base, les Classifier, reprsentant les tables de routage des nuds, sont statiques ou dynamiques. Nous nutilisons pas de protocole de routage particulier, nous devons donc utiliser des Classifier statiques. Ceux-ci se congurent soit manuellement soit automatiquement (en utilisant lalgorithme de Dijkstra [60]), mais il nexiste pas de mthode semi-automatique . Nous avons donc ajout quelques fonctions pour permettre la modication des routes dun classier statique automatique. Dsormais les tables de routage se calculent automatiquement grce lalgorithme de Dijkstra [60], puis les modications apportes manuellement par lutilisateur viennent changer les routes. Nous avons par exemple redirig les sorties du Classifier pointant vers les liens SASN-PGW et SASN-extrieur respectivement vers des objets de type Connector_SASN_DL et Connector_SASN_UL. Nous avons aussi fait en sorte que les paquets de donnes ne passent ni par le PCRF ni par le MME. Les Connector du SASN marquent les paquets et appliquent des limiteurs de bande passante en fonction du type de trac et du UE. Ils dtectent aussi les nouvelles connexions et avertissent le PCRF via lapplication ApplicationSASN et les TcpAppAgent.

84 4.2.4 Bearers

Pour reprsenter les bearers au niveau application sur les nuds du plan de donnes nous avons cr les classes GBR_Bearer et Non_GBR_Bearer schmatises la gure 4.11. De faon basique elles mettent en cache les paquets en attendant leur envoi sur le lien. La classe GBR_Bearer envoie elle mme les paquets et sassure que son dbit de sortie nexcde pas le MBR du bearer. Pour cela elle utilise une le spciale appele MBR_queue qui programme lenvoi du paquet suivant en fonction du MBR et de la taille du dernier paquet sorti.

Figure 4.11 Diagramme des classes reprsentant les bearers de notre simulateur En vrit les objets de type GBR_Bearer utilisent des les Protected_MBR_queue tendant les fonctionnalits des MBR_queue. Une le Protected_MBR_queue possde la capacit, si elle est correctement utilise, dempcher la destruction de lobjet auquel elle est rattache (en loccurrence un objet de type GBR_Bearer) tant quelle contient des paquets. Cette fonctionnalit nous est utile pour empcher les pertes de paquets lors dune destruction de bearer d un handover. On peut dtruire un bearer sur une application, celle-ci na alors plus aucun lien avec ce bearer, sans que celui-ci soit eectivement dtruit. Comme lapplication ne connait plus le bearer celui-ci ne reoit plus de nouveau paquet, mais continue de se vider tant donn quil dcide lui mme quand envoyer ses paquets. Lorsquil a envoy tous ses paquets il sauto-dtruit. Les objets de type GBR_Bearer dcident eux-mmes du moment o envoyer leurs paquets tant donn quils possdent leur propre MBR. Ce nest pas le cas des objets Non_GBR_Bearer qui partagent un mme AMBR, nous avons donc d crer une classe AMBR_scheduler eec-

85 tuant la manire de DiServ un DWBBRR sur les bearers dun mme UE. Ce fonctionnement est schmatis la gure 4.12. Les bearers non GBR nont pas de MBR ils nont donc pas besoin de les spciales comme MBR_queue, ils utilisent donc la classe PacketQueue de NS-2.

Figure 4.12 Diagramme dobjet reprsentant le scheduling des bearers

4.2.5

Rseau radio

Sur le rseau radio les bearers sont dirents de ceux du EPC, il ny a plus de GBR ou non GBR. Le eNodeB gre le scheduling des bearers en downlink et le scheduling des UE 7 en uplink, les UE grent le scheduling de leurs propre bearers en uplink. Ces mthode de scheduling ne sont pas spcies par 3GPP ; cependant Dahlman et al. [54, sec. 15.2.2] dcrivent de faon gnrale un algorithme de services des bearers sur les UE. Pour notre part nous avons choisi dappliquer lalgorithme dcrit par Dahlman et al. [54, sec. 15.2.2]. Chaque bearer Radio Access Network (RAN) possde une priorit ainsi quun dbit prfr. Le scheduler sert dabord le bearer ayant la plus haute priorit jusqu ce que celui-ci ait atteint son dbit prfr ou quil nait plus de paquet transmettre, ensuite il sert de la mme faon le bearer suivant par ordre de priorit. Lorsque tous les bearers ont atteint leur dbit prfr le scheduler sert le bearer de plus haute priorit jusqu ce quil nait plus de paquet et continue avec les bearers suivants par ordre de priorit. Le scheduling des UE en downlink et uplink se fait de faon optimiser lutilisation des ressources du eNodeB tout en assurant quaucun des UE ne soit privilgi. Ces ressources sont rparties quitablement entre tous les UE, celles non utilises par un UE sont redistribues quitablement entre tous les autres. La gure 4.13 prsente les direntes classes utilises pour reprsenter le rseau RAN. Nous avons cr la classe RAN_scheduler_global pour grer le scheduling des UE, chaque
7. Le eNodeB ne gre pas le scheduling des bearers des UE en uplink.

86 eNodeB possde deux objets de ce type, un pour le scheduling uplink et un autre pour le downlink. La procdure utilise par les RAN_scheduler_global pour servir les UE est dcrite lalgorithme 1. Chaque lien UE-eNodeB possde un RAN_scheduler_UL et un RAN_scheduler_DL grant le scheduling des bearers.

Figure 4.13 Diagramme des classes utilises dans la simulation du lien radio Les objets de type RAN_scheduler_UL et RAN_scheduler_DL possdent respectivement des RAN_bearer_UL et RAN_bearer_DL. La procdure utilise par les RAN_scheduler pour servir les bearers est dcrite de faon basique grce lalgorithme 2. La raison pour laquelle nous avons deux types de RAN_scheduler et RAN_bearer est que le eNodeB doit appliquer un AMBR aux bearers downlink. Les classes RAN_scheduler_DL et RAN_bearer_DL possdent donc des attributs supplmentaires pour sassurer que le trac issu des bearers non GBR du EPC nexcde pas le AMBR autoris 8 . 4.2.6 Traces

De base, NS-2 fournit quelques modules de traces permettant de gnrer les rsultats des simulations. Lun des modules permet de gnrer une trace exploitable par le logiciel nam utilis pour visualiser les paquets sur le rseau. Lautre module facilement exploitable permet denregistrer des informations sur les paquets passant dans une de ces traces. Ces informations regroupent, entre autre :
8. Nous aurions d implmenter cette fonctionnalit dans lapplication du eNodeB mais cela aurait t plus compliqu sans changer le comportement global du nud.

87

Algorithme 1 Scheduler utilis sur le RAN pour distribuer la bande passante entre les UE nombre de time slote total nb_time_slot_per _UE = nombre de UE surplus_total = 0 Pour tout UE faire servir le UE avec nb_time_slot_per _UE time slot surplus = nombre de time slot non consomm par le UE Si surplus > 0 alors surplus_total = surplus_total + surplus Sinon Si UE veut plus de time slot alors marquer le UE comme non rassasi Fin Si Fin Pour Tant que reste des UE non rassasis et surplus_total = 0 faire surplus_total nb_time_slot_per _UE = nombre de UE surplus_total = 0 Pour tout UE non rassasi faire servir le UE avec nb_time_slot_per _UE time slot surplus = nombre de time slot non consomm par le UE Si surplus >= 0 alors surplus_total = surplus_total + surplus marquer le UE comme rassasi Fin Si Fin Pour Fin Tant que

Algorithme 2 Scheduler utilis sur le RAN pour servir les bearers le RAN_scheduler_global fournit nb_time_slot time slot nb_bits_restant = quivalant de nb_time_slot time slot en bits /*tous les bearers sont limits leur dbit prfr*/ Pour tout bearers par ordre de priorit faire servir le bearer avec nb_bits_restant nb_bits_restant = nombre de time slot non consomm par le UE Fin Pour Si au moins un bearer non vide et nb_bits_restant > 0 alors activer le dpassement des dbits prfrs sur le bearer Pour tout bearers par ordre de priorit faire servir le bearer avec nb_bits_restant nb_bits_restant = nombre de time slot non consomm par le UE Fin Pour Fin Si retourner nb_bits_restant converti en time slot

88 lheure de passage ; la trace ayant enregistr linformation ; la taille du paquet ; la taille totale de ses en-ttes ; le type de trac ; la source et la destination du paquet. En plaant des traces dans les liens comme reprsent la gure 4.14 il est possible, grce au chier gnr, de retracer le parcours de chaque paquet et calculer les mtriques recherches. Cependant, cette mthode nest pas trs ecace selon nous, car elle require un long travail danalyse de chiers de traces pouvant avoir des tailles suprieures au giga.

Figure 4.14 Reprsentation des direntes composantes dun lien dans le simulateur NS-2 (inspir de The VINT Project [97, chap 6]) Dans un premier temps nous avons essay dutiliser ces chiers de traces brutes avec un programme crit en Ruby. Celui-ci permettait de calculer le dlai, le dbit, le goodputs ou les gigues dun trac en particulier ou de tout le rseau. Il tait fonctionnel mais trs lent tant donn la quantit de donnes mettre en relation. Lorsquil a fallu lancer des simulations de plusieurs centaines de UE nous avons dcid de crer un nouveau systme de traces permettant de calculer directement quelques mtriques de performances (les mmes que celles de lancien logiciel Ruby). Nous nous sommes inspirs de larchitecture des traces dj prsentes pour crer les classes reprsentes la gure 4.15 et notamment TracePerso. Chaque paquet passant par un objet TracePerso est enregistr dans un chier la manire de lancien module. Les enregistrements ont t pur et la classe utilise la nouvelle interface C++ ofstream au lieu dune interface Tcl ce qui rend le code plus simple. La classe TracePerso_Send doit tre utilise la sortie du nud source. Elle marque les paquets avec le temps courant et une liste de Trace_Computer_Loss pour permettre un calcul du dlai et du taux de perte de paquets, plus simple. La classe TracePerso_Recv doit tre utilise la sortie du lien juste avant la destination. Elle calcule le dlai des paquets grce

89

Figure 4.15 Diagramme des classes gnrant les traces au marquage laiss par TracePerso_Send et leurs retire les listes de Trace_Computer_Loss notier en cas de destruction. Chaque objet de type TracePerso possde une liste de Trace_Computer quil notie lors du passage dun paquet. Les Trace_Computer sont chargs de calculer durant la simulation les mtriques implmentes. Parmi les Trace_Computer, Trace_Computer_Loss et Trace_Computer_Goodput sont un peu spciales. Trace_Computer_Loss comme son nom lindique, permet de calculer le taux de perte de paquets. La technique utilise habituellement dans NS-2 consiste placer une trace chaque endroit o un paquet peut tre rejet, ce qui ore lavantage de donner lemplacement du rejet. Mais cela devient problmatique lorsque le nombre de ces endroits est grand ou quils nont pas t prvu pour accueillir une trace. Nous avons donc opt pour une autre approche, les TracePerso_Send possdent une liste de Trace_Computer_Loss, chaque paquet est marqu avec cette liste. Les TracePerso_Recv retirent cette marque. Lorsquun paquet nest plus utilis, par exemple parce quil est arriv destination ou quil a t rejet, les rgles de NS-2 font que la mthode static Packet::free est appele sur celui-ci. Nous avons donc modi cette mthode ; si le paquet est marqu avec une liste de Trace_Computer_Loss tous les lments de cette liste sont notis. Donc si un paquet passant par un TracePerso_Send est dtruit avant datteindre le TracePerso_Recv les Trace_Computer_Loss du TracePerso_Send en seront informs et le paquet sera considr

90 comme perdu. Les Trace_Computer_Goodput sapparentent aux Trace_Computer_Throughput mais se placent au niveau application, cest le seul type de Trace_Computer qui nest pas rattach une TracePerso. Elle sattache un agent TCP (que nous avons modi) et est noti chaque remonte dinformation de lagent vers lapplication. 4.2.7 Dierentiated Services

Dans les spcications de 3GPP la mthode utiliser pour appliquer la QoS requise par les QCI nest pas dnie. Il est tout de mme fait mention de DiServ comme exemple. Le fonctionnement de DiServ est dtaill la section 2.3. NS-2 possde certains modules permettant de simuler son comportement mais ne dispose pas de scheduler grant les les WFQ, DRR, LLQ ou DRR. Nous avons bien trouv un de ces schedulers sur Internet mais son fonctionnement ne nous a pas paru correct. Nous avons donc dcid de crer notre propre scheduler comprenant cinq les gres par lalgorithme DWBBRR, et deux les PRIO. Parmi les les gres par DWBBRR quatre sont pour les classes AF et une pour le DF. Une des les PRIO est utilise pour le trac EF et lautre pour le trac de contrle. Nous avons choisi lalgorithme DWBBRR car il simule le BBRR au mme titre que WFQ, tout en tant plus simple implmenter. Contrairement ce quon pourrait penser, dans NS-2 les modules permettant de simuler DiServ se trouvent dans les liens, comme reprsent la gure 4.14. Dans la suite de cette section nous allons dtailler le fonctionnement de lalgorithme de scheduling que nous avons implment. Ce scheduling intervient lorsquun paquet peut tre envoy sur le lien, cest dire lorsque linterface a ni denvoyer le dernier paquet ou lorsquun nouveau arrive dans le module DiServ et quaucun paquet nest entrain dtre transmis. Lorsque notre scheduler est appel il vrie dabord si la le PRIO rserve au trac de contrle du rseau est vide. Si ce nest pas le cas, il la sert (envoi le premier paquet) sans autre considration. Si la premire le PRIO est vide alors il ritre lopration sur la seconde (utilise pour le trac EF). Si les deux sont vides alors il peut lancer le scheduler DWBBRR sur les autres. Nous navons pas implment lalgorithme DWBBRR en utilisant le pseudo code de Shreedhar et Varghese [95] car cela aurait t trop gourmand en CPU. DWBBRR dans sa version basique, consiste servir tour tour chaque le avec n bits, n correspondant au poids de la le. Lalgorithme sarrte lorsque quune dentre elles a reu assez de bits pour envoyer son paquet de tte (nombre de bits reus est suprieur ou gal la taille du paquet). Celles qui sont vides ne sont pas servies et ne conservent pas leurs bits (reste de lenvoi dun paquet). Lalgorithme conserve en mmoire la dernire le quil a servi et repart au niveau de

91 la suivante lorsquil est relanc ; il ne repart pas de la premire le chaque fois quil envoie un paquet. Nous avons implment notre algorithme de faon ce quil se comporte exactement comme la version basique de DWBBRR dcrite ci-dessus tout en limitant la charge CPU. Nous limitons lalgorithme trois oprations par le : un tour de lecture, un tour dcriture et un tour (non complet) dcriture. Tout dabord nous parcourons toute la liste pour dterminer pour chaque le le nombre de services ncessaires lenvoi du paquet de tte. Par la mme occasion nous dterminons le nombre de tours minimum n eectuer pour envoyer un paquet. Nous servons chaque le avec (n 1) Pi bits, Pi tant le poids de la le courante ; de cette faon nous simulons lexcution de n 1 tours. Le dernier tour est eectu de faon basique, cest dire que lalgorithme sert (alloue Pi bits) tour tour les les. La premire servie, tant celle suivant la le ayant envoy un paquet la dernire excution. Il sarrte lorsquune dentre elles possde assez de bits pour envoyer un paquet. Le pseudo code de la procdure de slection dun paquet dans les les gres par le scheduler DWBBRR est reprsent lalgorithme 3. Dans ce pseudo code chaque le contient une liste de paquets en attente et le nombre de bits qui lui ont dj t attribus. La fonction nextpkt retourne le paquet de tte 9 de la liste des paquets dune le. La fonction size retourne la taille dun paquet en bits. La fonction alreadyserved retourne le nombre de bits qui ont dj t attribus une le. La fonction weight donne le poids dune le. lastQ dsigne la le par laquelle est sorti le dernier paquet. 4.3 Protocoles Dans notre rseau les applications schangent des messages de contrle pour connecter les UE, crer/modier/dtruire des bearers ou pour faire des relves. Ces procdures sont reprsentes dans les annexes A D. La plupart des messages utiliss proviennent de GTP-C, Diameter, S1 Application Protocol (S1-AP), NAS ou PMIPv6. Les protocoles de transport sont principalement UDP, TCP, et SCTP. Dans cette section nous allons dcrire comment nous avons simul quelques uns des principaux protocoles du rseau. 4.3.1 GTP

Pour simuler le protocole GTP nous nous sommes bass sur le code dUDP en adaptant la taille des en-ttes et des paquets. Dans les applications nous avons ensuite dni la taille
9. Le paquet de tte dune le est celui qui doit partir en premier.

92

Algorithme 3 Slection du paquet sortant par notre algorithme DWBBRR 1: Si toutes les les sont vides alors 2: on arrte l 3: Fin Si 4: /*on calcule le nombre minimum de tours eectuer par un WBBRR basique pour servir un paquet*/ 5: min_nombre_tour = 6: Pour tout le non vide faire size (nextpkt (f ile)) alreadyserved (f ile) 7: nombre_tour = weight (f ile) 8: Si nombre_tour < min_nombre_tour alors 9: min_nombre_tour = nombre_tour 10: Fin Si 11: Fin Pour 12: /*on simule lexcution de min_nombre_tour 1 tours*/ 13: Si min_nombre_tour > 1 alors 14: Pour tout le non vide faire 15: alreadyserved (f ile) + = (min_nombre_tour 1) weight (f ile) 16: Fin Pour 17: Fin Si 18: /*on eectue le dernier tour*/ 19: f ile = lastQ 20: Boucle innie 21: f ile devient sa le non vide suivante 22: alreadyserved (f ile) + = weight (f ile)/*on sert la le*/ 23: Si size (nextpkt (f ile)) alreadyserved (f ile) alors 24: supprimer nextpkt (f ile) de f ile et le sauvegarder dans paquet_tmp 25: Si f ile est non vide alors 26: alreadyserved (f ile) = size (nextpkt (f ile)) 27: Sinon 28: alreadyserved (f ile) = 0 29: Fin Si 30: lastQ = f ile 31: retourner paquet_tmp 32: Fin Si 33: Fin Boucle innie

93 des messages envoyer sur le rseau en fonction des informations contenues dans ceux-ci. La plupart des messages GTP sont dcrits dans le document 29.274 [22]. Les paquets GTP-U possdent len-tte reprsent la gure 3.4 dans lequel est encapsul le paquet de donnes. Cet en-tte fait 16 octets nous avons donc ajout cette taille len-tte UDP pour simuler GTP-U. Les paquets GTP-C possdent len-tte de 12 octets reprsents la gure 3.5, nous avons donc ajout cette taille celle de len-tte UDP pour simuler ce protocole. Les messages GTP-C (GTP-C PDU) encapsulent des blocs dinformations appels IE. Chaque IE possde un en-tte reprsent la gure 3.6 ainsi que des informations spciques. Pour chaque message GTP-C simul nous avons cherch les IE utiliss ou susceptibles de ltre pour dterminer sa taille. Les tailles des IE utiliss sont reprsentes dans les tableaux G.1 et G.2. Dans lannexe G nous dtaillons les tailles des messages du protocole GTP-C (ces tailles incluent les 12 octets de len-tte). 4.3.2 Diameter

Diameter se base sur les protocoles de transport TCP ou SCTP. Dans notre simulateur, bien quil existe une implmentation de SCTP nous ne lavons pas utilis car elle ne permet pas la transmission de donnes et la modier aurait t trop complexe (cf. section 4.3.3). Nous avons donc simul Diameter grce des agents TCP envoyant des messages de taille pr-calcule. Un message Diameter se compose dun en-tte standard et de nombreux sous messages, appels AVP, eux-mmes composs dun en-tte et de donnes (pouvant tre composes dautres AVP). La taille dun AVP (donnes + en-tte) est toujours un multiple de 4 octets. Dans lannexe H nous dnissons la taille de chacun des messages Diameter que nous avons utilis dans nos simulations. Celles-ci ont t calcules partir du tableau H.1 gnr grce Rigney et al. [92], Calhoun et al. [48], Loughney [74], Calhoun et al. [49] et Hakala et al. [66] et des documents 23.003 [2], 23.011 [3], 24.008 [10], 29.002 [15], 29.060 [16], 29.061 [17], 29.212 [18], 29.214 [19], 29.229 [20], 29.272 [21], 29.274 [22], 29.329 [25], 32.298 [26], 32.299 [27] et 32.422 [28]. 4.3.3 SCTP

SCTP, dni par Stewart [96], est un protocole de transport assez rcent (2000) par rapport TCP (1981) et UDP (1980). Il a t dvelopp dans le but de pallier aux imperfections de ces deux protocoles, il inclut donc plus de fonctionnalits et est plus tolrant aux pannes. Il est utilis notamment sur les interfaces S6a et S1-MME, respectivement pour le transport des messages Diameter et S1-AP.

94 Pour Olsson et al. [81] SCTP comme TCP ore une transmission sre, les donnes sont assures darriver au niveau application de destination sans erreur. Ce sont des protocoles orients connexion mais SCTP utilise une mthode de cration de session en quatre tapes, contrairement TCP qui utilise une mthode en trois tapes. SCTP utilise aussi une fonction dadaptation de la bande passante semblable celle du TCP. En revanche, il incorpore une mthode de gestion de message, ce que TCP 10 ne possde pas contrairement UDP, cest dire que le protocole lui mme spare les messages envoyer lapplication. En TCP, une session peut tre vue comme un canal sur lequel on peut faire passer un ot de bits, cest lapplication dimplmenter ses propres marqueurs de dbut et de n de message. SCTP permet aussi de faire du multi-streaming et du multi-homing, mais ces fonctionnalits ne nous intressent pas pour nos simulateurs. Un rsum des dirences et similarits importantes nos yeux est reprsent au tableau 4.2. Tableau 4.2 Comparaison entre SCTP, TCP et UDP (inspir de Olsson et al. [81]) Orient connection Transport sure Gestion des messages Respect de lordre des messages Non respect de lordre des messages Contrle de ux et de congestion Multi-streaming Multi-homing SCTP Oui Oui Oui Oui Oui Oui Oui Oui TCP Oui Oui Non Oui Non Oui Non Non UDP Non Non Oui Non Oui Non Non Non

Nous avons choisi dutiliser le code de TCP pour simuler SCTP. En eet, nous ne nous servons ni du multi-streaming, ni du multi-homing. Les seules dirences importantes pour nous sont la taille des paquets et le nombre dtapes linitialisation des connexions. Dans NS-2 il est facile de modier la taille des en-ttes dun protocole, le problme de la taille des paquets ne se pose donc pas. Concernant le problme du nombre dtapes lors des connexions nous ne faisons quune seule connexion au dmarrage du simulateur, par laquelle passe toutes nos donnes. Nous avons donc une priode de mise en place du rseau, qui ninuence pas le comportement des connexions par la suite. Nos rsultats ne dpendent donc pas de cette phase, ds lors le fait davoir des initialisations en quatre ou trois tapes importe peu. Tout comme pour Diameter ou GTP, len-tte SCTP se compose dune partie commune tous les paquets et de chunks (voir gure 4.16), ces chunks pouvant transporter des donnes ou des informations de contrles. Les deux en-ttes de chunk importants pour nous, cest
10. Nos modications sur le protocole TCP pour permettre la transmission de donnes font que celui-ci spare lui-mme les messages sur la destination.

95 dire celui de transport de donnes et celui dacquittement sont reprsents la gure 4.17 ; len-tte complet dun paquet SCTP pour le passage de donnes fait 28 octets, les acquittements faisant quant eux 32 octets. En fait, les acquittements sont de tailles variables mais inclure cette caractristique dans NS-2 aurait t trop complique, nous avons donc choisi de simuler des acquittements SCTP comportant un Gap Ack Block 11 et aucun Duplicate Transmission Sequence Numbers (TSN) 12 . Nous navons pas mis de TSN car nous nutilisons quun seul chemin pour les paquets.
0 8 Source Port 32 Verication Tag 64 Checksum 96 Chuncks 32 Chunck Value 16 24 Destination Port 32 0 Chunk Type 8 Chunk Flags 16 24 Chunk Length 32

(a) En-tte commun du protocole SCTP

(b) En-tte de chunk du protocole SCTP

Figure 4.16 En-tte du protocole SCTP (inspir de Olsson et al. [81])

4.3.4

NAS

Le protocole NAS, dni dans le document 24.301 [11], se situe sur la couche NAS entre le UE et le MME, il est charg de la gestion de la mobilit et des sessions dans cette partie du rseau. Il peut se diviser en deux sous parties, le EPS Session Management (ESM) et le EPS Mobility Management (EMM) ; le ESM grant les bearers et le EMM la mobilit. Ce protocole sinsre au dessus de S1-AP entre le eNodeB et le MME, et RRC entre le UE et le eNodeB. Pour nos simulations seule la taille des paquets qui transitent est importante, nous nous sommes donc intresss aux en-ttes du protocole NAS. Un en-tte commun tous les messages NAS est reprsent la gure 4.18, mais sa taille est variable (1 3 octets). Le plus simple est de direntier les en-ttes NAS en deux catgories : celles utilises par ESM et celles utilises par EMM. En eet, comme lindiquent les gures 4.19 et 4.20, on peut considrer que les paquets ESM ont des en-ttes de 3 octets tandis que les paquets EMM ont des en-ttes de 2 octets excepts les Service Request avec 1 octet. Outre ces en-ttes communs, dans chaque paquet NAS sont incorpors dirents IE dont les tailles sont dnies dans le document 24.301 [11].
11. Un Gap Ack Block traduit lacquittement dun paquet arriv aprs la perte dun paquet. 12. Un Duplicate TSN informe la source de la duplication dun paquet.

96

0 Type = 3

8 Chunk Flags

16

24 Chunk Length Advertised Receiver Window Credit Number of Duplicate TSNs =D Gap Ack Block n 1 End

32

Cumulative TSN Acknowledgement 0 Type = 0 32 64 Stream Identier 96 Payload Protocol Identier 128 Data Gap Ack Block n G Start Stream Sequence Number ... 8 Reserved + Flags TSN 16 24 Chunk Length 32 Number of Gap Ack Blocks =G Gap Ack Block n 1 Start

Gap Ack Block n G End

Duplication TSN 1

...

Duplication TSN D

(a) passage de donnes

(b) acquittement

Figure 4.17 En-tte des chunks de passage de donnes et dacquittement du protocole SCTP (inspir de Olsson et al. [81])
0 8 Protocol discriminator 32 PTI 64 Message Type 96 Other Information Elements as required 16 24 EBI or Security Header Type 32

Figure 4.18 En-tte commun tous les paquets NAS (inspir de 24.301 [11])

8 Protocol discriminator

16

24 EBI

32 0 8 Protocol discriminator 32 16 24 Security Header Type 32

32 PTI 64 Message Type 96 Other Information Elements as required

Security Parameters and Message Authentication Information

(a) En-tte normal

(b) En-tte spcique au Service Request

Figure 4.19 En-ttes relatifs ESM dans le protocole NAS (inspir de Olsson et al. [81])

97
0 8 Protocol discriminator 32 Message Type 64 Other Information Elements as required 16 24 Security Header Type 32

Figure 4.20 En-tte relatif EMM dans le protocole NAS (inspir de Olsson et al. [81]) 4.3.5 S1-AP

S1-AP nest utilis que sur linterface S1-MME (cf. gure 2.10), il permet de transporter les messages du protocole NAS (dialogue entre le UE et le MME) et de faire communiquer le eNodeB avec le MME. Malheureusement pour nous, bien que le document 36.413 [34] dnisse les IE du protocole, leur utilit et toutes les procdures, il ne dnit pas le format des messages. Nous navons donc pas pu calculer la taille de ses messages. 4.3.6 Proxy Mobile IPv6

Tous les paquets de contrle PMIPv6 contiennent un en-tte IPv6 classique reprsent la gure 3.18 et un mobility header schmatis la gure 4.21. Un mobility header doit avoir une taille multiple de huit octets [72, sec 6.1.1]. Le tableau 4.3 liste les options que nous avons utilises. Par la suite nous dtaillons et calculons la taille des dirents messages de contrle que nous avons utiliss.
0 8 16 MH Type 24 Reserved 32

Payload Proto Header Length 32 Checksum

Message Data. . .

Figure 4.21 Format des donnes contenues dans un paquet de contrle PMIPv6 (Mobility Header [72, sec 6.1.1])

Proxy Binding Update (connexion dun UE) Le PBU est dni par Gundavelli et al. [65, sec 6.9.1.5], son en-tte est reprsent la gure 4.22, il contient : une option Mobile Node Identier reprsente la gure 4.25 ;

98 Tableau 4.3 Taille des options du protocole PMIPv6 options Mobile Node Identier Prex Information Hando Indicator Access Technology Type Service Flow Identier Service Flow Description GRE Key Flow Label taille en octets 3 + Identier 32 4 4 8 + Service Flow Description variable 8 8 notes nous avons pris comme identier le IMSI (12 octets [22])

au moins une option Home Network Prex de type Prex Information reprsente la gure 4.26 ; une option Hando Indicator reprsente la gure 4.24 ; une option Access Technology Type reprsente la gure 4.23 ; une option Timestamp, optionnelle ; une option Mobile Node Link-layer Identier, optionnelle ; une option Link-local Address, optionnelle. La gure 4.27 schmatise les donnes transportes par les paquets IPv6 que nous avons utilises, leur taille total est de 72 octets. 544 8 = 72 82
0 8 16 24 Sequence number 32 A H L KMR P 64 Mobility Options 96 Reserved Lifetime 32

(4.2)

Figure 4.22 En-tte dun message Proxy Binding Update (inspir de Gundavelli et al. [65, sec 8.1]) Dans notre modle (dans les architectures 403 et 404), nous devons ajouter loption Flow Label que nous avons dnie et schmatise la gure 3.21, celle-ci est inspire de loption

99

0 Type 32

8 Length

16 Reserved (R)

24 ATT

32

Figure 4.23 Option Access Technology Type de PMIPv6 [65, sec 8.5]

0 Type 32

8 Length

16 Reserved (R)

24 HI

32

Figure 4.24 Option Hando Indicator de PMIPv6 [65, sec 8.4]

16

24

32

Option Type Option Length 32 Subtype 64 Identier. . .

Figure 4.25 Option Mobile Node Identier de PMIPv6 [82, sec 3]

0 Type 32

8 Length

16

24

32

Prex Length L A Reserved1

Valid Lifetime 64 Preferred Lifetime 96 Reserved2 128

Prex

256

Figure 4.26 Option Prex Information de PMIPv6 [79, sec 4.6.2]

100

16 MH Type

24 Reserved

32

Payload Proto Header Length 32 Checksum 64 A H L KMR P 96 Type 128 Length Reserved

Sequence number Lifetime Prex Length L A Reserved1

Valid Lifetime 160 Preferred Lifetime 192 Reserved2 224

Prex

352 Type 384 Type 416 Option Type Option Length 448 Subtype Identier Length Reserved (R) ATT Length Reserved (R) HI

Identier

544 Padding 576

Figure 4.27 Proxy Binding Update utilis (inspir de Gundavelli et al. [65, sec 8.1])

101 GRE key dnie par Muhanna et al. [78]. La taille totale du PBU slve donc 80 octets : 544 + 64 8 = 80 82 Proxy Binding Acknowledgement (connexion dun UE) Le PBA est dnie dans Gundavelli et al. [65, sec 5.3.6] il contient : une option Mobile Node Identier reprsente la gure 4.25 ; au moins une option Home Network Prex de type Prex Information reprsente la gure 4.26 ; une option Hando Indicator reprsente la gure 4.24 ; une option Access Technology Type reprsente la gure 4.23 ; une option Timestamp, optionnelle ; une option Mobile Node Link-layer Identier, optionnelle ; une option Link-local Address, optionnelle. La gure 4.28 schmatise len-tte des donnes (sans le Mobility Header ) du paquet IPv6 que nous avons utilis. Les options tant les mmes que pour le PBU et len-tte faisant la mme taille, nous pouvons dire que dans les architectures 23.401 [8] et 23.402 [9] la taille totale dun PBA (excluant len-tte IPv6) est de 72 octets.
0 8 16 Status 32 Sequence number 64 Mobility Options 96 Lifetime 24 32

(4.3)

KR P Reserved

Figure 4.28 En-tte dun message Proxy Binding Acknowledgement (inspir de Gundavelli et al. [65, sec 8.2]) Dans notre modle la taille totale du PBA slve donc 80 octets. Proxy Binding Update pour la dconnexion Le protocole PMIPv6 utilise le mme paquet que pour la procdure de connexion dun MN mais certains ags changent. Pour nous, cela na pas dimportance, la taille nale du paquet reste de 72 octets.

102 Proxy Binding Update pour la cration de bearer ddi Le PBU utilis pour une cration de bearer est compos des mmes options que celles dun PBU de connexion plus : une option Flow Label de 8 octets, reprsente la gure 3.21 ; une option Trac Flow Template de 4 octets, reprsente la gure 3.19 ; au moins une option Packet Filter de 65 octets au maximum, reprsente la gure 3.20. Nous pouvons calculer que le PBU utilis pour une cration de bearer fait en octets : 544 + 8 8 + 4 8 + 65 8 nombre de PFi 8 82 640 + 520 nombre de PFi soit 8 64 Proxy Binding Acknowledgement pour la cration de bearer Le PBA utilis lors de la cration, modication ou destruction de bearer contient les mmes informations que le PBU partir duquel il a t gnr. Ce PBA fait donc la mme taille que le PBU. PBU/PBA pour la modication de bearer ddi Ces deux messages sont identiques ceux utiliss lors de la cration de bearer ddi. Le nombre de PFi est alors le nombre de PFi modis et non tous ceux du bearer. Si cette modication est une suppression de service (soit une suppression de PFi), loption PFi ne fait plus que 3 octets. La taille du message est donc ramene : 544 + 8 8 + 4 8 + 3 8 nombre de PFi supprims 8 82 640 + 24 nombre de PFi supprims soit 8 64 PBU/PBA pour la destruction de bearer ddi Le PBU utilis pour une destruction de bearer est compos des mme options que celles dun PBU de connexion plus une option Flow Label de 8 octets reprsente la gure 3.21. Nous pouvons calculer que le PBU utilis pour une destruction de bearer fait en octets : 544 + 8 8 8 = 80 82 (4.8) (4.6) (4.7) (4.4) (4.5)

103 4.3.7 Liens Radio

Les protocoles RLC, RRC, MAC et PDCP respectivement dnis dans les documents 25.322 [13] et 36.322 [31], 25.331 [14] et 36.331 [33], 25.321 [12] et 36.321 [30], et 36.323 [32] sont utiliss sur le lien radio UE-eNodeB. Notre simulation du rseau radio est assez basic nous ne nous sommes donc pas attards sur ces protocoles et leur fonctionnement. PDCP a la capacit de compresser les en-ttes IPv4 et IPv6, cependant cette fonctionnalit nest pas obligatoirement utilise, nous ne lavons donc pas implmente. Trois en-ttes PDCP sont dnis, lun de zro octet (qui nest donc pas, proprement parler, un en-tte), lun de un octet et un dernier de trois octets [90]. Nous avons choisi dutiliser des en-ttes de trois octets pour simuler la prsence de PDCP. Plusieurs modes dutilisation de RLC sont dnis, pour le transfert de donnes [90] : transparent ; sans accus de rception ; avec accus de rception. Nous avons choisi de simuler la prsence den-tte RLC relatif au mode avec accus de rception car il est lgrement plus grand que les autres, il fait deux octets. Nous pouvons remarquer que depuis la septime version des spcications 3GPP la taille des PDU RLC est variable de manire viter les segmentations inutiles. La couche RRC semble ne pas dnir den-tte spcique nous navons donc pas simul son fonctionnement. Le protocole MAC possde un en-tte de taille variable mais nous avons remarqu lutilisation de quelques ags et dun champ UE-Id de 32 bits au maximum. Nous avons donc choisi une taille de 5 octets pour len-tte du protocole MAC.

104 CHAPITRE 5 CONCLUSION

Le prsent mmoire porte sur la cration darchitectures de rseau mobile 4G bas sur les architectures dveloppes par le consortium 3GPP, de manire maximiser lutilisation des capacits du protocole IPv6. Nous avons aussi compar les performances des architectures proposes avec celles dveloppes par 3GPP. Dans la premire section de ce chapitre de conclusion nous eectuons une synthse de nos travaux. Dans la deuxime section nous dcrivons les limitations de nos propositions et des mthodes utilises. Enn, nous terminons ce chapitre par une description des volutions futures qui pourraient sappliquer nos travaux. 5.1 Synthse des travaux Dans le cadre de cette maitrise nous avons propos des modications appliquer au rseau mobile dvelopp par 3GPP et dcrit dans le document 23.402 [9]. Ces modications ayant pour but de maximiser lutilisation des capacits du protocole IPv6 et donc minimiser lutilisation du protocole GTP. Dans larchitecture 403 propose, lutilisation de GTP est conserve entre les eNodeB et les SGW tandis que le PGW et le SGW sont transforms en vrai LMA et MAG ; la gestion des bearers est aussi dlgue PMIPv6. Dans larchitecture 404 propose, lutilisation de PMIPv6 est tendue entre les eNodeB et les SGW. Les performances des rseaux mobiles sont critiques tant donn quils ne disposent pas dautant de bande passante que les autres types de rseaux, et que les utilisateurs subissent des relves. De plus dans les architectures 4G tous les tracs transitent sur un mme rseau, ce qui accroit les risques de dgrader les performances des tracs temps rel comme la voix et la vido. Pour vrier que nos propositions ne dgradent pas les performances de larchitecture 23.402 [9], et pour valuer les celles de larchitecture 23.401 [8] par rapport aux autres, nous avons dcid de les implmenter dans le simulateur NS-2. Les rsultats obtenus nous montrent que les architectures que nous proposons ne modient pas, voire amliorent trs lgrement les performances de la 23.402 [9]. En revanche la 23.401 [8] reste de loin la plus performante, notamment en ce qui concerne la gigue des tracs temps rel et le taux de perte de paquets. Nous supposons que larchitecture 23.401 [8] bncie de performances suprieures car elle ne possde pas de lien SGW-PCRF. En eet, lapparition de ce lien dans les architectures

105 23.402 [9], 403 et 404 permet de parallliser les diagrammes de squences des procdures de rductions et destructions de bearer. Cela a pour eet de les acclrer, aussi les paquets qui passaient par ces bearers sont plus vite redirigs vers les bearers par dfaut o ils sont susceptibles dtre perdus plus facilement. Lajout du lien SGW-PCRF pourrait donc expliquer laugmentation du taux de perte de paquets dans les architectures 23.402 [9], 403 et 404. De la mme faon lacclration des procdures de ces architectures pourrait justier laugmentation de la gigue. En eet, les ux changeant plus vite de bearer, le nombre de ux dans un bearer variant plus vite, les dlais de leurs paquets peuvent changer rapidement, impliquant une gigue plus lev. Nous conseillons donc aux oprateurs dsirant dployer un rseau 4G bas sur les architectures proposes par le consortium 3GPP dutiliser celle dcrite dans le document 23.401 [8]. Cependant, sils veulent intgrer des rseaux daccs non dvelopps par 3GPP, e.g. WiMAX, ils pourraient ne pas pouvoir utiliser cette architecture. Nous leur conseillons alors de choisir lune de celles que nous proposons. 5.2 Limitations de la solution propose Les modications que nous proposons dapporter larchitecture 23.402 [9] soure de quelques problmes et limitations. Premirement les performances sont moins bonnes que celles de la 23.401 [8], ce qui pourrait rebuter les oprateurs les adopter. De plus nous transformons les SGW (et les eNodeB dans la 404) en routeurs IP ce qui rend ces nuds sans doute plus complexes et donc plus chers. Une autre critique que nous pourrions nous faire et que nous avons d modier le protocole PMIPv6 pour pouvoir intgrer la gestion des bearers au niveau IP. Tant que ces modications nont pas t standardises par lIETF nous retombons dans le mme problme politique qui a amen 3GPP crer larchitecture 23.402 [9]. Cest dire quil est dicile de faire accepter aux oprateurs grants des rseaux daccs non bass sur des technologies 3GPP, que leurs tracs transitent sur le EPC en utilisant un protocole gr par un consortium dindustriels et non pas standardis par lIETF (ou simplement non standardis par lIETF dans notre cas). Concernant limplmentation des architectures, le simulateur NS-2 possde de nombreux dfauts, e.g. la non gestion des couches de protocoles, limpossibilit de faire transiter de vraies informations sur le rseau, etc. Nos simulations sont donc moins prcises que celles que nous aurions obtenues avec NS-3 ou en utilisant un banc dessai (testbed ).

106 5.3 Amliorations futures

Notre projet nest pas xe, dailleurs le simulateur implment pour larchitecture 23.401 [8] est actuellement entrain dtre complt dun Graphic User Interface (GUI) en vue dtre distribu avec les SASN vendues par Ericsson. De notre point de vue il serait utile damliorer ces simulateurs. Comme dcrit prcdemment NS-2 est assez limit, nous pourrions donc envisager une r-implmentation sur NS-3 ou sur un testbed. Wakikawa et Gundavelli [99] dcrivent une mthode permettant dutiliser des MN ne possdant quune pile IPv4 dans un rseau PMIPv6, voire de faire transiter les donnes entre le MAG et le LMA sur un rseau IPv4. Dans notre tude nous avons pris comme hypothse que tous le rseaux taient en IPv6, cependant la transition dIPv4 IPv6 sera sans doute trs longue. Il serait donc intressant dtudier les modications proposes par Wakikawa et Gundavelli [99] et de les appliquer nos architectures, de manire autoriser lutilisation dIPv4 sur les UE. Nous pourrions aussi mener plus loin nos recherches de faon mettre en lumire les causes de ces dirences de performances entre larchitecture 23.401 [8] et les autres.

107 RFRENCES

[1] 03.60 (2002). General Packet Radio Service (GPRS) ; Service description ; Stage 2, 7.9.0 dition. [2] 23.003 (2010). Numbering, addressing and identication, 9.2.0 dition. [3] 23.011 (2009). Technical realization of Supplementary Services, 9.0.0 dition. [4] 23.060 (2010). General Packet Radio Service (GPRS) ; Service description ; Stage 2, 9.4.0 dition. [5] 23.101 (2009). General Universal Mobile Telecommunications System (UMTS) architecture, 9.0.0 dition. [6] 23.107 (2009). Quality of Service (QoS) concept and architecture, 9.0.0 dition. [7] 23.203 (2010). Policy and charging control architecture, 9.4.0 dition. [8] 23.401 (2010). General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, 9.4.0 dition. [9] 23.402 (2010). Architecture enhancements for non-3GPP accesses, 9.4.0 dition. [10] 24.008 (2010). Mobile radio interface Layer 3 specication ; Core network protocols ; Stage 3, 9.2.0 dition. [11] 24.301 (2010). Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) ; Stage 3, 9.2.0 dition. [12] 25.321 (2010). Medium Access Control (MAC) protocol specication, 9.2.0 dition. [13] 25.322 (2010). Radio Link Control (RLC) protocol specication, 9.1.0 dition. [14] 25.331 (2010). Radio Resource Control (RRC) ; Protocol specication, 10.1.0 dition. [15] 29.002 (2010). Mobile Application Part (MAP) specication, 9.1.0 dition. [16] 29.060 (2010). General Packet Radio Service (GPRS) ; GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface, 9.2.0 dition. [17] 29.061 (2010). Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN), 9.2.0 dition.

108 [18] 29.212 (2010). Policy and charging control over Gx reference point, 9.2.0 dition. [19] 29.214 (2010). Policy and charging control over Rx reference point, 9.3.0 dition. [20] 29.229 (2010). Cx and Dx interfaces based on the Diameter protocol ; Protocol details, 9.1.0 dition. [21] 29.272 (2010). Evolved Packet System (EPS) ; Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol, 9.2.0 dition. [22] 29.274 (2010). 3GPP Evolved Packet System (EPS) ; Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C) ; Stage 3, 9.2.0 dition. [23] 29.279 (2009). Mobile IPv4 (MIPv4) based mobility protocols ; Stage 3, 9.0.0 dition. [24] 29.281 (2010). General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U), 9.2.0 dition. [25] 29.329 (2010). Sh interface based on the Diameter protocol ; Protocol details, 9.1.0 dition. [26] 32.298 (2010). Telecommunication management ; Charging management ; Charging Data Record (CDR) parameter description, 9.3.0 dition. [27] 32.299 (2010). Telecommunication management ; Charging management ; Diameter charging applications, 9.3.0 dition. [28] 32.422 (2010). Telecommunication management ; Subscriber and equipment trace ; Trace control and conguration management, 9.0.1 dition. [29] 36.300 (2010). Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN) ; Overall description ; Stage 2, 9.3.0 dition. [30] 36.321 (2010). Evolved Universal Terrestrial Radio Access (E-UTRA) ; Medium Access Control (MAC) protocol specication, 9.2.0 dition. [31] 36.322 (2010). Evolved Universal Terrestrial Radio Access (E-UTRA) ; Radio Link Control (RLC) protocol specication, 9.1.0 dition.

109 [32] 36.323 (2010). Evolved Universal Terrestrial Radio Access (E-UTRA) ; Packet Data Convergence Protocol (PDCP) specication, 9.0.0 dition. [33] 36.331 (2010). Evolved Universal Terrestrial Radio Access (E-UTRA) ; Radio Resource Control (RRC) ; Protocol specication, 9.2.0 dition. [34] 36.413 (2010). Evolved Universal Terrestrial Radio Access Network (E-UTRAN) ; S1 Application Protocol (S1AP), 9.2.2 dition. [35] 3GPP (2010). General packet radio service / enhanced data rates for global evolution. http://www.3gpp.org/article/gprs-edge accd le 1 Septembre 2010. [36] 3GPP (2010). LTE. http://www.3gpp.org/LTE accd le 3 Septembre 2010. [37] 3GPP (2010). Overview of 3GPP Release 1999. 3GPP, version 0.1.1 dition. http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/ Rel-99_description_20100214.zip accd le 1 Septembre 2010. [38] ALMES, G., KALIDINDI, S. et ZEKAUSKAS, M. (1999). A One-way Delay Metric for IPPM. RFC 2679, Internet Engineering Task Force. [39] ALMES, G., KALIDINDI, S. et ZEKAUSKAS, M. (1999). A One-way Packet Loss Metric for IPPM. RFC 2680, Internet Engineering Task Force. [40] ALMQUIST, P. (1992). Type of Service in the Internet Protocol Suite. RFC 1349, Internet Engineering Task Force. [41] AMANTE, S., CARPENTER, B. et JIANG, S. (2010). Update to the

IPv6 ow label specication. draft 4, IETF. http://tools.ietf.org/html/ draft-carpenter-6man-flow-update-04 accd le 12 octobre 2010. [42] ANOUARD RACHDI, M. (2007). Optimisation des ressources de rseaux htrognes avec coeur de rseau MPLS. Thse de doctorat, EDSYS. [43] BABIARZ, J., CHAN, K. et BAKER, F. (2006). Conguration Guidelines for DiServ Service Classes. RFC 4594, Internet Engineering Task Force. [44] BATES, R. J. (2002). GPRS : general packet radio service. McGraw-Hill Professional, illustre dition. [45] BLAKE, S., BLACK, D., CARLSON, M., DAVIES, E., WANG, Z. et WEISS, W. (1998). An Architecture for Dierentiated Service. RFC 2475, Internet Engineering Task Force.

110 [46] BRADEN, B., CLARK, D., CROWCROFT, J., DAVIE, B., DEERING, S., ESTRIN, D., FLOYD, S., JACOBSON, V., MINSHALL, G., PARTRIDGE, C., PETERSON, L., RAMAKRISHNAN, K., SHENKER, S., WROCLAWSKI, J. et ZHANG, L. (1998). Recommendations on Queue Management and Congestion Avoidance in the Internet. RFC 2309, Internet Engineering Task Force. [47] BRAND, A. et AGHVAMI, H. (2002). Multiple Access Protocols for Mobile Communications GPRS, UMTS and Beyond. Antony Rowe. [48] CALHOUN, P., LOUGHNEY, J., GUTTMAN, E., ZORN, G. et ARKKO, J. (2003). Diameter Base Protocol. RFC 3588, Internet Engineering Task Force. [49] CALHOUN, P., ZORN, G., SPENCE, D. et MITTON, D. (2005). Diameter Network Access Server Application. RFC 4005, Internet Engineering Task Force. [50] CISCO (1999). Congestion Management Overview. Cisco. http://www.cisco.com/ en/US/docs/ios/12_2/qos/configuration/guide/qcfconmg.html accd le 5 Avril 2010. [51] CISCO (1999). Low Latency Queueing. Cisco. http://www.cisco.com/en/US/docs/ ios/12_0t/12_0t7/feature/guide/pqcbwfq.html accd le 5 Avril 2010. [52] CISCO (1999). Weighted Random Early Detection (WRED). Cisco. http://www. cisco.com/en/US/docs/ios/11_2/feature/guide/wred_gs.html accd le 4 Avril 2010. [53] CONTA, A. et DEERING, S. (1998). Generic Packet Tunneling in IPv6 Specication. RFC 2473, Internet Engineering Task Force. [54] DAHLMAN, E., PARKVALL, S., SKLD, J. et BEMING, P. (2008). 3G Evolution : HSPA and LTE for Mobile Broadband. Elsevier, seconde dition. [55] DAVIE, B., CHARNY, A., BENNET, J., BENSON, K., BOUDEC, J. L., COURTNEY, W., DAVARI, S., FIROIU, V. et STILIADIS, D. (2002). An Expedited Forwarding PHB (Per-Hop Behavior). RFC 3246, Internet Engineering Task Force. [56] DEERING, S. et HINDEN, R. (1998). Internet Protocol, Version 6 (IPv6) Specication. RFC 2460, Internet Engineering Task Force. [57] DEKERIS, B., ADOMKUS, T. et BUDNIKAS, A. (2006). Assurance of video conference services with combination of weighted fair queueing scheduling discipline and low latency queue. trac, 2, 4.

111 [58] DEMICHELIS, C. et CHIMENTO, P. (2002). IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). RFC 3393, Internet Engineering Task Force. [59] DEVARAPALLI, V. et DUPONT, F. (2007). Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. RFC 4877, Internet Engineering Task Force. [60] DIJKSTRA, E. W. (1959). A note on two problems in

connexion with graphs. Numerische Mathematik, 1, http://www-m3.ma.tum.de/twiki/pub/MN0506/WebHome/dijkstra.pdf le 25 Octobre 2010.

269271. accd

[61] EBERSPCHER, J., BETTSTETTER, C., VGEL, H.-J. et HARTMANN, C. (2009). GSM architecture, protocols and services. John Wiley and Sons, troisime dition. [62] EKSTROM, H. (2009). QoS control in the 3GPP evolved packet system. IEEE Communications Magazine, 47, 7683. [63] EKSTRM, H. (2009). QoS control in the 3GPP evolved packet system. IEEE Communications Magazine, 47, 7683. [64] FARINACCI, D., LI, T., HANKS, S., MEYER, D. et TRAINA, P. (2000). Generic Routing Encapsulation (GRE). RFC 2784, Internet Engineering Task Force. [65] GUNDAVELLI, S., LEUNG, K., DEVARAPALLI, V., CHOWDHURY, K. et PATIL, B. (2008). Proxy Mobile IPv6. RFC 5213, Internet Engineering Task Force. [66] HAKALA, H., MATTILA, L., KOSKINEN, J.-P., STURA, M. et LOUGHNEY, J. (2005). Diameter Credit-Control Application. RFC 4006, Internet Engineering Task Force. [67] HEINANEN, J., BAKER, F., WEISS, W. et WROCLAWSKI, J. (1999). Assured Forwarding PHB Group. RFC 2597, Internet Engineering Task Force. [68] HEINANEN, J. et GUERIN, R. (1999). A Single Rate Three Color Marker. RFC 2697, Internet Engineering Task Force. [69] HEINANEN, J. et GUERIN, R. (1999). A Two Rate Three Color Marker. RFC 2698, Internet Engineering Task Force. [70] HUI, M., CHEN, G. et DENG, H. (2010). Service ow identier in

proxy mobile IPv6. draft 3, IETF. http://tools.ietf.org/html/ draft-hui-netext-service-flow-identifier-03 accd le 20 Septembre 2010.

112 [71] INETDOC LINUX (2009). Gestionnaires de mise en le dattente pour ladministration de la bande passante. Linux France. http://www.linux-france.org/prj/inetdoc/ guides/Advanced-routing-Howto/lartc.qdisc.html accd le 11 Avril 2010. [72] JOHNSON, D., PERKINS, C. et ARKKO, J. (2004). Mobility Support in IPv6. RFC 3775, Internet Engineering Task Force. [73] LESCUYER, P. et LUCIDARME, T. (2008). Evolved Packet System (EPS) : The LTE and SAE Evolution of 3G UMTS. Wiley. [74] LOUGHNEY, J. (2003). Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. RFC 3589, Internet Engineering Task Force. [75] MABE, K. J. (2004). LLQ in integrated services networks. Southern African Telecommunication Networks and Applications Conference. 00. [76] MENONCIN, S. (2008). The need for QoS. [77] MISHRA, A. R. (2010). Cellular Technologies for Emerging Markets : 2G, 3G and Beyond. John Wiley and Sons, premire dition. [78] MUHANNA, A., KHALIL, M., GUNDAVELLI, S. et LEUNG, K. (2010). Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6. RFC 5845, Internet Engineering Task Force. [79] NARTEN, T., NORDMARK, E., SIMPSON, W. et SOLIMAN, H. (2007). Neighbor Discovery for IP version 6 (IPv6). RFC 4861, Internet Engineering Task Force. [80] NICHOLS, K., BLAKE, S., BAKER, F. et BLACK, D. (1998). Denition of the Dierentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, Internet Engineering Task Force. [81] OLSSON, M., SULTANA, S., ROMMERM, S., FRID, L. et MULLIGAN, C. (2009). SAE and the Evolved Packet Core : Driving the mobile broadband revolution. Elsevier. [82] PATEL, A., LEUNG, K., KHALIL, M., AKHTAR, H. et CHOWDHURY, K. (2005). Mobile Node Identier Option for Mobile IPv6 (MIPv6). RFC 4283, Internet Engineering Task Force. [83] PATEL, A., LEUNG, K., KHALIL, M., AKHTAR, H. et CHOWDHURY, K. (2006). Authentication Protocol for Mobile IPv6. RFC 4285, Internet Engineering Task Force.

113 [84] PAXSON, V., ALMES, G., MAHDAVI, J. et MATHIS, M. (1998). Framework for IP Performance Metrics. RFC 2330, Internet Engineering Task Force. [85] PERKINS, C. (2002). IP Mobility Support for IPv4. RFC 3344, Internet Engineering Task Force. [86] PIERRE, S. (2003). Rseaux et systmes informatiques mobiles : Fondements, architectures et applications. Presses inter Polytechnique. [87] PINOLA, J. bile wimax. et PENTIKOUSIS, K. The Internet Protocol (2008). Journal, Mo1935.

11,

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-2/ipj_11-2.pdf accd le 10 Novembre 2010. [88] POSTEL, J. (1981). Internet Protocol. RFC 0791, Internet Engineering Task Force. [89] PRIGGOURIS, RAKOS, L. G., (2000). HADJIEFTHYMIADES, S. IP QoS frameworks et in MEGPRS.

http://alexandra.di.uoa.gr/Dienst/UI/2.0/Describe/ncstrl.uoa_cs/TR00-0001 accd le 2 Septembre 2010. [90] PROTOCOLS.COM (2010). UMTS Family Protocol Information. Protocols.com. http://www.protocols.com/pbook/UMTSFamily.htm accd le 28 Octobre 2010. [91] RAMAKRISHNAN, K., FLOYD, S. et BLACK, D. (2001). The Addition of Explicit Congestion Notication (ECN) to IP. RFC 3168, Internet Engineering Task Force. [92] RIGNEY, C., WILLENS, S., RUBENS, A. et SIMPSON, W. (2000). Remote Authentication Dial In User Service (RADIUS). RFC 2865, Internet Engineering Task Force. [93] SCHULZRINNE, H., CASNER, S., FREDERICK, R. et JACOBSON, V. (2003). RTP : A Transport Protocol for Real-Time Applications. RFC 3550, Internet Engineering Task Force. [94] SHALUNOV, S. et SWANY, M. (2010). Reporting IP performance metrics to users. draft 5, IETF. http://tools.ietf.org/html/draft-ietf-ippm-reporting-05 accd le 4 aot 2010. [95] SHREEDHAR, M. et VARGHESE, G. (1996). Ecient fair queuing using decit roundrobin. IEEE/ACM Transactions on Networking, 4, 375385.

114 [96] STEWART, R. (2007). Stream Control Transmission Protocol. RFC 4960, Internet Engineering Task Force. [97] The VINT Project (2009). The ns Manual (formerly ns Notes and Documentation). The VINT Project, seconde dition. http://sourceforge.net/projects/nsnam/files/ ns-2/2.34/ accd le 21 Octobre 2010. [98] VEGA GARCIA, A. et HUITEMA, C. (1996). Mecanismes de Controle pour la Transmission de lAudio sur lInternet. Thse de doctorat, University of Nice-Sophia Antipolis. [99] WAKIKAWA, R. et GUNDAVELLI, S. (2010). IPv4 Support for Proxy Mobile IPv6. RFC 5844, Internet Engineering Task Force. [100] WALLINGFORD, T. (2005). Switching to VoIP. OReilly, premire dition. [101] WEIL, J., KUARSINGH, V. et DONLEY, C. (2010). IANA reserved IPv4 prex for IPv6 transition. draft 1, IETF. http://tools.ietf.org/html/ draft-weil-opsawg-provider-address-space-01 accd le 8 septembre 2010. [102] WiMAX Forum R (2009). Network Architecture : Architecture Tenets, Reference Model and Reference Points. WiMAX Forum R , release 1.0 version 4 - stage 2 dition. http:// www.wimaxforum.org/resources/documents/technical/T32 accd le 1 Septembre 2010. Network Architecture : Detailed Protocols and Pro[103] WiMAX Forum R (2009). R http: cedures. WiMAX Forum , release 1.0 version 4 - stage 3 dition. //www.wimaxforum.org/sites/wimaxforum.org/files/technical_document/ 2009/07/WMF-T33-001-R010v04_Network-Stage3-Base.pdf accd le 10 Novembre 2010. [104] ZHANG, H. et FERRARI, D. (1993). Rate-controlled static-priority queueing. IEEE INFOCOM. 227236.

115 ANNEXE A Diagrammes de squences de larchitecture 23.401

Les gures suivantes reprsentent les diagrammes de squences des principales fonctions de gestion de bearer dans larchitecture 23.401 [8]. Les informations utilises pour obtenir ces diagrammes sont tires des documents 23.401 [8], 23.203 [7] et 36.300 [29].

116

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Bearer Resource Command Indication of IP-CAN Session Modication SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Ack IP-CAN Session Modication Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Completed SASN Ack Notify Bearer Completed Update Bearer Request Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Update Bearer Response Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB Provision Ack SASN Notify Bearer Completed SASN Ack Notify Bearer Completed RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Update Bearer Response Provision Ack SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure A.1 Compltion de bearer ddi GBR avec UE QoS aware

117

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Update Bearer Request Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Update Bearer Response Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB Policy and Charging Rules Provision Ack SASN Response Politic SASN Ack Response Politic RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Update Bearer Response Policy and Charging Rules Provision Ack SASN Response Politic SASN Ack Response Politic

Figure A.2 Compltion de bearer ddi GBR avec UE QoS unaware

118

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Bearer Resource Command Indication of IP-CAN Session Modication SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Ack IP-CAN Session Modication Update Bearer Request Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Update Bearer Response Provision Ack SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure A.3 Compltion de bearer ddi non GBR avec UE QoS aware

119

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Policy and Charging Rules Provision Update Bearer Request Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Update Bearer Response Policy and Charging Rules Provision Ack SASN Response Politic SASN Ack Response Politic

Figure A.4 Compltion de bearer ddi non GBR avec UE QoS unaware

120

UE

eNodeB Attach Request User Authentication Request User Authentication Response

MME

SGW

PGW

PCRF

SASN

Authentication Information Request Authentication Information Answer Update Location Insert Subscriber Data Insert Subscriber Data Ack Update Location Ack Create Session Request Create Session Request Create Session Response Create Session Response Plus assez de bw dans le PGW ou sur le SGW cot PGW

Indication of IP-CAN Session Establishment SASN Info UE Connected SASN Ack Info UE Connected Ack IP-CAN Session Establishment premier paquet descendant Create Session Response Create Session Response Initial Context Setup Request Initial Context Setup Response Delete Session Request Delete Session Request Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB downlink data Indication of IP-CAN Session Termination Delete Session Response Delete Session Response SASN Notify Loss of Transmission downlink data SASN Ack Notify Loss of Transmission Ack IP-CAN Session Termination RRC Connection Reconguration RRC Connection Reconguration Complete Initial Context Setup Response Direct Transfer rst uplink data Attach Complete Modify Bearer Request uplink/downlink data Modify Bearer Response

Figure A.5 Connexion dun UE

121

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Bearer Resource Command Indication of IP-CAN Session Modication SASN Notify Bearer Creation SASN Ack Notify Bearer Creation Ack IP-CAN Session Modication Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Created SASN Ack Notify Bearer Created Create Dedicated Bearer Request Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Create Bearer Response Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB Provision Ack SASN Notify Bearer Created SASN Ack Notify Bearer Created RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response passe par le bearer ddi Direct Transfer Session Management Response Create Bearer Response passe par le bearer ddi Create Bearer Response Provision Ack SASN Notify Bearer Created passe par le bearer ddi SASN Ack Notify Bearer Created

Figure A.6 Cration de bearer ddi avec UE QoS aware

122

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Create Dedicated Bearer Request Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Create Bearer Response Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB Policy and Charging Rules Provision Ack SASN Response Politic SASN Ack Response Politic RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response passe par le bearer ddi Direct Transfer Session Management Response Create Bearer Response passe par le bearer ddi Create Bearer Response Policy and Charging Rules Provision Ack SASN Response Politic passe par le bearer ddi SASN Ack Response Politic

Figure A.7 Cration de bearer ddi avec UE QoS unaware

123

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Bearer Resource Command Indication of IP-CAN Session Modication SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Ack IP-CAN Session Modication Delete Bearer Request Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Delete Bearer Response Delete Bearer Response Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed

Figure A.8 Destruction de bearer ddi avec UE QoS aware

124

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Policy and Charging Rules Provision Delete Bearer Request Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Delete Bearer Response Delete Bearer Response Policy and Charging Rules Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed

Figure A.9 Destruction de bearer ddi avec UE QoS unaware

125

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Bearer Resource Command Indication of IP-CAN Session Modication SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Ack IP-CAN Session Modication Update Bearer Request Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Update Bearer Response Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced

Figure A.10 Rduction de bearer ddi GBR avec UE QoS aware

126

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform that Service Stop Ack SASN Inform that Service Stop Policy and Charging Rules Provision Update Bearer Request Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Update Bearer Response Policy and Charging Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced

Figure A.11 Rduction de bearer ddi GBR avec UE QoS unaware

127

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Bearer Resource Command Indication of IP-CAN Session Modication SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Ack IP-CAN Session Modication Update Bearer Request Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Update Bearer Response Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced

Figure A.12 Rduction de bearer ddi non GBR avec UE QoS aware

128

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Policy and Charging Rules Provision Update Bearer Request Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Update Bearer Response Policy and Charging Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced

Figure A.13 Rduction de bearer ddi non GBR avec UE QoS unaware

129

UE

eNodeB Source

eNodeB Destination Handover Required

MME

SGW

PGW

PCRF

SASN

Handover Request Handover Failure Handover Preparation Failure Handover Request Ack Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Handover Command Handover Command Handover Conrm Handover Notify lancement du timer Delete Bearer Command Delete Bearer Command Indication of IP-CAN Session Modication SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Si un bearer t rejet Ack IP-CAN Session Modication Delete Bearer Request Delete Bearer Response Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Modify Bearer Request Modify Bearer Response expiration du timer UE Context Release Command Delete Indirect Data Forwarding Tunnel Request UE Release Context Complete Delete Indirect Data Forwarding Tunnel Response Pas assez de bw dans le eNodeB destination ou sur le SGW cot eNodeB destination pour crer le Bearer par default

Figure A.14 S1 Handover

130

UE

eNodeB Source

eNodeB Destination Handover Required

MME Source

MME Destination

SGW Source

SGW Destination

PGW

Forward Relocation Request Create Session Request Create Session Response Handover Request Handover Failure Pas assez de bw dans le eNodeB destination ou sur le SGW cot eNodeB destination pour crer le Bearer par default Delete Session Request Delete Session Response

Forward Relocation Response (Reject) Handover Preparation Failure Handover Request Ack Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Forward Relocation Response Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Handover Command Handover Command Handover Conrm Handover Notify lancement du timer Forward Relocation Complete Notication lancement du timer Forward Relocation Complete Acknoledge procdure de destruction de bearer Modify Bearer Request Modify Bearer Request Modify Bearer Response Modify Bearer Response expiration du timer Delete Session Request UE Context Release Command Delete Session Response UE Release Context Complete expiration du timer Delete Indirect Data Forwarding Tunnel Request Delete Indirect Data Forwarding Tunnel Response

Figure A.15 S1 Handover avec changement de SGW

131

UE

eNodeB Source

eNodeB Destination

MME

SGW

Handover Request Handover Request Ack Handover Command RRC Connection Reconguration Request SN Status Transfer Handover Conrm RRC Connection Reconguration Complete Path Switch Request procdure de destruction de bearer Modify Bearer Request Modify Bearer Response Path Switch Request Ack Release Resource

Figure A.16 X2 Handover

132

UE

eNodeB Source

eNodeB Destination

MME

SGW Source

SGW Destination

PGW

Handover Request Handover Request Ack Handover Command RRC Connection Reconguration Request SN Status Transfer Handover Conrm RRC Connection Reconguration Complete Path Switch Request procdure de destruction de bearer Create Session Request Modify Bearer Request Modify Bearer Response Create Session Response lancement du timer Path Switch Request Ack Release Resource expiration du timer Delete Session Request Delete Session Response

Figure A.17 X2 Handover avec changement de SGW

133 ANNEXE B Diagrammes de squences de larchitecture 23.402

Les gures suivantes reprsentent les diagrammes de squences des principales fonctions de gestion de bearer dans larchitecture 23.402 [9]. Les informations utilises pour obtenir ces diagrammes sont tires des documents 23.401 [8], 23.402 [9], 23.203 [7] et 36.300 [29].

134

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Gateway Control and QoS Rules Reply Gateway Control and QoS Rules Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Completed SASN Ack Notify Bearer Completed Update Bearer Request Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Gateway Control and QoS Rules Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Control and QoS Rules Ack Policy and Charging Rules Provision Policy and Charging Rules Provision Ack SASN Notify Bearer Completed SASN Ack Notify Bearer Completed SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure B.1 Compltion de bearer ddi GBR avec UE QoS aware

135

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Gateway Control and QoS Rules Provision Ack Policy and Charging Rules Provision Policy and Charging Rules Provision Ack SASN Response Politic SASN Ack Response Politic SASN Response Politic SASN Ack Response Politic

Figure B.2 Compltion de bearer ddi GBR avec UE QoS unaware

136

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Gateway Control and QoS Rules Reply Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Control and QoS Rules Ack Policy and Charging Rules Provision Policy and Charging Rules Provision Ack SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure B.3 Compltion de bearer ddi non GBR avec UE QoS aware

137

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Control and QoS Rules Provision Ack Policy and Charging Rules Provision Policy and Charging Rules Provision Ack SASN Response Politic SASN Ack Response Politic

Figure B.4 Compltion de bearer ddi non GBR avec UE QoS unaware

138

UE

eNodeB Attach Request User Authentication Request User Authentication Response

MME

SGW

PGW

PCRF

SASN

Authentication Information Request Authentication Information Answer Update Location Insert Subscriber Data Insert Subscriber Data Ack Update Location Ack Create Session Request Create Session Response Plus assez de bw dans le PGW ou sur le SGW cot PGW Gateway Control Session Establishment Proxy Binding Update (connection) Ack Gateway Control Session Establishment Indication of IP-CAN Session Establishment SASN Info UE Connected SASN Ack Info UE Connected Ack IP-CAN Session Establishment Proxy Binding Ack (connection) Create Session Response Initial Context Setup Request Initial Context Setup Response Delete Session Request Gateway Control Session Termination Ack Gateway Control Session Termination Proxy Binding Update (termination) Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB downlink data Indication of IP-CAN Session Termination SASN Notify Loss of Transmission downlink data SASN Ack Notify Loss of Transmission Ack IP-CAN Session Termination Proxy Binding Ack (termination) Delete Session Response RRC Connection Reconguration RRC Connection Reconguration Complete Initial Context Setup Response Direct Transfer rst uplink data Attach Complete Modify Bearer Request uplink/downlink data Modify Bearer Response

Figure B.5 Connexion dun UE

139

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Creation SASN Ack Notify Bearer Creation Gateway Control and QoS Rules Reply Gateway Control and QoS Rules Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Created SASN Ack Notify Bearer Created Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Gateway Control and QoS Rules Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response passe par le bearer ddi Direct Transfer Session Management Response Create Bearer Response Gateway Control and QoS Rules Ack passe par le bearer ddi Policy and Charging Rules Provision Policy and Charging Rules Provision Ack SASN Notify Bearer Created passe par le bearer ddi SASN Ack Notify Bearer Created SASN Notify Bearer Created SASN Ack Notify Bearer Created

Figure B.6 Cration de bearer ddi avec UE QoS aware

140

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response passe par le bearer ddi Direct Transfer Session Management Response Create Bearer Response Gateway Gateway Control and QoS Rules Provision Ack passe par le bearer ddi Policy and Charging Rules Provision Policy and Charging Rules Provision Ack SASN Response Politic passe par le bearer ddi SASN Ack Response Politic SASN Response Politic SASN Ack Response Politic

Figure B.7 Cration de bearer ddi avec UE QoS unaware

141
UE eNodeB MME SGW PGW PCRF SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Gateway Control and QoS Rules Reply Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Delete Bearer Response Gateway Control and QoS Rules Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.8 Destruction de bearer ddi avec UE QoS aware

UE eNodeB MME SGW PGW PCRF SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Gateway Control and QoS Rules Provision Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Delete Bearer Response Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.9 Destruction de bearer ddi avec UE QoS unaware

142
UE eNodeB MME SGW PGW PCRF SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Gateway Control and QoS Rules Reply Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Control and QoS Rules Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.10 Rduction de bearer ddi GBR avec UE QoS aware

UE eNodeB MME SGW PGW PCRF SASN

SASN Inform that Service Stop Ack SASN Inform that Service Stop Gateway Control and QoS Rules Provision Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.11 Rduction de bearer ddi GBR avec UE QoS unaware

143

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Gateway Control and QoS Rules Reply Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Control and QoS Rules Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.12 Rduction de bearer ddi non GBR avec UE QoS aware

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Gateway Control and QoS Rules Provision Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.13 Rduction de bearer ddi non GBR avec UE QoS unaware

144

UE

eNodeB Source

eNodeB Destination Handover Required

MME

SGW

PGW

PCRF

SASN

Handover Request Handover Failure Handover Preparation Failure Handover Request Ack Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Handover Command Handover Command Handover Conrm Handover Notify lancement du timer Delete Bearer Command Gateway Control and QoS Rules Request SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Gateway Control and QoS Rules Reply Si un bearer t rejet Policy and Charging Rules Provision Gateway Control and QoS Rules Ack Policy and Charging Rules Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Modify Bearer Request Modify Bearer Response expiration du timer UE Context Release Command Delete Indirect Data Forwarding Tunnel Request UE Release Context Complete Delete Indirect Data Forwarding Tunnel Response Pas assez de bw dans le eNodeB destination ou sur le SGW cot eNodeB destination pour crer le Bearer par default

Figure B.14 S1 Handover

145

UE

eNodeB Source

eNodeB Destination Handover Required

MME Source

MME Destination

SGW Source

SGW Destination

PGW

PCRF

Forward Relocation Request Create Session Request Create Session Response Handover Request Handover Request Ack Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Forward Relocation Response Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Handover Command Handover Command Handover Conrm Handover Notify lancement du timer Forward Relocation Complete Notication lancement du timer Forward Relocation Complete Acknoledge procdure de destruction de bearer Modify Bearer Request Gateway Control Session Establishment Acknowledge Gateway Control Establishment Proxy Binding Update Proxy Binding Acknowledgement Modify Bearer Response expiration du timer UE Context Release Command Delete Session Request UE Release Context Complete Gateway Control Session Termination Acknowledge Gateway Control Termination Delete Session Response expiration du timer Delete Indirect Data Forwarding Tunnel Request Delete Indirect Data Forwarding Tunnel Response Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.15 S1 Handover avec changement de SGW

146

UE

eNodeB Source

eNodeB Destination

MME

SGW Source

SGW Destination

PGW

PCRF

Handover Request Handover Request Ack Handover Command RRC Connection Reconguration Request SN Status Transfer Handover Conrm RRC Connection Reconguration Complete Path Switch Request procdure de destruction de bearer Create Session Request Gateway Control Session Establishment Acknowledge Gateway Control Establishment Proxy Binding Update Proxy Binding Acknowledgement Create Session Response lancement du timer Path Switch Request Ack Release Resource expiration du timer Delete Session Request Gateway Control Session Termination Acknowledge Gateway Control Termination Delete Session Response Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure B.16 X2 Handover avec changement de SGW

147 ANNEXE C Diagrammes de squences de larchitecture 403

Les gures suivantes reprsentent les diagrammes de squences des principales fonctions de gestion de bearer dans larchitecture 403, soit larchitecture 23.402 [9] lgrement modie sur la partie PMIPv6 pour supprimer le protocole GRE. La procdure de connexion dun UE est exactement la mme que celle de larchitecture 23.402 [9] ; cependant le PBU contient une option Flow Label supplmentaire dans architecture. La procdure de relve avec interface X2 et sans changement de SGW est identique celle de larchitecture 23.402 [9]. Les informations utilises pour obtenir ces diagrammes sont tires des documents 23.401 [8], 23.402 [9], 23.203 [7] et 36.300 [29] et inspires des crits de Gundavelli et al. [65] et Hui et al. [70].

148

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Gateway Control and QoS Rules Reply Gateway Control and QoS Rules Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Completed SASN Ack Notify Bearer Completed Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Gateway Control and QoS Rules Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Control and QoS Rules Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Notify Bearer Completed SASN Ack Notify Bearer Completed SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure C.1 Compltion de bearer ddi GBR avec UE QoS aware

149

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Gateway Control and QoS Rules Provision Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Response Politic SASN Ack Response Politic SASN Response Politic SASN Ack Response Politic

Figure C.2 Compltion de bearer ddi GBR avec UE QoS unaware

150

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Gateway Control and QoS Rules Reply Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Control and QoS Rules Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure C.3 Compltion de bearer ddi non GBR avec UE QoS aware

151

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Creation SASN Ack Notify Bearer Creation Gateway Control and QoS Rules Reply Gateway Control and QoS Rules Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Created SASN Ack Notify Bearer Created Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Gateway Control and QoS Rules Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response passe par le bearer ddi Direct Transfer Session Management Response Create Bearer Response Gateway Control and QoS Rules Ack passe par le bearer ddi Proxy Binding Update (creation) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (creation) SASN Notify Bearer Created passe par le bearer ddi SASN Ack Notify Bearer Created SASN Notify Bearer Created SASN Ack Notify Bearer Created

Figure C.4 Cration de bearer ddi avec UE QoS aware

152

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response passe par le bearer ddi Direct Transfer Session Management Response Create Bearer Response Gateway Gateway Control and QoS Rules Provision Ack passe par le bearer ddi Proxy Binding Update (creation) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (creation) SASN Response Politic passe par le bearer ddi SASN Ack Response Politic SASN Response Politic SASN Ack Response Politic

Figure C.5 Cration de bearer ddi avec UE QoS unaware

153

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Gateway Control and QoS Rules Reply Proxy Binding Update (destruction) Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Delete Bearer Response Gateway Control and QoS Rules Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (destruction)

Figure C.6 Destruction de bearer ddi avec UE QoS aware

154

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Gateway Control and QoS Rules Provision Proxy Binding Update (destruction) Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Delete Bearer Response Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (destruction)

Figure C.7 Destruction de bearer ddi avec UE QoS unaware

155

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Gateway Control and QoS Rules Reply Proxy Binding Update (update) Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Control and QoS Rules Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure C.8 Rduction de bearer ddi GBR avec UE QoS aware

156
UE eNodeB MME SGW PGW PCRF SASN

SASN Inform that Service Stop Ack SASN Inform that Service Stop Gateway Control and QoS Rules Provision Proxy Binding Update (update) Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Update Bearer Response Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure C.9 Rduction de bearer ddi GBR avec UE QoS unaware

UE eNodeB MME SGW PGW PCRF SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Gateway Control and QoS Rules Reply Proxy Binding Update (update) Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Control and QoS Rules Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure C.10 Rduction de bearer ddi non GBR avec UE QoS aware

157

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Gateway Control and QoS Rules Provision Proxy Binding Update (update) Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Update Bearer Response Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure C.11 Rduction de bearer ddi non GBR avec UE QoS unaware

158

UE

eNodeB Source

eNodeB Destination Handover Required

MME

SGW

PGW

PCRF

SASN

Handover Request Handover Failure Handover Preparation Failure Handover Request Ack Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Handover Command Handover Command Handover Conrm Handover Notify lancement du timer Delete Bearer Command Gateway Control and QoS Rules Request SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Gateway Control and QoS Rules Reply Si un bearer t rejet Proxy Binding Update (destruction) Policy and Charging Rules Provision Proxy Binding Ack (destruction) Gateway Control and QoS Rules Ack Policy and Charging Rules Provision Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Modify Bearer Request Modify Bearer Response expiration du timer UE Context Release Command Delete Indirect Data Forwarding Tunnel Request UE Release Context Complete Delete Indirect Data Forwarding Tunnel Response Pas assez de bw dans le eNodeB destination ou sur le SGW cot eNodeB destination pour crer le Bearer par default

Figure C.12 S1 Handover

159

UE

eNodeB Source

eNodeB Destination Handover Required

MME Source

MME Destination

SGW Source

SGW Destination

PGW

PCRF

Forward Relocation Request Create Session Request Create Session Response Handover Request Handover Request Ack Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Forward Relocation Response Create Indirect Data Forwarding Tunnel Request Create Indirect Data Forwarding Tunnel Response Handover Command Handover Command Handover Conrm Handover Notify lancement du timer Forward Relocation Complete Notication lancement du timer Forward Relocation Complete Acknoledge procdure de destruction de bearer Modify Bearer Request Gateway Control Session Establishment Acknowledge Gateway Control Establishment Proxy Binding Update (connection + bearer) Proxy Binding Acknowledgement (connection + bearer) Modify Bearer Response expiration du timer UE Context Release Command Delete Session Request UE Release Context Complete Gateway Control Session Termination Proxy Binding Update (termination) Acknowledge Gateway Control Termination Proxy Binding Acknowledgement (termination) Delete Session Response expiration du timer Delete Indirect Data Forwarding Tunnel Request Delete Indirect Data Forwarding Tunnel Response Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure C.13 S1 Handover avec changement de SGW

160

UE

eNodeB Source

eNodeB Destination

MME

SGW Source

SGW Destination

PGW

PCRF

Handover Request Handover Request Ack Handover Command RRC Connection Reconguration Request SN Status Transfer Handover Conrm RRC Connection Reconguration Complete Path Switch Request procdure de destruction de bearer Create Session Request Gateway Control Session Establishment Acknowledge Gateway Control Establishment Proxy Binding Update (connection + bearer) Proxy Binding Acknowledgement (connection + bearer) Create Session Response lancement du timer Path Switch Request Ack Release Resource expiration du timer Delete Session Request Gateway Control Session Termination Proxy Binding Update (termination) Acknowledge Gateway Control Termination Proxy Binding Acknowledgement (termination) Delete Session Response Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure C.14 X2 Handover avec changement de SGW

161 ANNEXE D Diagrammes de squences de larchitecture 404

Les gures suivantes reprsentent les diagrammes de squences des principales fonctions de gestion de bearer dans larchitecture 404, soit larchitecture 403 modie pour supprimer les protocoles GTP-U et GRE et intgrer PMIPv6 entre le eNodeB et le SGW. Les informations utilises pour obtenir ces diagrammes sont tires des documents 23.401 [8], 23.402 [9], 23.203 [7] et 36.300 [29], ainsi que des crits de Gundavelli et al. [65] et Hui et al. [70].

162

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Gateway Control and QoS Rules Reply Gateway Control and QoS Rules Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Completed SASN Ack Notify Bearer Completed Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Gateway Control and QoS Rules Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Control and QoS Rules Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Notify Bearer Completed SASN Ack Notify Bearer Completed SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure D.1 Compltion de bearer ddi GBR avec UE QoS aware

163

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Update Bearer Request Bearer Modify Request Bearer Modify Response Update Bearer Response Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Gateway Control and QoS Rules Provision Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Response Politic SASN Ack Response Politic SASN Response Politic SASN Ack Response Politic

Figure D.2 Compltion de bearer ddi GBR avec UE QoS unaware

164

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Completion SASN Ack Notify Bearer Completion Gateway Control and QoS Rules Reply Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Control and QoS Rules Ack Proxy Binding Update (update) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update) SASN Notify Bearer Completed SASN Ack Notify Bearer Completed

Figure D.3 Compltion de bearer ddi non GBR avec UE QoS aware

165

UE

eNodeB Attach Request User Authentication Request User Authentication Response

MME

SGW

PGW

PCRF

SASN

Authentication Information Request Authentication Information Answer Update Location Insert Subscriber Data Insert Subscriber Data Ack Update Location Ack Create Session Request Create Session Response Plus assez de bw dans le PGW ou sur le SGW cot PGW Gateway Control Session Establishment Proxy Binding Update (connection) Ack Gateway Control Session Establishment Indication of IP-CAN Session Establishment SASN Info UE Connected SASN Ack Info UE Connected Ack IP-CAN Session Establishment Proxy Binding Ack (connection) Create Session Response Initial Context Setup Request Initial Context Setup Response Delete Session Request Gateway Control Session Termination Ack Gateway Control Session Termination Proxy Binding Update (termination) Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB downlink data Indication of IP-CAN Session Termination SASN Notify Loss of Transmission downlink data SASN Ack Notify Loss of Transmission Ack IP-CAN Session Termination Proxy Binding Ack (termination) Delete Session Response RRC Connection Reconguration RRC Connection Reconguration Complete Initial Context Setup Response Direct Transfer rst uplink data Proxy Binding Update (connection) Attach Complete Modify Bearer Request Proxy Binding Ack (connection) uplink/downlink data Modify Bearer Response

Figure D.4 Connexion dun UE

166

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Creation SASN Ack Notify Bearer Creation Gateway Control and QoS Rules Reply Gateway Control and QoS Rules Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Notify Bearer Created SASN Ack Notify Bearer Created Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Gateway Control and QoS Rules Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response Direct Transfer Session Management Response Proxy Binding Update (creation) Create Bearer Response Proxy Binding Ack (creation) passe par le bearer ddi Gateway Control and QoS Rules Ack Proxy Binding Update (creation) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (creation) SASN Notify Bearer Created passe par le bearer ddi SASN Ack Notify Bearer Created SASN Notify Bearer Created SASN Ack Notify Bearer Created

Figure D.5 Cration de bearer ddi avec UE QoS aware

167

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le PGW ou sur le SGW cot PGW SASN Response Politic SASN Ack Response Politic Create Dedicated Bearer Request Bearer Setup Request Bearer Setup Response Create Bearer Response Gateway Control and QoS Rules Provision Ack Plus assez de bw dans le eNodeB ou sur le SGW cot eNodeB RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Setup Response Direct Transfer Session Management Response Proxy Binding Update (creation) Create Bearer Response Proxy Binding Ack (creation) passe par le bearer ddi Gateway Gateway Control and QoS Rules Provision Ack Proxy Binding Update (creation) Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (creation) SASN Response Politic passe par le bearer ddi SASN Ack Response Politic SASN Response Politic SASN Ack Response Politic

Figure D.6 Cration de bearer ddi avec UE QoS unaware

168

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Gateway Control and QoS Rules Reply Proxy Binding Update (destruction) Delete Bearer Request Deactivate Bearer Request RRC Connection Reconguration RRC Connection Reconguration Complete Deactivate Bearer Response Direct Transfer Deactivate EPS Bearer Context Accept Proxy Binding Update (destruction) Delete Bearer Response Proxy Binding Ack (destruction) Gateway Control and QoS Rules Ack SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (destruction)

Figure D.7 Destruction de bearer ddi avec UE QoS aware

169

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Gateway Control and QoS Rules Reply Proxy Binding Update (update) Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Control and QoS Rules Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure D.8 Rduction de bearer ddi GBR avec UE QoS aware

170

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform that Service Stop Ack SASN Inform that Service Stop Gateway Control and QoS Rules Provision Proxy Binding Update (update) Update Bearer Request Bearer Modify Request RRC Connection Reconguration RRC Connection Reconguration Complete Bearer Modify Response Direct Transfer Session Management Response Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure D.9 Rduction de bearer ddi GBR avec UE QoS unaware

171

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

Request Bearer Resource Modication Request Bearer Resource Modication Bearer Resource Command Gateway Control and QoS Rules Request SASN Notify Bearer Reduction SASN Ack Notify Bearer Reduction Gateway Control and QoS Rules Reply Proxy Binding Update (update) Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Control and QoS Rules Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure D.10 Rduction de bearer ddi non GBR avec UE QoS aware

172

UE

eNodeB

MME

SGW

PGW

PCRF

SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Gateway Control and QoS Rules Provision Proxy Binding Update (update) Update Bearer Request Downlink NAS Transport Direct Transfer Direct Transfer Uplink NAS Transport Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update) Gateway Gateway Control and QoS Rules Provision Ack SASN Notify Bearer Reduced SASN Ack Notify Bearer Reduced Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

Figure D.11 Rduction de bearer ddi non GBR avec UE QoS unaware

173

UE

eNodeB Source

eNodeB Destination

MME

SGW

Handover Request Handover Request Ack Handover Command RRC Connection Reconguration Request SN Status Transfer Handover Conrm RRC Connection Reconguration Complete Path Switch Request procdure de destruction de bearer Proxy Binding Update (connection + bearer) Modify Bearer Request Proxy Binding Ack (connection + bearer) Modify Bearer Response Path Switch Request Ack Release Resource Proxy Binding Update (termination) Proxy Binding Ack (termination)

Figure D.12 X2 Handover

174

UE

eNodeB Source

eNodeB Destination

MME

SGW Source

SGW Destination

PGW

PCRF

Handover Request Handover Request Ack Handover Command RRC Connection Reconguration Request SN Status Transfer Handover Conrm RRC Connection Reconguration Complete Path Switch Request procdure de destruction de bearer Proxy Binding Update (connection + bearer) Create Session Request Proxy Binding Acknowledgement (connection + bearer) Gateway Control Session Establishment Acknowledge Gateway Control Establishment Proxy Binding Update (connection + bearer) Proxy Binding Acknowledgement (connection + bearer) Create Session Response lancement du timer Path Switch Request Ack Release Resource Proxy Binding Update (termination) Proxy Binding Update (termination) Proxy Binding Acknowledgement (termination) Proxy Binding Ack (termination) expiration du timer Delete Session Request Gateway Control Session Termination Acknowledge Gateway Control Termination Delete Session Response Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Figure D.13 X2 Handover avec changement de SGW

175 ANNEXE E Rsultats des simulations avec un seul UE

Les gures suivantes prsentes des comparaisons des rsultats obtenus par nos dirents simulateurs. Les simulations utilisent toutes le mme scnario, un UE se connecte la premire seconde et durant les trois premires secondes aprs sa connexion il lance des tracs voix, vido et web. la trentime seconde aprs sa connexion il fait un relve vers leNodeB suivant. la cinquantime seconde il lance son trac FTP. Chaque connexion (type de trac) dure cent secondes. Le rseau comporte deux eNodeB.
401 402 403 404 700

600

500 dbit en kbps

400

300

200

100 10 20 30 40 50 60 temps en secondes 70 80 90 100

Figure E.1 Dbit du trac vido

176

401 402 403 404 9 8.5 8 7.5 dlai en millisecondes 7 6.5 6 5.5 5 4.5 4 3.5 10 20 30 40 50 60 temps en secondes 70 80 90 100

Figure E.2 Dlai moyen du trac vido entre le SASN et le UE

401 402 403 404 1002.65 1002.6 1002.55 dlai en microsecondes 1002.5 1002.45 1002.4 1002.35 1002.3 1002.25 10 20 30 40 50 60 temps en secondes 70 80 90 100

Figure E.3 Dlai moyen du trac de voix entre le SASN et le eNodeB

177

401 402 403 404 471 470 469 Gigue en microsecondes 468 467 466 465 464 463 10 20 30 40 50 60 temps en secondes 70 80 90 100

Figure E.4 Gigue du trac de voix entre le SASN et le UE

401 402 403 404 20 18 16 Goodput en Mbps 14 12 10 8 6 4 60 70 80 90 100 110 temps en secondes 120 130 140 150

Figure E.5 Goodput du trac FTP

178

401 402 403 404 1

Taux de pertes de paquets en %

0.8

0.6

0.4

0.2

0 10 20 30 40 50 60 temps en secondes 70 80 90 100

Figure E.6 Taux de perte de paquets du trac de voix entre le SASN et le UE

401 402 403 404 1

Taux de pertes de paquets en %

0.8

0.6

0.4

0.2

0 60 70 80 90 100 110 temps en secondes 120 130 140 150

Figure E.7 Taux de perte de paquets du trac FTP entre le SASN et le UE

179 ANNEXE F Rsultats des simulations avec mille UE

Les gures suivantes prsentes des comparaisons des rsultats obtenus par nos dirents simulateurs. Les simulations utilisent toutes le mme scnario, un UE se connecte toutes les secondes, durant les trois premires secondes aprs sa connexion il lance des tracs voix, vido et web. la trentime seconde aprs sa connexion il fait un relve vers leNodeB suivant (dans une liste de eNodeB partag par tous les UE) celle sur laquelle il est attach actuellement. la cinquantime seconde il lance son trac FTP. Chaque connexion (type de trac) dure cent secondes. En tout mille UE se connectent, le rseau contenant dix eNodeB.
401 402 403 404 22 20 18 dlai en millisecondes 16 14 12 10 8 6 4 100 200 300 400 500 600 700 temps en second 800 900 1000 1100

Figure F.1 Dlai moyen du trac vido entre le SASN et les UE

180

401 402 403 404 12

10

dlai en millisecondes

0 100 200 300 400 500 600 temps en second 700 800 900 1000 1100

Figure F.2 Dlai moyen du trac de voix entre le SASN et les UE

401 402 403 404 6

5.5 dlai en millisecondes

4.5

3.5 100 200 300 400 500 600 700 temps en second 800 900 1000 1100

Figure F.3 Dlai moyen du trac vido entre le SASN et les eNodeB

181

401 402 403 404 1014

1012 dlai en microsecondes

1010

1008

1006

1004

1002 100 200 300 400 500 600 temps en second 700 800 900 1000 1100

Figure F.4 Dlai moyen du trac de voix entre le SASN et les eNodeB

401 402 403 404 25

20 Gigue en millisecondes

15

10

0 100 200 300 400 500 600 700 temps en second 800 900 1000 1100

Figure F.5 Gigue du trac vido entre le SASN et les UE

182

401 402 403 404 50 45 40 35 dbit en Mbps 30 25 20 15 10 5 0 100 200 300 400 500 600 700 temps en second 800 900 1000 1100

Figure F.6 Dbit global du trac vido

401 402 403 404 180 160 140 Goodput en Mbps 120 100 80 60 40 20 0 100

200

300

400

500

600 700 temps en second

800

900

1000

1100

1200

Figure F.7 Goodput global du trac FTP

183

401 402 403 404 4 3.5 3 Goodput en Mbps 2.5 2 1.5 1 0.5 0 100 200 300 400 500 600 temps en second 700 800 900 1000 1100

Figure F.8 Goodput global du trac web

401 402 403 404 1

Taux de pertes de paquets en %

0.8

0.6

0.4

0.2

0 100 200 300 400 500 600 700 temps en second 800 900 1000 1100

Figure F.9 Taux de perte de paquets global du trac vido entre le SASN et les UE

184

401 402 403 404 1

Taux de pertes de paquets en %

0.8

0.6

0.4

0.2

0 100 200 300 400 500 600 700 temps en second 800 900 1000 1100

Figure F.10 Taux de perte de paquets global du trac web entre le SASN et les UE

401 402 403 404 1

Taux de pertes de paquets en %

0.8

0.6

0.4

0.2

0 100

200

300

400

500 600 temps en second

700

800

900

1000

Figure F.11 Taux de perte de paquets global du trac FTP entre le SASN et les UE

185 ANNEXE G Tailles des messages GTP

Les paragraphes suivants dtaillent les tailles des messages du protocole GTP-C (ces tailles incluent les 12 octets de len-tte GTP-C) que nous avons utilis. Tableau G.1 Taille des IE du protocole GTP (inspir de 29.274 [22]) type de IE AMBR APN APN Restriction Bearer Contexts Bearer QoS Bearer TFT (voir [10, sec 10.5.6.12]) Cause Charging Characteristics Charging Id Delay Value EPS Bearer ID (EBI) Flow QoS Fully-qualied PDN Connection Set Identier (FQ-CSID) F-TEID IMSI Indication ME Identity (MEI) MS ISDN Number (MSISDN) Operations and Maintenance Center (OMC) Identity PDN Address Allocation (PAA) PDN Type Procedure Transaction Id (PTI) RAT type Selection Mode Serving Network taille en octets 12 104 5 4 plus le contenue 26 4 + 60 (nombre de SFI) 10 6 8 5 5 25 22 24 12 6 12 10 19 22 5 5 6 5 7

186 type de IE Trac Aggregate Description (TAD) (voir TFT dans [10]) Trace Reference Trace Type Trigger Id Trace Information User CSG Information (UCI) User Location Information (ULI) taille en octets 4 + 60 (nombre de SFI) 10 3 19 50 12 5 plus le contenue

Tableau G.2 Taille des informations du IE ULI du protocole GTP (inspir de 29.274 [22]) type dinformation CGI ECGI RAI SAI TAI taille en octets 6 6 6 6 4

Create Session Request Daprs le tableau G.3 le message GTP-C Create Session Request fait 372 octets sur le lien S11 et 394 sur le lien S5/S8. Create Session Response Daprs le tableau G.4 le message Create Session Response fait 231 octets sur le lien S11 sil est envoy directement du SGW (il ne vient pas du PGW) et que la rponse est ngative. Si en revanche il vient du PGW le message fait 253 octets. Si le message, toujours sur linterface S11 vient du PGW (en passant par le PGW) et que la rponse est positive alors il fait 234 octets. Si le message est sur le lien S5/S8 (il vient forcement du PGW cf. gure A.5) alors il fait 172 octets pour une rponse positive et 191 octets pour rponse ngative. Delete Session Request Daprs le tableau G.5 le message Delete Session Request fait 33 octets. Delete Session Response Ce message fait 22 octets suivant le tableau G.6. Modify Bearer Request Daprs le tableau G.7 ce message fait : 73 octets sil est envoy par le MME sur le lien S11 lors de la connexion dun UE ;

187

Tableau G.3 Create Session Request (interprt de [22])

(a) Create Session Request

IE

type

IMSI MSISDN ULI incluant ECGI Serving Network RAT Type Indication Flags Indication Sender F-TEID for Control F-TEID Plane PGW S5/S8 Address for F-TEID Control Plane APN Selection Mode PDN Type PAA Maximum APN Restriction APN Restriction APN-AMBR AMBR Bearer Contexts to be Bearer Context created Trace Information MME-FQ-CSID FQ-CSID SGW-FQ-CSID FQ-CSID Charging Characteristics IE EBI S5/S8-U SGW F-TEID Bearer Level QoS type F-TEID Bearer QoS

taille 12 10 11 7 6 6 24 24 104 5 5 22 5 12 4 + contenue 50 22 22 6 taille 5 24 26 Interface S5/S8

Interface

conditions

S11

S5/S8

(b) Bearer Contexts to be created

conditions

188 Tableau G.4 Create Session Response (interprt de [22])

(a) Create Session Response

IE

type

Cause Sender F-TEID for F-TEID Control Plane PGW S5/S8 F-TEID F-TEID PAA APN Restriction Bearer Contexts Bearer Context created Bearer Contexts Bearer Context marked for removal PGW-FQ-CSID SGW-FQ-CSID IE FQ-CSID FQ-CSID

taille 10 24 24 22 5 4 + contenue 4 + contenue 22 22 type taille 5 10 24 24 26 8

Interface S11

conditions

si cest une rponse ngative S5/S8 S11 S11 Interface conditions si la reponse vient du S5/S8

(b) Inclue dans le Bearer Context created

EBI Cause S1-U SGW F-TEID F-TEID S5/S8-U PGW F-TEID F-TEID Bearer Level QoS Bearer QoS Charging Id IE type EBI Cause taille 5 10

S11

S5/S8 conditions

(c) Inclue dans le Bearer Contexts marked for removal

Interface

Tableau G.5 Delete Session Request (interprt de [22]) IE Cause Linked EPS Bearer ID (LBI) Indication Flags type EBI Indication taille 10 5 6 Interface conditions

Tableau G.6 Delete Session Response (interprt de [22]) IE type Cause taille 10 Interface conditions

189 40 + 33 (nombre de bearers conservs) + 9 (nombre de bearers supprims) octets sil est envoy par le MME sur le lien S11 lors dun handover ; 62 + 33 (nombre de bearers conservs) + 9 (nombre de bearers supprims) octets sil est envoy par le SGW sur le lien S5/S8 lors dun handover. Tableau G.7 Modify Bearer Request (interprt de [22])
(a) Modify Bearer Request

IE Indication Flags Delay Downlink Packet Notication Request Bearer Contexts to be modied

type Indication Delay Value

taille 6 5

Interface

conditions

requte de service provenant du UE tout except sur S5/S8 lors dune requte de service provenant du UE handover, multipli par le nombre de bearer dtruit

Bearer Context

4 + contenue

Bearer Contexts to be removed MME-FQ-CSID SGW-FQ-CSID IE EBI S1 eNodeB F-TEID

Bearer Context FQ-CSID FQ-CSID type F-TEID taille 5 24

4 + contenue 22 22 Interface

S11 S11 et S5/S8 S5/S8

(b) Inclue dans Bearer Contexts to be modied

conditions UE QoS aware ou durant un handover

(c) Inclue dans Bearer Contexts to be removed

IE

type EBI

taille 5

Interface

conditions

Modify Bearer Response Il fait 44 octets lors dune procdure de connexion et 44 + 43 (nombre de bearers supprims) lors dun handover. Ces valeurs sont tire du tableau G.8. Update Bearer Request Daprs le tableau G.9, pour les UE QoS aware ce message fait 86+60(nombre de TFT) octets sil sort du SGW sur le lien S11 et 64+60(nombre de TFT) octets sil sort du PGW sur le lien S5/S8. Dans tout les cas il fait cinq octets de moins pour

190 Tableau G.8 Modify Bearer Response (interprt de [22])

(a) Modify Bearer Request

IE Cause Bearer Contexts marked for removal SGW-FQ-CSID IE EBI Cause S1 SGW F-TEID

type Bearer Context FQ-CSID type taille 5 10 24

taille 10 4 + contenue 22 Interface

Interface

conditions handover

(b) Inclue dans Bearer Context marked for removal

conditions

F-TEID

les UE QoS unaware. Update Bearer Response Daprs le tableau G.10 ce message fait 63 octets sil sort du MME sur le lien S11 et 85 octets sil sort du SGW sur le lien S5/S8. Create Bearer Request Daprs le tableau G.11 pour le UE QoS aware ce message fait 153 + 60 (nombre de TFT) octets sil sort du SGW sur le lien S11 et 115 + 60 (nombre de TFT) octets sil sort du PGW sur le lien S5/S8. Dans tout les cas il fait cinq octets de moins pour les UE QoS unaware. Create Bearer Response Il fait 133 octets sur le lien S11. Sur le lien S5/S8 ce message fait 133 octets si la requte Create Bearer Request correspondante sest rendue jusquau eNodeB et 89 octets sinon. Ces valeurs sont tir du tableau G.12. Bearer Resource Command Tel que reprsent au tableau G.13, ce message fait une taille de 57 + 60 (nombre dIP) octets si cest une demande dajout de services dans un bearer et 26 octets de moins si cest une demande de suppression de services. Delete Bearer Request Daprs le tableau G.14 pour les UE QoS aware ce message fait 66 octets sur le lien S11 et 44 sur le lien S5/S8. Il fait cinq octets de moins pour les UE QoS unaware. Delete Bearer Response Daprs le tableau G.15 ce message fait 63 octets sur le lien S11 et 88 sur le lien S5/S8.

191

Tableau G.9 Update Bearer Request (interprt de [22])

(a) Update Bearer Request

IE Bearer Contexts PTI APN-AMBR PGW-FQ-CSID SGW-FQ-CSID

type Bearer Context

taille 4 + contenue 5

Interface

conditions si le UE est QoS aware si la requete est pass par le PGW si la requete est pass par le SGW conditions si cest une modication de TFT si cest une modication de QoS

AMBR FQ-CSID FQ-CSID

12 22 22 S11

(b) Inclue dans le Bearer Context created

IE EBI TFT Bearer Level QoS

type

taille 5 4 + 60 (nombre de SFI) 26

Interface

Bearer TFT Bearer QoS

Tableau G.10 Update Bearer Response (interprt de [22])

(a) Update Bearer Response

IE

type

Cause Bearer Context MME-FQ-CSID SGW-FQ-CSID FQ-CSID FQ-CSID IE

taille 10 4 + contenue 22 22 taille 5 10

Interface

conditions

S11 S5/S8 S5/S8 Interface

si la reponse vient du S11

(b) Inclue dans le Bearer Context

type EBI Cause

conditions

192

Tableau G.11 Create Bearer Request (interprt de [22])

(a) Create Bearer Request

IE PTI

type

LBI EBI Bearer Context PGW-FQ-CSID FQ-CSID SGW-FQ-CSID FQ-CSID IE EBI type

taille 5 5 4 + contenue 22 22

Interface

conditions le UE est QoS aware

S11 Interface conditions

(b) Inclue dans le Bearer Context

TFT Bearer TFT S1-U SGW F-TEID F-TEID S5/8-U PGW F-TEID F-TEID Bearer Level QoS Bearer QoS Charging Id

taille 5 4 + 60 (nombre de SFI) 24 24 26 8

S11

S5/S8

Tableau G.12 Create Bearer Response (interprt de [22])

(a) Create Bearer Response

IE

type

Cause Bearer Context MME-FQ-CSID SGW-FQ-CSID FQ-CSID FQ-CSID

taille 10 4 + contenue 22 22

Interface

conditions

S11 S5/S8 S11 S5/S8 taille 5 10 24 24 24 24

si la reponse vient du S11 si la reponse vient du S11 conditions

(b) Inclue dans le Bearer Context

IE EBI Cause S1-U eNodeB F-TEID S1-U SGW F-TEID S5/8-U SGW F-TEID S5/8-U PGW F-TEID

type

Interface

F-TEID F-TEID F-TEID F-TEID

S11 S11 S5/S8 S5/S8

193

Tableau G.13 Bearer Resource Command (interprt de [22]) IE type LBI EBI PTI Flow QoS TAD EBI taille 5 5 26 4 + 60 (nombre de SFI) 5 Interface conditions

sauf pour resource release

Tableau G.14 Delete Bearer Request (interprt de [22]) IE type EBI PTI PGW-FQ-CSID FQ-CSID SGW-FQ-CSID FQ-CSID Cause taille 5 5 22 22 10 Interface conditions si le UE est QoS aware S11 si la requete est du un handover

Tableau G.15 Delete Bearer Response (interprt de [22])

(a) Delete Bearer Response

type Cause Bearer Context MME-FQ-CSID SGW-FQ-CSID IE FQ-CSID FQ-CSID taille 5 10

IE

taille 10 4 + contenue 22 22 Interface

Interface

conditions

S11 S5/S8 S5/S8 conditions

(b) Inclue dans le Bearer Context

type EBI Cause

194 Create Indirect Data Forwarding Tunnel Request Daprs le tableau G.16 ce message fait 69 octets. Tableau G.16 Create Indirect Data Forwarding Tunnel Request (interprt de [22])
(a) Create Indirect Data Forwarding Tunnel Request

IE type Bearer Context IE

taille 4 + contenue

Interface

conditions

(b) Inclue dans le Bearer Context

type F-TEID F-TEID

EBI eNodeB F-TEID for DL data forwarding SGW F-TEID for DL data forwarding

taille 5 24 24

Interface

conditions

Create Indirect Data Forwarding Tunnel Response Daprs le tableau G.17 ce message fait 89 octets. Tableau G.17 Create Indirect Data Forwarding Tunnel Response (interprt de [22])
(a) Create Indirect Data Forwarding Tunnel Response

IE

type Cause Bearer Context IE

taille 10 4 + contenue

Interface

conditions

(b) Inclue dans le Bearer Context

type

EBI Cause S1-U SGW F-TEID for DL data forwarding SGW F-TEID for DL data forwarding

F-TEID F-TEID

taille 5 10 24 24

Interface

conditions

Delete Bearer Command Daprs le tableau G.18 ce message fait 21 octets. Delete Indirect Data Forwarding Tunnel Request Ce message ne contient aucun IE sa taille correspond donc celle de len-tte du protocole GTP-C soit 12 octets. Delete Indirect Data Forwarding Tunnel Response Daprs le tableau G.19 ce message fait 22 octets.

195

Tableau G.18 Delete Bearer Command (interprt de [22])

(a) Delete Bearer Command

IE type Bearer Context IE type EBI

taille 4 + contenue taille 5

Interface

conditions

(b) Inclue dans le Bearer Context

Interface

conditions

Tableau G.19 Delete Indirect Data Forwarding Tunnel Response (interprt de [22]) IE type Cause taille 10 Interface conditions

196 ANNEXE H Tailles des messages Diameter

Dans cette annexe nous dtaillons la taille des messages Diameter que nous avons utiliss dans nos simulateurs. Ces tailles ont t calcules grce au tableau H.1 gnr grce Rigney et al. [92], Calhoun et al. [48], Loughney [74], Calhoun et al. [49] et Hakala et al. [66] et des documents 23.003 [2], 23.011 [3], 24.008 [10], 29.002 [15], 29.060 [16], 29.061 [17], 29.212 [18], 29.214 [19], 29.229 [20], 29.272 [21], 29.274 [22], 29.329 [25], 32.298 [26], 32.299 [27], 32.422 [28]. Tableau H.1 Taille des AVP du protocole Diameter [2, 3, 10, 15, 16, 17, 18, 19, 20, 21, 22, 25, 26, 27, 28, 92, 48, 74, 49, 66] IE 3GPP-Charging-Characteristics 3GPP-MS-TimeZone 3GPP-User-Location-Info 3GPP-RAT-Type 3GPP-SGSN-MCC-MNC 3GPP-SGSN-Address 3GPP-SGSN-IPv6-Address Access-Restriction-Data Access-Network-Charging-Address Access-Network-Charging-Identier-Gx Access-Network-Charging-Identier-Value Acct-Multi-Session-Id AF-Charging-Identier AF-Signalling-Protocol Age-Of-Location-Information All-APN-Congurations-Included-Indicator Allocation-Retention-Priority AMBR AN-GW-Address APN-Aggregate-Max-Bitrate-DL taille en octets 16 16 24 16 20 24 36 16 32 84 24 68 24 16 16 16 60 44 32 16

197 IE APN-Aggregate-Max-Bitrate-UL APN-Conguration APN-Conguration-Prole APN (depuit lIE GTP) APN-OI-Replacement Auth-Application-Id Authentication-Info AUTN AUTS Bearer-Control-Mode Bearer-Identier Bearer-Operation Bearer-Usage Call-Barring-Infor-List Called-Station-ID CC-Correlation-Id CC-Input-Octets CC-Money CC-Output-Octets CC-Request-Number CC-Request-Type CC-Service-Specic-Units CC-Session-Failover CC-Sub-Session-Id CC-Time CC-Total-Octets CC-Unit-Type CGI Charging-Information Charging-Rule-Base-Name Charging-Rule-Denition Charging-Rule-Install Charging-Rule-Name Charging-Rule-Remove taille en octets 16 500 544 112 32 16 412 28 28 16 24 16 16 36 32 24 20 76 20 16 16 20 16 20 16 20 16 24 300 24 828 960 24 60

198 IE Charging-Rule-Report Check-Balance-Result Condentiality-Key (CK) CoA-Information CoA-IP-Address Complete-Data-List-Included-Indicator Context-Identier Cost-Information Cost-Unit Credit-Control-Failure-Handling CSG-Id CSG-Information-Reporting CSG-Subscription-Data Currency-Code Current-Location-Retrieved Default-EPS-Bearer-QoS Destination-Host Destination-Realm Direct-Debiting-Failure-Handling ECGI EPS-Location-Information EPS-Subscribed-QoS Prole EUTRAN-Cell-Global-Identity EUTRAN-Vector Event-Report-Indication Event-Timestamp Event-Trigger Experimental-Result Experimental-Result-Code Expiration-Date Exponent Feature-List Feature-List-ID Filter-Id taille en octets 340 16 28 112 32 16 16 100 24 16 16 16 44 16 16 88 36 36 16 20 356 88 20 140 536 16 16 44 16 16 16 16 16 20

199 IE Final-Unit-Action Final-Unit-Indication Flow-Description Flow-Direction Flow-Information Flow-Label Flow-Number Flows Flow-Status Framed-IP-Address Framed-IPv6-Prex Geodetic-Information Geographical-Information GERAN-Vector GMLC-Number GMLC-Restriction GPRS-Subscription-Data Granted-Service-Unit G-S-U-Pool-Identier G-S-U-Pool-Reference Guaranteed-Bitrate-DL Guaranteed-Bitrate-UL HPLMN-ODB ICS-Indicator Integrity-Key (IK) Immediate Response Preferred IP address (depuit GTP) Item-Number IP-CAN-Type KASME Kc LCS-Info LCS-PrivacyException Location-Area-Identity taille en octets 16 224 112 16 340 72 16 60 16 24 36 24 20 92 24 16 232 200 16 92 16 16 16 16 28 16 28 16 16 28 20 120 84 20

200 IE Max-Requested-Bandwidth-DL Max-Requested-Bandwidth-UL Media-Component-Number Metering-Method MIP6-Agent-Info MIP6-Home-Link-Prex MIP-Home-Agent-Address MIP-Home-Agent-Host MME-Location-Information MN Network Access Identier (NAI) Monitoring-Key MSISDN Multiple-Services-Credit-Control (for Request) Multiple-Services-Credit-Control (for Answer) Multiple-Services-Indicator Network-Access-Mode Network-Request-Support Notication-To-UE-User Number Of Requested Vectors Oine OMC-Id Online Operator-Determined-Barring Origin-Host Origin-Realm Origin-State-Id Packet-Filter-Content Packet-Filter-Identier Packet-Filter-Information Packet-Filter-Operation Packet-Filter-Usage PCC-Rule-Status PDN-Connection-ID PDN-GW-Allocation-Type taille en octets 16 16 16 16 96 28 28 28 164 64 16 20 428 604 16 16 16 16 16 16 24 16 16 36 36 16 112 24 324 16 16 16 24 16

201 IE PDN-Type PDP-Address PDP-Context PDP-Type PLMN-Client Precedence Pre-emption-Capability Pre-emption-Vulnerability Primary-Charging-Collection-Function-Name Primary-Event-Charging-Function-Name Priority-Level Proxy-Host Proxy-Info Proxy-State QCI QoS-Information QoS-Negotiation QoS-Rule-Base-Name QoS-Rule-Name QoS-Rule-Report QoS-Subscribed QoS-Upgrade RAT-Frequency-Selection-Priority-ID Rating-Group RAI RAND RAT-Type Re-Auth-Request-Type Redirect-Address-Type Redirect-Host Redirect-Host-Usage Redirect-Max-Cache-Time Redirect-Server Redirect-Server-Address taille en octets 16 28 204 16 16 16 16 16 72 72 16 36 72 24 16 208 16 24 24 78 24 16 16 16 24 28 16 16 16 36 16 16 64 36

202 IE Regional-Subscription-Zone-Code Reporting-Level Requested-EUTRAN-Authentication-Info Requested-Action Requested-Service-Unit Resource-Allocation-Notication Restriction-Filter-Rule Result-Code Re-synchronization-Info Revalidation-Time Roaming-Restricted-Due-To-Unsupported-Feature Route-Record Routing-Area-Identity Rule-Activation-Time Rule-Deactivation-Time Rule-Failure-Code Secondary-Charging-Collection-Function-Name Secondary-Event-Charging-Function-Name Security-Parameter-Index Served-Party-IP-Address Service-Area-Identity Service-Context-Id Service-Identier Service-Parameter-Info Service-Parameter-Type Service-Parameter-Value Service-Selection Service-Type Service-Type-Identity Session-Id Session-Release-Cause SGSN-Location-Information SRES SS-Code taille en octets 16 16 88 16 184 16 112 16 44 16 16 36 24 16 16 16 72 72 72 28 24 48 16 52 16 24 76 60 16 68 16 180 16 24

203 IE SS-Status STN-SR Subscriber-Status Subscription-Data Subscription-Id Subscription-Id-Data Subscription-Id-Type Supported-Features TAI Tari-Change-Usage Tari-Time-Change Teleservice-List Termination-Cause TFT-Filter TFT-Packet-Filter-Information ToS-Trac-Class Trace-Collection-Entity Trace-Data Trace-Depth Trace-Event-List Trace-Interface-List Trace-NE-Type-List Trace-Reference TS-Code Tunnel-Header-Filter Tunnel-Header-Length Tunnel-Information ULA-Flags ULR-Flags Unit-Value Usage-Monitoring-Information Usage-Monitoring-Level Usage-Monitoring-Report Usage-Monitoring-Support taille en octets 16 28 16 1472 52 24 16 60 56 16 16 36 16 112 300 16 28 164 16 24 24 16 20 24 112 16 68 16 16 48 476 16 16 16

204 IE Used-Service-Unit User-Equipment-Info User-Equipment-Info-Type User-Equipment-Info-Value User-Name UTRAN-Vector Validity-Time Value-Digits Vendor-Id Visited PLMN Id Visited-Network-Identier VPLMN-Dynamic-Address-Allowed XRES Update Location Request fait 96 octets daprs le tableau H.2. Update Location Answer fait 1524 octets daprs le tableau H.3. Authentication Information Request fait 152 octets daprs le tableau H.4. Authentication Information Answer fait 448 octets daprs le tableau H.5. Insert Subscriber Data Request fait 1520 octets daprs le tableau H.6. Insert Subscriber Data Answer fait 392 octets daprs le tableau H.7. Indication of IP-CAN Session Establishment cest un message de type Credit Control Request pouvant possder les AVP reprsents au tableau H.8. En prenant les AVP ncessaires pour la connexion dun UE on obtient le tableau H.10 ce qui fait un total de 728 octets. Acknowledge IP-CAN Session Establishment ce message est de type Credit Control Answer pouvant possder les AVP reprsents au tableau H.9. Selon le tableau H.12 ce message fait 1472 octets lorsquil est utilis pour la cration dun nouveau bearer (connexion dun UE). Indication of IP-CAN Session Modication ce message est de type Credit Control Request (voir tableau H.8). Ce message ressemble au Indication of IP-CAN Session Establishment mais sapplique aux modications de session soit une cration/ modication/suppression de bearer. Daprs le tableau H.11 il fait 1264 octets. Acknowledge of IP-CAN Session Modication ce message est de type Credit Control Answer (voir tableau H.9). Il est en tout point identique au message Acknowtaille en octets 200 52 16 24 28 168 16 20 16 16 44 16 28

205 ledge IP-CAN Session Establishment (voir tableau H.12) mais ne possde pas lAVP Default-EPS-Bearer-QoS de 88 octets. Il fait donc 1384 octets lors de la cration dun nouveau bearer et 2284 octets lors dune destruction. Indication of IP-CAN Session Termination est un Credit Control Request (voir tableau H.8) sans AVP optionnel, soit 244 octets. Acknowledge of IP-CAN Session Termination est un Credit Control Answer (voir tableau H.9) avec pour seul AVP optionnel un Charging-Rule-Remove. Ce message fait donc 328 octets. Policy and Charging Rules Provision est un message de type Re-Authentication Request pouvant possder les AVP reprsents au tableau H.13. En prenant les AVP ncessaires on obtient le tableau H.15 qui nous indique que ce message fait 1432 octets. Acknowledge Policy and Charging Rules Provision message de type Re-Authentication Answer (voir tableau H.14). Daprs le tableau H.16 il fait 440 octets. Tableau H.2 Update Location Request (interprt de [21]) IE AVP IMSI User-Name Update-Location-Request (ULR) Flags Visited-PLMN-Id RAT Type taille 28 16 16 16 Interface conditions

Tableau H.3 Update Location Answer (interprt de [21]) IE AVP Result Result-Code ULA-Flags Subscription-Data taille 16 16 1472 Interface conditions

Tableau H.4 Authentication Information Request (interprt de [21]) IE AVP IMSI User-Name Requested EUTRAN Authentication Info Visited PLMN ID taille 28 88 16 Interface conditions

206 Tableau H.5 Authentication Information Answer (interprt de [21]) IE AVP Result Result-Code Authentication-Info taille 16 412 Interface conditions

Tableau H.6 Insert Subscriber Data Request (interprt de [21]) IE AVP IMSI User-Name Subscription Data taille 28 1472 Interface conditions

Tableau H.8 Credit-Control-Request (interprt de [66]) type de IE Session-Id Auth-Application-Id Origin-Host Origin-Realm Destination-Realm CC-Request-Type CC-Request-Number n des AVP obligatoires Destination-Host Origin-State-Id Subscription-Id Supported-Features Network-Request-Support Packet-Filter-Information Packet-Filter-Operation Bearer-Identier Bearer-Operation 36 16 52 60 16 324 16 24 16 taille en octets 68 16 36 36 36 16 16

Tableau H.7 Insert Subscriber Data Answer (interprt de [21]) IE AVP Result Result-Code IMS Voice over PS Sessions Supported EPS-Location-Information taille 16 16 356 Interface conditions

207 type de IE Framed-IP-Address Framed-IPv6-Prex IP-CAN-Type 3GPP-RAT-Type RAT-Type Termination-Cause User-Equipment-Info QoS-Information QoS-Negotiation QoS-Upgrade Default-EPS-Bearer-QoS AN-GW-Address 3GPP-SGSN-MCC-MNC 3GPP-SGSN-IPv6-Address RAI 3GPP-User-Location-Info 3GPP-MS-TimeZone Called-Station-ID PDN-Connection-ID Bearer-Usage Online Oine TFT-Packet-Filter-Information Charging-Rule-Report Event-Trigger Event-Report-Indication Access-Network-Charging-Address Access-Network-Charging-Identier-Gx CoA-Information Usage-Monitoring-Information Proxy-Info Route-Record taille en octets 24 36 16 16 16 16 52 208 16 16 88 32 20 36 24 24 16 32 24 16 16 16 300 340 16 536 32 84 112 476 72 36

Les AVP suivant ne sont utiliss que dans les simulateurs bass sur les architectures 402, 403 et 404.

208

Tableau H.9 Credit-Control-Answer (interprt de [18]) IE / AVP taille Session-Id 68 Auth-Application-Id 16 Origin-Host 36 Origin-Realm 36 Result-Code 16 Experimental-Result 44 CC-Request-Type 16 CC-Request-Number 16 n des AVP obligatoires Supported-Features 60 Bearer-Control-Mode 16 Event-Trigger 16 Origin-State-Id 16 Redirect-Host 36 Redirect-Host-Usage 16 Redirect-Max-Cache-Time 16 Charging-Rule-Remove 60 Charging-Rule-Install 960 Charging-Information 300 Online 16 Oine 16 QoS-Information 208 Revalidation-Time 16 Default-EPS-Bearer-QoS 88 Bearer-Usage 16 3GPP-User-Location-Info 24 Usage-Monitoring-Information 476 CSG-Information-Reporting 16 Route-Record 36

209

Tableau H.10 Indication of IP-CAN Session Establishment : connexion (interprt de [18]) IE / AVP Session-Id Auth-Application-Id Origin-Host Origin-Realm Destination-Realm CC-Request-Type CC-Request-Number n des AVP obligatoires Subscription-Id Network-Request-Support Framed-IP-Address Framed-IPv6-Prex IP-CAN-Type RAT-Type Default-EPS-Bearer-QoS AN-GW-Address 3GPP-MS-TimeZone Called-Station-ID PDN-Connection-ID Bearer-Usage Access-Network-Charging-Address Access-Network-Charging-Identier-Gx APN-Aggregate-Max-Bitrate-DL APN-Aggregate-Max-Bitrate-UL taille 68 16 36 36 36 16 16 52 16 24 36 16 16 88 32 16 32 24 16 32 84 16 16

210 Tableau H.11 Indication of IP-CAN Session Establishment/Modication : cration, modication ou suppression de bearer (interprt de [18]) IE / AVP Session-Id Auth-Application-Id Origin-Host Origin-Realm Destination-Realm CC-Request-Type CC-Request-Number n des AVP obligatoires Packet-Filter-Information Packet-Filter-Operation QoS-Information Charging-Rule-Report Event-Trigger Access-Network-Charging-Address Access-Network-Charging-Identier-Gx taille 68 16 36 36 36 16 16 324 16 208 340 16 32 84

Tableau H.12 Acknowledge IP-CAN Session Establishment (interprt de [18]) IE / AVP taille condition Session-Id 68 Auth-Application-Id 16 Origin-Host 36 Origin-Realm 36 Result-Code 16 Experimental-Result 44 CC-Request-Type 16 CC-Request-Number 16 n des AVP obligatoires Supported-Features 60 seulement pour 23.402 [9] Charging-Rule-Remove 60 ou Charging-Rule-Install Charging-Rule-Install 960 ou Charging-Rule-Remove Charging-Information 300 QoS-Information 208 Revalidation-Time 16 Default-EPS-Bearer-QoS 88 Bearer-Usage 16 3GPP-User-Location-Info 24 Usage-Monitoring-Information 476 CSG-Information-Reporting 16

211

Tableau H.13 Re-Auth-Request (interprt de [18]) IE / AVP taille Session-Id 68 Auth-Application-Id 16 Origin-Host 36 Origin-Realm 36 Destination-Realm 36 Destination-Host 36 Re-Auth-Request-Type 16 n des AVP obligatoires Session-Release-Cause 16 Origin-State-Id 16 Event-Trigger 16 Event-Report-Indication 536 Charging-Rule-Remove 60 Charging-Rule-Install 960 Default-EPS-Bearer-QoS 88 QoS-Information 208 Revalidation-Time 16 Usage-Monitoring-Information 476 Proxy-Info 72 Route-Record 36

212

Tableau H.14 Re-Auth-Answer (interprt de [18]) IE / AVP Session-Id Origin-Host Origin-Realm n des AVP obligatoires Result-Code Experimental-Result Origin-State-Id IP-CAN-Type RAT-Type AN-GW-Address 3GPP-SGSN-MCC-MNC 3GPP-SGSN-Address 3GPP-SGSN-IPv6-Address RAI 3GPP-User-Location-Info 3GPP-MS-TimeZone Charging-Rule-Report Access-Network-Charging-Address Access-Network-Charging-Identier-Gx Proxy-Info taille 68 36 36 16 44 16 16 16 32 20 24 36 24 24 16 340 32 84 72

Tableau H.15 Policy and Charging Rules Provision (interprt de [18]) IE / AVP taille condition Session-Id 68 Auth-Application-Id 16 Origin-Host 36 Origin-Realm 36 Destination-Realm 36 Destination-Host 36 Re-Auth-Request-Type 16 n des AVP obligatoires Event-Trigger 16 seulement pour 23.402 [9] Event-Report-Indication 536 seulement pour 23.402 [9] Charging-Rule-Install 960 QoS-Information 208

213 Tableau H.16 Acknowledge Policy and Charging Rules Provision (interprt de [18]) IE / AVP Session-Id Origin-Host Origin-Realm n des AVP obligatoires Result-Code Experimental-Result IP-CAN-Type RAT-Type AN-GW-Address 3GPP-User-Location-Info 3GPP-MS-TimeZone Access-Network-Charging-Address Access-Network-Charging-Identier-Gx taille 68 36 36 16 44 16 16 32 24 16 32 84

Gateway Control Session Establishment est un Credit Control Request (voir tableau H.8). Daprs le tableau H.17 il fait 932 octets. Acknowledge Gateway Control Session Establishment est un message de type Credit Control Answer (voir tableau H.9). Il est identique au message Acknowledge IP CAN Session Establishment utilis dans larchitecture 23.401 [8] mais contient lAVP Supported-Features en plus. Daprs le tableau H.12 il fait donc 1532 octets. Gateway Control Session Modication est un message de type Credit Control Request (voir tableau H.8). Daprs le tableau H.18 il fait 886 octets. Gateway Control Session Modication reply or Acknowledgement ce message est identique Acknowledge IP-CAN Session Establishment mais ne possde pas lAVP Default-EPS-Bearer-QoS de 88 octets. Il fait donc 1444 octets lorsquil est utilis pour une cration de bearer et 2324 octets lors dune destruction. Gateway Control and QoS Rules Provision est un message de type Re-Authentication Request (voir le tableau H.13). Daprs le tableau H.15 il fait 1984 octets. Gateway Control and QoS Rules Provision Acknowledgement de type Re-Authentication Answer (voir tableau H.14). Daprs le tableau H.16 il fait 440 octets. Gateway Control Session Termination est un message de type Credit Control Request (voir tableau H.8) sans AVP optionnel, il fait donc 244 octets. Acknowledge Gateway Control Session Termination est un message de type Credit Control Answer (voir tableau H.9). Son seul AVP optionnel est un Charging-Rule-Remove. Il fait donc 328 octets.

214

Tableau H.17 Gateway Control Session Establishment (interprt de [18]) IE / AVP Session-Id Auth-Application-Id Origin-Host Origin-Realm Destination-Realm CC-Request-Type CC-Request-Number n des AVP obligatoires Subscription-Id Network-Request-Support Framed-IP-Address Framed-IPv6-Prex IP-CAN-Type RAT-Type User-Equipment-Info QoS-Information Default-EPS-Bearer-QoS AN-GW-Address 3GPP-SGSN-MCC-MNC 3GPP-User-Location-Info 3GPP-MS-TimeZone Called-Station-ID PDN-Connection-ID APN-Aggregate-Max-Bitrate-DL APN-Aggregate-Max-Bitrate-UL taille 68 16 36 36 36 16 16 52 16 24 36 16 16 52 208 88 32 20 24 16 32 24 16 16

215

Tableau H.18 Gateway Control Session Modication : cration, modication ou suppression de bearer (interprt de [18]) IE / AVP taille Session-Id 68 Auth-Application-Id 16 Origin-Host 36 Origin-Realm 36 Destination-Realm 36 CC-Request-Type 16 CC-Request-Number 16 n des AVP obligatoires Packet-Filter-Information 324 Packet-Filter-Operation 16 QoS-Information 208 Event-Trigger 16 QoS-Rule-Report 78

216 ANNEXE I Exemple dapplication de QoS sous GNU/Linux

Ceci est un exemple de chier de conguration permettant de crer plusieurs classes de QoS direntes sous GNU/Linux. Deux personnes partagent une connexion, elles ont chacun leurs branches ce qui permet de rpartir quitablement le trac entre eux. Dans chacune des branches on trouve trois les permettant de prioriser le trac Secure Shell (SSH) par rapport au web, lui-mme prioritaire par rapport aux autres types de trac comme le P2P. La seule le partage est une le de trs haute priorit pour le trac de VoIP.
#!/bin/bash TC="/sbin/tc" EXTIF="ppp0" # Nettoyage ${TC} qdisc del dev ${EXTIF} root # # # # # # # # # # # # # # # # # # # #

&> /dev/null

1: prio / \ _____/ \_____ | | 1:1 1:2 | | 2: bfifo 3: htb | 3:1 / \ ____________/ \___________ | | 3:2 personne #1 3:3 personne #2 / | \ / | \ ____/ | \____ ____/ | \____ | | | | | | 3:21 3:22 3:23 3:31 3:32 3:33 | | | | | | 21: 22: 23: 31: 32: 33: sfq sfq sfq sfq sfq sfq

UPRATE="440" # Upload Rates en kbps # par defaut tout va dans 1:2 ${TC} qdisc add dev $EXTIF root handle 1: prio bands 2 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 # creation de la file haute priorite ${TC} qdisc add dev $EXTIF parent 1:1 handle 2: bfifo # tete du HTB, les paquet ne correspondant a aucun filtre # vont dans 3:23 ${TC} qdisc add dev $EXTIF parent 1:2 handle 3: htb default 23

217

# limitation du debit total du HTB # les classe HTB se partage ce debit ${TC} class add dev $EXTIF parent 3:0 classid 3:1 htb rate ${UPRATE}kbit # on divise le trafic de maniere equitable entre les 2 personnes # (si lun des deux nutilise pas sont trafic, le reste ira a lautre) ${TC} class add dev $EXTIF parent 3:1 classid 3:2 htb rate $((UPRATE/2))kbit ceil ${UPRATE}kbit ${TC} class add dev $EXTIF parent 3:1 classid 3:3 htb rate $((UPRATE/2))kbit ceil ${UPRATE}kbit ################################################## ## creation des filtre classes feuille du HTB ## ainsi que des files dattente correspondantes ################################################## ########## personne #1 # ssh ${TC} class add dev $EXTIF parent prio 1 quantum 1500 ${TC} qdisc add dev $EXTIF parent # web ${TC} class add dev $EXTIF parent prio 2 quantum 1500 ${TC} qdisc add dev $EXTIF parent # autres ${TC} class add dev $EXTIF parent prio 3 quantum 1500 ${TC} qdisc add dev $EXTIF parent ######### personne #2 # ssh ${TC} class add dev $EXTIF parent prio 1 quantum 1500 ${TC} qdisc add dev $EXTIF parent # web ${TC} class add dev $EXTIF parent prio 2 quantum 1500 ${TC} qdisc add dev $EXTIF parent # autres ${TC} class add dev $EXTIF parent prio 3 quantum 1500 ${TC} qdisc add dev $EXTIF parent

3:2 classid 3:21 htb rate $((UPRATE/2 * 20/100))kbit ceil ${UPRATE}kbit \ 3:21 handle 21: sfq perturb 10 3:2 classid 3:22 htb rate $((UPRATE/2 * 60/100))kbit ceil ${UPRATE}kbit \ 3:22 handle 22: sfq perturb 10 3:2 classid 3:23 htb rate $((UPRATE/2 * 20/100))kbit ceil ${UPRATE}kbit \ 3:23 handle 23: sfq perturb 10

3:3 classid 3:31 htb rate $((UPRATE/2 * 25/100))kbit ceil ${UPRATE}kbit \ 3:31 handle 31: sfq perturb 10 3:3 classid 3:32 htb rate $((UPRATE/2 * 50/100))kbit ceil ${UPRATE}kbit \ 3:32 handle 32: sfq perturb 10 3:3 classid 3:33 htb rate $((UPRATE/2 * 25/100))kbit ceil ${UPRATE}kbit \ 3:33 handle 33: sfq perturb 10

############################## ## creation des filtre dirigeant les paquets dans les classes ############################## ######### Filtre 1:0 # trafic avec TOS a EF ${TC} filter add dev $EXTIF parent 1:0 protocol ip prio 1 u32 match ip tos 0xb8 0xff flowid 1:1 # tous le reste va dans 1:2 (donc 3:0) ######### Filtre 3:0

218

# les paquets de la personne #2 # utilise un marquage realise par netfilter (dont la configuration est plus souple) ${TC} filter add dev $EXTIF parent 3:0 protocol ip prio 1 handle 3 fw classid 3:3 # les paquets de la personne #1 # tous le reste ${TC} filter add dev $EXTIF parent 3:0 protocol ip prio 3 u32 match ip dst 0.0.0.0/0 flowid 3:2 ######### Les filtres relatif a la branche HTB de la personne #2 # file prio 1 # ssh ${TC} filter add dev $EXTIF parent 3:3 protocol ip prio 1 u32 match ip dport 22 0xffff flowid 3:31 ${TC} filter add dev $EXTIF parent 3:3 protocol ip prio 2 u32 match ip sport 22 0xffff flowid 3:31 # file prio 2 # http ${TC} filter add dev $EXTIF parent 3:3 protocol ip prio 5 u32 match ip dport 80 0xffff flowid 3:32 # dns ${TC} filter add dev $EXTIF parent 3:3 protocol ip prio 6 u32 match ip dport 53 0xffff flowid 3:32 # https ${TC} filter add dev $EXTIF parent 3:2 protocol ip prio 7 u32 match ip dport 443 0xffff flowid 3:32 # file prio 3 # tout le reste ${TC} filter add dev $EXTIF parent 3:3 protocol ip prio 8 u32 match ip dst 0.0.0.0/0 flowid 3:33 ######### Les filtres relatif a la branche HTB de la personne #1 # file prio 1 # ssh ${TC} filter add dev $EXTIF parent 3:2 protocol ip prio 1 u32 match ip dport 22 0xffff flowid 3:21 ${TC} filter add dev $EXTIF parent 3:2 protocol ip prio 1 u32 match ip sport 22 0xffff flowid 3:21 # file prio 2 # web ${TC} filter add ${TC} filter add ${TC} filter add # dns ${TC} filter add ${TC} filter add # email ${TC} filter add

dev $EXTIF parent 3:2 protocol ip prio 2 u32 match ip dport 80 0xffff flowid 3:22 dev $EXTIF parent 3:2 protocol ip prio 2 u32 match ip sport 80 0xffff flowid 3:22 dev $EXTIF parent 3:2 protocol ip prio 2 u32 match ip dport 443 0xffff flowid 3:22 dev $EXTIF parent 3:2 protocol ip prio 2 u32 match ip sport 53 0xffff flowid 3:22 dev $EXTIF parent 3:2 protocol ip prio 2 u32 match ip dport 53 0xffff flowid 3:22 dev $EXTIF parent 3:2 protocol ip prio 2 u32 match ip dport 25 0xffff flowid 3:22

# file prio 3 # on a specifie a la racine du HTB que tout paquet ne correspondant au aucun filtre va dans cette classe.