Simulation de différents scénarios – Accès LEO

By 31 May 2012

Simulation De Différents Scénarios – Chapitre 6

Dans ce chapitre :
6.1 Introduction
6.2 Contexte général
6.3 Premier scénario
6.4 Conclusion

6.1 Introduction

Jusque-là, nous avons vu une étude théorique du problème d’optimisation de l’accès LEO. A présent, nous allons utiliser ns afin de réaliser des scénarios qui nous permettront de prendre une décision quant au choix du satellite qui récoltera le service de la communication.

Dans le contexte présenté aux chapitres précédents (des mobiles se déplaçant dans une surface fixe au-dessus desquels défilent deux satellites), deux critères ont été choisi pour nous aider à prendre une décision sur le satellite qui servira la communication:

– accès aléatoire avec une probabilité P=1/2 pour chaque satellite de servir la communication.
– rattachement de la communication au satellite ayant la charge résiduelle maximale entre les deux satellites en vue, de telle façon à réaliser un équilibre des charges dans les différents satellites et ainsi optimiser l’utilisation du réseau.

Nous présenterons donc les différents scénarios avec les observations et interprétations qui s’ensuivent. Ils nous permettront aussi de savoir s’il vaut la peine d’élaborer des algorithmes d’accès aux satellites ou si l’accès aléatoire serait une solution convenable.

Pour cela, nous commencerons par définir le cadre dans lequel se déroulent ces scénarios.

6.2 Contexte général

Comme nous l’avons déjà dit, des mobiles se déplacent à l’intérieur d’une surface de dimensions 700*700 Km2 (nous verrons un peu plus loin pourquoi on a choisi une telle surface).

Le nombre d’utilisateurs est un paramètre de la simulation en cours.

Les applications sont de deux types :
– CBR/UDP qui nous permettra de simuler le service voix traditionnel de 16 Kbps
– et FTP/TCP qui simulera un transfert de fichiers à un débit de 64 Kbps

Les scénarios suivront les étapes suivantes :
a- dans la première étape, deux satellites défilent au-dessus de la surface où se trouvent les mobiles, de façon à ce qu’un seul satellite soit en vue à la fois par les mobiles.
b- dans la seconde étape, trois satellites défileront : d’abord le satellite A qui prendra en charge toutes les communications, jusqu’au moment où il tombera au-dessous de l’Elevation Mask, alors que deux satellites B et C à égale distance de A, seront en vue par rapport aux mobiles.

Dans chaque étape, on fera l’itération suivante :
– densification du réseau de mobiles, ce qui revient à augmenter le nombre d’utilisateur et ainsi le nombre des applications.
– Variation des pourcentages de chaque type d’application. Ex : on simulera dans un scénario i, 70% de communications de voix, et 30% de communications de données.

6.3 Premier scénario

Répartition des mobiles

Répartition des mobiles à l’intérieur d’une grille de dimensions 700x700 Km2
Figure 6.1 Répartition des mobiles à l’intérieur d’une grille de dimensions 700×700 Km2.

Dans ce scénario, les mobiles -au nombre de 49- sont répartis de façon homogène à l’intérieur d’une surface de dimensions 700×700 Km2, comme il est représenté sur la figure 6.1

Soit m(i,j) le mobile se trouvant sur le parallèle i et le méridien j, la latitude et la longitude de ce mobile sont telles que :
Lat(m(i,j)) = 15 + i (en degrés);
Long(m()i,j) = 15 +j (en degrés).

distance en Km entre deux points séparés par 1 degré
Figure 6.2 distance en Km entre deux points séparés par 1 degré

D’où, nous aurons les relations suivantes entre deux mobiles adjacents :
Lat(m(i+1,j)) = Lat(m(i,j)) + 1o ;
Long(m(i,j+1)) = Long(m(i,j)) + 1o .

Et la distance d entre deux mobiles séparés de 1o (que ce soit en latitude ou longitude) est obtenue d’après l’équation :
d2 = 63702 + 63702 -2*6370*6370*cos(1o), ce qui donne d = 111,2 Km environ.

Répartition des applications

Dans ce premier scénario, nous allons considérer une répartition égale des deux types d’applications : CBR/UDP (50%) et FTP/TCP (50%).

Le programme cbrgen fourni avec Network Simulator (ns), nous permet de générer des trafics aléatoires avec les paramètres suivants :
– type d’applications : CBR/UDP (qui permet de simuler le service de voix) ou FTP/TCP (qui permet de simuler le transfert de fichiers).
– Nombre maximum de mobiles : nmax
– Nombre maximum d’applications
– Et le débit dans le cas de l’application CBR/UDP.

Il simule des communications aléatoires possédant les aléas suivants :
– mobile source
– mobile destination
– instant de début de la communication.

Programme sat-49.tcl

Ce programme permet de simuler les mobiles précédents avec leurs applications. Ces derniers communiquent entre eux grâce aux deux satellites A et B qui défilent l’un à la suite de l’autre au-dessus de la grille. Au début de la simulation, le satellite A se trouve à :

Lat_A(t=0) = 15 ;
Long_A(t=0) = 15.

Alors que le satellite B a les coordonnées suivantes :
Lat_B(t=0) = 0 ;
Long_B(t=0)=15 ;

La durée de la simulation est de 840s soit 14min. Sachant que le diamètre de l’empreinte de chaque satellite est de 700Km, nous pourrons alors observer les deux satellites couvrir les mobiles à tour de rôle de toute la surface de leur empreinte avant de sortir du « champ de vision » de ces derniers. Ceci nous permettra de surveiller les Handovers d’un satellite à l’autre.

Remarques sur le code

Note: Le code de sat-49.tcl est présent dans le CD joint avec le compte rendu.

Le débit D des applications CBR/UDP est calculé comme suit:

D = 512(octets/paquets)*8(bits/octet)*(1/0.25)(paquets/seconde) = 16384 bits/s = 16.384 Kbps

Chronologie des applications

Start source Sink type satellite
2.5568 1 2 CBR/UDP A
7.703 7 9 CBR/UDP A
12.4451 29 31 FTP/TCP A
19.6557 17 19 CBR/UDP A
20.4854 8 9 CBR/UDP A
22.6798 28 29 FTP/TCP A
29.5461 7 8 CBR/UDP A
29.7782 17 18 FTP/TCP A
30.0204 15 17 FTP/TCP A
31.4649 9 11 CBR/UDP A
36.2239 21 22 FTP/TCP A
39.0887 15 16 CBR/UDP A
43.4206 15 17 CBR/UDP A
46.2588 26 27 CBR/UDP A
46.4558 11 13 CBR/UDP A
47.1283 28 29 CBR/UDP A
47.6066 4 6 FTP/TCP A
47.6086 29 30 FTP/TCP A
50.3342 15 16 FTP/TCP A
51.7975 13 14 FTP/TCP A
51.9373 21 23 FTP/TCP A
55.6342 6 7 CBR/UDP A
56.3331 4 5 CBR/UDP A
60.4192 24 25 CBR/UDP A
62.7733 11 12 CBR/UDP A
72.9934 17 18 CBR/UDP A
75.3741 13 15 FTP/TCP A
76.2582 9 10 CBR/UDP A
83.0747 31 32 FTP/TCP A
83.9008 13 14 CBR/UDP A
95.6695 3 4 FTP/TCP A
96.1365 10 12 FTP/TCP A
98.0679 27 28 CBR/UDP A
103.3393 4 5 FTP/TCP A
103.3449 8 9 FTP/TCP A
103.93 14 15 FTP/TCP A
115.9911 12 13 FTP/TCP A
120.0315 3 5 FTP/TCP A
121.9228 16 17 CBR/UDP A
133.4431 41 42 FTP/TCP A
134.8247 27 28 FTP/TCP A
137.2017 16 18 CBR/UDP A
140.182 17 19 FTP/TCP A
146.9656 4 6 CBR/UDP A
155.1721 14 15 CBR/UDP A
160.4426 20 22 CBR/UDP A
163.2219 10 11 FTP/TCP A
164.7066 30 31 FTP/TCP A
170.3276 20 21 CBR/UDP A

Table 6.1 Chronologie des applications de la première simulation

Observations et interprétation des résultats du fichier de trace out49_2.tr

1- En prenant deux instants d’observation, on peut déduire d’après les coordonnées du satellite A, la vitesse de parcours du satellite en latitude comme en longitude.

Ex : + 2.5568 3 0 cbr 512 ——- 0 3.0 4.0 0 0 15.00 16.00 15.07 16.42
r 56.5106 32 0 ack 40 ——- 0 32.0 31.2 272 26154 19.00 17.00 17.91 16.48

d’où, vitesse de défilement en latitude est comme suit :
vlat = (17.91-15.07)/(56.5106-2.5568) = 0.0526 degré/s

alors que la vitesse de défilement en longitude est :
vlong = (16.48-16.42)/(56.5106-2.5568) = 0.00111 degré/s.

2- A t1 = 2.55 s, la première application CBR commence entre les mobiles 1 et 2 (notés 3 et 4 respectivement par le simulateur ns). Elle est servie par le satellite A qui se trouve alors à : lat_A(t1) = 15.07 long_A(t1) = 16.42. A est, à ce moment-là, le seul satellite en vue.
+ 2.5568 3 0 cbr 512 ——- 0 3.0 4.0 0 0 15.00 16.00 15.07 16.42

