Vous êtes sur la page 1sur 156

- 1 - 1

Table des matires




Table des matires................................................................................................. 1
Table des figures ................................................................................................... 4
1 Chapitre I........................................................................................................ 7
Introduction........................................................................................................... 7
1.1 Introduction.................................................................................................................7
1.2 Le rseau dtude........................................................................................................8
1.2.1 Gnralits sur les satellites................................................................................8
1.2.2 Projet de constellation de satellites pour le multimdia .....................................9
1.3 Les principaux axes dtude .......................................................................................9
1.3.1 La fonction CAC.................................................................................................9
1.3.2 La couche MAC..................................................................................................9
1.3.3 La qualit de service .........................................................................................10
1.4 Objectifs de la thse..................................................................................................10
1.5 Description du contenu .............................................................................................11
2 Chapitre II .................................................................................................... 13
Aspects Technologiques et Protocolaires dans la Constellation de satellites..... 13
2.1 Introduction...............................................................................................................13
2.2 Architecture du rseau LEOS ...................................................................................14
2.3 Algorithmes CAC.....................................................................................................15
2.3.1 Etude gnrale...................................................................................................15
2.3.2 Etude en LEOS .................................................................................................16
2.4 Techniques MAC......................................................................................................17
2.4.1 FDMA...............................................................................................................17
2.4.2 TDMA...............................................................................................................17
2.4.3 CDMA ..............................................................................................................18
2.4.4 Aloha et ses variants .........................................................................................23
2.4.5 Comparaison des techniques daccs................................................................24
2.5 Efficacit des protocoles MAC dans les systmes LEO...........................................24
2.5.1 TDMA dans LEOS ...........................................................................................24
2.5.2 CDMA dans LEOS...........................................................................................25
2.5.3 CDMA/TDMA hybride dans LEOS.................................................................27
2.6 Qualit de service......................................................................................................28
2.6.1 QoS dans IP et ATM.........................................................................................28
2.6.2 QoS dans lUMTS ............................................................................................29
2.6.3 QoS dans les satellites: .....................................................................................30
2.7 Intgration dans le rseau terrestre ...........................................................................32
2.7.1 Rseau daccs en UMTS (UTRAN)................................................................32
2.7.2 Intgration du satellite dans lUMTS................................................................35
2.8 Conclusion ................................................................................................................36
3 Chapitre III ................................................................................................... 38
S-PRMA (Satellite-Packet Reservation Multiple Access) ................................. 38
- 2 - 2
3.1 Introduction...............................................................................................................38
3.2 PRMA.......................................................................................................................39
3.2.1 Sous-systme de voix........................................................................................40
3.2.2 Sous-systme de donne ...................................................................................41
3.3 Les services...............................................................................................................42
3.4 La fonction CAC.......................................................................................................43
3.5 Modlisation mathmatique......................................................................................43
3.5.1 Modle du PRMA.............................................................................................44
3.5.2 Modle du S-PRMA.........................................................................................45
3.6 Discussion analytique et par simulation ...................................................................51
3.6.1 Service RTC (utilisateurs voix) ........................................................................51
3.6.2 Service STC (sources data)...............................................................................53
3.6.3 Multiplexage de services (utilisateurs voix et data)..........................................54
3.7 Conclusion ................................................................................................................55
4 Chapitre IV................................................................................................... 57
S-CDMA (Satellite-Code Division Multiple Access) ........................................ 57
4.1 Introduction...............................................................................................................57
4.2 La technique CDMA.................................................................................................58
4.3 Le protocole S-CDMA..............................................................................................59
4.3.1 Sous-systme voix ............................................................................................60
4.3.2 Sous-systme de donne ...................................................................................61
4.4 Les services...............................................................................................................62
4.5 La fonction CAC.......................................................................................................63
4.6 Le contrle de trafic..................................................................................................64
4.7 Modlisation mathmatique......................................................................................65
4.7.1 Sous-systme voix ............................................................................................65
4.7.2 Sous-systme de data........................................................................................69
4.8 Discussions analytiques et par simulation ................................................................71
4.8.1 Le RTC (utilisateurs voix) ................................................................................71
4.8.2 Le STC (utilisateurs data) .................................................................................75
4.8.3 Multiplexage de services (utilisateurs voix et data)..........................................80
4.9 Conclusion ................................................................................................................83
5 Chapitre V.................................................................................................... 84
S-CDMA/PRMA (Satellite-Code Division Multiple Access/ Packet Reservation
Multiple Access) ................................................................................................. 84
5.1 Introduction...............................................................................................................84
5.2 La technique TD-CDMA..........................................................................................85
5.3 Le protocole S-CDMA/PRMA.................................................................................87
5.3.1 Sous-systme voix ............................................................................................88
5.3.2 Sous-systme data.............................................................................................89
5.4 Les services...............................................................................................................90
5.5 La fonction CAC.......................................................................................................91
5.6 Le contrle de trafic..................................................................................................91
5.7 Modlisation mathmatique......................................................................................92
5.7.1 Sous-systme de voix........................................................................................93
- 3 - 3
5.7.2 Sous-systme data.............................................................................................97
5.8 Discussions analytiques et par simulation ................................................................99
5.8.1 RTC (utilisateurs voix) .....................................................................................99
5.8.2 STC (utilisateurs data) ....................................................................................103
5.8.3 ITC (utilisateurs web) .....................................................................................105
5.8.4 Multiplexage de services RTC, ITC et STC (voix, web et data) ....................107
5.9 Conclusion ..............................................................................................................110
6 Chapitre VI................................................................................................. 111
Comparaison des protocoles daccs et des stratgies dallocation de
ressources....................................................................................................... 111
6.1 Introduction.............................................................................................................111
6.2 Comparaison des protocoles ...................................................................................112
6.2.1 Utilisateurs voix..............................................................................................112
6.2.2 Utilisateurs data ..............................................................................................113
6.2.3 Multiplexage de services ................................................................................114
6.3 Allocation de ressources .........................................................................................115
6.3.1 Allocation de ressources dans la littrature ....................................................115
6.3.2 Allocation de ressources en S-CDMA............................................................118
6.3.3 Allocation de ressources en S-CDMA/PRMA...............................................125
6.4 Conclusion ..............................................................................................................135
7 Chapitre VII ............................................................................................... 136
Conclusion ........................................................................................................ 136
Ouvertures :.........................................................................................................................137
8 Rfrences : ................................................................................................ 139
9 Publications ................................................................................................ 144
10 Appendice A : Modle de simulation ........................................................ 145

- 4 - 4
Table des figures

Figure 1.1 Constellation des satellites IRIDIUM.......................................................................8
Figure 2.1 Architecture de la constellation des satellites..........................................................14
Figure 2.2 Effet de hand-off sur la fonction CAC....................................................................16
Figure 2.3 Technique d'accs FDMA.......................................................................................17
Figure 2.4 Technique d'accs TDMA.......................................................................................18
Figure 2.5 Technique d'accs CDMA.......................................................................................18
Figure 2.6 Description du CDMA............................................................................................19
Figure 2.7 Dfinition du processus d'talement........................................................................20
Figure 2.8 Dfinition du processus de dtalement....................................................................20
Figure 2. 9 Rsum de la technique CDMA.............................................................................21
Figure 2. 10 Gnration des codes orthogonaux.......................................................................21
Figure 2.11 Allocation de la bande passante en WCDMA dans l'espace Temps-Frq.-Code..23
Figure 2.12 Relation entre l'talement et le srambling .............................................................23
Figure 2.13 Canal d'accs dans IRIDIUM................................................................................25
Figure 2.14 Canal CDMA/TDMA hybride...............................................................................27
Figure 2. 15 Architecture de la QoS dans UMTS.....................................................................29
Figure 2.16 IP sur ATM dans la communication par satellite..................................................31
Figure 2.17 Couverture en UMTS............................................................................................32
Figure 2.18 Rseau d'accs UTRAN........................................................................................33
Figure 2.19 Vue en couche de l'interface radio de l'UTRAN...................................................34
Figure 2.20 Encapsulation des paquets arrivant du rseau coeur .............................................34
Figure 2.21 Handover en UMTS et S-UMTS...........................................................................36
Figure 3.1 Modle de source voix ............................................................................................40
Figure 3.2 Modle de source data.............................................................................................41
Figure 3.3 Modle de PRMA terrestre......................................................................................44
Figure 3.4 Modle de PRMA satellite (utilisateurs voix) .........................................................45
Figure 3.5 Stabilit de PRMA terrestre et satellite ...................................................................47
Figure 3.6 Modle de PRMA satellite (utilisateurs data) .........................................................50
Figure 3.7 Probabilit de perte vs. nombre dutilisateurs .........................................................51
Figure 3.8 Probabilit de non perte vs. nombre dutilisateurs ..................................................51
Figure 3.9 Comparaison de S-PRMA et T-PRMA...................................................................52
Figure 3.10 Dlai de paquet vs. nombre dutilisateurs .............................................................53
Figure 3.11 Probabilit de perte voix et dlai d'attente data (utilisateurs voix et data) ............54
Figure 4.1 Graphe reprsentatif du CDMA..............................................................................59
Figure 4.2 Source de trafic Email .............................................................................................61
Figure 4.3 Fonction de permission pour data ...........................................................................64
Figure 4.4 Modle des utilisateurs voix....................................................................................66
Figure 4.5 Modle des utilisateurs data ....................................................................................69
Figure 4.6 Distribution des utilisateurs voix en cas de f1(x) analytique ..................................73
Figure 4.7 Distribution des utilisateurs voix en cas de f2(x) analytique ..................................73
Figure 4.8 Distribution des utilisateurs voix en cas de f1(x) , simulation ................................74
Figure 4.9 Distribution des utilisateurs voix en cas de f2(x), simulation .................................74
Figure 4.10 Probabilit de perte, analyse et simulation............................................................75
Figure 4.11 Fonctions de permission pour data........................................................................76
- 5 - 5
Figure 4.12 Distribution des utilisateurs data en cas de f1(x), analyse ....................................77
Figure 4.13 Distribution des utilisateurs data en cas de f2(x), analyse ....................................77
Figure 4.14 Distribution des utilisateurs data en cas de f1(x) et f2(x), simulation...................78
Figure 4.15 Probabilit de perte (transfert des fichiers), analyse et simulation........................79
Figure 4.16 Dlai d'attente (transfert des fichiers), analyse et simulation................................79
Figure 4.17 Probabilit de perte (Email), simulation................................................................80
Figure 4.18 Dlai d'attente (Email), simulation........................................................................80
Figure 4.19 Perte des paquets voix en fonction de nombre dutilisateurs data.........................82
Figure 4.20 Perte des paquets data en fonction de nombre dutilisateurs data.........................82
Figure 4.21 Dlai des paquets data en fonction de nombre dutilisateurs data.........................82
Figure 5.1 Technique CDMA/TDMA......................................................................................85
Figure 5.2 La probabilit de perte pour diffrents spreading factor .........................................87
Figure 5.3 Le protocole S-CDMA/PRMA................................................................................87
Figure 5.4 Source de trafic web................................................................................................89
Figure 5.5 Fonctions de permission..........................................................................................92
Figure 5.6 Modle de canal (utilisateurs voix) .........................................................................94
Figure 5.7 Processus d'accs.....................................................................................................95
Figure 5.8 Modle de canal (utilisateurs data)..........................................................................98
Figure 5.9 Fonctions de permissions et spreading factors ......................................................101
Figure 5.10 Les fonctions de permissions tudies ................................................................101
Figure 5.11 La distribution des utilisateurs ............................................................................102
Figure 5.12 La probabilit de perte pour les utilisateurs voix ................................................102
Figure 5.13 Fonctions de permission (utilisateurs data) .........................................................103
Figure 5.14 Distribution des utilisateurs (utilisateurs data) ....................................................104
Figure 5.15 Probabilit de perte (utilisateurs data).................................................................104
Figure 5.16 dlai d'attente (utilisateurs data) ..........................................................................105
Figure 5.17 Fonctions de permission (sources web)...............................................................106
Figure 5.18 Probabilit de perte (sources web) ......................................................................106
Figure 5.19 dlai d'attente (sources web)................................................................................107
Figure 5.20 Fonctions de permission en multiplexage de service ..........................................108
Figure 5.21 Probabilit de perte en multiplexage de service (voix, web et data) ...................108
Figure 5.22 Dlai d'attente en multiplexage des service (web et data)...................................109
Figure 5.23 Distribution des utilisateurs en multiplexage de service .....................................109
Figure 6.1 Dlai d'attente des paquets data pour les diffrents protocoles d'accs.................114
Figure 6.2 Allocation de ressources en TDMA avec frontires variables ..............................116
Figure 6.3 Stratgie d'allocation de ressources en CDMA et TD-CDMA..............................117
Figure 6.4 Allocation de ressources en TDMA/CDMA entre les paquets synch. et asynch. .118
Figure 6.5 Allocation de ressources en S-CDMA..................................................................119
Figure 6.6 Frontires fixes en S-CDMA.................................................................................119
Figure 6.7 Fonctions de permission pour l'allocation de ressources fixe ...............................120
Figure 6.8 Allocation dynamique en S-CDMA......................................................................121
Figure 6.9 Fonctions d'accs en allocation fixe et en allocation dynamique haute charge..122
Figure 6.10 Fonctions de permission en allocation dynamique basse charge......................123
Figure 6.11 Dlai d'attente des paquets data et web en fonction des sources data .................124
Figure 6.12 Perte des paquets voix et data en fonction de nombre des sources data..............125
Figure 6.13 Allocation de ressources en S-CDMA/PRMA....................................................125
- 6 - 6
Figure 6.14 Cas de sparation des utilisateurs voix et web ....................................................127
Figure 6.15 Cas de multiplexage des voix et web ..................................................................128
Figure 6.16 quatre slots pour les utilisateurs data...................................................................129
Figure 6.17 Multiplexage des sources voix et data.................................................................130
Figure 6.18 Multiplexage de data et de web...........................................................................131
Figure 6.19 Allocation de ressources en S-CDMA/PRMA....................................................132
Figure 6.20 Stratgie d'allocation sans frontire.....................................................................133
Figure 6.21 Stratgie d'allocation avec frontire134
- 7 - 7









1.1 Introduction
Pendant les dernires annes, le rseau cellulaire est devenu accessible presque partout. Pour
complter ce rseau cellulaire terrestre, plusieurs systmes bass sur des satellites basse
orbite (LEO Low Earth Orbit) et moyenne orbite (MEO Medium Earth Orbit) ont t
dvelopps pour offrir une couverture globale. Les services multimdias sont largement
demands sur une chelle globale.
Le rseau de tlcommunication mobile international (UMTS Universal Mobile
Telecommunication System) est devenu rcemment le sujet de nombreuses tudes. Le but de
lUMTS est de permettre lintgration de services (voix et donne) dans la rgion couverte.
Un des besoins est de concevoir un schma de contrle du rseau afin daccommoder les
diffrents dbits et qualits de services (QoS). En particulier, la voix, qui est une application
temps rel, ncessite une limite en dlai et en probabilit de perte. Par contre, les applications
donnes peuvent supporter un dlai lev.
Un des objectifs majeurs de ETSI (European Telecommunications Standards Istitute) est
lintgration de lUMTS avec le composant satellitaire. Ceci pour raliser plusieurs buts :
Permettre un roaming global des utilisateurs UMTS.
Produire une qualit de service globale un prix acceptable.
Acclrer le dveloppement de lUMTS sur plusieurs rgions, surtout dans les pays en
voie de dveloppement.
Le projet constellation des satellites pour le multimdia [3] consiste offrir diffrents services
aux abonns fixes ou mobiles par le biais des rseaux de satellites LEO ou MEO. Cependant,
les caractristiques de tels rseaux satellitaires posent des problmes particuliers du fait de la
mobilit des satellites. Ainsi, le problme du mouvement de satellite n'a pas les mmes
contraintes que celles du monde des radio-mobiles. Le dlai de transmission est plus lev, ce
qui ncessite d'tudier et de valider des nouveaux mcanismes daccs et de contrle. Dans
notre thse, on va tudier le contrle dadmission, le problme daccs au canal et la qualit
de service dans le cas de LEO. Cet tude est dans le contexte du projet constellation de
satellites pour le multimdia ainsi que la partie satellitaire de lUMTS (S-UMTS).
- 8 - 8
1.2 Le rseau dtude
1.2.1 Gnralits sur les satellites
Depuis les annes 80 les satellites GEO ont dmontr leur efficacit pou les
tlcommunications. Ctait avec le lancement de la premire gnration des systmes
satellitaires de tlcommunications mobiles (INMARSAT) en 1982. Malgr lintrt des
systmes GEO pour les communications maritimes, ils ne sont pas adapts aux systmes de
communications personnels qui ncessitent des terminaux lgers et petits. Do la ncessit
des systmes orbites basses comme les satellites LEO. Deux types de satellites LEO ont t
proposs petit-LEO pour les applications faible dbit et grand-LEO pour les
applications haut dbit. Plusieurs systmes sont proposs, par exemple IRIDIUM,
GLOBALSTAR, SKYBRIDGE
La constellation IRIDIUM est prsente dans la figure 1.1. Dans cette constellation, on a 66
satellites qui sont lis entre eux pour former un rseau spatial complet. On dfinit plusieurs
termes pour dcrire une constellation :
Les orbites :
Cest le chemin parcouru par un satellite qui tourne autour de la terre. Une orbite contient
plusieurs satellites qui tournent sur la mme boucle. La hauteur dune orbite est en relation
avec la zone couverte par le satellite qui y appartient.

Figure 1.1 Constellation de satellites IRIDIUM
Les liens inter-satellites :
Les ISL (Inter Satellite Link) peuvent relier les diffrents satellites afin de raliser un rseau
spatial. Ces liaisons ne sont pas obligatoires ; IRIDIUM utilise ces liens pour relier chaque
satellite avec deux satellites de son orbite et deux satellites des orbites voisines.
Spot beams :
La zone couverte par un satellite est le foot-print. Cette zone peut tre dcompose en
plusieurs surfaces, appeles cellules, par des antennes multi-faisceaux. Ces antennes sont
appeles antennes spot beam multiple.
Le Hand-off :
Quand un utilisateur passe dune cellule une autre, un processus de hand-off est lanc. Dans
les systmes terrestres, les stations de base sont fixes et cest lutilisateur qui se dplace dune
cellule une autre. En LEOS, les satellites et les utilisateurs se dplacent, mais puisquun
satellite a une vitesse beaucoup plus grande que la vitesse dun utilisateur, on peut considrer
que les terminaux sont fixes et on peut donc prvoir les hand-off causs par le dplacement
des satellites. En fait, il y a deux types de hand-off ; inter-satellite (entre deux satellites
diffrents) et intra-satellite (entre deux spots du mme satellite). Du point de vue du
dplacement des cellules, on dfinit deux types de constellations :
- 9 - 9
1. Cellules fixes aux satellites, et donc se dplaant par rapport la terre.
2. Cellules fixes la terre, et donc se dplaant par rapport aux satellites.
Effet Doppler :
Cest le dcalage entre les frquences mise et reue d la vitesse relative de lmetteur et
du rcepteur. Si un satellite se dplace une vitesse donne, et envoie sur une frquence f, un
utilisateur en arrire du satellite reoit une frquence f df et un autre utilisateur en avant
reoit une frquence f + df. Le dcalage frquentiel est en relation avec llvation de lorbite,
la distance entre metteur et rcepteur, la vitesse du champ magntique du signal.
1.2.2 Projet de constellation de satellites pour le multimdia
La constellation est compose de 72 satellites en orbite LEO, rpartis sur 9 plans et avec un
terme de phase de 1 (72/9/1). Laltitude des satellites est 1603km et leur priode 118.5
minutes. Linclinaison des orbites est de 50 [3]. Llvation minimale est denviron 17.5, la
zone couverte par un satellite cette lvation ayant un diamtre denviron 5100km.
Le systme sappuie du cot du segment sol sur trois types de terminaux utilisateurs : les
terminaux pitons, vhicules et TGV pour faible, grande et trs grande vitesse,
respectivement. Outre les terminaux utilisateur, le systme est constitu au minimum
denviron 20 stations de connexion au rseau (G/W) en bande Ka qui permettent de relier le
rseau satellite aux infrastructures terrestres mais galement prennent en charge une partie des
fonctions du rseau comme le routage et lallocation de ressources.
Les satellites sont relis entre eux par des ISL 60 Ghz. Ces ISL au nombre de 4, permettent
un satellite dtre reli aux deux satellites adjacents de son plan et aux deux satellites des
plans voisins un dbit de 2155 Mb/s bi-directionnel.
1.3 Les principaux axes dtude
Dans cette section, on va introduire les principaux axes quon va laborer tout au long de cette
thse. Ces sujets sont traits pour tre utiliss dune faon efficace dans le contexte des
satellites LEO.
1.3.1 La fonction CAC
La fonction de contrle dadmission CAC (Connection Admission Control) a pour objet de
rejeter ou daccepter une demande de connexion en fonction du comportement futur de la
connexion et de la qualit de service demande. Si le centre de gestion estime quil ne pourra
pas garantir la qualit demande ou si cette nouvelle connexion risque de perturber les
connexions courantes, la demande est rejete. Si la demande est accepte et si une QoS stricte
est garantir, les ressources sont alors rserves sur toutes les entits constituant le chemin de
la connexion. Pour le faire, le CAC aura accs aux paramtres de la qualit de service
contenus dans le contrat liant lutilisateur au rseau.
1.3.2 La couche MAC
Le rle de la sous-couche MAC (Medium Access Control) est principalement de grer le
problme du conflit daccs lorsquun mme mdium de communication est partag par de
multiples systmes. La stratgie communment adopte consiste tout dabord simplifier ce
problme en faisant en sorte que les conflits ne se produisent pas lchelle dun bit de
donne mais plutt lchelle dun ensemble de bits. Pour cela, le MAC impose chaque
- 10 - 10
systme expditeur de regrouper les donnes quil transmet en paquet de bits. De plus, les
systmes de transmission ntant que rarement suffisamment synchrones, ces paquets doivent
gnralement tre dlimits par des squences de bits de contrle aisment reconnaissables.
Lensemble rsultant est appel une trame. Outre le data reu de la couche suprieure, cette
trame incorpore un certain nombre de bits de contrle et de gestion : description de
lexpditeur et du ou des destinataires de la trame, sommes de contrle, etc.
Paralllement cette structuration en trames, le MAC doit aussi grer le problme du conflit
proprement dit. Ce problme est gnralement rsolu en deux tapes. La premire consiste
choisir une technique de base afin disoler le trafic gnr par diffrentes stations. Cette
technique de base est gnralement appele technique daccs. Comme ces techniques ne sont
gnralement pas suffisantes, il convient ensuite dtablir la politique daccs aux ressources
de communication. Cette politique est gnralement appele schma daccs. Lensemble de
ces deux aspects est le protocole daccs.
1.3.3 La qualit de service
La QoS est leffet global produit par les caractristiques dun service fourni un usager qui
dterminent le degr de satisfaction que cet usager retire du service. La qualit dun service
est caractrise par leffet conjugu des notions suivantes : logistique, facilit dutilisation,
faisabilit, intgrit et dautres facteurs propres chaque service. Lexpression qualit de
service ne dsigne pas un degr dexcellence dans un sens comparatif, pas plus quelle nest
prendre dans un sens quantitatif aux fins dvaluation techniques. La notion QoS utilise
plusieurs paramtres qui sont communs dans tout contexte. Les principaux paramtres sont :
Taux derreur.
Taux de perte.
Dlai de transfert.
Gigue (variation du dlai de transfert).
Au niveau de la couche MAC, on parle de la notion des MTC (MAC Transfer Capabilities)
qui sont les classes de services au niveau MAC. Ces MTCs doivent supporter les diffrents
services dfinis sur les couches suprieures comme la couche rseau [16].
1.4 Objectifs de la thse
Notre but est de dvelopper une couche daccs MAC au canal satellitaire tout en respectant
les contraintes de la constellation LEO. Un grand nombre dutilisateurs de diffrents types
vont essayer daccder au canal satellite (sens montant) afin denvoyer leurs paquets. Il faut
distribuer les ressources disponibles entre les diffrents utilisateurs de faon respecter la
QoS de chaque utilisateur et minimiser le gaspillage. Nous avons trait dans cette thse les
ponts suivants :
Nous avons adopt les techniques CDMA (Code Division Multiple Access) et TDMA
(Time Division Multiple Access) pour dfinir les protocoles daccs proposs en
systme LEOS. Ces techniques sont adaptes afin dtre utilises dune manire
efficace dans le cas spcifique de satellites LEO (long RTD (Round Trip Delay),
Handover, ).
Nous avons utilis un contrle dadmission pour les diffrents types de services qui
agit au niveau dappel afin daccepter un maximum dutilisateurs de diffrents types
- 11 - 11
tout en respectant la QoS de chacun. Ce contrle utilise une fonction capacit
quivalente adapte aux diffrents contextes de nos tudes.
Nous avons dfini des services au niveau MAC dune faon gnrique. Les services
sont supports au niveau MAC par des MTCs (MAC Transfer Capabilities) afin de
garantir la QoS demande par chaque service. Nous avons propos des MTCs qui
supportent tous les services et applications possibles.
Nous avons tudi le systme pour des utilisateurs htrognes ce qui rend
lintgration de services ncessaire. La comparaison dpend de lintgration et de la
QoS de chaque utilisateur. Le but est toujours de maximiser la capacit totale du
systme.
Nous avons tudi le multiplexage de services et lallocation de ressources pour les
diffrents protocoles daccs. Des techniques dordonnancement et de partage de
ressources sont proposes afin datteindre pour un protocole daccs donn la
performance maximale.
1.5 Description du contenu
Dans cette thse, on va tudier la fonction CAC et la couche MAC pour une constellation de
satellites LEO (Low Earth Orbit). La thse comporte 7 chapitres.
Dans le deuxime chapitre, on introduit les aspects technologiques et protocolaires quon va
utiliser tout au long de la thse. Larchitecture de constellation est prise dun projet national
franais. La fonction CAC dans le contexte satellite est introduite ainsi que les diffrentes
techniques daccs au canal. La technique CDMA (Code Division Multiple Access) est
explique en dtail puisquon va dvelopper cette technique pour proposer nos diffrents
protocoles. Des propositions dans la littrature utilisant les diffrentes techniques sont ensuite
prsentes avec leurs spcificits. Le problme de la QoS est ensuite prsent puisque les
protocoles quon va proposer sont orients qualit de service. Le problme dintgration du
rseau spatial dans le rseau international mobile est introduit, o plusieurs stratgies
dintgration sont tudies dans la littrature. Aprs cette prsentation gnrale des problmes
lis notre tude, on passe au cur de notre recherche.
Dans le 3
me
chapitre, on propose une amlioration du protocole PRMA (Packet Reservation
Multiple Access) et le nouveau protocole est appel S-PRMA (Satellite-PRMA). On dfinit
les services au niveau MAC utiliss dans ce chapitre et la fonction de contrle dadmission
correspondante. La QoS est traite au niveau des MTCs qui assurent une qualit demande
par les diffrents services. Le systme est divis en deux sous-systme ; voix et data. Un
modle mathmatique est dvelopp pour le protocole S-PRMA afin de dterminer les
paramtres essentiels de la QoS pour les sources voix et data. Des calculs mathmatiques et
par simulation sont ensuite raliss afin doptimiser les diffrents paramtres du protocole.
Dans le 4
me
chapitre, on propose un protocole utilisant la technique daccs CDMA. Ce
protocole adapt au contexte satellite est nomm S-CDMA. Les services supports au niveau
MAC sont ensuite expliqus ainsi quune fonction de contrle dadmission. Le systme est
divis en deux sous-systme ; voix et data. Un modle mathmatique pour les deux sous-
systmes voix et data est dvelopp, ce qui permet de trouver les diffrents paramtres de la
QoS. Le calcul et la simulation dterminent les valeurs optimales de ces paramtres dans les
diffrents cas du systme. Ces rsultats servent aussi valider notre modle mathmatique
dvelopp.
- 12 - 12
Dans le 5
me
chapitre, on tudie le protocole CDMA/PRMA dans le contexte de satellite. Pour
ladapter ce contexte, ce protocole a besoin des changements dans la conception daccs et
de rservation ainsi que dans les paramtres daccs. Le nouveau protocole est nomm S-
CDMA/PRMA. Trois MTCs sont intgrs dans la couche MAC ce qui ncessite une fonction
de contrle dadmission plus complique ainsi quun protocole daccs avanc. Le systme
est divis en deux sous-systme ; voix et data. Le dveloppement mathmatique du protocole
dans les deux sous-systmes ncessite la mlange des deux thories utilises dans les deux
chapitres prcdents. Les paramtres optimiser ne sont pas que les paramtres du protocole
dans ce cas. Les paramtres du canal jouent un rle crucial. Le calcul mathmatique et la
simulation dterminent les valeurs optimales des diffrents paramtres pour les diffrents
types de service. Les rsultats obtenus valident aussi notre tude mathmatique et les
simplifications faites pour pouvoir analyser le protocole.
Le 6
me
chapitre compare les diffrents protocoles introduits dans le cas le plus gnral du
systme. On tudie dans ce chapitre le problme dallocation de ressources pour les
protocoles S-CDMA et S-CDMA/PRMA. Des stratgies statiques et dynamiques sont vises
afin de profiter de la flexibilit de la capacit en CDMA.
Le 7
me
chapitre donne les principaux conclusions de cette tude ainsi que des ouvertures
des sujets de recherche futurs.
- 13 - 13









2.1 Introduction
Plusieurs organisations ont propos les communications personnelles bases satellite pour
fournir une couverture globale pour la voix et les donnes en ralisant une liaison directe entre
le terminal et le satellite. Un tel systme offre des communications personnelles presque
partout dans le monde, mme dans les zones dsertiques et ocaniques. Les GEOS
(Geostationary Earth Orbit Satellites 35784km daltitude) taient utiliss pour raliser des
communications trs longues distances. Malgr les avantages des GEOS en couverture et
facilit, ce nest pas la bonne approche pour les communications personnelles ou mobiles. Les
LEOS (Low Earth Orbit Satellites 500-2000 km daltitude) ou MEOS (Medium Earth Orbit
Satellites 10000-12000 km daltitude) [1] paraissent mieux adapts cette situation,
essentiellement pour deux raisons :
Lattnuation due la propagation est faible, ce qui permet dutiliser des terminaux
faible puissance.
Le dlai de transmission est de lordre de 10ms pour les LEOS et 250ms pour les
GEOS, ce qui permet lutilisation des applications temps rel en LEOS avec une
meilleure performance.
Mais il faut noter que la dure de vie dun satellite LEO est infrieure celle dun GEO, et
que la complexit due au fait quun LEOS se dplace par rapport un utilisateur terrestre
augmente leffet doppler et ncessite lintgration des techniques de compensation et de hand-
off [1].
Le problme daccs au canal est crucial et plusieurs techniques ont t proposs pour les
LEOS. La technique CDMA (Code Division Multiple Access) est utilise par plusieurs
systme (Skybridge, Globalstar) alors quune technique FDMA/TDMA (Frequency Division
Multiple Access / Time Division Multiple Access) hybride soit utilise par le systme
IRIDIUM. La raison pour laquelle le CDMA est utilis pour les LEOS va tre traite tout au
long de cette thse.
Dans le paragraphe suivant, on prsente larchitecture de constellation utilise dans cette
thse. Le paragraphe trois introduit la fonction de contrle dadmission CAC. Le paragraphe
quatre dcrit les diffrentes techniques daccs. Les applications de ces techniques dans le
satellite LEO sont prsentes dans les paragraphes 5, 6 et 7. Le paragraphe huit introduit le
- 14 - 14
problme de la QoS. Le paragraphe 9 dcrit lintgration du satellite dans le systme UMTS.
Enfin, le dixime paragraphe conclut le chapitre.
2.2 Architecture du rseau LEOS
Le rseau est constitu dun ensemble des satellites en orbite basse qui constituent avec
quelques stations de base un systme de communication global et accessible de tout point sur
la terre. Les satellites peuvent tre relis entre eux travers des ISL. Ces ISL, au nombre de 4,
permettent un satellite dtre reli aux deux satellites adjacents de son plan et aux 2 satellites
des plans voisins (1 satellite sur chaque plan adjacent droite et gauche). Ceci est le cas du
systme IRIDIUM ainsi que la proposition faite par la CNES pour le projet RNRT [3]. Pour
des autres systmes comme Skybridge, on nutilise pas des ISL. Notons que des stations
terrestres nomms GateWay G/W peuvent servir plusieurs fonctions comme relier le rseau
satellitaire dautres rseaux terrestres [2]. Larchitecture gnrale du systme est reprsente
dans la figure 2.1.


Liaisons intersatellites si
existent

Accs G/W Accs utilisateur
G/W

Figure 2.1 Architecture de la constellation de satellites
Plusieurs paramtres darchitecture peuvent tre tudis pour une constellation. Ltude de
ces paramtres ne constitue pas un objet de notre thse. On va se contenter de les citer
brivement :
1 Nombre de satellites.
2 Nombre de plans orbitaux.
3 Inclinaison de plans orbitaux.
4 Espacement relatif de plans orbitaux.
5 Nombre de satellites dans chaque plan orbital.
6 Dphasage relatif de satellites dans le mme plan orbital.
7 Dphasage relatif de satellites dans deux plans orbitaux voisins.
8 Altitude de plans orbitaux.
- 15 - 15
Pour raliser un maximum de capacit et de couverture, plusieurs satellites sont utiliss.
Dautre part pour maximiser lutilisation de la bande passante une technique de spot-
beams est ralise par les antennes satellitaires. Lunit de couverture sur terre est le
spot similaire une cellule pour le rseau cellulaire terrestre [3]. A la diffrence que le
spot se dplace par rapport la terre sil est fix au satellite et par rapport au satellite sil est
fix la terre.
Dans le cas dutilisateurs multiples, le problme daccs est essentiel. Les techniques
principales daccs au canal sont :
1. FDMA (Frequency Division Multiple Access) ou accs multiple rpartition de
frquence.
2. TDMA (Time Division Multiple Access) ou accs multiple rpartition de temps.
3. CDMA (code Division Multiple Access) ou accs multiple rpartition de code.
4. Les techniques daccs alatoire surtout Aloha et Aloha en tranches.
Ces techniques traitent la partage de ressources entre les diffrents utilisateurs accepts dans
le systme, ce qui reprsente le contrle au niveau des paquets. Lacceptation des utilisateurs
est effectue par la fonction de contrle dadmission CAC (Connexion Admission Control),
cest le contrle au niveau de lappel.
2.3 Algorithmes CAC
2.3.1 Etude gnrale
Le CAC est plus ou moins compliqu suivant le type de service support. Dans le cas o ce
CAC serait seulement pour de services dbit maximal garanti, comme le service
tlphonique, la fonction CAC est trs simple. Il suffit daccepter un utilisateur dans le cas o
la bande passante libre dans le rseau serait suprieure la bande passante demande par ce
service et de le refuser dans le cas contraire. On dfinit ce stade une probabilit de blocage
qui est la probabilit quune demande de connexion soit refuse.
Dans le cas o on accepterait une probabilit de perte et un dlai dattente pour les paquets, un
multiplexage statistique peut se faire pour augmenter lefficacit du rseau et pour mieux
utiliser la bande passante. A ce stade, on dfinit une probabilit de perte maximale respecter.
On peut dmontrer dans ce cas que le nombre dutilisateurs accepts est beaucoup plus lev
que dans le cas classique qui ne prend en compte quun dbit maximal garanti [6].
Dans le cas o plusieurs services partageraient la bande passante, la fonction CAC doit
prendre en compte la qualit de service demande par chaque service. Et une fonction CAC
peut tre dfinie pour chaque type de service. En particulier, les diffrents services sont
spars lintrieur dune trame par des frontires qui peuvent tre dynamiques et les limites
acceptes pour les diffrents services varient dans le temps. On dfinit la notion de priode de
contrle qui est la priode pendant laquelle les frontires ne bougent pas.
En fait, plusieurs algorithmes CAC sont proposs pour le contrle dadmission. Chaque
algorithme est adapt un type de trafic. Ainsi, on utilise un algorithme suivant le type de
service.
Il est vident que les services qui demandent un dbit maximal sont associs un algorithme
CAC simple. Le problme se pose dans le cas de services dbit variable. On peut trouver
plusieurs algorithmes. Soit :

- 16 - 16
1. Capacit quivalente. Cest un dbit associ une source de telle faon que, si on suppose
que cette source met ce dbit, la probabilit de perte reste infrieure une valeur . Ce
dbit peut tre infrieur ou gal au dbit crte.
2. Approximation trafic fort. Dans ce cas, on accepte un tel utilisateur si la probabilit que le
dlai dattente dun message envoy par cet utilisateur soit suprieur une valeur, est
petite.
Beaucoup dautres algorithmes sont prsents dans [8]. On remarque que ces algorithmes
dpendent, toujours, du modle de trafic source et de la QoS demande.
2.3.2 Etude en LEOS
En satellite LEO, le hand-off est un facteur qui influence la fonction CAC. En effet, un
utilisateur accept par le systme exige une qualit de service qui doit tre garantie dans les
diffrentes cellules. Quand lutilisateur passe dune cellule une autre cause de hand-off, le
service fourni par le systme doit continuer avec la mme qualit. Ceci exige de ressources
disponibles la fois dans la cellule courante et dans les cellules futures. Quand le service
demand est temps rel, lexigence est plus stricte et une rservation est ncessaire dans
plusieurs cellules voisines. Ceci a pour effet de gaspiller les ressources puisquelles sont
rserves pour des utilisations futures. Plusieurs tudes sont effectues pour dfinir une
stratgie qui garantit la QoS sans gaspillage de ressources.
Dans [31] on prend en compte le problme de hand-off en dfinissant des services avec hand-
off garanti appels GH (Garanteed Handover). Pour ces services, le contrle dadmission doit
prendre en compte cet aspect. Dans cet article, on simplifie le problme en supposant que
toutes les cellules sont pareilles et ont une forme rectangulaire et que les handover sont dus
seulement au mouvement des satellites.
sens de satellite




utilisateur (GH) accept si
des ressources sont disponibles
dans les cellules i et i+1

Cellule i cellule i+1 cellule i+2
.

Figure 2.2 Effet de hand-off sur la fonction CAC
Dans ce cas simplifi, il suffit que le contrle dadmission se fasse sur la cellule en cours et la
prochaine cellule. Si on a des ressources dans ces deux cellules on accepte la demande. Par la
suite, on rserve dans la cellule i+2 au moment dentrer de la cellule i+1. Ceci permet un
service GH. La dmonstration de cette garantie est dans [31]. Un tel service cote cher en
terme de ressources utilises. Sa tarification doit tre leve. Dans [32], on trouve un
algorithme plus gnral pour garantir le handover avec un contrle dadmission associ.
On remarque ce stade que la rsolution de problme de handover est faite pour un seul type
de service qui est totalement garanti. Les services non-temps rel nacceptent pas de payer
une telle tarification. Une fonction CAC plus souple est ncessaire.
- 17 - 17
2.4 Techniques MAC
Dans cette section, on va parler brivement des techniques principales daccs au canal. Ces
techniques de base peuvent servir pour dfinir ensuite les protocoles daccs quon va
proposer dans cette thse.
2.4.1 FDMA
La bande passante est divise en sous bandes ; chaque sous bande est associe une
frquence porteuse utilise par un metteur. Cet metteur doit envoyer continment sur une
frquence particulire et le canal est lensemble des diffrentes frquences porteuses venant
des diffrents metteurs. Le rcepteur choisit la porteuse approprie pour ainsi lire les
donnes qui leur sont destines. Le FDMA nest pas essentiellement utilis dans LEOS mais
il reprsente une partie daccs puisque dans toute technique daccs, la bande passante est
partage en des sous-bandes o on utilise une rpartition de temps ou de code [4]. La figure
2.3 montre clairement cette technique.

frquence


frquence
f1 fn
temps
frquence
f1
temps

f2
temps
frquence


fn

temps
satellite

Figure 2.3 Technique d'accs FDMA

2.4.2 TDMA
Dans cette technique, la bande passante est utilise par tous les utilisateurs mais la division se
fait sur laxe de temps. Chaque utilisateur envoie sur un intervalle de temps et en utilisant
toute la bande passante. Les donnes envoyes par chaque utilisateur sont groupes en rafales
pour tre envoys sur des intervalles de temps appels slots. Le canal se comporte donc
comme la succession des slots remplis par des rafales venant des diffrents utilisateurs. Si la
dure dun slot est T
s
le canal peut contenir n slots ; on appelle trame lensemble des n slots
du canal. La dure dune trame est alors de T
f
= n T
s
. La figure 2.4 reprsente la technique
daccs TDMA. Le rcepteur doit identifier chaque paquet dans un slot afin de lire les
informations qui lui sont destines [4]. Ceci ncessite des informations didentification du
dbut dun paquet ainsi quune synchronisation.
- 18 - 18
frquence


frquence
t1
temps
frquence

t1 tn temps
Tf
t2
temps
frquence


tn

temps
Ts
satellite

Figure 2.4 Technique d'accs TDMA
2.4.3 CDMA
Dans cette technique, chaque utilisateur transmet ses informations sur le canal continment et
en utilisant toute la bande passante. Ceci veut dire quil y a interfrence entre les diffrents
utilisateurs, mais chaque utilisateur envoie sa propre signature avec ses informations. Cette
signature est appele code (dsign par p
i
) et elle est combine avec les informations utiles
avant de tout transmettre. Un metteur choisit son propre code dun ensemble des codes
caractriss par les proprits suivantes :
Chaque code doit tre facilement distingu de sa rptition dans le temps.
Chaque code doit tre facilement distingu des autres codes utiliss dans le rseau.
Les diffrents codes sont pseudo-orthogonaux et donc p
i
p
j
0 i j.
code

frquence code

c1
temps
code frquence

frquence t1 tn temps

c2
temps
code


cn frquence

temps
Ts
satellite

Figure 2.5 Technique d'accs CDMA
Un rcepteur doit pouvoir dcoder les informations utiles qui lui sont destins et les sparer
des interfrences produites par les autres utilisateurs [4]. On distingue deux types de CDMA :
Squence directe (DS Direct Sequence).
Saut de frquence (FH Frequency Hopping).
Dans cette thse, on traite seulement la technique de squence directe DS-CDMA. Si le
message binaire m(t) a un dbit binaire R
b
cod en NRZ (Non Return to Zero), alors m(t) = t
1. Le code p(t) doit tre cod en NRZ aussi et constitue une squence de chips avec un dbit
R
c
>> R
b
. Le mot chip est utilis pour reprsenter les bits du code par opposition aux bits
binaires dans le message. Le message et le code sont multiplis et on obtient une squence
NRZ envoyer sur une frquence porteuse
c
qui est la frquence des chips (figure 2.5), ce
- 19 - 19
qui donne le signal c(t) = m(t)p(t)cos(
c
t). Tous les autres utilisateurs envoient leurs messages
m
i
(t) sur cette frquence mais en utilisant des autres codes p
i
(t), soit c
i
(t) = m
i
(t) p
i
(t)cos(
c
t).
Un tel rcepteur recueille la somme de tous ces signaux soit :
( ) ( ) ( ) ( ) ( ) ( ) ( )

+
i
c i i c
t t p t m t t p t m t r cos cos (2.1)
En multipliant cette somme par 2cos(
c
t), on obtient :
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( )

+
+ + +
i i
c i i i i
c c
i
c i i c c
t t p t m t p t m
t t p t m t p t m t t t p t m t t t p t m t x


2 cos
2 cos cos 2 cos cos 2 cos
(2.2)


m(t)


p(t)



m(t)p(t)



p(t)


m(t)

Figure 2.6 Description du CDMA
En filtrant les hautes frquences puis en multipliant par le code p(t) le rcepteur rcupre le
message qui lui est destin (figure 2.6).

+
i
i i
t m t p t p t m t p t p t m ) ( ) ( ) ( ) ( ) ( ) ( ) ( (2.3)
Puisque les codes sont pseudo-orthogonaux, le message est reu avec de linterfrence venant
des autres utilisateurs, mais de trs faible nergie. En effet, la multiplication des autres
messages par deux diffrents codes avec faible corrlation tale ces messages deux fois et
affaiblit leurs nergies normment autour de la bande passante du message m(t).
En rsum, le CDMA, qui est actuellement employ dans de nombreux systmes de
communication, permet un grand nombre d'utilisateurs d'utiliser la mme onde porteuse sans
interfrer les uns les autres. Il consiste rpartir l'information radiolectrique mise sur une
bande de frquences plus large que celle rellement ncessaire la transmission du signal
utile. Ce dernier apparat alors comme un bruit et sa densit spectrale est constante sur
l'intgralit de la bande occupe.
Il s'agit de multiplier au sens mathmatique du terme (OU exclusif) chaque bit transmettre
par un code pseudo-alatoire PN (Pseudo random Noise code) propre chaque utilisateur. La
squence du code (constitue de sf lments appels "chips") est unique pour un utilisateur
donn, et constitue la clef de codage ; elle est conserve si le symbole de donne valait 1,
inverse sinon. On appelle facteur d'talement SF (Spreading Factor) la longueur sf du code.
- 20 - 20
Si chaque symbole a une dure Tb, on a 1 chip toutes les Tb/sf secondes. Le nouveau signal
modul a un dbit sf fois plus grand que le signal initialement envoy par l'usager et utilisera
donc une bande de frquences sf fois plus tendue. La relation entre les dbits initial et final
est donc :
Dbit Chip = Dbit Bit * SF
Ainsi plus SF est grand, plus le dbit chip (de l'ordre de 3.84 Mcp/s pour le WCDMA utilis
en UMTS) est grand, et plus le dbit de donnes du canal sera lev. Cela permet de dgager
des canaux dbits variables selon les besoins des utilisateurs (bandwidth on demand).
La figure 2.7 rsume le processus de transmission en CDMA.



Figure 2.7 Dfinition du processus d'talement
Pour rcuprer l'information, le rcepteur doit effectuer la mme opration : il gnre la mme
squence d'talement et la multiplie par le signal reu ; les donnes codes par cette squence
sont restaures (puissance spectrale augmente) alors que les donnes des autres utilisateurs
restent tals et les brouilleurs dus au canal sont tals, non corrls au signal utile. Ceci
permet de diminuer le niveau de bruit pour le signal en bande de base : plus l'talement est
important, plus les interfrences sont limines (figure 2.8).

Figure 2.8 Dfinition du processus de dtalement
Comme on le voit, lors du dcodage, la synchronisation est trs importante ; elle s'effectue en
deux tapes. Tout d'abord, on ralise la fonction de corrlation entre les deux signaux ; elle
prsente un maximum (pic de corrlation) lorsque les deux signaux se ressemblent, donc sont
en synchronisme. Ensuite, on maintient cette synchronisation par une boucle de verrouillage
- 21 - 21
de retard. Lorsque le calage est ralis, on peut dmoduler le signal par l'intermdiaire d'un
dmodulateur diffrentiel. La figure 2.9 rsume la technique CDMA.
Les codes d'talement
Pour viter toute interfrence avec les codes des diffrents utilisateurs et diffrencier des
canaux distincts, on se sert de code orthogonaux appels codes CDMA OVSF (Orthogonal
Variable Spreading Factor Code). L'utilisation de ces codes permet de modifier le facteur
d'talement et de maintenir l'orthogonalit des diffrents codes d'talement mme si ces
derniers sont de longueur diffrente.
Ils viennent d'une famille de codes orthogonaux au sens de la corrlation. Ils peuvent tre
dfinis par un arbre gnrateur tel qu'une racine engendre 2 branches. Les codes ports par ces
deux branches sont issus du code de la racine. En effet, le code d'une branche est compos par
le code de la racine et de son complmentaire. Ce principe permet ainsi de gnrer l'arbre des
codes OVSF utiliss pour UMTS, aussi regroups sous la forme de la matrice de Hadamard
(figure 2.10) [51, 52, 53].

Figure 2. 9 Rsum de la technique CDMA

Figure 2. 10 Gnration des codes orthogonaux
- 22 - 22
De plus, le facteur k, qui dtermine le nombre de bits dans les trames des canaux ddis au
transfert de donnes, vrifie la relation suivante :
SF = 256/ 2
k
(avec k de 0 6 )
Cela signifie que SF peut prendre les valeurs : 4, 8, 16, 32, 64, 128, 256. Cet arbre montre la
relation directe entre nombre de codes disponibles pour un talement donn et le facteur
d'talement. En effet, le facteur SF dtermine simultanment la longueur du code mais
galement le nombre de codes disponibles pour un talement SF.
Lutilisation de codes orthogonaux limite la flexibilit de la technique CDMA et ncessite un
assignement prcis des codes aux diffrents utilisateurs. Pour cette raison, des codes PN
(Pseudo-noise) qui sont presque orthogonaux (quasi-orthogonaux) peuvent tre utiliss. Le
nombre de codes disponibles est illimit et la flexibilit par rapport au dbit variable est
leve. Les besoins de synchronisation sont dans ce cas moins exigeants.
Une des variantes importantes du CDMA, utilise en UMTS, est le WCDMA. Cette technique
daccs augmente lefficacit du CDMA comme on va le dmontrer dans le paragraphe
suivant.
2.4.3.1 WCDMA
Le WCDMA se base largement sur le CDMA, utilisant une bande passante plus large, ce qui
permet d'accrotre le dbit total de transmission. Pour optimiser les ressources radio, il
propose deux modes de fonctionnement, selon le type de multiplexage. De plus, outre
l'talement (channelisation), le WCDMA applique une autre opration essentielle, le
brouillage (scrambling), que nous verrons par la suite. Enfin, de nouvelles solutions utilisant
le domaine spatial (antennes adaptatives) sont l'tude pour amliorer la rception des
signaux.
Les multiplexages
Deux modes de multiplexage sont utiliss :
Le FDD-WCDMA (Frequency Division Duplex) qui utilise en UMTS deux bandes
passantes de 5 Mhz, l'une pour le sens montant (uplink), l'autre pour le sens
descendant (downlink). Le dbit maximal support par un seul code est de 384 kbit/s.
Pour les services haut dbit, plusieurs codes sont ncessaires pour supporter un dbit
de 2 Mbit/s.
Le TDD-WCDMA (Time Division Duplex) n'utilise qu'une bande passante de 5 Mhz
divise en intervalles (time slot) ; elle est utilise pour les deux sens. Elle comprend
donc une composante AMRT (Accs Multiple Rpartition dans le Temps) fonde sur
la trame GSM (qui fait appel au TDMA) en plus de la sparation par code. Ce concept
offre une large gamme de dbits de service en allouant plusieurs codes ou plusieurs
intervalles de temps un utilisateur (figure 2.11). Le dbit de 2 Mbit/s peut galement
tre obtenu, mais des raisons techniques et complexes (dues par exemple au
dplacement ou au dphasage) limitent le bon fonctionnement de ce systme aux
btiments ou aux petites cellules.
Dans un premier temps, ces deux modes ont t dvelopps sans souci d'harmonisation, mais
suite la dcision de l'ETSI, ils devront cohabiter dans un mme terminal et dans un mme
service afin de couvrir l'ensemble des services prvus par l'UMTS.

- 23 - 23


Figure 2.11 Allocation de la bande passante en WCDMA dans lespace Temps-Frquence-Code
Le scrambling
Cette opration effectue par l'metteur permet de sparer les diffrents signaux d'un mme
terminal ou d'une mme station de base. Ralise juste aprs l'talement, elle ne modifie pas
la bande passante ni le dbit ; elle se limite sparer les diffrents signaux les uns des autres.
Ainsi, l'talement peut-tre effectu par plusieurs metteurs avec le mme code de
channelisation sans compromettre la dtection des signaux par le rcepteur. Le scrambling fait
appel aux codes de Gold qui sont une combinaison linaire de plusieurs m-squences. Notons
qu'il existe un arbre de codes de channelisation pour chaque code de scrambling. Cela signifie
que diffrents metteurs peuvent utiliser leurs arbres de codes indpendamment.


Figure 2.12 Relation entre l'talement et le srambling
2.4.4 Aloha et ses variantes
LAloha est une mthode daccs alatoire pour laccs au canal de transmission. Une
mthode daccs est vue sur un autre niveau quune technique daccs (FDMA, TDMA,
CDMA) mais on va la prsenter au mme niveau pour insister sur son intrt dans
lamlioration de performance. Une source utilise le canal seulement en cas de besoin, donc
quand elle a des informations envoyer. La source attend ensuite la rponse du destinataire
pour signaler une mauvaise ou bonne rception. Cette technique est adapte au cas dun grand
nombre dutilisateurs qui sont souvent inactifs. Dans le cas o plusieurs sources tenteraient
denvoyer en mme temps, une collision est provoque et les paquets en collision sont perdus,
- 24 - 24
ce qui ncessite une retransmission. Dans les rseaux satellitaires, cette technique peut tre
utilise pour la demande de ressources, et donc au niveau du plan de control. Les
inconvnients majeurs de cette technique sont linstabilit et le bas dbit utile (18%) [5].
Laloha en tranches donne une meilleure performance, puisque les transmetteurs sont
synchroniss par une discrtisation du temps. Dans le cas du rseau terrestre la dure dun slot
est le temps aller-retour RTD (Round Trip Delay) maximal entre deux points du rseau. Les
stations sont synchronises et connaissent le dbut dun slot. Une station ne peut mettre
quau dbut dun slot. On atteint par cette technique un dbit de 36%. Plusieurs variantes
dAloha ont t tudies :
Aloha avec rsolution de contention.
Aloha avec coute de porteuse.
Aloha avec dtection de collisions.
Aloha avec rsolution de collisions.
2.4.5 Comparaison des techniques daccs
Une premire comparaison des diffrentes techniques prsente des avantages du CDMA par
rapport aux autres techniques, surtout dans le contexte satellitaire :
CDMA prsente plus de robustesse aux phnomnes dattnuations par des
multichemins et interfrence.
CDMA permet un gain de multiplexage statistique par rapport aux TDMA et FDMA
o le nombre dutilisateurs est limit en avance soit par des contraintes temporelles ou
frquentielles. Par contre, en CDMA, une augmentation dutilisateurs gnre une plus
grande interfrence et par suite une lgre dgradation de la QoS. Cest la notion de
graceful degradation .
CDMA permet une meilleure utilisation spatiale, car lattnuation des signaux dun
faisceau voisin doit tre 2 3dB pour CDMA, compar 18dB pour TDMA ou
FDMA.
On peut transmettre plus dinformation avec la mme nergie en utilisant le fait quau
cours dune partie du temps, certains sources restent silencieuses. En effet, le dbit que
chaque source peut transmettre une puissance donne est une fonction du rapport
signal sur bruit, o la transmission dautres sources est prise en compte dans le bruit.
Une source peut donc profiter du silence des autres sources [5].
2.5 Efficacit des protocoles MAC dans les systmes LEO
2.5.1 TDMA dans LEOS
Comme application du TDMA dans LEOS, on va dcrire brivement lexemple de la
constellation IRIDIUM [9] qui utilise cette technique. La bande passante disponible est
1616.0-1626.5 MHz qui est divise en sous bandes de 31.5KHz spares par des bandes de
garde. Dans chaque sous bande, des trames TDMA de 90ms sont transmises avec un dbit de
50Kb/s pour former 4 liens montants et 4 liens descendants. Le multiplexage est donc
temporel TDM (Time Division Multiplexing). Le canal est prsent dans la figure 2.13.
La rutilisation de frquence ncessite une dcomposition cellulaire par des antennes multi-
faisceaux, le facteur de rutilisation de frquence en IRIDIUM est de sept comme dans le cas
de GSM [10].
- 25 - 25
Le taux dutilisation en TDMA peut tre facilement valu par :


i
f i T t / 1 (2.4)
o t
i
est la somme des portions de temps non utiliss comme les temps de gardes ou les
enttes.


UL = Up Link (lien montant)
DL = Down Link (lien descendant)
0.1ms temps de garde 0.28ms temps de garde





90ms
22.48ms UL1 UL2 UL3 UL4 DL1 DL2 DL3 DL4
temps de garde

Figure 2.13 Canal d'accs dans IRIDIUM
2.5.2 CDMA dans LEOS
Lutilisation de la technique CDMA dans les systmes LEOS prsente des avantages
majeurs ; la raison principale est que la bande passante, plus large cause dtalement du
spectre, permet une diversit frquentielle qui attnue linterfrence due au multi-chemin. En
plus, en CDMA la mme frquence est utilise dans les cellules voisines et donc un utilisateur
na pas besoin de changer de frquence chaque fois quil passe une nouvelle cellule, ce qui
est trs frquent en constellation LEO. En plus, en CDMA, lintgration des deux modes
circuit et paquet ne ncessite pas un protocole spcial puisque les deux modes se ressemblent
en terme daccs et de transmission. Ceci permet dintgrer de services voix et donnes
facilement. De la mme faon, laccs alatoire en CDMA est facile intgrer dune manire
non corrle. En effet, le nombre total de codes est toujours suprieur au nombre maximal de
codes utiliss simultanment et on peut la limite assigner un code chaque utilisateur
accept par la fonction de contrle dadmission. Ce code est utilis par lutilisateur
uniquement quand il a des paquets envoyer. Ce principe est trs important et va tre
largement utilis dans notre thse. Dautre part, la notion de collision est diffrente en
CDMA, puisque plusieurs utilisateurs peuvent envoyer en mme temps sur des codes
diffrents. Les informations ne sont pas perdues dans ce cas mais le niveau dinterfrence
slve et la probabilit de perte augmente. Laccs alatoire en CDMA est appel Aloha tal
ou CDMA Aloha [6].
Dans [7], Viterbi a calcul lefficacit spectrale du CDMA comme fonction du rapport signal
sur bruit. On va rsumer les rsultats de ces tudes puis les appliquer au satellite LEO afin de
montrer lintrt du CDMA dans la constellation de satellites orbites basses.
Dans un systme accs multiple o M utilisateurs envoient sur un canal, la puissance totale
reue est :
C = ME
b
R
b
avec E
b
est lnergie par bit dinformation et R
b
est le dbit de lutilisateur.
Si on divise lensemble par N
0
W
s
o N
0
est la densit spectrale du bruit thermique W
s
est la
bande passante totale du systme :
- 26 - 26
s
b b
s
W
R
N
E
M
W N
C
0 0
(2.5)
R
b
/W
s
est nomm le facteur dtalement du CDMA (spreading factor) et reprsente dans
beaucoup des cas le nombre maximal dutilisateurs qui peuvent envoyer simultanment
(nombre maximal des codes simultans).
La performance du lien est mesure par lefficacit spectrale
0
0
N
E
W N
C
W
R
M
b
s
s
b
(2.6)
en fait en CDMA le bruit total est la somme du bruit thermique et du bruit d laccs
multiple :
c
E M N I N ) 1 (
0 0 0
+ + (2.7)
E
c
est lnergie par chip et calcule par E
c
= E
b
R
b
/W
s
on obtient donc
s
b b
W N
C
M
M
N E
I N
E
0
0
0 0
1
1
/

+
(2.8)
et pour un grand nombre dutilisateurs (M-1)/M1 on obtient :
) 1 (
0 0 0
0
s
b
s
W N
C
I N
E
W N
C
+
+
(2.9)
Les trois facteurs principaux qui amliorent lutilisation du CDMA sont :
Lactivit de la source de trafic comme la voix, avec un facteur dactivit V.
La discrimination spatiale due aux antennes multi-faisceaux de nombre 1/a (surtout en
satellite).
La rutilisation des frquences orthogonales, avec un facteur disolation .
En tenant en compte ces facteurs on obtient :
s
b b
W
R E
M V a N I N ) 1 (
0 0 0
+ + (2.10)
do
) 1 (
0 0 0
0
s
b
s
W N
C
a
I N
E
V
W N
C

+
+
(2.11)
Le facteur en dnominateur est diminu par rapport 2.9 et la performance du canal est
augmente considrablement. Lefficacit spectrale reprsente galement le taux dutilisation
du canal et peut tre compar ce taux calcul pour TDMA.
En CDMA, lutilisation dune frquence unique permet lutilisateur dmettre et de recevoir
le mme signal pour diffrents satellites de la constellation ; cest le soft-hand-off. Dans le
sens descendant, les deux signaux reus par plusieurs satellites peuvent tre combins pour
- 27 - 27
amliorer la performance. Pour le sens montant, les signaux reus par diffrents satellites sont
dcods sparment et cest le centre de commutation qui doit grer la situation. En gnral,
le signal le plus puissant est pris en compte. Lavantage de cette caractristique est une
simplicit de hand-off qui est trs frquent dans le systme LEO. On peut dmontrer que ce
soft-hand-off peut doubler la capacit du systme si un algorithme adapt au contexte est
utilis [7].
Dautre part, lutilisation dune frquence commune dans les cellules voisines ncessite un
contrle de puissance pour chaque utilisateur et dans les deux directions. Le but du contrle
de puissance est dadapter la puissance mise la position du terminal afin que les signaux
reus soient presque identiques. Ceci diminue linterfrence due laccs multiple et
augmente la capacit. Le contrle de puissance boucle ferme est trs utilis en CDMA [7],
en LEOS le long dlai aller-retour dgrade la performance de cet algorithme et ne permet qun
seul contrle par RTD.
2.5.3 CDMA/TDMA hybride dans LEOS
Linconvnient majeur du CDMA pur est la difficult de la dtection multi-utilsateur cause
du grand nombre de codes. Pour faciliter cette tche, un composant temporel est introduit et
on parle du CDMA/TDMA hybride. Puisque la composante FDMA existe dans toute
technique, on se trouve dans une technique o les trois modes daccs sont prsents FDMA,
TDMA et CDMA. En rsum, sur chaque bande de frquence (FDMA), le temps est
dcompos en trames qui contiennent plusieurs slots (TDMA) et sur chaque slot plusieurs
codes peuvent envoyer simultanment (CDMA). Un contrle de puissance est facilement
ralis dans ce cas en insrant les informations de contrle au dbut dune trame. On se
contente pour linstant de ces quelques remarques et on laisse la comparaison dtaille pour
les autres chapitres.
Une proposition est faite dans [38] en utilisant un schma CDMA/TDMA hybride. Dans ce
schma, pour servir deux types de trafics, on dfinit deux types de trames ; les trames
synchrones et les trames asynchrones. Dans les trames asynchrones, on envoie des rafales
alatoires, alors que dans les trames synchrones, on envoie des donnes synchronises.













Trame pour laccs asynchrone. 20ms trame pour lenvoi des donnes. 20ms


plusieurs codes par trame plusieurs codes par slot
slot0
trame0 tramei
Burst
alatoi
re
dacc

Figure 2.14 Canal CDMA/TDMA hybride
- 28 - 28
La trame 0 est utilis pour accder au rseau alatoirement. Des bursts daccs alatoires
sont alors envoys dune manire asynchrone tout en demandant une partie de la bande
passante associe ce service. Laccs sur cette trame se fait en CDMA Aloha. Pour les
autres services, une demande de connexion est ncessaire. Cette demande se fait dune faon
alatoire et la trame 0 peut tre utilise dans ce but. Si la demande est accepte
lutilisateur commence envoyer ses donnes en utilisant un nombre de slots rservs. Il
envoie ses donnes en mode quasi-synchrone sur les trames synchrones en utilisant
CDMA/TDMA hybride.
Notons ce stade que, contrairement au CDMA, o le nombre maximal de codes est li la
bande passante totale, en CDMA/TDMA, le nombre maximal de codes quon peut utiliser sur
chaque slot est une fonction de nombre de slots et de la bande passante totale du systme.
Pour mieux comprendre cette diffrence, on donne quelques chiffres.
Si la sous bande dcompose en FDMA est de 256Kb/s et les utilisateurs ont un dbit constant
de 8Kb/s, en CDMA pur, le facteur dtalement (spreading factor) est de 256/8 = 32. En
CDMA/TDMA ce chiffre est ensuite divis par le nombre de slots pour obtenir le facteur
dtalement qui est de lordre de 8 dans ce cas. On peut donc considrer le CDMA pur comme
un cas particulier du CDMA/TDMA o le nombre de slots par trame est 1. Cette remarque est
importante et va tre utilise dans la suite.
2.6 Qualit de service
Comme on a dj mentionn, la constellation de satellites LEO est une composante essentielle
dans tout rseau international comme lUMTS. Ce rseau doit offrir plusieurs types de
services avec diffrentes qualits de service accessible de nimporte quelle rgion de la terre.
IP et ATM sont les deux protocoles qui peuvent tre utiliss dans le cur du rseau. Ces deux
protocoles offrent plusieurs services qui ont diffrentes qualits. En dfinissant les services du
rseau daccs, il faut prendre en compte ces deux protocoles puisquun mapping de services
est ensuite ncessaire.
En plus du mapping de service ralis par la couche MAC en utilisant la notion de MTCs
(MAC Transfer Capabilities) [16], la couche MAC doit raliser trois buts :
Prvision de la QoS ; c--d, la couche MAC doit garantir la QoS ngocie par
lutilisateur accept dans le systme.
Efficacit ; c--d, en ralisant la qualit de service pour chaque utilisateur, lutilisation
de ressources radios doit tre maximise.
Interoprabilit ; c--d, la couche doit supporter des services analogues aux services
dfinis pour IP, ATM ou UMTS.
Dans ce paragraphe, on va prsenter brivement les services dans un rseau IP et ATM parce
que les services dans le rseau daccs sont en inspirs. Les services dans le rseau UMTS
sont ensuite prsents. Des propositions dans le contexte de satellite sont ensuite signales.
2.6.1 QoS dans IP et ATM
2.6.1.1 IP
LIETF (Internet Engineering Task Force ) a propos plusieurs services et mcanismes pour
raliser une certaine QoS [11]. On signale deux grandes tendances ;
Le modle de services intgrs avec le protocole de rservation RSVP (Ressource
reSerVation Protocol) est caractris par une rservation de ressources. Pour les
- 29 - 29
applications temps rel, lapplication doit tablir un chemin et rserver des ressources.
Trois classes de services sont proposes pour ce modle :
1. Service garanti pour les applications temps rels.
2. Service dbit contrl pour les applications qui demandent une garantie mais
non-temps rel.
3. Service best effort.
Le modle de services diffrencis o les paquets sont marqus pour les diffrencier
au sein du rseau. Aucune rservation nest demande. Trois classes de service sont
proposes par ce modle :
1. Le service premium pour les applications demandant un dlai et une gigue basse.
2. Le service assur pour les applications demandant une meilleure fiabilit que le
best effort.
3. Le service olympic qui contient trois niveaux de priorit o le best effort a la
priorit la plus basse.
2.6.1.2 ATM
Dans ATM, cinq classes de services sont dfinies. Ces classes varient du temps rel au best
effort [12].
CBR (Constant Bit Rate) pour les applications temps rel et dbit constant.
VBRrt (Variable Bit Rate real time) pour les applications temps rel mais dbit
variable.
VBRnrt (Variable Bit Rate non real time) pour les applications qui demandent une
rservation garantie de ressources mais non temps rel.
ABR (Available Bit Rate) pour les applications qui demandent une rservation souple
de ressources.
UBR (Unsustainable Bit Rate) pour les applications best effort.
2.6.2 QoS dans lUMTS
Dans les spcifications 3GPP, plusieurs services supports (bearer services) sont dfinis pour
LUMTS. Ils sont dcomposs en plusieurs niveaux. La figure 2.15 reprsente larchitecture
de la qualit de service QoS dans lUMTS [13].
Dans son chemin dun terminal (TE : Terminal Equipment) un autre, le trafic utilise les
diffrents services supports intgrs dans le rseau. Un TE est connect au rseau UMTS par
le MT (Mobile Termination). Le service de bout en bout au niveau application utilise les
services supports du rseau sous jacent. A son tour, ce service utilise les services du rseau
UMTS ainsi que ceux des rseaux quil traverse.
Les services de support UMTS dterminent la QoS du rseau UMTS. Ils sont constitus de
deux parties, les services supports du rseau radio daccs et celles du cur du rseau.
Les services supports du rseau radio daccs produisent un transport confidentiel des
informations entre MT et CN.
Dans lUMTS, quatre classes de services sont considres. Ces classes sont gnriques et
peuvent supporter une multitude dapplications. Il faut prendre en compte la complexit de
linterface radio et viter de dfinir des mcanismes complexes comme dans le rseau fixe.
Ces classes sont :
Conversational class,
Streaming class,
- 30 - 30
Interactive class,
Background class.
Le caractre distinctif de ces quatre classes est la sensibilit au dlai. Les classes
conversational et streaming sont temps rel, donc trs sensibles au dlai ; des applications
comme vido et voix utilisent ces classes. Les classes Interactive et Background sont
insensibles au dlai et sont destines aux applications Internet.

TE MT UTRAN
CN Iu
EDGE
NODE
CN
Gateway
TE
UMTS
End-to-End Service
TE/MT Local
Bearer Service
UMTS Bearer Service External Bearer
Service
UMTS Bearer Service
Radio Access Bearer Service CN Bearer
Service
Backbone
Bearer Service
Iu Bearer
Service
Radio Bearer
Service
UTRA
FDD/TDD
Service
Physical
Bearer Service

Figure 2. 15 Architecture de la QoS dans UMTS

La classe conversational est utilise surtout pour les applications de parole. Cette classe exige
une contrainte temps rel et doit respecter un dlai et une gigue trs faibles.
La classe streaming est utilise pour des flux temps rel unidirectionnels.
La classe interactive est utiliss par des applications interactives sans contrainte temps rel
(Web Browsing par exemple).
La classe Background est utilise pour des applications sans exigences de dlai ni de dbit
(Emails par exemple).
2.6.3 QoS dans les satellites:
En passant de la couche rseau la couche MAC, un protocole daccs doit accomplir la QoS
demande ; on parle des diffrentes capacits de la couche MAC. En ralit, le protocole
daccs peut varier dun service un autre. Pour des applications temps rel par exemple, un
accs avec dlai garanti est ncessaire et un protocole rigide avec rservation est prfr. Par
contre, pour les applications non-temps rel o le dlai nest pas garanti mais la perte des
paquets est cruciale, un protocole avec accs alatoire est prfr. Mais il faut signaler que les
applications dbit variable et avec dlai garanti peuvent poser des problmes de gaspillage
de ressources quand un protocole avec rservation est utilis. Un compromis entre qualit de
service et utilisation de ressources est ncessaire.
Sur ce stade des problmes de multiplexage de services et dallocation de ressources sont
essentiels. En effet, le multiplexage de services mlange plusieurs types de services avec
- 31 - 31
diffrentes QoS. Limpact dun tel service sur les autres peut perturber leurs qualits
demandes. La sparation de services ncessite une allocation de ressources pour chaque
service une telle allocation peut diminuer lutilisation de ces ressources et par suite lefficacit
de la couche MAC [15].
Dans la communication personnelle par satellite, la plupart des sources de trafics sont
individuelles ; le trafic gnr est donc non agrg et trs variable. Un accs direct au canal
radio est ncessaire, ce qui complique la tche de la couche MAC. Dautre part la
constellation de satellites prsente plusieurs contraintes en dlai, gigue et perte. Ceci est d au
temps de propagation lev et au hand-off et impose lutilisation des protocoles daccs
avancs ainsi quune infrastructure trs rapide et avance comme lATM.
Les principaux caractres de lATM qui en font linfrastructure prfre pour les rseaux
satellites sont rsums dans le tableau 2.1.
La couche MAC doit raliser un contrle de trafic et de congestion pour atteindre la qualit
demande en terme de perte des cellules, dlai des cellules et variation de dlai. Une demande
de connexion est refuse si la capacit et la qualit de service demandes ne sont pas
disponibles. Mais pour les satellites, il nest pas toujours possible de connatre la capacit et la
qualit de service disponible, ce qui rend ltude plus complique.
Tableau 2.1 Avantage de lATM
Caractristiques de lATM Avantages dutilisation
Allocation de bande sur demande et
dynamique
Efficacit et meilleure utilisation de
ressources
Haut dbit Bas dlai
Non-propritaire Interoprabilit et bas prix.
Support pour le multimdia Efficace, pratique.
Support de multicast Efficacit par non-rptition
File dattente prioritaire Support des plusieurs qualits de services

Application



TCP


IP


AAL


ATM

CPCS=common part convergence sublayer
CPI=common part indicator (1 byte)
CRC=cyclic redundancy check
PHYSIQUE
Data
Header Data
Header Header Data CRC
AAL5 CPCS Payload PAD UU CPI Length CRC
Header 48 byte cell payload
0 1 2 32
MAC

Figure 2.16 IP sur ATM dans la communication par satellite
Dans [14], les cellules ATM sont considres comme des paquets, et la performance est
value par application de la thorie des files dattente. Dlai, variation de dlai, taux derreur
et longueur de la file dattente sont les facteurs essentiels pour dterminer le taux de perte.
- 32 - 32
La couche MAC accomplit la liaison entre couches suprieures et couche physique. En
satellite, cette liaison est ncessaire sur le lien montant et descendant. Si on utilise la
technique IP sur ATM la pile des protocoles est comme prsente dans la figure 2.16.
2.7 Intgration dans le rseau terrestre
Pour laborer lintgration du satellite dans le rseau terrestre, on prsente la figure 2.17 qui
montre les diffrents niveaux de couverture dans le rseau UMTS.
La couverture se fera dans un premier temps par taches de lopard , cest dire que seul
les villes et les centres daffaires seront quips en UMTS. Ce phnomne est d plusieurs
raisons. En effet, le territoire est globalement couvert par les systmes de deuxime
gnration, ceci par lintermdiaire de trois types de cellules, les macro-cellules, (couverture
sur 15Km de rayon), les micro-cellules (500m) et les pico-cellules (100m). Du fait dun dbit
et dune frquence dutilisation plus levs pour lUMTS, les cellules utilises seront plus
petites. LUMTS se dveloppera donc dans un premier temps dans des lots de couverture : en
milieux urbains, centres daffaires et se dploiera de faon progressive [54].
Dans ce paragraphe, on prsente en premier lieu le rseau daccs en UMTS pour ensuite
discuter lintgration du satellite dans lUMTS.


Figure 2.17 Couverture en UMTS
2.7.1 Rseau daccs en UMTS (UTRAN)
La figure 2.18 prsente de rseau daccs qui comporte les nodes B et les RNCs.
Le NodeB : son rle principal est d'assurer les fonctions de rception et de transmission radio
pour une ou plusieurs cellules de l'UTRAN (UMTS Terrestrial Radio Access Network).
Le RNC (Radio Network Controller) : son rle principal est le routage des communications
entre le NodeB et le rseau coeur.
Le rseau UMTS repose donc sur un rseau coeur et un rseau d'accs. Voyons maintenant le
moyen de communication en couches entre le mobile et le rseau d'accs.
Les protocoles de l'interface radio s'appliquent aux 3 premires couches du modle OSI (Open
Systems Interconnections), qui sont la couche physique, la couche liaison de donnes, et la
couche rseau (routage).
- 33 - 33
Le niveau 1 (PHY) reprsente la couche physique de l'interface radio. Elle ralise entre autres
les fonctions de codage de canal, d'entrelacement et de modulation.
Le niveau 2 comprend les couches PDCP, RLC, MAC et BMC. Le transport fiable des
donnes entre 2 quipements est assur par la couche RLC (Radio Link Control). La couche
MAC (Medium Access Control) remplit la fonction de multiplexage des donnes sur les
canaux de transport radio. La couche PDCP (Packet Data Convergence Protocol) a deux
fonctions principales. Tout d'abord, elle permet d'assurer l'indpendance des protocoles radio
de l'UTRAN (couches MAC et RLC) par rapport aux couches de transport rseau. Cette
indpendance permettra de faire voluer les protocoles rseau (par exemple de passer de
l'IPv4 l'IPv6) sans modification des protocoles radio de l'UTRAN. D'autre part, la couche
PDCP offre les algorithmes de compression de donnes ou d'en tte de paquets de donnes,
permettant un usage plus efficace de ressources radio. En effet, plusieurs tudes sur les
caractristiques du trafic sur les rseaux internet public ont montr que 40 % des paquets IP
taient des paquets de taille trs rduite (40 octets). Ces paquets sont composs de 20 octets
d'en-tte IP suivis de 20 octets d'en-tte TCP. Ce sont des paquets de contrle ne contenant
aucune donne utilisateur. La couche PDCP utilise le mcanisme de compression des en-ttes
TCP/IP dcrit dans les RFC 1144 [55] et RFC 2507 [56]. Enfin, la couche BMC
(Broadcast/Multicast Control) assure les fonctions de diffusion de messages sur l'interface
radio.

Figure 2.18 Rseau d'accs UTRAN
Le niveau 3 de linterface radio contient la couche RRC (Radio Resource Control). La
fonction principale de cette couche est la gestion de la connexion de signalisation tablie entre
l'UTRAN et le mobile. Cette connexion est utilise lors des changes de signalisation entre le
mobile et l'UTRAN, par exemple, l'tablissement et la libration de la communication.
La figure 2.19 montre les diffrentes couches et fonctionnalits dans lUTRAN. Pour mieux
comprendre cette fonctionnalit, on donne deux exemples pratiques qui reprsentent deux cas
diffrents du systme ; la voix et le data.
Utilisateurs data (cas dun paquet IP)
Le paquet d'information reu par l'UTRAN et provenant du rseau coeur est la N-PDU
(Network PDU). Dans le cas d'un paquet IP, l'en-tte de la N-PDU est compress par la
- 34 - 34
couche PDCP, c'est dire remplac par un en-tte PDCP de taille plus rduite. Cette nouvelle
PDU est ensuite segmente par la couche RLC, qui ajoute chaque segment son propre en-
tte. La RLC-PDU est alors traite par la couche MAC, qui ajoute un en-tte lorsqu'un
multiplexage est effectu.
Utilisateurs voix
Pour la voix, le fonctionnement est beaucoup plus simple. Les couches RLC et MAC sont
utilises en mode transparent (ni segmentation, ni multiplexage des trames de phonie) ; la
couche PDCP est dans ce cas inutile.


Figure 2.19 Vue en couche de linterface radio de lUTRAN


Figure 2.20 Encapsulation des paquets arrivant du rseau coeur

- 35 - 35
2.7.2 Intgration du satellite dans lUMTS
Plusieurs projets tudient lintgration des satellites LEO dans les rseaux terrestres surtout
lUMTS. Lintgration est oriente qualit de service puisquun utilisateur naccepte pas une
dgradation de sa QoS en passant au rseau satellitaire. Lintgration utilise une unit
dinterconnexion au cur du rseau UMTS o linfrastructure est probablement lATM. On
dfinit plusieurs niveaux dintgration [17] :
Niveau gographique ; dans ce cas, le systme satellitaire complte le rseau terrestre
en couvrant des zones non couvertes par le rseau terrestre. Les deux rseaux sont
technologiquement indpendants.
Niveau service ; dans ce cas les deux rseaux doivent offrir les mme services malgr
quils restent technologiquement indpendants.
Niveau rseau ; dans ce cas, les deux rseaux daccs sont diffrents et indpendants
mais le cur du rseau est le mme. Des fonctions dadaptation sont ncessaires pour
les terminaux.
Niveau technique ; dans ce cas, les deux techniques daccs doivent tre proches
puisque le passage dun rseau un autre doit tre transparent. Des terminaux duaux
qui ralisent des handover en passant dun rseau un autre sont ncessaires.
Niveau systme ; dans ce cas, les deux systmes daccs doivent tre pareils puisque le
rseau satellitaire constitue une partie de tout le rseau. Les hand-offs sont possibles
entre rseau satellitaire et terrestre quand cest ncessaire ; dbordement ou panne du
rseau terrestre par exemple. Les terminaux duaux doivent passer dun systme un
autre avec facilit.
Une tche importante pour accomplir lintgration est la dfinition de la couche MAC
satellitaire. Puisque lintgration est au niveau systme, les deux techniques terrestre et
satellitaire doivent concorder [20]. Les principaux projets dintgration du satellite avec
lUMTS sont :
INSURED (Integrated Satellite UMTS Real Environment Demonstrator) ; lobjectif
principal de ce projet est lintgration de la constellation de satellites LEO dans
lUMTS afin de raliser un systme global de communication personnelle. Les
concepts essentiels traiter sont les handovers entre les deux segments, les rseaux
daccs et la gestion de mobilit [18].
SINUS (Satellite Integration into Network for UMTS Systems) ; dans ce projet, on
tudie essentiellement des nouveaux protocoles daccs et de codages qui sont
performants pour les deux types de rseaux terrestre et satellitaire. La technique
daccs choisie est le WCDMA utilis par la voix ainsi que par des sources de donnes
haut dbit [19].
Lintgration du satellite est suppose au niveau systme et le satellite reprsente une partie
de lUMTS. Le terminal pourra se connecter aux deux systmes (satellite et terrestre) et
effectuer un handover entre les deux. Un terminal doit avoir la possibilit de supporter
plusieurs interfaces radios. Lapproche GRAN suivie par ITU et ETSI spare le terminal en
deux parties. Une partie dpendante de la technologie radio et une deuxime indpendante. La
partie dpendante est implmente de faon supporter plusieurs interfaces radio [57].
Deux techniques dintgrations sont proposes dans la littrature [58] : la premire considre
le satellite comme Node B et la deuxime comme RNS (mlange de RNC et node B). On
dfinit ce niveau le USRAN (UMTS Satellite Radio Access Network).
- 36 - 36
Node B : cette technique est utilise quand une couverture terrestre nest pas
accessible. Le satellite reprsente donc un lien entre le terminal et le RNC qui y est
gographiquement inaccessible. Le satellite doit supporter toutes les fonctionnalits
dune station de base ainsi que du node B.
RNS : dans ce cas le satellite peut accomplir les deux rles. Un parapluie pour les
cellules terrestres et un lien entre le terminal et le cur du rseau UMTS. Les
fonctionnalits de Node B et RNC sont implmentes dans le satellite. Le satellite doit
accomplir des fonctions de contrle ainsi que de transmission. Le satellite doit avoir la
possibilit dinterconnecter directement avec les RNC terrestres ainsi quavec des
autres satellites, ce qui impose lexistence des liens inter-satellites.
En rsum, lintgration complte du rseau satellite dans le rseau cellulaire terrestre est un
problme de rseau qui ncessite des solutions sur le niveau de transmission et de rseau.
Lintgration du satellite dans lUMTS est au niveau systme et le satellite nest pas considr
comme un chemin alternatif de routage capable de servir des utilisateurs non couverts par le
rseau terrestre mais comme partie dun systme unique. Le handover dune station de base
vers le Satellite est possible chaque fois que le lien terrestre est charg, en panne ou autre
raison. Un tel systme ncessite une seule technique daccs multiple pour les deux rseaux
terrestre et satellite. La couche MAC doit utiliser cette technique pour accder au systme
dune faon efficace et conomique. La figure 2.21 montre les diffrents hand-off dans un tel
systme.








Inter-segment



Intra-segment
Rseau daccs
S-UMTS
Coeur du rseau
UMTS
Rseau daccs T-
UMTS

terminal UMTS

Figure 2.21 Handover en UMTS et S-UMTS
2.8 Conclusion
Dans ce chapitre, on a prsent les architectures et techniques qui vont tre utiliss tout au
long de cette thse. Larchitecture dune constellation LEO est prise dun projet franais
national [3]. Les techniques daccs sont prsentes pour tre utiliss dans les chapitres
suivants dans le cadre de nos propositions des protocoles daccs et de fonctions de contrle
dadmission. Plusieurs techniques utilises dans des autres projets sont prsentes brivement
pour les comparer avec nos mthodes. La technique daccs CDMA est dtaille puisquelle
reprsente une grande partie de notre thse. Le problme de la qualit de service est ensuite
labor sur diffrents rseaux comme lIP, lATM et lUMTS. Plusieurs projets dintgration
du satellite dans lUMTS sont cits et une intgration au niveau systme est utilise dans cette
thse. Le rseau satellitaire est vu comme une partie du systme global de communication, ce
- 37 - 37
qui ncessite des mthodes comparables daccs, des classes de service souples ainsi quune
simplicit de hand-off.
On remarque daprs cette tude que lapplication des techniques daccs TDMA et CDMA
nutilisent pas le multiplexage statistique pour augmenter la capacit du canal. Le
multiplexage de services nest pas trait en dtail afin de dfinir des protocoles qui rsolvent
les problmes dus aux diffrents comportements de trafic et des diffrentes QoS demandes.
Dans la technique hybride CDMA/TDMA qui spare les donnes synchrones des donnes
asynchrones, on remarque que des sources faible dbit sont prises en compte pour
reprsenter le trafic IP. Des sources de transfert des fichiers et de WWW ne sont pas tudies.
En plus, cette technique nutilise pas efficacement les priodes dinactivits des sources
vocales qui peuvent augmenter la capacit du canal comme on a dmontr dans le paragraphe
2.6.
Notre thse consiste rsoudre ces diffrents problmes. Les tudes vont prendre en
considration les diffrentes remarques prsentes dans ce chapitre. Ainsi, la QoS doit tre
convenable avec les systmes existants, lintgration avec le rseau terrestre impose des choix
prcises... Les questions essentielles discuter et rsoudre sont :
Quels services doit-on dfinir au niveau MAC pour supporter les diffrentes sources
de trafic et pour raliser leurs QoS demandes ?
Quelle fonction de contrle dadmission est adapte aux protocoles daccs et qui peut
accepter le nombre maximal de demandes ?
Quel protocole daccs peut utiliser une technique daccs donne en profitant du
multiplexage statistique et en intgrant plusieurs services sur le mme canal ?
Dans les quatre chapitres suivants, on va tudier trois protocoles daccs diffrents. Ces
protocoles utilisent la technique TDMA et CDMA. Le but essentiel est de maximiser la
capacit du canal en utilisant le multiplexage statistique. Plusieurs services sont dfinir pour
supporter plusieurs sources de trafic (voix, transfert des fichiers, email, web). On va ensuite
comparer ces protocoles pour dduire les diffrents critres qui dterminent le choix des
diffrents paramtres daccs et de contrle en cas du rseau LEOS.
- 38 - 38









3.1 Introduction
Dans ce chapitre, on va tudier le protocole daccs multiple PRMA dans la constellation de
satellites basse orbite LEO. Ce protocole, qui utilise la technique TDMA, est une union du
TDMA et du Aloha en tranches afin de permettre un multiplexage statistique de sources
trafics variables. Ce protocole, dvelopp pour les utilisateurs vocaux et dans les rseaux
terrestres, peut tre utilis dans des systmes LEOS et pour plusieurs types de services.
Lintgration de services est lun des objectifs majeurs du rseau international de
tlcommunications. Ce rseau global va tre capable de supporter plusieurs types de services
avec simplicit et performance. La simplicit implique des techniques et protocoles simples et
capables de traiter plusieurs types de trafics. La performance consiste respecter une QoS
demande tout en maximisant lutilisation de ressources. Les questions majeures rsoudre
sont :
Comment intgrer sur le mme canal radio plusieurs services diffrents par le
comportement de leurs trafics et par leurs QoS demandes, ?
Comment unifier divers modes daccs pour les rseaux terrestres et satellitaires afin
de raliser une intgration au niveau du systme entre les satellites LEO et LUMTS ?
Comment utiliser les ressources radio avec efficacit et sans gaspillages tout en
respectant la QoS ?
Lutilisation de PRMA en satellite est nomme S-PRMA. Le protocole original doit tre
chang pour sadapter au nouveau contexte. Le protocole T-PRMA (Terrestre) est inutilisable
en contexte de satellite cause de long dlai dattente en LEO. Ceci est la raison essentielle
dintroduire le S-PRMA. Une comparaison est ensuite faite entre le T-PRMA et S-PRMA
pour dmontrer que les changements introduits pour adapter PRMA au satellite rend la
performance de ce protocole comparable celle de T-PRMA en contexte terrestre. Le modle
mathmatique propos pour analyser la performance du protocole dtermine les paramtres
majeurs qui influencent sa performance. Ce modle appliqu sur les sources data peut donner
des rsultats approximatifs sur leur comportement.
Une deuxime raison qui rend ce chapitre ncessaire est le fait que S-PRMA soit adapt de
faon multiplexer plusieurs services avec une efficacit acceptable. On va dmontrer que
dans ce cas la performance de S-PRMA est quivalent avec celle de T-PRMA en contexte
terrestre. Rappelons enfin que les comparaisons faites entre S-PRMA et T-PRMA sont en
- 39 - 39
contexte satellite et terrestre, respectivement. Le but sera daborder la performance de T-
PRMA en utilisant S-PRMA en LEOS.
Dans la premire section, on prsente le protocole PRMA terrestre utilis pour la voix et les
donnes ainsi que lapplication de ce protocole au systme LEO. Dans la deuxime section,
les services intgrs sont prsents afin de dfinir des QoS pour les diffrents utilisateurs. La
fonction de contrle dadmission CAC est discute dans la section 4. La modlisation
mathmatique de S-PRMA est dveloppe dans la section 5 afin de pouvoir calculer les
diffrents paramtres de performance et de stabilit pour les utilisateurs voix et donne. La
discussion analytique et par simulation est prsente dans la sixime section o on dtermine
les paramtres qui maximisent lefficacit de S-PRMA. On peut alors comparer notre
protocole avec des autres protocoles utilisant PRMA. Enfin le paragraphe 7 donne les
conclusions et introduit le prochain chapitre.
3.2 PRMA
En technique TDMA, le temps est divis en des slots dans des trames. Un slot est dans un des
deux tats ; rserv ou disponible . Ltat de chaque slot est diffus aux utilisateurs par
la station de base. Quand une rafale arrive au terminal (dbut du talkspurt pour un utilisateur
voix par exemple), il utilise le protocole Aloha pour accder un slot disponible afin
denvoyer le premier paquet de la rafale. Si la transmission est russie, le slot est rserv pour
lutilisateur tout au long de la rafale (talkspurt). Pour viter les contentions sur ce slot, son tat
devient rserv et aucun utilisateur na le droit dy accder. A la fin de la rafale, le slot est
libr, son tat redevient disponible .
Un terminal accde sur un slot disponible en utilisant le protocole Aloha. Il tente de
transmettre sur un slot disponible avec le risque que dautres utilisateurs peuvent essayer
dmettre sur ce mme slot. Si plusieurs utilisateurs russissent accder au mme slot, une
contention se produit. Le terminal doit tenter dmettre sur le prochain slot disponible avec
une probabilit p. La probabilit p est un paramtre de conception. Quand un terminal russit
envoyer un paquet dans un slot, la station de base (satellite pour notre cas) diffuse aux
diffrents utilisateurs le nouvel tat du slot. Les utilisateurs doivent savoir ltat dun tel slot
avant sa rptition dans la prochaine trame. Si RTD (Round Trip Delay) est le temps aller
retour dun paquet vers la station de base, T
f
la dure dune trame et T
s
la dure dun slot, on
doit avoir ;
RTD T
f
- T
s
(3.1)
Cette condition limite lutilisation du PRMA pour quelques services temps rel suivant le
temps aller-retour. Si le service impose un temps de trame maximal et le RTD est trop grand
pour respecter linquation 3.1, le service est non compatible PRMA. Dans [22] on distingue
entre service compatible PRMA et non compatible PRMA et on considre la voix comme non
compatible PRMA pour les satellites gostationnaire cause du dlai lev et compatible
PRMA pour les satellites orbite basse. On va dmontrer ce rsultat dans ce chapitre.
Un paquet envoy par lutilisateur est copi dans le tampon en attendant la rponse du
rcepteur (ou de la station de base). Si ce paquet est positivement acquitt, lutilisateur voit le
slot rserv tout au long de la rafale. Dans le cas contraire, le terminal renvoie le paquet sur
un autre slot. Un paquet peut attendre un dlai maximum D
max
dans le tampon. Si le temps
dattente dpasse ce dlai, le paquet est rejet et ceci reprsente la cause essentielle de perte
des paquets. Pour les utilisateurs voix, par exemple, ce dlai est de 40 ms dans les meilleurs
- 40 - 40
des cas, et 20 ms si on compte les retards dus aux calculs et la propagation. Par contre, pour
les utilisateurs de donne, ce temps peut tre beaucoup plus grand [26].
Dans une constellation de satellites LEO, le temps aller-retour est de 15-20ms, ce qui impose
un temps de trame suprieur pour pouvoir recevoir la rponse dans la trame mme. Puisque la
rponse une tentative prend un temps aussi lev, un terminal vocal ne pourra pas essayer
denvoyer un tel paquet sur plus quune trame. Si les tentatives sur les slots dune trame
chouent, le paquet sera rejet et on passe au deuxime paquet dans le talkspurt. Ce problme
ne se pose pas pour des utilisateurs qui acceptent un dlai. Ces remarques sont cruciales pour
la mesure de performance du systme ainsi que pour le choix des paramtres. De ce point de
vue, le systme peut tre divis en deux sous-systmes ; le sous-systme de voix et le sous-
systme de donne.
3.2.1 Sous-systme de voix
Un paquet vocal est form par des bits produits par une source voix pendant T
f
avec une
entte de H
v
bits. Si le nombre de slots par trame est N
s
et la dure dun slot est T
s
, on a
frame slots
H T R
T R
N
v f s
f c
s
/
1
1
]
1

+
(3.2)
ms
N
T
T
s
f
s
(3.3)
o R
c
est le dbit du canal et R
s
est le dbit de la source (voix et data).
En utilisant un dtecteur dactivit lent (S-VAD Slow Voice Activity Detector) tudi dans
[23] par ETSI, la source vocale est considre comme une source ON-OFF. Une source voix
cre des dures de paroles et de silences suivant que lutilisateur dans une conversation parle,
attend ou coute. La source peut tre considre comme un processus de Markov deux tats
(figure 3.1). La probabilit quune dure de parole de moyenne t
on
se termine dans un temps
est :

v
=1-exp(-/t
on
) (3.4)
Cest la probabilit de passage de ltat de parole ltat de silence. Dautre part, la
probabilit quune dure de silence de moyenne t
off
se termine dans un temps est :

v
=1-exp(-/t
off
) (3.5)
On dfinit la probabilit dtre dans ltat ON (parole), qui est aussi le facteur dactivit, par :

v
=
on
= t
on
/( t
on
+ t
off
) (3.6)
et la probabilit dtre dans ltat OFF (silence) par :

off
= t
off
/( t
on
+ t
off
) (3.7)


v

1-
v
1-
v


v
OFF ON

Figure 3.1 Modle de source voix
Notons que le choix du S-VAD qui impose un tel comportement des sources de trafic est
adapt aux systmes LEO puisque la dure moyenne de ltat on est de 1s et celle de ltat off
- 41 - 41
est 1.35s. Par contre, un dtecteur rapide dactivit implique des sources plus compliques
avec des dures moyennes de sjour dans les tats comparables au RTD.
Quand la source de trafic passe de ltat OFF ltat ON, lutilisateur passe ltat de
contention et tente denvoyer son premier paquet sur un slot disponible en effectuant un tirage
de Bernoulli de probabilit p
v
(il accde au slot avec une probabilit p
v
et naccde pas avec
une probabilit 1-p
v
). Quand il accde un tel slot, il passe un tat dattente puisque la
rponse du satellite va prendre un certain dlai RTD (cest spcifique pour le systme LEOS).
Si la rponse est positive, lutilisateur passe ltat rservation, dans le cas contraire il revient
ltat de contention. Puisque lutilisateur ne reoit la rponse quaprs un RTD T
f
, si cette
rponse est ngative, il ne pourra plus tenter daccder pour le mme paquet car le dlai
dattente maximal D
max
est coul. Le paquet est donc rejet et on essaye denvoyer le paquet
suivant. Lautre cause de rejet est le fait quun utilisateur ne russisse aucun tirage de
Bernoulli sur tous les slots disponibles dune trame ; le dlai maximal est encore coul dans
ce cas et le paquet est rejet.
3.2.2 Sous-systme de donne
Pour les donnes, on sintresse dans ce chapitre au trafic ABR qui reprsente des trafics de
transfert des fichiers. Le sous-systme de donne est constitu dun nombre dutilisateurs qui
gnrent des rafales suivant un processus de poisson indpendant de moyenne . Une rafale
est de longueur distribue gomtriquement de moyen en bits L
b
. Une rafale est donc
constitue dun nombre de paquets distribus gomtriquement et de nombre moyen :
msg paquets
T R
L
L
f s
b
s
/ (3.8)
o R
s
est le dbit de la source de trafic.
Une source de donne peut tre modlise comme un processus de Markov deux tapes.
Attente A, attente dun fichier, et Fichier F, avoir un fichier transmettre. Le passage
dattente la transmission est Poissonien de paramtre alors que le passage inverse est
gomtrique. La probabilit de passage de A F pendant une dure est donc exponentielle
de valeur

d
= 1 - exp(-) (3.9)
Par contre, la probabilit de passage de F A pendant est de valeur gale divis par le
temps total moyen pour mettre un message qui est gal L
b
/ R
s
. do :

d
= / (L
b
/ R
s
) (3.10)
Notons ici quune distribution gomtrique peut tre modlise par une distribution
exponentielle quand le temps est trs petit par rapport au temps total de transmission dun
message [28, 29].


d

1-
d
1-
d


d
A F

Figure 3.2 Modle de source data
- 42 - 42
Quand une source de donne passe ltat F, lutilisateur passe ltat de contention et tente
denvoyer son premier paquet sur un slot disponible en effectuant un tirage de Bernoulli de
probabilit p
d
(il accde sur le slot avec une probabilit p
d
et naccde pas avec une
probabilit 1-p
d
). Quand il accde un tel slot, il passe un tat dattente puisque la rponse
du satellite va prendre un certain dlai RTD (cest spcifique pour le systme LEOS). Si la
rponse est positive lutilisateur passe ltat rservation, dans le cas contraire il revient
ltat de contention. Contrairement aux utilisateurs vocaux, un paquet de donne peut attendre
un long dlai dans le tampon (beaucoup plus grand que RTD) avant dtre envoy
correctement. Le paquet reste dans le tampon jusqu' son acquittement positif. Dans ce cas
lutilisateur passe ltat rservation et envoie le reste du fichier.
Puisque lutilisateur de donne accepte un dlai, sa probabilit de permission p
d
doit tre
infrieure la probabilit de permission des utilisateurs voix p
v
. Une priorit est associe aux
utilisateurs vocaux. Le choix de ces deux paramtres ainsi que la dure dune trame vont tre
discuts dans la suite.
3.3 Les services
Les classes de services sont supportes au niveau MAC par les MTCs [21] (Mac Transfer
Capabilities) qui garantissent une qualit de service chaque classe de service. Un mapping
est donc ncessaire entre service et MTC. Dans ce paragraphe, on va dfinir les MTCs qui
vont supporter les diffrents services demands par les utilisateurs.
On dfinit deux MTCs au niveau MAC. La diffrence principale entre ces deux MTCs est le
dlai dattente et la probabilit de perte dun paquet. Le premier est nomm RTC (Rapid
Transfer Capability) et le deuxime est nomm STC (Slow Transfer Capability).
Le RTC doit garantir une transmission rapide de paquets gnrs par la source, ce qui
est souhaitable pour les services temps rels. La ralisation de cette rapidit se fait sur
deux niveaux ;
o Au niveau dappel par la fonction CAC, qui doit refuser une telle demande si
elle estime que la couche MAC est incapable de garantir un temps rel.
o Au niveau de paquet par un contrle de trafic accompli par la couche MAC par
lintermdiaire des probabilits de permission.
Un mapping est possible entre RTC et les services variables temps rel qui
reprsentent le trafic vocal. Comme exemple on note le VBRrt de lATM, service
garanti ou service premium de lIP et service conversationnel de lUMTS.
Le STC peut supporter un dlai avant de transmettre un paquet mais doit garantir une
probabilit de perte dun paquet trs petite. Pour garantir cette qualit de service, un
nombre limit dutilisateurs doit tre accept (fonction CAC). Le choix de la
probabilit de permission est aussi un facteur important comme on va le dmontrer
dans la suite. Un mapping entre STC et les services variables non-temps rel est
convenable. Comme exemple on note le ABR de lATM, service assur ou dbit
contrl de lIP et le service de base de lUMTS.
La diffrence entre ces deux MTCs est vue dans ce chapitre sous deux aspects ;
1 Une probabilit de permission suprieure pour les utilisateurs vocaux (RTC) et donc
une priorit souple des utilisateurs vocaux par rapport aux utilisateurs data (STC).
Ceci diminue linfluence des utilisateurs data sur les utilisateurs voix.
- 43 - 43
2 Un tampon pour les utilisateurs data pour stocker les paquets data en attendant une
transmission russie. Ceci est inexistant pour les utilisateurs voix. Cette technique
diminue la probabilit de perte dun paquet data.
3.4 La fonction CAC
Dans ce chapitre, la fonction dadmission CAC utilise est simple. Le rle de cette fonction
est de limiter le nombre dutilisateurs accepts par le systme afin de garantir une qualit de
service pour chaque utilisateur. Comme dcrit dans le paragraphe prcdent, on a deux types
dutilisateurs, RTC et STC. Le RTC est considr comme tant temps rel et le STC comme
tant non-temps rel. On suppose que tous les utilisateurs sont multiplexs ensemble sur le
mme canal daccs et cest la couche MAC qui doit partager les ressources disponibles entre
les diffrents utilisateurs.
Au dbut on considre un seul type de trafic, soit la voix supporte par le RTC. Puisque les
sources de trafics voix sont dbit variable, un multiplexage statistique est possible. Un slot
peut tre utilis par plus quun utilisateur. Si le nombre de slots est de n et si un nombre M
dutilisateurs peut tre accept par la fonction CAC, le rapport n/M dtermine le pourcentage
de slots consomm par un utilisateur. Ce rapport est la base de dcision de la fonction CAC.
En effet, si un utilisateur demande une connexion il suffit de regarder si les ressources
disponibles sont suprieures ou infrieures n/M. Dans le premier cas, la demande est
accepte et dans le deuxime, la demande est refuse.
Une mme fonction peut tre applique pour les utilisateurs data support par le STC. Puisque
ces utilisateurs sont non-temps rel, un nombre plus lev peut tre admis. Le pourcentage de
slot utilis par une source data est alors dtermin.
Daprs ces pourcentages pour chaque type de trafic on peut dfinir la fonction CAC utilise
dans ce chapitre. Chaque fois quun utilisateur demande une connexion, on regarde les
ressources disponibles. Si cet utilisateur est data, on compare avec le pourcentage pour les
utilisateurs STC, si lutilisateur est accept, les ressources seront diminues de ce
pourcentage. Si cet utilisateur est voix, on compare avec le pourcentage pour les utilisateurs
RTC, si lutilisateur est accept, les ressources seront diminues de ce pourcentage.
Notons enfin que les pourcentages de consommation sont dtermins dans la suite du
chapitre. Ainsi, il faut signaler que leffet du handoff nest pas pris en compte dans cette
fonction. On peut toujours supposer que cette fonction est une premire tape dadmission
effectue au niveau du satellite. Une deuxime tape est toujours ncessaire au niveau du
centre de gestion NCC (Network Control Center) o le handoff est pris en considration.
3.5 Modlisation mathmatique
Dans ce paragraphe, on va modliser le protocole S-PRMA afin dtudier sa performance
ainsi que les paramtres essentiels qui dterminent cette performance. Cette tude est base
sur le modle dvelopp par Nanda et Goodman dans [24] pour le PRMA terrestre. Ltude
utilise la mthode danalyse des points dquilibre EPA (Equilibrium Point Analysis) dfinie
par Tasaka dans [25]. Cette mthode est utilise pour faciliter le calcul puisquun calcul
Markovien est trs complexe comme on va le dmontrer. Notons quil ny a pas de preuves
mathmatiques sur lefficacit de lEPA, la seule preuve tant la validation par des
simulations. Rptons que la diffrence principale entre notre protocole S-PRMA et le PRMA
classique est ltat dattente pour un utilisateur S-PRMA d au dlai RTD et le fait quun
utilisateur ne puisse tenter denvoyer un paquet que pendant une seule trame. On prsente
- 44 - 44
brivement le modle PRMA dans le cas des utilisateurs voix pour ensuite dvelopper notre
propre modle de S-PRMA pour les utilisateurs voix et data.
3.5.1 Modle du PRMA
Ce modle est dvelopp pour les utilisateurs voix et expliqu dans [24]. Un utilisateur voix
de protocole PRMA est dans un des tats suivants :
(Silence Sil ), (Contention Cont ), (Rservation du slot 1 Res
1
), (Rservation du slot
2 Res
2
),.(Rservation du slot n Res
n
).
Ltat du systme est donc la configuration de n + 2 variables :
= { S, C, R
0
, R
1
, , R
n-1
} (3.11)
Chaque variable dsigne le nombre dutilisateurs dans ltat correspondant. Puisque le
nombre dutilisateurs en rservation du slot i est 0 ou 1 et le nombre dtats de S et C est M
(nombre total dutilisateurs), le nombre dtats de est de 2
n
M
2
. Pour tudier le systme avec
des chanes de Markov, il faut une chane 2
n
M
2
tats et de dimension n+2 qui est trop
complique analyser. Pour cette raison, on utilise la mthode EPA et on tudie ltat du
systme en quilibre ;
= { s, c, r
0
, r
1
, , r
n-1
} (3.12)
Cet ensemble reprsente les points dquilibre du systme. Un point dquilibre x dans
reprsente une valeur de la variable X dans pour lequel ltat qui reprsente X est en
quilibre et donc le nombre dutilisateurs qui entrent dans cet tat est gal au nombre
dutilisateurs qui en sortent. s est par exemple, le nombre dutilisateurs en tat de silence
dans le cas dquilibre. La reprsentation de ce modle est comme suit :
1-
f


1 1

f


(1-r)p(1-p)
c-1







1- 1-(1-r)p(1-p)
c-1

Sil
Res
n-1
Cont
Res
0

Figure 3.3 Modle de PRMA terrestre
Les tats de cette chane reprsentent les tats dquilibre et la technique simplifie la chane
de n+2 dimensions en sautant directement un tat spcial de cette chane nomm ltat
dquilibre.
Les valeurs et
f
reprsentent les paramtres de la source ON-OFF (figure 3.1) dans le cas
o est la dure de slot et de trame, respectivement. p est la probabilit de permission pour
les utilisateurs voix. En utilisant la proprit de ltat dquilibre qui est ; le nombre des
entrants un tat est gal au nombre des sortants de cet tat on dduit le systme
dquations pour calculer les valeurs des points dquilibre qui sont les valeurs des variables x
en quilibre. On peut donc dduire ltat stationnaire sans passer par le calcul de la matrice de
transition. Les dtails de calcul sont dans [24], on passe maintenant ltude du S-PRMA qui
a ses spcificits rendants le modle plus complexe. Le protocole S-PRMA et les tudes
- 45 - 45
mathmatique et par simulation effectues pour loptimiser reprsentent notre contribution
essentielle pour ce chapitre.
3.5.2 Modle du S-PRMA
En S-PRMA un utilisateur qui passe du silence la contention tente denvoyer sur un tel slot
puis attend le rsultat de cette tentative pendant un RTD T
f
. Lutilisateur se trouve donc dans
un tat dattente dune rponse qui peut tre positive ou ngative. Si la rponse est positive,
ltat dattente est nomm positif, dans le cas contraire il est ngatif. Un utilisateur voix de S-
PRMA est alors dans un des tats suivants :
(silence Sil ), (Contention Cont ), (rservation du slot 1 Res
1
), (Rservation
du slot n Res
n
), (Attente positive pour le slot 1 Ap
1
,.., (Attente positive pour le
slot n Ap
n
), (Attente ngative pour le slot 1 An
1
),, (Attente ngative pour le
slot n An
n
). Ltat du systme est la configuration de 3n + 2 variables
= { S, C, R
0
, , R
n-1
,A
0
,..; A
n-1
, A
0
,..; A
n-1
} (3.13)
A est utilis pour designer lattente positive et A pour dsigner lattente ngative.
Chaque variable dsigne le nombre dutilisateurs dans ltat correspondant. Puisque le
nombre dutilisateurs en rservation du slot i est 0 ou 1 et le nombre dutilisateurs dans un
autre tat varie entre 0 et M (nombre total dutilisateurs), le nombre des tats de est de
2
n
M
2n+2
. Pour tudier le systme avec des chanes de Markov, il faut une chane 2
n
M
2n+2

tats et de dimension 3n + 2 qui est trop compliqu analyser. Pour cette raison on utilise la
mthode EPA et on tudie lensemble dtat du systme en quilibre ;
= { s, c, r
0
, r
1
, , r
n-1,
a
0
, , a
n-1
, a
0
, , a
n-1
} (3.14)
Cet ensemble reprsente les points dquilibre du systme. Un point dquilibre dans x
reprsente une valeur de la variable dans X pour laquelle ltat qui reprsente X est
en quilibre et donc le nombre dutilisateurs qui entrent dans cet tat est gal au nombre
dutilisateurs qui en sortent. La reprsentation de ce modle est comme suit :
1-
f


1 1

f



1

(1-r)p
v
(1-p
v
)
c-1
1 1



(1-r)p
v
(1-(1-p
v
)
c-1
) 1
1- 1-(1-r)p
v
1 1
Sil
Res
n-1
Ap
0
Ap
n-1
C
Res
0
An
0
An
n-1

Figure 3.4 Modle de PRMA satellite (utilisateurs voix)
soit et les paramtres du modle ON-OFF dans le cas o est le temps dun slot alors:
=1-exp(-T
s
/ t
on
) (3.15)
=1-exp(-T
s
/ t
off
) (3.16)
- 46 - 46

f
est la probabilit quun utilisateur finit un talspurt aprs n slots ;

f
= 1 ( 1 - )
n
n . (3.17)
Les valeurs des points dquilibres sont calcules en utilisant la figure 3.4 et en admettant que
le nombre dutilisateurs entrants dans un tat est gal au nombre dutilisateurs sortant de cet
tat ;
r
0
= r
1
=.= r
n-1
= r. (3.18)
a
0
= a
1 =
= a
n-1
= a. (3.19)
a
0
= a
1 =
= a
n-1
= a. (3.20)
r
f
= s . (3.21)
r ( 1-
f
) + a = r. (3.22)
c (1 - r) p
v
(1-u)=a. (3.23)
c (1-r) p
v
u = a. (3.24)
s + c + n a + n a + n r = M. (3.25)
Avec u = (1-p
v
)
c-1
.
Dans ce systme dquations (3.18-3.25) les variables sont les lments de lensemble et les
autres termes sont les paramtres du systme.
La solution de ce systme dquations donne les valeurs des points dquilibre. Il se peut que
le systme ait plusieurs solutions, ceci est en fonction de M et li la stabilit du systme.
Dans [24] on prouve que PRMA terrestre peut avoir plusieurs points dquilibre qui peuvent
tre stables ou non. Les points stables, qui sont en gnral au nombre de deux, reprsentent
ltat normal et ltat de congestion du systme. Quand le systme est congestif, il faut utiliser
des techniques spciales pour retourner ltat normal du systme [30]. Dans S-PRMA ce
problme ne se pose pas puisque le systme ne peut pas avoir plus quune solution comme on
va dmontrer dans le paragraphe suivant.
3.5.2.1 Stabilit de S-PRMA
Le nombre dutilisateurs en contention en quilibre c est donne par lquation 3.26 qui
rsume le systme (3.18-1.25) :
f(c) [
f
/ + n
f
+ n] + c [1 + n p
v
(1-u)] n p
v
(1- u) c f(c) = M. (3.26)
O f(c) = c p
v
u / (
f
+ c p
v
u) (3.27)
Daprs cette quation on dtermine la valeur de c. Dans la figure 3.5 on trace la valeur de c
en fonction de M pour deux valeurs de probabilit de permission (p
v
=0.3 et p
v
=0.5) et pour
PRMA terrestre et satellitaire. Il est clair que pour le PRMA terrestre et pour quelques valeurs
de M on peut avoir trois solutions pour c, dont deux sont stable (graphe croissant [24]). Ces
deux solutions reprsentent les deux cas efficace et congestif. Une congestion peut se produire
dans PRMA terrestre et des mcanismes de rsolution sont ncessaire. Pour S-PRMA ce
problme ne se pose pas puisque pour les diffrents valeurs de la probabilit de permission, le
systme dquations admet une seule solution de c qui est stable (fonction croissante). La
raison de cette stabilit est le fait quun utilisateur en S-PRMA ne puisse pas tenter denvoyer
sur plus quun slot dans une trame. Sil russit accder un tel slot, il doit attendre une
trame pour savoir le rsultat de cette tentative. Ce temps dattente fait que le nombre de
tentatives se rduit et vite des congestions possibles. Cest un des avantages de notre
protocole mais qui a leffet de diminuer lefficacit du protocole dans le cas normal (non
congestif) [27] comme on va le dmonter.

- 47 - 47

10
-2
10
-1
10
0
10
1
10
2
0
50
100
150
200
250
300
les utilisateurs en contention en PRMA terrestre et satellite (p=0.3)
o PRMA terrestre
+ PRMA satellite


n
o
m
b
r
e

t
o
t
a
l

d

u
t
i
l
i
s
a
t
e
u
r
s

(
M
)

c (logarithmique)

10
-2
10
-1
10
0
10
1
10
2
0
50
100
150
200
250
300
350
400
450
les utilisateurs en contention en PRMA terrestre et satellite (p=0.5)
o PRMA terrestre
+ PRMA satellite


n
o
m
b
r
e

t
o
t
a
l

d

u
t
i
l
i
s
a
t
e
u
r
s

(
M
)

c (logarithmique)

Figure 3.5 Stabilit de PRMA terrestre et satellite
Dans [27] les auteurs proposent un nouveau protocole pour adapter le PRMA au satellite afin
datteindre des meilleures performances. Ce protocole appel PRMA-HSs (Hindiring States)
est bas sur le principe qun tel utilisateur continue faire des tentatives pendant quil attend
la rponse du satellite. Avec ce protocole on atteint des meilleures performances mais avec le
prix dun gaspillage de ressources. On remarque que ce protocole est rapidement congestif
quand le nombre dutilisateurs augmente. Une comparaison de notre protocole et de PRMA-
HS va tre faite dans la suite.
3.5.2.2 Calcul de performance de S-PRMA (utilisateurs voix)
On va calculer le temps quun paquet attend dans le tampon avant dtre envoy ou rejet
cause de lexpiration du temps dattente. Ceci nous permet en deuxime lieu de calculer les
paramtres de performances du protocole.
Calcul du temps dattente :
si R reprsente le nombre dutilisateurs en rservation et C reprsente le nombre dutilisateurs
en contention on a :
la probabilit quun terminal en contention obtient une rservation dans le slot en cours est :
= ( 1 R/n ) p
v
( 1 p
v
)
C
(3.28)
la probabilit quil ne tente pas sur le slot en cours est :
= 1 ( 1 R / n ) p
v
(3.29)
la probabilit quil tente mais quune collision se produise est :
= ( 1 R / n ) p
v
( 1 ( 1 p
v
)
C
) (3.30)
Un nouveau paquet attend dans le tampon jusqu que lutilisateur lenvoie sur un tel slot. Le
temps dattente est plus difficile calculer en S-PRMA quen PRMA terrestre. Un utilisateur
en contention peut passer lattente positive (quivalent une rservation), lattente
ngative ou rester en contention. Quand un utilisateur passe lattente ngative, il doit
attendre n slots avant de retourner ltat de contention. Ceci augment le temps dattente
considrablement. Pour calculer la probabilit dattente, on fait les remarques suivantes :
La probabilit dattendre un seul slot est (lutilisateur passe directement ltat dattente
positive).
La probabilit dattendre deux slots est (lutilisateur reste en contention pour un slot puis
passe lattente positive).
- 48 - 48
La probabilit dattendre n slots est
n-1
(lutilisateur reste n-1 slots en contention puis passe
lattente positive).
La probabilit dattendre n+1 slots est
n
+ (lutilisateur reste n slots en contention puis
passe lattente positive ou il fait une tentative non russite et passe lattente ngative,
attend n slots dans cet tat puis fait une tentative russite).
La probabilit dattendre n+2 slots est
n+1
+ 2 (lutilisateur reste n+1 slots en
contention puis envoie positivement ou tente ngativement et reste n slots dans lattente
ngative et un slot en contention pour enfin mettre positivement. Le facteur de 2 reprsente
la permutation de deux faits (rester en contention) et (tenter ngativement).
La probabilit dattendre 2n + 2 slots est
2 n+1
+ f
a
(n+1,2)
n+1
+ f
a
(1,3)
2
.
(lutilisateur reste 2n +1 slots en contention puis envoie positivement ou reste n+1 slots en
contention et fait une tentative ngative puis envoie positivement ou fait deux tentatives
ngatives et une contention puis transmet positivement).
La fonction f
a
(x,y) reprsente le nombre de permutations possibles des vnements (y-1
tentatives ngatives) et (x slots en contentions). Do :
) )! 1 ( ! /( )! 1 ( ) , (
1
+
+
y x y x C y x f
x
y x a
.
La probabilit dattendre kn + j (k0 et j>0) est alors :

+
+ +
+
+
k
i
i j n i k
i j n i k w
j n i k
C j kn P
0
1 ) (
1 ) (
1 ) (
) ( (3.31)
Cette probabilit est utilise dans la suite pour dterminer la performance du S-PRMA. On
remarque que la tentative ngative est la raison principale qui augmente cette probabilit et
qui va diminuer la performance du systme.
Calcul des paramtres de la performance :
Dans notre protocole, le temps maximal dattente est une trame puisque ce temps est proche
de RTD qui est de lordre de 15-20ms. Notons par D ce dlai dattente.
Le nombre de paquets perdus est alors une fonction du temps dattente. Si L est la longueur
dun talkspurt en nombre de paquets, le nombre de paquets perdus est :
( )
( )
( ) j n L D L j n
k D j n k D k j n
D j j n
drop
drop
drop
+ +
+ + +

1 ) 1 (
1 ) 1 (
1 0
(3.32)
La probabilit que dans un talkspurt de L paquets, k paquets sont perdus est :

'

+
+ +

+ +
D
x
w
n k D
n k D x
w
n L D x
w
drop
k x p
L k x p
L k x p
L k n
1
1 ) 1 (
1 ) 1 (
0 , ) (
, 0 , ) (
, ) (
) Pr( (3.33)

En utilisant lquation : Pr (talksurt = L ) =
f
( 1-
f
)
L 1
(3.34)
La probabilit de perte due un temps dattente inacceptable et pour un R et C donns est
donc :
- 49 - 49
) ( ) , , (
drop f drop
n E p (3.35)
o


0
) ( ) Pr( ) (
L
drop drop
L n E L n E (3.36)
et


L
k
drop drop
L k n k L n E
0
) Pr( ) ( (3.37)

Dautre part, puisque dans ltat dquilibre la probabilit quun slot soit rserv est r, la
distribution des utilisateurs en rservation est :
R n R R
n R
r r C R

) 1 ( ) ( (3.38)
La distribution conditionnelle des utilisateurs en contention est base sur la remarque que les
utilisateurs entrant en contention sont indpendants des utilisateurs en sortants et sont
distribus gomtriquement.
1
1
,
, 0
, ) 1 (
, ) 1 (
) (
0 0
0 0
+

'


<


c
p
autrement
R m C p
R m C p p
R C
R m
C
C
(3.39)
Enfin la probabilit de perte est :

1
0 0
). , , ( ) ( ) (
n
R
R m
C
drop C R loss
P R C R P (3.40)

La probabilit de perte est le paramtre essentiel de la qualit de service pour les utilisateurs
vocaux. Cette probabilit est une fonction des plusieurs paramtres, soit la probabilit de
permission, le temps dune trame
Le temps dune trame est fix 20ms qui est proche de RTD+T
s
. Dans notre protocole, on va
agir sur le choix de la probabilit de permission pour obtenir la performance maximale. Avant
de faire cette tude, on va appliquer notre modle mathmatique conu pour la voix sur les
utilisateurs de donnes o lattente est plus longue et le dlai moyen dans le tampon dcrit la
performance du protocole.
3.5.2.3 Calcul de performance de S-PRMA (utilisateurs data)
Pour les utilisateurs data, on utilise les sources de donnes dfinies dans la figure 3.2. Dans
cette figure, on a modlis une source donne par une source vocale dans le cas o la
longueur du message envoyer serait trs grande par rapport au temps dune trame. Les
paramtres de cette source approximative sont donns dans les quations 3.9 et 3.10. En
utilisant ces paramtres on peut appliquer la mthode EPA pour les utilisateurs data. Le
modle de reprsentation est alors :
Avec et
f
sont la probabilit de passer de lattente A au fichier F pendant un temps de slot
et la probabilit de passer de F A pendant un temps de trame, respectivement. Do :
=1-exp(-T
s
) (3.41)

f
=T
f
/ (L
b
/ R
s
)=1 / L
s
. (3.42)
La probabilit de permission est p
d
, on peut alors faire le mme calcul que pour les utilisateurs
voix. On se contente dans ce cas de calculer la probabilit dattente avant la rservation dun
tel slot. Cette probabilit reprsente la probabilit quun paquet attende dans le tampon un
- 50 - 50
temps donn. La valeur moyenne de ce temps peut tre donc estime. Daprs lquation 3.31,
on a :

+
+ +
+
+
k
i
i j n i k
i j n i k w
j n i k
C j kn P
0
1 ) (
1 ) (
1 ) (
) ( (3.43)

1-
f


1 1

f



1

(1-r)p
d
(1-p
d
)
c-1
1 1



(1-r)p
d
(1-(1-p
d
)
c-1
) 1
1- 1-(1-r)p
d
1 1
Sil
Res
n-1
Ap
0
Ap
n-1
C
Res
0
An
0
An
n-1

Figure 3.6 Modle de PRMA satellite (utilisateurs data)
est la probabilit quun terminal en contention obtient une rservation dans le slot en cours
= ( 1 R/n ) p
d
( 1 p
d
)
C
(3.44)
est la probabilit quil ne tente pas sur le slot en cours
= 1 ( 1 R / n ) p
d
(3.45)
est la probabilit quil tente mais quune collision se produise
= ( 1 R / n ) p
d
( 1 ( 1 p
d
)
C
) (3.46)
Dans ltat dquilibre, la probabilit quun slot soit rserv est r, la distribution des
utilisateurs en rservation est :
R n R R
n R
r r C R

) 1 ( ) ( (3.47)
La distribution conditionnelle des utilisateurs en contention est base sur la remarque que les
utilisateurs entrant en contention sont indpendants des utilisateurs en sortant et sont
distribus gomtriquement.
1
1
,
, 0
, ) 1 (
, ) 1 (
) (
0 0
0 0
+

'


<


c
p
autrement
R m C p
R m C p p
R C
R m
C
C
(3.48)
La probabilit dattendre kn + j slots avant de russir une rservation est la probabilit quun
paquet data attende kn + j slots dans le tampon. Pour calculer le temps moyen dattente pour
un nombre dutilisateurs en contention C et en rservation R on a :

+ +
0
1
0
) ( ) ( ) , (
k
n
j
w
j kn j kn p C R d (3.49)
Et le dlai moyen de sjour dun paquet dans le tampon est :
- 51 - 51

1
0 0
) , ( ) ( ) (
n
R
R m
C
C R
C R d R C R d (3.50)
Ce dlai est le paramtre essentiel de QoS pour les utilisateurs data, puisque le temps que le
fichier aille sjourner dans le tampon en est simplement dduit car les paquets suivants sont
envoys conscutivement sur le slot rserv avec un rythme dun paquet par trame.
3.6 Discussion analytique et par simulation
3.6.1 Service RTC (utilisateurs voix)
On va dabord choisir la probabilit de permission pour les utilisateurs voix. Pour cette raison
on suppose que le systme ne contient que des sources vocales. Ces utilisateurs accepts par
la fonction CAC mettent leurs paquets sur le canal radio en utilisant le protocole S-PRMA.
Une trame de dure 20ms contient 16 slots pour lenvoi des paquets. La bande passante sur
chaque frquence porteuse est de 155Kb/s pour permettre lenvoi dun paquet voix sur un slot
de la trame. Le dbit de la source voix est suppos de 8Kb/s qui augmente 9.6Kb/s au
niveau MAC cause des diffrents enttes. Les paramtres de la source ON-OFF sont : t
on
=
1s et t
off
= 1.35s . Ces valeurs sont utilises dans le calcul mathmatique et la simulation.
Dans la figure 3.7 la probabilit de perte dun paquet est trace en fonction du nombre
dutilisateurs voix dans le systme et ceci pour diffrentes valeurs de probabilit de
permission p
v
. On remarque que pour des valeurs basses de probabilit de permission, la perte
est leve contrairement au cas du PRMA terrestre. Ceci est d au fait que le nombre de
tentatives est limit dans PRMA satellite cause du RTD lev. Dautre part, lorsque cette
probabilit est proche de 1, la perte augmente cause dun grand nombre de contentions. Un
compromis est p
v
. = 0.7 o la probabilit de perte est minimale. On remarque aussi que le
choix de la probabilit de permission devient de plus en plus critique quand le nombre
dutilisateurs augmente et le canal est surcharg. Dans le cas dune probabilit de permission
de 0.7 on peut accepter jusqu 32 utilisateurs voix avec une QoS acceptable (perte infrieure
1% [31]).

15 20 25 30
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
0.016
0.018
0.02
choix de la probabilite de permission p (voix)
o p=0.3
x p=0.5
. p=0.7
+ p=0.9
nombre dutilisateurs


p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
0.016
0.018
0.02
choix de la probabilite de permission p (voix)
x 15 utilisateurs
o 20 utilisateurs
. 25 utilisateurs
+ 30 utilisateurs
probabilit de permission
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 3.7 Probabilit de perte, nombre dutilisateurs et probabilit de permission

- 52 - 52

0 5 10 15 20
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
zero utilisateur en contention
nombre dutilisateurs en resevation
p
r
o
b
a
b
i
l
i
t


d
e

n
o
n

p
e
r
t
e

+ prma terrestre p=0.4
* prma satellite p=0.7

0 5 10 15 20
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
un utilisateur en contention
nombre dutilisateurs en reservation



p
r
o
b
a
b
i
l
i
t
e

d
e

n
o
n

p
e
r
t
e

+ prma terrestre p=0.4
* prma satellite p=0.7

Figure 3.8 Probabilit de non perte vs. nombre dutilisateurs
Dans la figure 3.8, on compare notre protocole S-PRMA avec le protocole PRMA terrestre.
Le choix des probabilits de pertes est tir de [24] pour PRMA terrestre et des discussions
prcdentes pour S-PRMA satellitaire. Les valeurs choisies sont 0.4 et 0.7 pour PRMA
terrestre et satellite, respectivement. On remarque dans la figure 3.8 que la probabilit quil
ny a aucune perte des paquets est toujours infrieure en S-PRMA quen T-PRMA. Les deux
probabilits sont presque pareilles lorsque le nombre dutilisateurs en contention est de zro,
alors quelle est considrablement infrieure lorsque le nombre dutilisateurs en contention est
de un. La figure 3.9 prouve concrtement lefficacit de T-PRMA par rapport S-PRMA. Le
nombre maximal dutilisateurs quon peut accepter en systme terrestre est de 36 utilisateurs,
tandis quon ne peut accepter que 32 utilisateurs pour le systme LEO. La capacit du
systme est donc augmente grce lutilisation de S-PRMA..
Dans cette figure on trace galement des rsultats de simulation qui utilisent NS (Network
Simulator) comme outil de simulation, le modle de simulation ainsi que les intervalles de
confiances sont discuts dans lappendice A. On remarque que les deux rsultas (calcul et
simulation) sont trs proches. Ceci dmontre la validit de notre tude analytique.


15 20 25 30 35
0
0.002
0.004
0.006
0.008
0.01
0.012
comparaison de S-PRMA et T-PRMA
x,+ PRMA satellite p=0.7 calcul et simulation
o,. PRMA terrestre p=0.4 calcul et simulation
nombre dutilisateurs


p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 3.9 Comparaison de S-PRMA et T-PRMA
- 53 - 53
Calculons maintenant ce quon appelait le facteur de consommation par un utilisateur voix.
Ce facteur est le rapport de nombre total de ressources (16 slots) sur le nombre total
dutilisateurs (32 utilisateurs). Il est donc de 0.5 slot. Ce facteur peut tre utilis par la
fonction CAC.
Calculons maintenant le facteur defficacit de multiplexage statistique pour les utilisateurs
voix. Ce facteur est le rapport entre le nombre dutilisateurs voix accepts par le systme et ce
nombre en cas de multiplexage parfait. Ce dernier est gal au nombre de slots allous aux
utilisateurs voix, divis par le rapport dactivit des utilisateurs voix. Si M
v
est le nombre
maximum des utilisateurs voix accepts (32 dans notre exemple de simulation) r
v
est le
nombre de ressources alloues aux utilisateurs voix et
v
est le facteur dactivit (0.42 dans
notre exemple de simulation).
r
v
reprsente le nombre de ressources ddies aux utilisateurs voix. Cest le nombre
dutilisateurs voix quon peut accepter en mode circuit et sans lutilisation dune couche MAC
particulire. La fonction CAC accepte dans ce cas un utilisateur si son dbit maximal est
disponible. Ce nombre, qui ne tient compte que de la bande passante du canal et le dbit
maximal de la source, est calcul par :
r
v
= BW/R = 155/8 = 19.3.
Do:
= M
v

v
/ r
v
= 0.7
Ceci veut dire quun slot est utilis 70% du temps. Ce facteur est de 0.8 pour T-PRMA.
Notons que dans [27] les auteurs ont amlior lgrement la performance de S-PRMA en
utilisant un protocole PRMA-HSs pour atteindre un facteur de multiplexage statistique de
0.73 mais avec le cot dun risque dinstabilit comme on a dmontr dans le paragraphe
3.5.2.1.
3.6.2 Service STC (sources data)
Passons maintenant aux utilisateurs data (sources de transfert de fichiers). Ces utilisateurs
peuvent attendre une dure trs longue avant dtre servi. Les paramtres de ces utilisateurs
sont ( = 0.5 et L
s
= 100 paquets), larrive des messages est frquente et la longueur dun
message est de moyen 100 paquets quivalent 1.6secondes. Le paramtre de performance
est le dlai dattente dans le tampon. La figure 3.10 prsente ce dlai pour diffrentes valeurs
de probabilit de permission p
d
. On remarque que la probabilit de permission est infrieure
celle des utilisateurs voix. Ainsi, lorsque cette probabilit est de 0.4, lattente est leve
cause des contentions. Par contre, lorsque cette probabilit est de 0.2, une permission au canal
est rare et lattente augmente. Un bon choix est lorsque p
d
.= 0.3. On remarque que le choix
devient de plus en plus crucial quand le nombre dutilisateurs augmente et le canal est charg.
Ceci est d au fait que le contrle nest important que lorsque la charge soit leve.
Notons que dans cette figure, on suppose que tous les utilisateurs sont des data et que la taille
de buffer est infinie. Pour cette raison, la probabilit de perte est constamment nulle. Ce
rsultat nest pas trs pratique puisquune limite de tampon est toujours ncessaire. Lintrt
de cette figure est le choix de la meilleure probabilit de permission.

- 54 - 54

20 25 30 35
0
10
20
30
40
50
60
70
80
90
choix de la probabilit de permission p (data)
o p=0.2
x p=0.3
. p=0.4
nombre dutilisateurs

d

l
a
i

m
o
y
e
n

e
n

n
o
m
b
r
e

d
e
s

s
l
o
t
s


0.2 0.22 0.24 0.26 0.28 0.3 0.32 0.34 0.36 0.38 0.4
0
10
20
30
40
50
60
70
80
90
choix de la probabilit de permission p (data)
* 20 utilisateurs
o 25 utilisateurs
x 30 utilisateurs
. 35 utilisateurs
probabilit de permission
d

l
a
i

m
o
y
e
n

e
n

n
o
m
b
r
e

d
e

s
l
o
t
s



Figure 3.10 Dlai de paquet vs. nombre dutilisateurs
3.6.3 Multiplexage de services (utilisateurs voix et data)
On peut ce stade tudier la performance du systme dans le cas o les deux types de services
data et voix seraient multiplexs sur le mme canal. Les critres de performance sont la
probabilit derreur qui doit tre infrieur 1% pour la voix et le dlai dattente dun paquet
data qui doit avoir une valeur raisonnable. Ltude faite dans ce paragraphe est base sur des
simulations. Le simulateur NS est utilis pour simuler un systme LEOS comme dcrit dans
le deuxime chapitre. Une technologie multi-faisceaux est utilise. Dans chaque faisceau, on a
24 frquences porteuses. Chaque frquence a une bande passante montante gale la bande
passante descendante gale 155Kb/s. Le G/W a une bande de 155Mb/s ainsi que la liaison
inter-satellite. Les cellules utilises au niveau MAC sont insres dans des slots de dure
20/16 = 1.25ms. La longueur dun paquet (cellule) peut tre calcule par :155 1.25 = 194
soit 194 bits avec les enttes et 160 bits sans les enttes (qui donne aux voix le dbit de 8Kb/s
au niveau application et 9.6Kb/s au niveau MAC). Le modle de simulation est prsent dans
lappendice A. Les paramtres choisis sont les paramtres doptimisation dtermins par les
calculs prcdents.
Voix : t
on
= 1s, t
off
=1.35s et p
v
= 0.7.
Data ; L
s
= 100paquets, =0.5 et p
d
= 0.3.
On va calculer la performance du protocole quand on a 20 utilisateurs voix accepts par la
fonction CAC. On dtermine le nombre maximal dutilisateurs data quon peut accepter avec
une qualit de service accepte pour les utilisateurs voix et pour les utilisateurs data. On
compare ensuite les rsultats avec le PRMA terrestre.
Dans la figure 3.11, pour 20 utilisateurs voix dans le systme, on trace la probabilit de perte
des paquets voix et le dlai dattente de paquets data pour diffrents nombres dutilisateurs
data. Ces graphes sont pour les protocoles PRMA terrestre et satellite. On remarque que la
performance de PRMA en contexte satellitaire est lgrement dgrade. On peut accepter
jusqu 13 utilisateurs data en S-PRMA et 16 en T-PRMA. Le dlai dattente dun paquet data
nest influenc que par un supplment de RTD. En baissant la valeur de probabilit dattente
des utilisateurs data, on peut accepter plus des utilisateurs avec un dlai dattente plus lev.
En effet, linfluence des utilisateurs data sur les utilisateurs voix diminue et la probabilit de
perte des paquets voix diminue. Une sparation totale entre les deux types de service peut tre
- 55 - 55
galement effectue pour annuler linfluence dun service sur lautre. On a dans ce cas deux
files dattente au lieu dune seule et le multiplexage de service est diminu. Des tudes plus
avances sur le multiplexage de services et lallocation de ressources pour S-PRMA ainsi que
pour des autres protocoles sont laisses pour le chapitre six.


0 4 8 12 16
0
0.002
0.004
0.006
0.008
0.01
0.012
comparaison de S-PRMA et T-PRMA (20 utilisateurs voix)
+ PRMA satellite pv=0.7, pd=0.3
o PRMA terrestre pv=0.4, pd=0.15
nombre dutilisateurs data




p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e

d
e
s

p
a
q
u
e
t
s

v
o
i
x


0 4 8 12 16
0
20
40
60
80
100
120
comparaison de S-PRMA et T-PRMA (20 utilisateurs voix)
+ PRMA satellite pv=0.7, pd=0.3
o PRMA terrestre pv=0.4, pd=0.15
nombre dutilisateurs data



d

l
a
i

p
o
u
r

p
a
q
u
e
t

d
a
t
a


Figure 3.11 Probabilit de perte voix et dlai d'attente data (utilisateurs voix et data)
3.7 Conclusion
Dans ce chapitre, on a tudi le protocole PRMA dans le contexte de satellites LEO. Ltude
nous a men changer le protocole original pour dfinir une nouvelle version appele S-
PRMA. Ce nouveau protocole est utilis par des utilisateurs voix et donne. Pour diffrencier
les deux types dutilisateurs, on a dfini deux services au niveau MAC. Le RTC pour
supporter les utilisateurs voix qui sont considr comme VBRrt et le STC pour supporter les
utilisateurs data qui sont considrs comme ABR. La diffrenciation entre ces deux services
se fait sur plusieurs niveaux. Au niveau dappel, une fonction CAC est dfinie pour limiter le
nombre total dutilisateurs dans le systme afin de respecter la QoS de chaque service. Au
niveau de paquet, la sparation se fait par une priorit donne aux utilisateurs voix. Cette
priorit est ralise par le choix des probabilits de permission daccs au canal pour chaque
type de service. Une tude mathmatique pour calculer la performance est accomplie pour le
sous-systme voix et pour le sous-systme data. Cette tude permet le choix des probabilits
de permission pour les diffrents utilisateurs. Une probabilit de permission de 0.7 pour les
utilisateurs voix et 0.3 pour les utilisateurs data donnent des valeurs de performance
optimales. Ces valeurs sont calcules dans le cas o les utilisateurs seraient homognes. Dans
le cas o les utilisateurs seraient multiplexs ensemble, ltude mathmatique devient
complexe et une tude par simulation est accomplie. Daprs cette tude, on calcule les
valeurs de performance du systme qui sont la probabilit derreur des paquets voix et le dlai
dattente des paquets data. Le fait que la probabilit de permission des utilisateurs voix est
suprieure celle des utilisateurs data, diminue linfluence des utilisateurs data sur les
utilisateurs voix mais augmente le dlai de sjour dun paquet data dans le tampon. La priorit
donne aux utilisateurs voix est souple puisque les deux probabilits de permission sont
gnres indpendamment. Linfluence de sous-systme de donne sur celui de voix existe
toujours.
La contribution essentielle de ce chapitre se rsume en trois points :
- 56 - 56
1. Ladaptation du protocole PRMA au contexte satellite avec la dfinition de S-PRMA.
2. La modlisation mathmatique de ce nouveau protocole S-PRMA.
3. Loptimisation des paramtres du protocole par calcul mathmatique et simulation.
4. S-PRMA montre une performance proche de celle de T-PRMA en cas des utilisateurs
voix et data. En cas de multiplexage de services, les deux systmes sont presque
identiques en terme defficacit ceci reprsente un important rsultat pour les systmes
LEO.
- 57 - 57









4.1 Introduction
Dans ce chapitre, un protocole utilisant la technique daccs CDMA est propos dans le
contexte de constellation de satellites LEO (Low Earth Orbit). Le protocole est orient QoS et
peut multiplexer plusieurs types de services sur le mme canal. Les services utiliss sont la
voix et le data. La voix est toujours reprsentes par les sources ON-OFF par contre le data
est reprsent par des sources de transfert des fichiers comme dans le chapitre 3 mais aussi
par des sources plus complexes, reprsentants des sources de messages lectroniques (emails).
Les services multimdias mobiles vont tre demands de plus en plus par les utilisateurs
mobiles. La seconde gnration de rseau cellulaire est incapable de supporter des
applications haut dbit. La troisime gnration doit rsoudre ce problme en augmentant la
bande passante et en utilisant des techniques qui facilitent lutilisation du canal. W-CDMA
(Wideband CDMA) est la technique daccs utilis dans lUMTS qui a pour objectifs
principaux :
Lintgration de services rsidentiels, bureautiques et cellulaires dans un seul systme.
La capacit de servir plus que 50% de populations du globe.
Lintgration avec le secteur spatial (satellite).
Le composant S-UMTS doit raliser une couverture globale avec une QoS comparable celle
du rseau terrestre. Le rseau daccs de S-UMTS doit se connecter avec le cur du rseau
UMTS par des interfaces spciales. Ceci impose lutilisation des techniques daccs
comparables en UMTS et en S-UMTS.
Il est intressant de noter que lutilisation du CDMA facilite lintgration de services orients
circuits et de services orients paquets puisque les deux techniques sont transparentes du point
de vue de CDMA et on na pas besoin dun protocole spcial pour les intgrer.
Ce chapitre est organis comme suit : dans le deuxime paragraphe on prsente la technique
CDMA utilise en dfinissant ses paramtres de performance. Le protocole S-CDMA est
propos dans le paragraphe 3 pour les deux sous-systmes voix et data, les sources vocales
sont des sources ON-OFF alors que les sources data sont soit des sources de transfert des
fichiers soit des sources Emails introduites dans ce paragraphe. Les services du niveau MAC
nomms MTCs (MAC Transfer Capabilities) sont labors dans le quatrime paragraphe. La
fonction de contrle dadmission CAC est ensuite dfinie dans le paragraphe 5. Le sixime
paragraphe prsente le contrle gnral du trafic. En utilisant ces dfinitions on peut
- 58 - 58
dvelopper notre contribution analytique dans le septime paragraphe et pour le sous-systme
voix et pour le sous-systme data. Des rsultats de calcul et de simulation sont prsents dans
le paragraphe 8 pour dfinir les paramtres de performance de protocole et choisir leurs
valeurs optimales qui maximisent lefficacit du S-CDMA dans les diffrents cas des
utilisateurs. Enfin les conclusions sont introduites dans le neuvime paragraphe.
4.2 La technique CDMA
Dans [33] et [34] on suppose que la performance de CDMA est domine par la probabilit
derreur dun bit BER (Bit Error Ratio). Les problmes lis lacquisition des paquets sont
ngligs. Une approximation pour calculer lerreur en CDMA est lapproximation standard
Gaussienne (SGA Standard Gaussian Approximation) [35]. Assumons que linterfrence due
laccs multiple (MAI Multiple Access Interference) est Gaussienne et en utilisant des
rcepteurs simple corrlation, le BER ou la probabilit derreur dun bit est donne par :
) (SNR Q P
e
(4.1)
avec

x
u
du e x Q
2 /
2
2
1
) (

(4.2)
SNR est le rapport signal sur bruit. Si on considre la technique de squence directe en
CDMA (CDMA/DS Direct Sequence) (Pr{x
j
= 1 } = Pr{x
j
= -1} = 0.5) o x
j
est un chip dans
la squence avec un longueur de code ou spreading factor sf, la valeur moyenne du rapport
signal sur bruit (SNR) pour le paquet i dans le cas des puissances reues ingales est donne
par :

K
i k
k
k
i
T
N
P sf
P
SNR
1
0 1
2
) 3 (
(4.3)
On considre un systme avec K utilisateurs simultans chacun ayant une puissance reue P
j

(j=1..K). La dure dun bit est T et un bruit blanc additionnel N
0
/2. On considre un systme
cellulaire de R+1 cellules de K utilisateurs actifs dans chacune. Supposons quun contrle de
puissance parfait est utilis de faon que dans une cellule, les puissances reues par la station
de base (satellite) sont identiques de valeur P
0
. Dans ce cas, dans la cellule 0 on a :

K
i k
k
R
i
i k
P P K
sfP
SNR
1 1
0 ) , ( 0
0
) 1 (
3
(4.4)
On nglige le bruit blanc et on suppose que le signal de lutilisateur k dans la cellule i est reu
par la station de base 0 avec une puissance de P
(k,i)0
. prenons maintenant le cas o
linterfrence reue par les autres cellules est proportionnelle linterfrence totale dans la
cellule considre avec un facteur de f.
) 1 )( 1 (
3
) 1 ( ) 1 (
3
0 0
0
f K
sf
fP K P K
sfP
SNR
+

+
(4.5)
Dans [7] on calcule ce rapport pour plusieurs cas de systme. Dans cette thse, on suppose
que lattnuation du signal est dordre 4 et donc proportionnel la 4
me
puissance de la
- 59 - 59
distance parcourue. Dautre part, on considre le cas de handoff souple (soft-handoff) et le
rapport f varie entre 0.44 et 0.75 pour des dviations standards entre 0 et 10.
Si la longueur dun paquet est de L et en utilisant un code correcteur derreur qui peut corriger
jusqu t erreurs et si Q
e
= 1 - P
e
est la probabilit quun bit est bien reu, la probabilit de
succs dun tel paquet est :
i L
e
i
t
i
e
i
L E
Q Q C K Q

) ( ) 1 ( ) (
0
(4.6)
et la probabilit derreur dun paquet due linterfrence est :
P
error
(K) = 1 Q
E
(K) (4.7)
Cette probabilit dtermine un facteur essentiel dans le calcul de la QoS pour une telle
application. Pour expliquer le comportement de cette probabilit on prend lexemple avec sf
=16, f = 0.5, L = 160bits, t = 10, do la figure 4.1 qui dtermine la probabilit quun paquet
soit correctement reu par la station de base pour diffrents cas de codes simultans.

0 5 10 15 20 25 30
0.4
0.5
0.6
0.7
0.8
0.9
1
1.1
nombre de codes simultans



p
r
o
b
a
b
i
l
i
t


d
e

s
u
c
c

s


Figure 4.1 Graphe reprsentatif du CDMA
Lutilisation de cette technique par les diffrents services doit garantir une qualit de service
bien prcise pour chaque utilisateur. Ceci impose diffrents paramtres pour chaque type de
service. Le systme peut tre divis en sous-systme de voix et de donne.
Par exemple, daprs la figure 4.1 on remarque que lerreur augmente considrablement aprs
une limite donne. On peut dterminer le seuil pour une qualit de service acceptable pour les
utilisateurs voix et data. Une erreur infrieure 1% est ncessaire pour les utilisateurs voix et
0.1% pour les utilisateurs data [39]. Ceci donne des seuils de 20 et 18 pour les utilisateurs
voix et data, simultanment.
4.3 Le protocole S-CDMA
Dans le protocole S-CDMA, le temps est divis en trames o plusieurs utilisateurs peuvent
envoyer en mme temps mais sur diffrents codes. Un utilisateur qui voit une rafale, doit
choisir un code puis envoyer ses paquets dessus. Le code peut tre choisi alatoirement ou
associ lutilisateur lors de son entre dans le systme aprs avoir t accept par la fonction
CAC. Un utilisateur envoie sur ce code quand il a des paquets transmettre. Si le nombre de
- 60 - 60
codes utiliss simultanment est trs lev, la probabilit derreur augmente
considrablement. Il faut limiter le nombre maximal de codes utiliss simultanment. Pour
cette raison, au dbut de chaque trame, une probabilit de permission est diffuse aux
diffrents utilisateurs pour limiter laccs des utilisateurs aux codes. Cette probabilit est une
fonction de nombre de codes utiliss dans la trame prcdente. La fonction de permission
dpend de la qualit de service demand par lutilisateur et doit tre diffrente pour le sous-
systme voix et le sous-systme data. Dans le contexte de satellite, il est ncessaire de dfinir
la fonction de permission convenable pour chacun des sous-systmes afin dobtenir la
meilleure performance.
Notons quen CDMA, la collision nest pas dfinie comme en TDMA. Plusieurs utilisateurs
peuvent envoyer en mme temps mais sur plusieurs codes sans risque de perdre les paquets
envoys. On observe plutt une augmentation de linterfrence qui, sous une limite donne,
augmente lgrement la probabilit de perdre un paquet. Cette interfrence proportionnelle au
nombre dutilisateurs simultans augmente rapidement aprs un seuil donn o la probabilit
de perdre de paquet devient considrable. Cest l o on parle dune collision CDMA. On
dfinit alors la collision comme tant le fait que le nombre dutilisateurs simultans dpasse la
limite de la QoS pour un type de service.
4.3.1 Sous-systme voix
Un paquet vocal est form par des bits produits par une source voix pendant T
f
avec une
entte de H
v
bits. Le canal est reprsent dans ce cas par un code qui supporte un dbit gal au
dbit de la source de voix. La notion des slots ne se pose pas dans ce cas puisquune trame
reprsente un slot.
Les sources de trafic voix sont modlises par une chane de Markov ON-OFF comme dcrit
dans le chapitre 3. A lentre dun utilisateur dans le systme aprs tre accept par la
fonction de contrle dadmission CAC, on lui associe un code CDMA qui peut tre utilis
chaque fois quun talkspurt arrive. Ceci est possible puisque le nombre de codes dans le
systme est suprieur au nombre maximal de codes qui garantit une QoS accepte et aussi au
nombre dutilisateurs accepts (des codes PN Pseudo-Noise de nombre illimit sont utiliss
[78]).
Quand la source de trafic passe de ltat OFF ltat ON, lutilisateur doit employer son code
pour transmettre les paquets. Il se peut que le nombre total de codes utiliss soit lev et
quun nouveau code perturbe la qualit du canal et influence tous les autres utilisateurs. Pour
cette raison, on introduit la fonction de permission p
v
(x) o x est le nombre de codes utiliss
simultanment. Un utilisateur doit faire un tirage de Bernoulli de paramtre p
v
(x) (il transmet
avec une probabilit p
v
(x) et ne transmet pas avec une probabilit 1- p
v
(x)). Sil russit ce
tirage, il transmet son paquet sur son code et attend la rponse de la station de base (satellite).
Si la rponse est positive, il commence envoyer ses paquets sur son propre code. Dans le cas
contraire il doit refaire le tirage de Bernoulli.
Un paquet vocal ne peut pas attendre plus que D
max
avant dtre envoy. Ce paramtre est
comparable au temps aller-retour (RTD) en LEOS. Puisque lutilisateur ne reoit la rponse
quaprs un RTD T
f
, si cette rponse est ngative il ne pourra plus tenter pour le mme
paquet car le dlai dattente maximal D
max
est coul. Le paquet est donc rejet et on essaye
denvoyer le paquet suivant, cest la probabilit de rejet drop P
drop
. Lautre raison de perte
est lerreur due linterfrence des autres utilisateurs en CDMA et cest la probabilit
- 61 - 61
derreur P
error
. Ces deux probabilits contribuent dans la probabilit de perte dun paquet qui
est donc :
P
loss
= P
error
+ P
drop
(4.8)
Remarquons ce stade que ces deux probabilits sont inversement dpendantes, puisque si la
fonction de permission est restrictive, les tirages de Bernoulli chouent plus souvent et le rejet
des paquets augmente. Par contre, si cette fonction est gnreuse, le nombre de codes utiliss
simultanment augmente et la probabilit derreur augmente. Un cas particulier est lorsque la
fonction de permission est constamment gale 1 , la probabilit de rejet est zro et la
probabilit de perte est similaire la probabilit derreur.
Notons enfin quon na pas besoin dun tampon pour les utilisateurs vocaux puisquun paquet
gnr est soit transmis directement soit perdu, ce qui nest pas le cas pour le sous-systme de
donne.
4.3.2 Sous-systme de donne
Le sous-systme de donne contient un trafic de type ABR. Les sources de data utiliss dans
ce chapitre reprsentent les sources de fichiers et les sources de messages lectroniques
emails. Le modle de fichiers est prsent dans le chapitre prcdent et va tre tudi
analytiquement et par simulation en cas de CDMA. On sintresse maintenant aux sources
emails qui sont beaucoup plus complexes et vont tre tudies par simulation.
Dans le gnrateur de trafic Email, on considre que lutilisateur commence envoyer
plusieurs Emails, puis sarrte pour une longue priode et ainsi de suite [36, 37]. On appelle
session la srie des Emails envoys pendant une priode relativement courte. Dans une
session, il y a plusieurs messages envoys spars par des intervalles de temps correspondant
au temps de rdaction dun message. Chaque message est constitu des plusieurs rafales
spares par des intervalles distribus gomtriquement et la taille dune rafale suit la
distribution de Pareto tronque.

Appel Rdaction
session
Temps entre session

Figure 4.2 Source de trafic Email
Le temps entre deux sessions est exponentiel de paramtre , le nombre dappel dans une
session est gomtrique de moyenne N
p
, le temps de rdaction est gomtrique de moyenne
T
R
, le nombre de rafales dans un appel est gomtrique de moyenne N
b
, le temps sparant
deux rafales conscutives est gomtrique de moyenne T
sep
. Enfin, les paramtres de
distribution de Pareto sont et k et la longueur moyenne dune rafale est L
w
paquets.
A larrive dune rafale, lutilisateur doit envoyer les paquets sur un code donn. Il se peut
que le nombre total de codes utiliss soit lev et quun nouveau code perturbe la qualit du
canal et influence tous les autres utilisateurs. Pour cette raison, on introduit la fonction de
permission p
d
(x) o x est le nombre de codes utiliss simultanment dans la trame prcdente.
Un utilisateur doit faire un tirage de Bernoulli de paramtre p
d
(x) (il transmet avec une
- 62 - 62
probabilit p
d
(x) et ne transmet pas avec une probabilit 1- p
d
(x)). Sil russit ce tirage, il
transmet son paquet sur son code et attend la rponse de la station de base (satellite). Si la
rponse est positive il commence envoyer ses paquets sur le code. Dans le cas contraire il
doit refaire le tirage de Bernoulli.
Un paquet data peut attendre longtemps avant dtre envoy. Ce temps dattente est beaucoup
plus grand que le temps aller-retour (RTD) en LEOS. Un utilisateur reoit la rponse de son
paquet aprs RTD et dcide de continuer la transmission ou dattendre que le systme soit
moins charg. On ne jette jamais un paquet pour chec du tirage de Bernoulli puisquun
paquet peut attendre longtemps dans le tampon qui est suppos infini. La seule raison de perte
est donc lerreur due linterfrence des autres utilisateurs en CDMA, cest la probabilit
derreur P
error
. La probabilit de perte dun paquet est donc :
P
loss
= P
error
(4.9)
Remarquons ce stade que le temps dattente dun paquet dans le tampon et la probabilit de
perte sont inversement dpendantes, puisque si la fonction de permission est restrictive les
tirages de Bernoulli chouent plus souvent et le sjour des paquets dans le tampon augmente.
Par contre si cette fonction est gnreuse le nombre de codes utiliss simultanment augmente
et la probabilit derreur augmente.
On suppose quaucun retransmission est possible au niveau MAC et par suite un paquet perdu
cause dinterfrence daccs multiple CDMA est perdu. La retransmission peut se faire sur
le niveau lien avec la fonction RLC (Retransmission Link Control). Pour cette raison, et
puisque la probabilit de perte acceptable par le service ABR est trs petite, la fonction de
permission doit tre trs restrictive pour limiter le nombre de codes simultans et donc la
probabilit de perte. Ceci a linconvnient daugmenter le temps de sjour dun paquet data
dans le tampon.
4.4 Les services
Dans ce chapitre, les services dfinis sont analogues ceux utiliss dans le chapitre prcdant
mais avec quelques amliorations. On dfinit deux MTCs au niveau MAC. La diffrence
principale entre ces deux MTCs est le dlai dattente et la probabilit de perte dun paquet. Le
premier est nomm RTC (Rapid Transfer Capability) et le deuxime est nomm STC (Slow
Transfer Capability).
RTC doit garantir une transmission rapide des paquets gnrs par la source ; ceci est
souhaitable par les services temps rels. La ralisation de cette rapidit se fait sur deux
niveaux. Niveau dappel, par la fonction CAC, qui doit refuser une telle demande si
elle estime que la couche MAC est incapable de garantir un temps rel et niveau de
paquet par un contrle de trafic accompli par la couche MAC par lintermdiaire des
probabilits de permission.
Un mapping est possible entre RTC et les services variables temps rel qui
reprsentent le trafic vocal. Ainsi, on cite le VBRrt de lATM, service garanti ou
service premium de lIP et service conversationnel de lUMTS.
STC peut supporter un dlai avant de transmettre un paquet mais doit garantir une
probabilit de perte dun paquet trs petite. Pour garantir cette qualit de service, on
limite le nombre dutilisateurs par la fonction CAC. Le choix de la probabilit de
permission est aussi un facteur important comme on va le dmontrer dans la suite. Un
mapping entre STC et les services variables non temps rel est appropri. Ainsi, on
- 63 - 63
cite le ABR de lATM, service assur ou dbit contrl de lIP et le service de base
de lUMTS.
La diffrence entre ces deux MTCs est vue dans ce chapitre sous deux aspects ;
1 Une fonction de permission suprieure pour les utilisateurs vocaux (RTC) et donc une
priorit souple des utilisateurs vocaux par rapport aux utilisateurs data (STC). Ceci
diminue linfluence des utilisateurs data sur les utilisateurs voix dans le cas o les deux
services seraient multiplexs.
2 Un tampon pour les utilisateurs data pour stocker les paquets data en attendant une
transmission russie. Ceci est inexistant pour les utilisateurs voix. Cette technique
diminue la probabilit de perte dun paquet data. Mais notons ce stade quon na pas une
possibilit de retransmission des paquets errons comme dans le chapitre prcdent. Ceci
introduit une probabilit derreur pour les utilisateurs STC suprieure au cas du S-PRMA
o on ntudiait que le temps de sjour des paquets data o un nombre illimit des
retransmissions garantit une probabilit de perte minime.
4.5 La fonction CAC
On dfinit les indices de la couche MAC K
v
et K
d
comme tant les limites du nombre
dutilisateurs voix et data qui peuvent tre envoys simultanment avec une probabilit
acceptable derreur due laccs multiple. Soit :
P
error
(k) Pe
v
k K
v
pour les utilisateurs voix.
P
error
(k) Pe
d
k K
d
pour les utilisateurs data.
Pe
v
et Pe
d
sont les valeurs maximales de probabilit derreur accepte par les utilisateurs voix
et data, respectivement. P
error
(k) est la probabilit derreur donne par lquation 4.7 o k
reprsente les utilisateurs voix et data. En pratique Pe
v
> Pe
d
et donc K
v
> K
d
. Si le nombre
total dutilisateurs simultans est k K
d
, tous les utilisateurs voix et data sont reus avec une
qualit acceptable. Si K
d
. k K
v
donc parmi les k paquets, les paquets vocaux ont une
qualit acceptable au contraire des paquets data. Enfin, si K
v
. k tous les utilisateurs ont une
qualit de service inacceptable [38].
Par exemple, dans la figure 4.1 et avec Pe
v
= 1% et Pe
d
=0.1% les indices de la couche MAC
sont K
v
= 20 et K
d
= 18. En fait, ces deux limites peuvent tre dpasses de temps en temps
sans le risque dune dgradation catastrophique de la qualit : cest le principe de graceful
degradation . Daprs ce principe il y a toujours une probabilit de rception correcte dun
paquet pour tout nombre dutilisateurs simultans. Ce principe change le principe de collision
en CDMA et le rend plus souple [40,44,45].
Ces indices ne sont pas les seuls facteurs qui dterminent les limites pour la fonction CAC
mais ils sont essentiels pour dterminer les seuils de contrle de trafic de la fonction de
permission. Pour la fonction CAC, lactivit des diffrents utilisateurs, leurs qualits de
service ainsi que la probabilit de drop jouent des rles fondamentaux [45,46]. Dautre part en
CDMA, les diffrents utilisateurs sinfluencent entre eux et pour cette raison, on doit
minimiser cette influence afin de respecter la qualit de service de chaque utilisateur.
La fonction CAC utilise dans ce chapitre est oriente QoS. On accepte un utilisateur si on
estime quil ne va pas dgrader la QoS des autres utilisateurs et si on peut respecter sa qualit
demande. Les deux services voix et data sont reprsents au niveau MAC par le RTC et
STC, respectivement.
Un utilisateur RTC qui demande une connexion est accept si la partie de ressource quil
consomme est disponible. Dans le cas positif, on accepte lutilisateur et lensemble de
- 64 - 64
ressources est diminu de cette quantit. La dtermination de cette quantit va tre value par
le calcul et la simulation.
De mme, un utilisateur STC qui demande une connexion, est accept si la partie de ressource
quil consomme est disponible. Dans le cas positif, lensemble de ressources est diminu de
cette quantit. La dtermination de cette quantit va tre value par simulation pour les
modles des Emails qui sont trs complexes tudier analytiquement. Ltude analytique est
possible pour les modles de transfert de fichier.
4.6 Le contrle de trafic
Le contrle de trafic est ralis en CDMA par la fonction de permission afin dajuster le
nombre total dutilisateurs simultans. Le contrle doit prendre en compte la qualit de
service demande [43]. Donc, une fonction de permission est associe chaque type de
service. Pour les utilisateurs voix, la fonction doit respecter une perte maximale gnre par
des erreurs et des rejets. Le but est dobtenir une capacit maximale tout en respectant la QoS.
Dautre part, pour les utilisateurs data, il faut respecter une probabilit derreur limite ainsi
quun dlai moyen raisonnable. Notons que lorsque tous les utilisateurs sont multiplexs
ensemble, les fonctions de permission pour chaque service doivent garantir une priorit pour
un type de service qui est le RTC (voix) par rapport STC (data).
Pour les utilisateurs voix, un nouveau talkspurt perd un paquet chaque fois quil choue son
tirage de Bernoulli. Pour cette raison, la permission doit tre leve. La fonction choisie doit
tre trs gnreuse quand le nombre dutilisateurs qui transmettent simultanment est bas.
Cette fonction a le rle de limiter le nombre total dutilisateurs sur le canal par une limite de
contrle S
v
aprs laquelle aucun accs nest permis. La fonction gnralise peut tre crite
comme suit :
v
v
v
S x
S x
x P

<

0
1
) ( (CDMA avec limite)
La limite S
v
est dterminer afin dobtenir lefficacit maximale du protocole. Notons que si
cette limite est infinie, un utilisateur peut toujours envoyer sur un code pour transmettre ses
paquets, cest le CDMA classique.



1

data voix








S
d
S
v
a
fonction de permission
nombre de codes simultans
p
r
o
b
a
b
i
l
i
t
e

d
e

p
e
r
m
i
s
s
i
o
n


Figure 4.3 Fonction de permission pour voix et data
- 65 - 65
Pour les utilisateurs data, une nouvelle rafale qui choue son titage de Bernoulli pose ses
paquets dans le tampon en attendant une rservation de code. Ces paquets ne sont pas perdus
mais leur dlai dattente augmente. Par contre, au niveau MAC, un paquet envoy ne peut pas
tre retransmis sil est perdu cause dune interfrence. Pour cette raison, la fonction de
permission doit tre trs restrictive pour les utilisateurs data. On reprsente cette fonction dans
la figure 4.3. Cette figure est trs gnrale et utilise pour introduire lide de contrle des
utilisateurs data et voix.
La fonction de contrle pour le data utilise plusieurs paramtres ; la permission zro (a),
langle dinclinaison, le point de dviation et le point de zro qui est la limite de contrle pour
les utilisateurs data (S
d
). Ces paramtres doivent tre choisis pour obtenir la meilleure
performance.
4.7 Modlisation mathmatique
Dans ce paragraphe on va modliser le protocole S-CDMA mathmatiquement afin de
pouvoir dterminer les paramtres essentiels qui dterminent sa performance. Ltude est
base sur le processus de Markov et consiste dterminer ltat stationnaire du systme en
passant par sa transition dun tat un autre. Aprs avoir calcul son comportement en
quilibre, on peut mesurer les diffrents paramtres de performance. Cette tude faite pour les
utilisateurs voix et data ncessite plusieurs simplifications pour pouvoir effectuer le calcul.
Notons que les simplifications sont ensuite justifies laide dune simulation complte du
systme en utilisant le simulateur NS (Network Simulator voir Appendice A). Enfin ltude
mathmatique est faite pour chaque type de service part, puisquil est trop compliqu de
leffectuer pour le multiplexage de service.
4.7.1 Sous-systme voix
Le sous-systme voix est constitu des sources ON-OFF qui essayent denvoyer sur un code
chaque fois quun talkspurt arrive. Laccs au canal se fait par le tirage de Bernoulli de
paramtre p
v
(x). Un utilisateur qui russit ce tirage rserve le code utilis si le nombre de
codes utiliss simultanment est infrieur S
v
. Dans le cas contraire lutilisateur doit retenter.
La figure 4.4 reprsente ce protocole.
Dans cette figure M
v
utilisateurs voix sont accepts par la fonction CAC, ces utilisateurs sont
prsents et passent de la parole au silence avec les paramtres suivants.

v
=1-exp(-T
f
/t
on
) (4.10)

v
=1-exp(-T
f
/t
off
) (4.11)
Supposons que Y
n
est le nombre de codes utiliss pendant la trame n. Si les utilisateurs
entrants et sortants sont les utilisateurs qui utilisent et librent un code simultanment, on a :
Y
n+1
= Y
n
+ (utilisateurs entrants de M
v
- Y
n
OFF sources) - (utilisateurs sortants de Y
n
ON
sources).
Le nombre dutilisateurs entrants est indpendant de nombre de codes avant n et de mme le
nombre dutilisateurs sortants. Ceci est d au fait que les sources ON-OFF sont sans mmoire.
Y
n
est donc une chane de Markov suppose homogne [29].
La matrice de transition est dfinie par la probabilit de transition de ltat x vers ltat y.
Cest la probabilit que le nombre de codes utiliss simultanment passe de x codes dans la
trame n y codes dans la trame n+1.
- 66 - 66
{ } { } { }
{ }

+
+ +
+
a
n s n e
n s e n s e n n n xy
x Y x y a NI x Y a NI
x Y y NI NI x x Y y NI NI Y x Y y Y P
) ( ) ( Pr
Pr Pr Pr
1
(4.11)
NI
e
et NI
s
reprsentent le nombre dutilisateurs entrants et sortants pendant la trame n,
respectivement.
{ } { }
{ } { } x Y x y a NI x Y a NI P y x
x Y x y a NI x Y a NI P y x
n s
y
x y a
n e xy
y
a
n s n e xy
+ <
+

Pr Pr
Pr Pr
0
(4.12)

t r a m e n t r a m e n + 1




x c o d e s y c o d e s

p
x y



M v u t i li s a t e u r s v o i x

Figure 4.4 Modle des utilisateurs voix
Les utilisateurs entrent dans le canal en provenance de deux ensembles. Le premier est
lensemble des utilisateurs qui passent de ltat OFF ltat ON pendant la trame prcdente
et le deuxime contient les utilisateurs qui passaient ltat ON dans les trames antrieures
mais qui chouaient leurs tirages de Bernoulli jusqu linstant prsent. Calculons le nombre
moyen dutilisateurs dans le second ensemble pour approcher leffet de cet ensemble sur le
comportement du canal. Ceci est une premire simplification.
Prenons la ime trame qui prcde notre trame en considration. Si h reprsente le nombre
dutilisateurs sur cette trame, le nombre moyen dutilisateurs arrivants sur cette trame est

v
(M
v
h).
Un utilisateur tente daccder sur le canal avec une probabilit P
v
(h), donc le nombre
dutilisateurs qui chouent leur tirage est :
[ ]
i
v v v i
h p h M h W ) ( 1 ) ( ) ( (4.13)
Pour un nombre donn dutilisateurs ON, la population de cet ensemble est :
[ ]
[ ]
) (
) ( 1 ) (
) ( 1 ) ( ) ( ) (
1 1
h p
h p h M
h p h M h W h W
v
v v v
i
i
v v v
i
i



(4.14)
En utilisant la probabilit quil y a h utilisateurs dans les trames prcdentes comme tant :
h M
off
h
on
h
M
v
v
C h Y

) Pr( (4.15)
le nombre moyen dlments de cet ensemble est :
- 67 - 67


v
M
h
h W h Y h W E W
0
) ( ) Pr( )) ( ( . (4.16)
En utilisant ce rsultat, on peut calculer la probabilit davoir a utilisateurs entrants dans le
canal comme suit :
{ }




x M
W a t
n e e e
x M
W a t
n e e e n e
v
v
x Y t NT t NT a NI
x Y t NT t NT a NI x Y a NI
) Pr( ) Pr(
) ( ) ( Pr ) Pr(
(4.17)
Avec NT
e
est le nombre total dutilisateurs qui passent ltat ON pendant la trame et qui
vont faire des tirages de Bernoulli :
t W x M
v
t
v
t
W x M
n e
v
v
C x Y t NT


) 1 ( ) Pr( (4.18)
NI
e
sera le nombre dutilisateurs qui russissent leur tirage, venants de (t + E(w) )
utilisateurs :
[ ] [ ]
a w t
v
a
v
a
W t
e e
x p x p C t NT a NI
+
+
) ( 1 ) ( ) Pr( (4.19)
Calculons maintenant la probabilit pour les utilisateurs sortants du canal. Ce sont les
utilisateurs qui quittent la trame n soit parce que lutilisateur passe ltat OFF, soit parce que
le nombre de codes dpassent la limite de contrle S
v
qui peut tre gale lindice de la
couche MAC pour les utilisateurs voix. Suivant la valeur de x on a trois cas :
{ }
{ }
{ } . 0 Pr , 0 ) ( & ) (
) 1 ( Pr , 0 ) ( & ) (
) 1 ( Pr
> >
>
+

+ +
x Y y x NI a S y S x si
C x Y y x NI a S y S x si
C x Y x y a NI S x si
n s v v
y
v
y S
v
y S
S n s v v
a y
v
x y a
v
x y a
x n s v
v v
v


(4.20)
Daprs ces rsultats, on peut dterminer la probabilit de transition de ltat x vers ltat y, et
alors la matrice de transition de cette chane de Markov M
v
tats (le symbole ] reprsente
une matrice) :
]
[ ]
v
v
M y
M x
xy
P P


0
0
(4.21)
daprs cette matrice on peut calculer les probabilits dtat stationnaire du canal en utilisant
le systme dquations :
] ] ]
1

k
k
P


(4.22)

k
est la probabilit quil y a k utilisateurs sur le canal en tat stationnaire. Cette probabilit
dtermine la distribution des utilisateurs sur le canal et permet de calculer la probabilit de
perte due lerreur dinterfrence CDMA ainsi que le drop cause des expriences de
Bernoulli chous.
La probabilit derreur due linterfrence en CDMA quand k codes simultans utilisent le
canal est (1-Q
E
(k)). La probabilit derreur en tat stationnaire est donc :


v
M
k
E k error
k Q P
0
)) ( 1 ( (4.23)
- 68 - 68
Dautres paquets sont perdus cause de rejet chaque fois quun tirage de Bernoulli est
chou. Si k utilisateurs envoient simultanment sur le canal, un nouvel utilisateur choue son
tirage avec une probabilit ( 1 p
v
(k) ) do :
) ( 1 ) ( k p k
v
(4.24)
La probabilit quun utilisateur attende j trames avant dtre servi est alors :
1
) 1 ( ) (


j
w
j P (4.25)
Dans notre protocole, le temps maximal dattente est une seule trame qui est proche de RTD.
Notons par D (D =1 dans notre tude) ce dlai dattente en nombre de trames.
Le nombre de paquets perdus est alors une fonction du temps dattente. Si L est la longueur
dun talkspurt en nombre de paquets, le nombre de paquets perdus est :

( )

'

+ +
+ + +

j n L D si L
k D j n k D si k
D j si
j n
drop
1 ) 1 (
1 ) 1 (
1 0
(4.26)
La probabilit que k paquets sont perdus dans un talkspurt de L paquets est :

'

+
+ +

+ +
D
x
w
n k D
n k D x
w
n L D x
w
drop
k x p
L k x p
L k x p
L k n
1
1 ) 1 (
1 ) 1 (
0 , ) (
, 0 , ) (
, ) (
) Pr( (4.27)

La probabilit de perte due un temps dattente inacceptable et pour un nombre de codes
simultans k est :

1
1
) Pr( ) (
0
L
D
L
k
drop drop
L k n k L n E (4.28)
En utilisant lquation : Pr (talksurt = L ) =
v
( 1-
v
)
L 1
(4.29)

) 1 ( 1
) ( ) Pr( ) (
0 v
D
L
drop drop
L n E L n E

(4.30)
Enfin la probabilit de drop pour un nombre donn de codes sur le canal k est:

) 1 ( 1
) (
v
D
v drop
k P

(4.31)
et la probabilit de drop totale sera donne par :

v
M
k
drop k drop
k P P
0
) ( (4.32)
La probabilit de perte dun paquet est :
P
loss
= P
error
+ P
drop
(4.33)
Cette probabilit est le paramtre significatif qui dcrit la QoS offerte pour les utilisateurs
voix. Cette QoS est dfinie dans les normes ainsi que dans le contrat du service voix. Une
perte infrieure 1% est exige. En utilisant cette valeur, on dterminera dans la suite les
- 69 - 69
diffrents facteurs qui influencent cette perte pour dterminer leurs valeurs optimales qui
maximisent la capacit du canal. Avant de passer au calcul, tudions la performance du
protocole pour les utilisateurs data reprsents dans le modle analytique par des sources de
transfert de fichiers.
4.7.2 Sous-systme de data
Le sous-systme de data tudi analytiquement contient des sources de trafic qui ont une
arrive Poissonienne de paramtre et des rafales de longueur gomtrique de moyenne L
s

paquets. Dans le chapitre 3 on a dmontr que ce systme peut tre modlis par un systme
ON-OFF de paramtre

d
=1-exp(-T
f
) (4.34)

d
=T
f
/ (L
b
/ R
s
)=1 / L
s
. (4.35)
R
s
est le dbit de la source de trafic dans ltat dmission et est gal la bande passante dun
code en CDMA. L
s
est donc le nombre moyen de paquets dans une rafale. En utilisant ces
valeurs, on peut dterminer le comportement du canal en tat stationnaire. Si M
d
utilisateurs
data sont accept par la fonction CAC, le sous-systme data est modlis par :
t r a m e n t r a m e n + 1




x c o d e s y c o d e s

p
x y



M d u ti l i s a t eu r s d a ta

Figure 4.5 Modle des utilisateurs data
A la diffrence des utilisateurs voix, un utilisateur data qui reoit une nouvelle rafale doit
effectuer un tirage avec la fonction de permission p
d
(x), et le paquet doit attendre un tirage
russi pour tre envoy. Aucun paquet nest alors rejet et la seul cause de perte est lerreur
due linterfrence. Pour calculer la distribution des utilisateurs dans ltat stationnaire, on
procde de la mme faon que les utilisateurs voix mais avec les nouveaux paramtres. On
obtient :
[ ]
i
d d d i
h p h M h W ) ( 1 ) ( ) ( (4.36)
[ ]
[ ]
) (
) ( 1 ) (
) ( 1 ) ( ) ( ) (
1 1
h p
h p h M
h p h M h W h W
d
d d d
i
i
d d d
i
i



(4.37)
Avec

h M
off
h
on
h
M
d
d
C h Y ) Pr( (4.38)


d
M
h
h W h Y h W E W
0
) ( ) Pr( )) ( ( (4.39)
- 70 - 70
en utilisant ce rsultat on peut calculer la probabilit que a utilisateurs entrent dans le canal
comme suit :
{ }




x M
W a t
n e e e
x M
W a t
n e e e n e
d
d
x Y t NT t NT a NI
x Y t NT t NT a NI x Y a NI
) Pr( ) Pr(
) ( ) ( Pr ) Pr(
(4.40)
avec
t W x M
d
t
d
t
W x M
n e
d
d
C x Y t NT


) 1 ( ) Pr( (4.41)
[ ] [ ]
a w t
d
a
d
a
W t
e e
x p x p C t NT a NI
+
+
) ( 1 ) ( ) Pr( (4.42)
Calculons maintenant la probabilit des utilisateurs sortants du canal. Cest les utilisateurs qui
quittent la trame n soit parce que lutilisateur passe ltat OFF, soit parce que le nombre de
codes dpasse la limite de contrle S
d
qui peut tre gale lindice de la couche MAC pour
les utilisateurs data. Do :
{ }
{ }
{ } . 0 Pr , 0 ) ( & ) (
) 1 ( Pr , 0 ) ( & ) (
) 1 ( Pr
> >
>
+

+ +
x Y y x NI a S y S x si
C x Y y x NI a S y S x si
C x Y x y a NI S x si
n s d d
y
d
y S
d
y S
S n s d d
a y
d
x y a
d
x y a
x n s d
v v
v


(4.43)
Daprs ces rsultats, on peut dterminer la probabilit de transition de ltat x vers ltat y, et
alors la matrice de transition de cette chane de Markov M
d
tats :

]
[ ]
d
d
M y
M x
xy
P P


0
0
(4.44)
daprs cette matrice on peut calculer les probabilits dtat stationnaire du canal en utilisant
le systme dquation :
] ] ]
1

k
k
P


(4.45)
La probabilit derreur due linterfrence en CDMA quand k codes simultans utilisent le
canal est (1-Q
E
(k)). La probabilit derreur en tat dquilibre est donc :


d
M
k
E k error
k Q P
0
)) ( 1 ( (4.46)
Cette probabilit est gale la probabilit de perte puisquon considre que la probabilit de
drop est zro.
P
loss
= P
error
(4.47)
Dautre part, un paquet doit attendre dans le tampon avant dtre servi, le temps dattente est
dfini comme tant le temps entre larriv du paquet et sa transmission via un code CDMA.
La valeur moyenne de ce temps est un facteur important pour dcrire la QoS des utilisateurs
data.
En tat stationnaire la probabilit quun paquet attende m trames est donne par :
- 71 - 71
. ) ( )) ( 1 ( ) Pr(
1
0
1
0

1
]
1


1
]
1


m
M
i
d i
m
M
i
d i
d d
i p i p m d (4.48)
Le premier facteur reprsente la probabilit dchec dun tirage de Bernoulli dans les
diffrents cas de nombre de codes simultans. Le deuxime est la probabilit de succs.
La valeur moyenne de ce dlai est donc :
2
0
1
0
) 1 (
) Pr(

m
m
m
m m m d d
(4.49)
Ce dlai est une fonction de la probabilit de permission pour les utilisateurs data. Si cette
permission augmente, le dlai diminue mais la probabilit de perte augmente. Lessentiel est
de trouver un compromis entre le dlai dattente et la probabilit derreur tout en maximisant
la capacit du systme [42,43].
Notons que cette tude, faite pour les sources de transfert de fichiers, va tre valide par des
simulations qui justifient les simplifications faites sur le modle. Les autres sources dEmail
ne sont tudies que par des simulations ainsi que le multiplexage des utilisateurs voix et data.
4.8 Discussions analytiques et par simulation
Dans ce paragraphe, on va tudier la performance du protocole S-CDMA pour diffrents
types dutilisateurs. On tudie en premire tape chaque service part pour dterminer les
paramtres optimaux dans le cas des utilisateurs identiques (que des voix ou que des data). En
seconde tape, on mlange les diffrents utilisateurs dans le mme sceau et on calcule la
performance du systme. On remarque que les sources de trafic sont htrognes dans ce
dernier cas, ainsi que la qualit de service demande. La capacit totale du systme est
mesure et maximise. La fonction de permission joue un rle essentiel dans cette capacit et
doit tre choisie pour avoir une capacit maximale tout en respectant la QoS demande par les
diffrentes applications reprsentes dans la couche MAC par deux MTCs ; le RTC (Rapid
Transfer Capability) et le STC (Slow Transfer Capability).
Le simulateur NS est utilis pour simuler un systme LEOS comme dcrit dans le deuxime
chapitre. Une technologie multi-faisceaux est utilise. Dans chaque faisceau on a 24
frquences porteuses. Chaque frquence a une bande passante montante gale la bande
passante descendante gale 155Kb/s. Le G/W a une bande de 155Mb/s ainsi que la liaison
inter-satellite. Les cellules utilises au niveau MAC sont insres dans des trames de dure
20ms. la longueur dun paquet (cellule) peut tre calcule par :(155 20) /sf = 194 soit 194
bits avec les enttes et 160 bits sans les enttes (qui donne aux voix le dbit de 8Kb/s au
niveau application et 9.6Kb/s au niveau MAC).
4.8.1 Le RTC (utilisateurs voix)
Pour les utilisateurs voix, le problme essentiel rsoudre est le choix de la fonction de
permission qui permet lacceptation dun maximum dutilisateurs avec une qualit de service
reprsent essentiellement par une probabilit de perte infrieure 1% et un temps rel de
transmission ralis par un temps dattente maximal dune seule trame 20ms.
Les paramtres utiliss pour les sources ON-OFF sont dcris dans [41] et rsums par :
Le temps moyen de parole est de t
on
= 1 seconde.
Le temps moyen de silence est de t
off
= 1.35 secondes
La limite de QoS est alors : 20 %) 1 ) ( max( k P k K
error v

- 72 - 72
Les deux fonctions comparer sont une fonction sans limite et qui reprsente le CDMA
classique et une deuxime qui a lindice de la couche MAC comme limite.
x x f x p
v
1 ) ( 1 ) ( (CDMA classique)

v
v
v
K x
K x
x f x p

<

0
1
) ( 2 ) ( (CDMA avec limite S
v
= K
v
).
Les autres possibilits des fonctions sont exclues puisquon remarque que la perte devient
rapidement inacceptable ds que la fonction diminue. Dautre part, les comparaisons faites
dans cette section donnent des rsultats pour le cas dutilisateurs identiques et ne peuvent pas
tre gnraliss dans le cas de multiplexage de services o des simulations sont utilises pour
dcrire le systme.
Pour le CDMA classique, il ny a pas de limite sur laccs au canal et un utilisateur qui a
besoin denvoyer des paquets utilise un code immdiatement. Ceci est reprsent par la
premire fonction de permission (f1) et a leffet daugmenter le nombre dutilisateurs
simultans et donc le nombre de codes actifs. Linterfrence CDMA augmente et aussi la
probabilit derreur, mais la probabilit de drop est absolument zro. Dans la figure 4.6, on
reprsente la distribution des utilisateurs en calculant les codes actifs sur le canal. Quand le
nombre dutilisateurs passe de 25 40, les probabilits quil y a un plus grand nombre de
codes actifs augmentent. La limite du nombre dutilisateurs est calcule dans la suite.
Passons maintenant au cas de la deuxime fonction de permission. Dans ce cas, on essaye de
limiter le nombre de codes actifs lindice de la couche MAC pour les utilisateurs voix (K
v
).
Quand les codes simultans dpassent cette limite, aucune permission au canal nest autorise.
On remarque dans la figure 4.7 que lorsque le nombre dutilisateurs augmente, la probabilit
que les codes actifs soit dans la proximit de cette limite augmente. Lapproche de nombre de
codes actifs vers la limite est rgulire de 25 jusqu 35 utilisateurs. Quand ce nombre devient
40, le graphe devient anormal. Ceci est d la congestion. En effet, la plupart de temps les
utilisateurs actifs dpassent la limite et la probabilit de permission devient zro, tous les
utilisateurs quittent le canal et la permission redevient 1. Le comportement du systme est
alors instable. La dmonstration de cette remarque est le fait que quand le nombre de codes
actifs est suprieur K
v
la probabilit de permission devient 0 et tous les nouveaux
utilisateurs doivent quitter le canal. Dans ce cas le nombre de codes actifs devient infrieur
cette limite et la permission prend la valeur 1. Notons que dans la zone stable, les probabilits
que les codes simultans dpassent la limite de QoS est petite et ainsi la probabilit derreur.
Mais la probabilit de drop est considrable ce qui augmente la perte comme on peut voir
dans la figure 4.10.
Avant de passer la comparaison des deux fonctions de permission, on prsente des graphes
de simulation dans les figures 4.8 et 4.9. On remarque statistiquement les mme valeurs de
distribution des utilisateurs. Le nombre de codes actifs reprsente le nombre total
dutilisateurs sur le canal. Ce nombre augmente lorsque le nombre total dutilisateurs accepts
par la fonction CAC augmente pour les deux cas de CDMA. Ce nombre est centralis autour
de la limite de contrle dans le cas de f2(x). On remarque aussi que lorsque le nombre
dutilisateurs est 40 dans le second cas, les utilisateurs oscillent autour de la limite dune
faon instable et le nombre de codes actifs varie dune faon rapide entre des valeurs trs
leves par rapport la limite de contrle et des autres infrieurs cette limite. Ceci est leffet
- 73 - 73
du fait que la probabilit de permission oscille entre 1 et 0. Calculons maintenant la capacit
du systme dans chaque cas de contrle.







K
v
0 5 10 15 20 25 30 35 40
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
distribution des utilisateurs en cas de f1(x)
25, 30, 35 et 40 utilisateurs accepts
de gauche droite
nombre de codes actifs




p
r
o
b
a
b
i
l
i
t


d
e

x

c
o
d
e
s

a
c
t
i
f
s


Figure 4.6 Distribution des utilisateurs voix en CDMA classique (analytique)







K
v
= S
v
0 5 10 15 20 25 30 35 40
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
distribution des utilisateurs en cas de f2(x)
25, 30, 35 et 40 utilisateurs accepts
de gauche droite.
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t


d
e

x

c
o
d
e
s

a
c
t
i
f
s


Figure 4.7 Distribution des utilisateurs voix en CDMA avec limite (analytique)

- 74 - 74

0 200 400 600 800 1000 1200 1400
8
10
12
14
16
18
20
22
30 utilisateurs voix f1(x)
tranche de temps pendant la periode stationnaire
N
o
m
b
r
e

d
e

c
o
d
e
s

a
c
t
i
f
s


0 500 1000 1500
0
5
10
15
20
25
30
40 utilisateurs voix f1(x)
tranche de temps pendant la periode stationnaire
N
o
m
b
r
e

d
e

c
o
d
e
s

a
c
t
i
f
s


Figure 4.8 Distribution des utilisateurs voix
en cas de f1(x) , simulation

0 500 100
0
150
0
200
0
10
15
20
25
30 utilisateurs voix f2(x)
tranche de temps pendant la periode stationnaire
N
o
m
b
r
e

d
e

c
o
d
e
s

a
c
t
i
f
s


0 500 100
0
150
0
200
0
250
0
300
0
350
0
400
0
10
15
20
25
30
35
40 utilisateurs voix f2(x)
tranche de temps pendant la periode stationnaire
N
o
m
b
r
e

d
e

c
o
d
e
s

a
c
t
i
f
s


Figure 4.9 Distribution des utilisateurs voix
en cas de f2(x), simulation
La figure 4.10 compare les deux fonctions de permission en calculant la probabilit de perte
en fonction de nombre dutilisateurs accepts par la fonction CAC. On remarque que le
nombre maximal accept par la premire fonction est de 38 utilisateurs alors que 32
utilisateurs peuvent tre accepts avec une perte<1% quand la seconde fonction est utilise.
Ceci est spcialement d la probabilit de perte trs leve dans le deuxime cas caus
principalement par un pourcentage des paquets rejets (probabilit de drop) lev. Notons
que, pour f2(x), la probabilit de perte est proche de 1 (la plupart des paquets sont perdus)
quand le nombre dutilisateurs est gal 40. Ceci est caus par la congestion et linstabilit du
- 75 - 75
systme dmontre prcdemment. Enfin, le calcul et la simulation sont trs proches ce qui
montre la validit de notre modle analytique simplifi.

0 5 10 15 20 25 30 35 40
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
0.016
0.018
comparaison des fonctions de permission
o,. f2(x) analytique et simulation
x,* f1(x) analytique et simulation
nombre d utilisateurs
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 4.10 Probabilit de perte, analyse et simulation
Pour calculer le paramtre de dcision de la fonction CAC, qui est le pourcentage de code
consomm par un utilisateur, on prend le CDMA classique en considration. Dans ce cas, 38
utilisateurs sont accepts sur 16 codes (le spreading factor), le pourcentage de code
consomm est alors 16/38 = 0.42. Ce pourcentage est la base de dcision de la fonction
CAC comme expliqu dans le paragraphe 4.3. On remarque dautre part que la consommation
est infrieure en S-CDMA quen S-PRMA (ctait 0.5) et la capacit de systme est
suprieure. La comparaison dtaille des diffrents protocoles est tudi dans le chapitre 6.
4.8.2 Le STC (utilisateurs data)
Dans cette section, on va tudier le comportement du canal pour des utilisateurs data. On
considre en premier lieu des utilisateurs de transfert de fichiers avec les paramtres suivants :
Taux darrive par seconde est = 0.5.
Longueur moyen dune rafale est L
s
= 100 paquets.
Ces utilisateurs sont tudis analytiquement et par simulation afin de dterminer les
paramtres de la fonction de permission qui donnent les meilleurs rsultats.
On considre deux fonctions de permission f1(x) et f2(x). Ces deux fonctions diffrent par la
limite de contrle S
d
qui est de 18 (lgrement suprieure lindice de la couche MAC pour
les utilisateurs data) et 17 (lgrement infrieure lindice de la couche MAC pour les
utilisateurs data). La permission zro est toujours de 0.3 et le point de dviation est gal au
spreading factor 16. Ces fonctions sont prsentes dans la figure 4.11.
- 76 - 76

0 5 10 15 20 25
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
fonctions de permission
* f2(x)
o f1(x)
nombre de codes simultans
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n


Figure 4.11 Fonctions de permission pour data
Dans les figures 4.12 et 4.13, on trace la distribution des codes en fonction du nombre
dutilisateurs accepts par la fonction CAC et pour les deux fonctions de distribution. Dans
4.12 les codes actifs sont calculs pour 30, 35, 40 et 45 utilisateurs accepts. Lorsque le
nombre dutilisateurs augmente, la probabilit que le nombre de codes actifs soit gal la
limite de contrle augmente. Quand le nombre dutilisateurs est de 40 et 45, une probabilit
de dpasser cette limite est forte et la probabilit de perte est considrable.
Dans la figure 4.13, on essaye de rsoudre ce problme en diminuant le seuil de contrle.
Dans ce cas, on remarque que le nombre de codes actifs reste la plupart de temps dans la
limite de la QoS ncessaire pour le data qui est prsent par lindice de la couche MAC. La
probabilit de perte est diminue dans ce cas mais le temps dattente est cens augmenter.
Les rsultats de simulation sont prsents dans la figure 4.14. On observe dans cette figure le
nombre de codes actifs qui est proportionnel au nombre dutilisateurs accepts. Dans ce
graphe, on remarque que la plupart du temps le nombre de codes actifs est autour de la limite
de contrle. Quand le nombre total dpasse la limite, la fonction doit interdire laccs aux
autres utilisateurs et lexcs quitte le canal immdiatement. Notons que le nombre de codes
qui garantit une QoS accepte pour les utilisateurs data (perte<0.1%) est entre 17 et 18.
Une remarque importante dans ces figures est le fait que la probabilit de dpasser la limite de
contrle nest pas ngligeable dans le cas o plusieurs utilisateurs sont accepts dans le
systme. En effet, quand 45 utilisateurs sont accepts dans le cas de la premire fonction,
cette probabilit est de 0.2. Ceci est d au fait quen S-CDMA, les utilisateurs data attendent
dans un tampon la libration dun code pour accder au canal. Quand le nombre dutilisateurs
en attente est lev et lorsquun code se libre, plusieurs utilisateurs accdent au canal pour
utiliser ce code, ce qui provoque une collision CDMA (dpassement de la limite de QoS).
Pour cette raison, la limite est baisse dans la fonction f2(x), et le problme est attnu. La
diffrence majeure entre 4.12 et 4.13 est la probabilit davoir plus que 18 codes actifs qui est
infrieure pour la fonction f2 ce qui diminue la probabilit de perte considrablement comme
on voit dans la figure 4.15.

- 77 - 77







K
d
=18
0 5 10 15 20 25 30 35 40 45
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
distribution des utilisateurs en cas de f1(x)
30, 35, 40 et 45 utilisateurs accepts
de gauche droite
nombre de codes actifs


p
r
o
b
a
b
i
l
i
t


d
e

x

c
o
d
e
s

a
c
t
i
f
s


Figure 4.12 Distribution des utilisateurs data en cas de f1(x), analyse






K
d
=18
0 5 10 15 20 25 30 35 40 45
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
distribution des utilisateurs en cas de f2(x)
30, 35, 40 et 45 utilisateurs accepts
de gauche droite
nombre de codes actifs
p
r
o
b
a
b
i
l
i
t


d
e

x

c
o
d
e
s

a
c
t
i
f
s


Figure 4.13 Distribution des utilisateurs data en cas de f2(x), analyse
- 78 - 78

0 50
0
100
0
150
0
200
0
10
12
14
16
18
20
22
30 utilisateurs data f1(x)
tranche de temps pendant la periode stationnaire
N
o
m
b
r
e

d
e

c
o
d
e
s

a
c
t
i
f
s


0 50
0
100
0
150
0
200
0
8
10
12
14
16
18
20
22
30 utilisateurs data f2(x)
tranche de temps pendant la periode stationnaire
N
o
m
b
r
e

d
e

c
o
d
e
s

a
c
t
i
f
s


Figure 4.14 Distribution des utilisateurs data en cas de f1(x) et f2(x), simulation
Dans la figure 4.15 on prsente la probabilit de perte des paquets par calcul mathmatique en
utilisant notre modle dj dcrit et par simulation en utilisant NS. Les graphes presque
confondus valident notre tude. Dautre part, on remarque que la deuxime fonction de
permission diminue considrablement la perte. On peut accepter jusqu 40 utilisateurs data
avec une perte de 0.1%. Cette fonction augmente considrablement la capacit du systme
mais augmente aussi le dlai dattente dans le tampon comme on peut le constater dans la
figure 4.16. La remarque importante est le fait que la petite diffrence entre les fonctions f1 et
f2 qui se traduit dans les figures 4.12 et 4.13 par une probabilit datteindre la limite de QoS
lgrement infrieure pour f2 que pour f1, engendre une diffrence trs importante en terme
de la capacit du systme.
Dans 4.16 et pour 40 utilisateurs, le temps moyen dattente dun paquet est de 1400ms pour la
fonction f2(x) et 1000ms pour la fonction f1(x). Ceci nest pas dramatique puisque les
utilisateurs data peuvent attendre longtemps dans un tampon considr illimit. Dautre part,
on a pris une longueur moyenne des rafales de 100 paquets, ceci ncessite 2s pour tre
envoy, et le temps moyen dmettre une rafale sera de 3.4s. Dautre part, larrive dune
rafale est Poissonien de taux 0.5 et le temps moyen dattente dune arrive est de 2s qui est
infrieur au temps moyen dattente dun paquet dans le tampon. Ceci rend le systme stable.
Cette discussion a orient notre choix de la fonction de permission puisquil faut savoir
quune fonction de permission plus restrictive augmente toujours la capacit du systme mais
aussi le temps dattente.
Passons maintenant aux utilisateurs Emails. Les paramtres de ce systme sont pris des
normes ETSI dcrit dans [36] :
Le temps entre session est exponentiel de paramtre = 1/(60mn) = 0.00027.
Le nombre dappel dans une session est gomtrique de moyen N
p
= 5.
Le temps de rdaction est gomtrique de moyen T
R
= 180s.
Le nombre de rafales dans un appel est gomtrique de moyen N
b
= 10.
Le temps sparant deux rafales conscutives est gomtrique de moyen T
sep
.= 0.0625s.
Enfin les paramtres de distribution de Pareto sont = 1.1, k = 81.5 et le moyen dune rafale
est L
w
= 24paquets.
- 79 - 79

0 5 10 15 20 25 30 35 40 45
0
0.5
1
1.5
2
2.5
3
3.5
4
x 10
-3
perte des paquets data
*,+ permission f1(x), analytique et simulation
o,. permission f2(x), analytique et simulation
nombre dutilisateurs
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 4.15 Probabilit de perte (transfert des fichiers), analyse et simulation

0 5 10 15 20 25 30 35 40 45
0
200
400
600
800
1000
1200
1400
1600
1800
dlai de paquet
*,+ permission f1(x), analytique et simulation
o,. permission f2(x), analytique et simulation
nombre dutilisateurs
d

l
a
i


Figure 4.16 Dlai d'attente (transfert des fichiers), analyse et simulation
Dans les figures 4.17 et 4.18, la probabilit de perte ainsi que le dlai dattente sont prsents
pour les utilisateurs Emails et dans les deux cas des fonctions de permission. On remarque
toujours que la deuxime fonction augmente considrablement la capacit du systme qui
atteint 700 utilisateurs Emails alors quavec la premire fonction, on ne peut accepter que 500
utilisateurs. Dautre part, le dlai dattente augmente dans le cas de la deuxime fonction et
atteint 4000ms la limite de la fonction CAC (qui est 700 utilisateurs dans ce cas). Notons
que le simulateur NS est utilis dans le calcul de ces rsultats et que le tampon est considr
illimit et aucun paquet nest perdu cause du remplissage du tampon.
- 80 - 80

0 100 200 300 400 500 600 700
0
1
2
3
4
5
6
7
8
9
x 10
-3
perte de paquet (Email)
* permission f2(x)
o permission f1(x)
nombre dutilisateurs
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 4.17 Probabilit de perte (Email), simulation

0 100 200 300 400 500 600 700
0
500
1000
1500
2000
2500
3000
3500
4000
dlai de paquet Email
* permission f2(x)
o permission f1(x)
nombre dutilisateurs
d

l
a
i


Figure 4.18 Dlai d'attente (Email), simulation
4.8.3 Multiplexage de services (utilisateurs voix et data)
Dans cette section, on tudie brivement le multiplexage des utilisateurs voix et data dans le
mme canal. Les utilisateurs voix sont toujours considrs comme RTC et les utilisateurs data
comme STC. Les utilisateurs voix sont toujours des sources ON-OFF tandis que les sources
Emails reprsentent les utilisateurs data. Le multiplexage ralis doit garantir la QoS
demande par chaque utilisateur. Un utilisateur voix naccepte pas une attente suprieure au
temps dune trame et une perte suprieure 1%, alors quun utilisateur data peut attendre
longtemps avant dtre servi mais naccepte pas une perte suprieure 0.1%. Puisquen
CDMA un utilisateur peut influencer tous les autres cause dinterfrence, des techniques
- 81 - 81
spciales sont ncessaires pour diminuer leffet dun tel type de service sur lautre. Par
exemple les utilisateurs voix acceptent une perte suprieure aux utilisateurs data donc leur
indice de la couche MAC est plus grand que celui des utilisateurs data et de mme leur limite
de contrle. Dautre part, un utilisateur voix a besoin daccder rapidement au canal et donc il
faut lui donner une fonction de permission gnreuse, ce qui nest pas du tout le cas pour les
utilisateurs data.
Cette diffrence de QoS de chaque type de service nest pas la seule dterminer la technique
de multiplexage et de contrle. La diffrence dans le comportement des sources de trafic
influence aussi ce choix. Lessentiel sera de donner une priorit aux utilisateurs voix mais
sans que leur nombre sur le canal dpasse considrablement lindice MAC des utilisateurs
data ce qui risque de dgrader la QoS de ces derniers. On compare par simulation sur NS, cinq
stratgies de contrle afin de choisir celle qui donne la capacit maximale tout en respectant la
QoS de chaque type dutilisateurs. Ces stratgies sont ralises par cinq choix des fonctions
de permission :
Une fonction trop gnreuse pour la voix donc sans limite de contrle (CDMA
classique) et restrictive pour le data avec une limite de contrle de 17 S
d
= 17.
Fonctions restrictives pour la voix et le data ; Les limites de contrle sont fixes sur 17
pour les deux types soit S
v
= S
d
= 17.
Fonctions gnreuses pour la voix et le data ; Les limites de contrle sont fixes sur 20
pour les deux types soit S
v
= S
d
= 20.
Une fonction restrictive pour le data et gnreuse pour la voix ; la limite de contrle
est de 20 pour les utilisateurs voix S
v
= 20 et de 17 pour les utilisateurs data S
d
= 17.
Une fonction trs restrictive pour le data et gnreuse pour la voix. La limite de
contrle pour la voix est toujours de 20 mais celle de data est rduite 16, S
d
= 16.
Les figures 4.19, 4.20 et 4.21 donnent les rsultats de simulation de ces diffrentes stratgies.
On trace la probabilit de perte pour les utilisateurs voix dans 4.19, la probabilit de perte
pour les utilisateurs data dans 4.20 et le dlai dattente pour les utilisateurs data dans 4.21.
Ces trois graphes servent dterminer la meilleure stratgie de contrle ainsi que la capacit
totale du systme. On fixe le nombre dutilisateurs voix 15 utilisateurs et on trace les
diffrents paramtres de QoS pour diffrentes valeurs de nombre dutilisateurs data.
On remarque daprs les figures que lorsque les fonctions de contrle sont trs restrictives la
probabilit de perte des utilisateurs voix est trs leve. Ceci est d un pourcentage
considrable des paquets rejets car la limite de contrle est trop basse pour les utilisateurs
voix. Au contraire, quand la fonction de contrle des utilisateurs data est trs gnreuse la
probabilit de perte des paquets voix est basse mais celle des utilisateurs data est trop leve
puisquon autorise un grand nombre de codes actifs, ce qui augmente linterfrence.
Quand on utilise une fonction restrictive pour le data et gnreuse pour la voix, la probabilit
de perte pour les utilisateurs data reste considrable. Il faut alors diminuer les codes actifs
totaux (utiliss par les voix et les data) sans contrler la voix dune faon restrictive. On
propose alors une fonction trs restrictive pour le data et gnreuse pour la voix. La limite de
contrle est fixe sur 16 (gal au spreading factor) pour le data et 20 pour la voix. Dans ce cas
on obtient une perte trs petite pour la voix et acceptable pour le data. Dans ce cas, on peut
accepter jusqu 350 utilisateurs data avec une perte pour la voix dans lordre de 0.004, une
perte pour le data de 0.001 et un dlai dattente de 2200ms.

- 82 - 82

0 50 100 150 200 250 300 350
0
0.002
0.004
0.006
0.008
0.01
0.012
* sv = sd = 17
o sv = sd = 20
x sv = 20, sd = 17
. sv = 20, sd = 16
+ sv infini, sd = 17
probabilit de perte des paquets voix avec 15 utilisateurs voix
nombre dutilisateurs data
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 4.19 Perte des paquets voix en fonction de nombre dutilisateurs data

0 50 100 150 200 250 300 350
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
x 10
-3
* sv = sd = 17
o sv = sd = 20
x sv = 20, sd = 17
. sv = 20, sd = 16
+ sv infini, sd = 17
probabilit de perte des utilisateurs data avec 15 utilisateurs voix
nombre dutilisateurs data
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 4.20 Perte des paquets data en fonction de nombre dutilisateurs data

0 50 100 150 200 250 300 350
0
500
1000
1500
2000
2500
* sv = sd = 18
o sv = sd = 20
x sv = 20, sd = 18
. sv = 20, sd = 16
+ sv infini, sd = 18
dlai de paquet data avec 15 utilisateurs voix
nombre dutilisateurs data
d

l
a
i

(
m
s
)


Figure 4.21 Dlai des paquets data en fonction de nombre dutilisateurs data
- 83 - 83
Notons enfin que cette technique de multiplexage total de services ne ncessite pas une
allocation de ressources spcifique. Des mthodes dallocation sont tudies et compares
dans le sixime chapitre.
4.9 Conclusion
Dans ce chapitre, on a tudi un protocole utilisant CDMA dans le cas de satellite basse
orbite LEO. Ce protocole, appel S-CDMA, est conu pour supporter plusieurs services avec
diffrentes QoS. Ceci ncessite de dfinir plusieurs classes au niveau MAC pour supporter les
diffrents services. Ces classes appels MTCs (MAC Transfer Capabilities) sont le STC
(Slow Transfer Capability) pour supporter les utilisateurs data et le RTC (Rapid Transfer
Capability) pour les utilisateurs voix. Les utilisateurs data sont prsent par des sources de
trafic de transfert de fichier puis dEmail tandis que les utilisateurs voix sont reprsents par
des sources ON-OFF. Pour garantir une qualit de service pour les diffrents utilisateurs, on
introduit une fonction de contrle dadmission CAC ainsi quune fonction de contrle de
trafic. La fonction CAC agit au niveau dappel pour limiter le nombre total dutilisateurs dans
le systme tandis que la fonction de contrle de trafic agit au niveau de paquet pour limiter la
perte totale des paquets. Ces fonctions ne sont pas les mmes pour les diffrents services
puisque les QoSs demandes sont diffrents. Une tude mathmatique par des chanes de
Markov est labore pour les sous-systmes voix et data. On dtermine daprs lanalyse les
paramtres de QoS de chaque sous-systme. Les discussions analytiques peuvent alors tre
accomplies afin de dterminer les valeurs optimales du systme. Quand le systme contient
des utilisateurs voix seulement, le calcul mathmatique est utilis avec des simulations en NS.
Deux fonctions de permission sont compares et on distingue que la fonction sans limite qui
reprsente le CDMA classique donne la meilleure performance. Quand cette fonction est
utilise le pourcentage de consommation atteint 0.42. Cette valeur reprsente lefficacit du
systme puisque la capacit totale est inversement proportionnelle cette valeur. La
simulation valide notre tude. En passant au sous-systme data, on calcule la capacit du
systme en cas des sources de transfert de fichiers par analyse et simulation et pour deux
fonctions de permission. La fonction la plus restrictive donne la meilleure performance en
augmentant la capacit totale du systme. Le mme rsultat est obtenu quand des utilisateurs
Email sont simuls. On remarque que la capacit du systme augmente mais au prix dun
dlai dattente lev.
Enfin des sources voix et Email sont multiplexs ensemble et tudis par simulation. Dans ce
cas, la fonction de permission sans limite cesse dtre acceptable pour les utilisateurs voix et
une fonction trs restrictive pour les utilisateurs data est la meilleure. Une priorit souple est
donne aux utilisateurs voix dans ce cas mais le risque dinfluence de la part des utilisateurs
data reste considrable. En effet, si un utilisateur data a une grande quantit des donnes
envoyer un utilisateur voix ne peut pas linterrompre et il risque dattendre longtemps avant
dtre servi par un code. Pendant ce temps, plusieurs paquets voix sont perdus. Les
utilisateurs tudis dans ce chapitre qui sont les sources de transfert de fichiers courts et
dEmail ne posent pas ce problme puisque leurs dures de transmission ne sont pas leves.
Des utilisateurs data qui ncessitent un temps de service lev peuvent dgrader la
performance. Une sparation temporelle entre ce genre des utilisateurs data et les utilisateurs
voix est probablement ncessaire. Ce rsultat est dmontr dans le sixime chapitre. Do
lintroduction du CDMA/PRMA hybride tudi dans le prochain chapitre.
- 84 - 84










5.1 Introduction
Dans ce chapitre on va tudier un protocole daccs multiple hybride qui unit la division de
code et de temps pour concevoir le canal. Ce protocole, dvelopp pour le canal terrestre du
rseau UMTS (Universal Mobile Telecommunication System) dans le sens montant est tudi
et adapt au cas satellitaire. Le nouveau protocole est appel S-CDMA/PRMA (Satellite Code
Division Multiple Access/ Packet Reservation Multiple Access) et peut tre utilis dans la
partie satellite de lUMTS (S-UMTS).
Lun des objectifs majeurs de ETSI (European Telecommunications Standard Institute) [47] et
ITU (International Telecommunications Union) [48] est lintgration du composant terrestre
avec le rseau spatial pour raliser une couverture globale des communications mobiles. Le S-
UMTS permettra de raliser une portabilit de services et une compatibilit des terminaux.
Plus spcifiquement, il faut raliser :
Un roaming global pour les utilisateurs UMTS.
Une QoS pour les liaisons par satellite comparable celle ralise par le rseau UMTS
terrestre et avec un prix minimal.
Un dveloppement rapide des rseaux mobiles dans les pays envoie de dveloppement
ainsi que dans les zones rurales.
LUMTS et le S-UMTS se basent sur deux modes de multiplexage. Le mode duplex
division de frquence FDD (Frequency Division Duplex) et le mode duplex division de
temps TDD (Time Division Duplex). Les encouragements consistent utiliser le WCDMA
pour FDD mode et le TD-CDMA (Time Division-CDMA) pour le TDD mode. Ce dernier
mode est pris en compte dans ce chapitre et un protocole qui amliore lefficacit de TD-
CDMA est propos pour intgrer sur le mme canal plusieurs types de service voix/data qui
ncessitent diffrentes QoS requise par des applications (tlphonie, Email, Web, Transfert
des fichiers). Puisque cette technique est gnralement utilise en mode TDD, o les voies
montante et descendante sont spares temporellement, lintgration de la composante
temporelle ne pose pas des problmes additionnels au systme daccs. Une architecture de
commutation des paquets est utilise pour les diffrents utilisateurs de faon optimiser les
ressources et maximiser la capacit.
- 85 - 85
La suite du chapitre est organise comme suit ; dans la deuxime section, on dcrit la
technique hybride TD-CDMA pour introduire le protocole CDMA/PRMA amlior pour le
satellite et appel S-CDMA/PRMA. Les services supports par la couche MAC sont prsents
dans la section 4, la fonction de contrle dadmission dans la section 5 et le contrle de trafic
dans la 6
me
section. Une analyse mathmatique pour les deux sous-systmes voix et data est
dveloppe dans la septime section. Les discussions mathmatiques et par simulation sont
tudis dans la huitime section pour les diffrents types dutilisateurs (voix, web, data) ainsi
que pour le multiplexage de services. Enfin, la section 9 donne la conclusion.
5.2 La technique TD-CDMA
Cette technique combine les techniques TDMA et CDMA pour dfinir le canal radio. La
bande passante est divise en slots temporelles sur lesquelles plusieurs codes sont disponibles
pour supporter les informations transmettre. La figure 5.1 reprsente cette technique.
temps





Puissance







Bande passante

Figure 5.1 Technique CDMA/TDMA
On remarque que sur chacun des slots temporels, une certaine puissance et bande passante
peuvent tre utiliss pour servir plusieurs utilisateurs. La puissance est partage sous forme de
codes entre les diffrents utilisateurs. Un nombre limit de codes peuvent tre utiliss sur
chaque slot puisque la puissance maximale est borne par linterfrence limite accepte par un
utilisateur [49]. Elle dpend donc de la QoS demande.
Supposons que linterfrence due laccs multiple (MAI Multiple Access Interference) est
Gaussienne. En utilisant des rcepteurs simple corrlation, le BER ou la probabilit derreur
dun bit donne par :
) (SNR Q P
e
(5.1)
avec

x
u
du e x Q
2 /
2
2
1
) (

(5.2)
o SNR est le rapport signal sur bruit. Si on considre la technique de squence directe en
CDMA (CDMA/DS Direct Sequence) (Pr{x
j
= 1 } = Pr{x
j
= -1} = 0.5), o x
j
est un chip dans
la squence avec une longueur de code ou spreading factor sf, la valeur moyenne du rapport
- 86 - 86
signal sur bruit (SNR) pour le paquet i dans le cas des puissances reues ingales est donne
par

K
i k
k
k
i
T
N
P sf
P
SNR
1
0 1
2
) 3 (
(5.3)
Ce rapport dcrit la QoS reue par la station de base ; il est une fonction de la puissance totale
sur le slot considr. Pour faciliter ltude, on considre le cas dun contrle parfait de la
puissance sur chaque slot et on suppose que la puissance totale reue sur un tel slot par les
utilisateurs des cellules voisines est proportionnelle celle de la cellule analyse avec un
rapport f. On obtient :
) 1 )( 1 (
3
) 1 ( ) 1 (
3
0 0
0
f K
sf
fP K P K
sfP
SNR
+

+
(5.4)
On en dduit alors la probabilit de perte dun paquet en supposant que la longueur dun
paquet est de L et en utilisant un code correcteur derreur qui peut corriger jusqu t erreurs.
Si Q
e
= 1 - P
e
est la probabilit quun bit est bien reu, la probabilit de succs dun tel paquet
est :
i L
e
i
t
i
e
i
L E
Q Q C K Q

) ( ) 1 ( ) (
0
(5.5)
et la probabilit derreur dun paquet due linterfrence est :
P
error
(K) = 1 Q
E
(K) (5.6)
En TD-CDMA, la bande passante est divise sur deux plans, le plan temporel et le plan de
code. Une partie des ressources radios est assigne chaque plan. La partie donne au plan
temporel est reprsente par le nombre de slots dans une trame n tandis que la partie donne
au plan de code est reprsente par le spreading factor sf. Ces deux facteurs, qui reprsentent
la dcomposition de la bande passante totale, sont inversement proportionnels. En effet, quand
n augmente, la bande passante assigne chaque slot diminue et le nombre total dutilisateurs
qui peuvent envoyer sur ce slot diminue. Dans lquation 5.4 et pour le mme rapport signal
sur bruit, le facteur dtalement sf diminue. Si la bande passante totale est BW, BW/n est
assign pour chaque slot. Si R
s
est le dbit dun utilisateur, un slot peut supporter BW/(n R
s
)
utilisateurs qui peuvent envoyer sur le slot sans erreur. Cest donc le spreading factor sf.
sf = BW/(n R
s
) (5.7)
La figure 5.2 reprsente la probabilit de succs dun paquet sur un slot pour plusieurs choix
du nombre de slots dans une trame ou de spreading factor avec f = 0.5, L = 160 bits, t = 10 et
pour plusieurs spreading factors ou nombre de slots. On remarque que quand le sf augmente le
nombre total de codes accepts sur un slot augmente, mais le nombre total de slots dans la
trame diminue de faon garder la mme capacit du systme. La valeur sfn reste invariable
et reprsente le nombre total de codes dans le systme sans aucune interfrence. On remarque
ce stade que lorsque n est gal 1, sf sera le nombre total de codes dans le systme avec
probabilit derreur zro. On se retrouve donc dans le cas du CDMA pur du chapitre
prcdent. Notons que puisquune certaine erreur est accepte par les utilisateurs de diffrents
services, le nombre total de codes actifs peut dpasser sfn sans le risque dune dgradation
catastrophique de la qualit (graceful degradation).
- 87 - 87
La figure 5.2 montre que pour les diffrentes valeurs de spreading factor, la probabilit de
succs commence diminuer quelques codes plus tard. Ceci augmente la capacit du systme
comme on va le dmontrer dans la suite.

sf=2 sf=4 sf=8
0 5 10 15 20 25 30
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
nombre de codes simultans




p
r
o
b
a
b
i
l
i
t


d
e

s
u
c
c

s


Figure 5.2 La probabilit de succs pour diffrents spreading factor
5.3 Le protocole S-CDMA/PRMA
Le temps est divis en trames qui contiennent un nombre fixe de slots. Le rythme des trames
est gal au dbit des sources vocales. Les utilisateurs transmettent leurs paquets de faon les
placer dans un slot. Les slots ne sont pas considrs comme rserv ou disponible
comme dans PRMA puisque le composant CDMA permet lenvoi de plusieurs paquets dans
le mme slot. Le contrle daccs au canal se fait dune faon plus souple en dfinissant une
fonction de permission qui donne la probabilit daccder un slot.
nombre des codes actifs

x codes


p = f(x)





trame n trame n+1 temps
1 2 i 1 2 i

Figure 5.3 Le protocole S-CDMA/PRMA
En S-CDMA/PRMA, un utilisateur passe ltat de contention quand il a des paquets
envoyer. Il essaye daccder un slot du canal en faisant un tirage de Bernoulli avec une
probabilit calcule par la fonction de permission. Contrairement au CDMA/PRMA classique
[50] o un utilisateur passe de contention au rservation quand il reoit un acquittement
positif, il change de ltat de contention celui de rservation quand il dcouvre que le slot
accd pendant la trame prcdente nest pas trs charge. La dfinition de pas trs charg
dpend de la QoS demande par lutilisateur et va tre prcise dans la suite. Un utilisateur
- 88 - 88
reste dans ltat de rservation tant quil a des paquets envoyer. Plusieurs utilisateurs
transmettent alors sur le mme slot mais sur plusieurs codes. Le nombre de codes sur chaque
slot est dtect par la station de base (satellite) et diffus aux diffrents utilisateurs qui en
dduisent les probabilits de permission sur ce slot. Cette fonction doit tre inversement
dpendant par rapport au nombre de codes actifs afin de limiter le nombre total dutilisateurs
sur un slot et donc linterfrence.
La notion de collision ne se pose pas comme dans le cas de PRMA puisque plusieurs
utilisateurs peuvent envoyer en mme temps sur diffrents codes. La probabilit derreur dun
paquet augmente avec le nombre total dutilisateurs simultans et peut causer la perte du
paquet. Cette erreur est une raison de perte des paquets qui doit tre limite par le seuil de la
QoS demande. La figure 5.3 reprsente ce protocole dans son aspect gnral. Une
diffrenciation doit tre introduite entre les deux sous-systmes voix et data.
5.3.1 Sous-systme voix
Le sous-systme voix contient des utilisateurs vocaux reprsents toujours par des sources de
trafic ON-OFF comme dcrit dans le troisime chapitre. Le comportement dun utilisateur
voix suit une chane de Markov deux tats ON qui reprsente la parole et OFF qui
reprsente le silence.
Un utilisateur voix qui voit un talkspurt arrivant passe de ltat de silence ltat de
contention. Sur chaque slot, il fait un tirage de Bernoulli de paramtre p
v
(x) o x reprsente le
nombre de codes sur ce mme slot dans la trame prcdente. La fonction p
v
(x) reprsente la
permission daccder au canal pour les utilisateurs voix. Si lutilisateur choue son tirage, il
essaye sur le slot suivant de la mme faon. Dans le cas o lutilisateur arriverait accder au
slot, il envoie son paquet sur un code dans le slot et attend la rponse du satellite concernant le
nombre total de codes actifs sur le slot. Si ce nombre est infrieur un seuil S
v
lutilisateur
passe ltat de rservation et utilise son code sur le slot choisi tout au long du talkspurt.
Dans le cas contraire, il revient ltat de contention.
La rponse du satellite sur ltat dun slot narrive que dans un temps gal RTD qui est
proche de la dure dune trame. Ce temps est aussi le sjour maximal dun paquet voix avant
dtre envoy D
max
. Pour cette raison, un utilisateur peut essayer denvoyer un paquet pendant
une trame et donc sur n slots. Sil ne russit pas tout au long de cette dure, le paquet sera jet
et il passe au paquet suivant. Ceci reprsente la premire raison de perte des paquets
reprsente par la probabilit de drop P
drop
. Dautre part, sil envoie un paquet sur un slot, il
ne pourra pas retransmettre ce paquet dans le cas o il serait perdu cause dinterfrence
CDMA puisque le sjour maximal est aussi coul. Cest la deuxime raison de perte
reprsente par la probabilit derreur P
error
. La probabilit de perdre un paquet sera :
P
loss
= P
error
.+ P
drop
.
Ces deux termes qui constituent la probabilit de perte sont inversement dpendants. En effet,
quand la fonction de permission est restrictive, le temps ncessaire pour accder un slot
augmente et aussi la probabilit de rejet dun paquet tandis que le nombre total de codes actifs
sur un slot diminue et aussi la probabilit derreur. Par contre, quand la fonction de
permission est gnreuse, le temps ncessaire pour accder un slot diminue et aussi la
probabilit de rejet dun paquet tandis que le nombre total de codes actifs sur un slot
augmente et aussi la probabilit derreur. Un compromis entre les deux est ralis par le choix
des paramtres du systme comme la fonction de permission, le nombre total de slots dans
une trame et le spreading factor.
- 89 - 89
Notons quaucun tampon nest ncessaire pour les utilisateurs voix puisque le sjour maximal
est suppos gal la dure dune trame. Ceci simplifie la conception des terminaux voix.
5.3.2 Sous-systme data
Le sous-systme data contient des sources de transfert des fichiers, dEmail et de trafic Web.
Le transfert des fichiers et lEmail sont dcrit dans le chapitre prcdent et on sintresse ici
au trafic web qui reprsente une bonne partie du trafic de data dans lUMTS et de S-UMTS et
modlis par des sources dcrites dans [36,37].
Le modle consiste en des appels spars par des priodes de silence qui sont les temps de
lecture. Le nombre dappels dans une session est distribu gomtriquement. Le nombre de
rafales dans un appel ainsi que lintervalle de temps entre deux rafales conscutives sont
distribus gomtriquement. La taille des paquets suit une loi de Pareto avec cut-off pour
limiter la taille des paquets qui est la taille maximale dun datagrame IP (1502octets). La
figure 5.4 prsente une partie dune session de ce modle.


temps de lecture

Appel

Figure 5.4 Source de trafic web
Ce trafic, qui est interactif, est considr dans le sous-systme data mais prsente des
exigences plus strictes que le transfert des fichiers et lEmail en terme de temps dattente. En
effet, un utilisateur web prfre ne pas attendre trs longtemps pour une demande des
informations web, ce qui exige un accs rapide de la source web sur le canal satellite afin de
dlivrer les informations demandes. Pour cette raison, la probabilit daccs au canal des
utilisateurs web est note p
w
pour les diffrencier des autres utilisateurs data qui possdent p
d

comme probabilit daccs.
Un utilisateur data qui voit une rafale doit accder au canal radio par contention. Il essaye
daccder un slot de la trame en faisant un tirage de Bernoulli de paramtre p
d
(x) ou p
w
(x) o
x est le nombre dutilisateurs sur ce slot dans la trame prcdente. Si lutilisateur choue son
tirage, il essaye sur le slot suivant de la mme faon. Dans le cas o lutilisateur arriverait
accder au slot, il envoie son paquet sur un code dans le slot et attend la rponse du satellite
concernant le nombre total de codes actifs sur le slot. Si ce nombre est infrieur un seuil S
d
,
lutilisateur passe ltat de rservation et utilise son code sur le slot choisi tout au long de la
rafale. Dans le cas contraire, il revient ltat de contention. Un paquet data peut attendre
longtemps avant dtre envoy ; pour cette raison le paquet est mis dans un tampon en
attendant laccs au canal. Par contre, on suppose quun paquet envoy et perdu cause
dinterfrence CDMA ne peut pas tre retransmis au niveau MAC. Cest au niveau de RLC
quon accomplit la retransmission. Ceci reprsente la seule raison de perdre un paquet qui est
la probabilit derreur :
P
loss
= P
error

Dautre part, le temps dattente dun paquet dans le tampon dpend de la permission daccs
sur le canal et il est inversement dpendant par rapport la probabilit de perte. En effet,
quand la fonction de permission est restrictive, le temps ncessaire pour accder un slot
augmente et aussi le sjour dun paquet dans le tampon tandis que le nombre total de codes
- 90 - 90
actifs sur un slot diminue et aussi la probabilit derreur. Par contre, quand la fonction de
permission est gnreuse, le temps ncessaire pour accder un slot diminue et aussi le sjour
dun paquet dans le tampon tandis que le nombre total de codes actifs sur un slot augmente et
aussi la probabilit derreur. Un compromis entre les deux est ralis par le choix des
paramtres du systme comme la fonction de permission, le nombre total de slots dans une
trame et le spreading factor.
Notons enfin quon suppose que les tampons utiliss sont de taille infinie et aucune perte nest
cause par le remplissage des tampons. Mais le temps de sjour moyen est un facteur de QoS
respecter suivant lutilisateur en question (Email, web).
5.4 Les services
Dans ce chapitre, plusieurs types dapplications qui demandent diffrentes qualits de service
vont pouvoir accder au canal radio. Pour cette raison, plusieurs services sont fournis aux
utilisateurs. Du point de vue du temps dattente, on peut diviser les utilisateurs en trois
groupes : les utilisateurs qui demandent un temps rel comme la voix, les utilisateurs qui ne
demandent pas un temps rel mais qui sont interactifs et donc nacceptent pas un long dlai
dattente comme le web, et enfin les utilisateurs qui peuvent attendre indfiniment comme le
transfert des fichiers et lEmail. Ces diffrents types de services sont supports au niveau
MAC par trois MTCs (MAC Transfer Capabilities) afin de garantir leur QoS requise. Ces
MTCs sont le RTC (Rapid Transfer Capability), le ITC (Intermediary Transfer Capability) et
le STC (Slow Transfer Capability). Ces services sont dfinis au niveau MAC comme suit :
RTC doit garantir une transmission rapide des paquets gnrs par la source, ce qui est
souhaitable pour les services temps rels. La ralisation de cette rapidit se fait sur
deux niveaux ; au niveau dappel par la fonction CAC, qui doit refuser une telle
demande si elle estime que la couche MAC est incapable de garantir un temps rel, et
au niveau de paquet par un contrle de trafic accompli par la couche MAC par
lintermdiaire des probabilits de permission.
Un mapping est possible entre RTC et les services variables temps rel qui
reprsentent le trafic vocal. Ainsi le VBRrt de lATM, service garanti ou service
premium de lIP et service conversationnel de lUMTS.
ITC doit garantir une transmission modre des paquets et par suite un sjour
raisonnable dun tel paquet dans le tampon. Ceci est souhaitable par des services
interactifs comme le web. La probabilit de perte de ce genre des paquets doit tre trs
faible. Pour garantir cette qualit, il faut limiter le nombre dutilisateurs ITCs accepts
par la fonction CAC ainsi que contrler leur trafic par la fonction de permission. Un
mapping est possible entre ITC et le VBRnrt de lATM, service assur de lIP ou
classe interactive de lUMTS.
STC peut supporter un long dlai avant de transmettre un paquet mais doit garantir
une probabilit de perte dun paquet trs petite. Pour garantir cette qualit de service,
un nombre limit dutilisateurs doit tre accept (fonction CAC). Le choix de la
probabilit de permission est aussi un facteur important comme on va le dmontrer
dans la suite. Un mapping est possible entre STC et le ABR de lATM, service
olympic de lIP et le service de base de lUMTS.
La diffrence entre ces MTCs est ralise dune faon souple en donnant diffrentes priorits
aux diffrents MTCs. Ainsi, la classe STC a la priorit la plus haute puis la classe ITC et enfin
la classe STC. La priorit est donne dune faon souple par lintermdiaire de la fonction de
- 91 - 91
permission associe chaque classe. Ceci donne des garanties statistiques aux diffrents
utilisateurs en diminuant linfluence dune classe sur lautre. Une garantie stricte ncessite la
sparation des diffrents utilisateurs dune faon temporelle ou frquentielle comme on va
analyser dans le chapitre suivant. Dans ce chapitre, tous les utilisateurs ont accs un mme
canal. Dautre part, le fait que les utilisateurs ITC et STC acceptent un certain dlai ncessite
lintgration des tampons dans leurs terminaux, ce qui nest pas le cas pour les utilisateurs
RTC.
5.5 La fonction CAC
En CDMA/PRMA, les ressources sont partages sur deux niveaux ; le niveau de temps
laide des diffrents slots et le niveau des codes. Une ressource radio lmentaire est alors un
code sur un slot. Le nombre n de slots dans une trame reprsente le premier indice de la
couche MAC qui influence la fonction CAC. Les autres indices sont lis au nombre maximal
de codes sur un slot pour un tel service. Ces indices sont dsigns par K
v
et K
d
dfinis par :
P
error
(k) Pe
v
k K
v
pour les utilisateurs voix.
P
error
(k) Pe
d
k K
d
pour les utilisateurs data.
o Pe
v
et Pe
d
sont les valeurs maximales de probabilit derreur accepte par les utilisateurs
voix et data, respectivement. P
error
(k) est la probabilit derreur donne par lquation 5.5 o k
reprsente les utilisateurs voix et data sur un slot. En pratique Pe
v
> Pe
d
et donc K
v
> K
d
. Si le
nombre total dutilisateurs simultans sur un slot est k K
d,
tous les utilisateurs voix et data
reoivent une qualit acceptable. Si K
d
k K
v
, parmi les k paquets, les paquets vocaux ont
une qualit acceptable tandis que les paquets data ne lont pas. Enfin, si K
v
. k tous les
utilisateurs ont une qualit de service inacceptable.
n, K
v
et K
d
contribuent la dtermination de la capacit du systme et la dfinition de la
fonction CAC. Des autres paramtres lis aux utilisateurs sont aussi essentiels dans la
dfinition de la fonction de contrle dadmission [59, 60].
La fonction de permission associe chaque type de services joue un rle fondamental dans la
capacit total du systme et donc la fonction CAC. Cette fonction utilise dans ce chapitre est
capacit quivalente et se base sur un seul paramtre quil faut dterminer dans notre tude.
Ce paramtre est le pourcentage de consommation dun code par un utilisateur. Ce paramtre
nest pas le mme pour les diffrents services et doit tre dtermin pour chaque MTC. Pour
le RTC, ce paramtre peut tre dtermin puisquune QoS prcise est considr avec Pe
v
=
1% et une contrainte de temps rel. Pour ITC et STC, la probabilit de perte maximale
considre est de 0.1% mais le temps dattente moyen nest pas prconis dans notre tude.
Ce dlai contribue donc la dtermination du pourcentage de consommation qui nest pas le
mme pour le ITC et le STC. La fonction CAC gnrale peut tre dcrite comme suit.
Un nouvel utilisateur qui demande une connexion est accepte par la fonction CAC si le
pourcentage moyen de ressource consomm par cet utilisateur est disponible. On garantit dans
ce cas une QoS statistique pour lutilisateur qui a gnralement un dbit variable. Les
ressources disponibles sont ensuite diminues de cette valeur.
5.6 Le contrle de trafic
Le contrle de trafic est ralis au niveau MAC par la fonction de permission. Diffrentes
fonctions sont associes aux diffrents services de faon raliser la qualit de service de
chaque MTC. Ces fonctions sont dfinies par plusieurs paramtres et ont le rle de distribuer
- 92 - 92
les utilisateurs de la faon le plus homogne possible et aussi de minimiser linfluence dune
telle classe de service sur lautre. Pour cette raison, trois fonctions diffrentes sont dfinies
pour les diffrents MTCs comme dans la figure 5.5.



1

STC ITC RTC



2


3

sf Sd
Sv
a3
. a2

fonctions de permission
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n

a1

Figure 5.5 Fonctions de permission
Dans cette figure, on remarque que la gnrosit de la fonction diminue partir des
utilisateurs RTC (voix) aux utilisateurs ITC (web) et enfin vers les utilisateurs STC (data qui
comprennent le transfert des fichiers et lEmail). Ceci donne une priorit maximale aux
utilisateurs RTC puis ITC et enfin STC. Les fonctions possdent plusieurs paramtres qui sont
le point de dpart, langle dinclinaison, le point de dviation et le point de zro.
Le point de dviation est toujours choisi gal au spreading factor. Les points de dparts sont
a
1
, a
2
et a
3
, les angles dinclinaisons sont
1
,
2
et
3
. les points de zros sont gaux S
d
pour
les utilisateurs web et data puisquon a la mme limite derreur tandis quil est gal S
v
pour
les utilisateurs vocaux [61, 62]. Ce nombre correspond au nombre maximal de codes actifs
accepts avec une QoS convenable.
Les diffrents paramtres vont tre choisis par la suite afin de respecter la qualit de service
demande par chaque utilisateur tout en maximisant la capacit totale du systme. Ltude
mathmatique est faite pour les utilisateurs voix et transfert des fichiers seulement. Une
simulation est ensuite effectue pour les utilisateurs web ainsi que le multiplexage de services.
5.7 Modlisation mathmatique
Dans ce paragraphe, on prsente notre modle mathmatique dvelopp pour le protocole S-
CDMA/PRMA pour le sous-systme voix et data. Le sous-systme voix contient des sources
ON-OFF tandis quon considre que le sous-systme data contient des sources de transfert de
fichiers. Le modle est bas sur les chanes de Markov et prsente lintrt de dcrire le
comportement du protocole en fonction des diffrents paramtres. On utilise la mthode de
calcul de la matrice de transition pour ensuite dduire ltat stationnaire du canal. Des
simplifications sont introduites pour faciliter le calcul et sont ensuite justifis par des
- 93 - 93
simulations utilisant NS (Network Simulator). Notons enfin que le calcul est fait pour les cas
particuliers des utilisateurs voix seuls puis des utilisateurs fichiers seuls. Les cas plus
compliqus de multiplexage de service sont tudis par simulation.
5.7.1 Sous-systme de voix
Les utilisateurs voix sont des sources ON-OFF qui transitent entre le silence et la parole.
Quand un utilisateur passe de ltat OFF ltat ON, il essaye de rserver un slot par
contention suivant le protocole S-CDMA/PRMA. Le systme se comporte donc comme un
ensemble des sources ON-OFF de nombre M
v
qui est le nombre accept par la fonction CAC.
Ces utilisateurs essayent de rserver un code dans un slot quand ils ont des paquets envoyer.
Les paramtres dune telle source sont :
La probabilit de passer de ON (qui a une dure moyenne de t
on
) OFF pendant T
f
:

v
=1-exp(-T
f
/t
on
) (5.8)
La probabilit de passer de OFF (qui a une dure moyenne de t
off
) ON pendant T
f
:

v
=1-exp(-T
f
/t
off
) (5.9)
La probabilit dtre dans ltat ON :

on
= t
on
/( t
on
+ t
off
) (5.10)
La probabilit dtre dans ltat OFF :

off
= t
off
/( t
on
+ t
off
) (5.11)
Si un utilisateur passe du silence la parole, il fait sur le slot suivant un tirage de Bernoulli de
paramtre p
v
(x) o x est le nombre de codes sur le mme slot dans la trame prcdente. Si
lutilisateur ne russit pas ce tirage, il doit ressayer sur le slot suivant. Dans le cas positif, le
paquet est envoy sur le slot qui sera rserv si le nombre total de codes actifs sur le slot est
infrieur S
v
qui est aussi le seuil de contrle nomm le point de zro dans le paragraphe
prcdent. Remarquons que Y
m
est le nombre de codes sur le slot mentionn dans la trame m,
et T
m
est le nombre de codes actifs sur les diffrents slots dans la trame m. on a :
Y
m+1
= Y
m
+(utilisateurs entrants de M
v
T
m
sources OFF) (utilisateurs sortants de Y
m
sources
ON). On remarque que T
m
dpend de Y
m
.
Le nombre dutilisateurs entrants est indpendant de nombre dutilisateurs avant Y
m
et de
mme pour le nombre dutilisateurs sortants. Ceci est d au caractre sans mmoire des
sources exponentielles ON-OFF. Y
m
est alors une chane de Markov suppose homogne [29].
La figure 5.6 dcrit ce modle.
Soit P
xy
la probabilit de passage de ltat x ltat y dun tel slot o x et y sont arbitraires et
reprsentent le nombre de codes sur le slot. Pour pouvoir calculer cette probabilit, on
suppose que les autres slots de nombre (n-1) possdent le mme nombre de codes. Si on
suppose que t est le nombre de codes actifs dans la trame n, (t-x)/(n-1) codes sont prsents sur
chacun des (n-1) slots autre que notre slot tudi qui a x codes. Dans la trame suivante, le
nombre total de codes actifs devient t et celui de codes sur le slot mentionn devient y.
La probabilit de transition est :
{ } { }
{ } { } + +
+

+
a
m s m e m s e
m s e m m m xy
x Y x y a NI x Y a NI x Y y NI NI x
x Y y NI NI Y x Y y Y P
) ( ) ( Pr Pr
Pr Pr
1

NI
e
est le nombre dutilisateurs entrants sur le slots et NI
s
est le nombre dutilisateurs sortants.
- 94 - 94
{ } { }
{ } { }

+ <
+
y
x y a
m o m i xy
y
a
m o m i xy
x Y x y a NI x Y a NI P y x
x Y x y a NI x Y a NI P y x
Pr Pr
Pr Pr
0
(5.12)

n slots




(t-x)/(n-1) codes x codes (t-y)/(n-1) codes y codes


P
xy





M
v
utilisateurs voix
n-1 slots en quilibre ## n-1 slots en quilibre ##

Figure 5.6 Modle de canal (utilisateurs voix)
NI
s
est le nombre dutilisateurs qui quittent le slot. Il y a deux raisons pour quitter un slot. La
premire est le passage de ltat ON ltat OFF. La deuxime est quand un utilisateur russit
son tirage de Bernoulli mais dcouvre ensuite que le nombre de codes actifs sur le slot est
suprieur la limite de rservation S
v
(qui est aussi le seuil de contrle). Il doit donc quitter le
slot et recommencer la contention. Do :
{ }
{ }
{ } . 0 Pr , 0 ) ( & ) (
) 1 ( Pr , 0 ) ( & ) (
) 1 ( Pr
> >
>
+

+
x Y y x NI a S y S x si
C x Y y x NI a S y S x si
C x Y x y a NI S x si
m o v v
y
v v
y S
S m o v v
a y
v v
x y a
x m o v
y
v
S
v
v
x y a


(5.13)
NI
e
est le nombre dutilisateurs entrants le slot mentionn. Ce nombre provient de deux
ensembles. Le premier contient les utilisateurs qui passent ltat ON pendant la trame en
question. Le second ensemble est form des utilisateurs qui passaient ltat ON pendant les
trames prcdentes mais qui nont pas pu accder au canal jusqu linstant. Cet ensemble
sera approch par le nombre moyen de ses populations qui est calcul comme suit.
Pour un nombre t des utilisateurs ON sur une trame, le nombre moyen dutilisateurs arrivants
cette trame est
v
(M
v
t). Si chaque slot contient t/n codes, la probabilit daccder au slot
est p
v
(t/n). Si on considre la ime trame avant la trame courante m, le nombre dutilisateurs
en provenance de cette trame qui chouent leurs tirages de Bernoulli et atteint la trame m
sera :
n i
v v v i
n t p t M t W

)] / ( 1 [ ) ( ) ( (5.14)
le nombre total dutilisateurs de cet ensemble et pour un nombre donn dutilisateurs ON t
est :
n
v
n
v v v
i i
n i
v v v i
n t p
n t p t M
n t p t M t W t W
)] / ( 1 [ 1
)] / ( 1 [ ) (
)] / ( 1 [ ) ( ) ( ) (
1 1



(5.15)
et le nombre moyen des utilisateurs de cet ensemble est :
- 95 - 95


v
M
t
m
t W t T t W E W
0
) ( ) Pr( )) ( (
(5.16)
La probabilit dentr au slot mentionn sera :
{ } { }
{ }
{ } { } { }




a M
x t
t M
W a h
m m e e m e
a M
x t
t M
W a h
m m e e m e
a M
x t
m m m e m e
v v
v v
v
x Y t T h NT a NI t T h NT
x Y t T h NT a NI t T h NT
x Y t T t T a NI x Y a NI
Pr Pr Pr
) ( ) ( ) ( Pr
) ( ) ( Pr Pr
(5.17)
NT
e
est le nombre dutilisateurs qui transitent de ltat OFF vers ltat ON pendant la trame m.
Le nombre total dutilisateurs entrants pendants la trame m est donc NT
e
+ E(W), avec :
{ }
t W M
off
x t
on
x t
x W M
m m
v
v
C x Y t T


Pr (5.18)
{ }
h t W M
v
h
v
h
t W M
m e
v
v
C t T h NT


) 1 ( Pr (5.19)
{ }
a W h
v
a
v
a
W h
e e
p p C h NT a NI
+
+
) 1 ( Pr (5.20)
p
v
est la probabilit quun utilisateur entrant dans la trame tente daccder au slot mentionn.
Pour calculer p
v
on suppose que les codes sont distribus dune faon homogne sur les slots
autre que celui tudi. Si on suppose que t utilisateurs sont ON, il y a (t x) codes sur les
autres slots, Soit (t-x)/(n-1) codes sur chacun. La probabilit de permission daccs sur un tel
slot est de p
v
[(t-x)/(n-1)] sauf pour le slot tudi qui possde une probabilit de permission de
p
v
(x). Un utilisateur arrive sur un slot alatoirement et commence ses tentatives. La figure 5.7
prsente le processus daccs dun tel utilisateur.






1/n 1/n 1/n 1/n
(t-x)/(n-1) (t-x)/(n-1) (t-x)/(n-1) x
codes codes codes codes

Figure 5.7 Processus d'accs
Notons quen LEOS, le RTD est considr gal au temps aller retour et donc un utilisateur qui
accde au canal, envoie son paquet et attend la rponse, qui viendra dans une dure de trame,
il ne pourra pas retransmettre le paquet en cas de perte cause derreur dinterfrence. En
considrant ce fait, on calcule la probabilit de contention sur un slot :
{ }
{ }
{ }
{ }
{ } { }

'

+ +
+ +

+
+
+ +

1 2
1
2
)] 1 /( ) [( 1 . .......... )] 1 /( ) [( 1
)] 1 /( ) [( 1 1
) ( ) / 1 (
) ( )] 1 /( ) [( 1 ) / 1 ( . .......... .......... ..........
) ( )] 1 /( ) [( 1 ) / 1 (
) ( )] 1 /( ) [( 1 ) / 1 ( ) ( ) / 1 (
n
v v
v
v
n
v
v v
v v v v
n x t p n x t p
n x t p
x p n
x p n x t p n
x p n x t p n
x p n x t p n x p n p

- 96 - 96
{ }
{ } )] 1 /( ) [(
)] 1 /( ) [( 1 1
) ( ) / 1 (



n x t p
n x t p
x p n p
v
n
v
v v
(5.21)
En utilisant ces rsultats, on obtient la matrice de transition M
v
tats comme suit :
[ ]
v
v
M y
M x
xy
P P


0
0
(5.22)
et on peut calculer ltat stationnaire [ ]
v
M k k

0
par le systme dquations :
1

k
k
P


(5.23)
o
k
est la probabilit davoir k utilisateurs sur un tel slot dans ltat stationnaire. Cette
probabilit dcrit ltat stationnaire du systme et sert calculer les diffrents paramtres de
QoS. Pour calculer la probabilit de perte totale, on doit calculer la probabilit de perte due
linterfrence CDMA et celle de drop due au rejet dun paquet cause dune attente
inacceptable.
La probabilit derreur sur un slot qui possde k codes actifs est ( 1 - Q
E
( k ) ). La probabilit
derreur dans ltat stationnaire est donc calcule par la formule :


v
M
k
E k error
k Q P
0
)) ( 1 ( (5.24)
La probabilit de drop est plus complexe dterminer. Un paquet est rejet au dbut dun
talkspurt sil attend plus que D slots avant dtre envoy (D=n dans notre calcul). Or, un
utilisateur choue son tirage de Bernoulli sur un slot qui possde k
i
codes avec une probabilit
( 1 p
v
(k
i
) ). Il nenvoie pas sur les diffrents slots dune trame qui ont (k
j
)
1jn
avec une
probabilit de ( 1 - p ( k
j
) )
1jn
. La moyenne gomtrique de cette valeur est la probabilit
moyenne dans ltat stationnaire quun utilisateur ne choisisse pas un tel slot. On note cette
probabilit par = ( k
1
, k
2
,, k
n
) do :
n
n
i
i
k p


1
)) ( 1 ( (5.25)
la probabilit quun paquet attend j slots est :
1
) 1 ( ) (


j
w
j P (5.26)
En utilisant le calcul fait dans le chapitre 3 pour dterminer la probabilit de drop on obtient :
n
v
D
v n drop
k k k P



) 1 ( 1
) ,....., , (
2 1
(5.27)
La distribution des codes dans les diffrents slots dune trame dans ltat stationnaire est
donne par lquation :

n
i
k n
i
k k k
1
2 1
) ,....., , ( (5.28)
La probabilit de drop dans ltat stationnaire est :



m
k
m
k
m
k
n drop n drop
n
k k k P k k k P
0 0 0
2 1 2 1
1 2
) ,....., , ( ) ,....., , ( ...... (5.29)
daprs les quations 5.24 et 5.29 on obtient la probabilit de perte qui est le paramtre dcisif
de la QoS des utilisateurs voix :
- 97 - 97
drop error loss
P P P + (5.30)
Cette probabilit dpend de plusieurs facteurs, la fonction de permission le nombre de slots
dans une trame, la dure dune trame.. Ces facteurs sont donc essentiels pour dterminer la
capacit du systme. Des applications de calcul sont prsentes dans la suite.
5.7.2 Sous-systme data
Le sous-systme de data tudi dans cette section et modlis mathmatiquement est constitu
des sources de transfert des fichiers. Ces sources dcrites dans le chapitre 3 ont une arrive
Poissonienne de paramtre et des fichiers de longueur gomtrique de moyen L
s
paquets.
On a dmontr dans le chapitre 3 que ces sources peuvent tre approches par des sources
ON-OFF notes A-F (pour Attente et Fichier) avec les paramtres suivants :
La probabilit darrive dune rafale :

d
= 1 - exp(-T
f
) (5.31)
la probabilit de finir la transmission de la rafale :

d
= 1 / L
s
(5.32)
On dfinit la probabilit dtre dans ltat F=ON par :
f s
f s
F
T L
T L
+

/ 1
(5.33)
Et celle dtre dans ltat OFF=A par :
f s
A
T L +

/ 1
/ 1
(5.34)
En utilisant ce rsultat, on peut modliser le systme de la mme faon que le sous-systme
voix. Mais pour les utilisateurs data, un paquet peut attendre longtemps avant dtre transmis.
Un utilisateur stocke ses paquets dans un tampon en attendant la rservation dun slot pour
commencer transmettre sur un code de ce slot. Supposons que la taille du tampon est infinie
et quaucun paquet nest perdu cause du remplissage du tampon. La seule raison de perte est
linterfrence due laccs multiple CDMA puisquon suppose quun utilisateur qui russit
son tirage de Bernoulli de paramtre p
d
(x) (x est le nombre de codes actifs sur le slot dans la
trame prcdente) transmet son paquet qui peut tre perdu cause dinterfrence. Si ce paquet
est perdu, on ne pourra pas le retransmettre au niveau MAC. Notons que le slot est rserv si
le nombre de codes actifs sur le slot est infrieur la limite de rservation S
d
qui est aussi la
limite de contrle. Il ny a plus quune probabilit de perte cause par les erreurs, mais un
deuxime paramtre de QoS simpose ; cest le temps moyen de sjour dun paquet dans le
tampon. En supposant que le nombre dutilisateurs data est M
d
et avec les paramtres des
sources data, on obtient la figure 5.8.
Cest exactement la mme modlisation du canal quavec changement des paramtres. Le
calcul de ltat stationnaire est comme pour le sous-systme voix. On obtient :
{ }
{ }
{ } . 0 Pr , 0 ) ( & ) (
) 1 ( Pr , 0 ) ( & ) (
) 1 ( Pr
> >
>
+

+
x Y y x NI a S y S x si
C x Y y x NI a S y S x si
C x Y x y a NI S x si
m o d d
y
d d
y S
S m o d d
a y
d d
x y a
x m o d
y
v
S
d
d
x y a


(5.35)
Dautre part :
- 98 - 98





d d
M
t
n
d
n
d d d
m
M
t
m
n t p
n t p t M
t T t W t T W
0 0
)] / ( 1 [ 1
)] / ( 1 [ ) (
) Pr( ) ( ) Pr(

(5.36)

n slots




(t-x)/(n-1) codes x codes (t-y)/(n-1) codes y codes


P
xy





M
d
utilisateurs data
n-1 slots en quilibre ## n-1 slots en quilibre ##

Figure 5.8 Modle de canal (utilisateurs data)
{ } { } { }



a M
x t
t M
W a h
m m e e m e m e
d d
x Y t T h NT a NI t T h NT x Y a NI Pr Pr Pr ) Pr(
(5.36)
Avec :
{ }
t W M
A
x t
F
x t
x W M
m m
d
d
C x Y t T


Pr (5.37)
{ }
h t W M
d
h
d
h
t W M
m e
d
d
C t T h NT


) 1 ( Pr (5.38)
{ }
a W h
d
a
d
a
W h
e e
p p C h NT a NI
+
+
) 1 ( Pr (5.39)
{ }
{ } )] 1 /( ) [(
)] 1 /( ) [( 1 1
) ( ) / 1 (



n x t p
n x t p
x p n p
d
n
d
d d
(5.40)
En utilisant ces rsultats, on obtient la matrice de transition M
d
tats comme suit :
[ ]
d
d
M y
M x
xy
P P


0
0
(5.41)
et on peut calculer ltat stationnaire [ ]
d
M k k

0
par le systme dquations :
1

k
k
P


(5.42)
o
k
est la probabilit davoir k utilisateurs sur un slot dans ltat stationnaire. Cette
probabilit dcrit ltat stationnaire du systme et sert calculer les diffrents paramtres de
QoS.
La probabilit de perte, qui est aussi la probabilit derreur dans ltat stationnaire, est donc
calcule par la formule :


v
M
k
E k error
k Q P
0
)) ( 1 ( . (5.43)
Passons maintenant au calcul du dlai moyen dattente dun paquet. On calcule dabord la
probabilit dattente pour en dduire le dlai.
- 99 - 99
La probabilit dattendre j slots avant de russir un tirage de Bernoulli dans ltat stationnaire
est celle dchouer sur j-1 slots pour russir sur le j
me
. Cette probabilit est calcule par :

1
]
1


1
]
1


1
0
1
0
) ( )) ( 1 ( ) (
j
M
i
d i
j
M
i
d i
d d
i p i p j w P (5.44)
Le dlai moyen en nombre de slots est alors la somme des probabilits dattente multiplies
par les temps dattente correspondants :
2
0
1
0
) 1 (
) (

j
j
j
j j j w P d (5.45)
Ce dlai dtermine la qualit de service fournie pour les utilisateurs data. Un temps maximal
dattente peut tre impos par un tel service. Cette limite, avec celle sur la probabilit de perte
vont servir pour dterminer la capacit totale du systme. Cette capacit dpend de plusieurs
paramtres comme le nombre de slots dans une trame, la fonction de permission, le dlai
dune trame.
5.8 Discussions analytiques et par simulation
Dans ce paragraphe, on tudie analytiquement et par simulation la performance du protocole
S-CDMA/PRMA. Les utilisateurs voix ainsi que les utilisateurs de transfert des fichiers sont
tudis analytiquement et par simulation tandis que les autres cas du systme ne sont tudis
que par simulation. On va tudier chaque cas des MTCs (RTC, ITC et STC) part afin de
choisir les paramtres du systme. Puis, en utilisant ces paramtres, on tudie le cas de tous
les services multiplexs.
Le simulateur NS est utilis pour simuler un systme LEOS comme dcrit dans le deuxime
chapitre. Une technologie multi-faisceaux est utilise. Dans chaque faisceau, on a 24 de
frquences porteuses. Chaque frquence a une bande passante montante gale la bande
passante descendante de 155Kb/s. Le G/W a une bande de 155Mb/s ainsi que la liaison inter-
satellite. Les cellules utilises au niveau MAC sont insres dans des slots de dure (20/n)ms.
La longueur dun paquet (cellule) peut tre calcule par (155 (20/n))/sf = 194 car sf*n = 16
soit 194 bits avec les enttes et 160 bits sans les enttes (qui donne aux voix le dbit de 8Kb/s
au niveau application et 9.6Kb/s au niveau MAC).
5.8.1 RTC (utilisateurs voix)
Dans cette section, on va dterminer le choix des paramtres du canal et de protocole qui
ralisent la meilleure performance pour les utilisateurs voix reprsents par des sources ON-
OFF. Les paramtres utiliss pour les sources ON-OFF sont comme dcrit dans [41] et
rsums par :
Le temps moyen de parole est de t
on
= 1 seconde.
Le temps moyen de silence est de t
off
= 1.35 secondes
Pour trois cas de spreading factor (sf = 8, 4, 2), on tudie trois cas de fonctions de permission
(gnreuse, moyenne et restrictive). La diffrence entre ces fonctions est dans langle
dinclinaison puisquon suppose que le point de dpart est 0.5, le point de dviation est sf et le
point de zro est la limite S
v
. La figure 5.9 prsente ces fonctions. Pour chacun des cas, on
calcule la capacit du systme qui est le nombre dutilisateurs quon peut accepter par la
fonction CAC avec une QoS acceptable (perte<1%). Le tableau 5.1 prsente les rsultats.

- 100 - 100
Tableau 5.1 Capacit du systme
Sf \ fonction gnreuse Moyenne Restrictive
sf=8 30 33 29
sf=4 35 37 33
sf=2 40 42 38

Daprs ce tableau, on remarque qune fonction moyenne donne toujours des rsultats
meilleurs. Ceci est d au fait que grce une fonction modre, un compromis est fait entre la
probabilit de drop et celle derreur. En effet, une fonction gnreuse augmente le nombre de
codes actifs sur le slot et la probabilit derreur tandis quune fonction restrictive augmente le
refus daccs au canal et la probabilit de drop.
Les fonctions choisies sont prsentes dans la figure 5.10 pour les diffrents sf. Pour chacun
des cas, on trace la distribution des utilisateurs sur les diffrents slots dans la figure 5.11. On
remarque dans cette figure que la distribution des utilisateurs tend vers la limite de contrle
(qui est aussi la limite de QoS) quand le nombre dutilisateurs augmente. Cette distribution
reste acceptable pour le cas de 40 utilisateurs quand le sf = 2 tandis quelle dvient concentre
sur la limite de contrle dans les autres cas. Ce rsultat diminue la probabilit de perte dans le
cas o sf =2 comme on verrait dans la figure 5.12.
Dans la figure 5.12 on trace la probabilit de perte pour les diffrents cas de sf. On remarque
que quand le spreading factor est gal 2, la probabilit de perte atteint sa limite 42
utilisateurs. La capacit de systme est de 42 utilisateurs dans ce cas. Elle est de 33 et 36 dans
le cas de sf = 4 et sf = 8 respectivement. La raison essentielle de ce rsultat est la probabilit
de drop qui devient dominante quand le spreading factor augmente. En effet, quand sf
augmente, avec la mme bande passante le nombre de slots dans une trame n diminue. Le
nombre total de tentatives qui est gal n diminue. La probabilit de russite diminue aussi,
ce qui augmente lattente dun utilisateur pour accder au canal et aussi la probabilit de drop.
Une deuxime raison imprvisible joue un rle important dans ce rsultat. Le fait que la limite
de QoS est de 3, 5 et 10 pour sf = 2 (n = 8), sf = 4 (n = 4) et sf = 8 (n = 2) fait que le nombre
dutilisateurs qui peuvent tre actifs sur le canal avec une QoS accepte est de 3 8 =24
quand sf = 2, 5 4 =20 quand sf = 4 et 10 2 =20 quand sf = 8. Le cas de sf = 2 et n = 8 va
tre choisi pour le canal dans la suite, ainsi que dans ltude de cas des utilisateurs STC et
ITC.
On mentionne ce stade que mme si la fonction de contrle dadmission CAC agit dune
faon souple et peut accepter un nombre lev dutilisateurs avec une garantie statistique, le
protocole daccs contrle laccs au canal et gre la QoS des utilisateurs dune faon trs
acceptable. On remarque que la QoS est garantie la plupart de temps mme dans un cas
critique de temps rel. Par la suite, on va dmontrer que ce protocole peut grer aussi la QoS
pour les utilisateurs data en garantissant une perte minime pour ces utilisateurs. Une
diffrenciation de services est mme faisable avec une bonne efficacit.
- 101 - 101

0 2 4 6 8 10 12 14
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
fonctions de permission sf = 8
nombre de codes actifs
p
r
o
b
a
b
i
l
i
t
e

d
e

p
e
r
m
i
s
s
i
o
n


0 2 4 6 8 10 12 14
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
fonctions de permission sf = 4
nombre de codes actifs
p
r
o
b
a
b
i
l
i
t
e

d
e

p
e
r
m
i
s
s
i
o
n


0 2 4 6 8 10 12 14
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
fonctions de permission sf = 2
nombre de codes actifs
p
r
o
b
a
b
i
l
i
t
e

d
e

p
e
r
m
i
s
s
i
o
n


Figure 5.9 Fonctions de permissions et spreading factors



sf=2 sf=4 sf=8
0 2 4 6 8 10 12 14
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
fonctions de permission pour differents sf
nombre de codes actifs

p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n


Figure 5.10 Les fonctions de permissions tudies

- 102 - 102

0 5 10 15 20 25 30 35 40 45
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
distribution des utilisateurs en cas de sf = 8
30, 35, 40 et 45 utilisateurs acceptes
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t
e

d
e

x

c
o
d
e
s

a
c
t
i
f
s

Limite de contrle

0 5 10 15 20 25 30 35 40 45
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
distribution des utilisateurs en cas de sf = 4
30, 35, 40 et 45 utilisateurs acceptes
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t
e

d
e

x

c
o
d
e
s

a
c
t
i
f
s

Limite de contrle


0 5 10 15 20 25 30 35 40 45
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
distribution des utilisateurs en cas de sf = 2
30, 35, 40 et 45 utilisateurs acceptes
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t
e

d
e

x

c
o
d
e
s

a
c
t
i
f
s

Limite de contrle

Figure 5.11 La distribution des utilisateurs

0 5 10 15 20 25 30 35 40 45
10
-3
10
-2
10
-1
10
0
comparaison des choix de sf
x,* sf=2 analytique et simulation
o,. sf=4 analytique et simulation
+,

sf=8 analytique et simulation
nombre dutilisateurs
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 5.12 La probabilit de perte pour les utilisateurs voix
- 103 - 103
5.8.2 STC (utilisateurs data)
Dans cette section, on tudie analytiquement et par simulation le comportement de notre
protocole S-CDMA/PRMA dans le cas des utilisateurs data. Ces utilisateurs sont reprsents
dans cette section par des sources de transfert de fichier avec les paramtres suivants :
Taux darrive par seconde est = 0.5.
Longueur moyen dune rafale est L
s
= 100 paquets.
Le nombre de slots est suppos gal 8 tandis que le spreading factor est de 2. Ceci donne
une limite de rservation gale la limite de QoS de :
%) 1 . 0 ) ( max( k P k S
error d

Cest aussi le seuil de contrle optimal comme on va dmontrer dans la suite, il est de 3 codes
dans notre cas.
Dans la figure 5.13, trois fonctions de permission sont proposes. La premire est gnreuse
et permet laccs au canal avec une probabilit relativement leve. La deuxime est une
fonction modre, elle descend avec une seule pente vers la limite de contrle qui est de 3. La
troisime suppose que le seuil de contrle est 2 et infrieur la limite de rservation. Cette
fonction est trs restrictive afin de limiter le nombre total dutilisateurs sur le slot.
Dans la figure 5.14, on trace la distribution des utilisateurs pour les trois fonctions de
permission et pour plusieurs cas des utilisateurs accepts par la fonction CAC. On remarque
que pour la deuxime fonction de permission, qui est la fonction modre, la distribution des
utilisateurs est le plus homogne, surtout lorsque plusieurs utilisateurs sont accepts. En effet,
quand 40 utilisateurs sont accepts, 3 codes actifs sont prsents la plupart de temps dans le cas
de f1 et f3 avec une probabilit non ngligeable de dpasser cette limite contrairement au cas
de f2. Ce rsultat est prvisible pour la fonction f1 mais pour la fonction f3 un processus
dinstabilit produit cet effet. Le fait quon ne permette pas aux utilisateurs daccder au
systme augmente le nombre dutilisateurs qui attendent un slot libre. Ds quun slot se libre
plusieurs utilisateurs y accdent et le nombre total de codes actifs sur ce slot dpasse la limite
de rservation. Les utilisateurs doivent quitter le slot et ainsi de suite. Cet effet augmente la
probabilit de perte et diminue la capacit du systme. Ce rsultat est dmontr dans la figure
5.15. Dans cette figure, la probabilit de perte dun paquet data est calcule en fonction de
nombre dutilisateurs dans le systme. Cette probabilit est limite pour 35, 40 et 37
utilisateurs pour la fonction f1, f2 et f3, respectivement. La capacit du systme est donc
maximise pour f2 grce une distribution homogne des utilisateurs sur le canal.


f3 f2 f1
0 1 2 3 4 5
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
fonctions de permission sf = 2
(data)
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n


Figure 5.13 Fonctions de permission (utilisateurs data)
- 104 - 104

0 5 10 15 20 25 30 35 40
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
distribution des utilisateurs en cas de f1(x)
30, 35 et 40 utilisateurs acceptes
nombre de codes actifs


p
r
o
b
a
b
i
l
i
t
e

d
e

x

c
o
d
e
s

a
c
t
i
f
s


0 5 10 15 20 25 30 35 40
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
distribution des utilisateurs en cas de f2(x)
30, 35 et 40 utilisateurs acceptes
nombre de codes actifs
p
r
o
b
a
b
i
l
i
t
e

d
e

x

c
o
d
e
s

a
c
t
if
s




0 5 10 15 20 25 30 35 40
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
distribution des utilisateurs en cas de f3(x)
30, 35 et 40 utilisateurs
acceptes
nombre de codes actifs
p
r
o
b
a
b
i
l
i
t
e

d
e

x

c
o
d
e
s

a
c
t
i
f
s


Figure 5.14 Distribution des utilisateurs (utilisateurs data)

0 5 10 15 20 25 30 35 40
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
x 10
-3
comparaison des fonctions de permission
x,* f1 analytique et simulation
o,.^f2 analytique et simulation
+, f3 analytique et simulation
nombre dutilisateurs
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 5.15 Probabilit de perte (utilisateurs data)
- 105 - 105


10 15 20 25 30 35 40
10
1
10
2
10
3
10
4
comparaison des fonctions de permission
x,* f1 analytique et simulation
o,.^f2 analytique et simulation
+, f3 analytique et simulation
nombre dutilisateurs



d

l
a
i


Figure 5.16 dlai d'attente (utilisateurs data)
Enfin la figure 5.16 montre le dlai dun paquet pour les diffrentes fonctions de permission.
Ce dlai est minimis quand la fonction est gnreuse. Elle augmente lgrement pour la
fonction modre, mais dramatiquement quand la fonction devient trs restrictive. Ceci
dmontre notre discussion sur linstabilit du systme en cas dune fonction restrictive.
Notons enfin que les rsultats analytiques sont aussi valids par des simulations utilisant NS
(Network Simulator) ce qui prouve notre tude mathmatique.
5.8.3 ITC (utilisateurs web)
Dans cette section, on va tudier le systme dans le cas des utilisateurs ITC. Ces utilisateurs
sont reprsents par des sources de trafic web dcries dans le paragraphe 5.3. Les paramtres
proposs sont ceux utiliss dans le systme UMTS et proposs par ETSI dans [36] :
Le dbit utilis est de 8Kb/s.
Le nombre dappels dans une session est gomtrique de moyenne N
p
= 5.
Le temps de lecture est gomtrique de moyenne T
R
= 412s.
Le nombre de rafales dans un appel est gomtrique de moyenne N
b
= 25.
Le temps sparant deux rafales conscutives est gomtrique de moyenne T
sep
.= 0.5s.
Enfin les paramtres de distribution de Pareto sont = 1.1, k = 81.5 et la moyenne dune
rafale est L
w
= 24paquets.
Ce trafic est envoy par une source web vers un utilisateur via le canal satellite. Ces sources
doivent accder au canal satellite dans le sens montant quon va tudier son comportement
dans cette section.
La priorit des sources est intermdiaire entre la voix et le data. Pour cette raison, le point de
dpart est suppos de 0.3 tandis que la limite de contrle est toujours gale la limite de QoS
qui est gal 3. Les trois fonctions de permission compares dans ce cas sont prsentes dans
la figure 5.17.
- 106 - 106
La premire fonction est gnreuse pour diminuer le temps daccs et donc le temps dattente
dun paquet web. La deuxime est modr tandis que la troisime est restrictive et possde
une limite de contrle infrieure celle de QoS.


f3 f2 f1
0 1 2 3 4 5
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
fonctions de permission sf = 2 (web)
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n


Figure 5.17 Fonctions de permission (sources web)


0 100 200 300 400 500 600 700 800
0
0.5
1
1.5
2
2.5
3
x 10
-3
comparaison des fonctions de permission
x f1 simulation
o f2 simulation
+ f3 simulation
nombre dutilisateurs
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 5.18 Probabilit de perte (sources web)
- 107 - 107

200 300 400 500 600 700 800
10
0
10
1
10
2
10
3
comparaison des fonctions de permission
x f1 simulation
o f2 simulation
+ f3 simulation
nombre dutilisateurs
d

l
a
i

(
m
s
)


Figure 5.19 dlai d'attente (sources web)
Dans les figures 5.18 et 5.19 on trace la probabilit de perte et le dlai dattente pour les trois
cas de fonctions de permission. Quand le nombre de sources augmente, la probabilit de perte
et le dlai dattente augmentent. On remarque que le dlai est minimis quand la fonction de
permission est gnreuse mais la perte est augmente dans ce cas. Comme on a dj
mentionn, un dlai moyen est respecter pour les sources web. Ceci reprsente une
deuxime contrainte pour les utilisateurs web autre que la limite de perte. Ces deux
contraintes de QoS contribuent dterminer la capacit du systme. Par exemple, si on
suppose que 200ms [62, 63] est le dlai moyen accept par un paquet web et la probabilit de
perte maximale est toujours de 0.1%, la capacit du systme dans le cas de la fonction
modre est de 750 sources. Cette capacit est dtermine par la probabilit de perte qui
atteint sa limite ce point. Le dlai dattente est de 80ms qui est infrieur au dlai maximal.
Cette tude dtermine la capacit du systme dans le cas des sources web seulement. Dans la
section suivante, ainsi que dans le dernier chapitre, on tudie le multiplexage de service. La
notion des diffrentes priorits daccs est alors applique.
5.8.4 Multiplexage de services RTC, ITC et STC (voix, web et data)
Pour le multiplexage de services, on considre les fonctions de permission optimales pour les
utilisateurs voix et web trouves dans les sections prcdentes. Ces utilisateurs ont une
contrainte de dlai trs petit pour la voix et moyenne raisonnable pour le web. Les
utilisateurs data sont considrs comme best effort et peuvent accepter un dlai relativement
lev. Pour cette raison, on compare deux fonctions de permission pour le data ; la fonction
optimale trouve en cas des utilisateurs data homogne f1 et une deuxime fonction trs
restrictive f2. (figure 5.20)
- 108 - 108


web voix data f1 data f2
0 1 2 3 4 5
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
fonctions de permission pour voix web et data
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n


Figure 5.20 Fonctions de permission en multiplexage de service
Le but de ce paragraphe est de comparer le comportement gnral du systme en cas de f1 et
f2. Dans la figure 5.21, on remarque que la capacit du systme augmente quand la fonction f2
est utilise pour les utilisateurs data. En effet, la capacit totale du systme doit tre calcule
la limite des QoS pour les diffrents utilisateurs. Quand la fonction f1 est utilise, la limite de
QoS pour les utilisateurs voix est atteinte 14 utilisateurs data tandis quelle est atteinte 15
utilisateurs data pour les utilisateurs web et data. La capacit est donc de 14 utilisateurs data
avec les 10 utilisateurs voix et les 100 utilisateurs web. Dautre part, la limite est atteinte 18
utilisateurs data quand f2 est utilise pour les diffrents types dutilisateurs. La capacit est
donc de 18 utilisateurs data, 10 utilisateurs voix et 100 utilisateurs web dans ce dernier cas.


0 5 10 15 20
10
-5
10
-4
10
-3
10
-2
10
-1
10
0
comparaison des fonction de permission data (10 utilisateurs voix et 100 utilisateurs web)
x voix,f1
* voix,f2
o web,f1
. web,f2
+ data,f1
- data,f2
nombre dutilisateurs data
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 5.21 Probabilit de perte en multiplexage de service (voix, web et data)
- 109 - 109

2 4 6 8 10 12 14 16 18 20
10
1
10
2
10
3
10
4
comparaison des fonction de permission data (10 utilisateurs voix et 100 utilisateurs
web)
o web,f1
. web,f2
+ data,f1
- data,f2
nombre dutilisateurs data
d

l
a
i

(
m
s
)


Figure 5.22 Dlai d'attente en multiplexage des service (web et data)
Le dlai dattente pour les utilisateurs data est gnralement plus lev quand la fonction f2
est utilise et il est moins lev pour les utilisateurs web. Ceci est d au fait que linfluence
des utilisateurs best effort est minimise quand la fonction f2 est utilise. A 18 utilisateurs
data, le dlai atteint 200ms pour les utilisateurs web et 1000ms pour les utilisateurs data. La
limite est respecte pour les utilisateurs web tandis que le dlai des utilisateurs data nest pas
catastrophique.
0 2000 4000 6000 8000 10000
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
debit agrege des 10 utilisateurs voix, 10 utilisateurs web, 15 utilisateurs data avec f2(x)
tranche de temps pendant la periode stationnaire
d
e
b
i
t

Figure 5.23 Distribution des utilisateurs en multiplexage de service
La distribution des utilisateurs montre que la probabilit de dpasser la limite de QoS de 3 est
minimise dans le cas o f2 serait utilise avec un nombre dutilisateurs proche de la capacit
du systme (figure 5.23).
- 110 - 110
5.9 Conclusion
Dans ce chapitre, on a tudi un protocole hybride TDMA-CDMA dans le cas des satellites
LEO. Ce protocole S-CDMA/PRMA combine les deux protocoles tudis dans les deux
chapitres prcdents. Une tude mathmatique est faite afin de dterminer les paramtres
essentiels qui influencent lefficacit du protocole. On a propos une fonction CAC capacit
quivalente afin daccepter les utilisateurs temps rel considrs au niveau MAC comme
service RTC. Deux autres classes, ITC et STC, sont proposes pour supporter des utilisateurs
interactifs (web) et best efforts, respectivement. La diffrenciation entre les services est base
sur des diffrentes fonctions de permission qui donnent la priorit maximale aux utilisateurs
RTC puis aux utilisateurs ITC et enfin aux utilisateurs STC. Ltude mathmatique base sur
des modles de chane de Markov est possible dans le cas des utilisateurs voix et des
utilisateurs de transfert des fichiers. Quant aux utilisateurs web ou au multiplexage de
services, des simulations utilisant NS sont raliss. La discussion mathmatique et par
simulation montre quune fonction de permission modre donne toujours des meilleurs
rsultats quand un seul type dutilisateurs occupe le canal. Dautre part, grce des calculs
mathmatiques on dmontre quun facteur dtalement (sf) de 2 maximise la capacit du
systme. Enfin, dans le cas de multiplexage de service, on remarque que lorsque la fonction
de permission pour les utilisateurs STC (data) dcrot, la capacit totale du systme augmente.
Les utilisateurs data influencent moins les autres usagers qui ont une certaine contrainte de
dlai. On peut dire que ces utilisateurs sont traits comme best effort.
Un rsultat majeur de ce chapitre est le fait que le protocole S-CDMA/PRMA russisse
garantir une QoS aux diffrents utilisateurs dune faon souple et avec le moindre gaspillage
de ressources. Ce protocole peut, en effet, garantir un temps rel et une perte de 1% pour les
utilisateurs voix mme dans le cas o des autres types de sources partageraient le canal. Une
diffrentiation de service est ralise par ce protocole en appliquant une stratgie de priorit
avec des bons choix de niveaux afin de garantir toujours la QoS demande par chaque
utilisateur. Ce protocole montre que mme dans des cas trs exigeants en terme de QoS et
dans des contextes difficiles comme en LEO, on peut toujours utiliser des protocoles souples
pour garantir, avec une probabilit acceptable, la QoS avec une bonne utilisation de
ressources.
Notons enfin que la sparation des diffrents utilisateurs temporellement ncessite des
mcanismes dallocation de ressources quon va tudier dans le chapitre suivant. Dans ce
chapitre on va aussi comparer les diffrents protocoles proposs dans cette thse ainsi que
dautres protocoles tudis dans la littrature dans le cas des satellites.
- 111 - 111









6.1 Introduction
Dans ce chapitre, les diffrents protocoles tudis dans le cas de satellites LEO sont compars
du point de vue de la performance mais aussi de la simplicit dimplmentation surtout dans
le cas de lintgration de plusieurs services. La performance est dduite de la capacit totale
du systme en terme du nombre dutilisateurs de diffrents types et des diffrentes qualits de
service en terme de probabilit de perte et de dlai dattente.
Lallocation de ressources pour les diffrents services est un problme essentiel quand le
canal est utilis par diffrents types dutilisateurs qui possdent diffrentes sources de trafic et
diffrentes QoS. La question de sparer les diffrents types dutilisateurs ou de les mlanger
tous ensemble est pose dans ce chapitre en considrant trois types de service supports par
les trois MTCs dfinis dans le chapitre prcdent. Le RTC supporte les utilisateurs voix, le
ITC les utilisateurs web et le STC les utilisateurs data. Des techniques hybrides dallocation
de ressources sont ensuite proposes pour maximiser lefficacit du systme. La fonction
CAC et la stratgie dallocation de ressources sont lies par le fait que la fonction CAC doit
connatre tout instant les ressources disponibles pour chaque type de service. La fonction
CAC utilise toujours la mthode de capacit quivalente discute dans les chapitres
prcdents (paragraphes 3.4, 4.5 et 5.5).
Avant de passer au problme dallocation de ressources on va comparer les protocoles daccs
tudis dans cette thse : S-PRMA, le S-CDMA et le S-CDMA/PRMA. Ces protocoles
proposs et tudis dans cette thse ont t optimiss pour tre utilise dans le contexte des
satellites. Loptimisation faite par des tudes mathmatiques et par simulation dtermine les
diffrents paramtres qui influencent lutilisation de ces protocoles afin de maximiser la
capacit du canal radio.
Dans la section 2, on compare les diffrents protocoles daccs proposs dans cette thse pour
dterminer les protocoles qui maximisent la performance pour les sous-systme voix et data.
Dans la troisime section le problme dallocation de ressources est pos. On introduit ltat
de lart de ce problme dans le contexte satellitaire et des systmes utilisant CDMA pour
ensuite comparer des stratgies dallocation en S-CDMA et S-CDMA/PRMA. Enfin la
section quatre donne les conclusions essentielles du chapitre.
- 112 - 112
6.2 Comparaison des protocoles
Dans cette section, on compare les trois protocoles daccs, S-PRMA, S-CDMA et S-
CDMA/PRMA dans le cas des utilisateurs voix homognes reprsents par des sources ON-
OFF et dans le cas des utilisateurs data reprsents par des sources F-A gomtriques dcrites
dans le chapitre 3. Les comparaisons sont faites par calcul mathmatique et par simulation
afin de dterminer les protocoles qui maximisent la capacit du systme.
Les trois protocoles peuvent tre dduits dun seul protocole qui est le S-CDMA/PRMA. En
effet, le S-CDMA/PRMA contient un nombre n
S-CDMA/PRMA
de slots et un nombre de codes sur
chaque slot reprsents par sf
S-CDMA/PRMA.
Un code dans un slot reprsente lunit de
transmission dans ce protocole. Une fonction de permission contrle laccs sur ces codes de
faon maximiser lutilisation de chacun. Les deux autres protocoles S-PRMA et S-CDMA
peuvent tre considrs comme des cas particuliers du S-CDMA/PRMA.
En S-CDMA, le nombre de slots est 1 ( n
S-CDMA
= 1 ) et le nombre de codes est reprsents
par le facteur dtalement qui est dduit du prcdent par la multiplication du facteur
dtalement et du nombre de codes (sf
S-CDMA
= sf
S-CDMA/PRMA
n
S-CDMA/PRMA
). La fonction de
permission joue dans ce cas le mme rle que pour le S-CDMA/PRMA et dpend du nombre
de codes sur la trame prcdente.
En S-PRMA, le nombre de codes par slot est de 1 ( sf
S-PRMA
= 1) tandis que le nombre de slots
par trame est dduit du S-CDMA/PRMA par lquation (n
S-PRMA
= sf
S-CDMA/PRMA
n
S-
CDMA/PRMA
). La fonction de permission prend deux valeurs dans ce cas, une valeur non nulle si
le slot dans la trame prcdente tait disponible et une valeur nulle si ce slot tait rserv. La
notion de disponible et rserv peut tre vue de cette faon ce qui rend le protocole S-
PRMA un cas particulier du protocole S-CDMA/PRMA.
De ce point de vue, on peut comparer les diffrents protocoles daccs comme tant une
comparaison entre plusieurs choix des paramtres du protocole S-CDMA/PRMA, le
changement du facteur dtalement ralisent le passage dun protocole lautre.
6.2.1 Utilisateurs voix
Les utilisateurs voix utiliss sont des sources ON-OFF de paramtres t
on
= 1s et t
off
= 1.35s.
Le dbit dun utilisateur voix est 8Kb/s qui devient 9.6Kb/s au niveau MAC. La bande
passante est de 155Kb/s par chaque frquence porteuse. Ceci permet lutilisation de 16 slots
en cas de S-PRMA ou 8 slots avec sf = 2 en cas de S-CDMA/PRMA ou enfin un facteur
dtalement de 16 dans le cas de S-CDMA.
En utilisant les diffrents paramtres doptimisation trouvs pour les protocoles daccs dans
les chapitres prcdents et reprsents par les fonctions de permission, on obtient le tableau
6.1 des capacits du systme en terme des utilisateurs voix.
Tableau 6.1 Comparaison des capacits des protocoles d'accs
Capacit\protocole S-PRMA S-CDMA S-CDMA/PRMA
Nombre dutilisateurs 32 38 42

Dans le cas de S-PRMA, une valeur de probabilit de permission de 0.7 est considre. Une
fonction de permission qui est la fonction unit (f(x) = 1) est utilise en S-CDMA, et une
permission gnreuse (voir chapitre 5) est considre dans le cas de S-CDMA/PRMA.
Calculons maintenant le facteur defficacit de multiplexage statistique pour les utilisateurs
voix. Ce facteur est le rapport entre le nombre dutilisateurs voix accepts par le systme et ce
- 113 - 113
nombre en cas de multiplexage parfait. Ce dernier est gal au nombre de ressources alloues
aux utilisateurs voix, divis par le rapport dactivit des utilisateurs voix. Si M
v
est le nombre
maximum dutilisateurs voix accepts, r
v
est le nombre de ressources alloues aux utilisateurs
voix et
v
est le facteur dactivit (0.42 dans notre cas), on a :
= M
v

v
/ r
v

o r
v
reprsente le nombre de ressources ddies aux utilisateurs voix. Cest le nombre
dutilisateurs voix quon peut accepter en cas du mode circuit et sans lutilisation dune
couche MAC particulire. La fonction CAC accepte dans ce cas un utilisateur si son dbit
maximal est disponible. Ce nombre qui ne tient compte que de la bande passante du canal et
le dbit maximal de la source est calcul par :
r
v
= BW/R = 155/8 = 19.
En utilisant ces valeurs on obtient le tableau 6.2.
Tableau 6.2 Comparaison des capacits des protocoles d'accs
Efficacit\protocole S-PRMA S-CDMA S-CDMA/PRMA

0.7 0.84 0.92

Il est clair que le protocole S-CDMA/PRMA a un facteur de multiplexage trs lev et
suprieur aux diffrents rsultats trouvs dans la littrature pour le systme LEO et qui ne
dpassent pas 0.8 [27], [50] et [55]. En plus, le cas de S-CDMA est aussi intressant du point
de vue du multiplexage statistique.
En considrant le fait que le S-PRMA et S-CDMA sont des cas particuliers de S-
CDMA/PRMA on peut analyser les rsultats comme suit ; en S-CDMA, une permission
daccs est toujours gale 1 et la probabilit de drop dun paquet est nulle tandis que la
probabilit derreur est leve. En S-PRMA, la fonction daccs passe directement de 0.7
zro et en tat stationnaire, un nombre limit de slots peuvent tre accds ce qui augmente la
probabilit de drop. Un compromis entre la probabilit derreur et celle de drop est ralis en
cas de S-CDMA/PRMA avec un facteur dtalement de 2.
Une autre raison essentielle de la meilleure performance de S-CDMA/PRMA est lexcs de
ressources en cas de S-CDMA/PRMA avec facteur dtalement de 2. En effet, les ressources
disponibles en S-PRMA sont 16 slots, elles deviennent 19 codes en S-CDMA et 24 codes en
S-CDMA/PRMA (quation 5.6 et 5.7). Ceci augmente lefficacit du systme
considrablement.
6.2.2 Utilisateurs data
Les utilisateurs data sont considrs comme des sources de transfert des fichiers F-A qui
peuvent tre reprsentes par des sources ON-OFF de paramtres :
= 0.5 et L
s
= 100 paquets
Dans le cas de S-PRMA, on suppose quune retransmission est ncessaire au niveau MAC
pour les utilisateurs data pour garantir une probabilit de perte acceptable. Ceci nest pas
ncessaire en cas de S-CDMA/PRMA et S-CDMA puisquon peut agir sur la fonction de
permission pour diminuer la probabilit de perte au-dessous du seuil de la QoS. Ceci
reprsente un avantage pour les protocoles S-CDMA/PRMA et S-CDMA.
Dans cette section, on va comparer le dlai dattente dun paquet data dans le tampon de
lutilisateur selon diffrents protocoles.
- 114 - 114
S-PRMA analyse et simulation


, . S-PRMA analyse et simulation
0 5 10 15 20 25 30 35 40
0
50
100
150
200
250
300
350
400
450
500
comparaison des protocoles d"accs
o,* S-CDMA analyse et simulation
x,- S-CDMA/PRMA analyse et simulation
nombre dutilisateurs
d

l
a
i

m
o
y
e
n

e
n

m
s


Figure 6.1 Dlai d'attente des paquets data pour les diffrents protocoles d'accs
Dans la figure 6.1, on remarque que le dlai dattente est minimal dans le cas de S-PRMA et
maximal dans le cas de S-CDMA. Ceci est d essentiellement au temps sparant deux
tentatives successives qui est le temps dun slot. En CDMA pur, ce temps est 16 fois plus
grand quen PRMA. Une deuxime raison est la possibilit de retransmission en S-PRMA,
qui permet lutilisation dune probabilit de permission de 0.3 tandis que cette permission est
moins leve dans les fonctions de permission de S-CDMA et S-CDMA/PRMA. Une
fonction qui dbute par une probabilit de permission de 0.3 est utilise en S-CDMA tandis
quune fonction qui dbute par 0.2 est utilise en S-CDMA/PRMA (chapitres 4 et 5).
Remarquons que le dlai dattente en S-CDMA/PRMA est infrieur celui du S-CDMA
puisque la trame contient 8 slots en S-CDMA/PRMA et un slot en S-CDMA. Lattente en S-
CDMA/PRMA est acceptable par rapport celle de S-PRMA. En tenant en compte lavantage
du protocole S-CDMA/PRMA pour les utilisateurs voix, on considre ce protocole comme
tant le meilleur du point de vue de lefficacit du systme.
6.2.3 Multiplexage de services
En cas de multiplexage de services, plusieurs problmes sont poss et diffrentes techniques
peuvent tres utilises pour amliorer la capacit totale du canal. Dans les chapitres
prcdents, on a tudi le multiplexage des utilisateurs voix et transfert des fichiers en cas de
S-PRMA, des utilisateurs voix avec des Emails en cas de S-CDMA et trois types
dutilisateurs qui sont la voix, le transfert des fichiers et le web en cas de S-CDMA/PRMA.
On remarque quen S-CDMA et S-CDMA/PRMA, on peut toujours agir sur les fonctions de
permission pour augmenter la capacit du systme. Dans ce qui suit, on va tudier le
multiplexage des trois types des utilisateurs ; voix, web et transfert des fichiers en cas de deux
protocoles S-CDMA et S-CDMA/PRMA. Le transfert des fichiers peut reprsenter des
sources denvoi des emails courts de longueur moyenne comparable au talkspurt (2Ko). Ceci
ncessite des stratgies dallocation de ressources pour les diffrents services supports au
- 115 - 115
niveau MAC par les trois MTCs dfinis dans les chapitres prcdents : RTC (Rapid Transfer
Capability), ITC (Intermediate Transfer Capability) et STC (Slow Transfer Capability).
6.3 Allocation de ressources
La signification de lallocation de ressources est trs importante en canal satellite. Ceci est d
au prix lev de ressources qui sont rares dans ce contexte. La bande passante doit tre utilise
dune manire efficace afin de ne pas gaspiller les ressources. Lintgration des diffrents
services sur le mme canal complique le problme et ncessite des techniques avances. Le
long RTD (temps aller-retour) rend les techniques dynamiques dallocation plus difficile
raliser. On parle de deux niveaux dallocation de ressources :
Niveau de lutilisateur ; en assignant un utilisateur les ressources ncessaires pour
garantir sa QoS.
Niveau du service ; en prvoyant un ensemble de ressources pour un tel type de
service. Cet ensemble peut tre fixe ou dynamique. Si lensemble est fixe, on risque de
gaspiller les ressources. Les frontires sparant les diffrents ensembles de ressources
sont fixes ou mobiles.
Dans cette section, on introduit ltat de lart des stratgies dallocation de ressources en
satellite ainsi quen systme CDMA et TD-CDMA. On compare ensuite quelques stratgies
utilises par les protocoles S-CDMA et S-CDMA/PRMA pour tudier leur comportement en
cas de multiplexage de services.
6.3.1 Allocation de ressources dans la littrature
Dans cette section, on va prsenter brivement diffrentes stratgies dallocation de
ressources dans les deux contextes TDMA et CDMA. Des propositions faites pour le TD-
CDMA sont aussi dcrites de faon introduire notre travail dans ce domaine.
TDMA
Dans le contexte TDMA, plusieurs stratgies sont proposes dans le contexte de satellite GEO
[67, 68, 69]. Le lien montant est structur en des trames divises en slots qui reprsentent les
canaux ou les ressources radios. Ces ressources sont partages entre les diffrents types de
service dune manire fixe ou variable.
Quand la division est fixe, un type de service est assign un nombre de canaux en permanence
et les autres services nont pas le droit dutiliser ces canaux. Cette technique rigide est
gnralement inefficace. En effet, un ensemble de ressources peut tre sous-utilis si une
service gnre peu de trafic gnr par un tel service tandis quun autre ensemble peut souffrir
de congestion cause dun trafic lev du service associ.
Les frontires mobiles peuvent remdier ce problme en permettant un service dutiliser
les ressources associes dautres services en cas de congestion. La difficult est due dans ce
cas aux diffrents QoS associs aux diffrents services. Quand on intgre la voix avec le data,
de ressources ddies la voix et qui sont utilises par le data peuvent bloquer la transmission
des paquets vocaux qui sont temps rel et qui nacceptent aucun dlai. La premption des
utilisateurs data peut rsoudre ce problme mais au prix de perdre les paquets data envoys.
On remarque que des techniques frontire mobile peuvent garantir la QoS des diffrents
services et diminuer le temps dattente des utilisateurs data [70, 71, 72].
En gnral, les services sont groups en deux catgories ; synchrone et asynchrone. La
premire reprsente des services qui ncessitent une rservation de ressources pour des
longues dures tandis que la deuxime reprsente des sources qui envoient des rafales pendant
- 116 - 116
des basses dures et dune faon asynchrone. La priorit est donne aux utilisateurs
synchrones mais leurs ressources peuvent tre utilises par les autres types des sources.
Dans [16], les auteurs proposent un schma dallocation de ressources deux frontires afin
dintgrer trois types de services. Un service CBR qui a un dbit maximal garanti, un service
bursty qui est trait comme un VBRnrt et enfin un service best effort. Le schma dallocation
de ressources est le suivant :

Trame = N
F
slots



Partie (1) partie (2) partie (3)



CBR = C
1
slots Best Effort = CRP slots donne bursty = D slots

C
2
slots

Figure 6.2 Allocation de ressources en TDMA avec frontires variables.
La trame est compose de trois parties ;
Partie (1) o les utilisateurs CBR ont la priorit maximale puis les utilisateurs bursty et
enfin les utilisateurs best effort.
Partie (3) o les utilisateurs bursty ont la priorit maximale puis les utilisateurs best
effort. Les utilisateurs CBR nont pas le droit daccder cette sous-trame.
Partie (2) est gre suivant un algorithme dcrit dans [16].
Pour dcrire la stratgie dallocation de ressources, on dcrit le comportement de la fonction
de contrle dadmission. Le CAC agit toujours sur les demandes CBR qui ont une priorit
daccs sur la partie 1, mais pas sur la partie (2). Supposons, pour simplifier le problme,
quun utilisateur CBR utilise un seul slot dans chaque trame.
Si on a une requte de demande de connexion et le nombre de slots rservs pour les
utilisateurs en cours (qui est dans notre cas, le nombre dutilisateurs CBR) est infrieur C
1
,
on accepte cette requte. Si ce nombre est gal C
1
et on a toujours des requtes de demande,
on teste les utilisateurs donnes bursty. Si le nombre des requtes pour ces utilisateurs est
suprieur un certain seuil L
thrld
, le CAC refuse la demande. Sinon, il accepte la demande
CBR et rserve un slot de la parie (2) cet utilisateur. Si le nombre de slots, de la partie (2),
associs aux utilisateurs CBRs, dpasse une valeur gale (N
F
C
1
D), le CAC refuse la
demande CBR.
Les valeurs L
thrld
et sont dtermines par une simulation afin de diminuer le dlai dattente
des utilisateurs data sans avoir une grande probabilit de blocage pour les utilisateurs CBRs.
Dans [16], on propose un seuil dynamique qui dpend de nombre de slots de la partie (2)
utilis par les utilisateurs CBRs. Si (L
thrld
)
i
est le seuil initial, N est le nombre de slots de la
partie (2) associs aux utilisateurs CBRs, le nouveau seuil (L
thrld
)
d
devient :
- 117 - 117
N C
C L
L
i thrld
d thrld
+

1
1
) (
) ( .
CDMA et TD-CDMA
Dans [64, 65, 66], quelques stratgies dallocation de ressources sont prsentes dans le cas de
systme CDMA et TD-CDMA. Le but de ces tudes est de raliser une allocation de
ressources pour supporter plusieurs QoSs, minimiser la probabilit de perte et avoir une
utilisation acceptable des ressources.


Mesure dinterfrence


QoS 1

requtes
QoS 2


QoS 3
Contrle
dadmission
Estimateur
des
ressources

Allocation de
puissance et
de dbit
Allocation
temporelle

Figure 6.3 Stratgie d'allocation de ressources en CDMA et TD-CDMA
Un estimateur contrle lallocation de ressources en se basant sur les mesures dinterfrence
et sur la situation de trafic des diffrents services. Ceci est reprsent par deux entrs sur cet
estimateur dans la figure. Cet estimateur agit sur le planificateur de temps pour distribuer les
ressources temporelles entre les diffrents services tandis que le planificateur de puissance
distribue les ressources code entre les services. Ce modle ncessite un trafic de contrle
important afin dutiliser la flexibilit du systme CDMA pour allouer les ressources. En se
basant sur les informations reues par lestimateur, la fonction de contrle dadmission peut
dcider daccepter ou de refuser une requte. Ce systme va tre utilis dune faon souple et
dynamique dans notre modle dallocation pour les deux protocoles S-CDMA et S-
CDMA/PRMA. Notons que dans notre modle, les sources de trafic reprsentent des serveurs
denvoi des fichiers et de web. Les paquets data gnrs par les utilisateurs sont considrs de
trs bas dbit et peut tre servis dune faon asynchrone comme dcrit dans [36]. Dans ce
schma, pour servir deux types de trafics, on dfinit deux types de trames ; les trames
synchrones et les trames asynchrones. Dans les trames asynchrones, on envoie des rafales
alatoires, alors que dans les trames synchrones on envoie des donnes synchronises.
La trame 0 est utilis pour accder au rseau alatoirement. Des bursts daccs alatoires sont
alors envoys dune manire asynchrone tout en demandant une partie de la bande passante
associe ce service. Laccs sur cette trame se fait en CDMA Aloha. Pour les autres
services, une demande de connexion est ncessaire. Cette demande se fait dune faon
alatoire et la trame 0 peut tre utilise dans ce but. Si la demande est accepte, lutilisateur
commence envoyer ses donnes en utilisant un nombre de slots rservs. Il envoie ses
donnes en mode quasi-synchrone sur les trames synchrones en utilisant CDMA/TDMA
hybride.
- 118 - 118





MF







Trame pour laccs asynchrone. 20ms trame pour lenvoi des donnes. 20ms


plusieurs codes par trame plusieurs codes par slot
slot0
trame0 tramei
Burst
alatoi
re
dacc

Figure 6.4 Allocation de ressources en TDMA/CDMA entre les paquets synchrones et asynchrones
Dans ce qui suit, on va tudier lallocation de ressources sur les trames synchrones entre trois
types de sources utilisateurs du canal : les utilisateurs voix qui se comportent comme des
sources ON-OFF, le serveur web qui aprs la rception dune requte commence envoyer
des informations comme dcrit dans 5.3.2 et la troisime reprsente des sources denvoi des
fichiers comme dcrit dans 3.2.2 qui peuvent reprsenter des sources denvoi des emails
courts. Ces sources doivent envoyer leurs paquets dune faon synchrone avec diffrentes
QoSs. La source voix est considre comme un service STC, la source web comme ITC et
enfin la source de transfert des fichiers comme STC.
6.3.2 Allocation de ressources en S-CDMA
La notion de slot est inexistante en S-CDMA. Les ressources sont divises sur les deux plans
frquentiels et de code. Lunit dallocation temporelle dans la figure 6.3 nexiste pas dans ce
cas. Dautre part, le dbit est suppos fixe pour les diffrentes sources, grce la possibilit
dutiliser plusieurs codes dans le cas o le dbit dpasserait le dbit unit (bande passante
dun seul code). Une telle source est vue dans ce cas comme lagrgation des plusieurs
sources units.
La figure 6.3 est donc simplifie dans ce cas et peut tre reprsente par la figure 6.5.
Lestimateur de ressources peut agir sur lallocation de puissance dune faon directe en
allouant des codes pour chaque classe de service suivant la charge du service correspondant.
Cette charge est mesure par la file dattente des requtes. Dans cette section, on va comparer
deux stratgies dallocation. La premire consiste isoler leffet de lestimateur de ressources
sur lallocation de codes en utilisant une technique dallocation souple afin de raliser une
certaine flexibilit du canal : cest la mthode dallocation fixe. La deuxime permet
lestimateur dagir sur lunit dallocation de ressources pour changer la partage de ressources
entre les diffrentes classes de service : cest la mthode dallocation dynamique.
- 119 - 119

Mesure dinterfrence


QoS 1

requtes
QoS 2


QoS 3
Contrle
dadmission
Estimateur
des
ressources

Allocation de
puissance

Figure 6.5 Allocation de ressources en S-CDMA
6.3.2.1 Allocation fixe
Le protocole S-CDMA est toujours utilis avec diffrentes fonctions de permission pour les
diffrents services. La notion de permission permet une allocation souple de ressources mme
si lestimateur ninfluence pas lallocation des codes. Les codes sont diviss en trois
ensemble : le premier est accessible par tous les utilisateurs suivant des fonctions de
permission qui donnent une priorit maximale aux utilisateurs voix puis aux utilisateurs web
et enfin aux utilisateurs data. Le deuxime est accessible par les utilisateurs voix et web
seulement avec une priorit pour les utilisateurs voix. Et enfin, le troisime est utilis
seulement par les utilisateurs voix. La figure 6.6 montre cette stratgie.
Trame







C
1





C
2



C
3


Figure 6.6 Frontires fixes en S-CDMA
Dans la figure 6.6, lensemble C
1
est accessible par les trois types de service, lensemble C
2

est accessible par la voix et le web tandis que lensemble C
3
est accessible par la voix
seulement. Les frontires qui sparent les diffrents ensembles sont fixes mais lallocation
reste souple puisque les fonctions de permissions dpendent toujours de la charge sur la trame
comme on a expliqu dans le chapitre 4 de S-CDMA. Pour raliser une telle stratgie, les
- 120 - 120
fonctions de permission pour les diffrents utilisateurs doivent avoir des seuils de permission
convenables comme dans la figure 6.7.



STC ITC RTC
C1 C1
+ C2
C1
+ C2 + C3
a3
. a2

fonctions de permission
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n

a1

Figure 6.7 Fonctions de permission pour lallocation de ressources fixe
Les fonctions de permission dcrites dans la figure 6.7 limitent laccs aux codes du canal
suivant la frontire alloue au service. Pour le service STC, la limite est C
1,
elle est de C
1
+ C
2

pour le service ITC et C
1
+ C
2
+ C
3
pour le service RTC.
Remarquons que ces limites sont aussi les limites de rservation. Un utilisateur STC rserve
le code choisi par contention si le nombre de codes utiliss par les diffrents types de service
est infrieur C
1
, Un utilisateur ITC rserve le code accd si le nombre de codes utiliss par
les diffrents types de service est infrieur C
1
+ C
2
et un utilisateur RTC rserve le code
choisi si le nombre de codes utiliss par les diffrents types de service est infrieur C
1
+ C
2
+
C
3
.
6.3.2.2 Mthode dallocation dynamique
Cette mthode suppose que dans la figure 6.6 la frontire qui spare lensemble C
1
de
lensemble C
2
est dynamique. Le but de cette stratgie est de diminuer le dlai dattente des
utilisateurs STC quand le systme nest pas trs charg. Quand la charge voix et web est
infrieure un seuil L
1
, la frontire est dplace de C
2
codes afin de diminuer le dlai
dattente de ces utilisateurs. Quand cette charge dpasse une deuxime limite L
2
, la frontire
revient sa place initiale. Les valeurs de L
1
et L
2
sont choisis de faon garantir toujours la
QoS des utilisateurs voix et web et que la diffrence L
2
-L
1
ralise une gamme dhystrsis
pour assurer la stabilit du systme.
En pratique, le systme dmarre avec une fonction de permission pour le data qui a C
1
+ C
2

comme seuil de contrle. Lorsque la charge des utilisateurs accepts par la fonction CAC
dpasse une limite de L
2
, cette fonction de probabilit est rduite et la limite de permission
devient C
1
. Le systme doit garantir dans ce cas la QoS des utilisateurs voix et web. Quand un
nombre dutilisateurs quittent le canal et la charge des utilisateurs voix et web dans le canal
devient infrieur L
1
la fonction de permission pour les utilisateurs STC prend la valeur
- 121 - 121
initiale de C
1
+ C
2
comme limite. La figure 6.8 prsente cette stratgie dallocation sous
forme graphique.
Trame







C
1



C
2



C
3




STC ITC RTC
C1 C1
+ C2
C1
+ C2 + C3
a3
. a2

fonctions de permission
nombre de codes actifs



p
r
o
b
a
b
i
l
i
t
e

d
e

p
e
r
m
i
s
s
i
o
n

a1

Figure 6.8 Allocation dynamique en S-CDMA
Dans la figure 6.8, on remarque que la frontire de lensemble C
1
oscille entre deux limites en
fonction de la charge totale des utilisateur voix et web. La fonction de permission des
utilisateurs data reste toujours la moins prioritaire afin de respecter la QoS des utilisateurs
voix et web. La frontire sparant C
2
et C
3
est fixe puisque cette frontire reprsente la
diffrence de la probabilit de perte accepte par un utilisateur voix et un utilisateur web. Un
utilisateur voix accepte 1% de perte des paquets ce qui lui permet dutiliser C
1
+ C
2
+ C
3

codes avec une perte acceptable tandis quun utilisateur web (et data) naccepte que 0.1% de
perte, ce qui lui permet un nombre maximal de C
1
+ C
2
codes actifs. Notons que la diffrence
entre les QoSs peut tre rsolue en choisissant des fonctions de permission convenable
comme on a dmontr dans le paragraphe 4.8.3.
Notons enfin que la dcision de dplacement de frontire est prise localement au sein du
satellite. Les utilisateurs accepts par la fonction CAC sont donc les utilisateurs accepts dans
une cellule prcise. Le nombre total dutilisateurs accepts par le NCC (Network Control
Center) nagit pas sur cette stratgie dallocation.
6.3.2.3 Comparaison des deux stratgies dallocation
La comparaison des stratgies dallocation est base sur des simulations. Le simulateur NS est
utilis pour simuler un systme LEOS comme dcrit dans le deuxime chapitre. Une
technologie multi-faisceaux est utilise. Dans chaque faisceau on a 24 frquences porteuses.
avec une bande passante montante gale la bande passante descendante de 155Kb/s. Le G/W
a une bande de 155Mb/s ainsi que la liaison inter-satellite. Plusieurs utilisateurs de diffrents
types peuvent envoyer en mme temps en utilisant diffrents codes. Les utilisateurs sont de
types voix, web et data.
Une source voix se comporte comme une source ON-OFF avec les paramtres (t
on
= 1s et t
off

= 1.35s ).
Une source web se comporte comme dcrit dans le paragraphe 5.3.2 avec les paramtres :
Le dbit utilis est de 8Kb/s.
Le nombre dappels dans une session est gomtrique de moyenne N
p
= 5.
- 122 - 122
Le temps de lecture est gomtrique de moyenne T
R
= 412s.
Le nombre de rafales dans un appel est gomtrique de moyenne N
b
= 25.
Le temps sparant deux rafales conscutives est gomtrique de moyenne T
sep
.= 0.5s.
Enfin les paramtres de distribution de Pareto sont = 1.1, k = 81.5 et la moyenne dune
rafale est L
w
= 24paquets.
Une source data se comporte comme dcrit dans 3.2.2 avec les paramtres = 0.25 et L
s
=
100 paquets. Cest une source denvoi des courts messages.
Les frontires dallocation de ressource sont : (C
1
= 16, C
1
+ C
2
= 18 et C
1
+ C
2
+ C
3
=20).
Dans le cas de la fonction dynamique, on dfinit la charge gnr par un tel service par la
valeur M o est le facteur dactivit tandis que M est le nombre dutilisateurs appartenant
cette classe de service accepts par la fonction CAC. Dans notre exemple, la charge des
utilisateurs voix et web est de (
v
M
v
+
w
M
w
). Le facteur dactivit est le rapport entre le temps
moyen dactivit sur le temps moyen dun cycle (activit + inactivit). Il est calcul comme
suit :
. 027 . 0
. 42 . 0

+ +

p R sep b p f w b p
f w b p
w
off on
on
v
N T T N N T L N N
T L N N
t t
t


La charge en voix et web est dtermine par (0.42M
v
+0.027M
w
) Erlangs. On sait que le
systme peut supporter jusqu 17 Erlang, les seuils dallocation sont L
1
= 10 et L
2
= 12 dans
cet exemple.
Les fonctions de permission sont traces dans la figure 6.9 et 6.10, et sont inspirs des
discussions faites en 4.8.3. Dans le cas o lallocation est statique, les fonctions de la figure
6.10 sont utilise tout le temps tandis que dans le cas o lallocation est dynamique, les
permissions oscillent entre la figure 6.9 et 6.10 suivant la charge du systme. La limite
daccs qui est aussi celle de rservation se dplace entre 16 et 18 comme dj dcrit.


0 5 10 15 20 25
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
fonctions de permission
nombre de codes simultans
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n


Figure 6.9 Fonctions d'accs en allocation fixe et en allocation dynamique haute charge
- 123 - 123

0 5 10 15 20 25
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
fonctions de permission
nombre de codes simultans
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
m
i
s
s
i
o
n


Figure 6.10 Fonctions de permission en allocation dynamique basse charge
Remarquons quen cas de charge leve, les deux stratgies se comportent de la mme faon.
On va dmontrer par les simulations que le dlai dattente pour les paquets data diminue
considrablement dans le cas dallocation dynamique lorsque la charge voix et web est basse.
Supposons que cette charge est de 10 Erlangs ; elle est infrieure au seuil L
1
et dans la
stratgie dallocation dynamique, la figure 6.10 est utilises pour les fonctions de permission
tandis que la figure 6.9 est toujours utilise dans la technique dallocation fixe.
On remarque dans la figure 6.11 que le dlai dattente des paquets data est considrablement
diminu en cas de stratgie dallocation dynamique. Lorsque le nombre de sources data est
lev, on remarque un facteur de 3 entre le dlai dattente en tat statique et celui en
dynamique. En plus, on remarque que le dlai des paquets web est aussi rduit dans le cas
dallocation dynamique. Ce rsultat est imprvisible puisque leffet des utilisateurs data sur
les utilisateurs web est sens diminuer en cas dallocation statique o la fonction de
permission est infrieure. En fait, dans le cas o la probabilit de permission est trs basse, le
nombre de sources data qui attendent une permission daccs augmente, ce qui augmente
leurs effets sur les utilisateurs web. Ce mme effet est remarqu aussi dans la mesure de la
perte des paquets des utilisateurs voix dans la figure 6.12. Leffet des sources data sur les
utilisateurs voix augmente quand la stratgie dallocation fixe est utilise. Le mme effet est
remarqu tout au long de cette thse pour les protocoles S-PRMA, S-CDMA et S-
CDMA/PRMA ce qui nous a men faire des compromis dans le choix des paramtres.
Notons enfin que cette comparaison montre que lutilisation dune stratgie dallocation
dynamique augmente la flexibilit du systme, mais aussi amliore la QoS et la capacit
totale. Des stratgies dallocation dynamique plus avances peuvent tre utilises pour
amliorer encore plus lefficacit du systme.
- 124 - 124

0 5 10 15 20
10
1
10
2
10
3
10
4
+ web (dynamique)
* data (dynamique)
o web (statique)
x data (statique)
dlai des paquets web et data avec 10E de charge
nombre dutilisateurs data
d

l
a
i

(
m
s
)


Figure 6.11 Dlai d'attente des paquets data et web en fonction des sources data


0 5 10 15 20
10
-5
10
-4
10
-3
10
-2
+ voix (dynamique)
* data (dynamique)
o voix (statique)
x data (statique)
perte des paquets data et voix avec 10E de charge
nombre dutilisateurs data


p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e


Figure 6.12 Perte des paquets voix et data en fonction de nombre de sources data

- 125 - 125
6.3.3 Allocation de ressources en S-CDMA/PRMA
En S-CDMA/PRMA, les ressources sont partages sur trois plans ; le plan frquentiel, le plan
temporel et le plan de code. Comme dans le cas de S-CDMA, le partage de ressources entre
les diffrents services nutilise pas le plan frquentiel. Dans [73, 74], on dmontre que tout
partage frquentiel diminue le gain de multiplexage et rend le systme rigide et inflexible. Les
deux plans utiliss pour le partage de ressources sont le plan de code et le plan temporel. Le
nombre de codes est trs limit en S-CDMA/PRMA et une division de ressources au niveau
de code est difficile raliser. La division au niveau temporel parat plus logique et efficace.
Le schma dallocation devient :

Mesure dinterfrence


QoS 1

requtes
QoS 2


QoS 3
Contrle
dadmission
Estimateur
des
ressources

Allocation
temporelle

Figure 6.13 Allocation de ressources en S-CDMA/PRMA
Lallocation temporelle est estime suivant les ressources disponibles qui influencent aussi la
dcision de la fonction de contrle dadmission. Les trois classes de services sont le RTC
(utilisateurs voix), le ITC (utilisateurs web) et le STC (utilisateurs data). Lallocation de
ressources na pas une dimension de code dans la figure 6.13 puisque les codes sont distribus
entre les utilisateurs suivant le protocole daccs S-CDMA/PRMA expliqu dans le chapitre
prcdent de faon donner les utilisateurs RTC la priorit maximale, puis les utilisateurs
ITC et enfin STC.
Dans ce qui suit, on va tudier le multiplexage de services dans le mme canal. Lessentiel est
de comparer la capacit totale du systme en cas de multiplexage des diffrents services sur le
mme canal et en cas de sparation temporelle de services.
La comparaison est base sur des simulations. Le simulateur NS est utilis pour simuler un
systme LEOS comme dcrit dans le deuxime chapitre. Une technologie multi-faisceaux est
utilise. Dans chaque faisceau on a 24 frquences porteuses. Chaque frquence a une bande
passante montante gale la bande passante descendante gale 155Kb/s. Le G/W a une
bande de 155Mb/s ainsi que la liaison inter-satellite.
Une source voix se comporte comme une source ON-OFF avec les paramtres t
on
= 1s et t
off
=
1.35s
Une source web se comporte comme dcrit dans le paragraphe 5.3.2 avec les paramtres :
Le dbit utilis est de 8Kb/s.
Le nombre dappels dans une session est gomtrique de moyenne N
p
= 5.
Le temps de lecture est gomtrique de moyenne T
R
= 412s.
Le nombre de rafales dans un appel est gomtrique de moyenne N
b
= 25.
Le temps sparant deux rafales conscutives est gomtrique de moyenne T
sep
.= 0.5s.
- 126 - 126
Enfin les paramtres de distribution de Pareto sont = 1.1, k = 81.5 et la moyenne dune
rafale est L
w
= 24paquets.
Une source data se comporte comme dcrit dans 3.2.2 avec les paramtres = 0.25 et L
s
=
100 paquets.
6.3.3.1 Services RTC (voix) et ITC (web)
On va comparer le comportement du systme en deux cas qui sont la sparation et le
multiplexage des deux services. Les deux cas sont reprsents par deux stratgies dallocation
de ressources :
Division ; on divise les ressources entre les utilisateurs voix et les sources web en
donnant 4 slots temporels pour les utilisateurs voix et les 4 restants dans une trame
pour les sources web. La fonction de permission dun tel service prend une valeur de
zro sur les slots qui ne lui sont pas allous.
Multiplexage ; on assigne tous les slots aux deux types des utilisateurs. Les utilisateurs
accdent nimporte quel slot en appliquant le protocole S-CDMA/PRMA expliqu
dans le chapitre prcdent.
Pour les utilisateurs voix, on peut faire des calculs mathmatiques et des simulations tandis
que seule une simulation est faisable en cas des sources web et en cas de multiplexage.
Dans la figure 6.14, on trace la probabilit de perte des paquets voix ainsi que le dlai subi par
un paquet web. Le graphe montre que la capacit de systme est de 18 utilisateurs voix et 200
sources web avec un dlai maximal de 200ms. La figure 6.15 montre la probabilit de perte
des utilisateurs voix et le dlai dattente des paquets web pour diffrents nombres de sources
vocales et webs. Le terme VUT (Voice User Terminal) reprsente un utilisateur voix. On
remarque que pour 15 utilisateurs voix, on peut accepter 180 sources webs avec un dlai de
80ms. Le dlai est donc diminu et la QoS offerte au trafic web est amliore mais la capacit
totale du canal est dgrade. Ceci est d au fait que le comportement de deux trafics voix et
web sont trs diffrents ainsi que leurs QoSs. Le long dlai pris par une session web pour tre
transmise (de lordre de 20s dans le cas de 8Kb de dbit) par rapport au talkspurt dune source
voix (1s) dgrade la qualit offerte aux utilisateurs voix mme dans le cas o on leur donne
une priorit plus leve. En effet, la priorit donne dans le protocole S-CDMA/PRMA est
souple et le systme est non premptif. Quand une source web rserve une ressource, elle ne
peut pas tre arrte par un utilisateur voix qui veut envoyer son talkspurt. Les paquets
vocaux sont perdus dans ce cas cause dune longue attente de la fin dun appel web et la
probabilit de perte des paquets voix augmente considrablement. La sparation de web et de
voix est prfrable.
La conclusion essentielle de cette comparaison est que le facteur principal qui dcide la
sparation des deux types de trafic est la grande diffrence entre le comportement des deux
sources de trafic. La diffrence des QoS demandes par les deux sources nest pas cruciale
comme on a dmontr dans le chapitre prcdent. Les limites de contrle et de rservation
pour les deux services sont proches et la diffrence entre les deux techniques daccs
appliques sur le sous-systme voix et sur le sous-systme data peut rsoudre le problme de
la QoS. Un systme premptif peut rsoudre le problme en permettant lutilisateur voix
dinterrompre la source web pour envoyer ses paquets. Un tel systme perd une partie des
paquets webs envoys et risque de gaspiller les ressources.



- 127 - 127


0 5 10 15 20 25
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
Utilisateurs voix
x Simulation
o Analytique
Nombre dusagers



p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e



0 50 100 150 200 250 300 350
0
200
400
600
800
1000
1200
1400
1600
1800
2000
Sources Web
Nombre de sources web



D

l
a
i

(
m
s
)


Figure 6.14 Cas de sparation des utilisateurs voix et web


- 128 - 128


0 50 100 150 200 250 300 350
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
5 VUTs
10 VUTs
15 VUTs
20 VUTs
25 VUTs
30 VUTs
Multiplexage des web et voix
Nombre de sources web


P
e
r
t
e

d
e
s

p
a
q
u
e
t
s

v
o
i
x



0 50 100 150 200 250 300 350
0
200
400
600
800
1000
1200
5 VUTs
10 VUTs
15 VUTs
20 VUTs
25 VUTs
30 VUTs
Multiplexage des web et voix
Nombre de sources web
D

l
a
i

d
e
s

p
a
q
u
e
t
s

w
e
b

(
m
s
)


Figure 6.15 Cas de multiplexage des voix et web


- 129 - 129
6.3.3.2 Services RTC (voix) et STC (data)
Les services voix et data ont des qualits de service trs diffrentes mais possdent des
sources de trafic comparables o la longueur moyenne de fichier est de lordre de talkspurt
(un fichier est considr comme un court message). Le multiplexage des deux services
considre des fonctions de permission choisies dans le paragraphe 5.8.3 afin de minimiser
linfluence des sources data sur les utilisateurs voix. Les deux stratgies comparer sont
toujours celles introduite dans la section prcdente ; la sparation et le multiplexage de
services.

0 5 10 15 20 25 30 35 40
0
0.002
0.004
0.006
0.008
0.01
0.012
Utilisateurs data
o analyse avec taux darrive 0.25
. simulation avec taux darrive 0.25
Nombre de sources
l

p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e



0 5 10 15 20 25 30 35 40
0
200
400
600
800
1000
1200
1400
1600
Utilisateurs data
o analyse avec taux darrive 0.25
. Simulation avec taux darrive 0.25
Nombre de sources data




D

l
a
i


Figure 6.16 quatre slots pour les utilisateurs data
Dans la figure 6.16 on remarque que la limite des utilisateurs data accepts sur les 4 slots
dune trame atteint 32 utilisateurs avec une probabilit de perte infrieure 0.1%. Le dlai
- 130 - 130
dattente dans ce cas est de 600ms qui est un dlai acceptable par un paquet data de qualit
suppose best effort. Les quatre autres slots sont affects aux utilisateurs voix et peuvent
accueillir jusqu 18 utilisateurs voix avec une QoS accepte (figure 6.14).
On passe maintenant la deuxime stratgie qui mlange les deux types de sources voix et
data dans les mme slots. On remarque dans la figure 6.17 quavec 20 utilisateurs voix on
peut accepter 32 utilisateurs data avec un dlai dattente de 150ms. Le nombre dutilisateurs
voix est augment avec une meilleure qualit pour les utilisateurs data.

0 5 10 15 20 25 30 35 40 45
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
0.1
15 VUTs
20 VUTs
25 VUTs
o resultas avec taux d"arrive 0.25
Multiplexage voix et data
nombre de sources data
p
e
r
t
e

d
e
s

p
a
q
u
e
t
s

d
a
t
a



0 5 10 15 20 25 30 35 40 45
0
100
200
300
400
500
600
700
15 VUTs
20 VUTs
25 VUTs
o resultats avec taux d"arrivee 0.25
Multiplexage voix et data
nombre de sources data
d

l
a
i

d
e
s

p
a
q
u
e
t
s

d
a
t
a

(
m
s
)


Figure 6.17 Multiplexage des sources voix et data
- 131 - 131
Daprs cette tude on conclut que le fait de mlanger les utilisateurs data avec les utilisateurs
voix est prfrable mme si les deux types de service ont deux QoSs trs diffrentes. Le fait
de multiplexer les usagers a le rsultat de diminuer le dlai dattente des paquets data.
6.3.3.3 Services ITC (web) et STC (data)

0 50 100 150 200 250 300 350
0
100
200
300
400
500
600
700
800
900
1000
10 DSs
30 DSs
50 DSs
Multiplexage data et web
nombre de sources web
d

l
a
i

d
e
s

p
a
q
u
e
t
s

w
e
b

(
m
s
)



0 50 100 150 200 250 300 350
0
200
400
600
800
1000
1200
1400
1600
1800
2000
10 DSs
30 DSs
50 DSs
Multiplexage data et web
nombre de sources web
d

l
a
i

d
e
s

p
a
q
u
e
t
s

w
e
b

(
m
s
)


Figure 6.18 Multiplexage de data et de web
Les sources web et data utilises dans cette thse ont des comportements de trafic trs
diffrents mais des qualits de service comparables. Le fait que les deux types de source
appartiennent au sous-systme data (chapitre 5) permet lutilisation du mme protocole
- 132 - 132
daccs pour les deux types de ressource avec deux diffrentes fonctions de permission afin
de donner une priorit au trafic web qui ne supporte pas un trs long dlai comme le trafic
data (best effort). La figure 6.18 montre quon peut accepter jusqu 250 utilisateurs web avec
un dlai dattente infrieur 200ms quand 30 DSs (Data Sources) sont prsentes dans le
systme. La capacit totale du systme est amliore. Dautre part le dlai dattente des
paquets data est de 300ms dans ce cas et de 500ms dans le cas de sparation des deux types de
trafic. Le multiplexage des sources web et data est donc prfrable.
6.3.3.4 Services RTC (voix) ITC (web) et STC (data)
Daprs les discussions prcdentes, on peut proposer une stratgie dallocation de ressources
pour les diffrents types de trafic utilis dans ce chapitre. On sait que le multiplexage de
sources web avec les utilisateurs voix est inacceptable tandis que le multiplexage de sources
data et dutilisateurs voix ainsi que les sources data et les sources web amliore lefficacit du
systme. Pour cette raison, on utilise la stratgie suivante dallocation et on la compare au
multiplexage des trois services prsent dans 5.8.4.










p
v
p
w





p
d

S o u r c e s v o i x

S o u r c e s w e b
S o u r c e s d a t a

Figure 6.19 Allocation de ressources en S-CDMA/PRMA
Dans la stratgie dallocation utilise dans la figure 6.19, les slots sont spars par une
frontire fixe pour sparer les sources web et les utilisateurs voix. Les utilisateurs voix ont le
droit daccder aux quatre slots en utilisant la probabilit de permission p
v
(x) alors que les
sources web ont le droit daccder sur les quatre slots restants avec une permission p
w
(x).
Enfin, les sources data peuvent envoyer sur tous les slots mais en utilisant une fonction
restrictive de permission introduite dans 5.8.4 p
d
(x) = f2(x).
La comparaison entre cette technique et celle prsente dans le paragraphe 5.8.4, o tous les
services sont mlangs sur les mme slots, est trace dans les figures 6.20 et 6.21. On
remarque que le nombre maximal dutilisateurs data quon peut accepter dans le cas sans
frontire est de 16 sources tandis que ce numro passe 18 sources dans le cas o une
frontire sparerait les deux services web et voix. La capacit du systme est amliore et le
dlai dattente dun paquet data est diminu. En effet, ce dlai passe de 700ms en cas de la
stratgie sans frontire 400ms en cas de la stratgie avec frontire. On remarque aussi que
linfluence des sources web sur les utilisateurs voix nexiste pas dans cette dernire stratgie
dallocation.

- 133 - 133


0 5 10 15 20
10
-5
10
-4
10
-3
10
-2
10
-1
10 sources voix et 100 sources web et x sources data (sans frontire)
* voix
. web
+ data
nombre dutilisateurs data
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e



2 4 6 8 10 12 14 16 18 20
10
1
10
2
10
3
10
4 10 sources voix et 100 sources web et x sources data (sans frontire)
o web
* data
nombre dutilisateurs data
d

l
a
i

(
m
s
)


Figure 6.20 Stratgie d'allocation sans frontire
- 134 - 134

0 5 10 15 20
10
-5
10
-4
10
-3
10
-2
10
-1
10 sources voix et 100 sources web et x sources data (frontire)
* voix
. web
+ data
nombre dutilisateurs data
p
r
o
b
a
b
i
l
i
t


d
e

p
e
r
t
e



2 4 6 8 10 12 14 16 18 20
10
1
10
2
10
3
10 sources voix et 100 sources web et x sources data (frontire)
o web
* data
nombre dutilisateurs data
d

l
a
i

(
m
s
)


Figure 6.21 Stratgie d'allocation avec frontire
- 135 - 135
On note que la stratgie avec frontire rend le systme plus rigide. Il faut avoir une prvision
du nombre dutilisateurs voix qui demandent une connexion. Pour rsoudre ce problme on
peut utiliser une stratgie avec frontire mobile.
6.4 Conclusion
Dans ce chapitre, on a compar les diffrents protocoles daccs tudis dans cette thse. On a
dduit que malgr lamlioration faite au protocole PRMA pour ladapter au contexte des
satellites LEO, soit par notre proposition ou par la proposition de Hindering States, le
protocole S-PRMA possde une performance infrieure au protocole S-CDMA ou S-
CDMA/PRMA. Ces deux derniers possdent une bonne performance surtout quand on a un
seul type des sources. Dans le cas des plusieurs types des sources de trafic, des stratgies
dallocation de ressources sont ncessaires. Un multiplexage simple de services dgrade
lefficacit des protocoles. Une nouvelle stratgie frontire dynamique est propose en S-
CDMA et une comparaison avec une stratgie statique montre que notre proposition amliore
la performance de systme considrablement.
En S-CDMA/PRMA, on a dmontr que le multiplexage de deux services amliore
lefficacit en augmentant la capacit en excluant le cas o on mlangerait les sources web
avec les utilisateurs voix. Dans ce cas, la capacit du systme est diminue. Ceci est d
principalement au fait que les deux types de source sont trs diffrents ainsi que leurs QoS.
Pour cette raison, on a spar les utilisateurs voix des sources web tandis que les sources data
peuvent accder aux deux parties de ressources. Cette stratgie montre une amlioration de la
QoS des diffrents services par rapport au cas o tous les sources seraient mlanges dans les
mme slots. Cette technique est inflexible mais une stratgie avec frontire dynamique
pourrait rsoudre ce problme.
- 136 - 136










Dans ce chapitre, on va dcrire les conclusions essentielles de notre thse ainsi que des
ouvertures des recherches futures dcoulant de nos tudes. Ce chapitre prsente aussi notre
point de vue sur le dveloppent des rseaux mobiles personnels et le rle du satellite LEO
dans ce dveloppement.
Dans cette thse, on a tudi la couche daccs MAC et la fonction de contrle dadmission
CAC dans le contexte satellitaire. Le but principal tait de dvelopper une couche MAC base
sur lintgration des plusieurs services qui sont multiplexs laide dun protocole daccs
spcifique. Ce protocole daccs doit raliser une qualit de service demande par les
diffrents services tout en maximisant lutilisation de ressources radios. La fonction CAC est
dfinie sous ce point de vue pour chacun de services.
Lintgration de satellite avec lUMTS et lutilisation de lATM au sein du rseau de cur
sont deux facteurs essentiels qui dirigent nos propositions sur la couche MAC. Les services
vus par cette couche sont appels les MTCs (MAC Transfer Capabilities) et doivent se
coordonner avec les services de lUMTS et lATM. Le choix est bas aussi sur les sources de
trafics utilises dans les diffrents chapitres. La dfinition complte des MTCs est accomplie
dans le chapitre 5 o trois MTCs sont proposs pour supporter trois types de services ; le
temps rel, linteractif et le best effort.
Nous avons propos un protocole S-PRMA, qui est une version satellite de PRMA, et qui
dmontre une efficacit moyenne quand ses paramtres sont optimiss. Ltude est base sur
un modle mathmatique et une simulation. On dmontre que le fait davoir un long RTD
impose l'accroissement de la probabilit de permission pour les utilisateurs voix. Une
permission restrictive est donne aux utilisateurs data qui ont une priorit infrieure. Ceci
diminue linfluence des utilisateurs data sur les utilisateurs voix. Malgr les changements
faits, lefficacit reste limite ce qui ncessite lintroduction dune composante CDMA dans
la couche MAC.
On propose ensuite un protocole daccs S-CDMA utilisant le CDMA et la notion de
permission daccs au canal. On dmontre que quand des utilisateurs voix utilisent seuls le
canal, le CDMA classique donne une performance maximale. Quand on mlange plusieurs
sources de trafic, un protocole qui utilise deux fonctions de permission pour les utilisateurs
voix et data donne des rsultats intressant quand ces deux fonctions sont choisies de faon
donner aux services temps rel une priorit leve. Une fonction restrictive pour les data et
gnreuse pour les voix donne une performance importante. Le problme reste toujours
linfluence dun type de service sur lautre via linterfrence et la difficult de sparer les
diffrents services. Ce problme se pose quand des services non temps rel mais qui ont des
- 137 - 137
contraintes temporelles sont introduits. Lutilisation des services interactifs comme le web
parat difficile. Pour cette raison on a introduit une composante temporelle dans le canal, do
le S-CDMA/PRMA.
Nous avons dvelopp une version satellite du protocole CDMA/PRMA. Dans ce protocole,
les notions de contention et de rservation sont modifies afin dadapter le protocole au canal
satellite. La fonction de permission est utilise pour contrler le trafic afin de maximiser
lutilisation de ressources. Trois MTCs sont utiliss ce stade avec trois niveaux de priorit.
Le choix des paramtres du canal et des fonctions de permission est effectu par modlisation
mathmatique et simulation. On remarque ce stade que le multiplexage de diffrents
services peut causer des problmes, ce qui ncessite des stratgies de multiplexage de services
avances.
Dans le dernier chapitre, on compare les diffrents protocoles daccs et on dduit que S-
CDMA et S-CDMA/PRMA ont une performance suprieure au S-PRMA. Des techniques
dallocation dynamique de ressources en S-CDMA amliorent lefficacit du systme
considrablement. Quant au protocole S-CDMA/PRMA, on remarque que le multiplexage de
deux services ensemble nest pas toujours souhaitable surtout quand ils sont trs diffrents par
la qualit de service et le comportement de trafic. Il est prfrable de sparer les services web
et voix dune faon temporelle alors que les utilisateurs data peuvent utiliser le canal de voix
ou de web avec une basse priorit. Ceci ncessite une allocation de ressources qui divise le
canal en deux sous canaux ; voix et web. Les sources data peuvent accder tout le canal en
utilisant une permission trs basse. La sparation peut tre statique ou dynamique. Une
sparation dynamique ncessite un seuil mobile et rend le systme plus flexible.
Une remarque importante est que la communication mobile sans fil doit toujours respecter un
des principes fondamentaux de Shanon qui parat en contradiction avec les tendances en
conception des rseaux daccs. Ce principe est le fait que le meilleur signal et la pire
interfrence sont vue par un observateur extrieur comme un bruit Gaussien uniforme. La pire
perturbation est vue comme un bruit uniforme. Puisque linterfrence ne peut pas tre
limine, la solution est de profiter de cette interfrence en utilisant le signal comme bruit.
Pour un utilisateur, linterfrence est vue comme bruit liminer. Le CDMA est lapplication
directe de cette philosophie.
En satellite, linterfrence est encore plus importante, ce qui augmente lefficacit du CDMA
dans ce contexte. Dans cette thse, on a dmontr que lutilisation du CDMA augmente la
capacit du systme et amliore la qualit de service des diffrents utilisateurs et aussi permet
des mthodes de multiplexage qui augmente le gain statistique.
Dautre part, le fait que la plupart des systmes mobiles terrestres utilisent des autres
techniques comme le TDMA ou le FDMA impose le choix du protocole daccs multiple
puisque lintgration du satellite dans le rseau terrestre est une ncessit.
Pour cette raison, on a amlior une technique hybride daccs qui est le S-CDMA/PRMA
pour tre utilise dans la constellation de satellites. Cette technique dmontre une efficacit
considrable qui peut dans certains cas dpasser celle du S-CDMA.
Ouvertures :
Le problme de multiplexage de services est dallocation de ressources peut tre labor et
dvelopp pour mieux grer les ressources radio qui sont trs chres dans les systmes
satellites. Dautre part, la remarque qui considre que les protocoles S-CDMA et S-PRMA
sont des cas particuliers du S-CDMA/PRMA peut tre dveloppe pour dfinir une technique
- 138 - 138
qui passe dun protocole daccs un autre suivant les conditions du systme. Ltude de
performance et loptimisation de cette technique reprsente un sujet de recherche important.
Lutilisation de nos protocoles sur les systmes MEO nest pas discute dans cette thse ainsi
que la possibilit dutiliser le PRMA dans ce contexte.
- 139 - 139

8 Rfrences :

[1] Raymond L. Pickholtz. Communications by Means of Low Earth Orbiting Satellites.
The George Washington University. Report 1995.
[2] Grard Maral, Jean Jacques DERIDER. Basic Concepts of Low Earth Satellite
Systems for Communications. ENST Toulouse. Report 1991.
[3] Projet : Constellation des satellites pour le multimdia.
http://constellation.prism.uvsq.fr.
[4] G. Maral, M. Bousquet. Satellite Communications Systems. Third Edition. WILEY.
1998.
[5] Eitan Altman, Afonso Feriera, Jrom Galtier. Les rseaux satellites de
tlcommunication. Edition DUNOD. Paris 1999.
[6] Abbas Jamalipour. Low Earth Orbital Satellites for Personal Communications
Networks. Artech House publishers. Boston, London 1998.
[7] V. Andrew J. CDMA Principles of Spread Spectrum Communication. Addison-
Welsey 1995.
[8] Harry G. Perros, Khaled M. Elsayed. Call Admission Control Schemes: A Review.
Department of Computer Science, North Carolina State University. Report 1996.
[9] IRIDIUM Project. www.iridium.com.
[10] Xavier Lagrange, Philippe Godlewski, Sami Tabbane. Rseaux GSM-DCS. HERMES.
1996.
[11] Adami, D. Marchese, M. Ronga, L. S. TCP/IP-based multimedia applications and
services over satellite links: experience from an ASI/CNIT project. IEEE Personal
Communications. Volume 8 Issue: 3, June 2001.
[12] Clark P. Hammond, C. Jaenho Oh; Wen Wang; Hadynski G. QoS-based provisioning
of ATM services over DAMA-controlled SATCOM networks. Military
Communications Conference Proceedings, 1999. MILCOM 1999. Volume: 2, 1999.
[13] 3GPP TSG RAN. Quality of Service (QoS) concept and architecture. 3G TS 23.107
V3.0.0 (1999-10).
[14] Jhon Fareserotu and Ramjee Prasad. Broad band wide Area Networking via IP/ATM
over SATCOM. IEEE Journal on Selected Areas in Communications. Volume 17, No
2, February 1999.
[15] Dennis P. Connors, Bo Ryu and Son Dao. Modeling and Simulation of Broadband
Satellite Networks. Part I: Medium Access Control for QoS Provisionning. IEEE
Communications Magazine. Volume 27. March 1999.
[16] Heba Koraitim, Samir Tohm. Resource Allocation And Connection Admission
Control in Satellite Networks. IEEE Journal On Selected Areas In Communications.
February 1999.
[17] Enrico Del Re. A Coordinated European Effort for the Definition of a Satellite
Integrated Environment for Future Mobile Communications. IEEE Communications
Magazine. Volume 34. February 1996.
[18] INSURED Project. http://www.nh.gr/INSURED/.
[19] SINUS Project. http://manuel.brad.ac.uk/Research/SINUS/index1.html.
[20] Alexander Guntsch, Mohamed Ibnkahla, Giacinto Losquadro, Michel Mazella, Daniel
Rovira and Andreas Timm. EUs R&D Activities on Third Generation Mobile
- 140 - 140
Satellite Systems (S-UMTS). IEEE Communications Magazine. Volume: 36, February
1998
[21] Heba Koraitim. Protocoles Daccs multiple et allocation de ressources sur un canal
satellite. Thse lENST. September 1998.
[22] Fulvio Ananasso and Francesco Delli Priscoli. The Role of Satellite in Personal
Communication Services. IEEE Journal On Selected Areas In Communications.
Volume 13 February 1995.
[23] Radio Equipment and Systems (RES); Trans-European Trucked Radio (TETRA);
Voice + Data; Part I. ETSI ETS 300 392. Edition 1. 1996.
[24] Sanjiv Nanda, David J. Goodman, Uzi Timor. Performance of PRMA: A Packet Voice
Protocol for Cellular Systems. IEEE Transactions On Vehicular Technology, Volume
40. August 1991.
[25] S. Tasaka. Stability and Performance of the R-ALOHA packet Broadcast System.
IEEE transaction on Computer. August 1983.
[26] Enrico Del Re, Romano Fantacci and Giovani Giambene. Performance Evaluation of
the PRMA protocol for Voice and Data Transmission in Low Earth Orbit Mobile
Satellite Systems. PIMRC 1998.
[27] Enrico Del Re, Romano Fantacci and Giovani Giambene. Performance Analysis of an
Improved PRMA Protocol for Low Earth Orbit-Mobile Satellite Systems. IEEE
Transactions On Vehicular Technology. Volume 48. May 1999.
[28] Stochastic Process in Queuing Theory. A. A. Borovkov. Spriger-Verlag. 1976.
[29] S. Tohm and L. Decresefond. Evaluation de performance. ENST, Janvier 1998.
[30] David J. Goodman and Sherry X. Wei. Efficiency of Packet Reservation Multiple
Access. IEEE Transactions On Vehicular Technology. Volume 40. February 1991.
[31] Grard Maral, Joaquin Restrepo, Enrico Del Re, Romano Fantaci and Giovanni
Giambene. Performance Analysis For a Garanteed Handover Service in an LEO
Constellation with a satellite-Fixed Cell System. IEEE Transactions On Vehicular
Technology. Volume 47. November 1998.
[32] Grard Maral et Restrepo Joaquin. Transfert dune communication dans une
constellation de satellite non GEO. Demande de brevet franais N 97-02392.
[33] N. D. Wilson, R. Ganesh, K. Joseph and D. Raychaudhuri. Packet CDMA versus
Dynamic TDMA for Multiple Access on an Integrated Voice/Data PCN. IEEE J. on
Selected Areas in Communications. Volume 11. August 1993.
[34] N. D. Wilson, R. Ganesh, K. Joseph and D. Raychaudhuri. Performance of cellular
Packet CDMA in an Integrated Voice/Data Network. Int. Journal Wireless Information
Networks. Volume 1. 1994.
[35] M. B. Pursley. Performance Evaluation of Phase-coded Spread Spectrum Multiple
Access Network-Part I: System Analysis. IEEE Trans. Commun. Volume 10. August
1977.
[36] Selection procedure for the choice of radio transmission technologies of the UMTS.
UMTS technical report ETSI TR 101 112 V3.2.0 (1998).
[37] A. Erik and J. Zender. A Traffic Model for Non-real-time Data Users in a Wireless
Radio Network. IEEE Communication Letters. Volume 1. March 1997.
[38] Mohsen S. and Evaggelos G. Multi-Access Strategies for an Integrated Voice/Data
CDMA Packet Radio Network. IEEE Transaction On Communications. Volume 43.
February/Mars/April 1995.
- 141 - 141
[39] E. Miltiades A. Multiuser Descriptive Traffic Model. IEEE Transaction On
Communications. Volume 44. October 1996.
[40] M. Hu J. Chang. Collision Resolution Algorithms for CDMA Systems. IEEE J. on
Selected Areas in Communications. Volume 8. May 1990.
[41] Payam Taaghol, Enrico Burachini, Riccardo De Gaudenzi, Gennaro Gallinaro, Joon
Ho Lee, Chung Gu Kang. Satellite UMTS/IMT2000 W-CDMA Air Interfaces. IEEE
Communications Magazine. Volume 10. September 1999.
[42] Heba Koraitim, Gunter Schafer, Samir Tohme. Quality of Service Aspects of
Transport Technologies for UMTS Radio Access Network. PWC2000 Gdansk,
Poland.
[43] T. Liu and J. A. Silvister. Joint Admission Congestion Control for Wireless CDMA
Systems Supporting Integrated Services. IEEE J. on Selected Areas on
Telecommunications. Volume 16. August 1998.
[44] K. Gilhoussen, A. J. Viterbi. On the Capacity of Cellular System. IEEE Transaction
On Vehicular Technology. Volume 40. May 1991.
[45] I. F. Akyildiz and D. A. Levine. A Slotted CDMA Protocol with BER Scheduling for
Wireless Multimedia Networks. IEEE/ACM Transactions On Networking. Volume 7
April 1999.
[46] Alfred Baier, U. Fiebig, G. W. Koch, P. Teder and J. Thieleke. Design Study for A
CDMA-Based Third Generation Mobile Radio System. IEEE J. on Selected Areas on
Telecommunications. Volume 12. May 1994.
[47] ETSI Standards available at http://www.etsi.org/getastandard/home.htm.
[48] ITU publications available at http://www.itu.int/publications.
[49] Martin Haadart, Anja Klein, Reinhard Loehn, Stefan Oeisterch, Markus Purat, Volker
Sommer and Thomas Ulrich. The TD-CDMA Based UTRA TDD Mode. IEEE J. on
Selected Areas on Telecommunications. Volume 18. August 2000.
[50] Alex E. Brand and A. Hamid Aghvami. Performance of a Joint CDMA/PRMA
Protocol for Mixed Voice/Data Transmission for Third Generation Mobile
Communication. IEEE Journal on Selected Areas in Communications. Volume 14.
December 1996.
[51] Shibutani A.; Suda H.; Adachi F. Multistage recursive interleaver for turbo codes in
DS-CDMA mobile radio Vehicular Technology. IEEE Transactions on
communications. Volume: 51. Issue 1. Jan. 2002.
[52] Otal B.; Alonso L.; Agusti. Design and analysis of cellular mobile communications
system based on DQRAP/CDMA MAC protocol. R. Electronics Letters. Volume: 38
Issue 3. 31 January 2002.
[53] Vollmer M.; Haardt M.; Gotze. Comparative study of joint-detection techniques for
TD-CDMA based mobile radio systems. J. Selected Areas in Communications.
Volume: 19. Issue 8. August 2001.
[54] Gessner C.; Kohn R.; Schniedenharn J. Sitte. Layer 2 and layer 3 of UTRA-TDD.
Vehicular Technology Conference Proceedings VTC 2000-Spring Tokyo. Volume: 2.
2000.
[55] V. Jackobson. Compressing TCP/IP Headers for Low-Speed Serial Links. Available at
http://www.faqs.org/rfcs/rfc1144.html.
[56] Lulea University of Technology/SICS February 1999. IP Header Compression.
Available at. http://www.faqs.org/rfcs/rfc2507.html.
- 142 - 142
[57] Efthymiou N. Yim Fun Hu. Sheriff R.E. Performance of intersegment handover
protocols in an integrated space/terrestrial-UMTS environment. IEEE Transactions on
Vehicular Technology. Volume: 47. Issue: 4. November 1998.
[58] Koodli R. Puuskari M. Supporting packet-data QoS in next generation cellular
networks. IEEE Communications Magazine . Volume: 39 Issue: 2. Feb. 2001.
[59] Abbas Jamalipour, Masaaki Katayama, Takaya yamazato and Akira Ogawa.
Performance of an Integrated Voice/Data System in Nonuniform Traffic Low Earth-
Orbit Satellite Communication Systems. IEEE Journal on Selected Areas in
Communications. Volume 13. February. 1995.
[60] Alex E. Brand and Hamid Aghvami. Multidimensional PRMA with Prioritized
Bayesian Broadcast A MAC strategy for Multiservice traffic over UMTS. IEEE
Transaction On Vehicular Technologies. November 1998.
[61] Lin Wang, Jianjun Wu, Aghvami A. H. Performance of CDMA/PRMA with adaptive
permission probability control in packet radio networks. IEEE Vehicular Technology
Conference. Volume: 3. 1999.
[62] Hoefel R.P.F. de Almeida C. Performance of CDMA/PRMA TDD protocol with
decorrelating multiuser detector and adaptive permission access scheme. IEEE
Electronics Letters. Volume 37. Issue: 15. July 2001.
[63] A.E. Aghvami, A.H Brand. Joint CDMA/PRMA: a candidate for a third generation
radio access protocol Mobile Communications. Towards the Next Millenium and
Beyond. IEE Colloquium. 1996.
[64] Calin D. and Areny M. Impact of radio resource allocation policies on the TD-CDMA
system performance: evaluation of major critical parameters. IEEE Journal on Selected
Areas in Communications. Volume 19. Issue: 10. October 2001.
[65] Jorguseski L. Fledderus E. Farserotu J. Prasal R. Radio resource allocation in third
generation mobile communication systems. IEEE Communications Magazine. Volume
39. Issue 2. February 2001.
[66] Young Dae Lee, Sung Lark Kwon, Jin Sung Choi, Jin Young Park, Seung June Yi.
Performance evaluation of start of message indicator mechanism for uplink common
packet channel in UMTS W-CDMA. IEEE Vehicular Technology Conference. VTC
2001 Spring.
[67] J. Wieselthier and A. Ephermides. Fixed and Movable Boundary Scheme for
Integrated Voice/Data Wireless Networks. IEEE Transactions On Communications.
Volume 43. January 1995.
[68] Kikalapudi Sriram, Pramod K. Varshney, and J. George Shanthikumar. Discrete-Time
Analysis of Integrated Voice/Data Multiplexers with and without speech activity
detectors. IEEE Journal on Selected Areas in Communications. Volume SAC-1.
December 1983.
[69] S. Bohm, A. K. Alhakeem, K. M. S. Murthy, M. Hachicha and M. Kadoch. Analysis
of a Movable Boundary Access Technique for a Multiservice Multibeams Satellite
System. Int. Journal of Satellite Communication. Volume 12. 1994.
[70] El-Kadi, M. Olariu, S. Todorova. Predictive resource allocation in multimedia satellite
networks. IEEE Global Telecommunications Conference. GLOBECOM '01. Volume
4. 2001.
[71] Boukhatem L., Beylot A.L., Gaiti D., Pujolle G. Performance analysis of dynamic and
fixed channel allocation techniques in a LEO constellation with an "Earth-fixed cell"
- 143 - 143
system. IEEE Global Telecommunications Conference. GLOBECOM 00. Volume 2.
2000.
[72] Teledesic Corporation. Application of Teledesic corporation for a Low Earth Orbit
(LEO) satellite system in the Fixed Satellite Service (FSS). 1996.
[73] Klein S. Gilhossen, IRWIN M. Jacob, Roberto Padovani and Lindsay A. Weaver.
Increased Capacity Using CDMA for Mobile Satellite Communication. IEEE Journal
on Selected Areas in Communications. Volume 8. May 1990.
[74] Klein S. Gilhossen, IRWIN M. Jacob, Roberto Padovani, Lindsay A. Weaver and
Andrew J. Viterbi. On the Capacity of Cellular CDMA System. IEEE Transaction on
vehicular technology. Volume 40. May 1991.
[75] Y. Fun Hu, Grard Maral, Erina Ferro. Service Efficient Network Interconnection via
Satellite. EU Cost Action 253. WILEY 2002.
[76] NS2. Network Simulator version 2. http://www.isi.edu/nsnam/ns/.
[77] NS manual : ns Notes and Documentation. http://www.isi.edu/nsnam/ns/ns-
documentation.html.
[78] Averill M. Law and W. David Kelton. Simulation Modeling and Analysis. Mc-Graw-
Hill Book Company. 1982.
- 144 - 144

[1] Ibrahim and Tohm, A Modified CDMA/PRMA Medium Access Control Protocol
for Integrated Services in LEO Satellite Systems Mobicom2000 August 6-11, 2000
Boston, Massachusetts USA.
[2] Ibrahim and Tohm, A Modified CDMA/PRMA Medium Access Control Protocol
for Voice Users in LEO Systems, PWC2000 Gdansk Poland.
[3] Ibrahim and Tohm. CDMA and PRMA Analytical models for Voice users in
Satellite-UMTS Systems. PWC2001 Lappenranta Finland.
[4] Ibrahim and Tohm. CDMA, PRMA and CDMA/PRMA for Voice users in Satellite
UMTS Systems. WATM2001. Paris. France.
[5] Ibrahim and Tohm. CDMA/PRMA Analytical models for Voice users in Satellite-
UMTS Systems. ICC2002 New York. USA.
[6] Ibrahim and Tohm. Service Multiplexing and Resource Allocation in S-
CDMA/PRMA LEO Systems. ISCC2002. Toaramina. Italia.
[7] Ibrahim and Tohm. Service Multiplexing and Resource Allocation in S-CDMA LEO
Systems. PIMRC2002. Lisboa. Portugal.
- 145 - 145









Dans cet appendice, on va prsenter brivement le modle de simulation de la couche MAC
dans le contexte de satellite ainsi que le calcul des intervalles de confiance utilises dans la
simulation.
Modle de simulation
La simulation est faite en utilisant ns2 (Network Simulator 2) ce qui ncessite des
programmations sur deux nivaux : C++ et Tcl.
Le schma gnral dun lien satellite est reprsent par la figure A.1 suivante :























Channel
LL
IFq
MAC
Phy_tx Phy_rx
Radio
propagation
model


Les diffrentes parties de ce modle reprsentent les couches implmentes dans la pile
protocolaire des liens satellites. Ces couches servent transmettre et recevoir les paquets en
- 146 - 146
utilisant des entits physiques pour accomplir ces tches. Les diffrents entits implments
sont :
LL : cest la couche liaison implmente en C++. On dfinit la classe (LL/Sat) pour les
satellites.
IFq : cest la file dattente implmente, par exemple la classe (Queue/DropTail). On a
programm une classe pour dfinir une file dattente FIFO infinie implmente dans les
terminaux data.
MAC : cest la couche MAC qui fait la liaison entre la couche physique et les couches
suprieures. La classe implmente est (MAC/Sat). Cest une couche MAC basique qui ne fait
que linsertion dun entte MAC et lenvoie vers la couche physique qui utilise le canal
satellite pour transmettre le paquet. A ce niveau, on a implment les diffrents protocoles
daccs que nous avons proposs. On a dfini les diffrents classes (MAC/Sat/PRMA) et
(MAC/Sat/CDMA) et (MAC/Sat/CDMAPRMA). La dfinition de ces protocoles ncessite le
changement de plusieurs paramtres et fonctions en NS, ce qui donne un nouveau simulateur
propre notre tude.
Phy : deux classes sont dfinies pour cette couche dans les satellites (Phy/Sat) et
(Phy/Repeater). La classe (Phy/Sat) contient deux entits et un modle de propagation. Cette
classe transmet les paquets sur le canal satellite et reoit les paquets pour les passer aux
couches suprieures. La classe (Phy/Repeater) constitue un miroir pour retransmettre
directement les paquets reus. La classe (Phy/Sat) est utilise dans notre modle.
Notons enfin, quon a implment les diffrentes sources de trafic (voix, transfert de fichiers,
Email, Web) utilises dans cette thse afin dtre utilises dans la dfinition du rseau de
simulation.
Aprs la dfinition des diffrents protocoles et paramtres au niveau C++, on passe au niveau
de programmation Tcl pour lancer les diffrentes simulations. Sur ce niveau, on utilise les
diffrents protocoles et sources de trafic dfinis pour tudier le comportement dune telle
situation.
Intervalles de confiance
En pratique, le problme est de calculer un intervalle raisonnable pouvant contenir la valeur p
quon veut dterminer par simulation. On utilise le thorme de Moivre-Laplace pour calculer
un intervalle de confiance pour p. Dans le cas des sondages, un intervalle de confiance est
appel une fourchette. Si f est la frquence observe sur un sondage de taille n, alors
l'intervalle de confiance (fourchette) de niveau 0,95 pour p sera :
[ f + 1,96 (f(1-f)/n)
(1/2)
; f - 1,96 (f(1-f)/n)
(1/2)
] (A.1)
Concrtement, si on calcule l'intervalle de confiance ci-dessus pour 100 sondages
indpendants de taille n, on peut s'attendre ce qu'environ 95 contiennent la vraie valeur de p,
et environ 5 ne la contiennent pas.
Pour nos simulations, on mesure la probabilit de perte pour les utilisateurs voix, qui est dans
lordre de 1% et celle des utilisateurs data, qui est dans lordre de 0.1%. En utilisant
lquation A.1 on remarque que 40 milles tests (n = 40000) pour les utilisateurs voix
produisent une erreur de t0.001 sur la probabilit de perte des utilisateurs voix. Si un paquet
est envoy tous les 20ms en cas dactivit et que le temps dactivit est de 50% prs, un test
est accompli en un temps moyen de 40ms. Les 40 milles de tests ncessitent un temps de
simulation de 1600secondes prs pour chaque utilisateur. Si on fait des tests pour 40
utilisateurs sur le mme canal et on mesure la probabilit de perte pour tous les paquets en
provenance de tous les utilisateurs, un temps de simulation de 40secondes suffira. Enfin, on
- 147 - 147
lance la simulation plusieurs fois (vnements indpendants) et on fait la moyenne pour avoir
une probabilit que le rsultat obtenu appartient lintervalle de confiance proche de lunit.
Toutes ces mesures sont faites en tat stationnaire. Cet tat est dtect quand le systme
devient en quilibre et les entrants au canal seraient statistiquement gaux aux sortants.
La mme discussion est faite pour les autres utilisateurs data pour calculer des intervalles de
confiance acceptables et en dduire le temps de simulation ncessaire. Remarquons que pour
les sources data, la probabilit de perte est dans lordre de 0.1% ce qui ncessite un intervalle
de confiance de marge 0.01% (erreur = t0.0001) et alors 400 milles tests. Puisque le nombre
de tests est dduit de nombre total de paquets envoys par les diffrents utilisateurs, un temps
de simulation de 400secondes suffira (en moyenne 1 test est effectu par 1ms). La simulation
est encore rpte plusieurs fois pour augmenter la fiabilit du modle. Les mesures sont
toujours faites en tat stationnaire.
Dans le cas o plusieurs types dutilisateurs seraient multiplexs, le temps de simulation doit
tre calcul sur les utilisateurs les plus exigeants qui sont les utilisateurs data. Par exemple,
quand 20 sources de transfert de fichiers et 20 sources voix sont multiplexs, un temps de
simulation de 800secondes est ncessaire (1 test data est accompli en 2ms dans ce cas).
Tous ces rsultats sont valables pour le calcul de la probabilit de perte. Pour le dlai on a
calcul la valeur moyenne des dlais moyens pour les diffrents utilisateurs. Puisque les
gnrateurs alatoires implments dans les diffrentes sources de trafic sont indpendants, on
peut calculer un intervalle de confiance en utilisant la formule dduite du thorme central
limite :
95 . 0
) (
) ( ,
) (
) ( Pr(
2
975 . 0 , 1
2
975 . 0 , 1

1
1
]
1

+

n
n S
t n D
n
n S
t n D d
n n


D(n) est la valeur moyenne des D
i
qui reprsentent les dlais moyens des diffrents
utilisateurs (de nombre n) tandis que S
2
(n) est sa variance. t est le point critique calcule
daprs le tableau prsent dans [78] pour une distribution normale.
Pour dmontrer la prcision de nos rsultats de simulation, on prend un exemple critique qui
est la figure 6.11 o on compare les dlais dattente des paquets data ou web suivant deux
stratgies dallocation de ressources. Dans le cas de 10 utilisateurs data, pour les utilisateurs
web la diffrence entre les deux stratgies est minime. Le dlai est de 100ms pour la stratgie
dynamique et 130ms pour la stratgie statique. Le problme qui se pose est si cette diffrence
est significative vue la prcision des mesures. Avec 100 utilisateurs web, la moyenne obtenue
dans le premier cas est de 100 et la variance est de 150, lintervalle de confiance est donc
(t1.831.2=t2.24ms). Il est proche ce rsultat dans le deuxime cas. Lintervalle de
confiance est beaucoup plus petit que la diffrence mesure. Notons que cette discussion est
applicable aux probabilits de perte et donne une autre preuve de la prcision des valeurs
dduites par simulation de cette perte.
Ce raisonnement est fait sur les diffrents cas de simulation pour montrer que lintervalle de
confiance est toujours acceptable. Notre stratgie de simulation est la suivante : puisque le
nombre de sondages indpendants est gal au nombre dutilisateurs (minimum de 5 dans
toutes nos simulations) la longueur dun sondage augmente quand le nombre de sondage
diminue de faon avoir une valeur minime de lintervalle de confiance. Cet approche est
quivalente au procdure de (Batch means) [78].

- 148 - 148
Cette discussion est utilise pour dterminer des intervalles de simulation acceptable. On va
donner une preuve additionnelle de lexactitude de nos rsultas en rptant la simulation 5
fois et en calculant lintervalle de confiance correspondante. On prend toujours lexemple de
la figure 6.11 et 6.12 et on obtient en cas de 10 utilisateurs data avec allocation statique, le
tableau :
Probabilit de perte Dlai
Premire simulation 0.0004 1000ms
Deuxime simulation 0.0004 980ms
Troisime simulation 000042 1030ms
Quatrime simulation 0.00041 1020ms
Cinquime simulation 0.00043 960ms
Intervalle de confiance 0.000016 35ms
Ceci dmontre que lintervalle de confiance est infrieur 1% de la probabilit de perte et
ngligeable devant le dlai dattente et la diffrence mesure entre les cas de data statique et
dynamique. Notons que cette valeur est infrieure pour les utilisateurs web puisquon a plus
des utilisateurs web dans ce cas.
On va finir cet appendice par deux exemples qui reprsentent le protocole S-CDMA
implment en C++. et un multiplexage de services crit en Tcl.

Le programme C++ est limplmentation du CDMA pour les terminaux Voix :
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS AS IS AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* Contributed by abbas IBRAHIM,
*/

#ifndef lint
static const char rcsid[] =
"@(#) $Header: /usr/src/mash/repository/vint/ns-2/satcdma.cc,v 1.5
1999/07/22 19:14:50 tomh Exp $";
#endif


#include "satcdma.h"
#include "satlink.h"
#include "sattrace.h"
#include "satposition.h"
#include "satnode.h"
#include "satgeometry.h"
- 149 - 149
#include "errmodel.h"
#include "math.h"
#include "stdio.h"

static class PrmacdmaClass : public TclClass {
public:
PrmacdmaClass() : TclClass("Mac/Sat/Prmacdma") {}
TclObject* create(int, const char*const*) {
return (new PrmacdmaMac());
}
} sat_class_prmacdmamac;

/*=========================================================================
=*/
/* _PrmacdmaMac
*/
double PrmacdmaMac::lastone=0;
//int PrmacdmaMac::tab_slot_[20]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
PrmacdmaMac::PrmacdmaMac() : SatMac(), tx_state_(MAC_CONT),
rx_state_(MAC_IDLE),
slot_(1),z_time(0), prev_time(0), r(0), time(0)
{

out1.open("slot1.tr");
bind_time("tslot_", &tslot_);
bind_time("frame_",&frame_);
bind("T_",&T_);
bind("L_",&L_);
bind("n_slot_",&n_slot_);
bind("n_code_",&n_code_);
bind("s_factor_",&s_factor_);
bind("users_",&users_);

}

void PrmacdmaMac::send_timer()
{
int i,j;
switch (tx_state_) {

case MAC_RES:
if (arr) {
HDR_MAC(snd_pkt_)->sstime()=tab_slot_[slot_];
downtarget_->recv(snd_pkt_, this);
arr=0;
send_timer_.resched(frame_);
}
else {
tx_state_=MAC_CONT;
tab_slot_[slot_]=tab_slot_[slot_]-1;
}

Scheduler::instance().schedule(&hRes_,&intr_,0);
break;
case MAC_BER:
tab_slot_[slot_] = tab_slot_[slot_] + 1;
- 150 - 150
HDR_MAC(snd_pkt_)->sstime()=tab_slot_[slot_];
downtarget_->recv(snd_pkt_,this);
if (tab_slot_[slot_] <= n_code_) {
tx_state_ = MAC_RES;
prev_time=NOW;
}
else {
tx_state_=MAC_CONT;
tab_slot_[slot_]=tab_slot_[slot_]-1;
}
Scheduler::instance().schedule(&hRes_,&intr_,0);
break;
case MAC_CONT:
j = fqo(NOW-fqo(NOW,frame_)*frame_,tslot_)+2;
i=1; r=j-1;
if (j>n_slot_) { j=1; }
z_time=NOW-fqo(NOW,frame_)*frame_;
while (i <= n_slot_) {
if (Random::uniform( prob(tab_slot_[j])-1, prob(tab_slot_[j]))
> 0) {
tx_state_=MAC_BER;
slot_ = j;
i = n_slot_ + 3;
sendDown(snd_pkt_); }
else { i = i + 1; r=r+1;
if (j==n_slot_) { j=1; }
else { j=j+1; } }
}
if (i != n_slot_+3) { drop(snd_pkt_);
Scheduler::instance().schedule(&hRes_,&intr_,0); }
break;
default:
printf("Error: wrong tx_state in prmacdma: %d\n",
tx_state_);
break;
}
}

void PrmacdmaMac::recv_timer()
{
switch (rx_state_) {

case MAC_RECV:
Scheduler::instance().schedule(uptarget_,rcv_pkt_,delay_);
break;
default:
printf("Error: wrong rx_state in prmacdma: %d\n",
rx_state_);
break;
}

}

void PrmacdmaMac::sendUp(Packet* p)
{
int i;
- 151 - 151
hdr_mac* mh = HDR_MAC(p);
int dst = this->hdr_dst((char*)mh);
int src = this->hdr_src((char*)mh);
if (((u_int32_t)dst != MAC_BROADCAST) && (dst != index_))
{ drop(p); }
else {
i=(int)mh->sstime();
if (resp(i)) {
rcv_pkt_ = p;
rx_state_ = MAC_RECV;
recv_timer_.resched(mh->txtime()); }
else {
drop(p); }
}
}
void PrmacdmaMac::sendDown(Packet* p)
{
double txt;
// compute transmission delay:
int packetsize_ = HDR_CMN(p)->size() + LINK_HDRSIZE;
if (bandwidth_ != 0)
txt = tslot_;
HDR_MAC(p)->txtime() = txt;
if (NOW > lastone) {
out1<<NOW<<" "<<tab_slot_[1]<<" "<<tab_slot_[2]<<"
"<<tab_slot_[3]<<" "<<tab_slot_[4]<<" "<<tab_slot_[5]<<"
"<<tab_slot_[6]<<" "<<tab_slot_[7]<<" "<<tab_slot_[8]<<"
"<<tab_slot_[9]<<" "<<tab_slot_[10]<<" "<<tab_slot_[11]<<"
"<<tab_slot_[12]<<" "<<tab_slot_[13]<<" "<<tab_slot_[14]<<"
"<<tab_slot_[15]<<" "<<tab_slot_[16]<<"\n";
lastone = NOW;
if (NOW>100)
{ out1.close();
lastone = 300;
}
}
snd_pkt_=p;
if (tx_state_ == MAC_CONT) {
send_timer_.resched(0); }
else if (tx_state_ == MAC_BER) {
time=(r*tslot_ - z_time + txt);
send_timer_.resched(time); }
else if (tx_state_ == MAC_RES) {
arr=1;
send_timer_.force_cancel();
if (((slot_-1)*tslot_-NOW+fqo(NOW,frame_)*frame_+txt)>0) {
time=((slot_-1)*tslot_-NOW+fqo(NOW,frame_)*frame_+txt);
}
else { time=((slot_-1)*tslot_-
NOW+fqo(NOW,frame_)*frame_+txt+frame_);
}

send_timer_.resched(time);
}
}

- 152 - 152
double PrmacdmaMac::prob(int j)
{
int s = 0;
int n;
double U=2;

//return 1;

//if ((s_factor_-j) >= 0) {
//return (0.3-0.05*j); }
//else
//{ return ((0.3 - 0.09*j)>0)? (0.3-0.09*j): 0; }

if ((s_factor_ - j) > 0) {
return 1; }
else if ((n_code_-j) > 0) {
return s_factor_/(j*U); }
else { return 0; }
}

int PrmacdmaMac::resp(int i)
{
static double s=1;
int j;
double q=0;
if (i<=1) { return 1; }
else {
double h = erfc(sqrt(3.0*s_factor_/(i - 1)))/2;

for (j=0; j<=T_; j++) { q = q + comb(L_,j)*pow(h,j)*pow(1 - h,L_ -
j); }
if (q < s) { s = q;
printf("tab1: %d\n",tab_slot_[1]);
printf("tab2: %d\n",tab_slot_[2]);
printf("tab3: %d\n",tab_slot_[3]);
printf("tab4: %d\n",tab_slot_[4]);
printf("tab5: %d\n",tab_slot_[5]);
printf("tab6: %d\n",tab_slot_[6]);
printf("tab7: %d\n",tab_slot_[7]);
printf("tab8: %d\n",tab_slot_[8]);
printf("tab9: %d\n",tab_slot_[9]);
printf("tab10: %d\n",tab_slot_[10]);
printf("tab11: %d\n",tab_slot_[11]);
printf("tab12: %d\n",tab_slot_[12]);
printf("tab13: %d\n",tab_slot_[13]);
printf("tab14: %d\n",tab_slot_[14]);
printf("tab15: %d\n",tab_slot_[15]);
printf("tab16: %d\n",tab_slot_[16]);
printf("h: %f\n",h);
printf("i: %d\n",i);
printf("qmin: %f\n",s); }
return (Random::uniform(q-1, q)>=0) ? 1: 0; }
}


double PrmacdmaMac::comb(int i, int j)
- 153 - 153
{
double s=1;
int k;
for (k=1; k<=j; k++) {
s=s*(i-j+k)/k;
}
return s;
}
double PrmacdmaMac::fact(int i)
{
double s=1;
int k;
for (k=1; k<=i; k++) {
s = s*k; }
return s;
}

int PrmacdmaMac::fqo(double i, double j)
{
int s;
double l;
s=1; l=j;
while (l<=i) {
s = s + 1;
l = l + j; }
return s-1;}

le programme TCL est un multiplexage de services qui comprend des sources de transfert de
fichiers et de voix sur le canal satellite CDMA :

global ns
set ns [new Simulator]
$ns rtproto Dummy; # Using C++ routing agents and objects
HandoffManager/Term set elevation_mask_ 8.2
HandoffManager/Term set term_handoff_int_ 10
HandoffManager/Sat set sat_handoff_int_ 10
HandoffManager/Sat set latitude_threshold_ 60
HandoffManager/Sat set longitude_threshold_ 10
HandoffManager set handoff_randomization_ "true"
SatRouteObject set metric_delay_ "true"
SatRouteObject set data_driven_computation_ "true"
ns-random 1
Agent set ttl_ 32;
set users 100;
set band 128;
set n_s 8;
set p_l 20;
set s_f [expr $band/(8*$n_s)]
set t_s [expr ($p_l*8*$s_f*1.0)/($band*1000)]
set t_f [expr $n_s*$t_s]
set n_c 3
Mac/Sat/Prmacdma set users_ [expr $users/2]
Mac/Sat/Prmacdma set s_factor_ $s_f
Mac/Sat/Prmacdma set tslot_ $t_s
Mac/Sat/Prmacdma set n_slot_ $n_s
Mac/Sat/Prmacdma set n_code_ $n_c
- 154 - 154
Mac/Sat/Prmacdma set frame_ $t_f
Mac/Sat/Prmacdma set T_ 10
Mac/Sat/Prmacdma set L_ 384

Mac/Sat/Prmacdmadta set users_ [expr $users/2]
Mac/Sat/Prmacdmadta set s_factor_ $s_f
Mac/Sat/Prmacdmadta set tslot_ $t_s
Mac/Sat/Prmacdmadta set n_slot_ $n_s
Mac/Sat/Prmacdmadta set n_code_ $n_c
Mac/Sat/Prmacdmadta set frame_ $t_f
Mac/Sat/Prmacdmadta set T_ 10
Mac/Sat/Prmacdmadta set L_ 384

global opt
set opt(chan) Channel/Sat
set opt(bw_up) 128Kb;
set opt(bw_down) 128Kb;
set opt(bw_isl) 25Mb;
set opt(phy) Phy/Sat
set opt(mactv) Mac/Sat/Prmacdma
set opt(mactd) Mac/Sat/Prmacdmadta
set opt(mac) Mac/Sat
set opt(ifqt) Queue/DropTail
set opt(qlimt) 100
set opt(ifq) Queue/NODropTail
set opt(qlim) 5
set opt(ll) LL/Sat
set opt(alt) 780;
set opt(inc) 86.4;

# XXX This tracing enabling must precede link and node creation
#set f [open out.tr w]
#set f0 [open sim.tr w]
#$ns trace-all $f

# Set up satellite and terrestrial nodes

set linkargs "$opt(ll) $opt(ifq) $opt(qlim) $opt(mac) $opt(bw_down)
$opt(phy)"
set alt $opt(alt)
set inc $opt(inc)
set chan $opt(chan)

source sat-iridium-nodes.tcl
source sat-iridium-links.tcl

set a 100
for {set c 30} {$c < 40} {incr c} {
for {set b 30} {$b < [expr 30+0.5*$users/10] } {incr b} {
set n($a) [$ns satnode-terminal [expr $b ] [expr $c ] ]
incr a } }

for {set c 40} {$c < 50} {incr c} {
for {set b 30} {$b < [expr 30+0.5*$users/10] } {incr b} {
set n($a) [$ns satnode-terminal [expr $b ] [expr $c ] ]
incr a } }
- 155 - 155

for {set a 100} {$a < [expr 100+$users/4]} {incr a} {
$n($a) add-gsl polar $opt(ll) $opt(ifqt) $opt(qlimt) $opt(mactv)
$opt(bw_up) $opt(phy) [$n0 set downlink_] [$n0 set uplink_]
}
for {set a [expr 100+$users/4] } {$a < [expr 100+$users/2]} {incr a} {
$n($a) add-gsl polar $opt(ll) $opt(ifqt) $opt(qlimt) $opt(mactd)
$opt(bw_up) $opt(phy) [$n0 set downlink_] [$n0 set uplink_]
}
for {set a [expr 100+$users/2] } {$a < [expr 100+0.75*$users]} {incr a} {
$n($a) add-gsl polar $opt(ll) $opt(ifqt) $opt(qlimt) $opt(mactv)
$opt(bw_up) $opt(phy) [$n0 set downlink_] [$n0 set uplink_]
}
for {set a [expr 100+3*$users/4] } {$a < [expr 100+$users]} {incr a} {
$n($a) add-gsl polar $opt(ll) $opt(ifqt) $opt(qlimt) $opt(mactd)
$opt(bw_up) $opt(phy) [$n0 set downlink_] [$n0 set uplink_]
}

#$ns trace-all-satlinks $f

for {set a 100} {$a < [expr 100 + $users/4]} {incr a} {
set a1 [expr int($a + $users/4)]

set b [expr int($a + $users/2)]
set b1 [expr int($a +3*$users/4)]

set udp($a) [new Agent/UDP]
set udp($a1) [new Agent/UDP]

$ns attach-agent $n($a) $udp($a)
set exp($a) [new Application/Traffic/Exponential]
$exp($a) attach-agent $udp($a)
$exp($a) set rate_ 8Kb
$exp($a) set packetSize_ 20
$exp($a) set burst_time_ 1s
$exp($a) set idle_time_ 1.35s

$ns attach-agent $n($a1) $udp($a1)
set ge($a1) [new Application/Traffic/Geometrical]
$ge($a1) attach-agent $udp($a1)
$ge($a1) set packetSize_ 20
$ge($a1) set rate_ 8Kb
$ge($a1) set p_ 0.99
$ge($a1) set idle_time_ 4s

set null($a) [new Agent/LossMonitor]
set null($a1) [new Agent/LossMonitor]

$ns attach-agent $n($b) $null($a)
$ns attach-agent $n($b1) $null($a1)

$ns connect $udp($a) $null($a)
$ns connect $udp($a1) $null($a1)

$ns at 1.0 "$exp($a) start"
$ns at 1.0 "$ge($a1) start"
- 156 - 156
}
proc record {} {
global null f0
set ns [Simulator instance]
set now [$ns now]
set lo00 [$null(100) set nlost_]
set eo00 [$null(100) set expected_]
set lo01 [$null(101) set nlost_]
set eo01 [$null(101) set expected_]
set lo02 [$null(102) set nlost_]
set eo02 [$null(102) set expected_]
set lo03 [$null(103) set nlost_]
set eo03 [$null(103) set expected_]
set lo04 [$null(104) set nlost_]
set eo04 [$null(104) set expected_]
set lo05 [$null(105) set nlost_]
set eo05 [$null(105) set expected_]

set lo10 [$null(125) set nlost_]
set eo10 [$null(125) set expected_]
set lo11 [$null(126) set nlost_]
set eo11 [$null(126) set expected_]
set lo12 [$null(127) set nlost_]
set eo12 [$null(127) set expected_]
set lo13 [$null(128) set nlost_]
set eo13 [$null(128) set expected_]
set lo14 [$null(129) set nlost_]
set eo14 [$null(129) set expected_]
set lo15 [$null(130) set nlost_]
set eo15 [$null(130) set expected_]

puts stdout "$now $eo00 $lo00 $eo01 $lo01 $eo02 $lo02 $eo03 $lo03 $eo04
$lo04 $eo05 $lo05 $eo10 $lo10 $eo11 $lo11 $eo12 $lo12 $eo13 $lo13
$eo14 $lo14 $eo15 $lo15"
$ns at [expr $now + 0.5] "record"
}
# We use centralized routing
set satrouteobject_ [new SatRouteObject]
$satrouteobject_ compute_routes

$ns at 800.0 "finish"

proc finish {} {
global ns f f0
$ns flush-trace
# close $f
# close $f0
exit 0
}
$ns at 2.0 "record"
$ns run