THSE

En vue de l'obtention du

DOCTORAT DE LUNIVERSIT DE TOULOUSE

Dlivr par Institut National Polytechnique de Toulouse Discipline ou spcialit : Rseaux, Tlcommunications, Systme et Architecture

Prsente et soutenue par Mohamad Salhani Le 23 Octobre 2008 Titre :

Modlisation et Simulation des Rseaux Mobiles de 4me Gnration

JURY Monique Becker Francine Krief Guillaume Urvoy-Keller Andr-Luc Beylot Michel Diaz Riadh Dhaou Prsidente Rapporteur Rapporteur Examinateur Examinateur Examinateur Professeur Telecom & Management Sud Paris Professeur ENSEIRB Matre de Confrences HDR EURECOM Professeur INPT/ENSEEIHT Directeur de recherches du CNRS Matre de Confrences INPT/ENSEEIHT

Ecole doctorale : Mathmatique, Informatique et Tlcommunication de Toulouse Unit de recherche : Institut de Recherche en Informatique de Toulouse (IRIT-ENSEEIHT) Directeur(s) de Thse : Andr-Luc Beylot Encadrant : Riadh Dhaou

Cette thse est ddie

Mes parents, Ma famille, Mes ami(e)s, Tous ceux qui maiment et que jaime.

REMERCIEMENTS

Les travaux prsents dans ce mmoire ont t effectus lInstitut de Recherche en Informatique de Toulouse (IRIT-ENSEEIHT). Nombreux sont ceux que je voudrais remercier pour mavoir aid, soutenu ou accompagn durant ces trois annes de thse. Cest pour leur montrer tout ma gratitude et reconnaissance que je leur ddie cette page. Je tiens remercier mon directeur de thse, Monsieur Andr-Luc Beylot, professeur des universits lIRIT-ENSEEIHT, pour mavoir accueilli dans son laboratoire. Je tiens galement remercier mon encadrant, Monsieur Riadh Dhaou, Matre de confrences lIRIT-ENSEEIHT pour avoir su me guider avec attention et gentillesse pendant ces trois annes. Je tiens remercier ces deux encadrants pour toute lattention quils mont porte et pour les moyens mis ma disposition durant ces trois annes de thse. Leurs prcieux conseils de tous ordres, leur disponibilit, leur confiance, leur exprience et leurs grandes comptences ont permis laccomplissement de ce travail. Quils trouvent ici les marques de ma reconnaissance et de mon respect. Jexprime toute ma gratitude lensemble de jury pour lhonneur quils mont fait davoir accept dtre prsident, rapporteurs et membres de jury de cette thse. Jexprime mes sincres remerciements lensemble du laboratoire. Jadresse mes remerciements luniversit de Damas, qui a financ mes tudes en France. Je souhaite exprimer toute ma reconnaissance mes parents. Grce eux, jai russi toutes les tapes que jai passes dans ma vie. Je remercie aussi mes deux frres Khaled et Omar et mes surs Khalida, Zoubida, Tahani et Iman pour leur soutien constant. Je voudrais remercier galement mes ami(e)s de laboratoire, nous avons pass avec eux de bons moments. Je salue enfin les membres du laboratoire TSA en commenant par son directeur et sa secrtaire.

vi

TABLE DES MATIERES

REMERCIEMENTS .................................................................................................. v LISTE DES FIGURES ............................................................................................xiii LISTE DES TABLEAUX....................................................................................... xvii LISTE DES ACRONYMES.................................................................................... xix INTRODUCTION ...................................................................................................... 1

CHAPITRE I - Etat de lart....................................................................................... 5 1. 2. Introduction ......................................................................................................... 7 Les rseaux WiMAX........................................................................................... 7

2.1. Standard de linterface air IEEE 802.16.............................................................. 7 2.2. Pile protocolaire .................................................................................................. 8 2.3. Fonctionnalits .................................................................................................... 9 2.4. QoS ...................................................................................................................... 9 2.4.1. Connexion ........................................................................................................... 9 2.4.2. Flux de service................................................................................................... 10 2.4.3. Principe de la gestion de la QoS........................................................................ 10 3. Procdure de handover ...................................................................................... 10 3.1. Introduction ....................................................................................................... 11 3.2. Acquisition de la topologie du rseau ............................................................... 11 3.2.1. Les annonces ..................................................................................................... 11 3.2.2. La scrutation par le terminal de ses stations de base voisines........................... 11 3.2.3. Lassociation ..................................................................................................... 11 3.3. Handover break before make ...................................................................... 12 3.4. Modes optionnels de handover : MDHO et FBSS ............................................ 12 3.5. Dcision et dbut de MDHO/FBSS................................................................... 13 3.5.1. FBSS (commutation rapide de station de base)................................................. 13 3.5.2. MDHO (soft handover) ..................................................................................... 13 3.6. Conclusion......................................................................................................... 14 4. Les rseaux WiMAX......................................................................................... 14 4.1. Handovers dans les rseaux terrestres ............................................................... 14

viii 4.2. Amlioration du handover................................................................................. 15 4.3. Slection du meilleur rseau.............................................................................. 17 4.4. Handover avec mobilit..................................................................................... 19 4.5. Handover avec mobilit et localisation ............................................................. 21 4.6. Amlioration de handover horizontal................................................................ 21 5. Systme satellite (DVB-RCS) ........................................................................... 22 5.1. Prsentation ....................................................................................................... 22 5.2. Architecture DVB-RCS..................................................................................... 22 5.3. Pile protocolaire ................................................................................................ 23 5.4. Couche physique ............................................................................................... 23 5.5. Mthode daccs................................................................................................ 24 5.5.1. Partage des ressources ....................................................................................... 24 5.5.2. Allocation des ressources .................................................................................. 24 6. Solutions pour linterconnexion des rseaux sans fil ........................................ 25 6.1. Introduction ....................................................................................................... 25 6.2. Generic Access Network (GAN)....................................................................... 25 6.2.1. Architecture GAN ............................................................................................. 26 6.2.2. Avantages, inconvnients et dfis ..................................................................... 28 6.2.3. Positionnement de la technologie GAN [31] [32] :........................................... 28 6.3. Media Independent Handover (MIH IEEE 802.21) .......................................... 29 6.3.1. Objectifs initiaux ............................................................................................... 29 6.3.2. Prsentation du standard IEEE802.21 ............................................................... 30 6.3.3. IEEE 802.21 Media Independent Handover Function (MIHF)......................... 31 6.3.4. Scnarios du standard........................................................................................ 34 6.4. Protocole FMIP (Fast Mobile IPv6 Protocol) ................................................... 35 6.5. Solutions fondes sur IEEE 802.21................................................................... 36 6.6. Comparaison des solutions IEEE 802.21 et GAN............................................. 40 6.7. Intgration entre les rseaux terrestres et le systme de satellite ...................... 41 6.8. Conclusion......................................................................................................... 43

ix CHAPITRE II Convergence des rseaux sans fil terrestres et le systme satellite 45 1. 2. Introduction ....................................................................................................... 47 Handover dans un contexte satellite.................................................................. 47

2.1. Handover terrestre vers satellite ........................................................................ 48 2.2. Handover satellite vers terrestre ........................................................................ 48 2.3. Handover satellite vers satellite......................................................................... 49 3. Cas particuliers .................................................................................................. 49 3.1. Cas dun handover incluant une fonction de backhauling WiMAX sur le segment satellite ........................................................................................................................ 49 3.2. Cas dun handover incluant un rpteur sur le segment satellite ...................... 50 4. Architecture du rseau DVB-RCS .................................................................... 51 5. Modle de rfrence du rseau et les scnarios proposs ................................. 52 6. Proposition darchitecture satellitaire hybride base de WiMAX, DVB-RCS et IEEE 802.21 ......................................................................................................................... 53 6.1. Composants fonctionnels IEEE 802.21............................................................. 54 6.2. Modle de rfrence MIH pour des rseaux d'accs ......................................... 54 6.2.1. Modle MIH pour lutilisateur DVB-RCS ........................................................ 55 6.2.2. Point daccs au service MIH_DVB_RCS_SAP .............................................. 56 6.2.3. Point daccs au service MIH_MGMT_SAP.................................................... 56 6.2.4. Point daccs au service MIH_SAP .................................................................. 56 6.2.5. Transport des messages MIH ............................................................................ 56 6.2.6. Modle de rfrence MIH pour les stations mobiles avec les diffrentes piles protocolaires................................................................................................................ 57 7. Procdure de handover WiMAX/DVB-RCS .................................................... 57 8. Conclusion......................................................................................................... 60

CHAPITRE III Performance des rseaux WiMAX en utilisant handover horizontal avec un mcanisme de rservation .......................................................................... 61 1. 2. Introduction ....................................................................................................... 63 Description du systme ..................................................................................... 63

2.1. Approches proposes......................................................................................... 64 2.2. Quand initialisons-nous le handover ? .............................................................. 65 3. Analyse du pire cas de rservation et rservation de ressources ....................... 65

x 3.1. Pire cas de rservation....................................................................................... 65 3.2. Rservation des ressources ................................................................................ 66 3.2.1. Approches ractives .......................................................................................... 66 3.2.2. Approches proactives : Expiration (soft state) .................................................. 66 3.2.3. Approches mixtes .............................................................................................. 67 4. Modle de simulation ........................................................................................ 67 4.1. Dfinition de la topologie de mobilit du modle propos ............................... 67 4.2. Processus de handover, rservation et pire cas de rservation .......................... 70 4.3. Paramtres du modle propos.......................................................................... 70 5. Analyse de performance .................................................................................... 71 5.1. Mcanisme de handover et rservation de ressources....................................... 72 5.2. Comparaison...................................................................................................... 73 6. Conclusion ......................................................................................................... 77

CHAPITRE IV Performance du rseau WiMAX intgr dans un systme satellite DVB - RCS................................................................................................................. 79 1. 2. 3. 4. Introduction ....................................................................................................... 81 Coexistence entre le rseau WiMAX et le rseau DVB-RCS........................... 81 Mcanisme de handover.................................................................................... 82 Scnarios et approches ...................................................................................... 83

4.1. Description des scnarios .................................................................................. 83 4.2. Approches adoptes........................................................................................... 84 5. 6. Dfinition de la topologie.................................................................................. 84 Analyse de performance .................................................................................... 85

6.1. Paramtres du modle ....................................................................................... 85 6.2. Critres de performance .................................................................................... 86 6.3. Cas de linterconnexion sans rservation .......................................................... 86 6.3.1. Mcanisme rseau et utilisateur, trafic contraint temporellement..................... 86 6.4. Cas de linterconnexion de rseaux avec rservation........................................ 94 7. Conclusion....................................................................................................... 100

xi CHAPITRE V Mise en correpondance de la qualit de service dans les rseaux WIMAX ET DVB S/RCS .................................................................................... 103 1. 2. Introduction ..................................................................................................... 105 Catgories de demande de capacit DVB-RCS .............................................. 105

2.1. Continuous Rate Assignment (CRA) .............................................................. 105 2.2. Rate Based Dynamic Capacity (RBDC) ......................................................... 105 2.3. Volume Based Dynamic Capacity (VBDC).................................................... 106 2.4. Absolute Volume Based Dynamic Capacity (AVBDC) ................................. 106 2.5. Free Capacity Assignment (FCA) ................................................................... 107 3. 4. 4.1. 4.2. 4.3. 4.4. 4.5. 5. 6. Stratgie de file dattente dans le systme satellite DVB-RCS....................... 107 Qualit de service dans les rseaux WiMAX .................................................. 108 Service UGS .................................................................................................... 108 Service rtPS ..................................................................................................... 109 Service ErtPS................................................................................................... 109 Service nrtPS ................................................................................................... 109 Service Best Effort (BE).................................................................................. 110 Mise en correspondance WiMAX et DVB-RCS............................................. 110 Conclusion....................................................................................................... 114

CHAPITRE VI Contrle dAdmission de Connexion...................................... 115 1. 2. Introduction ..................................................................................................... 117 Contrle dadmission de connexion dans les rseaux WiMAX et DVB-RCS.117

2.1. Cas du rseau WiMAX.................................................................................... 117 2.2. Cas du systme satellite DVB-RCS ................................................................ 118 2.3. Conclusion....................................................................................................... 119 3. Scnarios proposs .......................................................................................... 120 3.1. Mise au point du mcanisme dans le cadre WiMAX DVB-RCS................. 120 3.1.1. Handovers........................................................................................................ 120 3.1.2. Partage des ressources ..................................................................................... 121 3.1.3. Remplacement des connexions ....................................................................... 121 4. CAC propos ................................................................................................... 122 5. Evaluation de performance.............................................................................. 124 5.1. CAC dans WiMAX ......................................................................................... 125

xii 5.2. CAC dans le cas dune interconnexion de rseaux WiMAX/DVB-RCS........ 127 5.2.1. Stratgie 1 : Dbit adaptatif et remplacement complet et strict ...................... 127 5.2.2. Stratgie 2 : Dbit non adaptatif et remplacement partiel (les connexions de type ErtPS et rtPS sont remplaces par des connexions de type RBDC) ......................... 128 5.2.3. Stratgie 3 : Dbit non adaptatif et remplacement glouton ............................. 129 6. Conclusion....................................................................................................... 131

CONCLUSION ....................................................................................................... 133 RFRENCES........................................................................................................ 137

LISTE DES FIGURES

Figure 1 : Standard IEEE 802.16 [1] ......................................................................................8 Figure 2 : Architecture de la pile protocolaire IEEE 802.16e [1]...........................................8 Figure 3 : Protocole propos de takeover [3]........................................................................15 Figure 4 : Handover fond sur takeover [3]..........................................................................15 Figure 5 : Types des handovers dans un rseau 4G [8] ........................................................16 Figure 6 : Algorithme hysteresis-based ................................................................................17 Figure 7 : Architecture propose [15]...................................................................................18 Figure 8 : Plateforme dagents [18] ......................................................................................19 Figure 9 : Architecture propose [19]...................................................................................20 Figure 10 : Architecture DVB-RCS [26]..............................................................................23 Figure 11 : Pile protocolaire du DVB-RCS [26] ..................................................................23 Figure 12 : Chane de codage du DVB-RCS [26] ................................................................24 Figure 13 : Les standards pour le handover..........................................................................25 Figure 14 : Rseau GAN [28] ...............................................................................................26 Figure 15 : Architecture GAN [30].......................................................................................27 Figure 16 : Le tunnel scuris [28] .......................................................................................27 Figure 17 : Modle de rfrence du rseau logique [28] ......................................................30 Figure 18 : Echelle de norme IEEE 802.21 [28]...................................................................31 Figure 19 : Fonction de MIH [28] ........................................................................................32 Figure 20 : Points daccs au service [28] ............................................................................34 Figure 21 : Architecture propose [35].................................................................................38 Figure 22 : Architecture propose [38].................................................................................39 Figure 23 : Cadre dintgration propos [43] .......................................................................40 Figure 24 : Modle de rfrence SI-SAP propos [49] ........................................................42 Figure 25 : Modle de rfrence MIH pour le systme satellite [49] ...................................42 Figure 26 : Handover terrestre vers satellite [50] .................................................................48 Figure 27 : Handover satellite vers terrestre [50] .................................................................48 Figure 28 : Handover satellite vers satellite [50] ..................................................................49 Figure 29 : Cas du backhauling WiMAX [50] .....................................................................50 Figure 30 : Cas du rpteur [50] ...........................................................................................51 Figure 31 : Architecture propose de rseau DVB-RCS [50] .............................................52 Figure 32 : Modle de rfrence IEEE 802.21 et scnarios proposs ..................................53 Figure 33 : Services et localisation de MIH [29]..................................................................54 Figure 34 : Modle de rfrence gnral et scnario propos ..............................................55 Figure 35 : Modle de rfrence de lutilisateur DVB-RCS ................................................55 Figure 36 : Modle de rfrence MIH pour les stations mobiles avec les piles protocolaires [29] [51] ........................................................................................................................57 Figure 37-a : Procdure de handover WiMAX/DVB-RCS (tapes 1 7)............................58 Figure 38-b : Procdure de handover WiMAX/DVB-RCS (tapes 7-12) ............................60 Figure 39 : Puissance du signal dune cellule WiMAX........................................................64 Figure 40 : Messages changs.............................................................................................64 Figure 41 : Topologie adopte ..............................................................................................68

xiv Figure 42 : Sens potentiels dun mobile ...............................................................................68 Figure 43 : File dattente.......................................................................................................69 Figure 44 : Rseau de files dattente reprsentant notre modle ..........................................69 Figure 45 : Microcellule dans la zone de recouvrement .......................................................70 Figure 46 : Taux de blocage avec lapproche cooprative ...................................................72 Figure 47 : Taux de blocage avec lapproche individuelle ...................................................73 Figure 48 : Comparaison des taux de blocage des nouveaux appels ....................................74 Figure 49 : Comparaison des taux de blocage du handover .................................................75 Figure 50 : Comparaison des taux de blocage de rservation de canal ................................75 Figure 51 : Taux de blocage des handovers en fonction de la capacit de station de base ..76 Figure 52 : Scnarios de l'intgration WiMAX/satellite.......................................................83 Figure 53 : Messages changs dans les approches proposes.............................................84 Figure 54 : Topologie adopte ..............................................................................................85 Figure 55 : Taux de blocage avec le mcanisme rseau .......................................................87 Figure 56 : Taux de blocage avec le mcanisme utilisateur .................................................88 Figure 57 : Taux de blocage dans le mcanisme rseau et dbit adaptatif ...........................89 Figure 58 : Taux de blocage avec le mcanisme utilisateur et dbit adaptatif .....................89 Figure 59 : Dbit de tentatives des handovers horizontaux trafic contraint temporellement ......................................................................................................................................90 Figure 60 : Dbit de tentatives des handovers montants trafic contraint temporellement.91 Figure 61 : Dbit des handovers descendants trafic contraint temporellement .................92 Figure 62 : Dbit de tentatives des handovers horizontaux trafic non contraint temporellement .............................................................................................................93 Figure 63 : Dbit de tentatives des handovers montants trafic non contraint temporellement .............................................................................................................93 Figure 64 : Dbit des handovers descendants trafic non contraint temporellement ..........94 Figure 65 : Taux de blocage WiMAX des nouveaux appels trafic contraint temporellement .............................................................................................................95 Figure 66 : Taux de blocage WiMAX des nouveaux appels trafic non contraint temporellement .............................................................................................................95 Figure 67 : Taux de blocage satellite des nouveaux appels trafic contraint temporellement ......................................................................................................................................96 Figure 68 : Taux de blocage satellite des nouveaux appels trafic non contraint temporellement .............................................................................................................97 Figure 69 : Taux de blocage des handovers horizontaux trafic contraint temporellement 98 Figure 70 : Taux de blocage des handovers montants Trafic contraint temporellement ...98 Figure 71 : Taux de blocage des handovers horizontaux trafic non contraint temporellement .............................................................................................................99 Figure 72 : Taux de blocage des handovers montants trafic non contraint temporellement ....................................................................................................................................100 Figure 73 : Schma de la mise en correspondance DVB-RCS WiMAX.......................111 Figure 74 : Schma de la mise en correspondance WiMAX DVB-RCS.......................113 Figure 75 : Taux de blocage de CAC_WiMAX en fonction de la charge..........................126 Figure 76 : Taux de blocage de CAC_WiMAX en fonction de la taille de leaky bucket ..127 Figure 77 : Taux de blocage des diffrentes classes de service avec le taux darrive (stratgie 3) .................................................................................................................130

xv Figure 78 : Dbits de diffrents handovers avec le taux darrive (stratgie 3) .................131

xvi

LISTE DES TABLEAUX

Tableau 1 : Paramtres de modle ........................................................................................71 Tableau 2 : Catgories de demande de capacit DVB-RCS et correspondance ATM .......107 Tableau 3 : Classes de QoS IEEE 802.16e 2005 [60] [61]..............................................108 Tableau 4 : Diffrentes applications potentielles [63] ........................................................110 Tableau 5 : Mise en correspondance des paramtres de QoS dans un contexte WiMAX/DVB-RCS....................................................................................................112 Tableau 6 : Applications envisageables dans DVB-RCS [57] ...........................................114 Tableau 7 : Paramtres de modle de simulation ...............................................................125 Tableau 8 : Dbits des diffrentes classes de service dans les deux rseaux......................125 Tableau 9 : Connexions changes dans le sens montant lors de ltablissement de connexion (stratgie 2)................................................................................................128 Tableau 10 : Connexions changes dans le sens descendant lors du down handover (stratgie 2) .................................................................................................................129 Tableau 11 : Connexions changes lors dun up handover (stratgie 3) ..........................129 Tableau 12 : Connexion changes lors dun down handover (stratgie 3) .......................129

xviii

LISTE DES ACRONYMES

AN ABC ABR AES-CCM AP AR ASP ATM AVBDC BS BSC BSM BSP BTS BW BWA CAC CBR CID CINR CMAC CoA CR CRA CSMA/CA DAMA DSL DVB-RCS EAP ESS ETSI FA FBSS FCA FEC FMIP GAN GANC GEO GPRS GPS GSM HA H-ARQ HHO Access Network Always Best Connected Available Bit Rate Advanced Encryption Standard CCM (Counter with CBC-MAC) Access Point Access Router Access Service Provider Asynchronous Transfer Mode Absolute Volume Based Dynamic Capacity Base Station Base Station Controller Broadband Satellite Multimedia Working Group Broadcast Service Provider Base Transceiver Station Bandwidth Broadband Wireless Access Call Admission Control Constant Bit Rate Connection ID Carrier-to-Interference plus Noise Ratio Cipher-MAC Care of Address Channel Reservation Continuous Rate Assignment Carrier Sense Multiple Access with Collision Avoidance Demand Assignment Multiple Access Digital Subscriber Line Digital Video Broadcast - Return Channel by Satellite Extensible Authentication Protocol Extended Service Set European Telecommunications Standards Institute Foreign Agent Fast BS Switching Free Capacity Assignment Forward Error Control Fast Mobile IPv6 Protcol Generic Access Network Generic Access Network Controller Geostationary Earth Orbit General Packet Radio Service Global Positioning System Global System for Mobile communication Home Agent Hybrid Automatic Repeat Request Horizontal Handover

xx
HLR HO IEEE IETF IMS IP IS ITU-T LEO LOS MAC MAN MAP MDHO MFTDMA MICS MIES MIH MIHF MIIS MIMO MIP MN MPE MPEG2-TS MR MS MSC MSL MSS MT NAR NCC NLOS NN OFDM PKM PoA QoS RAN RBDC RCST RSS SAP SDU SGSN SS SSIDs TCP Home Location Register Handover Institute of Electrical and Electronic Engineers Internet Engineering Task Force IP Multimedia Subsystem Internet Protocol Information Service Telecommunication Standardization Sector of the International Telecommunications Union Low Earth Orbit Line Of Sight Media Access Control Metropolitan Area Network Multi-Access Provider Macro Diversity Handover Multi Frequency Time Division Multiple Access Media Independent Command Service Media Independent Event Service Media Independent Handover Media Independent Handover Function Media Independent Information Service Multiple Input Multiple Output Mobility IP Mobile Node Multi-Protocol Encapsulation Moving Picture Experts Group - Transport Stream Mobile Router Mobile Station Mobile Switching Centre Minimum Scheduling Latency Mobile Subscriber Mobile Terminal New Access Router Network Control Center No Line Of Sight Neighbor Node Orthogonal Frequency Division Multiplexing Privacy Key Management Point of Attachment Quality of Service Radio Access Network Rate Based Dynamic Capacity Return Channel Satellite Terminal Received Signal Strength Service Access Point Service Data Unit Serving GPRS Support Node Subscriber Station Service Set Identifier Transmission Control Protocol

xxi
TEK UBR UDP UMA UMTS UNA VBDC VBR-rt VHO VoIP VPN VSAT WiFi WiMAX WLAN WMAN AAL-5 2G 3G 3GPP Traffic Encryption Key Unspecified Bit Rate User Datagram Protocol Unlicensed Mobile Access Universal Mobile Telecommunications System Unlicensed Network Access Volume Based Dynamic Capacity Variable Bit Rate - real time Vertical Handover Voice over IP Virtual Private Network Very Small Aperture Terminal Wireless Fidelity Worldwide Interoperability for Microwave Access Wireless Local Area Network Wireless Metropolitan Area Network ATM Adaptation Layer Second Generation Third Generation Third Generation Partnership Project

xxii

INTRODUCTION
Les rseaux mobiles et sans fil ont connu un essor sans prcdent ces dernires annes. Il sest agit dune part du dploiement de plusieurs gnrations successives de rseaux de tlcommunications essentiellement ddis la tlphonie (2G, GSM) puis plus orients vers le multimdia (3G, UMTS). Dautre part, les rseaux locaux sans fil sont rentrs dans la vie quotidienne au travers de standards phares tels que WiFi, Bluetooth, etc. Les volutions se poursuivent de toute part, tant dans le monde des rseaux spcialiss (capteurs, tiquettes intelligentes, etc.) que des rseaux tlcoms. Ceux-ci voient dsormais des solutions concurrentes apparatre provenant de divers horizons : monde tlcoms classiques avec HS(D)PA, monde des rseaux sans fil avec le WiMAX voire le monde de la diffusion tlvision terrestre et satellite (DVB-T, DVB-H, DVB-S). La future gnration de rseaux sans fil dite de quatrime gnration (4G) apporte un vritablement tournant dans le foisonnement et la disparit des solutions existantes. Lobjectif cette fois sera certes daugmenter les dbits et les applications prises en charge par ces rseaux mais encore de construire un cadre permettant leur interoprabilit. Des premires solutions sont dj disponibles auprs de la plupart des oprateurs de tlcommunications mais la plupart dentre elles sont des solutions spcifiques un type dinterconnexion et un oprateur. LIEEE, au travers dun groupe de travail spcifique 802.21, a donc propos un cadre gnral pour un dveloppement harmonieux de cette interoprabilit. Ce travail porte surtout sur les basculements entre systmes au travers de mcanismes que lon qualifie de handovers verticaux en raison du changement de technologie entre les systmes. Il ne traite pas, et ce nest bien videmment pas son objectif, le problme de la continuit de la qualit de service. Notre travail de thse sest donc concentr sur ces problmes dinteroprabilit avec prise en compte de la qualit de service. Par ailleurs, les systmes satellites nayant pas encore t intgrs dans les tudes de ce groupe de travail, nous avons fait porter une bonne partie de nos efforts sur linteroprabilit entre systmes terrestres et systmes satellites. Pour les rseaux terrestres, nous en avons choisi un qui a des caractristiques intressantes en particulier vis vis de son interconnexion avec un systme satellite (couverture large, prise en compte de la QoS, mobilit, dbit, etc.). Nous avons donc retenu le rseau mtropolitain WiMAX. En ce qui concerne le rseau satellite, nous avons choisi le systme DVB-RCS comme un des plus aboutis. Ce choix dinterconnexion donne une ouverture importante la fois en terme de scnarios envisageables mais encore de mcanismes proposer. Par ailleurs, la solution qui vise profiter du cadre gnrique du modle IEEE 802.21 nous semble largement la plus saine dans la mesure o, mme si elle est sans doute plus contraignante car elle impose aux standards existants se conformer une vision commune de linteroprabilit, elle permet une volutivit et une rutilisabilit bien plus importante que la solution cousue main des solutions jusquici dployes qui ncessitent de reprendre le travail zro pour tout couple de technologies devant cohabiter. Par ailleurs, lvolution naturelle des systmes de communication sans fil soriente dsormais largement vers la prise en compte de la qualit de service. Celle-ci est inhrente

2 aux solutions des oprateurs tlcoms (GSM, UMTS) mais nest reste que marginale dans les premires solutions de rseaux sans fil (WiFi ou Bluetooth) pour lesquelles, il sest agit essentiellement dans un premier temps de proposer des solutions qui fonctionnent des utilisateurs peu exigeants. Ce temps est rvolu et dsormais, tous les nouveaux standards intgrent des mcanismes visant garantir de la qualit de service certains flux et/ou certains utilisateurs. Notre travail a donc port sur la prise en charge de la qualit de service en particulier lors des transferts entre systmes. Nos travaux se sont donc focaliss la fois sur larchitecture et les protocoles lis ces rseaux htrognes mais encore sur la dfinition de mcanismes visant garantir de la qualit de service et sur lvaluation de lensemble de ces propositions. Notre premire contribution porte sur le dveloppement de la norme IEEE 802.21 afin quelle puisse intgrer un systme satellite de type DVB-RCS. Pour ce faire, nous avons pris le parti de nous inspirer des recommandations qui ont t faites par ce groupe de travail aux diffrents standards de tlcommunications terrestres afin quils offrent les possibilits dinteroprabilit. Cela se traduit dans le standard DVB-RCS par la cration de points daccs au service . Cette notion nexiste pas vraiment dans le monde des systmes de communications par satellite pour lesquels les protocoles et les fonctions sont vus comme des enchanements plus que comme des couches communicantes au travers dun modle de rfrence tel que normalis par lOSI et largement repris par les standards de tlcoms ITU ou IEEE. Ce travail a t dclin au travers dun certain nombre de scnarios que nous avons dfinis pour linterconnexion de systmes WiMAX/DVB-RCS. Dans ce cadre, nous avons propos une procdure de handover vertical. La deuxime partie de la thse porte sur des mcanismes permettant damliorer les procdures de handover. Nous avons alors considr plusieurs cadres successifs. Le premier contexte concerne une solution purement WiMAX o les utilisateurs doivent basculer entre plusieurs cellules. Une technique relativement simple consiste rserver des ressources dans les diffrentes cellules afin de prparer les changements de cellules dans de bonnes conditions. La question gnralement pose consiste savoir quand et comment mettre en uvre la rservation. Plutt que de gaspiller des ressources, notre ide est quen se servant de mcanismes de signalisation, on doit pouvoir rserver des ressources quand des utilisateurs commencent se rapprocher de la zone de recouvrement entre cellules. Nous avons alors propos plusieurs solutions pour effectuer ces rservations : en les faisant passer par des utilisateurs proches gographiquement des mobiles qui se rapprochent de la zone de basculement mais qui eux sont porte de la nouvelle station de base vise, par la station de base de service ou par une combinaison de ces deux techniques. Nous avons montr que ces propositions amliorent sensiblement les performances du handover et avons montr lintrt respectif de ces deux techniques en fonction de la densit du trafic. Le deuxime contexte reprend le cas de linterconnexion WiMAX/DVB-RCS. Dans ce cas de figure, le mcanisme a t revisit en prenant en compte la disparit de porte des deux systmes mais aussi de dbit. Lide est de favoriser la prise en charge par le rseau WiMAX qui offre des dlais moindres et des dbits plus levs. Le mcanisme de rservation de ressources conserve de nouveau son intrt. Dans les prcdents chapitres, la notion de qualit de service a surtout t mise en vidence au travers de la russite des transferts intercellulaires en regardant essentiellement

3 le dbit ncessaire lapplication lors du changement de systme. Il nous a paru alors intressant de prolonger cette tude en nous intressant la mise en correspondance entre les paramtres de qualit de service entre systmes. Il est noter que beaucoup de systmes de tlcommunications rcents se sont penchs sur la dfinition de classes de services et de paramtres de qualit de service associs. Les prcurseurs en la matire ont t les rseaux ATM, mais lon a vu ces travaux repris dans de trs nombreux contextes : IP (on pense surtout DiffServ voire Intserv), GSM/GPRS, UMTS, WiMAX, DVB-S/RCS et plus mdiocrement IEEE 802.11e. Si les dmarches sont sensiblement quivalentes, les rsultats restent toutefois encore un peu htrognes. Nous avons donc profit du cadre gnral de cette thse pour faire lexercice de mise en correspondance dans le cadre WiMAX/DVBRCS. Lintrt est multiple puisquil permet denrichir les modles prcdents lors du basculement vertical entre les deux systmes, mais encore de mettre en uvre une interconnexion simple, une communication pouvant passer par un rseau daccs WiMAX puis relaye par un systme satellite de type backhauling . Un mcanisme de CAC (Call Admission Control) a finalement t propos pour le rseau WiMAX, le DVB-RCS et lintgration WiMAX/DVB-RCS. Nous lavons valu et les rsultats sont prometteurs.

CHAPITRE I - ETAT DE LART

1.

Introduction

Dans ce chapitre nous nous intressons aux architectures de futurs rseaux daccs sans fil terrestres et satellite. Dans un premier temps, nous allons prsenter larchitecture du rseau WiMAX (Worldwide Interoperability for Microwave Access) et celle du systme satellite DVB-RCS (Digital Video Broadcast - Return Channel by Satellite). Pour le rseau WiMAX, nous nous intresserons plus spcifiquement : au standard, la pile protocolaire, aux fonctionnalits, la QoS, et au handover. Puis, nous allons synthtiser les diffrents travaux de handover dans lensemble des rseaux sans fil terrestres. Ensuite, nous nous focaliserons sur le systme satellite DVB-RCS : architecture, pile protocolaire, couche physique, et mthode daccs. Dans un deuxime temps, nous allons prsenter les diffrentes solutions existantes pour linterconnexion des rseaux sans fil : le standard GAN (Generic Access Network), le protocole FMIP6 (Fast Mobile IPv6 Protocol), ainsi que le standard IEEE 802.21 et les travaux de recherche associs. Une comparaison entre ces diffrentes solutions est prsente suivie par une synthse des travaux de recherche sur lintgration des rseaux sans fil terrestres et des systmes satellites. Notons que dans la suite du manuscrit, quand on parlera de DVB-RCS, il sagira du systme DVB-RCS qui comporte une voie aller en DVB-S/2 et une voie retour exploite en DVB-RCS.

2.

Les rseaux WiMAX

Le rseau WiMAX dsigne dans le langage courant un ensemble de standards et techniques du monde des rseaux mtropolitains sans fil WMAN (Wireless Metropolitan Area Network). Le standard IEEE 802.16, ou WiMAX permet le raccordement sans fil d'entreprises ou de particuliers sur de longues distances haut dbit. WiMAX apporte une rponse approprie pour certaines zones rurales ou difficilement accessibles, qui sont aujourd'hui prives d'accs l'Internet haut dbit pour des raisons de cot. Cette technologie vise donc introduire une solution complmentaire au DSL (Digital Subscriber Line) et aux rseaux cbls d'une part, et interconnecter des hotspots WiFi d'autre part. WiMAX est principalement fond sur une topologie en toile bien que la topologie maille soit possible. La communication peut tre ralise en ligne de vue (LOS : Line Of Sight) ou non (NLOS). La dernire mouture du standard qui nous intresse ici est le standard IEEE 802.16 2005 qui couvre les terminaux mobiles et dfinit des mcanismes volus de gestion des handovers.

2.1. Standard de linterface air IEEE 802.16

Plusieurs standards IEEE 802.16 (Figure 1) ont t dfinis : IEEE 802.16 (2001) ddi aux systmes LOS (10-66 GHz), IEEE 802.16c (2002) qui fonctionne sur la bande des frquences 10-66 GHz et IEEE 802.16a pour les systmes NLOS (2-11 GHz). Les deux derniers standards retenus sont IEEE 802.16 (2004) pour les terminaux fixes WiMAX fixe et IEEE 802.16e (2005) pour les terminaux mobiles WiMAX mobile.