3- A t2 = 7.703 s, la deuxième application CBR commence, également servie par A.
+ 7.7030 9 0 cbr 512 ——- 0 9.2 11.0 0 22 16.00 15.00 15.34 16.43

4- A t3 = 12.4451, la troisième application commence, cette fois-ci de type FTP :
+ 12.4451 31 0 tcp 40 ——- 0 31.3 33.0 0 59 19.00 16.00 15.59 16.43

Les paquets sont acquittés. On observe alors le chemin suivant :
trajet emprunté par les paquets et les acquittements d’une application FTP/TCP
Figure 6.3 trajet emprunté par les paquets et les acquittements d’une application FTP/TCP

La taille de la fenêtre de congestion est : w = 32 paquets.
La taille du paquet = 40 octets.

Entre t4 = 12.45 s et t5 = 12.65, 32 paquets sont envoyés, donc le débit est égal à:
Débit = 32*40*8 / (t5 –t4) = 51.2 Kbits/s

A t6 = 23.7979, le flag A apparaît pour la première fois dans le fichier de trace.
r 23.7979 31 0 tcp 552 —A— 0 31.3 33.0 3193 6787 19.00 16.00 16.19 16.44

Il correspond à la réduction de la fenêtre de congestion de TCP (Congestion Window Reduction. Ceci montre que les acquittements tardent à revenir aux sources TCP du fait de la congestion du satellite A.

En effet, à t6, ce satellite sert 4 applications CBR et deux applications FTP.
A t7 = 30.0844, la première perte a lieu.
d 30.0844 0 30 ack 40 ——- 0 31.1 30.3 717 10519 16.52 16.45 19.00 15.00

Le satellite A est surchargé. A partir de ce moment, on continue de voir le flag d (drop). Ce sont les acquittements qui sont perdus. C’est pourquoi on observe aussi tout au long du fichier de trace, le flag A ; puisque, les sources TCP ne trouvant pas d’aquittements réduisent la fenêtre de congestion.

A t8 = 205.4546, on observe le lien intraplan (Intraplane ISL) entre les satellites A et B.
+ 205.4546 0 1 cbr 512 ——- 0 6.1 8.0 230 113805 25.77 16.71 10.84 15.16

On observe aussi que la communication FTP entre les mobiles 3 et 5 (notés 5 et 7 respectivement dans le fichier de trace), suit le chemin suivant :
trajet suivi par les paquets et les acquittements d’une communication FTP/TCP
Figure 6.4 trajet suivi par les paquets et les acquittements d’une communication FTP/TCP

A partir de ce moment, les communications sont servies soit par le satellite A tout seul, soit par les deux satellites A et B.

8- t9 = 326.3936, les communications sont servies soit par A et B, soit par le satellite B tout seul.
+ 205.4546 0 1 cbr 512 ——- 0 6.1 8.0 230 113805 25.77 16.71 10.84 15.16

9- A t10 = 316.0391, seule la communication FTP entre les mobiles 41 et 42 est servie par le A, toutes les autres applications sont servies par le satellite B.
+ 316.0391 0 44 tcp 552 ——- 0 43.0 44.0 9431 241044 31.60 16.95 21.00 15.00

10- A partir de t11 = 329.3, même la communication FTP entre 41 et 42, est servie par le satellite B, le satellite A est donc tombé au-dessous de l’Elevation Mask pour tous les mobiles, ou il est devenu « hors vue ».
+ 329.3125 44 1 ack 40 ——- 0 44.0 43.0 12587 254994 21.00 15.00 17.37 15.29

11- A t12 =560.2583, le satellite B se trouve à Lat_B = 29.55 et à Long_B = 15.76.

Le mobile 17 ne trouve plus de satellites pour servir sa communication (la destination est alors notée –2 dans le fichier de trace). Et ainsi, à tour de rôle, les mobiles 9,14, 20, 26, 11…ne sont plus couverts par aucun satellite (Ils se trouvent en bas de la grille).

d 560.2583 19 -2 cbr 512 ——- 0 19.3 21.0 2141 395834 17.00 18.00 -999.00 -999.00

12- 12- A t13 = 576.7405, même le mobile 42, ne voit plus le satellite B. A partir de ce moment, toutes les communications sont sans issue, et les paquets perdus.

6.4 Conclusion

Dans ce chapitre, nous nous sommes familiarisé avec l’utilisation de ns pour la simulation d’un cas réel de la fonction de coût. Nous avons aussi pu interpréter un cas simple dans lequel un seul satellite était visible à la fois par les mobiles. Nous allons étudier dans les chapitres suivants des cas plus complexes où deux satellites seront en vue simultanément par les mobiles. L’interprétation des résultats de ces scénarios nous permettra de savoir si l’accès aléatoire est une solution convenable dans le cadre de l’équilibre de Nash.

– Chapitre 7 : Simulation De Différents Scénarios (Suite) – Accès Aléatoire :

Dans ce chapitre :

7.1 Introduction
7.2 Contexte général
7.3 Scénario 2
7.4 Scénario 3
7.5 Scénario 4
7.7 Comparaison des résultats des différents scénarios
7.8 Conclusion

7.1 Introduction

Dans le premier scénario, nous avons observé l’établissement des communications, d’abord par le satellite A qui, au départ, est le seul satellite en vue, ensuite, par le satellite B, qui en s’approchant, devient meilleur candidat que A pour le service des communications.

Dans ce chapitre, nous allons observer les traces des communications lorsque deux satellites B et C deviennent candidats au service des communications après A (scénarios 2, 3, 4 et 5).

Pour ces scénarios, nous avons opté pour un accès aléatoire. Nous entamerons donc par la situation du contexte général de ces scénarios pour ensuite passer à la description de la réalisation de l’accès aléatoire. Finalement, nous passerons à l’interprétation des résultats pour chacun d’eux.

7.2 Contexte général

Les scénarios 2, 3, 4 et 5 suivront l’itération exposée au chapitre précédent (§ 6.2). De plus, ils diffèrent du scénario 1 par la partie codant pour le “next” de A entre autres.

Ce code, qui s’écrivait dans sat-49.tcl comme suit:

$na set-position $alt $inc $long] $alpha 1
$nb set-position $alt $inc $long $alpha2 1
$na set_next $nb

sera remplacé dans les scénarios 2 à 5 par:

set na [$ns node]
set nb [$ns node]
set nc [$ns node]
$na set-position $alt $inc [expr $long + 3] $alpha 1
$nb set-position $alt $inc $long $alpha2 0
$nc set-position $alt $inc [expr $long + 6] $alpha2 2
$ns add-isl intraplane $nb $na $bw_isl $qtype $opt(qlim)
$ns add-isl intraplane $nc $na $bw_isl $qtype $opt(qlim)
$ns add-isl intraplane $nb $nc $bw_isl $qtype $opt(qlim)
proc set_sat_next {} {
#set ns [Simulator instance]
global ns outfile
global na nb nc
set time 1.0
set now [$ns now]
puts $outfile “$now”
set rng [new RNG]
$rng seed 0
set u [new RandomVariable/Uniform]
$u set min_ 0.0
$u set max_ 1.0
$u use-rng $rng
set rand [$u value]
if {$rand > 0.5} {
$na set_next $nb
puts $outfile “$now $rand next of A is B”
} else {
$na set_next $nc
puts $outfile “$now $rand next of A is C”
}
$ns at [expr $now + $time] “set_sat_next”
}

Modifications apportées par les scénarios 2, 3, 4 et 5 au scénario 1:

1- les deux satellites A et B du scénario 1 appartenaient au même plan orbital, alors que les satellites A, B et C des scénarios 2 à 5 appartiennent à 3 plans différents numérotés 0, 1, 2 et distants de 30 . De plus, les satellites B et C ont même latitude et sont en arrière de 150 par rapport à A.

2- la procédure set_sat_next présente dans les scénarios 2 à 5. Cette procédure actualise à chaque seconde la valeur du satellite qui secondera le satellite A. Ce choix est réalisé à partir d’une variable aléatoire rand. Si rand est supérieure à 0.5, le satellite B prendra les communications servies par A sinon, ce sera le rôle du satellite C.

Notons finalement que d’autres modifications, relatives à chaque scénario seront présentées au fur et à mesure qu’on y parviendra.

Notes sur les fichiers de trace :

1- On note d’abord que le simulateur ns numérote les différents agents de la communication de la façon suivante:
0 pour le satellite A,
1 pour le satellite B,
2 pour le satellite C

Quant aux différents mobiles, les numéros qui leurs sont accordés dans les différents programmes seront translatés de 3 dans les fichiers de trace correspondants

Ex: le mobile numéroté 5 dans le programme sat49-withRNG.tcl sera numéroté 8 dans le fichier de trace out49-withRNG.tr.

2- On note aussi que les fichiers de trace affichent à chaque seconde la valeur du “next” de A. Ex : 8 1.575800e-01 next of A is C

Ceci s’interprète par : à l’instant t = 8s, la valeur de rand est 1.575800e-01 d’où “next” de A est le satellite C.

7.3 Scénario 2

Pour cette première simulation de l’accès aléatoire, les paramètres, tels que la répartition des mobiles dans la surface S, et la répartition des applications et de leurs types entre les différents mobiles seront les mêmes que ceux de la simulation précédente.

Note:Le programme sat49-withRNG.tcl relatif à cette simulation, ainsi que le fichier de trace out49_withRNG.tr (comprimé en format WinZip), et le tableau sat49-2.xls sont présents dans le disque dur joint avec le compte-rendu.

Observations et interprétation des résultats du fichier de trace out49_withRNG.tr

1. Evaluons le débit de FTP/TCP au début de la simulation. On a à t0 = 12.4451, l’établissement d’une communication FTP/TCP entre les mobiles 29 et 31 notés respectivement 32 et 34 dans le fichier de trace.
+ 12.4451 32 0 tcp 40 ——- 0 32.3 34.0 0 59 19.00 16.00 15.59 19.43

C’est un premier paquet de taille 40 octets qui est envoyé au début du transfert de fichiers pour l’échange des paramètres de la communication. Ensuite, des paquets de grande taille (552 octets), sont envoyés du mobile 29 au mobile 31(puisque FTP correspond à un transfert de fichiers en blocs ou “bulk data transfer”).

En observant le temps mis pour envoyer toute la fenêtre fixée par TCP source au début de la communication, et qui est de 32 paquets, on peut calculer le débit de cette application :
Dcbr = 32 * 552 /(t32 – t1) = 32 * 552 /(12.5763 – 12.4659) = 1.077Mbits

2. A t1 = 23.4139, on observe la première perte de paquets, c’est-à-dire, peu après l’établissement de la 7ième communication – de type FTP/TCP. Le satellite est congestionné.

Or la bande passante du satellite est Bp = 1.5 Mbps ; et à t1, il y 4 applications CBR/UDP déjà établies et 2 applications de type FTP/TCP.

Le débit des applications CBR/UDP est calculé comme suit :
Dcbr = 4paquets/s * 512 octets/paquets* 8 bits/octets = 16384 Bits/s = 16.384 Kbits.

D’où, le débit des applications FTP/TCP peut être évalué d’après :
Bp = 4 * Dcbr + 2 * Dftp
Dftp = ( Bp – 4 * Dcbr)/2 = 717.232 Kbits

3. Si on observe à présent le débit de l’application FTP/TCP entre les mobiles 4 et 6 (notés respectivement 7 et 9), initiée à t = 47.6066 ; on trouve que ce dernier s’évalue à
Dcbr = 32 * 552 /( t32 – t1) = 32 * 552 / (48.5071 – 47.7401) = 184.24 Kbits.

On voit bien que le débit de FTP/TCP a diminué presque de 10 fois à cause de la congestion.

4. A t1′ = 25.8706, on observe le flag A pour la première fois dans le fichier de trace
+ 25.8706 31 0 tcp 552 —A— 0 31.3 32.1 370 8016 19.00 15.00 16.30 19.45

Donc jusqu’à cet instant on a les mêmes statistiques que dans le premier scénario.

5. A t2 = 30.0693, la première perte a lieu.

d 30.0693 0 34 tcp 552 ——- 0 32.3 34.0 4002 10469 16.52 19.45 19.00 18.00

A t3 = 203.1246, on observe le lien interplan (ISL) entre le satellites A et B
+ 203.1176 0 1 cbr 512 ——- 0 4.0 5.0 783 112266 25.64 19.70 10.72 15.16

Ceci veut dire que le satellite A demande au satellite B de le seconder dans le service de la communication entre les mobiles 4 et 5. Ceci est attendu puisque d’après la simulation:

203 8.336536e-01 next of A is B

C’est pourquoi, on trouve que le trafic entre les mobiles 4 et 5 suit le chemin suivant:
4015
r 203.1176 4 0 cbr 512 ——- 0 4.0 5.0 783 112266 15.00 16.00 25.64 19.70
+ 203.1176 0 1 cbr 512 ——- 0 4.0 5.0 783 112266 25.64 19.70 10.72 15.16
+ 203.1246 1 5 cbr 512 ——- 0 4.0 5.0 783 112266 10.72 15.16 15.00 17.00

Notons aussi qu’à t3, le satellite A se trouve à la latitude 25.640 alors que B se trouve à la latitude 10.720. Puisque les mobiles 4 et 5 sont tous les deux à la latitude 150 donc le satellite B est meilleur candidat que A car il est plus proche ou plus en vue par les deux mobiles. C’est la raison pour laquelle, il prend la relève du satellite A.

6. On voit aussi que la communication CBR/UDP entre les mobiles 9 et 10 est entièrement prise en charge par le satellite B, du fait que A est tombé au-dessous du “elevation mask” pour ces deux mobiles.

+ 360.7567 9 1 cbr 512 ——- 0 9.1 10.0 1218 345645 15.00 21.00 19.03 15.33
+ 360.7649 1 10 cbr 512 ——- 0 9.1 10.0 1218 345645 19.03 15.33 16.00 15.00

7. Par contre, les satellites B et C ensemble servent la communication FTP/TCP qui existe entre les mobiles 32 et 34.

+ 447.3058 32 2 tcp 552 ——- 0 32.3 34.0 9477 447537 19.00 16.00 23.59 21.45
+ 447.3198 2 1 tcp 552 ——- 0 32.3 34.0 9477 447537 23.60 21.45 23.60 15.45
+ 447.3224 1 34 tcp 552 ——- 0 32.3 34.0 9477 447537 23.60 15.45 19.00 18.00

8. 8. Pour certains mobiles -ceux ayant les plus petites latitudes dans la surface S, le satellite A n’est plus visible donc leurs communications sont entièrement servies par le satellite ayant été le “next” de A lors du handover, comme c’est le cas du mobile 8. Alors que pour d’autres – ceux se trouvant dans la limite supérieure de la surface S, le satellite A est toujours en visibilité, donc leurs communications sont entièrement ou partiellement servies par A, comme c’est le cas du mobile 19.

+ 231.3485 1 8 tcp 552 ——- 0 6.1 8.1 1850 139371 12.21 15.18 15.00 20.00
r 231.3487 19 0 ack 40 ——- 0 19.3 18.5 2403 139378 17.00 17.00 27.13 19.76

9. 9. A t6 = 309.3026, seule la communication entre les mobiles 44 et 45 est servie par le satellite A. toutes les autres, passent soit par le satellite B, soit par le satellite C.

+ 309.3026 44 0 tcp 552 ——- 0 44.0 45.0 9424 275379 20.00 21.00 31.24 19.93

Comme les communications sont à présent servies par deux satellites au lieu d’un seul, comme dans le cas de la première simulation, on observe moins de pertes et moins de flag A pour la réduction de la fenêtre de congestion de TCP. Il y a donc partage de charge dans le réseau.

10. 10. A t7 = 532.0663, on observe un lien interplan (ISL) entre les satellites B et C pour le service de la communication entre les mobiles 31 et 32.

r 532.0663 2 1 ack 40 ——- 0 32.1 31.3 13227 538264 28.06 21.61 28.06 15.61

11. 11. A t8 = 574.2880, le mobile 10 n’a plus de satellite en vue pour servir sa communication, son paquet, à destination du mobile 11, est perdu.

d 574.2880 10 -2 cbr 512 ——- 0 10.1 11.0 2159 574514 16.00 15.00 -999.00 -999.00

A partir de ce moment les mobiles sortent les uns après les autres de l’empreinte des satellites B et C et leurs paquets sont perdus. A t9 = 588 tous les paquets sont perdus, car les satellites B et C sont au-delà de 300 de latitude, donc au-dessous du “elevation mask”.

12. 12. On trouve s’après le fichier sat49-2.xls les résultats suivants concernant la répartition des applications entre les deux satellites B et C après handover des communications du satellite A:

* 39 applications sont servies par le satellite B contre 36 pour le satellite C.
* Les applications servies par B sont partagées entre 20 communications CBR/UDP contre 19 de type FTP/TCP.
* Les applications servies par C sont partagées entre 17 communications de type CBR/UDP, contre 19 de type FTP/TCP.
* Les satellites B et C servent en commun 12 communications CBR/UDP et 14 communications FTP/TCP.
* Ainsi le satellite B sert 3 communications de type CBR/UDP de plus que le satellite C, donc sa charge est supérieure à celle de C. La charge additionnelle Ch+ due aux 3 communications CBR/UDP peut être évaluée de la façon suivante:

Ch+ = 3*16.384/(1.5*1000) = 3.27%.

La différence entre les deux satellites est faible, et l’on peut dire qu’il y a équilibre de charges dans le réseau.

7.4 Scénario 3

C’est pour suivre l’itération du (§ 5.2) que nous avons établi ce scénario. Il diffère du scénario 2 par le nombre de mobiles présents dans la surface S – pratiquement le double, et par suite par le nombre de d’applications ou de requêtes à servir. Ceci correspond à la densification du réseau des abonnés.