Figure 1 : Standard IEEE 802.16 [1]

2.2. Pile protocolaire

La pile protocolaire du standard IEEE 802.16e est focalise sur les couches PHY et MAC comme on peut le voir sur la Figure 2. Elle contient les sous-couches de convergence et de scurit.

Figure 2 : Architecture de la pile protocolaire IEEE 802.16e [1]

2.3. Fonctionnalits
Le standard IEEE 802.16 peut utiliser efficacement les bandes de frquences disponibles. Il met en place un certain nombre de fonctionnalits permettant doffrir une solution pour le passage lchelle, et un accs haut dbit tout en tenant compte des besoins de lutilisateur et des applications en terme de qualit de service (QoS), de mobilit et de scurit. Nous pouvons aussi classifier ces fonctionnalits selon les besoins suivants [1] : Le passage lchelle : la couche PHY permet le passage lchelle en utilisant de faon adaptative la bande passante de 1,25 20 MHz pour le standard WiMAX fixe. Le profil global du WiMAX mobile est propos de 5 MHz 10 MHz. Des mcanismes de rutilisation flexible de frquence et de planification sont galement proposs. Le haut dbit : la trame MAC est de taille importante avec un faible overhead. Au niveau physique, WiMAX utilise des mcanismes FEC (Forward Error Control) avancs et une modulation adaptative. Lutilisation de technique H-ARQ (Hybrid Automatic Repeat Request) permet de rduire les pertes de paquets. H-ARQ est une technique permettant de combiner la technique FEC fonde sur lutilisation de turbo-codes avec une stratgie de retransmission permettant lchange dinformations entre lmetteur et le rcepteur. Les amliorations portent aussi sur ladaptation de la technique MIMO (Multiple Input Multiple Output) et la mise en uvre dune formation adaptative de faisceaux. La QoS : plusieurs types de trafic sont pris en compte. La QoS est ngocie au niveau du flux de service (cf. 2.1.1.4), ltablissement de la connexion et un cadre gnral avanc de lordonnancement est dfini. Une modulation et un codage sont mis en place ainsi que le choix de technique de reprise (ARQ, H-ARQ). La mobilit : elle comprend la dfinition de plusieurs mcanismes : hard/soft handover, fast base station switching handover (handover FBSS) et contrle de puissance avec les modes sleep et idle . Nous dcrirons en dtail ces mcanismes dans (3.3). La scurit : Elle comprend plusieurs mcanismes volus dont : authentification d'EAP (Extensible Authentification Protocol), chiffrement avec AES-CCM (Advanced Encryption Standard CCM (Counter with CBC-MAC) mode), mode d'authentification CMAC (CipherMAC), certificats X.509 (un standard de cryptographie de lITU-T pour les infrastructures cls publiques (PKI)), cl de rattachement (key binding) et possibilits d'authentification du dispositif et de l'utilisateur.

2.4. QoS
2.4.1. Connexion Le lien dans un rseau IEEE 802.16 est un lien logique unidirectionnel entre la station de base (BS) et le niveau MAC du terminal utilisateur SS (Subscriber Station) [1]. Il y a un indicateur de la destination, les requtes de transmission sont vhicules sparment. Enfin, certaines proprits de QoS sont associes chaque connexion. Lactivation par la station de base repose sur les dispositifs suivants : enregistrement du terminal utilisateur, modification de service du terminal utilisateur et connexions de base tablies au ranging initial pour les messages MAC de gestion intolrants au dlai. Les sessions de niveau plus lev peuvent partager la mme connexion MAC, les connexions se partageant

10 linterface air. 2.4.2. Flux de service Un service de transport unidirectionnel (montant ou descendant) au niveau MAC est dfini pour vhiculer les paquets. Nous pouvons distinguer les services suivants [1] : Caractrisation des paramtres de QoS (latence, gigue et dbit garanti). Caractrisation des processus dallocation de la bande passante. Gestion de la QoS pour la connexion. Dautre part, les flux de service sont dynamiques ; cela signifie quils peuvent tre crs, modifis, ou supprims laide dune srie de messages de gestion MAC. 2.4.3. Principe de la gestion de la QoS La gestion de la QoS a pour but de garantir la QoS par connexion comme suit [1] : Association des paquets traversant l'interface MAC avec les flux de service. Dfinition de l'ensemble des paramtres de QoS pour chaque flux de service. Des mcanismes QoS permettent de dfinir un ordre de transmission sur l'interface air et de fonctionner en conjonction avec des mcanismes au del de l'interface air afin dessayer de fournir une QoS de bout en bout. Un ensemble de fonctionnalits est mis en place pour rpondre ces besoins [1] : Une fonction pour pr-configurer les flux de service et les paramtres du trafic fonds sur la QoS par terminal ; Une fonction afin dtablir dynamiquement les flux de service avec QoS et des paramtres de trafic ; Lutilisation dun ordonnancement MAC et de paramtres de trafic QoS pour les flux de service sur le lien montant ; Lutilisation des paramtres de trafic QoS pour les flux de service sur le lien descendant ; Le regroupement des proprits des flux de service en classes de service pour les entits de niveau suprieur et les applications. Dans le chapitre 5, nous prsentons les paramtres de QoS, dfinis dans le rseau WiMAX, pour chaque classe de service.

3.

Procdure de handover

Afin de prendre en compte la mobilit des usagers, le standard met en place une procdure de handover utilisable dans les cas suivants [1] : Quand la station mobile MS (Mobile Station) peut tre prise en compte avec une meilleure qualit de signal par une autre station de base (mouvement du terminal, affaiblissement du signal ou interfrence). Quand le terminal mobile peut tre pris en compte avec une meilleure QoS par une autre station de base (quilibrage de charge, contrle d'admission, ou attentes en terme de QoS).

11

3.1. Introduction
Le handover de niveau deux est l'opration effectue par un terminal qui change de station de base de service vers une station de base cible [2]. Cela peut se produire quand le terminal se dplace et souhaite conserver un signal de bonne qualit, ou si le terminal voit qu'une autre station de base peut lui fournir une meilleure QoS. Ce handover peut engendrer ou non un handover des couches suprieures selon que les stations de base sont sur le mme lien rseau ou non.

3.2. Acquisition de la topologie du rseau

3.2.1. Les annonces Une station de base de service diffuse priodiquement des annonces aux terminaux. Il s'agit d'un ensemble d'informations sur les stations de base voisines : leur nombre, et pour chacune, son identifiant, ses caractristiques physiques (liens montants et descendants), etc. La diffusion priodique dannonces permet au terminal de mettre jour ses connaissances sur la topologie et de se synchroniser plus facilement avec une station de base voisine. 3.2.2. La scrutation par le terminal de ses stations de base voisines Le but dune scrutation est de tester dans quelle mesure une station de base voisine pourrait convenir en tant que station de base cible d'un handover, et dacclrer ce handover sil a lieu. On distingue deux scrutations : une scrutation sans association, dans laquelle le terminal se synchronise sur le lien descendant de la station de base cible pour estimer la qualit du canal physique. Une scrutation avec association (appele association), qui est une scrutation simple laquelle sajoute une mesure de porte (ranging). 3.2.3. Lassociation Cette procdure est effectue en vue de la slection d'une station de base cible approprie pour un handover et/ou pour acclrer un ventuel futur handover. Une association est une procdure optionnelle de ranging pouvant se produire durant la scrutation sur une des stations de base voisines. Le but est de permettre au terminal de recueillir et d'enregistrer des paramtres ainsi que des informations sur la disponibilit de service dune station de base voisine. Lassociation comprend louverture des connexions de gestion de base et primaires entre le terminal et la station de base cible. Il y a plusieurs niveaux de connexion : de base, primaire, secondaire, et enfin connexion de transport (vhiculant des donnes utilisateur). Il existe trois types d'association : Association de niveau 0 (sans coordination) : La station de base de service ne participe pas lassociation. La station de base cible ne connat pas le terminal et va donc lui fournir un accs en contention pour le ranging. Association de niveau 1 (avec coordination) : La station de base de service coordonne l'association entre le terminal et la station de base cible. Ainsi, la station de base de service fournit au terminal des paramtres lis l'association : le terminal et la station de base cible se connaissent mutuellement, donc la station de base cible fournit au terminal une allocation sans contention.

12 Association de niveau 2 (assiste par le rseau) : La station de base de service coordonne l'association avec les stations de base cibles. Cependant, un terminal ayant transmis le code de ranging la station de base cible ne devra pas attendre la rponse de ranging.

3.3. Handover break before make

Cest la procdure classique de hard handover : le terminal se dconnecte de sa station de base de service avant de se connecter la station de base cible. Il y a donc une coupure dans la communication. Par consquent, ce mode de handover ne fonctionne que si la mobilit est lente. La procdure de handover comporte plusieurs tapes : Re-slection de cellule : Le terminal utilise les informations recueillies lors des scrutations, associations, annonces, pour valuer l'intrt d'une station de base voisine comme cible dun handover. Une telle procdure nimplique pas la terminaison de la connexion avec la station de base de service, et n'est pas forcment suivie dune dcision de handover. Entre dans le rseau : Lentre dans le rseau comprenant la synchronisation avec les liens descendants/montants, le ranging (obtention des paramtres du lien descendant et montant), la ngociation des capacits, lauthentification par change de cls et lenregistrement du terminal auprs de la station de base. Si l'enregistrement est russi, on tablit la connectivit IP et les connexions de transport ; la station de base cible devient la station de base de service. Terminaison du contexte terminal : Le terminal envoie, la station de base de service, une indication avec l'option de relchement des ressources. La station quant elle arme le temporisateur "retenue des ressources". Lorsque ce temporisateur expire, la station de base de service met fin toute connexion avec le terminal et dtruit les informations le concernant. Si la station de base de service reoit un message provenant de la station de base cible indiquant que le terminal y a t attach, la station de base de service peut supprimer le contexte du terminal mme avant l'expiration du temporisateur. Baisse de connectivit pendant le handover : Quand un terminal dtecte une baisse de connectivit pendant lentre dans le rseau d'une station de base cible, il peut essayer de reprendre la communication avec sa station de base de service en envoyant un message d'annulation de handover. Coordination de transmission : Quand le terminal termine le handover, il faut maintenir la continuit de la transmission entre l'ancienne et la nouvelle station de base de service vers le terminal.

3.4. Modes optionnels de handover : MDHO et FBSS

En plus de la procdure de hard handover, il existe deux modes optionnels de handover (FBSS (Fast BS Switching) et MDHO (Macro Diversity Handover)). La prise en charge de ces modes est paramtre lors de la phase denregistrement. Le jeu de diversit est un ensemble contenant une liste des stations de base actives pour le terminal. La notion de station de base active surpasse la notion de station de base associe : en effet, lenregistrement a eu lieu, et donc louverture des connexions de gestion secondaires aussi.

13 Une entit prenant en charge le MDHO/FBSS doit grer le jeu de diversit, dans lequel une station de base ancre est dsigne. Nous notons que la coordination de transmission nest effectue que dans le mode FBSS, et se droule de la mme manire que dans le hard handover.

3.5. Dcision et dbut de MDHO/FBSS

3.5.1. FBSS (commutation rapide de station de base) Le handover FBSS ncessite plusieurs conditions : les stations de base, qui sont synchronises sur une rfrence temporelle commune, ont une structure de trame (trame = unit de temps) synchronise et utilisent les mmes frquences. les trames envoyes par les stations de base un moment donn doivent parvenir au terminal pendant l'intervalle de prfixe OFDM (Orthogonal Frequency Division Multiplexing). les stations de base doivent partager et se transmettre le contexte MAC. Il contient les informations que le terminal et la station de base s'changent lors de l'entre dans le rseau, par exemple l'tat d'authentification, afin qu'un terminal authentifi/enregistr auprs d'une station de base du jeu de diversit soit aussi automatiquement auprs des autres stations de base de lensemble.

Le FBSS est un genre nouveau de handover. Le terminal est servi par une seule station de base un instant donn : la station de base ancre, qui est donc considre comme sa station de base de service. Les donnes du terminal sont reues par toutes les stations de base du jeu de diversit mais seule la station de base ancre va les interprter. Le terminal ne communique quavec la station de base ancre pour le sens montant et descendant, mais les autres stations de base actives doivent tre prtes envoyer des donnes au terminal dans n'importe quelle trame. En effet, dune trame lautre, la station de base ancre peut changer au sein du jeu de diversit. En FBSS, on parle plutt de commutation rapide de station de base. Cest un changement de station de base ancre qui ninduit pas de coupure, car les connexions de gestion sont dj en place entre le terminal et les stations de base actives. Il sagit juste pour le terminal douvrir les connexions de transport vers la nouvelle station de base ancre. L'avantage est de ne pas devoir utiliser des messages de signalisation de handover quand on veut changer de station de base ancre, car la commutation de station de base ancre est effectue sans invoquer la procdure de handover classique. 3.5.2. MDHO (soft handover) Avec un soft handover, le terminal est servi par toutes les stations de bases du jeu de diversit. Ce mode se fonde sur la capacit du terminal communiquer simultanment avec plusieurs stations de base. Au fil du temps et de ses dplacements, le terminal va modifier son jeu de diversit.

14 Dans le sens descendant, le terminal reoit la mme trame MAC, au mme instant, en provenance de chacune des stations de base du jeu de diversit. Il effectue ensuite la combinaison de diversit : en combinant le signal des diffrentes stations de base, il en fabrique un seul grce un rcepteur de type RAKE. Il y a un gain de diversit car le terminal profite de la rception de plusieurs PDUs pour limiter les erreurs en combinant les informations. Dans le sens montant, le trafic provenant du terminal est reu par toutes les stations de base du jeu de diversit. Le MDHO requiert les mmes conditions que le FBSS, mais en plus : les stations de base utilisent le mme ensemble de CIDs (Connection ID) pour les connexions tablies avec le terminal. Les stations de base doivent utiliser le mme type de PDU MAC/PHY. Enfin, le terminal doit pouvoir prendre en charge plusieurs connexions simultanes.

3.6. Conclusion
Le handover de niveau deux dans le rseau WiMAX mobile (IEEE 802.16e) est anticip par des procdures pr handover permettant den limiter la dure. A la procdure de handover classique, utilise dans des situations de mobilit lente, sajoutent deux modes permettant un handover sans coupure adapts aux dplacements rapides de lutilisateur. MDHO sera srement implant en dernier du fait de sa complexit.

4.

Les rseaux WiMAX

4.1. Handovers dans les rseaux terrestres

La majorit des travaux de recherche actuels sont orients vers la possibilit dintgrer les rseaux sans fil terrestres : le rseau WLAN (Wireless Local Area Network) et des rseaux 3G ; cela constitue une dfinition dun rseau 4G. Cette intgration soulve plusieurs problmes puisque chaque rseau a des caractristiques diffrentes (bande passante, zone de couverture, puissance, norme, etc.). Lun des problmes envisags est galement celui de la mise en uvre dun handover sans couture et sans perte des donnes. La procdure de handover a t tudie de plusieurs points de vue : algorithmique, protocolaire, mcanismes, architecturel, etc. Les intrts des travaux prennent en compte plusieurs aspects : Lamlioration de handover (handover sans couture, rduire la perte de blocage, amliorer lutilisation de rseau, etc.) et de la QoS. Le dveloppement de handover pourrait alors tre mis en uvre aux diffrents niveaux des piles protocolaires, surtout au niveau rseau. La dcision de handover dans la mesure o on doit savoir quand et quel niveau le handover doit tre dclench. Lintrt est donc de choisir le meilleur rseau selon des critres et des conditions qui permettent le dclanchement de handover. La mobilit sans et avec considration de la localisation du terminal mobile.

15

4.2. Amlioration du handover

La rduction de la dure dun handover est lun des buts recherchs. Cela peut se faire en dveloppant un protocole de handover. Les auteurs dans [3] se sont intresss rduire la dure de handover en proposant un handover coopratif afin de prparer prmaturment le handover avec le rseau cible. Les auteurs proposent un handover vertical sans couture (Figure 3 et Figure 4). Pour cela, ils prsentent un nouveau concept appel Takeover . Cela consiste permettre un nud voisin situ dans la zone de recouvrement de traiter les demandes dun nud mobile qui veut faire un handover avant que celui-ci ne puisse le mettre en uvre. On parle alors dun handover coopratif dans la mesure o les nuds saident les uns les autres concernant le handover. Cela rduit la dure de handover : temps de pr-authentification et de pr-enregistrement (utilisant une procdure denregistrement IP mobile). De plus, un protocole pour le Takeover a t dvelopp et appliqu. La dcision de handover est fonde sur la qualit du signal de deux stations de base. En revanche, le systme propos demande plus de signalisation et aussi plus de traitement par le nud voisin. Cela impose enfin le fonctionnement en mode maill (communication directe entre terminaux).

Figure 3 : Protocole propos de takeover [3]

Figure 4 : Handover fond sur takeover [3]

Par ailleurs, la rduction de la dure de handover peut tre traite au niveau physique. Smaoui et al. [4] prsentent un schma dun handover UMTS/WLAN afin de rduire la dure de handover et le taux de blocage. Pour prendre la dcision de handover, la puissance du signal reu (RSS : Received Signal Strength) du rseau de service doit tre infrieure celle du rseau cible et une puissance du signal prdfinie. Cependant, les auteurs dans [5] ont montr que le handover IP rapide nest pas suffisant pour rduire la dure de handover. Cest pour cela quils proposent un schma dun handover qui traite le dlai de blocage. Par ailleurs, la prise en compte de la QoS en effectuant le handover a t aborde dans plusieurs travaux. R. Corvaja [6] a propos un handover IEEE 802.11b/Bluetooth en

16 tenant compte de la QoS. La procdure de handover ne repose pas sur la puissance du signal reu mais sur les paramtres de QoS du terminal mobile (dlai dacheminent des paquets et taux derreur de paquet). Les paramtres de QoS sont dfinis par des seuils pour chaque paramtre dans le profil utilisateur pour quil puisse dcider du handover au moment opportun. En outre, les auteurs dans [7] proposent damliorer la performance du handover au niveau de la couche liaison entre les rseaux IEEE 802.11 et Bluetooth en dfinissant une nouvelle interface virtuelle comme solution dun handover transparent pour les services IP entre diffrentes technologies. Les protocoles actuels montrent une limitation pour les applications avec des contraintes temporelles, telles que VoIP, cause de la latence (une rupture de quelques millisecondes lors de la procdure de handover est constate). En plus de la QoS, Zahran et al. [8] ont pris en compte dautres critres afin deffectuer un handover : lutilisation de ressources rseau et le nombre de handovers. Les auteurs prsentent deux types dalgorithmes pour mettre en uvre le handover (WLAN/3G) : Hysteresis-based algorithm et lifetime-based algorithm. Les auteurs distinguent dailleurs deux types de handover (deux sens) (Figure 5) : MI : Movement-In qui est le handover du rseau 3G vers le rseau WLAN et MO : Movement-out qui prsente le sens inverse.

Figure 5 : Types des handovers dans un rseau 4G [8]

LAlgorithme Hysteresis-based utilise deux seuils (Figure 6). Le terminal mobile effectue un handover de type MI lorsque la puissance moyenne du signal reu ( RSS ) dpasse le seuil MITWLAN et effectue un handover de type MO quand cette puissance moyenne est infrieure au seuil MOTWLAN prdfini.

17
MITWLAN RSS MOT WLAN

MO

MI

Figure 6 : Algorithme hysteresis-based

LAlgorithme Lifetime-based utilise la puissance du signal reu afin destimer la puissance moyenne du signal et le taux daffaiblissement de la puissance du signal (RSS). Ces deux derniers paramtres sont utiliss pour calculer la dure de vie du terminal dans le rseau WLAN. Dans cet algorithme, le terminal mobile effectue un handover lorsque la puissance du signal est infrieure ou gale un seuil prdfini et la dure de vie estime est infrieure ou gale au seuil prdfini THO, o THO correspond au dlai prvu du handover entre les deux rseaux. Le terminal effectue un handover WLAN ds que la puissance du signal baisse en dessous du seuil prdfini. Les mmes auteurs par la suite ont dvelopp ce travail dans [9] [10] [11]. Ils proposent un algorithme de handover adaptatif qui sappelle ALIVE-HO et LIVE-HO (Adaptive Lifetime). Cet algorithme permet de baisser significativement le nombre de handovers non ncessaires (vite le phnomne de Ping-Pong) et amliore lutilisation de ressources. Cependant, un inconvnient de laugmentation de dure de vie du terminal dans le rseau WLAN est laugmentation du dlai des paquets cause de la dgradation de ltat du canal. Cela est peut tre dlicat si le terminal mobile effectue des applications temps rel.

4.3. Slection du meilleur rseau

Un des points critiques pour le handover rside dans le choix des conditions de dclenchement. Ces conditions peuvent tre fondes sur plusieurs paramtres. Les auteurs [12] proposent un schma dun handover IEEE 802.16a/IEEE 802.11n qui peut rduire la probabilit du handover inutile d la chute temporaire de la puissance du signal reu. Afin de dterminer la ncessit dun handover, les auteurs prennent en compte la bande passante (niveau rseau) et la puissance du signal reu (niveau physique) sans tenir compte de la QoS ni de la scurit. Par ailleurs, dautres travaux sont fonds sur des mthodes mathmatiques afin de dfinir des paramtres qui aident prendre la dcision de handover. Q. Song et al. dans [13] prsentent un mcanisme de slection de rseau (WLAN/UMTS) afin de garantir aux utilisateurs mobiles dtre toujours pris en charge par le meilleur rseau (ABC : Always Best Connected). Les techniques mathmatiques intitules Analytic Hierarchy Process (AHP) et Grey Relational Analysis (GRA) sont combines dans le mcanisme pour dcider le meilleur rseau pour les utilisateurs mobiles en trouvant un compromis entre la prfrence de l'utilisateur, le service rendu lapplication et les conditions du rseau. Ces mthodes ne sont pas bien adaptes un contexte 4G car il est difficile de modliser le systme 4G laide de ces mthodes analytiques qui ncessitent beaucoup de paramtres.

18 Une autre solution mathmatique est propose dans [14]. Les auteurs ont suggr un algorithme pour prendre la dcision dun handover UMTS/WLAN. Cet algorithme sappelle : Trust-Assisted Handover Decision Algorithm. Il prend en compte un environnement multi-oprateurs et multi-technologies et peut tre alors utile dans un contexte 4G. Afin de dcider le handover avec le rseau cible, lalgorithme propos spcifie un indicateur comme signe dun handover avec succs. Cela conduit baisser les tentatives supplmentaires et les handovers non ncessaires. Une solution architecturelle afin de slectionner le meilleur rseau a t propose dans [15], les auteurs proposent une architecture potentielle intgrant un rseau UMTS et un rseau WLAN IEEE 802.11 en utilisant un SGSN (Serving GPRS (General Packet Radio Service (2.5G)) Support Node) (Figure 7). Ils prsentent un modle analytique de dclenchement du handover fond sur les critres : la puissance du signal reu et la distance entre le nud et le point daccs ou la station de base. Ils mettent en place une entit fonctionnelle, appele NIU (Network Interwork Unit), pour raliser une interface standardise du rseau mre et pour cacher les particularits du WLAN. Donc, la NIU met en uvre toutes les fonctionnalits demandes comme lencapsulation des donnes, le transfert de signal, et constitue un pont entre les deux rseaux. La gestion de handover dpendant du protocole de mobilit MIP augmente le cot de signalisation ainsi que la latence du handover. La mission majeure de la conception dun handover est alors de rduire la probabilit de faire un handover si ce nest pas ncessaire, et en consquence de rduire la probabilit des appels rejets.

Figure 7 : Architecture propose [15]

En revanche, larchitecture propose possde quelques limitations ; en particulier, seule la probabilit du handover est value. Les auteurs ont galement considr quil y a seulement une seule cellule WLAN implante dans des cellules UMTS. De plus, ils ont suppos que la charge du rseau nest pas leve et que l'utilisateur se dplace tout droit. La prvision de rupture de lien peut aussi amliorer les performances de handover. Aust et al. proposent dans [16] un mcanisme de handover IP proactif (WLAN/GPRS). Dans cette tude, la dcision de handover proactif est fonde sur linformation de la couche liaison. Cela vite la rupture de lien lors du handover au niveau IP et ainsi rduit la perte de paquet en utilisant linformation de la couche liaison pour dclencher le handover avant la rupture

19 de lancienne connexion. D'ailleurs, les auteurs ont montr l'amlioration du handover en utilisant linformation modifie de la couche liaison. Par ailleurs, dans le contexte de rseaux de deuxime gnration, des travaux rcents [17] proposent une nouvelle architecture capable de prendre en charge le service Always Best Connected. Cette architecture, appele architecture ouverte, tient compte de diverses technologies d'accs radio. Tout dabord, un nouveau mcanisme de dcouverte d'accs intgre le protocole du service de localisation et le service fond sur la localisation. On propose un schma de slection de rseau. Les utilisateurs peuvent choisir le meilleur rseau en changeant les poids des facteurs et des contraintes. Enfin, un mcanisme de handover sans couture fond sur IPv6 mobile a t choisi. Ce mcanisme prend en compte la qualit de service de bout en bout.

4.4. Handover avec mobilit

Dans les rseaux 3G, la puissance du signal reu est considre comme lun des facteurs essentiels afin de dclencher les procdures dinitialisation et de dcision de handover. En revanche, dans les rseaux 4G, il faudra considrer dautres facteurs (QoS, cot, bande passante, etc.). Zafeiris et al. dans [18] grent un handover 4G (en phases dinitialisation et de dcision) comme le montre la Figure 8. Ils ont propos une architecture fonde sur un agent qui dtermine le rseau cible en respectant les contraintes des utilisateurs et des applications. Lutilisateur prend en charge le dclenchement des procdures dinitialisation et de dcision de handover selon le profil de lutilisateur (ses besoins) et des applications. Lagent de mobilit permet nimporte quel terminal, qui contient la plateforme agent, dtre utilis pour accder aux fournisseurs de service MAP (Multi Access Provider). Le fournisseur MAP prend en charge lauthentification et la facturation lorsque les utilisateurs se dplacent entre plusieurs rseaux. Cependant, cette proposition est une solution logicielle pure qui demande plusieurs entits et interfaces fournir au niveau de lutilisateur, du rseau et de loprateur.

Figure 8 : Plateforme dagents [18]

20 Un travail rcent propose une solution architecturale pour un handover UMTS/WLAN [19] (Figure 9) afin de baisser la perte de handover et amliorer la QoS. Les auteurs proposent une architecture fournissant la mobilit et la QoS (MQMA : Mobility and QoS Management Architecture) fonde sur le handover make-before-break de niveau IP afin de mettre en uvre un handover sans couture. Le handover vertical est transfr vers un handover horizontal si le rseau cible ne rpond pas aux besoins de la QoS demande ou si le handover vertical nest pas un handover sans couture. Pour cela, les auteurs mettent en place trois entits : HIDM (Horizontal Inter-Domain Management) qui permet deffectuer un handover horizontal, VIDM (Vertical Inter-Domain Management) qui soccuper du handover vertical et SIDM (Stand-by IDM) qui vite les appels de handovers dtre rejets. Le handover IP est galement pris en compte. Nguyen-Vuong et al. dans [20] proposent un schma dun handover sans couture UMTS-WiMAX fond sur IP mobile. Cette architecture repose sur la norme 3GPP. Le schma propos permet galement la continuit de service avec une latence faible et une faible perte de paquet. Les auteurs proposent le protocole IP mobile (MIP) commun au niveau rseau. La mobilit dans le rseau WiMAX est gre via un HA (Home Agent), et la mobilit dans le rseau UMTS est gre par son mcanisme de mobilit et par les fonctions de FA (Foreign Agent) implantes. Afin de rduire la perte de paquet lors de handover, le Foreign Agent informe le Home Agent du mouvement du terminal, le Home Agent met en attente les paquets et les envoie au terminal lorsquil sest dplac vers le rseau cible (quand le Home Agent reoit la mise jour MIP). En revanche, le problme dans une telle architecture est que si le terminal mobile se relie plusieurs points daccs, la phase de prparation du handover devient plus complique.

Figure 9 : Architecture propose [19]

21

4.5. Handover avec mobilit et localisation

La localisation du terminal mobile est aujourdhui la mode. Cela ncessite bien videment dautres entits afin de localiser le terminal, toutefois cela permet dviter des handovers non ncessaires. A. Saleh dans [21] a propos un algorithme qui prend en compte la localisation de lutilisateur dans une interconnexion de rseaux (WLAN/UMTS). Cela va empcher le dclenchement des handovers qui se produisent lorsque le terminal mobile rend visite au rseau WLAN pendant un laps de temps. Lide principale derrire lalgorithme propos est de prendre en charge les informations sur la position de lutilisateur, sa vitesse et sa direction pour connatre la dure de visite pour que lalgorithme de handover puisse dcider la ncessit du handover. Par ailleurs, Ylianttila a propos dans [22] une architecture de handover WLAN/UMTS dpendant de la localisation du terminal. Larchitecture propose permet au nud mobile de prparer le prochain handover et dactiver linterface rseau. Les paramtres de la procdure de handover pris en compte sont : la mobilit (vitesse de terminal), la position du nud mobile (information de go-localisation), la puissance du signal reu et le dlai de handover. Afin deffectuer la procdure de handover, lauteur a utilis un prototype de mobilit IP (MIP) pour rpondre aux applications VoIP.

4.6. Amlioration de handover horizontal

Quelques solutions ont t proposes pour amliorer les mcanismes de handover dans le rseau WiMAX IEEE 802.16e. Les auteurs dans [23], prsentent un algorithme pour amliorer le handover de niveau liaison dans lequel la station de base active fait suivre des donnes descendantes la station de base voisine cible. Les terminaux mobiles peuvent alors recevoir des donnes descendantes ds qu'ils deviendront synchroniss avec la station de base voisine. Le schma propos rduit le dlai de la transmission de donnes et la probabilit de perte de paquet pour le service temps rel sur le lien descendent. Mais une inefficacit vidente de ce schma consiste en son incapacit rduire la latence du handover dans le sens montant, qui est sensible pour quelques applications (par exemple, voix sur IP). Les auteurs dans [24] veulent se focaliser sur lamlioration de la procdure de dcision de handover. Pour cela, ils proposent dutiliser le rapport signal interfrence et bruit (Carrier-to-Interference plus Noise Ratio : CINR) et la diffrence de temps d'arrive ATD (Arrival Time Difference) pour prvoir la meilleure station de base cible. Ce schma a limit les interactions inutiles avec dautres stations de base voisines que la station de base cible. Cette mthode a montr son efficacit en rduisant le nombre d'interactions exiges. Cependant, elle empche galement le terminal mobile d'acqurir une information plus prcise qui serait normalement obtenue par un ranging et pourrait tre dcisive pour la slection finale de la station de base cible. Dautre part, lide damliorer la performance du handover vertical en utilisant la rservation de ressource pourrait amliorer les performances des rseaux htrognes. Trs peu de travaux de recherche sont faits sur ce sujet. Les auteurs dans [25] prennent en compte la rservation de bande passante dans des rseaux WiMAX et WiFi. L'allocation de ressource est fonde sur deux seuils correspondant au trafic de voix/data. La politique propose pourrait amliorer l'utilisation dune interconnexion de rseaux WiFi-WiMAX,

22 cela conduit augmenter le nombre d'utilisateurs servis ce qui augmentera les bnfices de l'oprateur. En tout cas, dans tous les travaux rcents, aucun na abord lamlioration de handover vertical en adoptant un mcanisme de rservation de ressources, autrement dit la prparation de la rservation avant quun nud mobile se dplace vers le rseau cible. De mme peu dtudes ont intgr la prise en compte dun systme satellite. Ce sujet sera lide de base dans notre travail, que nous prsenterons au fil des chapitres suivants.

5.

Systme satellite (DVB-RCS)

5.1. Prsentation
Les standards des systmes de communication par satellite europens sont tudis par lETSI et sont trs fortement influs par lapplication de rfrence qui est la diffusion tlvisuelle qui est intrinsquement unidirectionnelle. Les normes DVB-S et DVB-S2 [26] [27] ne spcifient donc pas de recommandation en ce qui concerne limplantation dune voie de retour. Pour les services interactifs, un lien est tabli soit par des liaisons terrestres via des lignes tlphoniques, soit par le satellite. La norme DVB-RCS fournit un standard dutilisation du satellite pour la voie de retour (Return Channel by Satellite). La norme DVB-RCS est donc considre comme un complment du DVB-S. En fait, les flux aller DVB-S possdent diffrentes informations pour rgir le systme global en termes daccs, de signalisation et de synchronisation des terminaux. Le systme DVB-RCS dfinit quant lui un systme large bande bidirectionnel par satellite pour des terminaux de type VSAT (Very Small Aperture Terminals) de sorte que la voie aller suit la norme DVB-S (ou DVBS2) et la voie de retour les spcifications techniques pour linterface air comme expliques dans [27].

5.2. Architecture DVB-RCS

Larchitecture classique du DVB-RCS (Figure 10) est en toile ; tout le trafic engendr par les terminaux utilisateurs (RCST : Return Channel Satellite Terminal) transite par la Gateway/NCC (Network Control Center) qui est comme une passerelle entre les RCST et les fournisseurs daccs Internet [26]. Les RCST peuvent mettre et recevoir des donnes. En outre, des mthodes de gestion du rseau, par exemple laccs au systme et aux ressources, doivent tre dfinies. Des entits prennent en charge les oprations de contrle, de supervision, de gestion du systme de communication, etc. Le centre de contrle gre laccs au systme et une grande partie de la signalisation. Dans une deuxime gnration de satellites, les procdures de gestion du systme pourraient tre implantes bord du satellite. Dautre part, afin de fournir un accs Internet pour des usagers localiss dans une zone non couverte par un rseau infrastructure, les terminaux RCST peuvent tre considrs comme un relais du trafic IP.

23

Figure 10 : Architecture DVB-RCS [26]

5.3. Pile protocolaire

La norme DVB-RCS possde deux piles protocolaires possibles (Figure 11) [26]. Ces piles sont diffrentes au niveau de la couche 2 dans la mesure o il y a deux mthodes dencapsulation des donnes transmettre : une mthode qui utilise les cellules ATM et une autre fonde sur les paquets MPEG2-TS (Moving Picture Experts Group - Transport Stream). Toutefois, lencapsulation par la couche AAL-5 (ATM Adaptation Layer) est la technique obligatoire que chaque terminal RCST doit pouvoir lutiliser. La seconde mthode dencapsulation, dfinie par la couche MPE (Multi-Protocol Encapsulation), est optionnelle [27].
IP AAL-5 ATM MPE MPEG-2 TS DVB-RCS

Figure 11 : Pile protocolaire du DVB-RCS [26]

5.4. Couche physique

La chane de transmission du DVB-RCS montre sur la Figure 12 [26] repose sur lmission de slots (bursts) (ce nest pas le cas en DVB-S). Les donnes (trafic ou donnes de niveau MAC) sont aussi formates en slots. On distingue quatre types de slots : Le slot TRF (TRaFfic) de trafic : ce slot contient les donnes, ATM ou MPEG-2, des

24 terminaux. Le slot CSC (Common Signaling Channel) : ce slot prend en charge lidentification des terminaux lors de la phase de log-on. Le slot ACQ (ACQuisition) permet une synchronisation grossire des terminaux. Le slot SYNC (SYNChronisation) permet une synchronisation plus fine des terminaux et transporte des informations telles que les demandes de connexion, les requtes de capacit, etc. Ensuite, les slots forms sont embrouills afin de disperser lnergie. Pour les protger contre les erreurs, un codage canal adquat est ncessaire. Puis, ces slots sont transmis par une modulation QPSK. Le codage des slots peut tre effectu de deux faons diffrentes : soit ils sont cods suivant la concatnation des codages Reed-Solomon et convolutifs, comme dans la chane de transmission du DVB-S, soit ils sont cods par un turbo-code.
Donnes Formation de burst Dispersion dnergie Codage de canal Modulation QPSK

Synchronisation

Figure 12 : Chane de codage du DVB-RCS [26]

5.5. Mthode daccs

5.5.1. Partage des ressources Contrairement la norme DVB-S, o il y a un nombre trs limit dutilisateurs gateways qui accdent au rseau, dans la norme DVB-RCS un nombre considrable de terminaux se partagent les ressources du rseau [26]. La norme DVB-RCS fournit un partage de la bande passante par une technique MF-TDMA (Multi Frequency Time Division Multiple Access). Cela permet une bonne efficacit spectrale et la prise en compte de nombreux terminaux. Deux modes de partage MF-TDMA existent : un mode statique et un mode dynamique. Dans le mode statique on utilise une mme configuration MF-TDMA trame par trame. En revanche, dans le mode dynamique, la structure MF-TDMA permet de varier dune priode lautre : la proportion des diffrents niveaux de codage pouvant varier. 5.5.2. Allocation des ressources Puis quil y un nombre considrable de terminaux, lallocation fixe et constante des ressources demandes par terminal nest pas adapte [26]. On met donc en place des procdures de requtes dynamiques de connexions : afin de satisfaire les critres de QoS pour une application, le terminal est amen envoyer la Gateway/NCC des messages contenant ses besoins en terme de capacit. Dans ce cas, le NCC va rpondre aux requtes en allouant chaque groupe de terminaux une supertrame (comportant plusieurs trames) ; chaque trame sera divise en time-slots qui transportera ensuite les slots contenant les donnes des terminaux. Lallocation se produit deux niveaux : au niveau connexion par la fonction CAC

25 (Contrle dAdmission des Connexions) et au niveau MAC par la fonction DAMA (Demand Assignment Multiple Access). La fonction CAC permet daccder au support pour toute la dure de connexion en rservant une partie des ressources. La fonction DAMA quant elle permet dassurer lallocation des time-slots au terminal pour vrifier les paramtres de QoS (dbit, gigue, temps de transfert, etc.). Ces deux fonctions sont alors utilises sur deux chelles de temps diffrentes.

6.

Solutions pour linterconnexion des rseaux sans fil

6.1. Introduction
Dans ce paragraphe, nous allons prsenter les diffrentes solutions pour linterconnexion entre les rseaux sans fil (Figure 13). Ces solutions ont t considres au sein de plusieurs organismes de standardisation aussi bien par lIEEE et par le 3GPP quau niveau de lIETF (Internet Engineering Task Force). Nous en dcrivons dans la suite quelques unes et nous nous focaliserons sur une solution propritaire qui sest impose en tant que standard du 3GPP.
VCC I-WLAN SAE-LTE 802.11r 802.16e

GAN

3GPP/2
Inter-fonctionnement & Signalisation de handover

IEEE IEEE 802.21

Handovers horzontaux
Mobilit IP & signalisation de Handover

MIP DNA

SIP FMIP

IETF

HI MIPSHO

Figure 13 : Les standards pour le handover

6.2. Generic Access Network (GAN)

Aujourd'hui plusieurs choix d'interconnexion sont dvelopps (essentiellement entre rseaux terrestres sans fil). Tous sont fonds sur des architectures protocolaires propritaires. GAN en est un exemple qui permet de fournir un service GSM (Global System for Mobile communications)/GPRS sans couture sur n'importe quel rseau d'accs (par exemple WLAN). Ce choix dinterconnexion permet de favoriser la performance. Il permet de fournir de nouveaux services avec un impact minimal sur le rseau de cur, sur les services du rseau et sur l'infrastructure radio existante. En fait, le consortium GAN (initialement appel UMA (Unlicensed Mobile Access)) a t constitu par des entreprises de l'industrie du sans fil afin de dvelopper la technologie

26 GAN et ses spcifications [28]. Ce consortium travaille avec l'organisme de normalisation 3GPP pour dvelopper la norme standard pour GAN. En septembre 2004, le consortium GAN a dit un premier ensemble des spcifications de GAN mais la norme est encore l'tat de test aujourd'hui. Le standard GAN dtaille l'utilisation d'un terminal bi-mode au travers d'une connexion radio avec licence GSM lorsqu'il est l'extrieur d'une couverture GAN, et d'une connexion radio sans licence (Bluetooth ou WiFi) lorsqu'il est dans une zone de couverture GAN. Avec GAN (Figure 14), les consommateurs peuvent utiliser des applications de voix et de donnes sans se soucier de la transition entre les rseaux : on parle de mobilit sans couture. Ds qu'un utilisateur possdant un terminal bi-mode, implantant la technologie GAN, rentre dans une zone de couverture d'un rseau sans licence auquel il peut se connecter, la procdure de handover va s'initialiser. Lors de la connexion, le terminal contacte le GAN Controller (GANC) par l'intermdiaire du rseau d'accs IP large bande afin d'tre authentifi et autoris accder au service de voix du GSM et de donnes du GPRS au travers du rseau sans fil sans licence. Si la connexion est accorde, les donnes courantes de localisation de l'utilisateur sont mises jour et partir de ce moment, toutes les communications de voix et le trafic de donnes sont routs vers le terminal via le GAN Network au lieu du Radio Access Network (RAN).

GAN

GAN Controller

GAN

Figure 14 : Rseau GAN [28]

6.2.1. Architecture GAN Le GANC (Figure 15 et Figure 16) est connect au rseau IP priv ou public et au cur du rseau mobile en utilisant les interfaces des standards industriels [28]. Il assure donc les mmes fonctions qu'un contrleur de station de base BSC (Base Station Controller). Il connecte MSC (Mobile Switching Centre) et SGSN (Serving GPRS Support

27 Node) dj existants par l'intermdiaire des interfaces A et Gb du GSM/GPRS. Tout le trafic est rout au travers du cur du rseau permettant de n'effectuer aucun changement dans la manire de facturer. Cela permettra d'amliorer le rseau mobile sans en changer les quipements dj mis en place. Quand le terminal mobile est connect un rseau WLAN, il va communiquer avec un point d'accs standard WLAN. Le client GAN, dans le terminal, va initialiser un tunnel IP scuris (Figure 16) au travers du rseau IP (priv ou public) afin de se connecter au GAN Controller (GANC).