Note:Le programme sat98-withRNG.tcl relatif à cette simulation, ainsi que le fichier de trace out98_withRNG.tr (comprimé en format WinZip) sont présents dans le disque dur joint avec le compte-rendu.

Observations et interprétation des résultats du fichier de trace out98_withRNG.tr

1. A t1 = 6.7205, on observe la première perte de paquet.

d 6.7205 0 28 ack 40 ——- 0 29.1 28.2 746 1623 15.29 19.43 16.50 19.50

Cette perte est précoce par rapport à celles observées dans les scénarios 1 et 2 en raison de la densification des requêtes. En effet, à t1′ = 6.7173, il y a déjà 3 applications FTP/TCP et une application CBR/UDP.

A partir de t1, on observe le flag d correspondant à des paquets perdus de façon plus fréquente que dans les deux premiers scénarios. Ce résultat est aussi attendu.

2. A t2 = 6.9058, on observe le flag A, aussi de façon précoce aux deux simulations 1 et 2.

+ 6.9058 58 0 tcp 552 —A— 0 58.2 60.2 54 1741 18.50 21.50 15.30 19.43

On peut interpréter ce résultat d la même manière que dans 1. On peut dire de même pour l’apparition plus régulière du flag A.

3. A partir de t3 = 210, on observe les liens interplans entre les satellites A et B d’une part, pour la commutation de la communication entre les mobiles 4 et 5 au satellite B:

+ 210.5514 0 1 cbr 512 ——- 0 7.0 8.0 617 120158 26.04 19.72 11.11 15.16

D’autre part, entre les satellites A et C pour le relais de la communication entre les mobiles 9 et 10 par le satellite C:

+ 210.9142 0 2 cbr 512 ——- 0 7.1 9.0 259 120349 26.06 19.72 11.13 21.16

A partir de ce moment, la charge du satellite A est partagée par les deux autres satellites, c’est pourquoi, on observe de moins en moins de paquets perdus pour le trafic passant par le satellite A (moins de flags d) et moins de flags A pour la réduction de la fenêtre de congestion de TCP.

4. A t4 = 219.6311, le flag A apparaît pour le trafic passant par le satellite B

+ 219.6311 14 1 tcp 552 —A— 0 14.5 16.2 447 129752 15.50 19.50 11.59 15.17

C’est que pour les mobiles, les satellites B et C sont meilleurs candidats pour le service de leurs requêtes que le satellite A, donc une grande part du trafic qui était écoulé par A passe à présent par les deux satellites.

A t4 = 219.6311, on peut même considérer que tout le toutes les communications ont divergé du satellite A aux satellites B et C.

On revient donc au scénario 1, en ce qui concerne chaque satellite avec en plus un partage équitable des charges. Ce résultat est attendu puisque la variable aléatoire rand à partir de laquelle se fait la décision du “next” de A est uniforme.

De plus, le calcul de la charge additionnelle due au trafic servi uniquement par B a montré que la différence de charge ente les satellites B et C est inférieure à 7% ,donc elle n’est pas notable.

5. A partir de t5 =590, la plupart des mobiles ne trouvent plus de satellites pour couvrir leurs communications, on observe alors la destination -2 (“destination unreachable”) apparaître dans le fichier de trace:

d 590.0688 29 -2 cbr 512 ——- 0 29.0 30.0 2185 593156 16.50 20.50 -999.00 -999.00

7.5 Scénario 4

Dans le scénario 3, le rapport du nombre de requêtes de type CBR/UDP sur le nombre total de requêtes était le même que celui des requêtes de type FTP/TCP.

RCBR/UDP = 50%
RFTP/TCP = 50%

Dans ce scénario, nous avons modifié ces rapports pour avoir :
R’CBR/UDP = 70%
R’FTP/TCP = 30%.

Nous allons comparer l’influence que cette modification a apportée sur la charge des satellites, les handovers et les pertes de paquets avec le scénario précédent.

Note:Le programme sat98-withRNG73.tcl relatif à cette simulation, ainsi que le fichier de trace out98_withRNG73.tr (comprimé en format WinZip) et le tableau sat98-73.xls sont présents dans le disque dur joint avec le compte-rendu.

Observations et interprétation des résultats du fichier de trace out98_withRNG73.tr

1. A t1 = 43.6226, on observe une perte du paquet ftp envoyé du mobile 16 au mobile 17.

d 43.6226 0 17 tcp 552 ——- 0 16.3 17.2 835 16821 17.24 19.47 16.00 15.00

ce qui explique l’occurence un peu plus tard du flag A:

– 43.8475 0 17 tcp 552 —A— 0 16.3 17.2 820 16901 17.25 19.47 16.00 15.00

De même, on observe aussi la perte d’un autre paquet ftp entre les mobiles 18 et 20

d 44.2138 0 20 tcp 552 ——- 0 18.4 20.4 809 17160 17.27 19.47 16.00 18.00

On remarque dans cette simulation que ce sont les paquets FTP/TCP eux-mêmes qui sont perdus et non plus seulement leurs acquittements comme c’était le cas dans les simulations précédentes. Ceci est dû à l’envahissement du réseau par les paquets CBR/UDP qui sont éjectés sans contrôle, leur seule limitation étant la capacité du réseau.

C’est aussi pour cette raison qu’on voit apparaître sans cesse le flag A pour les applications FTP/TCP.

2. Nous allons calculer le débit moyen et le temps moyen de transfert de paquets pour des applications FTP/TCP servies par les satellites A, B et C, en régime stationnaire.

Commençons par le débit moyen Dmoy de transfert de fichiers entre les mobiles 50 et 52.

A t2 = 244.2876, le mobile 50 envoie le flag A à son destinataire pour le renseigner de la réduction de la fenêtre de congestion.

+ 244.2876 50 0 tcp 552 —A— 0 50.1 51.1 863 160668 18.00 20.00 27.81 19.78

Nous allons donc évaluer Dmoy pour 16 paquets envoyés au lieu de 32.

A t3 = 245.1571 le 16ième paquet est envoyé du mobile 50 au mobile 52 à travers le satellite A.

Le débit moyen sera donc:

Dmoy = 16* 552/(245.1571-244.2876) = 1.157 Kbytes/s = 81.26 Kbits

Le temps moyen pour envoyer 16 paquets est de : 245.1571-24.2876 = 0.8695s

Calculons à présent le débit moyen pour le transfert de fichiers entre les mobiles 15 et 16, requête servie par le satellite B:

Entre ti = 300.4570 et tf = 300.4799, 10 paquets sont transmis, d’où:
Dmoy = 10*552/(300.4799-300.4570) = 241 Kbytes/s = 1.93 Mbits

Calculons de même le débit moyen pour l’application FTP/TCP entre les mobiles 48 et 49 servie par le satellite C.

Entre ti =300.6882 et tf = 301.4942, 28 paquets sont transmis, d’où le débit moyen s’évalue à :
Dmoy = 28 * 552 / (301.4942 – 300.6882) = 19.176 Kbytes/s = 153.41 Kbits

On voit donc bien que le débit dans les satellites B et C est nettement supérieur à celui observé dans le satellite A. Ce résultat est attendu vu que le satellite A servait toutes les requêtes avant de se décharger sur les satellites B et C.

3. Nous avons obtenu les résultats suivants (qu’on peut aussi voir dans le fichier sat98-73.xls se trouvant aussi sur le CD) en dénombrant les applications servies par les satellites B et C:

* Après handover des communications du satellite A, 76 applications sont servies par le satellite B, dont 53 de type CBR/UDP, le reste, au nombre de 23, étant évidemment de type FTP/TCP.
* Parmi les 53 applications de type CBR/UDP servies par B, 29 passent en même temps par C.
* D’autre part, 69 applications sont servies par le satellite C, dont 46 de type CBR/UDP, le reste aussi au nombre de 23 étant e type FTP/TCP.
* D’où, sachant que le nombre d’applications FTP/TCP est de 30, on peut dénombrer celles servies par les deux satellites à la fois de la façon suivante: 23+ 23 -30 = 16.
* Ainsi le satellite B sert 7 applications de plus que C, toutes de type CBR/UDP, donc il est plus chargé que son voisin; pourtant la différence n’est pas importante. En effet, sachant que la capacité du satellite est de 1.5 Mbps, on peut calculer la charge additionnelle Ch+ reléguée au satellite B d’après :

Ch+ = 7 * 16.384/(1.5*1000) = 7.64%

On peut donc estimer qu’il y a partage un partage équitable des charges entre les deux satellites, obtenu à partir d’un mode d’accès aléatoire.

7.6 Scénario 5

Finalement, dans ce scénario, nous avons réalisé des rapports opposés à ceux adoptés dans le scénario 4. Ainsi, le rapport du nombre de requêtes de type CBR/UDP sur le nombre total de requêtes est égal à :
R”CBR/UDP = 30%

Alors que celui des requêtes FTP/TCP est :
R”FTP/TCP = 70%.

Note:Le programme sat98-withRNG37.tcl relatif à cette simulation, ainsi que le fichier de trace out98_withRNG37.tr (comprimé en format WinZip) et le tableau sat98-37.xls sont présents dans le disque dur joint avec le compte-rendu.

Observations et interprétation des résultats du fichier de trace out98_withRNG37.tr