Figure 15 : Architecture GAN [30]

Comme on peut le voir sur le schma (Figure 16), tous les trafics de l'utilisateur (voix et donnes) et la signalisation passent par le tunnel IP scuris depuis le terminal mobile jusqu'au cur du rseau de l'oprateur mobile. Le tunnel scuris VPN (Virtual Private Network) apporte une scurit supplmentaire par rapport au mcanisme d'authentification et de scurit, qui est dj pris en compte dans le standard GSM.

GAN-enabled Mobile

GAN Controller GANC

GAN Solution

Figure 16 : Le tunnel scuris [28]

28 6.2.2. Avantages, inconvnients et dfis La technologie GAN est lheur actuelle lunique solution dploye pour un accs WLAN mobile mais elle nest pas la solution optimale pour un accs de donnes. Plusieurs avantages sont fournis par cette technologie. Dabord, cette solution permet dutiliser le WLAN comme tout autre rseau daccs avec des impacts minimaux : sur le rseau de cur, sur les services rseau, et sur linfrastructure radio existante. De plus, tous les services peuvent tre fournis par le WLAN avec le moins de changements possible. Enfin, elle permet des handovers sans couture pour lutilisateur. En revanche, cest une solution de haute complexit et lenvoi de donnes ncessite lencapsulation IP sur GPRS sur GAN sur IP. Dailleurs, cette technologie procde lutilisation de plusieurs niveaux de scurit (scurit WLAN, IPsec (protocole de scurit IP) et scurit GPRS). Enfin, elle nest pas fonde sur IP tandis quil y a aujourdhui une tendance gnrale au tout-IP. En contrepartie, il y a plusieurs dfis associs au WLAN/GAN concernant la configuration de la scurit, qui est tout sauf simple, surtout lorsquon parle de la configuration du mobile. La mobilit dans un WLAN o les WLAN sont scuriss par des problmes pour la prise en charge du fast roaming. De plus, les Firewalls ne fonctionnent pas toujours bien avec IPsec, alors que la tendance gnrale est au tout-IP. Dautre part, la localisation est fonde sur WLAN et non sur GSM. Cela pose des problmes par linteroprabilit et la mise en place de mcanismes dquilibrage de charge. La qualit de la voix sur IP/WLAN reste galement un dfi. 6.2.3. Positionnement de la technologie GAN [31] [32] : Le dploiement de la solution GAN est tributaire du dveloppement de certaines technologies : volution court terme : - VoIP : la solution GAN permet surtout de fournir un service de type voix. Nanmoins, lutilisateur peut aujourdhui installer le logiciel skype ou dautre logiciels tlphoniques sur son mobile. Cela lui permet non seulement de rpondre aux besoins en terme de service voix mais galement denvoi de donnes (MMS, etc.) et de tenir compte de la mobilit (nomadisme de niveau IP). GAN est principalement vu comme une solution pour fournir un accs gnrique, travers un rseau daccs WiFi, aux services GSM/GPRS mais rien nempche laccs des services de rseau WiMAX via un rseau daccs WiFi ; ou laccs via un rseau daccs WiMAX aux service GPRS/3G. Cependant, plusieurs questions sur lefficacit et sur la faisabilit restent ouvertes. volution moyen terme : La relation entre GAN et IMS (IP Multimedia Subsystem) est caractrise par le rle que pourront avoir ces technologies dans les rseaux mobiles. GAN est utilis au niveau dun rseau daccs, limit fournir des services via le rseau mobile mre (GSM/3G). Remarquons que tous les services disponibles via le rseau mobile mre seront aussi disponibles via GAN. IMS est une norme qui dfinit une architecture gnrique offrant des services multimdias

29 via nimporte quel rseau IP. IMS spcifie l'interoprabilit et est bien intgr dans les rseaux doprateurs en adoptant plusieurs des caractristiques principales du domaine des tlcoms. IMS fournit des services n'importe quel rseau d'accs fond sur IP et des services fournis par IMS fonctionneront de la mme manire dans GAN que dans le rseau daccs radio GSM/3G. GAN augmente le dploiement de services IMS en fournissant la mobilit sans couture entre le rseau WLAN et le rseau daccs radio GSM/3G. GAN doit tre considr en tant qu'une des technologies daccs aux services IMS. A un autre niveau, IMS permet de fournir des services multimdias, mais ne prend pas en charge la mobilit des utilisateurs. De plus, le dploiement d'IMS n'est pas ce jour bien concrtis. Plusieurs de ses concepts comme la continuit de voix (VCC) sont en cours de standardisation. En revanche, ce choix ne permet pas de prendre en compte la mobilit pour des services autres que la voix. volution long terme : Tout IP : cette dernire solution est fonde sur IP mobile. Lvolution est considre long terme et elle est trs loin dtre standardise. Nanmoins, lIETF apporte des solutions adaptes au niveau rseau pour tenir compte de lhtrognit de mdias.

6.3. Media Independent Handover (MIH IEEE 802.21)

La ralisation de handover entre des rseaux d'accs htrognes de manire transparente du point de vue de l'utilisateur mobile (sans couture ni dtrioration) ncessite la prise en compte de certaines notions telles que la continuit de service, les classes d'application, la qualit de service, la dcouverte et la slection du rseau, la scurit et la gestion de la consommation d'nergie du systme mobile [28] [29]. Le groupe de travail IEEE 802.21 a pour cela cr une architecture de base qui dfinit une fonction MIHF Media Independent Handover Function qui va aider les systmes mobiles effectuer un handover sans couture entre des rseaux d'accs htrognes tels que IEEE 802.3 (rseau local filaire), IEEE 802.11x (rseau local sans fil), IEEE 802.16e (rseau WiMAX mobile), GPRS et UMTS (rseau mobile 3G), en venant s'interfacer avec les protocoles de polling et de mobilit des couches suprieures. 6.3.1. Objectifs initiaux Initialement le groupe IEEE 802.21 sest fix les objectifs suivants : - Mettre en uvre des terminaux qui soient capables d'interagir avec diffrents rseaux. - Respecter le principe d'une communication toujours active always-on, anytime, anywhere, any networks [28]. - Optimiser les transitions travers les diffrents rseaux pour qu'elles soient sans couture ni dtrioration : mobilit sans couture. La Figure 17 reprsente le modle de rfrence dun rseau logique IEEE 802.21. La normalisation IEEE 802.21 est toujours en cours. Un premier draft est paru en juillet 2005 [29] ; des amliorations ont t proposes.

30 6.3.2. Prsentation du standard IEEE802.21 Nous prsenterons dans la suite le standard IEEE 802.21 [28]. Le standard IEEE 802.21 consiste en l'laboration d'une architecture qui permet la continuit de service de manire transparente lorsque le terminal mobile (Mobile Node) passe entre deux rseaux htrognes au niveau liaison de donnes. Un ensemble de fonctions permettant l'optimisation du handover est dfini dans la pile protocolaire de gestion de mobilit MME (Mobility Management Entity) des lments du rseau et il y a une cration d'une nouvelle entit appele MIHF (Media Independent Handover Function). Ensuite, il consiste en la dfinition d'un point daccs au service (MIH_SAP) et des primitives associes qui fournissent aux utilisateurs de MIH laccs aux services MIHF. La dfinition de nouveaux points daccs au service SAPs (Service Access Points) de niveau liaison de donnes et des primitives associes pour chaque technologie d'accs (IEEE 802.3, IEEE 802.11x, IEEE 802.16) est aussi prise en compte par le standard IEEE 802.21.

Figure 17 : Modle de rfrence du rseau logique [28]

Le standard IEEE 802.21 (Figure 18) spcifie des procdures qui facilitent la prise de dcision du handover, fournit l'tat de niveau liaison de donnes sous forme d'informations

31 aux utilisateurs de MIH. Cela permet d'effectuer des handovers de faible latence entre des technologies de rseaux daccs diffrentes. Il dfinit les mthodes et la smantique ncessaires pour faciliter l'obtention des informations du rseau et donc optimiser la dtection des rseaux disponibles prsents dans un environnement. Le standard gre la spcification des procdures de commandes qui permettent de mettre en uvre la continuit de service sans couture entre des rseaux htrognes. IEEE 802.21 n'excute pas les handovers et ne dfinit pas non plus les politiques de dcision de handover. Il ne contrle pas la dtection du rseau et ne spcifie pas les procdures de slection de rseau.

Figure 18 : Echelle de norme IEEE 802.21 [28]

En rsum, IEEE 802.21 ne fait qu'aider les couches suprieures pour dbuter et prparer les handovers, et ne gre en aucun cas l'excution de ceux-ci. 6.3.3. IEEE 802.21 Media Independent Handover Function (MIHF) Aprs un long processus, le groupe de travail a dcid que MIH serait une couche intgre au-dessus du niveau PHY/MAC (2.5 Layer) plutt qu'une API (Application Programming Interface) (Figure 19).

32

Figure 19 : Fonction de MIH [28]

La fonction IEEE 802.21 de Media Independent Handover (MIHF) est une couche positionne dans la pile protocolaire Mobility Management ct mobile et rseau. La fonction MIH fournit des services aux couches hautes au travers d'une interface indpendante mono-technologie. Elle obtient des services des couches infrieures au travers des nombreuses interfaces dpendantes de la technologie ou SAPs. Media Independent Event Service (MIES) : En rgle gnrale, les handovers peuvent tre initialiss aussi bien par le terminal mobile que par le rseau [28]. Les vnements, qui peuvent initier un handover, peuvent provenir des couches MAC, PHY ou de la fonction MIH et ce depuis le MN (Mobile Node) ou le PoA (Point of Attachement) du rseau. Cela peut tre d la mobilit du terminal, des changements d'tat de l'environnement ou une fonction de gestion dans la partie rseau. En effet, la cause des vnements peut tre locale ou distante. Un protocole de transport est ncessaire pour grer les vnements distants (remote events). Plusieurs entits des couches suprieures peuvent tre intresses par ces vnements en mme temps. Donc, ces vnements doivent pouvoir avoir plusieurs destinations. Ainsi, les couches suprieures peuvent s'enregistrer pour recevoir les notifications d'vnements gnres par des sources particulires grce la fonction MIH qui va redistribuer les vnements. On notera que les vnements sont traits de manire discrte. Dans certains cas, un vnement peut avoir des informations qui lui sont lies. C'est pourquoi, un identifiant est affect l'vnement afin que d'autres vnements s'y associent en utilisant cet identifiant. Le service dvnement peut tre divis en deux catgories : vnements de lien et vnements MIH. Typiquement, les deux vnements se transmettent d'une couche basse une couche haute. Les vnements de lien sont dfinis comme issus d'une entit positionne

33 sous la fonction MIH pour arriver MIHF. Les entits gnrant les vnements de lien sont les diffrentes technologies d'accs IEEE 802, les technologies 3GPP et 3GPP2. A l'intrieur de MIH, les vnements de lien peuvent tre propags aux couches suprieures qui se sont enregistres pour des vnements spcifiques, avec ou sans traitement additionnel. Les vnements, qui sont propags par MIH, sont appels MIH Events. Media Independent Command Service (MICS) : Le service de commande MICS (Media Independent Command Service) concerne les commandes envoyes depuis les couches suprieures vers les couches infrieures du modle de rfrence [28]. Les couches hautes et les autres utilisateurs MIH peuvent utiliser le service de commandes pour dterminer les tats des liens et/ou contrler de manire optimale les performances du terminal multi-mode. Le service de commandes peut aussi permettre aux utilisateurs MIH d'excuter de manire optimale le handover car les services de commande contiennent des informations dynamiques telles que la puissance du signal, le dbit du lien, etc. Comme pour les vnements, il existe deux types de commandes : les commands MIH et les commandes de lien. Les figures ci-dessous illustrent les diffrences entre ces commandes. Media Independent Information Service (MIIS) : La fonction principale du service dinformation est de permettre aux terminaux mobiles ainsi quaux entits ct rseau, de dcouvrir linformation qui peut les aider slectionner correctement un rseau lors dun handover [28]. Cette information sera principalement utilise par des entits permettant de dfinir des politiques base de rgles. Grce ces informations, ces moteurs sont capables de prendre la bonne dcision lors dun handover. Le service dinformation doit fournir pour une grande partie, une information de type statique. Dautres informations dynamiques sur les diffrents rseaux daccs tels que les niveaux instantans de ressources disponibles, les paramtres dtat, les statistiques dynamiques, etc. devraient tre obtenus directement auprs des rseaux daccs respectifs. Modles MIH de rfrence : Les modles MIH de rfrence pour toutes les technologies envisages par le standard (IEEE 802.3, IEEE 802.11x, IEEE 802.16, 3GPP et 3GPP2) sont illustrs ci-dessous [28]. Ainsi, pour chaque technologie d'accs, le standard IEEE 802.21 dfinit des points d'accs qui permettront les changes de primitives avec MIH. Les diffrents points daccs au service (SAP), dfinis par le standard IEEE 802.21, sont regroups sur la figure suivante (Figure 20).

34

Figure 20 : Points daccs au service [28]

6.3.4. Scnarios du standard

Le groupe de travail sappuie sur des scnarios et des cas d'usages pour modliser au mieux les diffrents cas de handovers grs par le standard IEEE 802.21. Classes de scnarios : Les diffrents scnarios de Handover dfinis par le standard IEEE 802.21 se dcomposent en 4 grandes classes [28] : - Classe 1 : Le mobile et le rseau implantent le module MIH. Dans ce cas, le handover se fera en suivant la procdure recommande par le standard. - Classe 2 : Le mobile implante MIH, mais pas le contrleur rseau : le handover (si cela est possible) se fera l'initiative du mobile. - Classe 3 : Le contrleur rseau implante MIH, mais pas le mobile : le handover (si cela est possible) se fera l'initiative du contrleur rseau. - Classe 4 : Ni le mobile, ni le rseau n'implantent MIH : c'est le cas des systmes actuels. Le handover est impossible. Scnarios pour la mise en uvre de MIH : A ces classes s'ajoutent les scnarios ou plutt les cas d'utilisation sur lesquels le groupe de travail IEEE 802.21 va devoir s'appuyer pour dfinir les modles de MIH [28]. Ces scnarios permettent de mettre en vidence les diffrents handovers inter et intratechnologies. Scnario n 1 : IEEE 802.11x <=> IEEE 802.16e

35 Une station multi-mode est connecte son Intranet en IEEE 802.11x. Elle traverse le campus vers un autre btiment. Entre les 2 btiments, la connexion Intranet se fait en IEEE 802.16. Scnario n 2 : IEEE 802.x <=> 3G Une station multi-mode est connecte son Intranet en IEEE 802.x. Elle souhaite continuer sa session sur un rseau GPRS/UMTS ou vice-versa. Scnario n 3 : IEEE 802.11x <=> IEEE 802.11y Une station uni-mode est connecte Internet depuis un hotspot public IEEE 802.11 dans un htel. L'utilisateur part une confrence o un autre hotspot 802.11 est prsent, mais avec un ESS (Extended Service Set) diffrent. Il souhaite continuer sa session. Scnario n 4 : IEEE 802.11x <=> IEEE 802.11y ou IEEE 802.11z Une station uni-mode se trouve dans un aroport et voit plusieurs SSIDs (Service Set Identifiers) possibles pour crer une association : quel rseau va-t-elle choisir ? Scnario n5 : IEEE 802.3 <=> IEEE 802.11x Une station multi-mode est connecte de faon filaire et se dplace faiblement dans la mme rgion o se situe un hotspot 802.11x. L'utilisateur souhaite continuer sa session. Derniers scnarios 3G Cellular IEEE 802.x : Les handovers entre un rseau cellulaire 3G et IEEE 802.x ont t plus amplement dtaills et trois nouveaux scnarios ont t dfinis [28] : Scnario A : le rseau 3G n'implante pas MIH. Scnario B : le rseau 3G implante MIH et fournit un service dinformation IS (Information Service), un service dvnement ES (Event Service) et un service de commande CS (Command Service). Scnario C : le rseau 3G utilise un proxy MIH pour les IS, et fournit les ES et CS. Scnario A : le rseau 3G visit n'a pas de connaissance du IEEE 802.21 (pas de fonction spcifique IEEE 802.21 implante dans le rseau 3G). Donc, le rseau 3G visit n'a pas le contrle de la dcision du handover. C'est le rseau mre qui contrle la slection du rseau et la dcision du handover. Scnario B : les exemples illustrant le scnario B pourraient tre : - L'oprateur possde diffrentes technologies d'accs et permet ses abonns l'accs multiple sur ses rseaux. - L'oprateur a des accords de "roaming" afin de couvrir l'accs multiple de ses abonns sur les autres rseaux. Le rseau 3G peut contrler la slection du rseau et la dcision du handover dans le gestionnaire de mobilit MME (Mobility Management Entity). Scnario C : Un proxy est utilis pour accder au service dinformation IS depuis les autres rseaux. L'exemple illustrant le scnario C pourrait tre : L'oprateur n'a pas d'accord de "roaming" pour couvrir l'accs multiple de ses abonns. Le rseau 3G contrle la prise de dcision du handover.

6.4. Protocole FMIP (Fast Mobile IPv6 Protocol)

Tout comme lIEEE, plusieurs organismes de standardisation se sont attels proposer des cadres gnraux pour favoriser l'intgration de rseaux htrognes. Le

36 groupe MIPSHOP (Mobility for IP : Performance, Signaling and Handoff Optimization) a t cr au niveau de lIETF afin d'tudier les interactions entre les mcanismes de niveau rseau et ceux spcifiques aux technologies d'accs de niveau liaison de donne. Ces travaux profitent ainsi du cadre gnrique IEEE 802.21 propos pour optimiser les performances du systme global en utilisant des mcanismes d'interactions (cross-layer) entre diffrents niveaux. Ce groupe met en place un ensemble de protocoles comme par exemple FMIP6, qui est une extension du protocole Mobile IPv6, et qui propose danticiper des oprations de la couche rseau en utilisant des dclencheurs de niveau deux. Ces dclencheurs sont des messages gnriques tout protocole de la couche liaison qui avertissent dun changement dans ltat de liaison du mobile avec les points daccs. Le but est dautoriser le nud mobile envoyer les paquets sans dlai et dlivrer des paquets au nud mobile ds lattachement au NAR (New Access Router). Plusieurs scnarios ont t prvus afin danticiper le handover de niveau 3 (un mode proactif et un mode ractif ont t en particulier dfinis).

6.5. Solutions fondes sur IEEE 802.21

Lintrt de la norme IEEE 802.21 est de fournir une couche de niveau 2.5 intelligente et indpendante (MIH) de la technologie radio afin deffectuer un handover sans couture. Cela requiert lamlioration de la continuit de service, de la QoS, de la mobilit, de la consommation de puissance, de la scurit, etc. Les travaux de recherche abordent plusieurs points : rduction de la latence de handover, du dlai de handover, de la perte de paquet lors de handover, de handover sans couture (continuit de service), de la QoS, etc. On se focalise en particulier sur lamlioration de la fonctionnalit des entits MIH ou bien les services, en les dveloppant ou bien en ajoutant des nouvelles primitives et des entits supplmentaires pour quelles puissent prendre en compte les besoins demands. En rsum, nous pouvons dire que les thmes les plus abords sont les suivants : amlioration de handover FMIP6, dcision de handover, mobilit, handover sans couture et QoS. Nous allons maintenant exposer les diffrents travaux dans ce cadre. Loptimisation de performance du handover FMIP6 a t un des sujets les plus traits. Pour cela, certains veulent amliorer les primitives de MIH et ajouter de nouvelles entits. Les auteurs dans [31] ont fait face au problme de la latence de handover FMIP6 fond sur IEEE 802.21. Lintrt est de rduire la latence de handover dun mobile IPv6 en baissant la dure de dcouverte de routeur et la dure de linitialisation du handover. Pour cela, les auteurs proposent un mcanisme amliorant le handover en ajoutant de nouvelles primitives et paramtres de services MIH en dfinissant une nouvelle primitive lie toutes les primitives actuelles de MIH. La nouvelle primitive contient un prfixe dinformation sur le routeur daccs. Le niveau trois du routeur daccs envoie la nouvelle primitive au niveau deux afin de linformer lorsquil y a un nouvel attachement de point daccs (IEEE 802.11) ou lorsque le prfixe est chang. Par consquent, le niveau deux du routeur et le point daccs peuvent obtenir linformation de prfixe sur leur routeur. Le niveau trois du nud mobile cherche les informations sur les points daccs voisins en utilisant de nouvelles primitives. Bref, le nud mobile pourrait tre capable de chercher des informations sur le nouveau point daccs sans la procdure de dcouverte de routeur.

37 Par ailleurs, la couche IP a besoin des dclencheurs de la couche deux afin de configurer la nouvelle adresse IP (nCoA : new Care-of-Address). Avec les primitives actuelles de MIH, la performance de handover MIP6 est limite car le service MIH est utilis seulement pour dcouvrir les informations de niveau deux. Par consquent, il est difficile damliorer le handover FMIP6. Pourtant, en prenant en compte les nouvelles primitives, la dure de linitialisation devient faible, cela conduit effectuer un handover FMIP6 en mode prdictif et baisser la latence de handover FMIP6. Lamlioration des services MIH afin deffectuer un handover FMIP6 est encore traite dans [33] [34]. Les auteurs veulent faire face aux problmes qui dgradent la performance de FMIPv6 comme la dcouverte de laccs radio et la dcouverte de routeurs. Pour cela, les auteurs amliorent le service dinformation (MIIS) pour quil puisse avoir des informations sur les rseaux daccs voisins. De plus, ils proposent un nouveau message (Information Report) qui porte des informations de couches 2 et 3 concernant les rseaux daccs voisins. Cela a permis de rduire le temps danticipation ainsi que la dure de latence de handover. Ce dernier travail [34] a t dvelopp dans [35] dans le cadre des rseaux vhiculaires (Figure 21) en tendant le handover FMIP6. Cela ncessite de fournir des messages supplmentaires dfinis dans la prise en charge de base des rseaux mobiles (NEMO : Networks Mobile). De plus, les auteurs dfinissent un service : HNI (Heterogeneous Network Information) pour avoir des informations aux niveaux deux et trois sur les rseaux voisins obtenues par le service MIIS (IEEE 802.21). Afin de rduire la dure danticipation de FMIP6, les auteurs proposent un cache appel : NNR (Neighboring Network Report Cache) install dans le nud pour stocker le rapport HNI. Cela rduit la dure danticipation de FMIP6 et la signalisation. En outre, les auteurs dfinissent une nouvelle primitive de service de commande MICS afin de rpondre aux besoins de QoS. Comme on a vu dans les travaux de recherche sur les rseaux terrestres (cf.4), la dcision de handover est un des points importants qui attire lattention des chercheurs. Les auteurs dans [36] amliorent la procdure de la dcision de handover IEEE 802.21 MIH en utilisant des informations de la couche application et concernant les utilisateurs. Afin de slectionner le meilleur rseau, les informations sont regroupes pour former un degr dagrgation selon plusieurs facteurs de QoS (bande passante, gigue, dlai, taux de perte, etc.). Ce dernier travail [36] a t dvelopp dans [37] pour quil tienne compte de la mobilit. Les auteurs proposent un cadre dun IEEE 802.21 MIH amlior et un mcanisme pour grer la mobilit sans couture en fournissant des nouvelles entits fonctionnelles concernant la couche liaison et la couche application. Larchitecture pourrait tre implante dans la norme IEEE 802.21 et bnficier au client ainsi qu loprateur. Un autre point de vue afin deffectuer un handover sans couture consiste ajouter un mcanisme pour prvoir la taille dun buffer ddie des donnes du handover. Wang et al. dans [38] proposent un algorithme pour la prdiction de la taille dun buffer rgle dynamiquement afin damliorer les fonctionnalits de MIH IEEE 80.21. Une couche SSL (Service Specific Layer) a t propose (Figure 22) pour fournir les informations ncessaires MIH afin de mettre en uvre la procdure de handover. Durant la dure de coupure (du rseau dorigine), due au handover, le systme peut fournir le service lutilisateur et par consquent les utilisateurs ne ressentent pas la coupure de service.

38

Figure 21 : Architecture propose [35]

Lamlioration de performance du handover sans couture avec un dlai faible est trait autrement en implantant un modle de double interface radio sur le nud mobile avec un mcanisme cross-layer. Dans [39] [40], les auteurs ont propos un modle de double interface air utilisant les services IEEE 802.21 MIH. En plus du dveloppement des services IEEE 802.21 MIH, lintgration dun rseau IEEE 802.16 avec dautres rseaux a aussi intress les chercheurs. Les auteurs dans [41], proposent des schmas de handover MIPv6, de handover horizontal et de handover vertical dans un rseau htrogne IEEE 802.11g/IEEE 802.21. On a vu dans le travail propos dans [36] que les auteurs ont dvelopp, dans ce but, le service dinformation IEEE 802.21 MIH. Cependant, les auteurs de ce travail, afin de slectionner le rseau cible auprs des nuds mobiles, proposent dajouter les entits suivantes pour prendre en charge les handovers : un schma IHS (Integrated Handover Scheme), service PoS (Point of Service) et un service dinformation IS (Information Service). Ils ont de plus propos un protocole du handover horizontal et vertical pour optimiser les performances de MIPv6. Par ailleurs, comme on a vu dans les travaux prcdents, lamlioration de handover est toujours mene en ajoutant des entits. Les auteurs dans [42] proposent dautres entits pour un autre type dintgration. En fait, les auteurs sintressent une solution dun handover WiMAX/3G fond sur IEEE 802.21 MIH. Pour ce faire, les auteurs proposent dajouter plusieurs entits. Afin de fournir les services MIH, tous les rseaux daccs et les utilisateurs doivent avoir MIHF. Cependant, les points daccs au service (SAPs) sont rutiliss. Cette solution reste coteuse. Dans [43], les auteurs ont propos un cadre (Figure 23) pour la continuit de service entre un rseau WLAN et un rseau WMAN fond sur IEEE 802.21 MIH.

39

Figure 22 : Architecture propose [38]

Les auteurs proposent plusieurs entits ajouter pour fournir la QoS lorsque le nud mobile passe dun systme un autre et pour fournir aux nuds les informations ncessaires pour quils puissent prendre la dcision du handover. Enfin, un travail rcent propos dans [31] concerne un handover sans couture en tenant compte de la QoS entre le rseau IEEE 802.16e et le rseau UMTS. Le cadre est fond sur IEEE 802.21 MIH et utilise les services dfinis dans IEEE 802.21. Afin de mettre en uvre le handover, le rseau de service examine la possibilit que le rseau cible rponde aux besoins de QoS du nud mobile. Une mise en correspondance des paramtres de QoS est faite. Le rseau de service rserve les ressources pour le nud mobile afin de maintenir la QoS une fois que le nud mobile sy dplace. Enfin, le nud mobile active les ressources rserves lors de ltablissement de connexion au niveau deux en mettant en route la procdure dinitialisation sur le rseau cible. Toutefois, cela ajoute des nouvelles primitives MIH. Pour conclure, nous avons prsent les travaux effectus dans le cadre des solutions fondes sur IEEE 802.21 MIH afin de mettre en uvre et amliorer le handover sans couture en tenant compte de QoS et de mobilit dinteraction avec le handover FMIP6, etc. Ces thmes sont toujours dactualits.

40

Figure 23 : Cadre dintgration propos [43]

6.6. Comparaison des solutions IEEE 802.21 et GAN

Bien que l'on dsigne la technologie GAN comme une technologie propritaire et distingue du standard IEEE 802.21, nombreuses sont les diffrences entre les spcifications [28]. - Le standard IEEE802.21 concerne plus de technologies d'accs que la technologie GAN qui ne permet pour l'instant que d'effectuer les scnarios : IEEE 802.11 ou Bluetooth GSM/GPRS. Les scnarios du 802.21 sont : IEEE 802.3, 802.11x, 802.16, 802.22, 3GPP, 3GPP2 idem - Les terminaux qui implanteront IEEE 802.21 seront multi-radio et pas seulement "bimode". - Le standard IEEE 802.21 ne normalise pas l'excution du handover mais laide la dtection, l'initialisation et la prise de dcision alors que GAN normalise les changes pour effectuer le handover. - La technologie GAN ne permet pas de choisir si la connexion sans licence est meilleure ou non. En effet, ds la dtection d'un rseau sans licence, le standard oblige le handover sous certaines conditions de qualit, mais ne permet pas de prendre en compte le besoin des applications lors de la prise de dcision du handover. Le standard IEEE 802.21 permettra d'avoir ce choix d'effectuer ou non un handover. - Le standard IEEE 802.21 doit effectuer des amendements auprs des autres standards IEEE 802 et des groupes 3GPP/GPP2 afin que la normalisation de nouveaux points daccs au service SAPs ou de nouvelles primitives soit faite. Sans cela, IEEE 802.21 ne sera pas viable. Nous considrons dans la suite de la thse que les solutions sont fondes sur IEEE 802.21.

41

6.7. Intgration entre les rseaux terrestres et le systme de satellite

Certains travaux de recherche visent amliorer les rseaux satellites sans intgration avec les rseaux terrestres. Dans un contexte satellite, les auteurs dans [44] proposent et valuent un mcanisme de handover tolr pour les systmes satellites orbite basse LEO (Low Earth Orbit) appels : rservation dynamique de canal. L'algorithme propos profite de la topologie dterministe de ce type de systme afin d'augmenter l'utilisation de canal et rduire les deux probabilits de blocage et de terminaison force. Nanmoins, ce travail ne sintresse pas valuer la performance de l'intgration entre le rseau terrestre et le systme de satellite. Par ailleurs, nous nous intressons dans le cadre de notre thse aux travaux dintgration entre le rseau terrestre tel que le rseau WiMAX fond sur IEEE 802.21 MIH et le rseau satellite tel que DVB-RCS. En fait, il existe relativement peu des travaux sur ce thme. Les solutions prsentes aujourdhui, afin dintgrer un segment satellite dans un rseau WiMAX, sont : des solutions architecturelles sans tenir compte de la performance [45] [46], une dfinition dun schma dun handover sans couture dans le cadre dune application prcise, et un solution qui repose sur lintgration dune couche MIH dans un systme satellite. Le but est deffectuer un handover fond sur IEEE 802.21 MIH, un handover IP rapide pour une application prcise en rduisant la latence et la dgradation du dbit, etc. Nous allons maintenant rsumer les diffrents travaux dans ce cadre. Comme nous allons le dcrire dans le chapitre suivant nous avons propos dans [45] une architecture pour l'intgration entre le rseau WiMAX et le rseau satellite DVB-RCS. L'architecture dfinie repose sur le modle IEEE 802.21 MIH comme intgration entre un systme satellite et un rseau terrestre. Deux scnarios avec une procdure de handover WiMAX/DVB-RCS ont t considrs. Une autre solution architecturelle d'une telle intgration a t galement propose dans [46]. La performance d'une telle intgration na pas t value dans ces travaux. Dans [47] et [48] les auteurs proposent un schma dun handover IP rapide entre le rseau sans fil terrestre WLAN et le systme satellite GEO (Geostationary Earth Orbit) pour une application de trains grande vitesse. Daprs les auteurs, un problme majeur dans les rseaux satellites est que les antennes des trains ne reoivent pas bien les signaux satellites. Le problme est que la dure de coupure entre la couche liaison et la couche rseau est considrable dans les rseaux sans fil terrestres. Les auteurs proposent alors dy faire face en amliorant le handover IP dans les rseaux sans fil terrestres. Le schma, que ces chercheurs ont dj propos dans [47], a bien rduit la latence de handover mais il y avait une dgradation remarquable du dbit TCP due laugmentation du RTT (Round Trip Time) cause de la mobilit de routeur avec un dlai de propagation. Pour cela, les auteurs dveloppent les performances dans [48] en proposant un algorithme de proxy (Performance Enhancing Proxy (PEP)). Cet algorithme empche la dgradation de performance (taux derreur, latence, bande passante) des liens satellites TCP. Par ailleurs, dans [49], les auteurs proposent un modle de rfrence qui intgre les couches basses du systme satellite dans IEEE 802.21 MIH. Le modle permet aux couches hautes du systme satellite denvoyer des requtes et de recevoir des informations des couches basses via la fonction MIH (MIHF). Par consquent, la fonction MIH peut fournir les informations du niveau liaison des diffrents rseaux terrestres et les technologies daccs satellites aux niveaux plus levs facilitant loptimisation de la procdure de

42 handover. Le modle de linterface satellite utilise est fond sur larchitecture IP du rseau satellite dfinie par lETSI (European Telecommunications Standards Institute). Comme larchitecture du groupe BSM ESTI (Broadband Satellite Multimedia Working Group) ne propose pas de handovers verticaux dans un environnement htrogne, les auteurs ont aussi propos des nouvelles primitives qui peuvent tre utilises pour changer des informations par le point daccs satellite SI-SAP (Satellite-Independent Service Access Point (Figure 24 et Figure 25)) (entre la couche MIHF et les couches basses de linterface satellite). Cependant, lvaluation de performance dune telle proposition nest pas encore faite.

Figure 24 : Modle de rfrence SI-SAP propos [49]

En tout cas, nous navons pas vu de schma dun handover WiMAX IEEE 802.21/systme satellite DVB-RCS fond sur la rservation de ressource comme solution dintgration entre ces deux systmes dune part et afin damliorer les performances (handover sans couture, QoS, etc.) dautre part. Ces deux systmes sont en ralit largement htrognes. Cela a conduit les chercheurs commencer par lintgration des rseaux terrestres car une telle intgration est plus facile mettre en uvre. Cest ce problme que nous nous attaquerons dans les chapitres suivants.

Figure 25 : Modle de rfrence MIH pour le systme satellite [49]

43

6.8. Conclusion
Dans ce chapitre, nous avons prsent les architectures du rseau WiMAX et du systme satellite DVB-RCS puis une synthse des travaux de recherche sur les handovers. Plusieurs solutions de handover ont t prsentes dans la littrature au niveau des diffrentes couches rseaux. Nous avons dautre part list les diffrentes solutions pour linterconnexion des rseaux sans fil. Les deux premires solutions (GAN et FMIP6) sont spcifies pour linterconnexion entre les rseaux sans fil terrestres (3G et WLAN) des niveaux diffrents. La solution FMIP6 permet dailleurs un handover IP avec mobilit. La troisime solution est le standard IEEE 802.21 qui est plus large et qui prend en compte la majorit des rseaux sans fil (3G, WLAN, WiMAX, etc.). Elle englobe en particulier un des plus intressants rseaux sans fil terrestres : WiMAX IEEE 802.16. Ce rseau possde une large couverture, permet la mobilit et laccs IP et une bande passante capable de combler les besoins des utilisateurs. Nous pensons quune intgration entre un rseau WiMAX et un systme satellite DVB-RCS va tre une solution intressante pour la nouvelle gnration (4G). Nous allons prsenter dans les chapitres suivants notre travail dans ce cadre.

44

CHAPITRE II CONVERGENCE DES RESEAUX SANS FIL TERRESTRES ET LE SYSTEME SATELLITE

1.

Introduction

Le prolongement de la couverture des rseaux d'accs terrestres couvre un des objectifs de la 4G [50]. Une telle volution peut tre mene de diverses manires, mais la tendance est plus l'utilisation du rseau d'accs adapt au contexte (gographique, mobilit...) de l'utilisateur qu' la dfinition d'une norme rpondant un seul besoin. Les systmes satellitaires DVB-RCS fournissent quant eux une liaison montante partage entre plusieurs terminaux utilisateurs. Ces systmes sont conus spcifiquement pour un environnement satellite. Dans un tel contexte, lestimation de la couverture des rseaux daccs sans fil par un systme satellite est une solution optimale. Les techniques de handover (par exemple rsultant des travaux du groupe IEEE) peuvent permettre dobtenir la convergence exige. Le groupe IEEE 802.21 a propos une solution plus gnrique pour cette intgration couvrant la 4me gnration des rseaux sans fil : le modle de rfrence MIH. Plusieurs mcanismes ont t proposs pour les rseaux terrestres. Dans ce chapitre, nous avons l'intention dtendre ces solutions un systme satellite fond sur la pile protocolaire DVBS/RCS. Nous montrons qu'une volution du modle de rfrence MIH, tenant compte du systme satellite DVB-RCS, pourrait tre mise en place pour intgrer un rseau terrestre sans fil (fond sur le rseau WiMAX par exemple) et un systme satellite. Nous dfinissons plusieurs scnarios fonds sur des architectures MIH. Nous montrons que les concepts MIH peuvent tre mis en application. Dans ce chapitre, nous dfinissons une architecture qui tient compte des fonctions MIH. Par consquent, Nous montrons plusieurs mcanismes afin d'adapter DVB-RCS MIH. Nous rappelons que le principe de lIEEE 802.21 est de proposer aux autres groupes de standardisation de mettre en place des amendement afin quils deviennent compatibles avec MIH. Nous proposons une procdure de handover vertical entre un rseau terrestre (WiMAX) et le systme satellite GEO DVB-RCS tenant compte des services proposs par le groupe IEEE 802.21. Nous supposons que les utilisateurs ont la capacit de communiquer avec ces deux rseaux, et que la passerelle vers le satellite utilise la norme DVB-RCS et propose les services MIH.

2.

Handover dans un contexte satellite

Nous allons tout dabord tcher de dfinir un certain nombre de scnarios afin de mettre en uvre un handover vertical. Le mcanisme gnral de handover impose une fermeture de lensemble des connexions daccs et donc des flux rseaux usagers lors du changement de station de base. Cette contrainte semble incompatible avec lun des objectifs principaux de la 4G, savoir la mobilit sans couture au travers de rseaux htrognes. Cependant, les deux types de handover optionnels (MDHO et FBSS) dfinis dans le standard imposent un certains nombre de contraintes, notamment au niveau de la synchronisation, dont nous dtaillerons les impacts dans les sections suivantes.

48

2.1. Handover terrestre vers satellite

Ce handover recouvre en premier lieu lextension de couverture (Figure 26), cest-dire le passage dune station de base WiMAX vers une gateway en raison dun niveau dattnuation important de la seule station de base terrestre disponible. Le handover est alors effectu afin de transfrer le terminal mobile vers le systme satellite. En outre, ce type de handover peut galement tre envisag pour rsoudre des contraintes de routage ou de charge sur le rseau terrestre.

Association 1 Association 2

BS

Terminal

Gateway/NCC

Figure 26 : Handover terrestre vers satellite [50]

2.2. Handover satellite vers terrestre

Ce handover (Figure 27) peut tre dclench par un terminal mobile, pris en charge par le systme satellite, ds la rception de lannonce dune station de base terrestre. Cela sapparente du smart routing, o le type daccs est choisi en fonction de critres de performances. Ce scnario est prfrable pour les utilisateurs temps rel dans la mesure o les utilisateurs dapplications temps rel profitent de la baisse du dlai une fois quils sont pris par la station de base du rseau terrestre.

Association 2

Association 1

BS

Terminal

Gateway/NCC

Figure 27 : Handover satellite vers terrestre [50]

49

2.3. Handover satellite vers satellite

Ce type de handover (Figure 28) est particulier et nest applicable que dans un cas multispot. Ce type de scnario nimplique pas de handover proprement parler, puisque la gateway laquelle est rattach le nud mobile reste la mme. Seul le spot satellite est chang car le terminal sest dplac vers un autre spot ou que le satellite est remplac par un autre de mme type.

Association 2

Association 1

Terminal

Gateway/NCC

Figure 28 : Handover satellite vers satellite [50]

3.

Cas particuliers

3.1. Cas dun handover incluant une fonction de backhauling WiMAX sur le segment satellite
Le cas du handover (Figure 29) entre dune part dans une zone couverte par une station de base WiMAX raccorde au backbone et dautre part dans une zone couverte par une station de base WiMAX relie au satellite prenant en charge le backhauling vers le backbone est fonctionnellement quivalent au cas du handover terrestre classique.

50

BS1 Association 1

Association 2

BS2

Backbone IP

Figure 29 : Cas du backhauling WiMAX [50]

Nanmoins, la communication entre les stations de base tant retarde dau moins un bond satellite, lensemble des contraintes sur les dures de handover cites prcdemment sont valides. Le principal intrt de cette approche est de diminuer les contraintes sur les parties rception et surtout mission du nud mobile. Cette approche permet en outre duniformiser la gestion du rseau et damliorer les possibilits de dploiement des stations de base dans des zones difficilement accessibles ou tout du moins difficilement interconnectables avec un backbone sol. Linconvnient de cette technique est de ncessiter un maillage important afin doffrir une couverture globale. Cela a aussi comme corollaire de placer le satellite dans une position dfensive o il risque dtre supplant par une infrastructure 100% sol.

3.2. Cas dun handover incluant un rpteur sur le segment satellite

Le cas du handover (Figure 30) entre dune part une zone couverte par une station de base WiMAX et dautre part une zone couverte par un rpteur permettant daccder une station de base via un segment satellite est fonctionnellement quivalent au cas du handover avec un accs direct pour la partie satellite, les dlais entre le terminal et le rpteur tant ngligeables par rapport un bond satellite. Le principal intrt de cette approche est de diminuer les contraintes sur les parties rception et surtout mission du nud mobile. Linconvnient de cette technique est de limiter la zone couverte et par consquent dimposer un maillage important dquipements sol.

51

BS2 BS1 Association 1 Association 2 Backbone IP

Figure 30 : Cas du rpteur [50]

4.

Architecture du rseau DVB-RCS

Avant denvisager la mise en uvre de lintgration de la technologie DVB-RCS au sein de MIH, il convient de prciser larchitecture du rseau satellitaire sur laquelle nous nous appuierons. Cette architecture, reprsente dans la Figure 31, est dduite du modle de rfrence dfini dans EN 301 790 [27], que nous simplifions quelque peu. Lobjet de cette simplification est avant tout de faciliter la suite de la prsentation, mais aussi pour la rendre plus reprsentative des architectures rencontres aujourdhui. Nous retenons pour notre architecture les hypothses suivantes : Le rseau satellitaire DVB-RCS nest compos que dun satellite gostationnaire ; Le satellite est de nature transparente vis--vis du trafic vhicul, et offre une couverture multi-faisceaux. Cette technique, frquemment dploye aujourdhui, permet damliorer la qualit des liaisons et la capacit globale du systme ; Le systme satellite ne permet pas les connexions mailles (mesh) et donc, des communications directes entre les terminaux ; Une seule passerelle prend en charge lensemble des terminaux satellite du systme ; La passerelle met sur la liaison descente DVB-S/S2 et reoit sur la liaison montante DVB-RCS ; La passerelle du systme intgre toutes les fonctions de contrle et de gestion du rseau satellite. Elle est notamment responsable de lallocation des ressources (attribution des schmas de modulation/codage dynamiques aux diffrentes porteuses). Elle est aussi charge de gnrer les tables de signalisation et de les multiplexer avec le reste du trafic mis. Le fournisseur de service interactif ISP (Interactive Service Provider) et le fournisseur de service d'mission BSP (Broadcast Service Provider) dfinis par DVB-RCS sont assimils une mme entit que nous appelons fournisseur de service d'accs ASP (Access Service Provider).

52

LAN

RCSTs
WAN

ASP Internet Passerelle

Figure 31 : Architecture propose de rseau DVB-RCS [50]

5.

Modle de rfrence du rseau et les scnarios proposs

Le groupe IEEE 802.21 a propos un scnario du modle de rfrence comme le montre la Figure 32. Cependant, nous proposons galement plusieurs scnarios pour grer l'intgration entre les rseaux terrestres et un systme satellite [45]. L'interoprabilit et l'intgration entre les rseaux terrestres et satellites impliquent une grande diversit de situations qu'il est impossible de traiter exhaustivement. Nous avons choisi de limiter l'tude l'intgration d'un rseau dune seule passerelle DVB-RCS avec un rseau WiMAX puisque la technologie WiMAX semble proposer de bonnes caractristiques en termes de performance l'utilisateur (dbits daccs, zones de couverture tendues, etc.), et de plus cette technologie semble se dvelopper rapidement. ce stade, nous pouvons proposer deux scnarios (Figure 32). Ces scnarios sont fonds sur le modle de rfrence propos par IEEE 802.21 : Scnario 1 : le terminal mobile (MT : Mobile Terminal) a deux interfaces : une interface DVB-S2/RCS et une interface WiMAX. Quand il est situ prs d'une station de base WiMAX, il choisit ce rseau prfrentiellement. Ce scnario pourrait par exemple intgrer les terminaux nomades simples ou bien mobiles dutilisation collective, plutt que de petits quipements portables, puisque cela suppose que le terminal soit quip d'une antenne encombrante. Scnario 2 : le terminal mobile a une seule interface WiMAX, mais peut avoir plusieurs points daccs WiMAX selon sa position. Le handover sera donc de type WiMAX 1/WiMAX 2. La connexion DVB-S2/RCS interviendra ici dans le rseau de l'oprateur par une des deux stations de base WiMAX (cas appel backhauling).

53 En tant que tel, le deuxime scnario ne permet pas un rseau daccs direct entre le terminal mobile et le systme satellite DVB-RCS ; il n'affectera pas la fonctionnalit MIH. En consquence, dans la suite, nous nous concentrons sur le scnario 1.

V-AAA Information Database Visited Core

WLAN

Scenario 1 Route 1 Route 2 MT

SAL
Information server

Visited Core

WiMAX 1

SAL V-AAA
Home Core Network

WiMAX 2
Wireline Connection 803.3 Direct or through a tunnel

Satellite

H-AAA

Tunnel

HA

Internet

Visited Core

Scenario 2 Route 1 Route 2

CN V-AAA

Gateway

Figure 32 : Modle de rfrence IEEE 802.21 et scnarios proposs

6.

Proposition darchitecture satellitaire hybride base de WiMAX, DVB-RCS et IEEE 802.21

La porte de l'IEEE 802.21 est de fournir une couche intelligente (2.5) et dautres informations aux couches suprieures pour optimiser le handover entre rseaux htrognes. Lintrt est de donner la possibilit aux nuds mobiles deffectuer un handover entre rseaux diffrents. En fait, la procdure de handover repose sur des mesures et des dclencheurs fournis par les couches liaisons de donnes du terminal. Ces mesures peuvent inclure : la qualit du signal, les diffrences de temps de la synchronisation, les taux derreur de transmission, etc. Ces mtriques peuvent tre utilises dans la procdure de handover afin de prendre la dcision de handover. Le handover peut se produire dans les cas suivants : un changement des conditions du lien ; un manque de couverture radio (mouvement du terminal ou sil existe un obstacle, etc.) ; le choix dun rseau qui rponde mieux aux besoins dutilisateur (par exemple : canal plus haut dbit) (slection de meilleur rseau). Maintenant, dveloppons l'architecture propose. Dans notre approche nous nous

54 concentrons d'abord sur le modle de rfrence MIH avant de dtailler les adoptions proposes.

6.1. Composants fonctionnels IEEE 802.21

Dans la Figure 33, nous reprenons la pile du modle de rfrence MIH propos par le groupe IEEE 802.21, les principaux services et la localisation de MIH. Nous voyons les commandes (MICS), les services d'information (MIIS) et les vnements (MIES) qui peuvent se produire entre les diffrentes couches. Par ailleurs, nous nous intressons aussi au rseau satellitaire DVB-RCS. Nous allons tenter dintgrer ce rseau ct des rseaux sans fil mis en place dans le modle gnral du groupe IEEE 802.21.

SIP

MIPv4

MIPv6

HIP

Upper Layers (L3 and above)

MIH Commands Information Service

MIH Events

MIH Function
Link Events Link Commands Information Service

802.3

802.11

802.16

3GPP

3GPP2

DVB-RCS

Lower Layers (L2and below)

Figure 33 : Services et localisation de MIH [29]

6.2. Modle de rfrence MIH pour des rseaux d'accs

La Figure 34 prsente le modle de rfrence de chaque rseau considr dans le draft IEEE 802.21. Nous essayons galement d'intgrer dans ce modle un utilisateur qui prend en charge le systme de satellite DVB-RCS. Nous expliquons les dtails de MIH pour un utilisateur DVB-RCS dans le paragraphe suivant.

55

Figure 34 : Modle de rfrence gnral et scnario propos

6.2.1. Modle MIH pour lutilisateur DVB-RCS En considrant les recommandations IEEE 802.21 du draft faites sur les modles de rfrence pour IEEE 802.11, 802.16 et pour les normes 3GPP, nous pouvons proposer un modle de rfrence MIH dans un contexte DVB-RCS. Le modle suivant concerne un terminal mobile. En effet, limplantation de MIH dans le contexte satellite n'a pas besoin d'tre faite sur les satellites eux-mmes. Cela signifie que l'initiative du handover sera la charge du terminal (Figure 35). MIH_DVB_RCS_SAP, MIH_MGMT_SAP et MIH_SAP sont trois points d'accs au service dfinis afin de vhiculer les primitives de service du MIH IEEE 802.21 (service d'vnement, service de commande et services d'information).
Couches suprieures
3

MIH

MPE MPEG2-TS

AAL-5 ATM

DVB-RCS

Figure 35 : Modle de rfrence de lutilisateur DVB-RCS

56 6.2.2. Point daccs au service MIH_DVB_RCS_SAP Ce point d'accs au service dfinit l'interface entre la fonction MIH et la couche DVB-RCS. Cette interface est principalement utilise pour les transferts de donnes (MSDUs : MAC Data Service Unit) entre entits distantes. 6.2.3. Point daccs au service MIH_MGMT_SAP Ce point daccs au service est cens dfinir l'interface entre la fonction MIH et le plan de gestion des divers rseaux. Dans notre cas, le plan de gestion n'existe pas en tant que tel dans l'architecture protocolaire DVB-RCS. Il faudrait ainsi dfinir les primitives de gestion qui seront utilises pour l'aide la slection du rseau, linitiation et l'excution du handover. Le MIH_MGMT_SAP dfinit donc des primitives pour les services MIES, MICS et MIIS. 6.2.4. Point daccs au service MIH_SAP Ce point daccs au service dfinit l'interface entre la fonction MIH et le protocole de gestion de mobilit de niveau trois (L3MP) ou une fonction de handover qui est situe dans des couches suprieures ou encore une couche suprieure de transport. Cette interface est une interface locale et doit tre prsente dans tous les modles de rfrence. 6.2.5. Transport des messages MIH Pour le niveau transport des messages impliquant deux entits distantes MIHF (le contrle de lien distant, le contrle distance de MIH, lvnement de lien distant et lvnement distance MIH), nous sommes alors devant l'alternative suivante. La premire solution considrerait MIH comme un utilisateur du protocole transport par IP, tandis que dans la seconde, le MIH serait assimil un protocole de gestion de rseau, et directement ou indirectement transport ainsi par le niveau 2 (MPEG-2 TS ou ATM). Cette question du transport des messages MIH a t dj souleve dans le groupe IEEE 802.21, d'une manire lgrement plus spcifique pour les rseaux IEEE 802.x. Les arguments suggrs pour le transport des messages par la couche IP (directement ou par UDP) sont l'indpendance de la solution vis vis des technologies du niveau sous-jacent, le service et la flexibilit de l'tablissement, et la plus grande simplicit de limplantation si MIHF est localis dans l'quipement du coeur du rseau et non dans la station de base. Au contraire, le transport par la couche MAC pourrait tre une solution plus rapide installer (dans rseaux IEEE 802.x, grce lidentifiant Ethertype) et pourrait tre rendu facilement fiable. On peut ajouter que cette dernire solution est galement plus efficace du point de vue de l'encapsulation. Afin de tenir compte d'un composant DVB-RCS par MIH, la solution du transport par IP semble clairement la plus adapte. D'ailleurs l'introduction d'une nouvelle indication du niveau 2 dans des rseaux DVB-RCS exige l'utilisation d'un nouveau format ou d'une nouvelle table, qui implique une volution particulirement peu recommande de la norme. En outre, le choix du transport par IP converge avec les prfrences du groupe IEEE 802.21 quant lintgration d'autres rseaux que IEEE 802.x (par exemple rseaux 3GPP) pour lesquels des adaptations plutt lourdes sont ncessaires.

57 Quelle que soit la solution adopte (les deux sont possibles dans l'architecture MIH) le trafic gnr par MIH entrera en concurrence avec le reste du trafic, utilisateur ou non, sur le segment satellite. Il faudra faire attention que le systme fournisse un niveau de QoS adapt. Une tape prliminaire de l'analyse pourrait tre effectue, en tenant compte des contraintes du systme : dlai, limitation possible des ressources en cas dlvation de la charge du rseau satellite, et dgradations de la qualit du signal quand le terminal approche les limites de la couverture des spots. 6.2.6. Modle de rfrence MIH pour les stations mobiles avec les diffrentes piles protocolaires La Figure 36 prsente le modle de rfrence pour les stations mobiles avec les diffrentes piles protocolaires. Cependant, nous sommes galement intresss l'intgration avec les systmes satellites. Dans ce but, nous proposons galement un modle d'un utilisateur DVB-RCS avec trois points d'accs au service (Figure 35) afin de vhiculer les primitives des services IEEE 802.21 (vnements, commande et information).

Figure 36 : Modle de rfrence MIH pour les stations mobiles avec les piles protocolaires [29] [51]

7.

Procdure de handover WiMAX/DVB-RCS

Le scnario montr dans la Figure 37 et la Figure 38 couvre tous les services proposs par le groupe IEEE 802.21. Le service MIIS est utilis pour dcouvrir la prsence de nouveaux rseaux. Nous expliquons les tapes indiques dans ces figures tout en essayant deffectuer un handover entre un rseau terrestre (WiMAX) et un systme de satellite DVB-RCS. Cela signifie que nous supposons que la passerelle DVB-RCS prend en charge les services MIH. Les tapes suivantes sont dveloppes en se rfrant [51] [52] :

58 1. Considrons un terminal mobile situ dans un rseau terrestre, tel que WiMAX, et non reli au rseau DVB-RCS.
Mobile Terminal
L3 Protocol MIP MIH MAC 1 MAC 2

Entity

Network WiMAX
MAC MIH

Information Server Old AR/FA With MIHF MAC MIH

Gateway _ -RCS DVB

New AR/FA With MIHF Home Agent

Layer

1.

Steady state connection between MT and Network WiMAX Obtain Neighbor Reports and Network Information
MIH_Info.Request Information Request MIH_Info.Indication

2.
MIH_Info.Confirm

Information Response MIH_Info.Response Query List of Available Networks Response List of Available Networks

3.

Query More Info on DVB-RCS gateways Response Info on DVB-RCS gateways Link Detected Handover Evaluation & Link Selection Link Going Down

4.

5.

IP Information Request

6.
IP Information Response

7.
CoA Generation

Method 1

Figure 37-a : Procdure de handover WiMAX/DVB-RCS (tapes 1 7)

2. Cette tape montre le flux de base afin de rechercher les informations sur les rseaux voisins utilisant le service d'information MIIS. 3. Le terminal peut d'abord rechercher des informations sur le systme satellite (le ou les satellites (passerelles) disponibles) (par exemple leur nombre), et peut alors rechercher des dtails sur les rseaux choisis (ou sur seulement un satellite (passerelle)). De tels dtails peuvent inclure les informations telles que des adresses MAC des diffrentes passerelles, des paramtres de la couche liaison pour tablir des connexions ventuelles, des services disponibles, etc. Selon la mobilit de terminal et la couverture de rseau, le terminal peut continuer dcouvrir des informations sur de nouveaux rseaux. 4. Une fois que les informations sur un nouveau rseau (systme satellite DVB-RCS) sont disponibles, le terminal peut recevoir le flux de la liaison montante et faire l'valuation de handover et la slection de lien en utilisant des politiques spcifiques

59 lutilisateur et les proprits de diffrents rseaux satellites disponibles. Nous supposons ici que la qualit du signal reu (de la liaison montante) est comparable celle reue par la passerelle sur la liaison descendante de sorte que l'valuation soit valide. Si cette hypothse n'est pas vrifie, l'valuation du handover ne peut pas tre mise en uvre jusqu' ce que l'utilisateur soit connect au systme DVB-RCS, afin de permettre la passerelle d'envoyer au terminal une mesure sur le canal de retour. 5. Si la qualit du signal reu baisse, la couche liaison (du terminal) peut anticiper le handover et dclencher le service d'vnement Link_Going_Down sur les deux entits MIHs (le MIH du terminal mobile (local) et celui du rseau WiMAX ( distance)). Dans le cas de lvnement (Remote MIH Link Going Down event), ladresse MAC de la passerelle peut tre incluse soit lors de l'valuation du handover soit au cours de la procdure de slection de lien. 6. Le MIH du rseau WiMAX tient compte de ladresse IP de la passerelle que le terminal pourrait utiliser. 7. La rponse la demande, permettant au terminal d'obtenir sa nouvelle adresse CoA, peut tre excute de deux manires diffrentes. Dans le premier cas, le routeur d'accs (Access Router : AR) de la passerelle DVB-RCS rpond directement au terminal (mcanisme similaire lauto- configuration IPv6). Dans le deuxime cas, le routeur daccs de la passerelle DVB-RCS communique avec le routeur daccs associ au rseau WiMAX, qui indique au terminal mobile son CoA. 8. Une fois que les paramtres de la couche liaison ont t identifis, le terminal peut sattacher un nouveau lien en utilisant la procdure de logon du DVB-RCS. Une fois que toutes les tapes d'attachement de lien sont accomplies, et une fois que le lien est prt pour envoyer les paquets de niveau trois, un vnement de dclenchement (Link-Up) peut tre envoy la fonction MIH sur le lien local et distance. 9. Une fois que le lien a t convenablement install, la fonction MIH peut rellement procder au handover. 10. Le protocole de niveau suprieur (MIP) (nous supposons ici que le systme satellite inclut un protocole MIPv4 ou MIPv6) peut maintenant se prparer accomplir le handover au travers de lenregistrement auprs du HA. 11. MIP envoie et reoit la demande d'enregistrement (MIPv4)/ la mise jour et la rponse denregistrement et la rponse denregistrement (MIPv4)/ lacquittement denregistrement (MIPv6) en utilisant le CoA qui est reli au lien ancien. 12. Le terminal peut maintenant arrter lutilisation de lancien lien (WiMAX), qui peut avoir comme consquence la gnration de l'vnement Link-Down qui sera livr la fonction MIH sur le terminal.

60
Entity Mobile Terminal
L3 Protocol MIP MIH MAC 1 MAC 2

Network WiMAX
MAC MIH

Information Server Old AR/FA With MIHF MAC MIH

Gateway DVB-RCS
New AR/FA With MIHF Home Agent

Layer

Agent Advertisement Tunneling De-tunneling

7.
CoA Generation

Proxy Agent/ Router Advertisement

Method 2

Link Connect
8.

Log-on request on CSC burst + Authentication [ Log-on & SYNC OK ]

Link Up
9.
Handover Commit

Initiate Handover and Complete MIP Signaling. 10.

Registration Request / Binding Update

11.

Registration Reply / Binding Acknowledge

Disconnect old link

12.

Link Down

Figure 38-b : Procdure de handover WiMAX/DVB-RCS (tapes 7-12)

8.

Conclusion

Dans ce chapitre, nous avons dfini une architecture qui tient compte du modle de rfrence MIH comme intgration entre un systme satellite et des rseaux terrestres. Deux scnarios ont t considrs. Une procdure de handover entre un rseau terrestre (WiMAX) et le systme satellite de DVB-RCS GEO est dcrite. Les mcanismes du handover sont essentiels dans un scnario 4G, o les utilisateurs mobiles se dplacent d'un rseau d'accs l'autre. L'utilisation d'un segment satellite comme extension de couverture est particulirement intressante dans un tel contexte 4G. Nous avons montr la possibilit fonctionnelle de l'intgration des rseaux satellites dans une infrastructure 4G. Dans la suite de la thse, nous allons nous intresser la prise en compte de la QoS lors des handovers. Tour tour, nous nous intressons en cas WiMAX seul pris lintgration dun segment satellite dans ce rseau WiMAX.

CHAPITRE III PERFORMANCE DES RESEAUX WIMAX EN UTILISANT HANDOVER HORIZONTAL AVEC UN MECANISME DE RESERVATION

Les futurs rseaux sans fil vont tre caractriss par des dbits variables et levs, la prise en compte de la QoS et une mobilit sans couture. Dans ce chapitre, nous considrons un modle de mobilit pour un utilisateur de rseau WiMAX en introduisant un handover horizontal avec un mcanisme de rservation du canal. Dans ce chapitre, nous ne faisons pas la diffrence entre les utilisateurs, le concept du canal reprsente un dbit fixe demand par un utilisateur (correspondant par exemple classe de service UGS (Unsolicited Grant Service) dans le rseau WiMAX)). Nous enrichirons ces modles de QoS dans le chapitre 5 en considrant plusieurs classes de service. Nous prenons en compte plusieurs scnarios afin deffectuer la rservation. Nous valuons les performances du modle propos. Les rsultats montrent, par le biais de simulation (QNAP2), que le mcanisme de rservation amliore le handover horizontal sans dgrader la performance du systme.

1.

Introduction

Le handover sans couture est l'une des caractristiques importantes dans les rseaux de future gnration. La dfinition dune procdure de handover adapte doit tre aborde. En outre, nous pouvons esprer amliorer l'opration de handover (HO) par un mcanisme de rservation [53]. Dans ce chapitre, nous adoptons un mcanisme de rservation du canal (CR : Channel Reservation) dans le rseau WiMAX et l'utilisons pour amliorer le handover horizontal. En fait, la rservation peut tre effectue de plusieurs manires. Dans une approche cooprative, nous considrons un schma de rservation de canal excut par des nuds voisins NNs (Neighbor Nodes) tenant compte de la mobilit. Dans une approche individuelle, la rservation est effectue par les stations de base WiMAX. Enfin, nous considrons une troisime approche qui unifie ces deux solutions. En conclusion, ces approches sont compares afin de choisir la meilleure politique de rservation. Ce chapitre est organis comme suit : la section 2 dcrit le systme considr, la section 3 prsente les diffrentes approches envisageables, et la section 4 analyse la performance du systme. Les auteurs dans [3] se sont intresss au handover sans couture. Ils prsentent un nouveau concept, le Takeover, qui permet un nud voisin de traiter les demandes d'autres nuds mobiles MNs (Mobile Nodes). Les auteurs ont dvelopp un protocole et un fonctionnement de Takeover et les ont appliqus au handover vertical pour des rseaux htrognes de future gnration. Lide dutiliser un nud voisin, qui aide prparer le handover, sera dveloppe dans ce chapitre avec un mcanisme de rservation du canal.

2.

Description du systme

Considrons un rseau WiMAX avec plusieurs cellules appeles (macro-cellules). Dans certains cas, le mode maill (mesh) peut tre suppos. Chaque station de base couvre une cellule. Les nuds mobiles peuvent se dplacer dans toutes les directions. La cellule est divise en trois zones selon la puissance du signal reu par le nud mobile (Figure 39) comme suit : une zone centrale CZ (Central Zone) o la puissance du signal est au-dessus d'un seuil (T1), dans cette zone il na pas de handover ; une zone frontire BZ (Boundary

64

Zone) (la zone qui est prs de la zone de recouvrement) o la puissance du signal est audessus d'un seuil (T2) et infrieure T1, dans cette zone les nuds mobiles peuvent envisager la rservation ; une zone de recouvrement OZ (Overlapping Zone) est une zone o la puissance du signal est infrieure T2, dans cette zone les nuds (nuds voisins) peuvent effectuer le handover horizontal. Notons que pour modliser ces trois zones, on peut utiliser la puissance du signal reu ou un systme de localisation. En outre, nous distinguons deux types d'utilisateurs selon leurs localisations (leur puissance de signal reu). Quand un utilisateur est situ dans la zone de recouvrement, et galement par consquent couvert par la station de base cible, on lappellera nud voisin. Pour excuter la rservation, nous considrons effectivement trois approches.