1. Commençons d’abord par calculer le débit moyen de FTP/TCP, dans les 3 satellites avant et après handover.

* Prenons pour cela, l’exemple de transfert de fichiers entre les 2 mobiles 40 et 41 (notés respectivement 43 et 44 par le simulateur ns). Ce transfert est géré par le satellite A.

A t = 243.0339, on observe le flag A envoyé du mobile source à son destinataire pour le renseigner de la réduction de sa fenêtre de congestion. C’est pourquoi, l’on va calculer le débit moyen Dmoy pour 8 paquets transmis et reçus avant de commencer à rencontrer les acquittements.

+ 243.0339 43 0 tcp 552 —A— 0 43.2 44.1 1918 190201 17.50 20.50 27.75 19.78

Entre t1 = 243.0339 et t8 = 243.6111, 8 paquets sont envoyés, d’où:

Dmoy = 552 * 8 / (243.6111 – 243.0339) = 7.65 Kbytes/s = 61.2 Kbits

* Calculons à présent le débit moyen Dmoy entre les mobiles 27 et 28 (notés 30 et 31 respectivement) servis par le satellite B tout seul après handover.

A t = 407.4003, on observe le flag A, d’où, pour la même raison que précédemment, on calcule Dmoy pour 16 paquets transmis

Entre t1 = 407.4003 et t16 = 408.3842, 1 paquets sont envoyés et reçus. D’où,
Dmoy = 16 * 552 / (408.3842 – 407.4003) = 71.8 Kbits

* Finalement, évaluons ce débit pour un transfert de fichiers supporté par le satellite C tout seul, comme c’est le cas des 2 mobiles 3 et 4 (notés respectivement 6 et 7) .

+ 322.9619 6 2 tcp 552 —A— 0 6.1 7.2 5338 334863 15.00 18.00 17.04 21.28

Entre t1= 323.9616 et t16 = 324.2875, 1 paquets sont transmis. D’où,
Dmoy = 16 * 552 / (324.2875 – 323.9616) = 216.802 Kbits.

* On peut facilement déduire que les débits dans les satellites B et C sont supérieurs à ceux dans le satellite A, parce que ces deux satellites sont moins chargés que A.

2. A présent, calculons la répartition des charges dans chaque satellite.

D’après le tableau sat98-37.xls, on trouve les résultats suivants:

* 74 applications sont servies par le satellite B, dont 25 de type CBR/UDP et 49 de type FTP/TCP.
* 79 applications sont servies par C dont 24 de type CBR/UDP, et 55 de type FTP/TCP.
* Comme le nombre total d’applications CBR/UDP est de 30, donc il y a

25 + 24 -30 = 19 applications CBR/UDP prises en charge par les deux satellites.

* De même, il y a 55 + 49 – 70 = 34 applications FTP/TCP servies par les deux satellites à la fois.
* Par suite, B sert 6 applications CBR/UDP de plus que C. Cependant, C sert une application de type FTP/TCP de plus que B.

3. on peut déduire la charge additionnelle dans chaque satellite due au nombre supplémentaire d’applications qu’il sert.

Ch+B = 6 * 16.384 = 98.304Kbits
Ch+C = 216.802 Kbits
D’où la charge additionnelle du satellite C par rapport au satellite B est :
(216.802 – 98.304) / (1.5 * 1000) = 118.5 / 1500 = 7.9 %

Cette différence entre les charges des deux satellites n’est donc pas notable, et on réalise ici aussi que l’approche aléatoire a contribué à un équilibre des charges dans le réseau.

7.7 Comparaison des résultats des différents scénarios

Les différences entre les scénarios 2, 3, 4 et 5 sont rassemblées dans le tableau 6.1.

On note que le nombre de paquets perdus Nperdus est obtenu en dénombrant le nombre de flags ‘d’ apparaissant dans les fichiers de trace correspondants à chaque scénario.

Celui des paquets envoyés Nenvoyés est obtenu en dénombrant le nombre de ‘+’ apparaissant en début de ligne dans les mêmes fichiers.

Quant à la probabilité de pertes de paquets Pperte-paq, elle est évaluée de la façon suivante:

Pperte-paq = Nperdus / (Nperdus + Nreçus) = Nperdus / Nenvoyés

Scénario Nombre de paquets perdus Nombre total de paquets transmis Nombre de flags A rencontrés Probabilité de perte de paquets (Pperte-paq)
2 62290 1358314 40600 4.58%
3 108479 1278679 53974 8.48%
4 118004 1136008 38353 10.38%
5 89102 1485097 76985 6%

Tab. 6.1 – statistiques sur les différents scénarios réalisés

Interprétation :

D’abord, en ce qui concerne le scénario 2 correspondant à 49 utilisateurs, c’est le réseau le plus faiblement chargé entre les 4 scénarios, ceci explique la probabilité de perte de paquets la plus faible.

Ensuite, le scénario 3 dans lequel il y a un rapport égal d’applications CBR/UDP que d’applications FTP/TCP, a une probabilité de perte de paquets comprise entre celles des scénarios 4 et 5. Ce résultat est attendu.

En effet, dans le scénario 4, on a 70% des applications de type CBR/UDP. Or les paquets UDP ne sont pas acquittés et leur flux n’est pas contrôlé. On dit qu’ils ne sont pas “TCP friendly”, c’est-à-dire qu’en cas de congestion, aucun mécanisme n’est adopté par les agents source et destination UDP pour y faire face et réduire les pertes. C’est pourquoi les pertes sont les plus élevées.

Dans le scénario 5, ces pertes sont contrôlées par les agents TCP par la réduction de la fenêtre de congestion. C’est le “backoff”, il permet de faire face à la congestion en ralentissant le débit d’émission de la source. On voit bien l’efficacité de ce mécanisme par la probabilité de pertes de paquets obtenue plus faible que dans le scénario 4.

Pourtant le flag ‘A’ apparaît le plus dans le scénario 4. Ce résultat est qui aussi attendu puisque ce sont les sources TCP qui génèrent ce flag et qu’elles sont le plus nombreuses dans ce scénario.

7.8 Conclusion

On voit donc que tous les scénarios réalisés dans ce chapitre ont donné des résultats pareils en ce qui concerne le partage des charges: l’accès aléatoire réalise un équilibre des charges dans le réseau.

La solution de l’accès aléatoire semble donc être convenable pour un réseau dans lequel le critère majeur est l’équilibre des charges.

Mais est-ce que d’autres approches telles que la charge résiduelle ne donneraient-elles pas des résultats pareils sinon meilleurs en ce qui concerne d’autres paramètres?

Chapitre 8 – Conclusion

Conclusion

Ainsi comme nous l’avons dit, la diversification des requêtes des clients et la complexité des services a engendré la multiplication des opérateurs de télécommunications aux quatre coins du monde. Mais cet essor des télécommunications, malgré son intégration et la densification de son maillage a présenté des lacunes de couverture qui ont été comblées par les constellations de satellites LEO.

Mais la proximité de ces satellites et leur mobilité par rapport à la terre a engendré des problèmes de handover.

Dans ce projet, nous avons essayé de résoudre le problème de handover lorsque plusieurs satellites se portent candidats au service du même mobile du fait de leur visibilité simultanée par ce mobile.

Comme plusieurs algorithmes de choix du satellite successeur sont applicables, nous avons commencé par l’algorithme le plus élémentaire: celui du handover aléatoire vers l’un des satellites en vue. Nous avons voulu savoir si cet algorithme réalise l’équilibre de Nash (qui consiste à satisfaire l’opérateur et le client).

L’interprétation des résultats de cet accès aléatoire pour différents scénarios (où nous avons varié le nombre de mobiles, le nombre d’applications et le rapport des deux types d’applications) a en effet montré que l’accès aléatoire a rempli les exigences de l’opérateur en ce qui concerne le critère d’équilibre de charge dans le réseau.

Ce critère va aussi dans le sens de la satisfaction du client puisqu’il optimise la disponibilité du réseau. Pour être plus clair, l’équilibre des charges optimise la probabilité de blocage des communications de voix.

D’autre part, il régule le temps moyen de service des paquets dans le cas d’une application de données.

Ainsi, l’algorithme d’accès aléatoire semble convenable lorsque le critère majeur est l’équilibre des charges dans la constellation.

Mais est-ce que d’autres algorithmes de choix ne donneraient pas des résultats pareils sinon meilleurs lorsque d’autres critères seront envisagés? Nous citons à titre d’exemple l’accès tenant compte de la charge résiduelle maximale, dans lequel, le handover de la communication aura lieu vers le satellite en vue ayant la charge résiduelle maximale.

D’autre part, est-ce que la diversification des scénarios dans lesquels les clients se déplacent à l’intérieur de la surface d’observation S donnerait des résultats analogues pour le critère d’équilibre de charge ?

Annexe A

A.1 Description physique de l’orbite
A.1 Description physique de l’orbite

Dans cette annexe nous donnons une description physique de l’orbite du satellite. Pour cela, nous commençons par un rappel sur les composants de l’ellipse pour ensuite mettre l’accent sur les éléments importants dans l’orbite du satellite.

Description physique de l'orbite

Légende :
F, F´ : les deux foyers de l’ellipse R : rayon vecteur e satellite
AA’ : horizontale locale du satellite V : vecteur vitesse du satellite
a : demi-longueur du grand axe
b : demi-longueur du petit axe
2c : distance entre les foyers
rp : rayon du périgée
ra : rayon de l’apogée
v: true anomaly
phi: flight-angle path

Figure A.1 Grandeurs caractéristiques de l’orbite elliptique

L’angle phi (flight-path angle) prend une valeur de 0° à l’apogée et au périgée. Il est positif lors du trajet périgée-apogée et négatif dans le sens du retour au périgée. La valeur maximale est de 90°. On peut donc dire que à chaque instant : -90° < phi < 90°

L’angle v (anomalie vraie) varie de 0° à 360°

Caractéristiques des orbites

Lors de la détermination de l’orbite d’un satellite, il y a quatre éléments fondamentaux que l’on voudrait déterminer :

la taille de l’orbite
la forme de l’orbite
l’orientation (du plan de l’orbite dans l’espace et de l’orbite dans le plan)
la position du satellite sur l’orbite

Pour arriver à les connaître, les astronomes ont défini six éléments fondamentaux de l’orbite, appelés les COE, Classical Orbital Elements, ou encore les éléments de Kepler.Le premier de ces éléments n’est autre que la demi-longueur du grand axe de l’ellipse, a. Sa connaissance nous permet immédiatement de connaître la taille de l’orbite.Le deuxième élément est l’excentricité, e. Pour rappel, celle-ci est égale à 2c/2a. La connaissance de cet élément nous permet de déterminer la forme de l’orbite (e=0, cercle ; 0 < e < 1, ellipse).Pour connaître le troisième élément, il faut d’abord introduire la notion de moment cinétique spécifique:h = R × V où h est le vecteur moment cinétique spécifiqueR est le vecteur position du satelliteV est le vecteur vitesse du satelliteLe symbole × représente ici le produit vectoriel (home.pi.be/~pin94312/prdtvect.htm) des vecteurs.Ce troisième élément se définit alors comme étant l’angle orienté du vecteur K au vecteur h (voir figure A.2). Cet angle, noté i, est appelé inclinaison.On peut alors distinguer plusieurs cas en fonction de la valeur de i :

i = 0° ou 180° : on a alors à faire avec une orbite équatoriale, puisque le plan de rotation du satellite est confondu avec celui de l’équateur.
i = 90° : on a alors à faire avec une orbite polaire, puisque le satellite va passer au-dessus des pôles Nord et Sud.
0° < i < 90° : on parle alors d’orbite prograde ou d’orbite directe.
90° < i < 180° : on parle alors d’orbite rétrograde ou d’orbite indirecte.

Le quatrième élément peut se déterminer en faisant l’observation suivante : à l’intersection des plans de l’orbite du satellite et du plan de l’équateur se trouve une ligne, baptisée ligne des noeuds. Les deux points où l’orbite franchit le plan de l’équateur sont les deux noeuds.

le noeud ascendant est le noeud où le satellite passe de l’hémisphère Sud à l’hémisphère Nord (voir fig.2)
le noeud descendant est le noeud où le satellite passe de l’hémisphère Nord à l’hémisphère Sud

On définira donc le quatrième élément comme étant la longitude du noeud ascendant. Cet angle est baptisé omega et est mesuré par rapport à I(voir fig.2)La connaissance du troisième et du quatrième élément (i et omega) nous permet de déterminer l’orientation du plan de l’orbite dans l’espace.

Les éléments de Kepler.
Figure A.2. Les éléments de Kepler.

Le cinquième élément n’est autre que la position angulaire du périgée, le point de la trajectoire du satellite le plus proche du centre de la Terre, par rapport au noeud ascendant et dans la direction du mouvement du satellite. Cet angle est baptisé argument du périgée et est noté w (voir fig.2). Cet élément fournit lui l’orientation de l’orbite dans son plan.Le sixième élément fournit quant à lui la connaissance exacte de la position du satellite sur l’orbite. C’est l’anomalie vraie, que nous avons déjà vue plus haut, qui définit cet élément. Elle est notée v et est mesurée dans le sens de déplacement du satellite également. Il est important de bien comprendre que l’orbite du satellite garde (dans le cas idéal) une position fixe dans l’espace (et non pas par rapport à la Terre, qui elle est en rotation).

Elément Nom Valeurs Description
a demi-longueur du grand’axe Taille
e excentricité compris entre 0 et 1 Forme
i inclinaison compris entre 0° et 180° angle entre K et h
omega longitude du noeud ascendant compris entre 0° et 360° angle entre l’équinoxe vernal et le noeud ascendant
w argument du périgée compris entre 0° et 360° angle entre le noeud ascendant et le périgée
v anomalie vraie compris entre 0° et 360° angle du périgée au satellite

Tableau A.1 Tableau récapitulatif des COE des COE

Parfois, il est impossible de définir ces éléments. C’est le cas notamment des orbites circulaires, équatoriales voire les deux en même temps. On est alors obligé de recourir à des éléments alternatifs.

Annexe B

Terminologie relative aux satellites

A

ACCÈS MULTIPLE PAR ASSIGNATION EN FONCTION DE LA DEMANDE (AMAD) – Technique employée pour permettre à un nombre relativement important de stations terrestres de partager un nombre restreint de porteuses monovoies.

ACCÈS MULTIPLE À RÉPARTITION PAR CODE (AMRC) – Technique d’accès permettant à chaque station terrestre d’émettre sur la même fréquence et au même moment, mais seulement à un niveau de puissance donné et limité. Cette technique exige que chaque station utilise un code d’identification unique qui est modulé avec le signal de communications. L’AMRC est une technique d’accès employée avec la distribution de données par étalement du spectre ainsi que certains systèmes mobiles de télécommunications par satellite et certains systèmes VSAT.

ACCÈS MULTIPLE À RÉPARTITION DANS LE TEMPS (AMRT) – Technique d’émission par rafales qui permet à plus d’une station terrestre d’avoir accès à la même porteuse.

ACCÈS MULTIPLE PAR RÉPARTITION DE FRÉQUENCE (AMRF) – Technique employée pour permettre à plus d’une station terrestre de partager la bande passante d’un transpondeur de satellite. On affecte à chaque station terrestre une porteuse ou un groupe de porteuses aux fins d’émission dans une portion donnée de la bande passante.

ACCÈS AVEC MULTIPLEXAGE TEMPOREL – Méthode de transmission des données qui consiste à envoyer simultanément sur un seul canal les flux de données qui proviennent de plusieurs sources.

ANGLE D’INCLINAISON – Angle d’observation de la station terrestre en degrés au-dessus de l’horizon. Un angle de 0º signifie que le satellite se trouve au niveau de l’horizon et un angle de 90º signifie qu’il se trouve directement au-dessus de nos têtes.

B

BANDE C – L’une des deux principales bandes de fréquences (l’autre est la bande Ku) par lesquelles passent les communications par satellite. Les stations terrestres en bande C émettent dans la plage de fréquences de 6 GHz et reçoivent dans la bande de 4 GHz.

BANDE DE BASE – Plage de fréquences du signal d’information (voix, données ou image) avant que celui-ci soit modulé sur un porteuse satellite. À titre d’exemple, la bande de base de la voix s’étale entre 300 Hz et 3 400 Hz.

BANDE Ka – Bande de fréquences satellite. L’émission se fait dans la plage de fréquences de 30 GHz et la réception, dans la plage de 20 GHz.

BANDE Ku – L’une des deux principales bandes de fréquences satellite, l’autre étant la bande C. Les stations terrestres en bande Ku émettent dans la plage de fréquences de 14 GHz et reçoivent dans la plage de 12 GHz.

BANDE PASSANTE – Mesure de la partie du spectre des fréquences occupée par un signal. La mesure est habituellement en hertz (Hz), en kilohertz (kHz) ou en mégahertz (Mhz).

C

CANAL – Voie de transmission reliant deux points.

D

DÉMODULATEUR – Appareil qui extrait le signal de la bande de base d’une porteuse modulée.

E

EMPREINTE – Surface sur la terre couverte par le signal d’un satellite.

F

FAISCEAU ÉTROIT – Faisceau d’une antenne de satellite qui n’assure le service que dans une partie de la couverture totale du satellite.

FDD – Frequency Division Duplex. Multiplexage avec duplex fréquentiel, où les voies montantes et descendantes utilisent les mêmes intervalles de temps, mais avec des fréquences séparées.

G

GPRS – Global Packet Radio Service. Cette norme 2,5G permet la transmission de données en mode paquet sur une infrastructure de réseau GSM. Cette technologie autorise un débit trois à quatre fois supérieur à celui du GSM, soit environ 40 kbit/s. Après l’ouverture d’une session vers Internet ou un intranet, l’utilisateur est connecté en permanence.

I

Itinérance (ou Roaming) – Il s’agit de la possibilité offerte aux utilisateurs d’un terminal GSM ou UMTS de bénéficier d’une partie de leurs services lorsqu’ils se trouvent sous la couverture d’un réseau qui n’est pas leur réseau nominal (à l’étranger par exemple). Ainsi le client Orange qui se déplace, en Europe par exemple, a la possibilité de garder le même numéro de téléphone et de recevoir tous les appels et les messages qui lui sont destinés. L’abonné est facturé par son opérateur grâce à des accords passés entre les différents opérateurs.