Puissance du signal Nud voisin (NN) Nud mobile (MN)

MN

CA 2

NN

BS1

BS2

IA CR Phase
T1 T2
CR request

Distance
CR response

MA Handover Preparation Process

Figure 39 : Puissance du signal dune cellule WiMAX

Figure 40 : Messages changs

2.1. Approches proposes

1. Approche Cooprative CA (Cooperative Approach) Cest une approche en mode ad-hoc (Figure 40 et Figure 41). Quand la puissance du signal d'un nud reste plus basse que T1 et plus haute que T2 (par exemple pendant une dure prdfinie D, mais cette ide na pas t retenue par la suite), ce nud est appel : nud mobile (MN). Le nud mobile, qui est en train dentrer dans la zone frontire et se dplace vers la station de base cible, commence le processus de scrutation pour trouver un nud voisin NN. Cette scrutation peut tre ralise laide des protocoles de dcouverte de voisins de 802.16e enrichis par ces informations. Le nud mobile identifie qu'un autre nud est un nud voisin par sa puissance du signal prdfinie et parce que ce nud est couvert par les deux stations de base. Un nud voisin sert rserver un canal dans la station de base cible. Il n'est donc pas un relais par lequel le trafic passe. Dans ce travail, nous supposons qu'un utilisateur a besoin d'un seul canal pour communiquer. En revanche, ce travail peut tre gnralis au cas o les utilisateurs ont besoin d'une quantit donne de ressources pour communiquer. Le nud voisin demande la station de base cible un canal pour chaque nud mobile qui en fera la demande. Si la station de base cible a des canaux disponibles, un message d'acceptation sera envoy de la station de base cible au nud voisin qui relayera vers le nud mobile. La station de base cible commence alors la procdure de prparation de handover pour ce nud mobile. Quand cela est ralis, la

65 station de base cible envoie une confirmation au nud mobile par le nud voisin. Le nud voisin libre ensuite le canal qui a t rserv dans l'ancienne station de base et utilise le canal rserv dans la station de base cible (maintenant station de base de service) une fois que ce dernier est entr dans la zone de recouvrement aprs avoir effectu le handover (ou dans le cas de la fin de son appel). Le canal prcdent peut tre rutilis ainsi par un autre nud mobile. Un cas simple permet la station de base cible de contrler ses canaux sans distinguer les canaux occups pour les demandes de rservation et les canaux rservs par un nud.

2. Approche Individuelle IA (Individual Approach) Cette approche peut correspondre un mode avec infrastructure (Figure 40). Quand la puissance du signal d'un nud mobile reste infrieure T1 et plus grande que T2 pendant une dure prdfinie (D), le nud mobile envoie une demande la station de base de service. Si cette station de base n'est pas surcharge (la charge est infrieure un seuil , dans notre travail, nous considrons =0.95), la station de base de service traite la rservation dun canal dans la station de base cible. La station de base de service entre en contact ainsi avec la station de base cible pour rserver un canal. Considrons dans cette approche que les stations de base peuvent communiquer en mode maill ou en mode avec infrastructure. 3. Approche Mixte MA (Mixed Approach) Ce mode est fond sur les deux approches prcdentes (Figure 40). Le nud mobile a deux choix pour rserver un canal. Si la station de base de service est surcharge (l'approche individuelle ne peut pas tre tablie), le nud mobile commence vrifier la possibilit de rserver l'aide d'un nud voisin (approche cooprative). En fait, nous avons trouv aprs exprimentation par simulation que l'ordre (lapproche cooprative avant ou aprs lapproche individuelle) n'a aucun impact sur les rsultats de performance. La motivation de lapproche cooprative et de lapproche mixte est lorsquun obstacle empcherait le nud mobile de joindre la station de base cible (entranant une puissance du signal faible pendant une dure prdfinie). Remarquons que ces approches de rservation pourraient aussi servir pour transfrer les donnes.

2.2. Quand initialisons-nous le handover ?

Un nud voisin, situ dans la zone de recouvrement et de dplace vers la station de base cible, peut initialiser un handover. Cela signifie que quand la puissance du signal d'un nud passe sous le seuil prdfini T2, la station de base cible doit galement avoir un dbit disponible pour traiter les demandes de handover.

3.

Analyse du pire cas de rservation et rservation de ressources

Nous avons effectivement suppos que quand un nud mobile a une puissance du

3.1. Pire cas de rservation

66 signal entre T1 et T2 pendant une dure D, il est situ dans la zone frontire. Dans ce cas-ci nous commenons le processus de rservation selon l'approche cooprative, individuelle ou mixte (bien videment lorsque la station de base cible a un dbit disponible). En ce qui concerne le pire cas de rservation, nous distinguons deux cas : dans le premier cas, nous supposons que notre systme est quip dun systme de localisation GPS. Dans ce cas-ci, nous pouvons savoir chaque instant la position d'un nud et par consquent annuler ou non la rservation quand le nud change la localisation (quand le nud quitte la zone frontire et se dplace vers sa station de base de service). Dans le deuxime cas, il n'y a aucun moyen de savoir la position de nud. Nous dfinissons alors le pire cas de rservation comme suit : nous supposons que si le nud mobile a une puissance du signal plus grande que T1 aprs le processus de rservation (sa puissance du signal a t comprise entre T1 et T2 pendant une dure D), c'est que ce nud mobile a chang la direction (il ne se dirige plus vers la station de base cible). Par consquent, la demande de rservation est fige pendant une priode W moins que le mobile entre de nouveau dans la zone frontire.

3.2. Rservation des ressources

Nous allons tudier les performances du systme dans le pire cas de rservation. Ces performances peuvent tre optimises en tenant compte des phnomnes suivants : le changement de direction, la fin dappel avant lexcution du handover (ces deux cas sont pris en compte dans notre travail), et la panne du nud mobile avant lexcution du handover. Lobjectif est dabandonner le plus vite possible la rservation en cours. Plusieurs approches peuvent dsormais tre envisages :

3.2.1. Approches ractives

Extermination : Une approche de suivi est mise en uvre. Le nud mobile maintient toutes les rservations faites. Lorsquil dtecte un changement (direction, fin dappel, cas de panne, prvisible, mobilit, etc.), il demande dannuler ses rservations actives. Un problme potentiel est le risque dinstabilit. En revanche, cela pourrait permettre de rduire le trafic de signalisation. Rincarnation : On met en uvre une technique de numro de squence. En fait, un numro dpoque correspondant lpoque des tentatives. Afin dviter leffet dinstabilit (ping pong), par exemple d aux changements de direction intempestive, la perte des rponses aux requtes du client, le client change dpoque et renvoie une nouvelle requte ce qui permettra la station de base de confirmer ou dannuler les rservation du client.

3.2.2. Approches proactives : Expiration (soft state)

Une technique de dlai de garde est utilise. Le maintient de la rservation est toujours associ une surveillance priodique du client. La station de base arme des dlais de garde. Si le dlai expire, la station de base demande au nud mobile sil est encore

67 oprationnel. Si le nud mobile rpond : on arme un nouveau dlai de garde et on poursuit. Si le nud mobile ne rpond pas, on abandonne la rservation. Par consquent, cette technique permet la fois la surveillance du nud mobile par la station de base et celle de la station de base par le nud mobile. Toutefois, un problme peut se poser. Le nud mobile peut ne plus tre accessible directement par la station de base ou inversement la station de base peut ne plus tre accessible partir du nud mobile (par exemple, en cas de disparition des nuds voisins). Une solution doptimisation, dans ce cas, est dfinie de faon ce que le dlai de garde puisse tre estim en fonction de la position du nud mobile. En revanche, il faudrait prendre en considration la vitesse du nud mobile ( moins que les nuds soient immobiles).

3.2.3. Approches mixtes

Des approches combinant le mcanisme soft state (fond sur le temporisateur) et base dannulation de rservation. Notons que ces trois approches (ractives, proactives et mixtes) doivent tre values en particulier au niveau de la signalisation induite.

4.

Modle de simulation

4.1. Dfinition de la topologie de mobilit du modle propos

Nous avons considr le rseau reprsent sur la Figure 41 et Figure 42. Un utilisateur peut se dplacer dans quatre directions (D1, D2, D3 et D4). Nous considrons un rseau WiMAX compos de deux macro-cellules carres (MaCs) avec un recouvrement. Chaque station de base couvre une macro-cellule. Chaque macro-cellule se compose de trois zones principales : une zone centrale CZ o aucun handover ne peut rapidement se produire et dans cette zone la puissance du signal est leve, une zone frontire en haut UBZ (Up Boundary Zone), une zone frontire en bas DBZ (Down Boundary Zone). Dans ces deux dernires zones la puissance du signal est moyenne et le nud mobile est couvert par une seule station de base (station de base de service). Nous considrons enfin une zone de recouvrement OZ o la puissance du signal est faible et le nud voisin est couvert par deux stations de base (de service et cible). Afin dobtenir des rsultats au bout de dlais raisonnables dans notre modle, nous ne modlisons pas la couche physique et seule la localisation gographique est considre. Par exemple, un utilisateur, situ dans la zone de recouvrement et se dirige vers sa station de base cible, subir un handover. Toutefois, un utilisateur situ dans les zones frontires et qui se dirige vers la station de base cible, peut demander une rservation. Dans l'approche cooprative, nous supposons que l'utilisateur, qui veut initialiser une rservation, a la capacit de scruter les nuds voisins dans une couverture de cinq cents mtres. Pour faciliter la simulation de la procdure de scrutation chaque zone frontire ainsi que la zone de recouvrement a t divise en micro-cellules carres. On pourrait considrer que chaque micro-cellule reprsente en ralit la surface de la porte dun nud. Dans le modle de simulation, nous considrons que l'utilisateur met en uvre la procdure de scrutation dans les trois micro-cellules frontires (Figure 41). Dans l'approche individuelle, nous considrons que la station de base de service ne doit pas tre surcharge (charge infrieure 95%) pour procder la rservation une fois le nud mobile la ncessite.

68 Afin de tenir compte du handover, nous modlisons ainsi que les zones frontires. La zone frontire nest couverte que par une seule station de base. Cependant, la zone de recouvrement modlise le recouvrement entre les macro-cellules. Chaque zone frontire ou zone de recouvrement est reprsente par une bande compose de micro-cellules. En outre, nous supposons que la micro-cellule est carre afin de simplifier le modle de mobilit. En revanche, la zone centrale de chaque macro-cellule a t considre comme une seule grande zone.
Overlapping Zone 2 (OZ2)

..

..

..

..

18

19

20

Up Boundary Zone (UBZ1)

CR BS1 CR request CR
MN

WiMAX macro-cell 1

Central Zone 1 (CZ1)

Down Boundary Zone (DBZ1) NN

HO

Overlapping Zone 1 (OZ1)

Up Boundary Zone 2 (UBZ2)

BS2

WiMAX marco-cell 2
D4

Central Zone 2 (CZ2)

Microcell
D3
Down Boundary Zone 2 (DBZ2)

D1

Overlapping Zone 2 (OZ2)

D2

Figure 41 : Topologie adopte

Figure 42 : Sens potentiels dun mobile

La topologie d'un tel systme est modlise par un rseau de files dattente. Le nombre de serveurs est limit par le nombre de canaux que possde la station de base (capacit de la station de base) qui sont partags entre tous les utilisateurs de macro-cellule. Chaque cellule (macro-cellule) ou micro-cellule est reprsente par une seule file dattente C serveurs (Figure 43). Les clients de rseau sont les connexions actives. Les rservations et le partage entre les micro-cellules restreignent la capacit instantane de chaque file.

69
out
handover/reservation
1

source des clients

handover/reservation cellule/microcellule

Figure 43 : File dattente

Les utilisateurs peuvent se dplacer dans plusieurs sens. Par consquent, il y aura plusieurs transitions entre les diffrentes zones de rseau (Figure 44). Le temps de sjour dans la cellule est suppos suivi une loi exponentielle. Le temps de sjour dans la zone de recouvrement avant deffectuer un handover (TPS1) est uniformment distribu entre 0 et le temps de traverse de la zone de recouvrement. Notons TPS2 est le temps de sjour rsiduel dans cette zone une fois le handover effectu.
UBZ1
1

OZ2
1

s Zone centrale
c

s s
c c c

1 S1

Zones voisines (UBZ2, DBZ2, CZ2)

c s
Dlai

s c

s
c

DBZ1

OZ1

Figure 44 : Rseau de files dattente reprsentant notre modle

Afin de traiter la procdure de handover, nous avons dcompos le temps de sjour dun utilisateur dans la zone de recouvrement en deux parties (Figure 45) : le temps de sjour avant dinitialiser un handover (TPS1) et le temps de sjour aprs avoir effectu un

70 handover (TPS2). De plus, nous avons suppos quun utilisateur, entrant dans la zone de recouvrement, a dj choisi un sens et quil va le garder pendant son sjour dans cette zone.
Aprs HO Temps de sjour 2 Exp(1./TPS2) MN change la BS de service

BS cible

TPS2

HO
Avant HO Temps de sjour 1 Exp(1./TPS1)

BS de service

TPS1

Figure 45 : Microcellule dans la zone de recouvrement

4.2. Processus de handover, rservation et pire cas de rservation

Dans le modle de simulation adopt, nous connaissons la localisation et la direction du nud mobile. Le processus de rservation est effectu dans les zones frontires. Nous distinguons deux cas selon la politique de rservation. Dans la politique de rservation, ds que lutilisateur entre dans la zone frontire et sil se dirige vers la station de base cible, il fait la rservation. Une fois quil entre dans la zone de recouvrement et sil est toujours dirig vers la station de base cible, la rservation est conserve sinon la rservation est annule. Dans la politique du pire cas de rservation, le nud mobile qui entre dans la zone de recouvrement, qui a dj rserv lentre dans la zone frontire, mais qui ne se dirige plus vers la station de base cible, conserve la rservation. Lintrt est alors dtudier leffet de ce cas, qui est considr comme le pire cas sur les performances de systme. Le processus de handover est toujours initi dans la zone de recouvrement. Le problme avec le mcanisme de pire cas de rservation est que les rservations non utilises restent bloques. Le systme doit finir par se paralyser, il nest probablement pas ergodique en particulier dans lapproche individuelle. Dans lapproche cooprative, la conclusion est plus difficile tirer a priori. En effet, pour quune nouvelle rservation ait lieu, il faut que lon trouve un nud voisin pour leffectuer. La rarfaction du nombre de connexions disponibles se traduira par labsence de candidats pour relayer ces rservations et par consquent, on aura de moins en moins de rservations y compris inutiles. En tout tat de cause, les conclusions que lon pourra tirer de nos simulations sur le pire cas de rservation seront essentiellement du type : en partant dun systme vide et pour une dure simule T, voici le taux de blocage de nouveaux appels ou le taux de refus de handover .

4.3. Paramtres du modle propos

Dtaillons les paramtres de simulation : la capacit de station de base (C) varie de C = 5 45 canaux. Le temps simul est de 10+6sec. Nous choissions des micro-cellules

71 carres pour faciliter le modle de mobilit. Le tableau suivant (Tableau 1) montre les paramtres retenus :
Paramtres
Dimensions dune cellule (km x km) Dimensions dune micro-cellule (m2) Dimension de la zone centrale (km x km) Nombre des microcellules dans la zone frontire Vitesse de nud mobile (km/h) Temps de traverse de la zone centrale (s) Temps de traverse de la microcellule (s) Dure dappel (s)

Cas 1
10 x 10 500 x 500 10 x 8 20 36 900 50 150

Cas 2
4x4 500 x 500 4x2 8 36 300 50 150

Tableau 1 : Paramtres de modle

Tmicro et Tcz sont respectivement le temps moyen pour traverser la micro-cellule et le temps moyen pour traverser la zone centrale. La porte de couverture dune station de base WiMAX est considre de 10x10 km2 (cas 1) ou de 4x4 km2 (cas 2) (voir Tableau 1). Si on suppose que la porte dmission/rception dun nud est de 500 m et que la vitesse de dplacement est de 36 km/h, par consquent, le temps moyen de traverse dune microcellule est de 50 s. La dure moyenne dappel est de 150 s soit le temps moyen de traverse de 3 micro-cellules. Dautre part, nous avons suppos que la dure des appels est exponentiellement distribue. Les taux darrives () sont variables de telle sorte que la charge normalise est comprise entre 60% et 100%. En outre, nous supposons que les arrives de nouveaux appels sont uniformment rparties dans lespace. Le taux darrive dans une zone donne sera alors proportionnel sa surface. Enfin, il faudra noter ici que nous avons choisi deux cas (cas 1 et cas 2 (Tableau 1)) pour tudier leffet de la densit des nuds sur les performances. Pour cela, dans le cas 2, nous avons baiss la dimension dune cellule (la puissance dune station de base est faible) en gardant la mme couverture dun nud que dans le cas 1. Ainsi, lorsque nous avons une cellule de 4x4 km2, la zone frontire est reprsente par 8 microcellules.

5.

Analyse de performance

Nous prsentons d'abord les performances du systme avec la procdure classique de handover, puis le handover avec le mcanisme de rservation. Nous considrons les critres de performance suivants : Le taux de blocage des nouveaux appels NCBR (New Call Blocking Rate), le taux de blocage de handover HOBR (Handover Blocking Rate) et le taux de blocage de rservation CRBR (Channel Reservation Blocking Rate). Nous tudions les deux cas : la rservation et le pire cas de rservation. Nous notons quau lieu d'tudier des taux de blocage, nous pourrions aussi tenir compte du taux d'utilisation (doccupation) du canal. Cela nous conduirait aux mmes rsultats.

72

5.1. Mcanisme de handover et rservation de ressources

Nous prsenterons les rsultats pour le cas 1 (la dimension de la macro-cellule est de 10 x 10 km2) lorsque la station de base possde C = 15 canaux. Comme le montre la Figure 46, le taux de blocage des nouveaux appels (en %) augmente en fonction de la charge offerte (Erlang). Il en est de mme pour le taux de blocage de handover. L'approche cooprative n'augmente pas le taux de blocage de handover. Dans la Figure 46, nous comparons le handover sans rservation et celui de l'approche cooprative. Nous remarquons que l'approche cooprative amliore lgrement le taux de blocage de handover et rduit le taux de blocage des nouveaux appels. En outre, le taux de blocage de rservation dans l'approche cooprative (Figure 46) est intressant et presque constant. Les blocages sont dus au fait que les nuds mobiles ne trouvent pas de nuds voisins) (la densit des nuds voisins n'est pas suffisante). En outre, dans le cas 2 (dimension de cellule est de 4x4 km2) si nous fixons le taux darrive des utilisateurs (cela signifie que nous augmentons la densit des utilisateurs et que nous rduisons les dimensions des macrocellules), nous observons que l'approche cooprative devient efficace. Par consquent, l'approche cooprative est principalement fonde sur la densit des utilisateurs puisque cette approche tient compte du nud voisin pour effectuer les rservations. En tout cas, le mcanisme de rservation propos dans l'approche cooprative ne dgrade pas les performances du systme. Autrement dit, nous observons dans la Figure 47 que l'approche individuelle rduit clairement le taux de blocage de handover et mne un taux de blocage de rservation plus faible que celui de l'approche cooprative. Lapproche mixte mne presque aux mmes rsultats que ceux obtenus avec lapproche individuelle puisque l'approche cooprative avec ces paramtres (cest--dire cas 1) n'est pas efficace.

Figure 46 : Taux de blocage avec lapproche cooprative

73 En fait, le mcanisme de rservation conduit de bons rsultats lorsque nous avons peu de canaux. Par consquent, le mcanisme de rservation peut tre plus utile quand le systme est surcharg.

Figure 47 : Taux de blocage avec lapproche individuelle

5.2. Comparaison
Comparons maintenant les trois approches. Nous notons les diffrences suivantes : le mcanisme de rservation n'augmente pas clairement le taux de blocage des nouveaux appels (Figure 48) en comparant au cas sans rservation selon les trois approches. L'approche cooprative mne aux meilleurs rsultats en ce qui concerne le taux de blocage des nouveaux appels car elle n'est pas efficace faible densit. En outre, dans le cas des deux dernires approches, cette augmentation est faible. En fait, quand nous appliquons un mcanisme de rservation cela signifie que nous rservons tt un canal. Dautre part, le mcanisme de rservation rduit le taux de blocage de handover particulirement dans les deux dernires approches (Figure 49). D'ailleurs, l'approche individuelle rduit au minimum le taux de blocage de handover. Par consquent, l'approche cooprative mne au plus mauvais taux de blocage de handover. Ce taux n'est pas trs loign de celui obtenu sans rservation. En ce qui concerne le taux de blocage de rservation, la troisime approche clarifie le taux minimum (voir la Figure 50). L'approche cooprative mne encore au plus mauvais taux de blocage de rservation.

74 Maintenant observons les rsultats dans le pire cas de rservation. En fait, l'approche cooprative conduit au taux minimum (aussi bien que dans le cas de rservation). L'approche cooprative conduit galement au taux de blocage des handovers minimal. A propos du taux de blocage de rservation, l'approche individuelle est la meilleure solution, alors que l'approche cooprative mne au plus mauvais taux. D'ailleurs, nous avons remarqu que le pire cas de rservation montre les plus mauvais rsultats. Cela est d au fait qu'il n'y a pas assez de canaux disponibles dans la station de base cible pour servir les demandes de rservation ou de handover dans la mesure o un utilisateur peut garder sa rservation, ventuellement pour une dure indfiniment mme sil change de direction.

Figure 48 : Comparaison des taux de blocage des nouveaux appels

Nous npiloguerons pas plus avant sur ce pire cas de rservation. Notre objectif tait de montrer quil est ncessaire dimplanter des mcanismes dannulation de rservations implicites ou explicites comme ceux que nous avons prsent dans le paragraphe 3.2.

75

Figure 49 : Comparaison des taux de blocage du handover

Figure 50 : Comparaison des taux de blocage de rservation de canal

76 Finalement, dans la Figure 51, nous prsentons les taux de blocage des handovers en fonction de la capacit de station de base (dans les deux cas : cas 1 (20 microcellules) et cas 2 (8 microcellules)), cette capacit variant de 5 45 canaux (charge normalise est de 80 %). Nous notons que les taux diminuent quand la capacit de la station de base augmente, la charge normalise diminue galement. Dautre part, nous observons que l'approche cooprative est efficace forte densit des utilisateurs (cas de 4x4 km2). L'efficacit du mcanisme de rservation est claire faible capacit (de 10 30 canaux). Les rsultats obtenus avec l'approche individuelle sont clairement proches de ceux de la troisime approche. Cela est d au fait que dans ces deux approches, les stations de base sont utilises comme moyen intermdiaire pour effectuer la rservation. Toutefois, l'approche cooprative dpend de la distribution des nuds voisins. Nous pouvons dire que les performances sont meilleures quand le mcanisme repose sur les stations de base pour rserver un canal plutt que lorsquil dpend des nuds voisins faible densit. Finalement, nous avons fait varier la vitesse du nud mobile de 10 km/h 120 km/h. Cela na pas vraiment chang les rsultats.

Figure 51 : Taux de blocage des handovers en fonction de la capacit de station de base

77

6.

Conclusion

Nous venons dvaluer des mcanismes de rservation du canal pour amliorer les performances de handovers horizontaux dans le cadre de WiMAX. Ce mcanisme rduit le taux de blocage de handover et ne dgrade pas la performance du systme. En revanche, les performances de systme se dgradent si lon nannule pas les rservations non utilises. Nous avons compar trois approches (cooprative, individuelle et mixte). A faible densit dutilisateurs, les meilleurs rsultats de performance sont obtenus quand la rservation est ralise par une station de base plutt que quand les nuds mobiles envoient leurs demandes par un nud voisin. L'efficacit du mcanisme de rservation est remarquable quand il y a un faible nombre de ressources. En outre, l'approche cooprative montre de bons rsultats quand la densit des utilisateurs augmente. Cette densit est lie aux dimensions de systme. Nous allons nous intresser maintenant lintgration de ce modle de rseau WiMAX et dun segment de satellite avec et sans rservation de canal.

78

CHAPITRE IV PERFORMANCE DU RESEAU WIMAX INTEGRE DANS UN SYSTEME SATELLITE DVB - RCS

1.

Introduction

Dans les rseaux de future gnration, l'intgration de rseaux htrognes utilisant diffrentes technologies sera indispensable afin de fournir une couverture globale sans couture. La mobilit et la continuit de service reprsentent des dfis importants pour ces rseaux. Comme not prcdemment, l'intgration d'un segment satellite dans un rseau terrestre (particulirement WiMAX) a plusieurs avantages dans un contexte 4G (vaste couverture, bande passante considrable, etc.). Dans ce chapitre, nous nous concentrons sur des mcanismes de rservation de ressources pour assurer la qualit de service. Nous allons dailleurs reprendre le modle du rseau WiMAX dfini dans le troisime chapitre. Deux mcanismes (mcanisme rseau et mcanisme utilisateur) et deux scnarios sont considrs afin deffectuer cette intgration. Enfin, nous valuons les performances du modle propos.

2.

Coexistence entre le rseau WiMAX et le rseau DVBRCS

L'intgration dun rseau satellite et dun rseau terrestre WiMAX est un problme difficile comme nous lavons montr dans le chapitre 2. L'architecture que nous avons dfinie tient compte du modle de rfrence MIH, propos par le groupe IEEE 802.21, comme base dintgration entre un systme satellite et des rseaux terrestres. Il est maintenant ncessaire d'valuer la performance de cette intgration. Cette valuation porte sur les performances rendues aux utilisateurs. Une tude complmentaire pourrait tre envisage concernant la signalisation. Dans ce chapitre, nous reprenons le modle WiMAX adopt en y ajoutant ensuite un segmente satellite [54]. Nous tudions cette intgration avec et sans mcanisme de rservation de ressources. Ce mcanisme est implant dans le rseau WiMAX, en utilisant les trois approches proposes dans le chapitre trois : cooprative, individuelle et mixte. Nous considrons galement deux scnarios avec deux mcanismes. Les scnarios concernent le dbit des connexions prises en charge successivement par le systme satellitaire et les rseaux WiMAX. En effet, le dbit global et la couverture confrent au rseau WiMAX un dbit global largement suprieur au dbit de la voie de retour satellite exploite en DVB-RCS. Plusieurs solutions sont alors envisageables quand une connexion devra tre transfre d'un systme un autre : - le dbit est identique dans les deux systmes et la dure de connexion aussi. Cest le cas de la majeure partie dapplications courantes ; - le dbit doit tre rduit lors d'un passage en DVB-RCS sans modification de la dure de la connexion. Ce choix rpond aux besoins des applications avec des contraintes temps rel. On supposera dans la suite que lapplication sait sadapter ce contexte ; - le dbit est rduit lors du transfert mais on augmente la dure de la connexion pour permettre l'envoi d'un mme volume d'information. Ce choix pourrait servir les applications best effort ou non temps rel ; ces classes ne mettent pas de contraintes sur le dlai (applications non temps rel). Cest le cas des applications ncessitant le

82 transfert dun volume constant. Dans nos simulations (QNAP2), nous sommes rests dans ce chapitre sur la notion de canal attribu une connexion. Pour matrialiser le changement de dbit, cela se traduira par le fait que les canaux ont un dbit plus faible dans le systme DVB-RCS que dans le rseau WiMAX. Les cas 2 et 3 ont t implants. Remarquons que l'on pourrait interprter le cas 2 exactement comme le cas 1, mais avec comme particularit d'avoir un systme DVB-RCS avec une capacit globale beaucoup plus importante. Ces cas tant tout de mme trs dissemblables, nous n'essayerons pas de les comparer dans l'absolu mais simplement d'valuer nos mcanismes dans ces diffrents cas de figure. Notons enfin que nous reviendrons en dtail dans le cinquime chapitre sur la mise en correspondance entre les classes de service et les paramtres QoS. Nous allons considrer galement deux types des handovers verticaux : down handover (handover descendant) et up handover (handover montant). Le down handover consiste effectuer un transfert des utilisateurs depuis le systme satellite vers le rseau WiMAX. De faon symtrique, un up handover transfre un utilisateur WiMAX vers le systme satellite. Nous rappelons que le modle adopt du rseau WiMAX, prsent dans le chapitre trois, est compos de deux cellules WiMAX. Ces cellules sont couvertes par un satellite gostationnaire (GEO). Les cellules WiMAX sont de nouveau dcoupes en trois zones selon la puissance du signal reu comme dans le chapitre prcdent.

3.

Mcanisme de handover

L'utilisateur WiMAX met en uvre un handover horizontal dans la zone de recouvrement (Figure 54). Si la station de base cible possde des ressources, l'utilisateur effectue le handover horizontal. Sinon, il essaye un handover montant pour rejoindre le systme satellite. En fait, nous distinguons, deux mcanismes de handover. Dans le premier, l'utilisateur neffectue un handover horizontal ou vertical (up ou down) que dans la zone de recouvrement des cellules WiMAX. Cela signifie que lors dun changement de zone de couverture de cellule WiMAX, que lutilisateur soit pris en charge par le rseau WiMAX ou par le systme DVB-RCS, il tentera de faire un handover vers la nouvelle cellule WiMAX. Ce mcanisme est appel mcanisme utilisateur. Dans le deuxime mcanisme, l'utilisateur soccupe du handover vertical (up et down) dans la zone de recouvrement (comme avec le mcanisme utilisateur). En revanche, quand un utilisateur WiMAX quitte le rseau (fin dappel), le rseau essayera galement de transfrer un utilisateur connect au systme satellite et situ dans la cellule WiMAX dans laquelle la fin de connexion vient de se produire. La recherche dun utilisateur dans dautres cellules WiMAX na rien apport en terme de performances. Ce mcanisme est motiv par le fait que la communication avec les rseaux terrestres est plus avantageuse en raison du cot dappel, du dlai, du dbit, etc. Le remplacement est de type 1 pour 1 dans la mesure o dans ce chapitre, les connexions sont toutes quivalentes.

83 Par ailleurs, nous avons galement essay de prolonger notre solution de sorte que l'utilisateur satellite puisse consulter priodiquement la possibilit de rejoindre le rseau WiMAX en effectuant un down handover (dans le modle de simulation, le systme consulte cette possibilit de transfert chaque fois que lutilisateur change de zone dans la cellule WiMAX). Mais cette approche n'a pas men des rsultats intressants.

4.

Scnarios et approches

4.1. Description des scnarios

Comme reprsent sur la Figure 52, nous reprenons les deux scnarios adopts dans le chapitre deux de sorte que le terminal mobile WiMAX rejoigne le systme satellite. Nous ne retiendrons ici que le premier, le terminal mobile a deux interfaces : une interface DVBS /RCS et une interface WiMAX.

V-AAA Information Database Visited Core

AP WLAN

Scenario 1 chemin 1 chemin 2 Terminal mobile (MT)

SAL
Information server

Visited Core

BS WiMAX 1

SAL V-AAA
Home Core Network

BS WiMAX 2

Satellite

H-AAA

Tunnel

Wireline Connection 803.3 Direct or through a tunnel

HA

Internet

Visited Core

Scenario 2 chemin 1 chemin 2

CN V-AAA

Gateway

Figure 52 : Scnarios de l'intgration WiMAX/satellite

Chaque terminal a deux chemins pour atteindre le rseau mre : directement travers la station de base WiMAX (chemin 1) ou travers le segment satellite (chemin 2). Notons que le systme satellite est transparent. Seules les passerelles et les stations de base WiMAX peuvent traiter les demandes (requtes) d'allocation de ressources.

84

4.2. Approches adoptes

Le but du mcanisme de rservation de canaux est de rserver le plus tt possible un canal auprs de la station de base cible d'un utilisateur situ dans les zones frontires et en train de se dplacer vers la station de base cible. Cette rservation peut garantir le handover horizontal et amliorer la performance du systme entier comme nous avons vu dans le chapitre trois. Afin deffectuer la rservation de canaux, nous rappelons les trois approches adoptes dans le chapitre prcdent (Figure 53 et Figure 54) : Approche cooprative (CA) : la rservation auprs de la station de base cible est mise en uvre laide des nuds voisins. Approche individuelle (IA) : la station de base de service et la station de base cible prennent en charge la procdure de rservation. Approche mixte (MA) : Ce mode est fond sur les deux approches prcdentes. Le nud mobile a donc deux choix pour rserver un canal.

CA 2
MN

NN

BS1

BS2

IA CR Phase
CR request CR response

MA Handover Preparation Process

Figure 53 : Messages changs dans les approches proposes

5.

Dfinition de la topologie

Le modle du rseau WiMAX est le mme que celui du chapitre prcdent. Le rseau WiMAX est couvert par le systme gostationnaire (GEO) (Figure 54). Le spot de rseau satellite est beaucoup plus grand que les cellules WiMAX, il les recouvre donc compltement.

85
Satellite System (GEO)
Overlapping Zone 2 (OZ2)

..

..

..

..

18

19

20

Up Boundary Zone (UBZ1)

CR BS1 CR request CR
MN Down Boundary Zone (DBZ1)

WiMAX macro-cell 1

Central Zone 1 (CZ1)

HO

Overlapping Zone 1 (OZ1) NN

Satellite System (GEO)

Up Boundary Zone 2 (UBZ2)

VHO HHO

BS2

WiMAX marco-cell 2

Central Zone 2 (CZ2)

Microcell

NN BS2
Overlapping zone

BS1

Down Boundary Zone 2 (DBZ2)

WiMAX marcro-cell
Overlapping Zone 2 (OZ2)

Figure 54 : Topologie adopte

6.

Analyse de performance

6.1. Paramtres du modle

Dtaillons les paramtres de simulation. La capacit de la station de base (C) est gale 45 canaux et la capacit du satellite vaut 2C canaux. Nous avons dfini cette capacit en nombre de canaux afin de faciliter lanalyse des rsultats. Attention toutefois, les canaux du systme satellite sont supposs plus petits que ceux du rseau WiMAX. On ne considre quun seul type de connexions dans une simulation (un seul dbit et une seule dure moyenne). Nous considrons les paramtres du chapitre 3 dans le cas 2 (4 km x 4 km) et faisons de nouveau varier la charge normalise de 60% 100%. Dans chaque mcanisme utilisateur et rseau , nous distinguons deux scnarios : un scnario avec un dbit adaptatif sans modification de la dure des connexions et un autre avec un dbit adaptatif et une modification de la dure des connexions. On prendra des dbits des canaux du systme DVB-RCS quatre fois plus faibles dbit adaptatif avec un facteur 4. Notons que les rsultats obtenus dans le cas o lon change le dbit mais pas la dure des connexions lors dun handover vertical peut aussi sinterprter comme un cas de figure o lon ne changerait pas le dbit des connexions lors dun changement de systme mais pour lequel le dbit total du systme DVB-RCS serait le mme que celui de

WiMAX. Le temps simul est de 10 confiance qui ne dpasse pas 10%.

+6

86 s pour quon puisse garantir un intervalle de

6.2. Critres de performance