L

LIAISON ASCENDANTE – Trajet parcouru par le signal entre une station terrestre et un satellite.
LIAISON DESCENDANTE – Trajet parcouru par le signal entre un satellite et la station terrestre réceptrice.
LIAISON ENTRE INSTALLATIONS – Liaison entre une antenne et son matériel au sol.
LIAISON TERRESTRE – Circuit terrestre qui relie le matériel dans les installations du client à un bureau central ou à une station terrestre centrale partagée (un téléport, par exemple).

M

MODULATION – Procédé qui consiste à modifier certaines caractéristiques de la porteuse en fonction de celles du signal à transporter. Par exemple, on peut modifier la fréquence de la porteuse en fonction de l’amplitude du signal.

P

PORTEUSE – Onde radio monofréquence d’amplitude constante qui peut être modulée avec un signal porteur d’information.
PROTOCOLE – Ensemble de conventions régissant le format et la position temporelle relative des messages échangés entre deux systèmes de communications.
PROTOCOLE ALOHA PUR – Protocole semblable à Ethernet qui permet à toutes les stations terrestres dans un réseau de partager la bande passante entrante.
PROTOCOLE ALOHA À SEGMENTATION TEMPORELLE – Moyen permettant de partager la capacité spatiale entrante d’un réseau VSAT. Le protocole Aloha à segmentation temporelle assure la synchronisation des créneaux temporels fixes dans un réseau VSAT. Ce protocole convient surtout si les messages sont de petite taille, si le réseau est vaste et si les transactions sont peu fréquentes et prévisibles.

R

RÉSERVATION – Méthode de partage de la capacité spatiale entrante d’un réseau VSAT. L’expéditeur peut réserver un créneau avant d’envoyer le message. Cette méthode est utile surtout lorsque les messages sont importants et peu fréquents.

S

SATELLITE GÉOSTATIONNAIRE – Satellite à 35 786 km au-dessus de l’équateur qui décrit son orbite à une vitesse identique à la vitesse de rotation de la Terre. Depuis la Terre, le satellite semble immobile. La position du satellite est définie en fonction de la longitude d’un point au sol sous celui-ci.
STREAMING – Procédé qui permet d’utiliser les données (vidéo, musique) au fur et à mesure qu’elles sont transmises donc sans attendre un téléchargement complet qui peut prendre beaucoup de temps.

T

TANGAGE – Mouvement d’un satellite autour d’un axe qui passe par son centre de gravité et qui entraîne un déplacement de l’empreinte de l’antenne vers l’est ou vers l’ouest.
TAUX D’ERREURS SUR LES BITS – Rapport du nombre de bits reçus de façon erronée au nombre de bits émis.
TEMPS DE PROPAGATION – Temps qu’un signal met à monter jusqu’au satellite et à retourner à la terre. Les signaux satellite voyagent à la vitesse de la lumière et font le trajet en 270 millisecondes.
TRANSPONDEUR – Matériel satellite qui reçoit les signaux de la liaison ascendante, les convertit à la fréquence de la liaison descendante et les amplifie aux fins de ré-émission vers la terre.
TDD- Time Division Duplex. Multiplexage temporel dans les deux sens de transmission sur une seule fréquence : les voies montantes et descendantes utilisent à tour de rôle la même fréquence.
3G – Third generation. Réseau de troisième génération.
3GPP – Third Generation Partnership Project. Forum de normalisation regroupant l’ETSI, l’European Telecommunications Standard Institute, les organismes homologues des Etats-Unis, au Japon, en Chine et en Corée. A travers eux, ce sont les principaux constructeurs et opérateurs des grands pays industriels qui échafaudent ensemble les spécifications techniques, de l’UMTS qui sont ensuite reprises par les différents organismes de normalisation membres du 3GPP.

V

VDI – Voix, données, image.
VSAT – Very Small Aperture terminal. Station terrestre réceptrice et émettrice à très petite ouverture d’antenne. Le diamètre de l’antenne ne dépasse pas 2.4 m.
Visiophonie – Technique qui permet de transmettre en temps réel à la fois le son et l’image.

Annexe C

C.1 Code source de optimum_access.c
C.2 Résultats du code optimum_access.c
C.1 Code source de optimum_access.c

# include
#include
#include

long factoriel (int i);
float a_exp_n (float a, int n);
float Prob_blocage (float t_arrivee,float t_service, int nb_channels);
int main (int argc, char *argv[])
{
int ret = 0, i = 0;
float blocage_reseau =0, prob_bloc_A = 0, prob_bloc_B =0;
float t_arriveeA= 0, t_serviceA = 0, t_arriveeB =0, t_serviceB =0;
int nb_canauxA = 0, nb_canauxB = 0;
float p_th_A = 1e-3;
float p_th_B = 1e-3;
float p_th_res = 1e-6;
float prob_B = 0;
float prob_res = 0;
int th_A = 0, th_B = 0,th_res = 0;
FILE *fd = NULL;
char buff[1024]=””;
int nwritten = 0;
char buff2[] = “”;
const char titre[] = “Dans cette simulation, on fixe les paramètres du satellite B
ntaux_arrivee=140 clients par min
ntemps de service=2min
n nb de canaux = 90
nDonc la probabilité de blocage du satellite B est constante egale à :n”;
const char string[] =”net pour A,on fixe taux_service, et on fait varier taux_Arrivee de 130 a 140
navec un pas de 1, d’ou 10 iterations.
non recueille les valeurs dans buff
nSi pA depasse le seuil de blocage, th_A est mis a 1(set)
nde meme pour p_res.
nprobalilité de blocage:nt_arriveeA SatelliteA(*10e(-3))tth_AtRéseau(*10e(-6)) th_resn”;
printf(“strlen buff%d”,strlen(buff));
fd = fopen(“result10.txt”,”w”);
if (!fd)
{
printf(“couldn’t open file result10.txtnexitingn”);
ret = -1;
}
else
{
fwrite(titre,sizeof(char),strlen(titre),fd);
t_arriveeA = 130.0;
t_serviceA = 2.0;
nb_canauxA = 90;
t_arriveeB = 140.0;
t_serviceB = 2.0;
nb_canauxB = nb_canauxA;
prob_bloc_B =Prob_blocage(t_arriveeB, t_serviceB, nb_canauxB);
if(prob_bloc_B >=p_th_B)
th_B = 1;
else th_B =0;
fd = fopen(“result10.txt”,”a”);
prob_B = 1000*prob_bloc_B;
sprintf(buff2,”%f*10e(-3) th_B = %d”,prob_B,th_B);
fwrite(buff2,sizeof(char),strlen(buff2),fd);
fd = fopen(“result10.txt”,”a”);
fwrite(string,sizeof(char),strlen(string),fd);
printf(“calcul de la probabilite de blocage du satellite An”);
prob_bloc_A = 1000*Prob_blocage(t_arriveeA, t_serviceA, nb_canauxA);
printf(“nProbabilite de blocage satellite A:%f*10e(-3) n”,prob_bloc_A);
blocage_reseau = prob_bloc_A*prob_bloc_B;
for(t_arriveeA=130;t_arriveeA<=140;t_arriveeA+=1)
{
prob_bloc_A = Prob_blocage(t_arriveeA, t_serviceA, nb_canauxA);
if(prob_bloc_A>=p_th_A)
th_A = 1;
else th_A =0;
blocage_reseau = prob_bloc_A*prob_bloc_B;
if(blocage_reseau>=p_th_res)
th_res = 1;
else th_res =0;
prob_res = 1000000*blocage_reseau;
fd = fopen(“./result10.txt”,”a”);
if(!fd)
ret =-1;
else
{
sprintf(buff,”%.2ftt%ftt%dt%ftt%dn”,t_arriveeA,1000*prob_bloc_A,th_A,prob_res,th_res);
nwritten=fwrite(buff,sizeof(char),strlen(buff),fd);
if(!nwritten)
ret = -1;
}
}
}
return ret;
}
float terme_i(float charge, int i)
{
int j = 1;
float ret = 1;
for(j=1;j<=i;j++)
{
ret *= charge/j;
}
return ret;}
float Prob_blocage (float t_arrivee,float t_service, int nb_channels)
{
int i =0;
float charge = 0,somme_i = 1;
float ret = 0;
if((t_service <=0) ||(nb_channels<=0))
{
printf(“la valeur du taux de service est %f, celle du nombre de canaux:%f !!!non valides”);
ret = -1;
}
else
{
charge = t_arrivee/t_service;
for(i=1;i<=nb_channels;i++)
{
somme_i += terme_i(charge,i);
}
ret = (terme_i(charge,i))/somme_i;
printf(“nProb_blocage : %fn”,ret);
}
return ret;
}

C.2 Résultats du code optimum_access.c

Les éléments du tableau s’interprètent comme suit:
Th_A = 1e-3 : correspond au seuil de probabilité de blocage du satellite A fixée comme critère de QoS par l’opérateur.
Th_B= 1e-3 : correspond au seuil de probabilité de blocage du satellite B fixée comme critère de QoS par l’opérateur.
Th_res= 1e-6 : correspond au seuil de probabilité de blocage du réseau foxée comme critère de QoS par l’opérateur.

t_arriveeB Prob_bloc_B (*1e-3) th_B t_arriveeA Prob_bloc_A (*1e-3) th_A Réseau (*1e-6) th_res
130 0.412645 0 130 0.412645 0 0.170276 0
130 0.412645 0 131 0.502818 0 0.207485 0
130 0.412645 0 132 0.609495 0 0.251505 0
130 0.412645 0 133 0.735012 0 0.303299 0
130 0.412645 0 134 0.881908 0 0.363915 0
130 0.412645 0 135 1.052921 1 0.434483 0
130 0.412645 0 136 1.250983 1 0.516212 0
130 0.412645 0 137 1.479209 1 0.610389 0
130 0.412645 0 138 1.740883 1 0.718367 0
130 0.412645 0 139 2.039438 1 0.841564 0
130 0.412645 0 140 2.378442 1 0.981453 0
131 0.502818 0 130 0.412645 0 0.207485 0
131 0.502818 0 131 0.502818 0 0.252826 0
131 0.502818 0 132 0.609495 0 0.306465 0
131 0.502818 0 133 0.735012 0 0.369577 0
131 0.502818 0 134 0.881908 0 0.443439 0
131 0.502818 0 135 1.052921 1 0.529427 0
131 0.502818 0 136 1.250983 1 0.629017 0
131 0.502818 0 137 1.479209 1 0.743773 0
131 0.502818 0 138 1.740883 1 0.875347 0
131 0.502818 0 139 2.039438 1 1.025466 1
131 0.502818 0 140 2.378442 1 1.195923 1
132 0.609495 0 130 0.412645 0 0.251505 0
132 0.609495 0 131 0.502818 0 0.306465 0
132 0.609495 0 132 0.609495 0 0.371484 0
132 0.609495 0 133 0.735012 0 0.447986 0
132 0.609495 0 134 0.881908 0 0.537518 0
132 0.609495 0 135 1.052921 1 0.64175 0
132 0.609495 0 136 1.250983 1 0.762468 0
132 0.609495 0 137 1.479209 1 0.90157 0
132 0.609495 0 138 1.740883 1 1.061059 1
132 0.609495 0 139 2.039438 1 1.243026 1
132 0.609495 0 140 2.378442 1 1.449648 1
133 0.735012 0 130 0.412645 0 0.303299 0
133 0.735012 0 131 0.502818 0 0.369577 0
133 0.735012 0 132 0.609495 0 0.447986 0
133 0.735012 0 133 0.735012 0 0.540242 0
133 0.735012 0 134 0.881908 0 0.648212 0
133 0.735012 0 135 1.052921 1 0.773909 0
133 0.735012 0 136 1.250983 1 0.919487 0
133 0.735012 0 137 1.479209 1 1.087236 1
133 0.735012 0 138 1.740883 1 1.279569 1
133 0.735012 0 139 2.039438 1 1.499011 1
133 0.735012 0 140 2.378442 1 1.748183 1
134 0.881908 0 130 0.412645 0 0.363915 0
134 0.881908 0 131 0.502818 0 0.443439 0
134 0.881908 0 132 0.609495 0 0.537518 0
134 0.881908 0 133 0.735012 0 0.648212 0
134 0.881908 0 134 0.881908 0 0.777761 0
134 0.881908 0 135 1.052921 1 0.928579 0
134 0.881908 0 136 1.250983 1 1.103251 1
134 0.881908 0 137 1.479209 1 1.304526 1
134 0.881908 0 138 1.740883 1 1.535298 1
134 0.881908 0 139 2.039438 1 1.798596 1
134 0.881908 0 140 2.378442 1 2.097566 1
135 1.052921 1 130 0.412645 0 0.434483 0
135 1.052921 1 131 0.502818 0 0.529427 0
135 1.052921 1 132 0.609495 0 0.64175 0
135 1.052921 1 133 0.735012 0 0.773909 0
135 1.052921 1 134 0.881908 0 0.928579 0
135 1.052921 1 135 1.052921 1 1.108642 1
135 1.052921 1 136 1.250983 1 1.317186 1
135 1.052921 1 137 1.479209 1 1.55749 1
135 1.052921 1 138 1.740883 1 1.833012 1
135 1.052921 1 139 2.039438 1 2.147367 1
135 1.052921 1 140 2.378442 1 2.504311 1
136 1.250983 1 130 0.412645 0 0.516212 0
136 1.250983 1 131 0.502818 0 0.629017 0
136 1.250983 1 132 0.609495 0 0.762468 0
136 1.250983 1 133 0.735012 0 0.919487 0
136 1.250983 1 134 0.881908 0 1.103251 1
136 1.250983 1 135 1.052921 1 1.317186 1
136 1.250983 1 136 1.250983 1 1.564959 1
136 1.250983 1 137 1.479209 1 1.850466 1
136 1.250983 1 138 1.740883 1 2.177815 1
136 1.250983 1 139 2.039438 1 2.551303 1
136 1.250983 1 140 2.378442 1 2.975391 1
137 1.479209 1 130 0.412645 0 0.610389 0
137 1.479209 1 131 0.502818 0 0.743773 0
137 1.479209 1 132 0.609495 0 0.90157 0
137 1.479209 1 133 0.735012 0 1.087236 1
137 1.479209 1 134 0.881908 0 1.304526 1
137 1.479209 1 135 1.052921 1 1.55749 1
137 1.479209 1 136 1.250983 1 1.850466 1
137 1.479209 1 137 1.479209 1 2.18806 1
137 1.479209 1 138 1.740883 1 2.57513 1
137 1.479209 1 139 2.039438 1 3.016756 1
137 1.479209 1 140 2.378442 1 3.518213 1
138 1.740883 1 130 0.412645 0 0.718367 0
138 1.740883 1 131 0.502818 0 0.875347 0
138 1.740883 1 132 0.609495 0 1.061059 1
138 1.740883 1 133 0.735012 0 1.279569 1
138 1.740883 1 134 0.881908 0 1.535298 1
138 1.740883 1 135 1.052921 1 1.833012 1
138 1.740883 1 136 1.250983 1 2.177815 1
138 1.740883 1 137 1.479209 1 2.57513 1
138 1.740883 1 138 1.740883 1 3.030672 1
138 1.740883 1 139 2.039438 1 3.550422 1
138 1.740883 1 140 2.378442 1 4.140589 1
139 2.039438 1 130 0.412645 0 0.841564 0
139 2.039438 1 131 0.502818 0 1.025466 1
139 2.039438 1 132 0.609495 0 1.243026 1
139 2.039438 1 133 0.735012 0 1.499011 1
139 2.039438 1 134 0.881908 0 1.798596 1
139 2.039438 1 135 1.052921 1 2.147367 1
139 2.039438 1 136 1.250983 1 2.551303 1
139 2.039438 1 137 1.479209 1 3.016756 1
139 2.039438 1 138 1.740883 1 3.550422 1
139 2.039438 1 139 2.039438 1 4.159308 1
139 2.039438 1 140 2.378442 1 4.850686 1
140 2.378442 1 130 0.412645 0 0.981453 0
140 2.378442 1 131 0.502818 0 1.195923 1
140 2.378442 1 132 0.609495 0 1.449648 1
140 2.378442 1 133 0.735012 0 1.748183 1
140 2.378442 1 134 0.881908 0 2.097566 1
140 2.378442 1 135 1.052921 1 2.504311 1
140 2.378442 1 136 1.250983 1 2.975391 1
140 2.378442 1 137 1.479209 1 3.518213 1
140 2.378442 1 138 1.740883 1 4.140589 1
140 2.378442 1 139 2.039438 1 4.850686 1
140 2.378442 1 140 2.378442 1 5.656987 1

Table C.1 Résultats du programme optimum_access.c

Optimisation de l’accès Low Earth Orbit LEO
Mémoire de fin d’études – Réseaux de télécommunications
Université Saint-Joseph, Faculté d’Ingénierie

Sommaire :

Bibliographie

[1] Conception des réseaux par André Girard, Janvier 2004.
La référence comprend une explication des méthodes d’optimisation de problèmes avec contraintes, ainsi qu’une analyse détaillée sur des problèmes de dimensionnement de réseaux.

[2] Planification des réseaux cellulaires par Sami Tabbane, 2003-2004
La référence comprend une description des réseaux de télécommunications GSM ainsi qu’une introduction sur l’UMTS.

[3] Les architectures de service par Samir Tohmé, Avril 2004
Le document présente le schéma d’interconnexion de différents types de réseaux.

Références et webographie
[1] fr.gsmbox.com/satellite/satel.gsmbox
et fr.gsmbox.com/satellite/leo.gsmbox . Deux sites de valeur pour une connaissance approfondie sur les satellites LEO.

[2] www.rd.francetelecom.com/fr/technologie/ddm200401/glossaire.php
Il offre une explication détaillée sur les modes d’accès multiple notamment le TDMA et le CDMA