Afin dvaluer la performance du modle propos dinterconnexion WiMAX/DVBRCS, nous considrons les critres suivants : Le taux de blocage des nouveaux appels dans le rseau WiMAX et dans le systme satellite (NCBR_wimax et NCBR_satellite). Le taux de blocage de handover horizontal et de handover montant (up handover) (HHOBR et UHOBR). Le dbit de tentatives des handovers horizontaux (HHOR : Horizontal Handover Rate), des up handovers (UHOR : Up Handover Rate) et le dbit des down handovers (DHOR : Down Handover Rate). Ces dbits ont un impact sur la signalisation engendre. Nous rappelons quen cas de blocage sur une cellule WiMAX (nouvel appel ou handover), lutilisateur tente alors sa chance dans le systme satellite. Ce nest que dans le cas dun chec vers le satellite quil y a un rejet de la connexion ou une interruption dune communication en cours.

6.3. Cas de linterconnexion sans rservation

6.3.1. Mcanisme rseau et utilisateur, trafic contraint temporellement Dans le premier scnario, nous considrons que le basculement vers le systme DVB-RCS se traduit par une division de dbit de 4 sans modification de la dure de connexion. Dans toutes les figures qui suivent, les critres de performance sont observs en fonction de la charge exprime en Erlang, qui est la charge soumise au systme global. Sur les premires figures, nous avons observ les diffrentes probabilits de blocage en fonction de la charge (Figure 55 et Figure 56). La premire correspond aux rsultats obtenus avec le mcanisme rseau et la seconde avec le mcanisme utilisateur. Nous constatons que tous ces taux de blocage augmentent en fonction de la charge (Erlang). Cette remarque est rassurante et sera observe dans tous les cas de figure, nous ne la rappellerons plus ultrieurement. Le principe du mcanisme rseau va tre de charger autant que possible le rseau WiMAX. On constate donc que les performances lies au rseau WiMAX se dtriorent trs rapidement avec la charge ; ce phnomne tant accentu avec le mcanisme rseau. En contrepartie, ce seront les performances du systme satellitaire qui seront comparativement moins bonnes dans le cas du mcanisme utilisateur. En effet, comme les communications WiMAX sont globalement moins interrompues et quil ny a pas de dissymtrie flagrante dans le traitement des deux systmes, la charge relative devient plus importante sur le systme satellitaire dans le cas o lon ne force pas les utilisateurs un handover descendant. Cela est trs vrai pour le handover montant, moins sensible pour le

87 blocage de nouveaux appels devant tre pris en charge par le systme DVB-RCS.

Figure 55 : Taux de blocage avec le mcanisme rseau

Notons que lanalyse des performances compltes est plus dlicate. En effet, une estimation de la probabilit de blocage des nouveaux appels consiste multiplier les taux de blocage des deux systmes (cest mme exactement lestimateur que lon utiliserait : nombre de nouveaux appels qui sont refuss par le satellite divis par le nombre de nouveaux appels simuls). Cette analyse conduit des performances presque identiques avec un taux plus lev avec le mcanisme rseau. Pour les handovers, on peut utiliser sensiblement la mme technique, pour obtenir encore une fois des probabilits dchec de handover moins importantes avec le mcanisme utilisateur quavec le mcanisme rseau (par exemple 0.31 x 0.41 = 0.1271 (mcanisme utilisateur) contre 0.21 x 0.75 = 0.1575 (mcanisme rseau) avec un charge 150 Erlang).

88

Figure 56 : Taux de blocage avec le mcanisme utilisateur

6.3.2. Mcanisme rseau et utilisateur avec un dbit adaptatif Dans cette deuxime variante, on considre des applications non temps rel. Dans ce cas de figure, le passage du rseau WiMAX au systme satellite se matrialise par un dbit divis par 4 et une dure rsiduelle de communication multiplie par 4 (transfert de fichier par exemple). Comme reprsent sur la Figure 57 et la Figure 58, nous observons des rsultats qui confirment ceux que nous avons obtenus dans le cas prcdent. En revanche, cette fois les carts se sont trs nettement creuss si lon analyse les performances globales : le mcanisme rseau conduit des performances trs largement moins bonnes que le mcanisme utilisateur.

89

Figure 57 : Taux de blocage dans le mcanisme rseau et dbit adaptatif

Figure 58 : Taux de blocage avec le mcanisme utilisateur et dbit adaptatif

90 6.3.3. Dbits des handovers, trafic contraint temporellement Nous allons maintenant examiner les dbits des diffrents types de handovers dans le cas du trafic contraint temporellement (Figure 59 et Figure 60). Nous avons trois types de handovers : horizontal, vertical descendant et vertical montant. Ces critres de performance sont significatifs dans la mesure o ils donneront des indications sur la charge de signalisation que lon obtiendra.

Figure 59 : Dbit de tentatives des handovers horizontaux trafic contraint temporellement

On constate tout dabord que les dbits des tentatives de handover horizontal sont peu influencs par la charge du systme. Cela matrialise le fait que lon refuse normment de connexions et/ou que le systme est extrmement charg dans tous les cas de figure. Ce phnomne est encore plus frappant dans le cas du mcanisme rseau .

91

Figure 60 : Dbit de tentatives des handovers montants trafic contraint temporellement

Pour ce qui est du dbit de handover montant (Figure 60), on retombe sur une configuration plus classique dans la mesure o le systme satellite est moins satur en raison de la politique implante. Ces dbits de handovers augmentent avec la charge. Ils sont plus nombreux dans le cas du mcanisme rseau dans la mesure o le systme WiMAX est plus satur que dans le cas du mcanisme utilisateur ce qui se traduit par de plus frquents checs dans les tentatives de handovers horizontaux. On a enfin reprsent les dbits des handovers descendants en fonction de la charge (Figure 61). Ces handovers nont pas t tudis dans les paragraphes prcdents dans la mesure o lon ne les met en uvre que lorsque lon est sr quil y a de la place dans la cellule WiMAX correspondante. Sil ny a pas de place, le handover nest pas effectu et lutilisateur reste connect au systme satellite. Cela engendre de la signalisation mais pas dinterruption de connexion.

92

Figure 61 : Dbit des handovers descendants trafic contraint temporellement

On retrouve une partie des rsultats prcdents. Pour ce qui est du mcanisme rseau, il est bien vident que les handovers descendants seront extrmement nombreux puisque chaque fois quun appel se termine dans une cellule WiMAX, on essayera de remplacer la connexion correspondante par une connexion jusqu la prise en charge par le satellite. Pour le mcanisme utilisateur, le dbit des handovers descendants est plus faible et peu sensible la charge. 6.3.4. Dbits des handovers, trafic non contraint temporellement Dans les figures suivantes (Figure 62, Figure 63 et Figure 64), nous avons repris les mmes critres de performances dans le cas de trafic non contraint temporellement. Nous aboutissons sensiblement aux mmes analyses. Ces dbits semblent assez proches de ceux obtenus avec un trafic contraint temporellement. Notons que dans ce cas de figure, la signalisation est certes un point cl mais quen revanche, le basculement dun systme un autre est moins problmatique dans la mesure o le dlai nest pas une contrainte significative (mme si un protocole tel que TCP peut y ragir de faon peu performante).

93

Figure 62 : Dbit de tentatives des handovers horizontaux trafic non contraint temporellement

Figure 63 : Dbit de tentatives des handovers montants trafic non contraint temporellement

94

Figure 64 : Dbit des handovers descendants trafic non contraint temporellement

6.4. Cas de linterconnexion de rseaux avec rservation

Dans cette nouvelle srie de rsultats, nous allons adjoindre, lensemble de nos mcanismes de handover, des mcanismes de rservation de ressources pour lesquels, nous rutilisons les approches coopratives et individuelles prsentes dans le chapitre prcdent. Le temps simul quant lui est toujours de 10+6 s. Les courbes user et network font rfrence dans les figures qui suivent au mcanisme de handover mais sans stratgie de rservation de ressources. 6.4.1. Blocage WiMAX des nouveaux appels Dans ces deux premires figures (Figure 65 et Figure 66), nous avons reprsent les taux de blocage des nouveaux appels WiMAX. Remarquons que dans cette configuration, la charge normalise est bien identique tous les cas de figure avec satellite de faon avoir des rsultats comparables. Il apparat que le mcanisme utilisateur conduit des performances plus intressantes que le mcanisme rseau et que, de la mme faon, lapproche cooprative est meilleure que lapproche individuelle. En revanche, le mcanisme de rservation ne semble pas apporter damlioration trs significative ce critre de performance.

95

Figure 65 : Taux de blocage WiMAX des nouveaux appels trafic contraint temporellement

Figure 66 : Taux de blocage WiMAX des nouveaux appels trafic non contraint temporellement

96 6.4.2. Blocage satellite des nouveaux appels Nous allons maintenant nous intresser au taux de blocage des nouveaux appels envoys vers le systme satellite (Figure 67 et Figure 68). Dans le cas du trafic contraint temporellement, nous obtenons des taux de blocage qui sont assez peu sensibles la politique adopte ; ils sont lgrement dans un ordre oppos celui que nous avons obtenu pour les blocages des nouveaux appels au rseau WiMAX. Le dbit global rejet tant le produit des deux termes, nous obtenons donc sensiblement au total le mme ordre de classement que celui obtenu sur le blocage des appels au rseau WiMAX.

Figure 67 : Taux de blocage satellite des nouveaux appels trafic contraint temporellement

97

Figure 68 : Taux de blocage satellite des nouveaux appels trafic non contraint temporellement

En revanche, pour ce qui est du trafic non contraint temporellement, on observe cette fois une diffrence assez nette entre les diffrentes solutions. Il apparat nettement que lapproche de rservation individuelle conduit des performances largement moins bonnes. Cest le mcanisme utilisateur qui conduit aux meilleures performances soit seul, soit avec un mcanisme de rservation individuel. Si lon synthtise les performances (produit des deux taux de blocage), il apparat cette fois que le mcanisme rseau conduit des performances moins bonnes que le mcanisme utilisateur et que, pour ce dernier, lapproche de rservation cooprative est la meilleure. Nanmoins, les mcanismes de rservation napportent quune contribution marginale aux performances globales du systme.

98 6.4.3. Taux de blocage des handovers trafic contraint temporellement

Figure 69 : Taux de blocage des handovers horizontaux trafic contraint temporellement

Figure 70 : Taux de blocage des handovers montants Trafic contraint temporellement

99 Regardons maintenant les taux de blocage des handovers dans le cas du trafic contraint temporellement (Figure 69 et Figure 70). Pour ce qui est des handovers horizontaux, on constate encore une fois que le mcanisme rseau qui force les handovers en cas de terminaison dappels dans le rseau WiMAX conduit aux taux de blocage des handovers les plus mauvais. Ces rsultats ne sont quen partie contrebalancs par des taux de blocage des handovers montants plus faibles. Le mcanisme utilisateur est le meilleur en particulier lorsquon y adjoint un mcanisme de rservation ; lapproche cooprative est plus efficace que celle individuelle en ce qui concerne les blocages des handovers horizontaux, le fait que nous montrent les rsultats dans le cas 2 (4 km x 4 km) en consquence la densit des utilisateurs est suffisante. Lapproche cooprative et lapproche individuelle conduisent des rsultats presque identiques au total. 6.4.4. Taux de blocage des handovers trafic non contraint temporellement Pour finir, nous allons reprendre les mmes critres de performances dans le cas du trafic non contraint temporellement (Figure 71 et Figure 72), c'est--dire celui pour lequel, le passage vers le systme satellite se traduit par une rduction de dbit mais un allongement de la dure des communications.

Figure 71 : Taux de blocage des handovers horizontaux trafic non contraint temporellement

100

Figure 72 : Taux de blocage des handovers montants trafic non contraint temporellement

Les rsultats auxquels on aboutit confirment les remarques prcdentes : la meilleure solution est la technique o lon ne force pas les utilisateurs passer au systme WiMAX et avec une approche de rservation cooprative en ce qui concerne les blocages des handovers horizontaux et avec une approche de rservation individuelle concernant les blocages des handovers montants.

7.

Conclusion

Dans ce chapitre, nous avons adopt un modle d'interconnexion d'un rseau WiMAX et dun systme satellite comme type de rseau 4G. Nous considrons deux mcanismes afin deffectuer cette intgration : un mcanisme o le handover sera provoqu par le rseau et un mcanisme o seuls les changements de zones de couverture WiMAX posent la question du handover vertical. Nous avons adjoint ce mcanisme les approches de rservation de ressources que nous avons voques dans le chapitre prcdent. Il apparat que la technique qui consiste forcer les handovers vers le systme WiMAX a tendance conduire des probabilits de blocage de connexions plus importantes (mme sil est vrai quen contrepartie, la qualit de service des utilisateurs sera meilleure une fois la connexion tablie en raison des dbits plus grands et dun dlai galement plus faible).

101 Les mcanismes de rservation amliorent les performances ; en revanche, aucune des approches de rservation ne semble conduire des performances qui soient meilleures dans tous les cas de figure. Dans ce chapitre, nous avons commenc faire apparatre la notion de diffrents types de trafic ; nous allons maintenant essayer de nous attaquer plus compltement cette thmatique en proposant tout dabord des solutions de mise en correspondance entre les classes de service WiMAX et celles du DVB-RCS puis en essayant de mettre en place des fonctions dadmission de connexion plus complexes de faon prendre en compte les diffrentes contraintes (et pas seulement le dbit) dans ladmission ou le refus des nouvelles connexions ou des transferts entre systmes.

102

CHAPITRE V MISE EN CORREPONDANCE DE LA QUALITE DE SERVICE DANS LES RESEAUX WIMAX ET DVB S/RCS

1.

Introduction

Ce chapitre a pour objectif de mettre en correspondance la qualit de service entre les rseaux WiMAX et DVB-RCS afin de mettre en uvre leur interoprabilit. Nous prsentons le mcanisme dallocation de ressources utilis dans chaque type de rseau. Nous listons dailleurs les classes de service en montrant les paramtres les dcrivant. Puis, nous proposons une mise en correspondance des paramtres de la QoS entre ces rseaux [55] [56] [57] [58].

2.

Catgories de demande de capacit DVB-RCS

Afin de manipuler un nombre lev de terminaux satellites sur la voie de retour (RCSTs), la norme DVB-RCS spcifie un accs multiple division temporelle et multifrquence (MF-TDMA) comme mode daccs au systme satellite [57]. Le centre de contrle prend en charge lallocation chaque terminal actif, en attribuant un certain nombre de slots ventuellement sur plusieurs frquences, un instant de dpart et une dure. Le processus d'allocation des ressources repose sur cinq catgories de capacit : Continuous Rate Assignment (CRA) ; Rate Based Dynamic Capacity (RBDC) ; Volume Based Dynamic Capacity (VBDC) ; Absolute Volume Based Dynamic Capacity (AVBDC) ; Free Capacity Assignment (FCA). Pour plus de clart, nous ferons des analyses en faisant une analogie avec des classes de service ATM (Asynchronous Transfer Mode) [59].

2.1. Continuous Rate Assignment (CRA)

La catgorie CRA est une capacit de dbit (une quantit de time-slots fixe par supertrame [58]), qui sera donne intgralement dans chaque supertrame (une supertrame est compose de trames (ensemble de slots) sur une frquence porteuse donne). Typiquement une supertrame correspond une trame. Une supertrame est une portion de temps et frquence sur la voie de retour [56]. Cette capacit sera ngocie entre le terminal et le centre de contrle pendant la procdure de logon et alloue pour toute la dure de la connexion [55]. CRA est utilis pour le trafic qui exige un dbit garanti fixe, avec un dlai et une gigue minimaux (lapplication doit fournir les paramtres de gigue maximale tolre et de latence maximale). La catgorie CRA est galement prfre pour le trafic dbit variable qui na mme pas une tolrance de latence minimale dordonnancement MSL (Minimum Scheduling Latency) [56]. Un exemple d'une telle classe de trafic, pour un satellite GEO, pourrait tre la classe : CBR (Constant Bit Rate) ou la limite VBR-rt (Variable Bit Rate - real time) du rseau ATM.

2.2. Rate Based Dynamic Capacity (RBDC)

La catgorie RBDC est une capacit de dbit qui est demande dynamiquement par le terminal. La capacit RBDC sera fournie en rponse aux demandes nonces par le terminal au centre de contrle, de telles demandes tant absolues (c.--d. correspondant au dbit demand) [55]. Chaque demande effacera toutes les demandes prcdentes de type

106 RBDC du mme terminal, et sera soumise une limite de dbit maximum ngocie directement entre le terminal et le centre de contrle. Le trafic vis pour RBDC a un profil de dbit variable pouvant tolrer la latence minimale dordonnancement (MSL), c.--d. le temps minimum du dbut de la trame dans laquelle une demande est envoye, jusqu' la trame dans laquelle lallocation correspondante est effectue. RBDC est utilis pour le trafic qui tolre une gigue faible de quelques trames et qui n'exige pas un dbit garanti fixe. Une application typique de RBDC sur un satellite GEO [56], pourrait tre la classe (Available Bit Rate (ABR)) et la classe (VBR-nrt) du rseau ATM. CRA et RBDC peuvent tre combins. Dans ce cas, CRA fournit une capacit minimum fixe par supertrame tandis que RBDC assure une variation dynamique des ressources disponibles au-del de ce minimum. Dans la stratgie RBDC, une quantit de time-slots ngocie pour une supertrame ne peut pas excder un seuil maximum (RBDCmax) [58]. Bien quoptionnelle, RBDC permet dajouter ponctuellement dans cas de figure de la capacit par rapport CRA.

2.3. Volume Based Dynamic Capacity (VBDC)

La stratgie VBDC est une capacit de volume qui est demande dynamiquement par le terminal [55]. La capacit VBDC sera fournie en rponse aux demandes explicites du terminal au centre de contrle, de telles demandes tant cumulatives (c.--d. chaque demande s'ajoutera toutes les demandes prcdentes du mme terminal). Le total cumulatif pour un terminal sera rduit de la quantit de cette catgorie de capacit alloue dans chaque supertrame. VBDC devrait tre utilis uniquement pour les trafics qui peuvent tolrer la gigue, tels que la classe UBR (Unspecified Bit Rate) du trafic ATM ou du trafic standard IP [56]. Par consquent, les connexions VBDC n'ont pas de contraintes particulires en terme de QoS. Les stratgies VBDC et RBDC peuvent galement tre utilises en combinaison pour le trafic ABR, la composante VBDC fournissant une prolongation de capacit de priorit faible au-dessus de la limite garantie dans la catgorie RBDC. La stratgie VBDC, dans laquelle une quantit de time-slots est ngocie auprs du centre de contrle, peut tre partage sur plusieurs supertrames [58]. Ces demandes sont cumulatives.

2.4. Absolute Volume Based Dynamic Capacity (AVBDC)

La stratgie AVBDC est une capacit de volume qui est demande dynamiquement par le terminal [55]. Cette capacit sera fournie en rponse aux demandes explicites du terminal au centre de contrle, de telles demandes tant absolues (c.--d. cette demande remplace les prcdentes du mme terminal). AVBDC ressemble VBDC et devrait tre utilis la place de VBDC quand le terminal sent qu'une demande VBDC pourrait tre perdue [56]. Cela pourrait se produire quand des demandes sont envoyes sur des slots en contention ou quand les conditions du canal (PER (Packet Error Rate), Eb/N0 (Energy per bit to Noise power spectral density ratio, etc.) sont dgrades. Le trafic correspondant AVBDC ressemble celui de VBDC. La stratgie AVBDC est une quantit de time-slots ngocie auprs du centre de contrle et peut tre partage sur plusieurs supertrames [58]. Une nouvelle demande AVBDC annule la demande prcdente.

107

2.5. Free Capacity Assignment (FCA)

La stratgie FCA est une capacit de volume alloue au terminal et obtenue partir de la capacit inutilise [55]. Cette allocation est automatique, car elle n'implique aucune signalisation du terminal vers le centre de contrle. FCA ne devrait tre mis en correspondance avec aucune catgorie de trafic puisque la disponibilit est fortement variable. La capacit alloue dans cette catgorie est prvue comme une capacit bonus qui peut tre utilise pour rduire le dlai sur n'importe quel trafic qui peut tolrer la gigue. CRA et FCA peuvent galement tre regards comme des mcanismes pour accorder dynamiquement de la capacit un terminal sans demande effectue partir de ce terminal [56]. FCA reprsente les time-slots dune supertrame non utiliss par les autres types de capacits qui sont distribus ou non entre les terminaux satellites [58]. Le Tableau 2 rcapitule les catgories de demande de capacit et la classe de trafic ATM correspondant chaque catgorie :
Catgorie DVB-RCS CRA RBDC CRA et RBDC en combinaison VBDC VBDC et RBDC en combinaison trafic ABR AVBDC FCA

Classe de trafic

CBR et VBR-rt ATM

ABR ATM

VBR-rt ATM

UBR ATM

semblable VBDC

capacit bonus

Tableau 2 : Catgories de demande de capacit DVB-RCS et correspondance ATM

3.

Stratgie de file dattente dans le systme satellite DVBRCS

Un terminal gre tout le trafic arrivant de l'interface utilisateur [56] en utilisant des files d'attente spares correspondant des priorits diffrentes de transmission. Les stratgies de files dattente peuvent tre nombreuses. Communment, on peut mettre en place une file dattente par classe de service pour chacune des priorits suivantes : trafic temps rel (pour CRA), dbit variable (pour RBDC) et non contraint (pour VBDC/AVBDC). De plus, on peut ventuellement imaginer davoir une file par flux. Nous dcrivons maintenant le mcanisme de rservation utilis dans DVB-RCS. La norme DVB-RCS offre un canal de retour dont les capacits peuvent varier au cours du temps [58]. Chaque terminal rclame dynamiquement des capacits de transmission au centre de contrle qui les lui alloue selon les ressources disponibles et les besoins exprims. En outre, si un moment donn, on observe une accumulation de trafic transmettre dans un terminal, il peut requrir plus de bande passante auprs du centre de contrle. L'algorithme et le protocole utiliss s'appelle DAMA : Demand Assigned Multiple Access. Il y a cinq catgories de capacits prsentes comme nous venons de le voir. Pour que lon puisse transporter les requtes de capacit vers le centre de contrle, deux types de signalisation sont proposs : une signalisation dans la bande et une signalisation hors-bande. Le premier type est fond sur une mthode lie un champ optionnel et s'appelle SAC (Satellite Access Control) et repose sur la mthode DULM

108 (Data Unit Labelling Method) qui permet au terminal de transmettre les informations de contrle et/ou d'administration auprs du centre de contrle dans des slots consacrs au trafic. La signalisation hors-bande est fonde sur la mthode de mini-slot avec ou sans contention qui correspond l'allocation priodique au terminal ou un groupe de terminaux de slots de plus courte dure que les slots de trafic. Cette allocation de bande passante la demande est considre comme une des plus robustes des systmes satellites dans le cadre de QoS en rpartissant toute la bande passante entre les terminaux selon leurs charges.

4.

Qualit de service dans les rseaux WiMAX

La qualit de service dans le rseau WiMAX IEEE 802.16e est prise en charge par le biais dallocations chaque connexion entre le terminal et la station de base (appels flux de service dans la terminologie IEEE 802.16) pour une classe spcifique de QoS [59]. Le Tableau 3 montre les cinq classes de service de QoS spcifies dans le rseau 802.16e :
Service
Unsolicited Service (UGS) Grant

Definition
Real-time data streams comprising fixed-size data packets issued at periodic intervals Real-time service flows that generate variable-sized data packets on a periodic basis Real-time data streams comprising variable-sized data packets that are issued at periodic intervals Delay-tolerant data streams comprising variable-sized data packets for which minimum data rate is required Data streams for which no minimum service level is required and therefore may be handled on a spaceavailable basis

Typical Applications
T1/E1 transport, VoIP without silence suppression. VoIP with silence suppression. MPEG Video FTP with guaranteed minimum throughput HTTP

Extended Real-time Polling Service (ErtPS) Real-time Polling Service (rtPS) Non-real-time Polling Service (nrtPS) Best Effort (BE)

Tableau 3 : Classes de QoS IEEE 802.16e 2005 [60] [61]

Les stations de base et les terminaux utilisent un flux de service avec une classe approprie de QoS (plus d'autres paramtres, tels que la bande passante et le dlai) pour s'assurer que les donnes applicatives reoivent le traitement de QoS appropri l'application. Les services d'ordonnancement reprsentent les mcanismes de traitement des donnes pris en charge par lordonnanceur pour lenvoi de donnes sur une connexion [59]. Chaque connexion est associe un service simple de donnes. Chaque service de donnes est associ un ensemble de paramtres de QoS qui mesurent son comportement. Ces paramtres sont contrls en utilisant des messages de dialogue. Nous fournissons dans la suite une courte description de chacun des services dordonnancement proposs, y compris les paramtres obligatoires de QoS qui seront inclus dans la dfinition des flux de service. 4.1. Service UGS La classe de service UGS prend en compte les flux de donnes en temps rel se composant des paquets de donnes de taille fixe envoys intervalles priodiques, tels que

109 le T1/E1 et la voix sur IP sans suppression de silence. Les paramtres obligatoires de QoS pour ce service dordonnancement sont (dans un rseau WiMAX fixe) [59] [62] : - Le dbit maximum de trafic soutenable : ce paramtre dfinit le dbit maximal. Nous utilisons la dnomination utilise dans la norme. - La latence maximale : la valeur de ce paramtre spcifie la latence maximale entre la rception d'un paquet par la station de base ou le terminal sur son interface rseau et lexpdition du paquet son interface RF. - La gigue tolre : ce paramtre dfinit la variation de dlai (gigue) maximale pour la connexion. - La politique de requte/transmission est utilise pour lallocation de ressources. La valeur de ce paramtre, prsentant cette politique, fournit les possibilits de spcifier certains attributs pour le flux de service associ. Ces attributs incluent des options pour le format de PDU (Protocol Data Unit) et, pour le flux de service sur la liaison montante, des restrictions sur les types d'options de demande de bande passante qui peuvent tre utilises. - De manire optionnelle, on peut spcifier le dbit minimum rserv pour le flux de service. Dans cette classe de service, le dbit minimum rserv pourrait tre gal au dbit maximum soutenable de trafic. 4.2. Service rtPS La classe de service rtPS prend en charge les flux (streams) de donnes en temps rel se composant de paquets de donnes de taille variable qui sont mis priodiquement, tels que les flux MPEG [59]. Les paramtres obligatoires de QoS pour ce service dordonnancement sont : le dbit minimum rserv, le dbit maximum soutenable, la latence maximale, et la politique de requte/transmission. 4.3.

Service ErtPS La classe de service ErtPS est un mcanisme dordonnancement construit michemin entre UGS et rtPS [60]. La station de base fournit des droits mettre unicast d'une faon non sollicite comme dans UGS ; cela permet de garantir la latence d'une demande de bande passante. Tandis que les attributions UGS sont de taille fixe, les attributions ErtPS sont dynamiques. La station de base fournit des allocations priodiques sur le lien montant afin de demander de la bande passante et des transferts de donnes. Le service ErtPS prend en charge les flux de service qui utilisent une taille variable de donnes sur une base priodique comme dans le cas de VoIP avec suppression de silence (avec dtection dactivit [62]). Au contraire, le service UGS prend en charge VoIP sans suppression de silence. Les paramtres de QoS de cette classe sont : le dbit minimum rserv, le dbit maximum soutenable, la latence maximale, la gigue tolre et la politique de requte/transmission. Service nrtPS La classe de service nrtPS est conue pour prendre en charge les flux de donnes tolrants au dlai se composant de paquets de taille variable pour lesquels un dbit minimum est prfrable, comme FTP (File Transfer Protocol) [59]. Les paramtres de QoS de cette classe de service sont : le dbit minimum rserv, le dbit maximum soutenable, et 4.4.

110 la priorit du trafic. La valeur de ce paramtre spcifie la priorit alloue au flux de service. Etant donns deux flux de service identiques quant leurs paramtres de QoS sauf la priorit, le service priorit la plus leve devrait subir un dlai plus faible et une prfrence plus leve au niveau du buffer. 4.5. Service Best Effort (BE) La classe de service BE est utilise pour prendre en charge les flux de donnes pour lesquels aucun niveau de qualit de service n'est exig [59]. Les paramtres obligatoires de QoS de ces flux de service sont : le dbit maximum soutenable, la priorit du trafic, et la politique de requte/transmission. Pour rsumer, certains types dapplications [63], qui peuvent tre utilises dans un rseau WiMAX, sont prsents dans le Tableau 4.
Applications UGS
IP Traffic Compressed Video Multimedia Circuit Emulation real-time audio/video Variable rate VoIP Video on demand (streaming), Large data files Web access, emails, http FTP with guaranteed minimum throughput ok ok ok

Classes de service WiMAX ErtPS rtPS nrtPS

ok ? ? ok ok ? ? ? ?

BE
ok

ok ok ok ok

Tableau 4 : Diffrentes applications potentielles [63]

5.

Mise en correspondance WiMAX et DVB-RCS

Nous essayons ici de raliser la mise en correspondance des trafics et des paramtres de QoS entre les rseaux WiMAX et les rseaux DVB-RCS. Nous voulons permettre au trafic de passer dun rseau l'autre en garantissant une QoS qui convienne lapplication. Le Tableau 5 montre cette mise en correspondance des paramtres. En fait, dans la littrature [57], les auteurs ont propos trois catgories de service gnriques de systme DVB-RCS : CBA, DBA et BEA (Constant Bandwidth Allocation, Dynamic Bandwidth Allocation et Best Effort Allocation). Cependant, nous reprenons les catgories de systme DVB-RCS spcifies dans la norme (CRA, RBDC et VBDC) de sorte que nous mettons en correspondance ces trois catgories avec les cinq classes de service dans WiMAX. Trois classes de rseau WiMAX seront mises en correspondance avec une seule classe WiMAX. Dans un premier temps, la mise en correspondance est effectue dans le sens DVB-RCS WiMAX. La Figure 73 montre le schma de la mise en correspondance dans un cadre dinterconnexion de rseaux WiMAX/DVB-RCS.

111

5.1.

DVB-S/RCS

WiMAX

Dans ce cas, nous avons trois catgories DVB-RCS et on est en charge de mettre en correspondance les paramtres de QoS dfinissant chaque catgorie DVB-RCS avec la classe quivalente dans WiMAX. 1. CRA est une allocation de bande passante constante, qui est considre comme une stratgie de rservation lorsquun utilisateur DVB-RCS veut rejoindre le rseau. CRA doit tre mis en correspondance avec la classe UGS dans le rseau WiMAX. Les paramtres de la classe CRA sont les suivants : - Le dbit maximal (Peak Data Rate (PDR)) qui est gal au taux fixe garanti dans la catgorie CRA. Ce paramtre est mis en correspondance avec le dbit maximum soutenable (max STR) dans le rseau WiMAX. - La tolrance de gigue minimale peut tre mise en correspondance avec la tolrance de gigue dans le rseau WiMAX. Notons que dans WiMAX, il est fait rfrence une gigue minimale alors que dans DVB-RCS, on parle de tolrance minimale de gigue. Il sagit bien de la mme notion : on veut une gigue faible pour laquelle on donne la valeur maximale. Les paramtres spcifis dans le standard DVB-RCS front en fait rfrence au dlai maximum, la latence minimale et la gigue maximale mais par la suite nous continuerons utiliser les mmes dnominations que dans la norme. - Le dlai minimum : nous pouvons mettre en correspondance ce paramtre avec la latence maximale dans le rseau WiMAX. Il y a de nouveau une lgre ambigut dans le standard DVB-RCS. On veut que pour ce trafic le dlai soit minimal, on en donne la valeur maximale. Nous tenons noter ici que le terminal satellite, qui veut transfrer son trafic vers le rseau WiMAX, n'est pas oblig de faire attention au dlai propos par WiMAX. En effet, les applications qui acceptent le dlai de rseau DVB-RCS, acceptent forcment le dlai dans le rseau WiMAX qui est comparativement beaucoup plus faible.
La mise en correspondance
DVB-RCS
- CRA QoS - ErtPS - rtPS - RBDC Non QoS - VBDC

WiMAX
- UGS

-nrtPS
- Best effort

Figure 73 : Schma de la mise en correspondance DVB-RCS

WiMAX

2.

RBDC est une allocation dynamique de bande passante non temps rel. Cette catgorie est quivalente la classe nrtPS dans le rseau WiMAX. Les paramtres de cette catgorie de service sont :

112 - Le PDR (Peak Data Rate) qui correspond au dbit maximal (max STR) de la classe nrtPS. - Le dbit minimum qui correspond au dbit minimum du trafic dans le WiMAX. VBDC (AVBDC) : cest une allocation best effort. Cette catgorie a seulement un paramtre, PDR (Peak Data Rate) qui est mis en correspondance avec le dbit maximal dans WiMAX (pour plus de dtails, voir Tableau 5).
WiMAX DVBS/RCS

3.

Classes de service WiMAX

Classes de service DVB-RCS

DVB-S/RCS WiMAX

UGS
- Maxi Sustained Traffic Rate (max STR) - Tolerated Jitter - Maximum Latency

CRA
- PDR = maxi STR - Mini tolerated jitter = tolerated jitter - Mini delay = maxi latency.

CRA
- PDR - Mini tolerated jitter - Mini delay.

UGS
- Maxi STR = PDR - Tolerated Jitter = mini tolerated jitter - Maxi Latency = mini delay

ErtPS
- Maxi Sustained Traffic Rate - Mini Reserved Traffic Rate - Maxi Latency - Tolerated Jitter

CRA
- PDR = maxi STR - Mini tolerated jitter =tolerated jitter - Mini delay = maxi latency.

rtPS
- Maximum Sustained Traffic Rate - Mini Reserved Traffic Rate - Maxi Latency

CRA
- PDR = maxi STR - Mini delay = maxi latency.

nrtPS
- Maxi Sustained Traffic Rate (STR) - Mini Reserved Traffic Rate (RTR)

RBDC
- PDR = Maxi STR - Mini rate = mini RTR

RBDC
- PDR - Mini rate - Maxi STR = PDR - Mini RTR = mini rate

BE
- Maxi Sustained Traffic Rate

BE
- PDR = Maxi STR

VBDC (AVBDC)
- PDR

BE
- Maxi STR=PDR

Tableau 5 : Mise en correspondance des paramtres de QoS dans un contexte WiMAX/DVB-RCS

5.2.

WiMAX

DVB-S/RCS

Nous expliquons maintenant la mise en correspondance dans le sens WiMAX DVB-RCS (voir Figure 74). 1. UGS : cette classe est mise en correspondance avec la catgorie CRA dans DVB-RCS. Les paramtres dcrivant la classe UGS sont : - Le dbit maximal qui est mis en correspondance avec le PDR de CRA. - La gigue tolre est mise en correspondance avec la gigue tolre de CRA. - La latence maximale est quivalente au dlai minimal de CRA.

113 Attention, ici, les contraintes de dlai ne sont pas vraiment du mme ordre de grandeur dans le systme satellite (o le dlai de propagation est incompressible et gal 240 ms). Cela dit, des exprimentations ont montr que les transferts de voix ou de vidos sont possibles dans le cas dun systme DVBS/RCS. Dans la suite de la mise en correspondance et dans le chapitre dvaluation de performances qui suit, on supposera que les applications contraintes temporellement pourront saccommoder de ce dlai du satellite. En revanche, notons que la classe CRA conduit une gigue extrmement faible dans la mesure o lallocation des slots pour ce type de trafic est constante. 2. ErtPS : Cette classe pourrait tre mise en correspondance avec la catgorie CRA dans DVB-RCS. Les paramtres qui caractrisent la classe ErtPS sont les suivants : - Le dbit maximal, ce dbit est mis en correspondance avec PDR dtermin par la catgorie CRA. - Le dbit minimal qui na pas un paramtre de qualit de service quivalent dans la catgorie CRA. - La latence maximale de classe ErtPS est mise en correspondance avec le dlai minimal, qui est termin par la catgorie CRA. - La gigue tolre correspond la gigue tolre gre par la stratgie CRA. On pourrait dire que la classe ErtPS pourrait mettre en correspondance avec la catgorie CRA. En revanche, le dbit qui sera allou sera constant et gal au dbit maximal.
La mise en correspondance
WiMAX
QoS - UGS - ErtPS - rtPS

DVB-RCS
- CRA

-nrtPS
- Best effort

- RBDC

Non QoS

- VBDC

Figure 74 : Schma de la mise en correspondance WiMAX

DVB-RCS

3.

4.

rtPS : Cette classe est aussi mise en correspondance avec la catgorie CRA. Les paramtres dcrivant la classe rtPS sont les mmes que pour la classe ErtPS mais la gigue tolre nest pas prise en compte pour rtPS. On a donc la mme mise en correspondance que pour la classe ErtPS. nrtPS : cette classe de service est mise en correspondance avec la catgorie RBDC dans DVB-RCS. La classe nrtPS est caractrise par les paramtres suivants : - Le dbit maximal correspond au dbit PDR de la catgorie RBDC.

114 5. Le dbit minimal est mis en correspondance avec le dbit minimal de la catgorie RBDC dans DVB-RCS. Best Effort : La classe best effort dans le rseau WiMAX correspond la catgorie VBDC ou AVBDC dans le systme DVB-RCS. La classe nrtPS dans WiMAX a un seul paramtre : le dbit maximal qui correspond au dbit PDR dans le systme DVB-RCS.

Quelques applications qui pourraient tre envisageables dans le systme satellite DVB-RCS sont montres dans le Tableau 6 [57].
Applications Videoconferencing, Telephony, Television, Distance Learning Video on Demand, Airline Reservations, Banking Transactions, Store & Forward Email, Web Browsing, FTP Catgories DVB-RCS CRA RBDC VBDC ok ok ok

Tableau 6 : Applications envisageables dans DVB-RCS [57]

6.

Conclusion

Dans ce chapitre, nous avons tent de mettre en correspondance les trafics et les paramtres de QoS des rseaux WiMAX et DVB-RCS. Nous avons list les diffrentes classes de service dans chaque rseau avec les paramtres de QoS qui contrlent chacune dentre elles. Nous avons montr les diffrentes stratgies de capacit utilises dans le rseau DVB-RCS. La stratgie CRA permet au terminal de rserver un dbit fixe et garanti, alors que les stratgies RBDC et VBDC permettent de prendre en compte la demande variable du terminal et la stratgie FCA est un bonus utilis si ncessaire. Une proposition de mise en correspondance des paramtres de QoS entre ces deux rseaux a t faite. Dans le chapitre suivant, nous allons poursuivre ltude du contexte multi-service en proposant un mcanisme dacceptation de connexion CAC (Call Admission Control) dans le rseau WiMAX et le rseau DVB-RCS ainsi que dans un cadre de linteroprabilit WiMAX/DVB-RCS.

CHAPITRE VI CONTROLE DADMISSION DE CONNEXION

1.

Introduction

Dans ce dernier chapitre, nous allons nous intresser la procdure de contrle dadmission de connexion CAC (Call/Connection Admission Control) multiservice dans le rseau WiMAX, dans le systme satellite DVB-RCS et dans linterconnexion de rseaux WiMAX/DVB-RCS. Des mcanismes sont proposs qui sont modliss puis valus.

2.

Contrle dadmission de connexion dans les rseaux WiMAX et DVB-RCS

2.1. Cas du rseau WiMAX

Contrairement aux solutions classiques du monde IEEE, la solution WiMAX repose sur un mode connect comme nous lavons vu dans les chapitres prcdents. Il est donc ncessaire de mettre en uvre une fonction dadmission de connexion qui prenne en compte laspect multiservice. D'abord, la fonction CAC dans ce contexte constitue une tape essentielle pour garantir de la qualit de service dans la mesure o elle peut grer la capacit disponible de systme et par consquent vrifier les conditions de qualit de service. Laspect multiservice et les contraintes htrognes en terme de qualit de service compliquent lopration. Les thmatiques de recherche concernant le mcanisme CAC dans les rseaux WiMAX portent sur : lamlioration de la performance de systme tudi et donc laugmentation de lutilisation des ressources ; ltude mathmatique de ces fonctions ; la mise en uvre dune architecture qualit de service tenant compte du mcanisme CAC. Les auteurs dans [64] proposent un schma dallocation adaptif de puissance APA (Adaptive Power Allocation) et un contrle d'admission de connexion CAC multiservice fond sur OFDMA-TDD (Orthogonal Frequency Division Multiple Access/Time Division Duplex) dans un rseau WiMAX. Les auteurs proposent un gestionnaire de CAC plac dans la station de base WiMAX. Ce gestionnaire peut dterminer la bande passante des liens montants/descendants pour chaque utilisateur connect la station de base. Lorsquun utilisateur tablit une connexion, il envoie la demande de connexion au gestionnaire de CAC avec ses besoins de la bande passante upstream et downstream. Puis, le gestionnaire effectue le contrle d'admission de connexion sur les deux liens (montant et descendant). Diffrentes stratgies sont imposes aux classes qualit de service garantie (UGS, rtPS, et nrtPS) et la classe de service best effort. Ainsi, la bande passante de l'utilisateur est divise en deux parties indpendantes, la premire concerne les ressources en bande passante alloues la classe de service qualit de service garantie et l'autre concerne les ressources en bande passante alloues la classe de service best effort. Cependant, il n'y a pas de conditions spcifiques chaque classe de trafic afin de vrifier les paramtres de qualit de service spcifis dans la norme. Pour amliorer les performances de systme

118 propos, une gestion de ressources cross-layer est prise en compte. Afin daugmenter lefficacit de lutilisation des ressources limites du rseau WiMAX, les auteurs dans [65] proposent un polling hirarchique adaptatif avec un mcanisme de CAC. Lintrt est damliorer laccs au canal, la rduction du dlai de vote et laugmentation du revenu du rseau en rduisant au minimum la perte partielle de revenu (Fractional Reward Loss (FRL)). Ce paramtre reprsente la probabilit pondre de blocage des appels. A chaque appel correspond un poids fonction de son revenu. Une fois que le facteur FRL est minimis, le revenu du rseau est maximis. Comme on le voit, les contraintes de qualit de service ne sont pas vraiment apprhendes avec cette technique. Le problme trait est un peu le problme dual de celui auquel on sintresse. Il sagit essentiellement doptimiser le gain engendr par lacceptation dappel plutt que la QoS utilisateur ou lutilisation du support. Wang et al. [66], ont fait un premier pas pour mettre en place un modle analytique de CAC afin damliorer la qualit de service dans le rseau WiMAX. Les auteurs prsentent un schma de CAC fond sur le principe de priorit en fournissant une priorit leve au trafic UGS et maximisant ainsi l'utilisation de bande passante. Des demandes non UGS sont acceptes seulement si la bande passante est disponible. Cho et al. dans [67] proposent une architecture de qualit de service dans un rseau WiMAX de niveau MAC. Larchitecture est fonde sur des modles analytiques afin damliorer lallocation de ressources et la bande passante sur le lien montant. Les auteurs dans [68] proposent un algorithme de division adaptative de trame pour les flux de donnes et de voix mais ils supposent un seul type de flux par utilisateur. La politique de CAC propose dans [69] suit un critre simple : une connexion est accepte s'il y a une bande passante suffisante disponible. La seule sgrgation propose se situe entre la classe best effort et le reste des classes de trafic. Les auteurs proposent dailleurs une file d'attente prioritaire FEPQ (Deficit Fair Priority Queue (DFPQ)) afin de sassurer que le trafic best effort soit servi. Une approche de CAC dynamique, pour garantir la qualit de service au niveau paquet, tout en ayant des contraintes sur la qualit de service au niveau de connexion, a t propose dans [70] mais les auteurs n'ont pas fait la diffrentiation entre trafics lorsquon applique le mcanisme CAC. Dans notre travail, nous voulons proposer un CAC qui soit capable de contrler chaque classe de service par des conditions gnrales qui peuvent tre adaptes et choisies selon les besoins dutilisateur et lapplication. Dans ce cas, chaque classe de service a potentiellement des conditions indpendantes des conditions des autres classes.

2.2. Cas du systme satellite DVB-RCS

Nous prsentons ici les travaux de recherche concernant le CAC dans le systme satellite DVB-RCS. Ces travaux visent les points suivants : Gestion de trafic dans un systme ATM/satellite ; Proposition dun mcanisme CAC afin de garantir la qualit de service des trafics stream (MPEG) ; Mise en uvre dun schma de CAC avec architecture multicouche (terrestre satellite).

119 Les auteurs dans [71] mettent en uvre une stratgie de gestion du trafic dans un systme dinterconnexion ATM - satellite. Cette stratgie est fonde sur un schma de CAC qui exploite le multiplexage statistique des sources de trafic et sur une gestion de ressources dynamiques. La performance des algorithmes proposs a t compare avec un systme de rfrence qui n'exploite pas le multiplexage statistique. La stratgie exploite bien la bande passante du satellite avec qualit de service des sources de type VBR temps rel et non temps rel. Lacceptation dappel est fonde sur le concept de la probabilit de demande en excs (Excess Demand Probability (EDP)). Chaque appel est dcrit par un modle Markovien On/Off deux tats. Ce travail est adopt et dvelopp dans un cas de rseau DVB-RCS dans [72] [73] [74]. Dans [72] [73], les auteurs considrent un algorithme de contrle d'admission de connexion capable de contrler les sources de trafic multimdia. Lalgorithme CAC est implant dans une architecture de systme satellite gostationnaire DVB-RCS avec une charge utile rgnrative. Dans ce travail, les auteurs tiennent compte de trois classes de service diffrentes (CRA, RBDC et VBDC). Les connexions VBDC n'ont pas de contraintes particulires en terme de qualit de service. La procdure CAC est implante dans le centre de contrle afin de garantir la qualit de service des classes CRA et RBDC. Les auteurs prennent en compte les flux (MPEG) et ils les modlisent par le dbit moyen et son cart-type. Dans [74], les auteurs proposent une stratgie optimale de contrle d'admission afin de garantir la qualit de service conforme pour des connexions de trafic multimdia par une architecture : Satellite- HAP (High-Altitude Platforms)-Terrestre. Les auteurs utilisent un systme multicouche compos de couches terrestres, HAP et GEO. D'ailleurs, ils proposent deux approches (centralise et distribue). Ils ont galement adopt les mmes paramtres et la mme application (MPEG) que dans [72] et [73]. Un autre mcanisme CAC semblable est prsent dans [75]. Les auteurs proposent un algorithme de CAC fond sur la bande passante discrte du taux de GOP (Group of Picture) appel SMDB (Standard Mechanism based on the Discrete Bandwidth). La solution propose est compare avec un mcanisme standard fond sur une distribution normale du taux de GOP appel SMND (Standard Mechanism based on the Normal distribution) propos dans [73]. Il est montr que SMDB amliore SMND lorsque l'carttype est lev et dans le cas dune forte charge de trafic dans le systme.

2.3. Conclusion
Dans tous les travaux prcdents, les auteurs utilisent des hypothses simples concernant les diffrentes classes de trafic, ou bien ces hypothses ne prennent pas en compte toutes les classes de trafic dfinies dans la norme IEEE 802.16 ou dans la norme DVB-RCS. De plus, concernant le systme satellite DVB-RCS, les auteurs se concentrent sur les flux MPEG comme seule application. Dans un contexte daccs Internet, ce seul type de flux nest pas reprsentatif (ces flux sont plus majoritairement prsents sur la voie aller). En revanche, nous visons proposer des critres et des conditions pour contrler les paramtres de qualit de service pour chaque classe de trafic de manire indpendante. Autrement dit, nous voulons proposer un mcanisme CAC gnral qui a des paramtres indpendants de l'application. Par consquent, ces conditions peuvent tre utilises pour plusieurs applications. Le dernier motif est que nous devons identifier les classes de service

120 afin de mettre en correspondance les paramtres de qualit de service des rseaux WiMAX et DVB-RCS. Pour ce faire, nous revenons aux travaux prsents dans [75] et [76] pour un rseau WiMAX afin de les dvelopper dans le cadre une interconnexion WiMAX/DVB-RCS. En outre, le travail dans [76] propose un mcanisme CAC multiclasse qui tient compte prcisment des profils du trafic UGS, rtPS et nrtPS. On joue en gros sur le multiplexage statistique des flux qui nmettent pas en permanence au dbit maximal. Cela correspond probablement la notion de bande passante quivalente ATM.

3.

Scnarios proposs

Nous supposons que les utilisateurs sont fixes et donc nous ne prenons plus en compte la mobilit dans nos modles. Cela correspond des terminaux collectifs par exemple qui auront une double interface WiMAX, DVB-RCS. Cela signifie quil n'y a plus de handovers horizontaux dans le rseau WiMAX (dans le rseau satellite il y a une seule cellule satellite). Par ailleurs, afin de transfrer les utilisateurs (nouveaux appels (handovers montants) et handovers descendants) d'un rseau vers l'autre, nous pouvons envisager plusieurs scnarios.

3.1. Mise au point du mcanisme dans le cadre WiMAX DVB-RCS

3.1.1. Handovers Plusieurs solutions sont notre disposition si lon veut procder des transferts de connexions entre les systmes mme si les clients sont fixes. Dans le cadre dune interconnexion entre un rseau WiMAX et un systme DVB-RCS, on peut envisager de dplacer un client dun systme un autre pour des raisons lies la qualit du support ; si les conditions se dtriorent rapidement, on peut envisager de procder un changement de systme. Nous ne retiendrons pas cette hypothse dans le cadre de ce chapitre mme si les fonctions CAC que nous avons dfinies sont parfaitement applicables dans ce cas de figure. La seconde motivation est lie au contexte des deux rseaux. Dans la mesure du possible, il est toujours prfrable de proposer un terminal qui peut se raccorder aux deux rseaux denvoyer ses connexions sur le rseau WiMAX qui offre un dbit agrg plus important et qui conduit des dlais beaucoup plus faibles. On aura donc la tentation de charger prfrentiellement le rseau WiMAX et sil ny a plus de place dans le rseau WiMAX, on enverra les demandes de connexions au systme DVB-RCS. De la mme faon ds que de la place se librera dans le rseau WiMAX, on tentera de raliser des handovers descendants pour utiliser les ressources libres. Notons que lon pourrait raffiner cette technique en distinguant parmi les connexions, celles qui doivent passer imprativement par le rseau WiMAX (en raison du dlai par exemple) et celles qui peuvent se contenter du systme DVB-RCS. Notons encore, que cette procdure est heuristique, on pourrait poser le problme en terme dquilibrage de charge, comment remplir au mieux le systme pour pouvoir trouver un maximum de place disponible quand une nouvelle connexion se prsente.

121 3.1.2. Partage des ressources Plusieurs stratgies sont envisageables pour partager les ressources dans chacun des systmes et de la mme faon, plusieurs techniques sont envisageables lorsque lon dsire procder au remplacement dune connexion qui se termine par une ou plusieurs connexions provenant de lautre systme. Notons que nous navons choisi que ces instants de fin de connexion pour procder des dplacements forcs de connexion ; le faire lors dune demande de connexion pourrait se rvler rdhibitoire en terme de temps de calcul et de transfert rel avant de pouvoir effectivement attribuer les ressources la nouvelle connexion entrante. Les stratgies de partage des ressources, que lon peut envisager, peuvent tre choisies parmi les stratgies classiques [77] : - Partitionnement complet : des ressources sont attribues chaque classe de trafic et la fonction dadmission de connexion est mise en uvre indpendamment sur chacune des classes en se proccupant uniquement des ressources disponibles de la classe considre ; - Partage complet : les ressources sont compltement partages entre tous les types de connexion ; - Trunk reservation : des ressources minimales sont rserves par type de trafic, le reste est mis en commun ; - Politique de seuils La politique de partage complet est connue pour tre la technique qui permet doptimiser lutilisation du support mais elle ne permet pas de se prmunir contre une sur-utilisation par une classe de trafic. La politique de partitionnement complet est la plus juste mais elle conduit aux performances les moins intressantes du point de vue de lutilisation des ressources. La politique de trunk reservation est sans doute un des meilleurs compromis en terme de performance. En revanche, toutes les politiques, sauf la politique de partage complet, ont besoin dun paramtrage qui ncessite en tant que tel une optimisation. Par consquent, pour des soucis de simplicit, nous nous sommes restreints la politique de partage complet des ressources (qui conduit tout de mme des performances raisonnables). 3.1.3. Remplacement des connexions La dernire question que lon doit sest pose est celle du choix du remplacement dune connexion qui se termine par une ou plusieurs autres connexions. Nous proposons les trois solutions suivantes : - Mise en correspondance stricte : quand une connexion WiMAX se termine, on ne peut la remplacer que par une connexion DVB-RCS quivalente (au sens nonc au chapitre 5) ; - Mise en correspondance limite : quand une connexion WiMAX se termine, on peut la remplacer par une ou plusieurs connexions DVB-RCS jusqu concurrence des ressources libres. Le choix peut encore donner lieu de nombreuses solutions ; on pourra prendre les connexions par dbit maximal dcroissant ;

122 Mise en correspondance large : quand une connexion WiMAX se termine, on peut la remplacer par une ou plusieurs connexions de nimporte quel type. Le choix est cette fois-ci encore plus large. On pense quil serait prfrable de procder par ordre de priorit temporelle dcroissante, en commenant par les connexions UGS, ErtPS, rtPS, nrtPS, BE.

4.

CAC propos

Nous proposons une procdure centralise du contrle d'admission de connexion (CAC) implant dans le centre de contrle de rseau (NCC) et/ou dans la gateway du systme DVB-RCS (ces quipements sont gnralement co-localiss) ou dans la station de base du rseau WiMAX. Le but est dassurer la qualit de service de diffrents types de classes de service. Les classes best effort et VBDC ninterviennent pas dans la qualit de service. Nous nen tiendrons pas compte dans ce qui suit. Nous nous proposons dtendre les rsultats prsents dans [75] et [76]. Dans notre tude, nous ne considrons quun type de trafic par classe ; on confondra par la suite les paramtres de classes et les paramtres de trafic. Nous dfinissons d'abord les terminologies suivantes : -

f : la dure de supertrame/trame dans le rseau satellite/WiMAX respectivement. di : le dlai maximum pour la connexion i. Pour une connexion donne, les paramtres f et di sont donns. On note alors mi = d i f le nombre de supertrames/trames correspondant ce dlai et m le minimum des mi pour une classe donne. Cette notion na dintrt que pour certains trafics WiMAX. Pour DVB-RCS, nous navons que deux classes de service de qualit : CRA et RBDC. CRA a deux paramtres sur le dbit et sur le dlai. Ce dlai est constant car les allocations sont fixes ( la granularit des emplacements des slots attribus dans une trame), tandis que pour RBDC le dlai nest pas une contrainte. Cuplink/Cforward : la capacit totale du lien montant WiMAX et de la voie de retour DVB-RCS respectivement. CUGS, CCRA : la capacit attribue aux connexions UGS/CRA. CErtPS : la capacit attribue aux connexions ErtPS. CrtPS : la capacit attribue aux connexions rtPS. CnrtPS, CRBDC : la capacit attribue aux connexions nrtPS/RBDC. Les connexions dbit variable sont caractrises par des paramtres du leaky bucket [75] [76]. ri,j : le dbit du leaky bucket (dbit moyen quivalent au dbit soutenable du trafic) de la connexion i de type j. bi : la taille du leaky bucket de la connexion i. ci,j : le dbit de la connexion i de type j.

Dans [76], on propose de faire varier les tailles des leaky buckets. Pour notre tude, nous avons choisi des tailles proportionnelles au dbit soutenu.

123 Le dbit du leaky bucket de la connexion ErtPS est gal au dbit de cette connexion (ri,ErtPS = 200 kbit/s). De mme, dans le cas de connexion rtPS (ri,rtPS = 390 kbit/s). En gnral, l'admission ou le rejet d'une nouvelle connexion est conditionne par la disponibilit de bande passante et par le respect de la condition du dlai maximum pour diffrentes connexions. La politique de contrle d'admission pour une nouvelle connexion est donne par les conditions suivantes : La condition de disponibilit des ressources : pour accepter un nouvel appel, il faut que le dbit rsiduel de lien vis Cr soit suprieur au dbit demand ci,j dune connexion i : Cr ci , j Les conditions de dlai : le contrleur veillera ce que lacceptation de la nouvelle connexion ne doive pas gner les autres connexions. Nous allons maintenant prsenter les conditions pour chaque connexion i :
-

Connexion nrtPS : Pour les connexions non temps rel, le seul paramtre vrifier est celui du dbit soutenu ; il ny a pas de contrainte sur le dlai. Il suffit donc que la capacit rsiduelle soit suffisante : (1)

ci,nrtPS Cuplink CUGS CErtPS CrtPS CnrtPS

En revanche, pour les autres types des connexions, il y aura toujours des conditions sur le dbit et sur le dlai.
-

Connexion UGS : Nous posons deux conditions sur le trafic UGS, la premire sur le dbit et la deuxime sur le dlai :

ci,UGS Cuplink CUGS CErtPS CrtPS CnrtPS (2)

(b
k

k , ErtPS

+ f .rk , ErtPS ) + (bk , rtPS + f .rk , rtPS ) + ( f .ck ,UGS ) + f .ci ,UGS
k k

Cuplink

f .m

(3)

Concernant le dbit, la contrainte est la mme que prcdemment ; il faut que le dbit rsiduel soit suffisant. Concernant le dlai, on va sassurer que le trafic maximal contraint pour le temps (UGS, rtPS et ErtPS), y compris celui de la connexion que lon ajoute, pourra scouler pendant une dure gale m trames. Pour le trafic UGS, le dbit est constant ; pour le trafic rtPS et ertPS, on se sert des paramtres de leaky bucket en se plaant dans le pire cas. Concernant les trafics rtPS et ErtPS, les conditions sont identiques : on vrifie que le dbit soutenu que lon ajoute est acceptable puis que le dlai dans le pire cas respecte les contraintes. Le pire cas est obtenu en prenant en compte de nouveau les paramtres du leaky bucket.

124 - Connexion ErtPS :

ci,Ertps Cuplink CUGS CErtPS CrtPS CnrtPS

(4)

bi , ErtPS + f .ri,ErtPS + (bk , ErtPS + f .rk , ErtPS ) + (bk , rtPS + f .rk , rtPS ) + ( f .ck ,UGS )
k k k

Cuplink

f .m (5)

- Connexion rtPS :
ci,rtPS Cuplink CUGS CErtPS CrtPS CnrtPS (6)

bi , rtPS + f .ri,rtPS + (bk , rtPS + f .rk,rtPS ) + (bk , ErtPS + f .rk , ErtPS ) + (f .ck,UGS ) Cuplink

f .m (7)

Les conditions des connexions de rseau satellite DVB-S/RCS ne font rfrence quau dbit, on les exprime de la faon suivante : - Connexion CRA : ci,CRA Cforward CCRA CRBDC Connexion RBDC :

(8)

ci,RBDC Cforward CCRA CRBDC

(9)

5.

Evaluation de performance

Nous avons mis en place des simulations vnements discrets (QNAP2) pour valuer nos propositions. Comme prcdemment, les interarrives de nouvelles connexions (les nouveaux appels) suivent une loi exponentielle et la dure de connexion est exponentiellement distribue. Comme nous lavons indiqu dans le paragraphe prcdent, nous ne considrons quun type de trafic par classe. Nous avons choisi des dbits de trafic ErtPS (voix avec suppression de silence) plus faibles que pour rtPS (vido). Le Tableau 7 et Tableau 8 reprsentent les paramtres du modle de simulation ([72] [74] [76] [78] [79]). La tolrance de dlai de tout le trafic ErtPS est identique ; il en est de mme pour rtPS. Dans [76], la tolrance de dlai avait t prise alatoirement entre mmin et mmax. Nous supposons que la dure de la trame est 1ms dans le rseau WiMAX.

125

Paramtres WiMAX
Capacit de lien montant Cuplink Dbit de leaky bucket rErtPS Dbit de leaky bucket rrtPS f (dure de trame) Nombre des trames mrtPS Nombre des trames mErtPS Dure de connexion Taille de leaky bucket de ErtPS (kbit) Taille de leaky bucket de rtPS (kbit) Nombre de cellules WiMAX

Valeurs
20.8 Mbit/s 200 kbit/s 390 kbit/s 1 ms 30 trames 40 trames 200 s 0.2597 * b 0.5064 * b 3 cellules

Paramtres DVB-RCS
Capacit de voie de retour Cforward

Valeurs
2 Mbit/s

Dure de connexion

200 s

Nombre de spots satellite

Tableau 7 : Paramtres de modle de simulation

Le dbit de chaque connexion est montr dans le Tableau 8 (comme toutes les connexions dune classe donne ont les mmes caractristiques, on omet lindice du numro de la connexion) :
Dbits des connexions WiMAX (kbit/s)
cUGS 80 cErtPS 200 crtPS 390 cnrtPS 160

Dbits des connexions DVB-RCS (kbit/s)

cCRA 64 cRBDC 128

Tableau 8 : Dbits des diffrentes classes de service dans les deux rseaux

Nous avons dcid un peu arbitrairement que les dbits darrives des diffrents types de connexions taient identiques : UGS = ErtPS = ErtPS = nrtPS. On note = i le dbit
i

total des arrives de connexions. Enfin, notons que le temps de simulation dans le cas de CAC_WiMAX et le cas de CAC_WiMAX/DVB-RCS est de 10+6sec.

5.1. CAC dans WiMAX

Nous allons tout dabord nous intresser au cas WiMAX pur pour lequel nous allons faire varier la charge normalise. De faon, un peu attributaire, nous choisissons des dbits darrive des diffrents types de connexions. Dans un premier temps (Figure 75), nous prenons des tailles respectives de leaky buckets de (bErtPS = 0.2597*b = 7.791 kbit) et de (brtPS = 0.5064*b = 15.192 kbit) o la taille b est gale 30 kbit. Pour les trafics UGS, rtPS et ErtPS, deux conditions doivent tre respectes, on examine dabord la condition de dbit (BW) puis celle de dlai (Delay). Dans ce cas de figure, les connexions UGS, nont jamais t rejetes cause de la condition de dlai. Pour les connexions rtPS et ErtPS, nous avons reprsent deux courbes : lune reprsente le blocage d au dbit (BW) et lautre le blocage d au dlai (Delay). On constate laugmentation exponentielle des blocages de connexion avec la charge.

126 Dans un deuxime temps (Figure 76), nous avons fait varier la taille des leaky buckets (elles sont supposes propositionnelles au dbit en fait bErtPS = 0.2597*b, brtPS = 0.5064*b ; o b est le paramtre en abscisse qui varient de 10 kbit 100 kbit) pour une charge normalise N = 70 %. Nous navons pas reprsent que les blocages dus au dlai. On constate que plus les leaky buckets sont grands et plus les pertes seront sensibles. Remarquons que nous navons pas reprsent les autres critres de performances qui eux samlioreront dans la mesure o lon a choisi une politique de partage complet, llimination de connexions rtPS et ErtPS est favorable aux autres classes de trafic.

Figure 75 : Taux de blocage de CAC_WiMAX en fonction de la charge

127

Figure 76 : Taux de blocage de CAC_WiMAX en fonction de la taille de leaky bucket

5.2. CAC dans le cas dune interconnexion de rseaux WiMAX/DVBRCS

Dans un cadre dune interconnexion de rseaux WiMAX/DVB-RCS, de nombreux scnarios et stratgies peuvent tre considrs. Cependant, nous nallons tudier que quelques cas en laissant les autres comme perspectives. Notons que nous allons considrer que toutes les connexions dune classe ont le mme dbit (le dbit dune classe est fixe) et les mmes paramtres. Nous avons dcid de nouveau que les dbits darrives des diffrents types de connexions, qui sont envisags en priorit WiMAX, taient identiques : UGS = ErtPS = ErtPS = nrtPS. On note = i . En revanche, dans ce cas, la notion de charge normalise perd son sens.
i

Nous distinguons les cas suivants :

5.2.1. Stratgie 1 : Dbit adaptatif et remplacement complet et strict Dans la premire stratgie, nous considrons les quatre classes de trafic dans WiMAX (UGS, ErtPS, rtPS et nrtPS) et deux classes de trafic dans DVB-RCS (CRA et RBDC). Les trafics BE et VBDC ne donnent pas lieu des restrictions sur le CAC des autres connexions. A ltablissement de lappel, on vrifie si le dbit demand est

128 disponible dabord dans le systme WiMAX puis dans le systme DVB-RCS. Dans cette stratgie, on met en correspondance les classes UGS, ErtPS et rtPS dun ct avec la classe CRA de lautre. Dans ce cas, les changements de classe induisent une adaptation de lapplication et donc un changement de dbit sans affecter la dure de connexion. La classe nrtPS est mise en correspondance de son ct avec la classe RBDC. Cela correspond au trafic dit lastique pour lequel le changement de dbit induit une variation de la dure de la connexion. A chaque handover la connexion prend le dbit de la classe quivalente. Un fois quune connexion WiMAX est termine, on essaie de la remplacer par une connexion DVB-RCS de classe quivalente. Il sagit dune opration de down handover. La connexion satellite candidate doit vrifier les conditions suivantes de QoS dans le rseau WiMAX : il y a suffisamment de dbit disponible dans le rseau cible et, selon la classe, la connexion ne peut tre accepte que si le rseau peut lui offrir le dlai demand sans porter atteinte aux garanties des autres connexions en cours. Si une des ces conditions nest pas vrifi, la connexion WiMAX se termine et la connexion satellite candidate continue tre prise en charge par le systme DVB-RCS sans down handover. Concernant la procdure dup handover, cette procdure peut se produire uniquement dans le cas des nouveaux appels et par consquent le dclenchement est fait lorsque le nouvel appel nest pas accept par WiMAX. Notons que dans cette tude, nous supposons quune connexion UGS, rtPS ou ErtPS peut tolrer le dlai satellite CRA qui est constant. Cette stratgie est assez limitative pour le down handover, puisque la probabilit de trouver une connexion situe dans la mme cellule WiMAX de classe quivalente peut tre assez faible. Nanmoins, cette stratgie est la plus simple.
5.2.2. Stratgie 2 : Dbit non adaptatif et remplacement partiel (les connexions de type ErtPS et rtPS sont remplaces par des connexions de type RBDC) Cette stratgie est semblable la stratgie 1, mais lors dune fin dune connexion WiMAX cette dernire est remplace uniquement par une ou plusieurs connexions satellite non temps rel. Une fois que la connexion UGS est termine, elle ne est pas remplace par aucune connexion CRA. Avec les valeurs que nous avons considres, la fin dune connexion ErtPS ou nrtPS conduit chercher la remplacer par une seule connexion RBDC. La fin dune connexion rtPS permet de combler la place laisse par au plus trois connexions RBDC (Tableau 10). Les connexions sont acceptes si elles vrifient les conditions de QoS dans le rseau WiMAX. De plus, la connexion transfre garde son dbit lorsque elle passe vers le rseau cible (Tableau 9). Cela signifie qu un moment donn, le rseau satellite a deux classes de connexions CRA et RBDC. En revanche, le rseau WiMAX peut avoir quatre classes mais avec diffrents dbits concernant la classe nrtPS : ses quatre classes de trafic et une classe nrtPS (128 kbit/s). Lide sous-jacente cette stratgie est que si une connexion temps rel a accept dtre prise en charge par le satellite elle peut y rester.
cUGS (80 kbit/s) cCRA (64 kbit/s) cErtPS (200 kbit/s) cCRA (64 kbit/s) crtPS (390 kbit/s) cCRA (64 kbit/s) cnrtPS (160 kbit/s) cRBDC (128 kbit/s)

Tableau 9 : Connexions changes dans le sens montant lors de ltablissement de connexion (stratgie 2)

129
cUGS (80 kbit/s) x cErtPS (200 kbit/s) cRBDC (128 kbit/s) crtPS (390 kbit/s) 3*cRBDC (3*128= 384 kbit/s) cnrtPS (160 kbit/s) cRBDC (128 kbit/s)

Tableau 10 : Connexions changes dans le sens descendant lors du down handover (stratgie 2)

5.2.3. Stratgie 3 : Dbit non adaptatif et remplacement glouton Cette stratgie dite gloutonne permet de transfrer le nombre maximal des clients satellites. Elle est semblable la stratgie deux, cependant, cette stratgie permet de compenser une fin de connexion ErtPS par le transfert de trois connexions CRA (voir Tableau 11 et Tableau 12), au prix dune perte de 8 kbit/s. La fin dune connexion ErtPS pourrait permettre le transfert au maximum de trois connexions RBDC, au prix dune perte de 6 kbit/s.
cUGS (80 kbit/s) cCRA (64 kbit/s) cErtPS (200 kbit/s) cCRA (64 kbit/s) crtPS (390 kbit/s) cCRA (64 kbit/s) cnrtPS (160 kbit/s) cRBDC (128 kbit/s)

Tableau 11 : Connexions changes lors dun up handover (stratgie 3)

cUGS (80 kbit/s) x

cErtPS (200 kbit/s) crtPS (390 kbit/s) 3*cCRA (3*64=192 kbit/s) 3*cRBDC (3*128= 384 kbit/s)

cnrtPS (160 kbit/s) cRBDC (128 kbit/s)

Tableau 12 : Connexion changes lors dun down handover (stratgie 3)

Nous avons dcid de ne reprsenter les rsultats de simulations que pour cette dernire stratgie. En effet, la stratgie 1 est le plus souvent trop contraignante en terme de remplacement ; aucune connexion satellite ne peut remplacer la connexion WiMAX qui sachve. La seconde stratgie est certes justifie par largument voqu (une fois quune connexion contrainte temporellement a accept dtre prise en charge par le systme satellite, autant ly laisser) mais cela semble tout de mme surprenant de favoriser la latence de transferts de fichiers par rapport des flux vido. On a reprsent les diffrentes probabilits de blocage des connexions en fonction du dbit global darrive () (Figure 77 et Figure 78). Pour WiMAX, plusieurs causes peuvent survenir pour refuser une demande de connexion : une condition est mise sur le dbit disponible quand la connexion est demande et une deuxime condition porte sur le dlai maximum que peut accepter la connexion sans gner les autres. Au cours de notre simulation (le temps de simulation a t augment 10+6 s), nous avons constat que la condition sur le dbit tait la plus contraignante. Nous avons obtenu un blocage trs faible (de lordre 10-5) de connexion d un non respect de la contrainte de dlai. Les courbes correspondant au blocage des diffrentes classes WiMAX sont prfixes par BW pour faire rfrence au blocage d au manque de bande passante disponible. Cette distinction na pas lieu dtre pour le systme satellite comme nous lavons expos prcdemment. La courbe UHO blocking rate correspond aux nouveaux appels bloqus, quelle que soit leur classe ; avec le systme satellite.

130

Figure 77 : Taux de blocage des diffrentes classes de service avec le taux darrive (stratgie 3)

Les taux de blocage des connexions WiMAX croissent avec le dbit demand : on trouve donc que les taux de blocage sont les plus levs pour les connexions rtPS qui ont besoin du plus fort dbit, puis ces sont les connexions ErtPS et ainsi de suite. La deuxime remarque porte sur le taux de blocage de CRA. Celui-ci va tre fonction du dbit des connexions (UGS, ErtPS et rtPS) refuses par le rseau WiMAX. Par consquent, charge faible ou moyenne, lessentiel du trafic est pris en charge par WiMAX, peu de trafic dborde et il est alors trs largement pris en charge par le systme satellite. A plus forte charge, il faut regarder la fois le dbit des nouveaux appels que lon rejette de WiMAX mais aussi le trafic que lon peut faire redescendre dans WiMAX. Ce dernier crot rgulirement avec la charge, jusqu ce que lon arrive la saturation du rseau WiMAX. A partir de ce moment-l, le dbit que lon arrive faire redescendre du systme satellite naugmente plus. Cela est sans doute li galement au fait que le nombre de connexions pouvant tre prises en charge par DVB-RCS va se stabiliser saturation du systme. La probabilit de rejet des connexions par le systme satellite va crotre exponentiellement avec la diffrence entre ces deux dbits ce qui est traduit par la courbe de rejet de connexion CRA en fonction du taux darrive des demandes de connexion. Ce phnomne de croissance exponentielle est d en particulier au fait que comme les down handovers ne pourront pas tre effectus, la dure moyenne de prise en charge dune connexion par le systme satellite va augmenter avec laugmentation du dbit darrives des connexions.

131

Figure 78 : Dbits de diffrents handovers avec le taux darrive (stratgie 3)

6.

Conclusion

Nous avons prsent dans ce chapitre une approche fonde sur un CAC avec mutualisation des ressources entre le systme DVB-RCS et WiMAX, en tenant compte des contraintes de QoS de chaque classe de service. Diffrentes stratgies peuvent tre considres afin de permettre une coopration efficace entre les deux systmes. Nous avons analys les performances de la stratgie gloutonne qui nous semble tre la stratgie qui permet dutiliser les plus efficacement possible les ressources des deux systmes. Nous nous sommes concentrs, dans ce sens, une optimisation dun point de vue de loprateur. Nous navons pas considr dans ce travail le point de vue de lutilisateur.

CONCLUSION
Les rseaux sans fil ont connu ces dix dernires annes des dveloppements trs significatifs qui ont donn aux utilisateurs lillusion que leurs qualits pouvaient tre presque quivalentes celles des rseaux filaires. Ils ont pris lhabitude que leur nomadisme et/ou leur mobilit puissent tre pris en charge. En revanche, il apparat galement clairement quune seule solution technologique, quelle quelle soit, ne peut pas rpondre tous les contextes dutilisation. Si les couches hautes semblent converger autour du tout IP, des solutions assez fortement htrognes vont forcment tre amenes cohabiter au niveau des couches basses : cette htrognit portant la fois sur les instances de standardisation les rgissant, mais encore sur les techniques retenues au niveau des couches physiques (ces dernires tant probablement celles qui ont le plus volu ces dernires annes), des couches accs et de la prise en compte de la qualit de service. Les nouvelles gnrations de rseaux devront apporter rapidement des solutions exploitables pour offrir la compatibilit entre ces diffrents rseaux de faon ce que des utilisateurs puissent passer de manire transparente dun systme lautre. Notre point de vue est que lapproche la plus raisonnable est celle prconise par le groupe de travail IEEE 802.21 qui propose un cadre gnrique permettant de faire interagir ces systmes. Nous sommes conscients que les oprateurs de tlcommunications nont pas le temps dattendre une normalisation trop contraignante et quils ont prfr commencer par des solutions cousues main dans lesquelles on ralise linterconnexion de deux techniques spcifiques plutt que dattendre les rsultats dfinitifs du cadre IEEE 802.21. Nous sommes tout de mme optimistes et pensons que le cadre du 4G constitue un tournant dans linteroprabilit entre les rseaux. Dans cette thse, nous nous sommes intresss plusieurs aspects lis ces rseaux de 4me gnration. Le premier point porte sur larchitecture dun rseau couverture trs globale qui permettrait de prolonger la couverture dun rseau sans fil terrestre par une couverture satellitaire. Les rseaux par satellite ont connu ces dernires annes des volutions assez importantes en terme de dveloppement de standards de diffusion de tlvision autour des solutions DVB-S, DVB-S2 ou DVB-SH (pour les mobiles) mais aussi pour une utilisation dans un contexte bidirectionnel avec la standardisation dune voie retour, le DVB-RCS. En revanche, ce type de rseau na pas t jusque l pris en compte par le groupe de travail IEEE 802.21 qui sest focalis sur les rseaux IEEE (essentiellement WiFi et WiMAX) et sur les rseaux tlcoms 2G et 3G. Notre premire contribution a donc consist montrer comment la solution IEEE 802.21 pouvait tre dcline en terme darchitecture dans un contexte de systme satellite de type DVB-S/RCS. Notre deuxime contribution a consist proposer des scnarios dintgration dans lesquels nous avons droul les protocoles permettant de raliser les transferts entre les diffrents systmes. Ces deux contributions sont originales et constituent un travail pionnier. La suite de la thse sest plus focalise sur la prise en compte de la qualit de service dans des rseaux sans fil cellulaires le plus souvent htrognes. Notre rflexion est partie des mcanismes de rservation de ressources qui consistent essayer de pr-rserver

134 des ressources afin dviter des interruptions de communications lors de transferts intercellulaires. Si ce type de techniques a dj t largement tudi dans la littrature, une des spcificits de notre proposition repose sur la possibilit offerte par les rseaux WiMAX de fonctionner en mode maill (les terminaux dialoguent entre eux) ou avec infrastructure. Notre ide est alors que les mcanismes de rservation puissent tre mis en uvre par les stations de base entre elles ou bien par le biais dquipements relais se situant dans les zones de recouvrement entre les cellules avant que le terminal mobile sy retrouve luimme. Cette technique de base a t tout dabord applique un rseau uniquement WiMAX. Lobjectif tait dans cette premire tape de pouvoir bien comprendre les qualits intrinsques du mcanisme ; dans ce chapitre, nous navons dailleurs considr quun seul type de connexion. Nous avons montr que lutilisation de relais, pour effectuer les rservations la place dun nud mobile, se rvle judicieuse condition que la densit de nud soit suffisante. Dans le cas contraire, il vaut mieux se reporter des solutions plus classiques de rservations prises en charge directement par les quipements rseaux (stations de base). Ltape suivante a t de considrer un rseau htrogne compos par un rseau terrestre de type WiMAX recouvert par un satellite gostationnaire reposant sur le standard DVB-S/RCS. Nous avons commenc par nous replacer dans le scnario le plus vraisemblable du chapitre deux pour lequel, les solutions architecturelles et protocolaires que nous avons proposes prennent tout leur sens. Nous avons de nouveau procd par tapes en distinguant des solutions pour la prise de dcision de handover et pour la rservation de ressources, encore une fois dans un contexte o un seul type de connexion est retenu. Concernant le fonctionnement gnral du systme, il nous a sembl tout dabord prfrable que les utilisateurs soient pris en charge le plus souvent par le rseau WiMAX qui a une capacit beaucoup plus leve et conduit des dlais beaucoup plus faibles. Les nouvelles connexions sont donc envoyes prioritairement vers WiMAX et, en cas de surcharge, vers le systme satellite. Deux solutions ont alors t compares pour faire descendre les utilisateurs du systme satellitaire vers le rseau WiMAX : quand les utilisateurs changent de zone de couverture WiMAX et/ou ds que de la place se libre dans les cellules WiMAX. Il apparat alors que la solution o lon force trop dutilisateurs tre pris en charge par le rseau WiMAX conduit des performances densemble moins bonnes du point de vue des rejets de connexions et des interruptions de connexion lors dun transfert intercellulaire. Nous avons alors repris les stratgies du chapitre prcdent quant la rservation de ressources WiMAX. Il apparat que les techniques de rservation de ressources permettent damliorer lgrement les performances du systme. On sait classiquement que ces techniques de rservation favorisent les connexions en cours, cest ce que nous avons de nouveau observ. Le mcanisme forant les handovers conduit encore une fois des performances moins bonnes ; lassistance par des nuds voisins pour effectuer des rservations est plutt meilleure que la solution pilote par le rseau. Dans ces deux chapitres, nous avons analys un certain nombre de mcanismes dans un contexte o lon na quun seul type de connexion. Les rseaux considrs tant multiservices, nous nous sommes alors interrogs sur la mise en correspondance entre les classes

135 de services proposes dans les rseaux WiMAX et dans les rseaux DVB-RCS. Le problme peut se poser aussi bien dans le cas de terminaux possdant une double interface mais encore si lon veut mettre en place des passerelles entre les deux types de rseaux. WiMAX distingue cinq classes de service l o DVB-RCS en propose essentiellement trois. Il ne peut donc y avoir bijection. Une de nos contributions a donc t de proposer une mise en relation entre les classes de service dune part mais galement une correspondance entre les paramtres de ces diffrentes classes de service. Dans le dernier chapitre, nous nous sommes alors attachs regrouper lensemble de nos contributions, en nous interrogeant la fois sur la dfinition de nouvelles fonctions dadmission de connexion pour les deux types de systmes et sur limpact de laspect multi-service sur les solutions proposes pour raliser le mcanisme de transfert entre systmes. Nous avons donc repris et tendu des solutions dadmission de connexion permettant de traiter de faon diffrencie les connexions : pour certaines classes, les conditions dacceptation portent uniquement sur le dbit, pour dautres, on doit tenir compte galement du dlai Pour essayer de relcher quelques contraintes dans cette dernire tude, nous navons considr que des utilisateurs fixes, ce qui constitue tout de mme une solution reprsentative, le rseau satellite permettant alors de raliser du partage de charge. La question principale porte sur la faon avec laquelle on va procder quand on va vouloir procder des remplacements de connexions pour quilibrer la charge. On peut soit partitionner les ressources et ne remplacer une connexion qui se termine que par une connexion du mme type (on remplace un appel de VoIP WiMAX qui se termine par une communication VoIP prise en charge par le satellite), soit on autorise des recherches parmi toutes les connexions de la mme classe, soit encore on partage compltement les ressources en examinant toutes les connexions susceptibles de remplacer une connexion qui se termine. Dans ce dernier cas, plusieurs variantes sont encore envisageables : donner priorit au trafic le plus contraint temporellement, ou tout au contraire, se dire que si une connexion contrainte a accept dtre prise en charge par le satellite, autant ly laisser et au contraire descendre des connexions non contraintes temporellement pour lesquelles la prise en charge par WiMAX va permettre une augmentation de dbit et conduire une rduction de la dure de connexion. Nous navons implant quune seule solution, celle qui permet un partage des ressources entre les diffrents types de trafic. La raison principale est la suivante, la capacit du rseau satellite est trs faible par rapport au rseau WiMAX et par consquent, des conditions trop restrictives dans les remplacements des connexions conduisent le plus souvent ne trouver aucune connexion ligible. Les perspectives de ce travail sont assez nombreuses. Tout dabord les principes que nous avons propos pourraient tre enrichis en particulier ceux du dernier chapitre en testant des configurations varies tant en terme de cellules que de type de trafic. Cela dit, il est assez clair que lanalyse des rsultats est de plus en plus dlicate. Notre travail sest galement beaucoup focalis sur la performance rendue aux utilisateurs en terme dacceptation ou de refus de connexion, nous pourrions aussi tendre ces tudes en intgrant dautres types de critres lis par exemple au volume de signalisation ou bien encore la qualit de service ressentie dans le plan de donnes. On sait par exemple que des protocoles tels que TCP ragissent trs mal des volutions

136 brutales de dbit et de dlai qui sont justement des cas de figure que lon peut rencontrer dans des basculements de systmes cellulaires terrestres des systmes satellitaires. Une perspective intressante serait galement denrichir nos types de rseaux daccs : nous nous sommes focaliss sur une interconnexion WiMAX Satellite, nous pourrions galement intgrer dans nos tudes des rseaux WiFi ou 3G. Dans ce dernier cas, nous pensons que la dmarche propose dans notre thse est galement trs judicieuse en particulier en terme darchitecture et de protocole mais encore avec la mise en correspondance des services et des mcanismes dacceptation de connexion associs. Notons enfin, que nous ne nous sommes pas trop focaliss sur les fluctuations de la qualit des supports de communication qui sont dsormais relativement bien exploites au niveau de la couche physique, on pense en particulier aux mcanismes de modulation et de codages adaptatifs. En revanche, lexploitation de telles informations au niveau des fonctions dadmission de connexion, de rservation de ressources ou de transferts intercellulaires restent des dfis pour les prochaines annes. Il existe une littrature abondante sur les rseaux coopratifs. Mais les travaux sont essentiellement labors au niveau physique. Trs peu dentre eux tiennent compte dinteractions entre les diffrents niveaux. A notre connaissance aucun de ces travaux ne considre les problmes de coopration entre rseaux terrestre et systmes satellites (qui sont pourtant complmentaires), ni encore moins les besoins dapplications en terme de QoS. Nous pouvons ainsi enrichir les mcanismes que nous avons proposs, en tenant compte de coopration de niveau physique, en mettant en place une coordination plus efficace aux niveaux plus levs. Finalement, la concrtisation de nos travaux pourrait galement tre des propositions dintgration de nos solutions dans le cadre de la standardisation des rseaux mobiles de 4me gnration.

RFRENCES
[1] [2] [3] K-H. Li, PhD, IEEE 802.16e-2005 Air Interface Overview, WiMAX Solutions Division, Intel Mobility Group, Technical Report, 05 June, 2006. IEEE Standard for local and metropolitan area networks (802.16), 2004. H-H. Cho, D-H. Cho, TAKEOVER: A New Vertical Handover Concept for NetGeneration Heterogeneous Networks, Vehicular Technology Conference, 2005 VTC 2005-Spring 2005 IEEE 61st , page(s) : 2225-2229, 30-01 May. I. Smaoui, F. Zarai, L. Kamoun, Vertical handoff management for next generation heterogeneous networks, 2007. ICICT 2007. ITI 5th International Conference on, on page(s) : 19 25, 16-18 Dec. 2007. N. Kim; H. Choi; H. Yoon, Seamless Handoff Scheme for 4G Mobile Systems based on IP and OFDM, Vehicular Technology Conference, 2004. VTC2004-Fall. 2004 IEEE 60th, page(s) : 3315 - 3318 Vol. 5, 26-29 Sept. 2004. R. Corvaja, QoS Analysis in Overlay Bluetooth-WiFi Networks with Profile-Based Vertical Handover, Mobile Computing, IEEE Transactions on 2006, page(s) : 1679 1690, Dec. 2006. K. Sethom, H. Afifi, Requirements and Adaptation solutions for Transparent Handover between Wifi and Bluetooth, Communications, 2004 IEEE International Conference on, page(s) : 3916 3920, 20-24 June 2004. A. H. Zahran, B. Liang, Performance Evaluation Framework for Vertical Handoff Algorithms in Heterogeneous Networks, in Proceedings of the IEEE International Conference on Communications (ICC), Seoul, Korea, May 2005. B. Liang, A. Zahran, A. Saleh, Application Signal Threshold Adaptation for Vertical Handoff in Heterogeneous Wireless Networks, IFIP Networking 2005, Waterloo, Canada, May 2-6, 2005. A. H. Zahran, B. Liang, ALIVE-HO: Adaptive lifetime vertical handoff for heterogeneous wireless networks, Technical report, University of Toronto (2004). A. H. Zahran, B. Liang, A. Saleh, Signal threshold adaptation for vertical handoff in heterogeneous wireless networks Journal Springer Science, page (s) : 625-640, 22 May 2006. J. Nie; J.C. Wen; Q. Dong; Z. Zhou, A Seamless Handoff in IEEE 802.16a and IEEE 802.11n Hybrid Networks, page(s) : 383 - 387 Vol. 1, 27-30 May 2005. Q. Song, A. Jamalipour, A Network Selection Mechanism for Next Generation Networks, 2005, ICC 2005, 2005 IEEE, International Conference on Communications, page(s): 1418-1422, 16-20 May 2005. M. Li, K. Sandrasegaran, T. Tung, Trust-Assisted Handover Decision Algorithm in Hybrid Wireless Networks, Wireless Communications and Networking Conference, 2007.WCNC 2007. IEEE, page(s) : 3535 3540, 11-15 March 2007. H. Bing; C. He; L. Jiang, Performance Analysis of Vertical Handover in a UMTSWLAN Integrated Network, page(s):187 - 191 Vol.1, 7-10 Sept 2003. S. Aust, C. Grg and C. Pampu, Proactive Handover Decision for Mobile IP based on Link Layer Information, First IFIP International Conference on Wireless and Optical Communications Networks (WOCN 2004), Muscat, Oman, June 2004.

[4]

[5]

[6]

[7]

[8]

[9]

[10] [11]

[12] [13]

[14]

[15] [16]

138 [17] C. Yiping, Y. Yuhang, A New 4G Architecture Providing Multimode Terminals Always Best Connected Services, Wireless Communications, IEEE, page(s) : 36 41, April 2007. [18] V.E. Zafeiris, E. A Giakoumakis, An Agent-based Architecture for Handover Initiation and Decision in 4G networks, page(s): 72 77, 13-16 June 2005. [19] N. Akkari, S. Tohme, M. Doughan, Vertical-to-Horizontal Handovers: Architecture and Mobility Management, Wireless Communications and Networking Conference, 2007.WCNC 2007. IEEE, page(s) : 3867 3871, 11-15 March 2007. [20] Q. Nguyen-Vuong, L. Fiat, N. Agoulmine, An Architecture for UMTS-WIMAX Interworking, Broadband Convergence Networks BCN, page(s) : 1- 10, 07-07 April 2006. [21] A. Saleh, A Location-aided Decision algorithm for Handoff across Heterogeneous Wireless Overlay Networks, Masters thesis, Virginia Polytechnic Institute and State University, 2004. [22] M. Ylianttila, Vertical Handoff and Mobility - System Architecture and Transition Analysis, Doctoral thesis, Department of Electrical and Information Engineering, University of Oulu, Finland. ACTA Univ. Oul. C220, 2005. [23] S. Choi, G-H. Hwang, T. Kwon, A-R. Lim and D-H. Cho, Fast Handover Scheme for Real-Time Downlink Services in IEEE 802.16e BWA System, Vehicular Technology Conference (2005 IEEE 61st), page (s) : 2028-2032, June 2005. [24] D. H. Lee, K. Kyamakya, J. P. Umondi, Fast Handover Algorithm for IEEE 802.16e Broadband Wireless Access System, Wireless Pervasive Computing, 2006 1St International Symposium on, page (s) : 1-6, 16-18 Jan. 2006. [25] T. A. Yahiya, A-L. Beylot, G. Pujolle, Policy-Based Threshold for Bandwidth Reservation in WiMAX and WiFi Wireless Networks, Wireless and Mobile Communications, 2007. ICWMC '07. Third International Conference, page(s) : 7676, March 2007. [26] F. Tra, Contrle dAdmission des Connexions pour les Systmes de Tlcommunication par Satellite avec des Liaisons Physiques Adaptatives, Ecole Nationale Suprieure de lAronautique et de lEspace, Thse soutenue le 29 janvier 2008. [27] ETSI. DVB; EN 301 790 V1.4.1 (2005-09), Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems. [28] C. Baudoin, R. Dhaou, F. Arnal, M. Salhani, A-L. Beylot, Analyse dapplicabilit de standards de tlcoms terrestres aux systmes de tlcommunications par satellite, scnario 4G , Rapport de contrat, IRT-06-09-01, Institut National Polytechnique de Toulouse, Septembre 2006. [29] IEEE 802.21, DCN 2105-0240-01-0000Joint_Harmonized_MIH_Proposal_Draft_Text.doc, May, 2005. [30] Rapport : 284 23-3035 Uen Rev, A GENERIC ACCESS NETWORK, GAN (FORMER GAN), White Paper, Octobre 2006. http://www.ericsson.com/technology/whitepapers/3035_gan_a.pdf [31] J-Y. Baek, D-J. Kim, Y-J. Suh, E-S. Hwang, Y-D. Chung, Network-initiated Handover Based on IEEE 802.21 Framework for QoS Service Continuity in UMTS/802.16e Networks, IEEE Vehicular Technology Conference (VTC 2008), Marina Bay, Singapore, page(s): 2157-2161, 11-14, May 2008.

139 [32] http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem [33] Y-Y. An, B. H. Yae, K.-W. Lee, Y. Z. Cho, W. Y. Jung, Reduction of Handover Latency Using MIH Services in MIPv6, Advanced Information Networking and Applications (AINA), page(s) : 229-234, 18-20 April 2006. [34] Q. B. Mussabbir, W. Yao, Optimized FMIPv6 Handover using IEEE802.21 MIH Services, in Proceedings of the 1st ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture (MobiArch 2006). [35] Q. B. Mussabbir, W. Yao, Z. Niu, X. Fu, Optimized FMIPv6 using IEEE 802.21 MIH Services in Vehicular Networks, Vehicular Technology, IEEE Transactions on, Page (s) : 3397-3407, Nov. 2007. [36] W. Ying, Y. Jun, Z. Yun, L. Gen, Z. Ping, Vertical Handover Decision in An Enhanced Media Independent Handover Framework, Wireless Communications and Networking Conference IEEE WCNC 2008, page(s) : 2693-2698, 31 March-3 April 2008. [37] W. Ying, Z. Yun, Y. Jun, Z. Ping, An Enhanced Media Independent Handover Framework for Heterogeneous Networks, IEEE Vehicular Technology Conference (VTC 2008), Marina Bay, Singapore, page(s) : 2306-2310, 11-14, May 2008. [38] Y. C. Wang, H. F. Lo, Y. C. Li, W. T Lee, Seamless Handover with Buffer Prediction for Wireless Networks Based on IEEE 802.21, Information Networking, 2008. ICOIN 2008. International Conference on, page(s) : 1 5, 23-25 Jan. 2008. [39] M. Li, K. Sandrasegaran, T. Tung, Performance evaluation of a multi-interface model for media independent handover, Communications and Information Technologies, 2007. ISCIT '07. International Symposium on, page(s) : 735 738, 17 - 19 Oct. 2007. [40] M. Li, K. Sandrasegaran, T. Tung, A Multi-Interface Proposal for IEEE 802.21 Media Independent Handover, Management of Mobile Business, 2007. ICMB 2007. International Conference on the, page(s): 1 7, 9 - 11 July 2007. [41] W. Wei, L. Yihua, W. Jianbai, HIS: An Integrated Handover Scheme for Heterogeneous Wireless Networks in MIPv6, Networking and Services, 2007. ICNS. Third International Conference on, page(s): 55 55, 19 - 25 June 2007. [42] J-H. Seol, J-H. Chung, IEEE 802.21 MIH based Handover for Next Generation Mobile Communication Systems, Innovations in Information Technology, 2007. Innovations '07. 4th International Conference on, page(s): 431 435, 18 - 20 Nov. 2007. [43] T. Ali-Yahiya, K. Sethom, G. Pujolle, A Case Study: IEEE 802.21 Framework Design for Service Continuity across WLAN and WMAN, Wireless and Optical Communications Networks, 2007. WOCN '07. IFIP International Conference on, page(s) : 1 5, 2-4 July 2007. [44] S. Karapantazis, F.-N. Pavlidou, Dynamic Time-based handover management in LEO satellite systems, Electronics Letters, page(s): 57 - 58, March 2007. [45] M. Salhani, R. Dhaou and A-L. Beylot, Terrestrial Wireless Networks and Satellite Systems Convergence, AIAA International Communication Satellite System Conference (ICSSC 2007), page (s) : 3288, 10-13 April, 2007. [46] G. Santoro, A. Pietrabissa, F. Rodriguez, Telespazio; Linghang Fan, Z. Sun, C. Baudoin, Performance Evaluation of the Interconnection between DVB-RCS and WiMAX, AIAA ICSSC, page(s) : 3292, 10-13 April, 2007.

140 [47] M-H. Han, N-K. Lee, K-S. Han, D-J. Lee, Fast IP Handover between Satellite Networks and Wireless LAN Networks for high-speed Trains, International Workshop on IP Networking over Next-generation Satellite Systems (INNSS'07), http://www.mobilesummit2007.org/workshop_information. [48] M-H. Han, K-S. Han, D-J. Lee,Fast IP Handover Performance Improvements Using Performance Enhancing Proxys between Satellite Networks and Wireless LAN networks for High-Speed Trains, IEEE Vehicular Technology Conference (VTC 2008), Marina Bay, Singapore, page(s) : 2341-2344, 11-14, May 2008. [49] R. Qureshi, A. Dadej, Adding Support for Satellite Interfaces to 802.21 Media Independent Handover, Networks, 2007. ICON 2007. 15th IEEE International Conference on, page(s) : 542 546, 19-21 Nov. 2007. [50] C. Baudoin, R. Dhaou, F. Arnal, M. Salhani, A-L. Beylot, Analyse dapplicabilit de standards de tlcoms terrestres aux systmes de tlcommunications par satellite, Scnario 4G, rapport de contrat, IRT-06-09-01, Institut National Polytechnique de Toulouse, septembre 2006. [51] A. Dutta, S. Das, D. Famolari, Y. Ohba, K. Tanichi, T. Kodama, H. Schulzrinne, Seamless Handover across Heterogeneous Networks An IEEE 802.21 Centric Approach , IEEE WPMC 2005. [52] IEEE 802.21, Joined Harmonized Media Independent Handover Draft, May, 2005. Vatistas, G. H., Lin, S., Kwok, C. K., Reverse Flow Radius in Vortex Chambers, AIAA Journal, page(s) : 1872 1873, No. 11, 1986. [53] M. Salhani, R. Dhaou, A-L. Beylot, Performance of WiMAX Networks using Horizontal Handover with Channel Reservation Channel Mechanism, IEEE Vehicular Technology Conference, Marina Bay, Singapore, page(s) : 2272-2276, 1114 May 2008. [54] M. Salhani, R. Dhaou, A-L. Beylot, Performance of WiMAX Networks integrated in a Segment of Satellite using Channel Reservation Channel Mechanism, IEEE Vehicular Technology Conference, Marina Bay, Singapore, page(s): 2952 - 2956, 1114 May 2008. [55] Digital Video Broadcasting (DVB), Interaction channel for satellite distribution systems, ETSI EN 301 790 V1.4.1 (2005-09). [56] Digital Video Broadcasting (DVB), Interaction channel for Satellite Distribution Systems; Guidelines for the EN 301 790, ETSI Technical Report 101 790, (200609). [57] M. Costabile, C. Follino, A. lera, A. Molinaro, QoS differentiation in DVB-RCS multimedia platforms, Personal, Indoor and Mobile Radio Communications, 2004. PIMRC 2004. 15th IEEE International Symposium on, on page(s): 2357- 2361 Vol.4, 5-8 Sept. 2004. [58] O. Alphand, Architecture QoS pour Systmes Satellites DVB-S/RCS dans un contexte NGN, Thse prsente lINP de Toulouse, soutenue le 07.12.2005. [59] Livre sous la direction de Pierre Rolin, Rseaux ATM, HERMES SCIENCE PUBLISHING Ltd, en association avec le groupe LAVOISIER, Fvrier 2002. [60] IEEE Standard for Local and metropolitan area networks Part 16 : Air Interface for Fixed and Mobile Broadband Wireless Access Systems, IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Cor1-2005 (Amendment and Corrigendum to IEEE Std 802.16-2004), 28 February 2006.

141 [61] http://en.wikipedia.org/wiki/IEEE_802.16 [62] IEEE Standard for local and metropolitan area networks (802.16), 2004. [63] K. Gakhar, Ingnierie de la QoS sur une plaque radio mixte IEEE 802.16/IEEE 802.11e, Thse prsente lENST de Bretagne, soutenue le 27.09.2007. [64] B. Rong, Y. Qian, H-H. Chen, Adaptive power allocation and call admission control in multiservice WiMAX access networks, IEEE Wireless Communications, page(s) : 14-19, Feb. 2007. [65] B-J. Chang, Y-L. Chen, C-M. Chou, Adaptive Hierarchical Polling and Cost-Based Call Admission Control in IEEE 802.16 WiMAX Networks, Wireless Communications and Networking Conference, 2007.WCNC 2007. IEEE, page(s) : 1954 1958, 11-15 March 2007. [66] H. Wang, W. Li, D. P. Agrawal, Dynamic Admission Control and quality de service for 802.16 Wireless MAN, in Wireless Telecommunications Symposium, 2005, page(s) : 60 66, April 28-30, 2005. [67] D.-H. Cho, J.-H. Song, M.-S. Kim, K.-J. Han, Performance Analysis of the IEEE 802.16 Wireless Metropolitan Area Network, in First International Conference on Distributed Frameworks for Multimedia Applications, 2005, page(s): 130-136, 6-9 Feb. 2005. [68] O. Gusak, N. Oliver, K. Sohraby, Performance Evaluation of the 802.16 Medium Access Control Layer, Lecture Notes in Computer Science - Proceedings of ISCIS, vol. 3280, page(s) : 228237, 2004. [69] J. Chen, W. Jiao, H. Wang, A Service Flow Management Strategy for IEEE 802.16 Broadband Wireless Access Systems in TDD mode, in IEEE International Conference on Communications, vol. 5, page(s): 34223426, May 2005. [70] L. Huang, C. C. J. Kuo, Dynamic Call Admission Control with Joint Connectionlevel and Packet-level quality de service Support in Wireless Multimedia Networks, in IEEE Symposium on Real-Time and Embedded Technologies and Applications, May 2004. [71] A. Iera, A. Molinaro, S. Marano, Call Admission Control and Resource Management Issues for Real-time VBR Traffic in ATM-Satellite Networks, IEEE JSAC, Selected Areas in Communications, Wireless Series, page(s): 2393-2403, Nov. 2000. [72] P. Pace, G. Aloi, S. Marano, Multimedia Traffic Admission Schemes Comparison for Satellite Systems. Proceedings of the IEEE Vehicular Technology Conference (VTC Fall), Los Angeles - USA, page(s) : 4022-4026, 26-29 Sept. 2004. [73] P. Pace, G. Aloi, S. Marano, Efficient Real-Time Multimedia Connections Handling over DVB-RCS Satellite System. Proceedings of the IEEE Global Telecommunications Conference (GLOBECOM), Dallas Texas USA, pp. 27222727, 29 Nov.-3 Dec. 2004. [74] P. Pace, G. Aloi, S. Marano, A multilayered architecture supporting quality de service for multimedia traffic connections, Proceedings of the IEEE Vehicular Technology Conference (VTC Spring), Stockholm Sweden, page(s): 2702-2706, 30 May-1 June 2005. [75] F. De Rango, M. Tropea, P. Fazio, S. Marano, Call admission control with statistical multiplexing for aggregate MPEG traffic in a DVB-RCS satellite network, Global Telecommunications Conference, 2005. GLOBECOM '05. IEEE, Volume: 6, page(s):

142 6 pp., 28 Nov.-2 Dec. 2005. [76] K. Gakhar; M. Achir, A.Gravey, How Many Traffic Classes Do We Need In WiMAX ?, Wireless Communications and Networking Conference, 2007.WCNC 2007. IEEE, page(s):3703 3708, 11-15 March 2007. [77] K. Boussetta, Mthodes Numriques et Protocoles pour le Support du Multicast dans les Rseaux Fixes et Mobiles ; Thse de Doctorat, Universit de Versailles StQuentin-en-Yvelines, 2003. [78] H. Tallon, Haut dbit mobile : WiMAX et HSDPA, concurrence ou coexistence ? Technical report, NORTEL-TELECOM PARIS, 14 septembre 2006. [79] P. Pace, G. Aloi, Effective Admission Policy for Multimedia Traffic Connections over Satellite DVB-RCS Network, ETRI Journal, vol.28, no.5, page(s) : 593-606, Oct. 200

144

Rsum
Cette thse porte sur linteroprabilit et la qualit de service dans les rseaux de 4me gnration. En particulier, nous proposons des solutions dintgration entre le rseau WiMAX et le systme satellite DVB-RCS en sappuyant sur le standard IEEE 802.21. Trois solutions peuvent tre mises en place pour linterconnexion de rseaux sans fil. Il sagit de la technologie GAN soutenue par le 3GPP, du protocole FMIP propos par lIETF et du standard IEEE 802.21. Notre choix se porte sur ce denier standard car il propose un cadre gnrique pour linteroprabilit des rseaux. En fait, nous proposons une architecture satellitaire base de WiMAX, DVB-RCS et IEEE 802.21 et nous dcrivons aussi la procdure de handover WiMAX/DVB-RCS. Par ailleurs, nous amliorons les performances des rseaux WiMAX en utilisant un handover horizontal avec un mcanisme de rservation de ressources. Ensuite, le rseau WiMAX est intgr dans un systme satellite DVBRCS afin dtudier les performances de cette convergence avec une rservation de ressources. Les rsultats obtenus montrent que les mcanismes de rservation amliorent les performances. Afin de permettre au trafic de passer dun rseau lautre en garantissant une qualit de service, une mise en correspondance de la qualit de service entre les rseaux WiMAX et DVB-RCS est propose. En outre, nous proposons un mcanisme dadmission de connexion CAC dans le cadre de linterconnexion WiMAX/DVB-RCS. Plusieurs stratgies sont prises en compte afin de permettre une cooprative efficace entre les deux systmes.

Title
Modelling and Simulation of fourth Generation Mobile Wireless Networks

Abstract
This PH.D thesis is based on the interworking and the quality of service in 4th generation mobile wireless networks. In particular, we propose solutions of integration between WiMAX networks and satellite systems (DVB-RCS). Three solutions can be considered for the interconnection of wireless networks: GAN technology supported by the 3GPP, FMIP protocol suggested by the IETF and the IEEE 802.21 standard. Our choice is focused on this last standard because it proposes a generic framework for the interworking of wireless networks. A procedure of handover WiMAX/DVB-RCS is then described. In addition, we improve the performance of WiMAX networks by using a horizontal handover with resource reservation mechanisms. Then, the WiMAX network is integrated in a DVB-RCS satellite system. The performance of this convergence with a resource reservation mechanism is studied. The obtained results show that the reservation mechanisms improve the performance of the system. In order to switch the traffic from one network to the other by guaranteeing an appropriate level of quality of service, a mapping of quality of service between WiMAX networks and DVB-RCS system is proposed. Moreover, we propose a Connection Admission Control (CAC) mechanism within the framework of the WiMAX/DVB-RCS interconnection. Several strategies are taken into account in order to allow an effective co-operative between the two systems.

Discipline : Rseaux et Tlcommunications Mots-cls : WiMAX, DVB-RCS, architecture, QoS, rservation de ressources, mapping, CAC. Adresse du laboratoire :
IRIT-ENSEEIHT, 2 rue Charles Camichel, 31071, Toulouse Cedex 7, BP 7122, France